Analyst Loring Wirbel covers programmable logic from an application perspective, providing a sneak peek at the vertical applications that help drive FPGA complexity, performance, and density. The blog will feature videos allowing engineers to spotlight their latest designs, along with news of products and corporate trends at FPGA vendors and the developers of third-party tools for programmable logic.
Advertisement
Profile
RSS Feed
-
Add this blog to your RSS newsreader!
Recent Posts
- Half-empty, half-full, or new world?
- Into the OTN data stream at OFC/NFOEC
- Altera's Case for DSP in Industrial Control
- Tier Logic's Threefold Path
- Revisiting High-Speed Serial Protocols
- The price of time-sharing and multiplexing
- Putting FPGAs in better control
- Shared foundries, differentiating paths
- Patching in RTL
- ADCs are latest domino to fall
Recent Comments
- Till on Half-empty, half-full, or new world?
- diets for kids under 13 on FPGAs in space-based applications
- Andy T on Into the OTN data stream at OFC/NFOEC
- desert rat on Altera's Case for DSP in Industrial Control
- Andy T on Altera's Case for DSP in Industrial Control
Most Commented On
- Serdes: nice feature or essential element? (13)
- FPGAs as enablers of bad behavior (11)
- It tolls for thee, GPU! (10)
- What do we call Atmel's CAP7L? (10)
- It tolls for thee (8)
Archives
- March 2010
- February 2010
- January 2010
- December 2009
- November 2009
- October 2009
- September 2009
- August 2009
- July 2009
- June 2009
- May 2009
- April 2009
- March 2009
- February 2009
- January 2009
- December 2008
By Category
- Analog (12)
- Broadband (13)
- Business and Marketing (20)
- Communication functions (23)
- Communities (4)
- Components, Hardware, Interconnect (3)
- Computers, boards, buses (52)
- Design Ideas (3)
- DSP (25)
- EDA (13)
- Embedded Systems (7)
- Environmental Compliance (1)
- FPGA Gurus (164)
- Global (4)
- Government/Legal (8)
- Multimedia (14)
- Packaging (1)
- Power Sources/Controllers (2)
- Processors & Tools (31)
- Programmable Logic (143)
- Semiconductors (4)
- Software (12)
- Test and Measurement (4)
- Vertical Markets (4)
- Wireless (10)
Blog
Thursday, January 8, 2009
Serdes: nice feature or essential element?
Jan 8 2009 8:41AM | Permalink |Comments (13) |
Seven or eight years ago, when Gigabit Ethernet ports were becoming commonplace and the first 10-Gbit Ethernet test structures were being prototyped, transceiver manufacturers started playing a game of macho head-count for on-chip Serdes (serializer-deserializers). If dual-port Serdes were useful, the thinking went, quad Serdes were great, and octal Serdes would a necessary adjunct for multiport switches and routers. Before long, FPGA manufacturers started playing the game as well.
If we listen to the proponents of downloadable movies in the digital home, the inclusion of 1- and even 10-Gbit Serdes as a standard FPGA feature is a no-brainer. Sure, the slowdown in telecommunication equipment markets may mean that routers and switches are taking a smaller percentage of overall FPGA units sold than ten years ago, but won’t the living room and the factory floor and the car and the battlefield need gigabit communications as a given? Isn’t the Serdes as much a modern necessity as a core processor of some kind?
In the long term, the answer may be affirmative, but the recession has taught us that from now on, “long term” may really mean ten years or more. FPGAs in some handheld appliances may only require a Bluetooth and Wi-Fi connection for some time to come, making a Serdes an unneeded luxury. Ditto for a car using a MOST network or a factory using 10/100-Mbit Ethernet. This shows the value of offering optional cores, and of differentiating FPGA products into different families. One obvious way to handle the Serdes issue is to make standard availability a differentiator between high-performance and lower-cost product lines, as Xilinx does for its Virtex and Spartan product lines. One could also focus on driving down costs of a 10-Gbit Serdes implementation, as Lattice Semiconductor has done.
The point is that one size will not fit all in Serdes options, perhaps for some years to come. What Ethernet transceiver manufacturers assumed would be a common feature in every technology platform by 2010 may not be quite so ubiquitous, at least for now.
Related entries in: Broadband | Communication functions | FPGA Gurus | Multimedia |
Reader Comments
at 1/8/2009 2:50:58 PM, Desert Rat said:
Loring:
Welcome back to the fight!
Serdes are OK for servers and telecom junk. Serdes technologies are too unstable for serious critical applications. Most of the implementors of high-speed serdes do not know what a balanced transmission line is. It''s OK for the telecoms to drop half their data, servers to go down, and for consumers to have nothing but problems with their faddish devices, bought on overextended credit so they can be cool. A few apps in MIL use some serdes-based connections (sensor networks), but those are Gen-1 cores that have been hammered so thin, no bugs could survive. Look at the PCIe roadmap: gen-1 is 2.5 gig using 8b/10b. Gen-2 goes to 5 gig and keeps the 8b-10b signaling. Both are in the market now. But, Gen-3 PCIe goes to 8 gig and PAM....no backward compatibility with previous generations. "They" say that they get better data throughput with PAM at 8 gig than 10 gig using 8b/10b (that''s logical since 20 percent of the bits in 8b/10b are trashed). As telecom, industrial, server, PC, and consumer product markets crash and burn in these economic conditions, there is no justifiable business opportunity to push them there. The MIL guys will buy some, if they are gleaned of all commodity quality and reliability problems. Trendy consumers couldn''t care less about having a serdes...they are already cutting their faddish telco services to the bone and living with older cellphones and laptops. There is just no real motivation to spend big bucks on a serdes-enabled consumer toy, and spend another big pile of bucks for the service, so you can watch reruns of "Leave it to Beaver in Spanish....in black and white.
Welcome back....Ray
at 1/8/2009 3:00:16 PM, Loring said:
But remember what we've learned in the single-ended vs. differential fights, as in so many other areas - sometimes an inferior technology wins by default and volume shipped. Serdes implementations certainly dominate a 1G, though I think all your points are relevant.
at 1/8/2009 3:46:46 PM, desert Rat said:
Well, a differential serdes is just a logical extension of an LS244 single-ended line driver, only more problematic. Serdes will be prevalent in very small PCB domains, since those freqs don't go far on a cable without getting hammered. The backplane guys are all pulling their hair out these days trying to get multiple boards from multiple vendors to work together at multi-gig freqs across a couple of feet. A serdes does one thing that is appealing, eclipsing single-ended buses: they reduce the pin count on ICs and connectors dramatically. However, the resulting architectures have a lot of aberrant behaviors, severe limitations, and boogers on them...not to mention severe cooling problems. There's no free lunch. If you move a lot of data around, whether with a bus or a serdes, you're gonna dissipate a lot of heat and suck-up a lot of power. A serdes is data-efficient all right, and it will become prevalent when it can be power-consumption and heat-dissipation efficient too. There's a lot of back-end memory or FIFO circuitry associated with a serdes that you have to consider, all big power users and heat dissipators...compared to some single-ended busses. Look inside an FPGA. What do you see?.... A core interconnect bus, a parallel bus, that hooks all the cores together (Wishbone is an example). So, while the FPGA guys promote serdes as the next-gen external interconnect, all their internal cores use a core-interconnect parallel bus. You want to explain that to those reading this blog?
at 1/8/2009 7:07:28 PM, Loring said:
Parallel interface to the outside world? Isn't that heresy?
at 1/9/2009 7:45:22 AM, Policebox said:
For those readers who don't get the tradeoffs and sarcasm in this post. Parallel interfaces are always faster and simpler (electronically) than serial. A nine wire interface will carry up to eight times the data of a two wire in the same time without conversion hardware. However, they always require bulkier and more expensive interconnects. If the serial link is not the limitation on throughput, it is almost always cheaper for a link that goes more than a few inches. Therein lies the rub. The SERDES people are trying to push into territory where they aren't needed yet.
at 1/9/2009 10:05:00 AM, Loring said:
Thanks, Policebox, there's nothing more annoying than two sarcastic wiseguys sharing inside jokes. The parallel vs. serial disputes will never have final resolution. We ought to have a series of bumper stickers: "I have a masochistic sense of humor, I use Serdes!" or "I insist on being old-school and right, I use parallel optics!" etc.
at 1/9/2009 2:58:54 PM, Desert Rat said:
Yea, Loring. How come AMD is using a parallel interface on their Hypertransport goodies? Is that heretical? It's a nice interface, fast as greased lightning, and we even did a spec for an HPT mezzanine card around here (that's definitely an external parallel interconnect). There are huge complexities, especially weird architectural implications, when you use serial interconnects, as Policebox says. Optical? That's another can of monkeys. Photons are electrons on steroids, and they behave even squirrellier than serial electron-based interconnects. We've been three years away from going to optical interconnects for the past 20 years. Some apps are good for parallel buses. Some are good for serial serdes interfaces, Some are good for optical. A serdes (or a bus) is NOT a universal interconnect, but they get used that way (inappropriately in many cases). The FPGA guys use core interconnect parallel buses because they are (1) simple, (2) ultimately cheaper, and (3) faster than serdes-based serial connections. Serdes packets are fast during transmission, but all the set-up and packet-handling that gets done before and after transmission make them slow as molasses on a cold Colorado day....compared to parallel connections. That's why VME is the mainstay interconnect used in most critical military applications (VME is hard realtime and there ain't a single serdes architecture out there that comes close to realtime determinism). I can write a paper on that topic (and did), about the latencies, about the weird architectural aberrant behaviors (loose sequential consistency, hot spots, required time-out stamping on Read Requests, no guaranteed delivery of any packet on a serdes architecture, etc, etc). So, serdes are OK where you can live with using only a couple of them (like I/O in a commodity PC), where you can live with the high latencies, and where you need a deterministic response in a minute or two (typical PC response times). Also parallel-bus software is a breeze. Serdes architecture software is a nightmare.
at 1/19/2009 9:43:33 PM, pedro said:
We have had a really good experience going from PCI to PCIe lately. In a Xilinx Virtex5 FPGA parallel PCI is really challenging at 66MHz. A lot of fiddling with directed routing constraints and so forth.
PCIe is very forgiving and gives a lot more freedom on how you lay out the board.
Pete
at 1/21/2009 8:59:03 AM, Loring Wirbel said:
I think that all the PICMG work on PCI Express and Advanced Switching was very worthwhile - it's too bad AS did not have the market acceptance PCIe did.
at 1/26/2009 5:05:02 PM, BERT said:
My answer is ''essential element''.
post:The FPGA guys use core interconnect parallel buses because they are (1) simple, (2) ultimately cheaper, and (3) faster than serdes-based serial connections.
Me:At the PCB level we have restrictions on routing area and pin limitations - inside the FPGA/ASIC we do not have the same limitations. The costs for connecting parallel busses inside the asic/fpga is small. But at the package/board level this is not true.
post: That''s why VME is the mainstay interconnect used in most critical military applications
me: VME has a twenty year head start on SERDES, so that isn''t ''the reason'' there is more VME in mil applications at the moment.
I predict more use of SERDES. It''s being used for IC to IC interconnect to minimize the routing and costs of moving volumes of data. I don''t agree that parallel is always faster than serial or preferred. SERDES can be faster and more cost effective than a parallel interface in backplanes. We have moved from EIDE to SATA and we have moved from PCI to PCIe, we''re getting more bandwidth from these SERDES architectures with less pins and less cost.
No doubt there is some challenges in getting it right especially with FPGAs. You need low noise DC/DC converters, low crosstalk PCB designs, low jitter clocks as a starter. Fortunately, SERDES is easy to test for these problems. BERT (Bit Error Rate Test) IP for FPGAs and JTAG software to execute it make SERDES on FPGAs more plug-n-play, easier to bring-up in the lab, test in manufacturing or test in the field than parallel connections.
at 1/27/2009 7:27:19 AM, Well grounded said:
We can comment on serial vs parallel interconnect forever. The day to day reality is what counts.
If you are defining a standard or an architecture. you have to ask yourself whether you want to go parallel or serial. If you are developing a product to fit into an already defined architecture then you have to follow. For example, the PC architecture has moved from PCI to PCIe and if FPGAs still want to be used, they have to have a way to interface with the system. An external serdes proved to be a viable solution for a x1 interface but wider implementations require integrated serdes. The bottom line is that we don't always have the choice. Adapt or die.
at 1/27/2009 9:20:34 AM, Loring said:
Well grounded, I have used that phrase far more often lately than in the parallel to serial debate. There are many laid-off friends in the manufacturing, media, etc. world who long for an ideal world that met their former expectations. Reminds me of those who want parallel interfaces everywhere. We can complain of a world that fails to meet our expectations, or live with the constraints we encounter in the world that actually exists, and adapt. "Adapt or die" can be the slogan of 2009.
at 7/13/2009 10:46:06 AM, Merane said:
Good post
Post a comment
ADVERTISEMENT
About Us | Contact Us | Free Email Newsletters | Free Magazine Subscription | Advertising | 
RSS
©1997-2010 Reed Business Information, a division of Reed Elsevier Inc. All rights reserved.
Use of this Web site is subject to its Terms of Use | Privacy Policy