BY Dave Rupe

We all know him, the unshaven guy with the thick glasses and wrinkled utensil-filled shirt. He lives and breathes every DC gadget, follows Slashdot like a religion, and loves to reinvent the wheel 100 different ways, just for the fun of it. If allowed, he will make it his life's goal to eek another picosecond out of his FPGA state machine just to see what happens if he runs the design at twice the required clock rate. He might even write a new UART because the one he wrote last week worked well enough, but it wasn't as elegant as it could be.

Brief eye contact with Joe Tech reveals disappointment when you congratulate him on a job well done, but break the news to him that the project he was working on has to end. Without being too perceptive, you catch him shift to excitement as he envisions the architecture of the next-generation FPGA product when you tell him the requirements doc will be on his desk tomorrow morning. His UART won't connect up to the new infrastructure, so he'll get to rewrite it after all!

If only you could convince Joe Tech that he won't lose his job, or his fun, if he'd agree to use an existing COTS framework that would allow him to simply reconfigure how his components are connected when building the next FPGA project. Then you could get him to be more efficient and finish projects and features, rather than just playing with an ever-changing laundry list of components, sub-components, and variants.

It's been a tough sell, but fortunately Joe Tech might have accidently glimpsed the "big picture" that afternoon. A buddy of his on IRC has a sister whose boyfriend, while in camo sitting shotgun in a Hummer, had to tune his radio to a higher bandwidth channel so he could get a pinpoint visual on the source of some mortar shell blasts.

Apparently, the heat had messed with something Joe Tech calls "signal integrity" and the SerDes data link was unstable under the extreme conditions. Fortunately, despite the pressure, G.I. Joe remembered his training and knew that he could input some new settings to reconfigure the radio for the current environment (a.k.a. Dynamic Reconfiguration).

Just in time, the hostile's position lit up on his display. Within seconds, G.I. Joe had eliminated the threat and earned himself a medal for the trip home. After word of the successful mission and the enabling radio widget traveled the tech blogs back to the Build Cool Stuff Corp. engineering department, Joe Tech was now much more open to your chiding that leveraging an existing framework really isn't a sign of weakness, as he decides to give it a try tomorrow on the new project. In fact, Joe is almost excited that it might enable him to build tomorrow's bigger, better system quicker and still have time to add in features even he couldn't fathom if he were writing his seventh, more-elegant variant of the UART.

A few months later, Joe Tech is so psyched about his productivity using the COTS framework you pushed him to use that he sends you an e-mail (reproduced on page 28) containing all the nitty-gritty details of tomorrow's project-as if you had a chance of understanding half of the nit or the grit. In fact, being Joe Boss, all you care about is the answer to one question: What kind of ROI (return on investment) does this framework path provide?

No way you are going to let Joe Tech burn company dollars when you could get a jump start on the next project! What about field maintenance? What if G.I. Joe requires a costly FPGA redesign updated with a new signal processing channel supporting more dynamic range or a slower but more robust SerDes link?

At this point, you probably need to remind yourself that the reason you encouraged him to go with that COTS FPGA framework methodology was because it enables reuse and portability leading to more efficient development and less costly maintenance... so you throw Joe Tech a bone, and let him have a few days to play with project features and enhancements, rather than that stupid laundry list and UART.

---

DAVE RUPE is the field-programmable gate array (FPGA) product manager at BittWare Inc., a specialist in embedded signal processing, located in Concord, N.H.

---

Joe Boss,

This framework stuff isn't so bad. In fact, I got the project up and running so quickly that I was able to add tomorrow's feature today, and it is not dev/null!

At this point, you pretty much have your answer to the ROI question, but because Joe Tech seemed to have put a lot of effort into explaining the details of this stuff, a twinge of guilt prevents you from filing this one in the recycle bin without at least skimming the rest of its contents.

The e-mail continues:

Check this out... It is Wednesday and I have been able to leverage each form of reconfiguration, THIS WEEK!

Monday (Project Reconfiguration):

It turns out the switch we we're using had way too many ports. As a result, the bandwidth allocated to each port was restricting the DDR3 throughput and blowing our latency budget. Quick fix: The switch component like all the others in this COTS package use a common interface. The framework's common interface makes it so that all components with the same interface type, memory mapped for addressable transactions, like control and status, and streaming for high-speed, point-to-point transfers, are all interchangeable.

In the past, I built adapters and interface translators each time I connected different components together. It's not my fault that Joan Tech does hers differently. Anyway, I realized that ports 6-8 don't need to be on the same switch as 0-5 because its "goesintos" and "goesouttos" don't ever goesintos and goesouttos the others.

Well, the common interfaces allowed me to pull out the extra ports and direct connect the SerDes physical interface to the DMA controller. Of course, at this point in the past, I would have to write a new switch, this time with fewer ports, because I would never waste resources with extra logic for unused switch ports. But, the switch component has an arrayed common interface that is as large or small as the number of ports connected to it.

How cool is that? On top of that, the DMA controller was expecting 64-bit streaming data input, while the SerDes receiver was pumping out 128 bits. I just changed the data width parameter on the SerDes receiver to 64 and bada bing, bada boom, they play nice!

Tuesday (Static Reconfiguration):

We got the new Stratix IV COTS hardware in. Since the COTS board used in phase one of the project had a Stratix II device, I was looking forward to writing my own SerDes transceiver to help port the FPGA design to the new board. It was awful; there was a blaringly obvious parameter named "BOARD_INFO" that I could not in good conscience ignore.

All I had to do was change the "FAMILY" field from "SIIGX" to "SIV" and call the supplied synthesis scripts indicating the new board, and my work was done. Again, a glimmer of hope. It turned out that the SFP interface wasn't limited to 2.5 Gb/s like we thought. It can actually support SFP+, and run at 5 Gb/s. The COTS SerDes component has a SERDES_SPEED parameter; by simply changing the value from 2.5 Gb/s to 5 Gb/s, I was able to get that pretty eye back up on the scope before lunch. It would have been really swell to write my own SerDes component but, lucky for me, I was able to stare into those eyes the rest of the day.

Today (Dynamic Reconfiguration):

Turns out that when she got hot in the environmental chamber today, the lady needed a bit of Visine to open up her eyes. It would have taken me a week to implement and test code to adjust the analog controls like VOD, preemphasis, and equalization to clear up the bit error rate issues. I simply popped open the COTS framework's SerDes component manual and spotted a set of reconfiguration registers already implemented.

I was upset I didn't get to write any of the SerDes reconfiguration control, but calculating the SerDes reconfiguration settings using my trusty TI-86 always brightens my day. I updated the host software by adding the settings to my hash and, once again, my calculations were correct the first time and the BER measured within spec.

Tomorrow:

Since I am ahead of schedule, can I spend the next week experimenting with the different Static and Dynamic Reconfiguration settings?

Later,

Joe Tech

More Military & Aerospace Electronics Current Issue Articles
More Military & Aerospace Electronics Archives Issue Articles