|
hardware loving owns, except making cables, sometimes you need a cable like right loving now and have to hand assemble things and it sucks workin on a little radio project with a PIC24FJ128GA204 right now, 44-pin QFN, 16-bit, up to 96 MHz clock, 3 SPI, 2 I2C, 4 UARTs, most functions are remappable which is new compared to the PIC18s i've used before (thought that was still a high end DSP feature) its nice to have a real SPI controller instead of a glorified shift register, 128-byte fifos on tx and rx and DMA in case i need even more buffering, perfect for my application where the main function is manipulating a low speed serial stream (reclocking + inserting data at start/end) 12-bit AD instead of the standard 10-bit is also an improvement, and 40nA deep sleep consumption a consultant at work said to try kicad so trying that now, it's pretty easy to use for CAD software, not as good as Allegro at schematics but very easy to draw symbols, haven't tried the PCB layout yet but it's probably just as terrible as commercial software
|
#
¿
Dec 1, 2014 21:49
|
|
|
|
| # ¿ Apr 29, 2024 11:53 |
|
|
Werthog 95 posted:i still don't know how to assemble a cable :-( buy a labelmaker that does shrink tubes and also buy good shrink tubes with glue, and ridiculously expensive industrial/mil connectors and the outrageously priced crimping tools, don't forget special pin insertion tools, and calibrated wire strippers, and teflon insulated wire, make a checklist and follow it, label every wire there's a reason we outsource these things i like the ecoMate m connectors from amphenol for power, IP65 or something, easy to assemble and cheap, 3+PE and 6+PE with screw/solder terminals i also like running things over standard cat5 cable, ebay has loads of bulkhead mount female RJ45 outlets with a short male cable on the end that work pretty well + are cheap
|
|
#
¿
Dec 1, 2014 22:07
|
|
|
made even more cables, getting better each time real happy with the brady bmp21 labelmaker, prints right on shrink tubes and it looks pro as gently caress, labelling on each end of the cable. only annoyance is the tubes are a bit hard to shrink all the way and its tedious with 60+ labels to shrink, and the smallest size doesn't fit anything smaller than ~AWG 18 neatly. today i brought it to a whole 'nother level, brought out the lacing thread and proper knot technique, a bit tricky to make good ends with PTFE wiring but it's doable still glad we're outsourcing most of this for production, but it's nice to have properly built prototype hardware instead of hundreds of unlabelled flying leads, and i'll still get to do some patch wiring with all the wank i want for the final hardware
|
|
#
¿
Dec 4, 2014 19:24
|
|
|
should i use something like freetros for my next project or just do what i always do and write ad hoc routines and a ten page exception handler? it's mostly just shifting serial data around, maybe some DMA, sleep and a ton of scheduled monitoring tasks
|
|
#
¿
Dec 12, 2014 19:22
|
|
|
i should probably clarify that the serial data is 4800 baud and the DMA would just be for a laugh, with ~20 mips of pure integer processing power I can bit bang this no problem but i don't want to i might still give freertos a try to see what it's like but i can definitely write this in standard C and a couple of state machines + a set of timed interrupts to handle maintenance tasks like self testing, monitoring battery status etc. new question i guess: my serial data is synchronous, the radio interfaces handle clock recovery and sync, but i need to receive some data from a sound card (ASK) interface with no clock UART is a no go since it's a bit-stream with no byte boundaries that it can detect i know the baud rate, so i was thinking i'd run it to a SPI input in master mode and use 4x (or more) oversampling to resolve ambiguity when the clock edges drift together (only one bit out of four is likely to be clobbered by sampling on a transition so majority rule) the other obvious option is to hook the input to an interrupt in the MCU and use a timer to count the on/off times and calculate each bit that way SPI mode might be less work, and fits my hardware architecture, but i do have remappable pins so it should be possible reconfigure the pins on the fly obviously i could also find some modem IC or add hardware to do clock recovery, but i don't want to spend too much money on this feature E: or I could just emulate a commercial products serial interface and drop the ASK, that might be easier for everyone longview fucked around with this message at 11:58 on Dec 13, 2014 |
|
#
¿
Dec 13, 2014 11:46
|
|
|
the saleae Logic series is pretty nice for slowish logic, the new ones are mixed signal too, not a scope replacement but a nice supplement if you're troubleshooting timing and logic problems instead of signal integrity issues
|
|
#
¿
Dec 17, 2014 17:27
|
|
|
movax posted:agilent fabs their own frontend components on an InP process for their 90000 series, 32ghz of true analog bandwidth (that's the 5th harmonic of 12.5Gb/s and third of 21) i've seen die shots of that thing, they're large enough that they had to make microstrip lines inside it to carry the signal to the actual ADC banks
|
|
#
¿
Dec 23, 2014 13:38
|
|
|
Mido posted:no, gently caress when you move up to spectrum analyzers and storage scopes their clothes literally fall off right there
|
|
#
¿
Dec 25, 2014 10:23
|
|
|
effortpost on single ended logic: the real issue also involves the speed of signal transmission, the speed of light is finite in a wire (and in free space), in a pcb its around half the free space speed if a digital line is 1 ns long (~5-6" in a PCB, or around 1 standard western dick) and you're driving a signal that takes 10 ns to move from 0 to 1, no problem, if it takes 100ps then you need to terminate the signal properly or the signal edge will reflect when it reaches the end of the line and come back, if the source isn't matched either it tends to keep bouncing back and forth until it settles. series termination is preferred where possible since it's simple and just means adding a resistor to each line at the worst, sometimes AC termination is used but this tends to cause more problems than it solves in my experience the voltage at the signal input may have oscillated a few times before settling, which can cause real problems if the voltage at the end of the line oscillates down to logic 0 before settling, fast logic may pick this up as a double clock, even if the actual clock speed is slow as balls additionally the capacitance in the line needs to be charged at the slew rate (rate of voltage change) if there's a lot of inductance between the grounds of two devices then that fast edge will create a voltage between "true ground" and the driver and the receiver grounds, which further reduces the signal to noise ratio this is why fast logic and solderless breadboards dont play nice together, the leads used for power and ground are just too long for real fast poo poo the bond wires inside the package cause the same problem, which is why modern ICs often come with a big ground pad in the middle (QFNs, some QFPs etc.), DIP packages are usually right out since the pin spacing forces long bond wires inside the package that may actually make the IC unusable CMOS logic basically connects each output to either VCC or ground, which also means that for most devices the current draw of a CMOS device is very low until you try to drive an output, when going from 0 to 1 on the output the driver will be connected from ground to VCC, the current going into the line (charging all that capacitance) has to come from the power supply, so the current waveform of a CMOS device will be a series of pulses with the same rise time and frequency as the sum of all the outputs, i.e. a series of very high frequency pulses if you forget to put bypass caps near the IC then the inductance in a power supply lead will cause the supply voltage to sag during the transitions, this results in a lovely signal on the output, and may cause problems for the IC if the voltage drops below the minimum operation voltage this is one of the many reasons LVDS and similar differential serial protocols are heavily used in modern designs, ground potential between devices matters a lot less when the signal is differential and ideally the sum of the current draw when two outputs are differential is more or less constant
|
|
#
¿
Dec 30, 2014 00:27
|
|
|
I have the original Fluke 17B, the word on the street is it was a legit Fluke, just a special version for Asian markets. A year later I bought an Agilent U1272B, a far better instrument. Also bought a full set of probe tips (super fine SMD probes, SMD clips, small insulated alligator clips) and the "leather" carry case. Unfortunately I had to buy my large alligator clips from Fluke, a set of huge clips is great for clipping onto N connector barrels or other large bits of chassis for grounding. Also used the same set of batteries from 2011 up to a few months ago (lithium AAAs are great). I checked the DC accuracy of the 17B a little while ago with my home made 5.0000V (+-100µV or so on a calibrated 289) reference and it measured 5.04V whereas the Agilent had 4.999 to 5.000. I guess that's ok for most uses, but not great for precision circuitry. I have a $100 instrument I bought around the same time as the Fluke and that's smaller, came with better probes and had the same features + True RMS, haven't checked the accuracy. Only upside for the Fluke over that is that it runs on AAs instead of 9V batteries. Anyway you should all get the Keysight U1272B or better instead of Flukes, I don't care for the Fluke 289, it's slow to power up and the menu system involves a lot of navigation to get to common modes.
|
|
#
¿
Jan 1, 2015 20:59
|
|
|
Arcsech posted:the 17b indeed a legit fluke but it is really rather poo poo, which is why they only sell it overseas I routinely use the 87V at work, it's a solid meter but it's pretty simple, the 179 is a very solid meter that I sometimes use too, it seems to do most of the useful things a 87V does to the point that I don't really see the point of a 87V for general lab use. I still recommend the U1272B since it's a better instrument for your money than a 289 or a 87V while offering some potentially quite useful features the 179 and 87V don't have all the real flukes have super nice mode selection knobs though, the keysight version feels super cheap compared to it
|
|
#
¿
Jan 1, 2015 23:59
|
|
|
been playing with a we just bought it and got a package deal with pretty much every optional extra included, segmented memory + hardware protocol analyzer is pro as gently caress, record several seconds of serial traffic at 2.5 GSPs and export waveforms + CSV of all traffic like it's no big deal so far pretty much everything i've wanted to do just required some fiddling and yup, it can do it
|
|
#
¿
Jan 14, 2015 20:09
|
|
|
somewhat unexpectedly a 5V OCXO module showed up in the mail today, just got it installed and tuned in the "new" HP 5335A counter. managed to find the 24V standby that's designed to drive the heaters so it'll stay warmed up when powered off too for $30 it's pretty good, used of course but the supplier was nice enough to write the pinout on the module with a marker pen, even included the "correct" tuning voltage which seems to have shifted a bit during transit keeps around +-1 ppb short term when warmed up, decent enough since the spec was +-30 ppb, a lot of hysteresis in the tuning so it's kind of tricky to adjust very finely kind of disappointed with whoever bought this counter originally, a 10 digit frequency counter with no OCXO is pretty shameful, if they still cost $50 i'd have installed a rubidium oscillator instead
|
|
#
¿
Jan 23, 2015 23:25
|
|
|
i spent friday night fixing one of my HP 3456As, randomly it would measure 0 ohms with open terminals, but only on the 100k and up range self test threw an error -10, input amp or current source error checking the output voltage on the various ohms ranges showed it produced no output voltage for 100k and up, so obviously nothing would be measured following the 385 page user/service manual I skipped most of the tests and just measured some test point voltages when i found nominal values, in the current source section there's a fairly intricate circuit to generate a wide range of constant currents based on the range, that current is passed through a resistor to measure the voltage across it and indirectly, the resistance the voltage reference test point was spot on for the working ranges and seemed to be hitting a supply rail on the broken ranges here's the list of ranges and currents  the service manual suggested checking some transistors that switch in the two reference voltages, Q201 and 2  this manual seems to have lost some of the little dots that show line junctions, pretty sure U203:2 isn't just connected to a test point for example. anyway, U202 is a quad comparator, HA2 on the input is a TTL signal that's part of the range switching system the purpose is to switch either the -5.5V reference (which is trimmed) or the -9.25V reference through to the rest of the circuitry notice that right in the middle there's some resistors with a line around them, those are precision resistors inside a HP custom hybrid, if that breaks the instrument is junk checking some voltages in here i found that the -9.25V was fine at one end of Q202, but for some reason it wouldn't switch so the 9.25V reference wouldn't get through and no current would flow after dicking around for a bit and trying to remember how a JFET worked, i did some diode tester measurements comparing the two transistors and found there were identical, so Q202 was almost certainly ok as it might not be very clear, the purpose of U202 is to pull the gate of Q201 and Q202 to -18V to completely turn them off, the inputs on the two are inverted so a single TTL signal selects one of the two references finally i used a ohm-meter to measure from the output of U202a and b down to -18V (U202 is a LM339, which has open collector outputs), the b output would switch between 15Mohm and around 40 ohms, the a output would switch from 36 to 39 ohm in the off state.  after checking that the inputs were in fact being set correctly i cut the relevant pin, and the 100k+ ranges worked perfectly, i happened to have around 50 LM339s in my IC box so replacing it was a simple job
|
|
#
¿
Feb 1, 2015 11:47
|
|
|
 guys there's something wrong with my bits
|
|
#
¿
Feb 4, 2015 19:50
|
|
|
Bloody posted:i am looking for a decent reference for rf circuits things. coworker told me some website like rfcircuits.com or something but coworker was wrong. any suggestions? if you're taking book suggestions i used this in school, it does a decent job explaining modulation forms, radio receivers/transmitters and transmission line stuff, IIRC it was pretty good at showing circuit examples too http://www.amazon.com/Modern-Electronic-Communication-9th-Edition/dp/0132251132
|
|
#
¿
Feb 16, 2015 22:14
|
|
|
depending on how lovely the layout and power supply network is the fix could be anything from putting bigger caps in all the way to redesigning the layout and power supply kind of wish ECL had taken off, the power supply requirements for high speed PECL are much lighter than high speed CMOS
|
|
#
¿
Feb 21, 2015 13:15
|
|
|
what's the alternative to an FPGA? serious question, everything i work with has an FPGA in it and i don't see how we realistically could do without them, we also have a lot of people in their 20s and 30s who exclusively do FPGA coding
|
|
#
¿
Jun 28, 2015 19:49
|
|
|
i guess that makes sense for high volume consumer stuff, though i'd hate to lose the ability to reflash FPGAs in the field (unless you can do that in ASICs now?)
|
|
#
¿
Jun 28, 2015 20:05
|
|
|
Also nothing you know from c programming will make sense, I spent a week making some leds flash
|
|
#
¿
Jun 29, 2015 20:35
|
|
|
guessing they're using ECL for the core logic then? i'd imagine standard TTL would be too jittery for that
|
|
#
¿
Jul 26, 2015 10:29
|
|
|
karasu posted:anybody have DDR3 layout experience? at what point are you supposed to do simulations on signal integrity? DDR2+ basically requires field solvers with IBIS models, there's no real way to make a good layout otherwise, using one integrated with the layout software would be the best choice since you don't have to change tools (gonna cost a good  or so)biggest wtf moment is when you realize the speed difference between outer and inner layers adds up to several centimeters length difference
|
|
#
¿
Oct 19, 2015 15:43
|
|
|
karasu posted:What our layout team did was calculate the traversal speed of the different signal layers and make a big spreadsheet which lists the lengths that each signal spends on every plane and calculate the combined delay. Then they added detours for some signals so that all the signals of a group have the same delay. We're using Altium which has signal integrity functionality but nobody used it. I joined the project when the first boards were already in the house, otherwise I would have freaked out with this workflow like our FAE did. lol full disclosure: i haven't actually done a DDR3 design yet, next week i'm off to denmark for a design course, at least i'll be using straight chips and not DIMMs i'm expecting to have to do the simulations and fine tuning myself on the layout though, i don't expect a PCB layout artist to know the SI tooling very well
|
|
#
¿
Oct 21, 2015 20:17
|
|
|
those old HP scopes are usually equivalent time below a certain timebase, really annoying because they don't give a clear indication of when that is all the newer fancy HP instruments run windows XP too, but they do offer windows 7 now. they just released a UI refresh that makes them look and perform like a CD player program from 2002 (http://literature.cdn.keysight.com/litweb/pdf/5991-3864EN.pdf?id=2432677) just get a rigol DS1054z for home use, it's well built, lots of features (advanced triggering, protocol decoders, all standard measurements), can be upgraded to 100 MHz and they all come with USB, LXI Ethernet and USB flash drive support as standard, either one can do screenshots that series also has a fairly wideband front-end so it will show sine wave signals significantly above 100 MHz, although loss increases a fair bit above 200 MHz and the frequency counter stops working above 100 or so I've tried several tektronix MDO 3000 series scopes through work (though we don't use tek scopes in my department), rigol scopes are easier to use, have better looking UIs (and better persistence rendering) and are actually responsive whereas the low end tek scopes are super slow to do anything.
|
|
#
¿
Nov 2, 2015 22:09
|
|
|
at 200 kHz even a saturated transistor should switch fine, biggest trap is using too high value pull-ups if you're doing RTL gates fwiw LTSpice does a pretty good job simulating standard 2n3904/bc547s so if you really care just pop it in there and do an AC sweep or run some steps into it
|
|
#
¿
Dec 21, 2015 21:53
|
|
|
too much work, just get some FRAM instead of NOR flash
|
|
#
¿
Jan 20, 2016 21:20
|
|
|
DuckConference posted:haha, list price for a 1Mbyte chip is like $50 that's why i only used a 512 kbyte chip in my design (also ~1 gbit of NOR)
|
|
#
¿
Jan 20, 2016 22:32
|
|
|
i imagine it's pretty profitable making things like OP07 opamps, they've been production for something like 30 years and I doubt the price has gone down much while the costs must be close to zero compared to when they were new and i'd expect the yield is close to 100% for the simpler stuff, that + using established cheap processes certainly sounds profitable also using a larger process is better for higher voltages and ESD tolerance isn't it? e: or rather, larger geometries are better, and larger geometry circuitry might as well be built on a larger process longview fucked around with this message at 16:22 on Mar 5, 2016 |
|
#
¿
Mar 5, 2016 16:13
|
|
|
seems like you'd just get an LTM2884? unless you need USB 3, then I have no idea what to use
|
|
#
¿
Mar 7, 2016 21:00
|
|
|
that makes it a bit more complicated... dp83867xx series seem like decent gbit PHYs, assuming you can do RGMII or SGMII interfaces. at least they come in packages that won't make you want to cry like the "QFN" that's actually an LGA that one of the larger PHY mfgs put out or just put in an SFP+ cage and run 10 gbit fiber
|
|
#
¿
Mar 7, 2016 21:18
|
|
|
well with TIs PHYs you have the DP83867IR that's a QFP/QFN with no SGMII, or the IS version with SGMII as an option marvell requires an NDA for data sheets but is used a lot, no experience with them myself we have an informal ban on LGA packages since they're nearly impossible to use with conformal coating (BGAs are difficult enough if you want to coat each ball)
|
|
#
¿
Mar 7, 2016 21:31
|
|
|
at the risk of starting a new topic, how do you more professional coders like to define bitfields like external HW config registers? since everyone who is good at coding is on vacation and i have HW that needs testing i've been coding C/C++ for the ARM processor on my embedded board my definition for a generic bitfield register now looks like this: code:is there another good way to define a register like that where I need to be able to read and set single bits/very small int values for cases where multiple bits are grouped and still allow easy access to the word level data I need to send to the underlying I2C/SPI controller? the other way I know how to do this is to use some compiler macros to automate the bit-shift boilerplate code and define each register in the preprocessor like #define SOMEDEVICE_SOMEREGISTER_BIT1 1 which works fine for small 8-bit stuff
|
|
#
¿
Jul 14, 2016 20:25
|
|
|
i've already ran into one pitfall, earlier today i was unfucking the I2C driver the SW people wrote (to be fair their intention was correct, but the underlying driver is poorly documented and does unexpected poo poo) anyway i needed to read a flash device ID since the code needs to know what size chip we put in, the ID is 24-bit so i defined another union structure to make the decoding look nicer and i used uint16s for the individual segments (12-bit mfg id and less than 8 bit for the rest) and unioned it with a uint32 to try to avoid issues i also set up an 8-bit wide uint16 to cover the upper byte the uint32 has available no idea what it actually mapped up, but the lower bits were fine, and then it looks like it left aligned the 12-bit mfg id or something in any case, redefining the structure to use all uint32s (1 bit uint32 just seems wrong...) made it map correctly the drivers for this platform have a really nasty tendency to do unexpected stuff that you don't expect, like instantiating a MAC driver to talk to a PHY will automatically set the PHY to SGMII mode for some unknown reason (this is strangely not a part of the lovely autogenerated documentation which only covers the highest level interfaces) another really weird thing is the I2C controller address setting; now you can't just set an 8-bit address in 7 bit mode and expect it to work sure, but what i didn't see coming was how the HW handles it the drat thing decided that bit shifting 1 to the left was correct behaviour, so my reads and writes to 0xF8 and 0xF9 ended up going out on the line as 0xF0 and 0xF3 (it sets the R/W bit correctly at least). that might be common behaviour, but it still seems retarded to me. ended up patching our driver layer to offset the addresses to avoid having to manually offset every single address relative to what the data sheets and schematics say
|
|
#
¿
Jul 14, 2016 20:57
|
|
|
more strangeness (documented but still weird), the TCA6408A I/O expander has a nice feature where it can automatically flip the polarity of I/O pins really nice since I can define this and provide an interface to the higher level code where all the logical signals are active high. except it only bit flips reads, not writes (this is at least documented, if not very clearly) where it gets fun is if you define both inputs and outputs as bit flipped and try to do read-modify-write operations; setting an inverted output high will then make it read as low (while the actual state on the line is high), so that operation will flip every inverted output when you write it back simple enough to work around though, just keep a copy of the polarity mask and XOR it with the data before writing it but still, gotta wonder who thought that was a good idea
|
|
#
¿
Jul 15, 2016 17:14
|
|
|
that type of problem is common enough to have a nickname: ground bounce primary issue is the inductance of the ground plane in combination with the capacitance of the line; to quickly switch a CMOS output you have to charge the capacitance of the line very quickly which causes a lot of problems with inductance in the ground reference that current pull is also a big factor in designing the power supply decoupling network for modern chips since it has to be able to supply the current that goes out on the line (potentially every single output switching at the same instant) using balanced transmission (LVDS, ECL, CML etc.) largely takes care of that specific issue but doesn't mean a free pass since there's a lot of other fun signal integrity issues that can pop up
|
|
#
¿
Jul 18, 2016 19:16
|
|
|
it's really not that difficult with modern circuitry and well designed standards most single ended signals are either too slow to really matter, or they can be series terminated easily enough for low speed board-board use RS-422 for slow poo poo and LVDS with shielded cables (depending on speed and length) for higher speed for really high speed board-board either give up, use ethernet, or use optical (at 10 Gbit you're not gonna run unshielded twisted pair for more than a few inches so forget that idea) also make sure your reference planes are in order, and make sure you've checked the need for power planes (scrub tier high speed stuff will require a power plane capacitor and less than 1 ohm source impedance at 100 MHz). be sure to get accurate mounting inductances for your caps and for anything above ~2V check the CV coefficient to make sure your high CV ceramics are actually useful for gods sake don't run high speed over a cut in either the power or ground plane parallell terminate and use HSTL where possible (DDR3 single rank is set up like this and it makes it fairly easy) don't forget to plan your stackup to be able to break out the signals without via stubs destroying everything (at 10 Gbit/s two good via stubs can be enough to mess it up completely) pushing 30 Gbit? better check the weave in your laminate and make sure to get the right kind of copper for your planes!! see, it's easy also just build everything in ECL, the best logic
|
|
#
¿
Jul 18, 2016 19:38
|
|
|
Mister Sinewave posted:Hey is paralleling modern switching DC-DC converters as a way to increase ability to supply current dumb / even worth looking at? I always thought it was a no-no because it fucks with how switching regulators feedback from the output but I seem to remember that's less of an issue nowadays for some reason. you can but only if the mfg says you can. in general i think it's current mode controllers that work best for parallel operation two choices i know are good: two of these in parallel http://www.delta-elektronika.nl/en/products/s280-series.html or one of these http://www.delta-elektronika.nl/en/products/sm800-series.html
|
|
#
¿
Jul 19, 2016 07:17
|
|
|
oh yeah, completely missed that so get a DC/DC boost converter module from whatever source voltage you have to 300VDC and use a switch mode AC/DC converter  Vicor makes a lot of nice converters but I couldn't find any that were fully adjustable at first glance
|
|
#
¿
Jul 19, 2016 18:31
|
|
|
silence_kit posted:What is the fastest speed used in on-board signaling in consumer electronics? What causes that speed limit--is it FR-4 attenuation, affordable transceiver speed x power limits, or is it a need to reduce system complexity and avoid obsessing over how to do the wiring? Varies a lot I guess, DDR3 is fairly complicated but even modern PCs don't tend to run that at more than 1 GHz (data strobe/clock), bandwidth comes from the large bus width and the complexity is matching delays and getting that delay matching without too much cross talk. It's really pushing it with DDR4 though, since the signalling is single ended and PCs require multiple devices on the same line it's starting to get really challenging to manage the impedances and reflections. They've already had to introduce differential clocks with DDR3. Fair chance the current DDR spec will be replaced with something fairly different in a few years, but that's just speculation. The DIMM based solution is probably running about as fast as we can make it without changing the architecture (like one controller or transceiver set per DIMM). Gigabit Ethernet is either 125 MHz (R)GMII or 625 Mbit/s SGMII so not too fast really, a good ground reference plane and impedance matching the traces takes care of signals at that speed with no problem (at least for smaller designs). As a guess for most common fast link I'd say PCI-E, the latest version apparently does close to 2 Gbit/s per lane which is a respectable speed. Doable with standard laminates if your manufacturer is good, but the real difficulty is probably in designing the connectors and managing skew between pairs for multi-lane cards. 10 gigabit ethernet and similar fiber based protocols aren't really common in consumer gear yet but those are "faster" per link since it's just a single pair for each direction which has to run at 10-16 Gbit/s. Challenge with parallel buses is to manage skew and still get the impedances right, and longer buses need to really think carefully about crosstalk since it becomes a very real problem if not managed. Wiring, essentially. Above ~5 Gbit/s inside a board is the point to start worrying about via stubs (obviously always avoid, but even 1-2 can destroy the signal above those speeds), losses at 10 Gbit/s inside a standard board are manageable with the current transceivers, at least for links shorter than a few inches. Transceivers for those speeds almost always use or can use pre-emphasis and fancy equalizers on both transmit and receive to compensate for losses in the board, and this helps a lot in dealing with resistive and dielectric losses. What they will struggle to deal with is an impedance discontinuity in the middle of the line, since this usually shows up as a notch in the frequency response (and a nice bit of edge-destroying phase distortion), connectors are the biggest source in most cases. 10 Gbit/s per link seems to be the current speed limit for even fairly high end gear; the transceivers are becoming fairly common (most high end FPGAs will have dedicated hardware for 4-16 links). To reach higher speeds the current trend seems to be paralleling up the links (see quad SFP modules). 30 Gbit/s per link is possible in FR-4 but not very common at all. Zopotantor posted:that's fine if you can design something from the ground up; unfortunately for me our backplane was originally designed more than two decades ago, and had one update since then (I think because the original bus transceivers or buffers or whatever they're called were no longer available, lol) ooh, ooh, let me guess: the replacement transceivers were at least 5x faster and nothing worked afterwards
|
|
#
¿
Jul 19, 2016 21:53
|
|
|
|
| # ¿ Apr 29, 2024 11:53 |
|
|
JawnV6 posted:??? yeah i messed up there; i've never done a pci-e design so i have very little experience with it and grabbed the wrong number i also forgot to mention that sata 3 is pretty fast and runs over cables which probably took a fair amount of engineering, but again i've never tried to design a motherboard so i don't know much about what type of tranceivers are used one thing i like a lot is that the same transceivers can be used for pci-e, 10g ethernet, jesd204b (i think), probably sata too. really simplifies design and means the same FPGA can handle several functions without wasting resources on too many special function pins (obviously the high speed transceivers are special function, but they're a requirement in a lot of modern designs)
|
|
#
¿
Jul 20, 2016 14:35
|
|