It's fun to ask people why they chose this path. Some answers get quite involved. With me it was and is simple: I like to make stuff. As a kid it was all about banging nails into boards. Then it was forts in the back yard, which became such an obsession my grandfather regularly hauled salvaged boards over for me. Around 8 years old, oh happy day, my dad gave me his old electric drill. What havoc I wreaked with that aluminum-cased Craftsman!
We moved to Maryland two years later and I claimed a small corner of the basement for a "lab." Pretty soon people were asking me to repair their TVs, an easy task then when most of the problems were bad tubes. The drug store tube tester was just a short bike ride away. Ironically, after a lifetime in electronics I doubt I could repair a modern TV given the mass of high-integration chips.
The TVs were a treasure trove for parts and pretty soon my friends and I were building vacuum tube amplifiers and Morse code ham radio gear. My best-ever contact on the radio was when the FCC picked up my second harmonic clear across the country. Their stern notice led to some modifications to the transmitter, but I was so proud of a 3000 mile contact I pinned the official letter on the wall next to the other QSL cards (postcards hams mailed to each other to confirm a contact).
We built rockets. Rebuilt engines, cars, eventually boats. Various projects led to the use of transistors and ICs; by late high school there was no doubt that my major would be electrical engineering, a term that still sounds odd to me. Shouldn't it be "electronic engineering?"
Why EE? Simply because it was so much fun to build stuff, and the EEs I knew used a soldering iron as much as a drafting table (uh, for the younger readers, we used "pencils" and "vellum" before the CAD era). Designing circuits was an intellectual challenge, and working with my hands on the prototypes satisfied my need to build stuff.
The book's thesis is apparently that working with one's hands connects us in important ways to the world around us. I hear he dismisses cube dwellers for their disdain of the trades.
But we engineers, prime examples of white collar office workers, make stuff. It could be an iPod or a well-crafted ISR. Maybe specialists assemble the circuits due to the high-density SMT. But turning an idea into a device, picking up the scope probe or loading the debugger to make it work, and then seeing a product emerge, is a hugely satisfying endeavor.
February 17, 2010
Eeeeek! My FPGA's not working: Problems with the *IP*
By
Clive
Maxfield
In my previous post (see my blog #222600858) I waffled on about the challenge of RTL mismatches in an FPGA methodology. This week we'll look at how using third-party IP can also introduce some nasty little issues...
Maybe you're an ASIC designer forced by short product lifecycles to move into FPGAs. Or perhaps you're a team leader whose latest project requires chip-level integration, and an FPGA implementation seems to be the obvious choice. Or possibly you're actually used small- and medium-sized FPGAs in the past, but your new project requires you to push the envelope with the newest, highest-performing, highest-capacity FPGA architectures.
The problem is that you've been led to believe that getting a design to work on an FPGA is relatively simple. How hard could it be? All you have to do is capture the design, simulate it, synthesize it, load the resulting configuration file into the FPGA, test the result, modify the design, and repeat...
In reality, however, designing with high-end FPGAs is harder than you think! One problem is that we all tend to have high levels of faith in various aspects of the FPGA design flow, but it's not long before we discover how unfounded this faith can be. In reality, bugs can manifest themselves in any portion of the flow. As an example, let's consider any third-party intellectual property (IP) blocks you may decide to incorporate in your design as illustrated in Figure 1.
 |
| Figure 1. Bugs can manifest themselves in any portion of the design flow; for example, the IP. |
What about that Fast Fourier Transform (FFT) core you purchased to speed up your design cycle? It seemed like such a good idea at the time you were selecting it, but integrating it into the rest of the design is another matter.
In the case of ASIC designs, any third-party IP cores are typically presented in the form of RTL (encrypted, obfuscated, or unencrypted). Thus, the same RTL representations of the IP blocks that are used during initial software simulation are subsequently synthesized, placed, and routed along with the rest of the design. This provides a high level of confidence that the RTL and gate-level representations of the design are functionally equivalent.
The situation is very different in the FPGA domain because the third-party IP models used for software simulation may be different to the corresponding models used by the FPGA's place-and-route software. That is, the IP vendor often supplies two different models " one at a high-level of abstraction and one at the gate-level.
The problem is that these two models are typically not directly related. Often, the high-level simulation model contains behavioral (non-synthesizable) constructs. These constructs make the software simulations run faster, but they prevent the models from being synthesized. Even worse, there are often subtle differences between the behavioral and gate-level representations, and these differences only manifest themselves when the FPGA design is deployed in its target system.
So here's where you find yourself... you received the promised high-level and gate-level models from the vendor. The high-level FFT model drops into your design and the software simulation looks good. You synthesize the design (including the gate-level version of the FFT) to your FPGA target, perform place-and-route, load the resulting configuration file into the FPGA and ... something's gone wrong. The long-chain test patterns that gave the correct transform in the software simulation fail in the physical FPGA implementation.
You re-check your high-level code and simulation results. Both appear to be correct. So you modify your design to add some debugging logic around the IP block, re-synthesize, re-place-and-route and re-load the FPGA. Your design still not working and you can't see why. Maybe you suspect a problem with your gate-level IP model, but simulating at the gate-level is a major chore. You don't have much time and don't even know if your long-chain test patterns will complete. You can't debug what you can't see. You're left guessing at the problem and running in crisis mode. Do you take the plunge into gate-level simulation to desperately try to locate the bug, or do you keep looping through the modify-synthesize-place-route-load process to try to identify the problem?
What you can't see is that the gate-level IP netlist used by place-and-route is subtly different to the high-level you've been simulating. Your software simulation doesn't match your netlist and your FPGA implementation is using constructs that don't abstract back into your RTL. But you don't know what is happening and you can't identify the problem because every step in the process appears to produce the results you expect ... until you reach the programmed FPGA. Simulation was fine. Synthesis and routing complete with no warnings or errors. The netlist loads without issues. But the FPGA doesn't work in the system and designing with FPGAs has suddenly become a lot harder than you expected.
An IP Example
Now you may be thinking to yourself: "How often does this sort of thing really happen?" Trust me; it happens more often than you might think. Consider the following real-world example from an FPGA vendor's user forum site (names have been changed to protect the innocent):
As we see, running the simulation on the gate-level netlist provided by the IP vendor showed different results to the behavioral model supplied by the same vendor. Ironically, this was a case where the gate-level representation was correct and the behavioral model ... wasn't (in many cases it's the other way around). Unfortunately, as we see, although the user managed to fix the underlying problem, he or she was still left having to run painfully slow gate-level software simulations.
The Solution is the RocketDrive
The GateRocket RocketDrive was uniquely developed to solve debugging problems with the traditional FPGA design process. The RocketDrive bridges the gap between the RTL/abstract-level software simulation domain and the physical FPGA.
Consider, for example, a design comprising say 100 functional blocks. Some of these blocks will be your own internally-developed, proven IP from previous projects; some will be IP from third party vendors; and some will be your newly-created "secret sauce" that will differentiate your design from all others.
Using the RocketDrive and its associated software, you can immediately move the gate-level representations of any "known good" blocks (your existing internally-developed IP and trusted third-party IP cores, for example) into the same type of FPGA you are targeting for your real-world design. Next, you can verify these blocks in conjunction with the rest of the design running in your software simulator of choice. Right-from the start, you are dramatically speeding your verification runs.
As each new block is verified at the RTL (or behavioral) level in the context of your full-chip design, its synthesized/gate-level equivalent can be moved over into the physical FPGA in the RocketDrive. As soon as a problem manifests itself, the verification run can be repeated with the RTL version of the suspect block resident in the simulation world running in parallel with the gate-level version realized in the physical FPGA. By means of a special software application, the signals from the peripheries of these blocks (along with any designated signals internal to the blocks) can be compared "on-the-fly."
Using this technology—combining conventional simulation with physical hardware and an appropriate debugging environment—it is possible to very quickly detect, isolate, identify, and resolve bugs, irrespective of where they originated in the FPGA design flow.
Questions? Comments? Feel free to email me " Clive "Max" Maxfield " at max@techbites.com.
Comment on this blog entry
February 08, 2010
Hardware Testing
By
Jack
Ganssle
Does your hardware work?
One of the most fascinating aspects of embedded development is that we're working in two very distinct camps: the firmware and the hardware, which, until the invention of the embedded systems, were two non-intersecting Venn circles.
One of the most frustrating aspects of embedded development is that we're working in those two very distinct camps. The hardware guys build a board, "verify" it, and toss it over the wall into the firmware group with a Good Hardware Seal of Approval stamped on the thing. Then the software group tries to test their code only to find a series of problems with the PCB.
To double the Embedded Excedrin headache, the problems manifest themselves as software issues. Troubleshooting becomes a nightmare because people are looking in all of the wrong places. Or maybe the board is intermittent, working at times but failing only when specific and hard-to-reproduce events occur.
In the best of cases, how do you even know if your hardware works? Crank out some diagnostics and, sure, with enough time one can insure that everything functions correctly. Yet some kinds of failures " say, with complex SDRAM logic " require quite complex test code, as failures occur in perverse ways, ways that few of us non-test engineers really understand.
I visited a Colorado company last month which aims to break this bottleneck. Kozio offers a variety of products that perform excruciatingly-detailed tests on custom hardware.
Their kDiagnsotics is a program they customize (often in just a few days) to your hardware design. That's possible and cost-effective since the company has a huge library of canned tests they've written for many types of peripherals. Given a board with not much more than a running CPU and a bit of memory, kDiagnostics can exercise the rest of the board and pinpoint design or production errors.
With the use of scripts the hardware engineer can loop through tests, or even subsets of tests, to create known and repeating stimuli to guide scopes and logic analyzers through the troubleshooting process. Said loops can run for an extended period of time to look for glitches, perhaps while cycling the board in an environmental chamber or around ESD discharges.
The upside: the hardware people deliver a known good board to the firmware engineers. The latter can use the tests to prove that a problem really is in the code, not on the board (all hope is not lost; we can still blame the compiler).
Other offerings include a royalty-free POST that can be embedded into your product, a utility that dumps peripheral register contents so you can get insight into how to set these up, and more.
But with hardware getting more complex I think validating it as thoroughly as we test the code is a good idea. Check them out at www.kozio.com.
Editor's Note: Jack' Embedded Poll Question this week is "What do you think about hardware testing?" To vote, go to the Embedded.com Home Page.
Jack G. Ganssle is a lecturer and consultant on embedded development issues. He conducts seminars on embedded systems and helps companies with their embedded challenges. Contact him at jack@ganssle.com. His website is www.ganssle.com.
Comment on this blog entry
February 02, 2010
Arrgghh! My FPGA's not working: Problems with the *RTL*
By
Clive
Maxfield
Maybe you're an ASIC designer forced by short product lifecycles to move into FPGAs. Or perhaps you're a team leader whose latest project requires chip-level integration, and an FPGA implementation seems to be the obvious choice. Or possibly you're actually used small- and medium-sized FPGAs in the past, but your new project requires you to push the envelope with the newest, highest-performing, highest-capacity FPGA architectures.
The problem is that you've been led to believe that getting a design to work on an FPGA is relatively simple. How hard could it be? All you have to do is capture the design, simulate it, synthesize it, load the resulting configuration file into the FPGA, test the result, modify the design, and repeat...
Simulate > Synthesize > Load > Test > Modify, Simulate > Synthesize > Load > Test > Modify, Simulate > Synthesize > Load > Test > Modify... It sounds easy enough, doesn't it? In reality, however, although Apply > Lather > Rinse > Repeat may work in the case of shampooing your hair, that reality is that designing with high-end FPGAs is harder than you think!
One problem is that we all tend to have high levels of faith in various aspects of the FPGA design flow, but it's not long before we discover how unfounded this faith can be. In reality, bugs can manifest themselves in any portion of the FPGA design flow. As a simple example, let's consider the RTL as illustrated in Figure 1.
Figure 1. Bugs can manifest themselves in any portion of the design flow; for example, the RTL (click on image to enlarge). |
Once you've captured your RTL, you loop around performing functional simulations, checking the results, and tweaking anything that concerns you until you are happy with the way things look. Eventually you synthesize the design to your FPGA target, load the configuration file into the FPGA and run. But what's this? Something's gone wrong!
You re-check your RTL and your simulation results. Both appear to be correct. You add some debugging logic around what you think may be the problem. You re-run synthesis—and associated tools like place-and-route)—all of which may take hours or days. Things still are not working in the FPGA as expected, you can't see why, and you can't debug what you can't see. You're left guessing at the problem and running in crisis mode. All you can do is to keep on cycling through that "long loop": tweaking the RTL, simulating, running the synthesis and place-and-route, loading the FPGA, and hoping that if you "shake" things hard enough something useful will "fall out."
Why is this happening? What is going wrong? What you don't see is that your simulation runs are ignoring the pragmas intended for use by the synthesis engine " the directives that provide the synthesis tools with the flexibility to fit your design into the silicon. The end result is that your RTL simulation doesn't match your netlist and your FPGA implementation is overwriting registers that you didn't care about in
your RTL.
But you don't know what is happening and you can't identify the problem because every step in the process appears to produce the results you expect ... until you reach the programmed FPGA. Simulation was fine. Synthesis and routing complete with no warnings or errors. The netlist loads without issues. But the FPGA doesn't work in the system and designing with FPGAs has suddenly become a lot harder than you expected.
An RTL Example
Now you may be thinking to yourself: "How often does this sort of thing really happen?" Trust me, it happens more often than you might think. Consider the following example from opencores.org:
In this case, the engineer's well-intentioned desire was to produce a better quality gate-level implementation netlist. Unfortunately, this code is guaranteed to behave differently in synthesis versus simulation, because the synthesis pragmas will be ignored by the simulator.
The problem is that the pragma told the synthesis tool that it could make arbitrary decisions about unspecified choices. This is contrary to what happens in the simulator. The end result is that a register was overwritten when an unspecified address was written to inadvertently.
Of course there are a wide variety of linting tools available, but generally speaking the majority of FPGA designers don't have access to them and—even if they do—they don't use them. This is very different to the ASIC world, because ASIC designers have these tools and always use them. But design engineers in a traditional "FPGA shop" don't tend to have ASIC tools lying around; managers don't want to spend money buying them; the designers don't want to spend time learning to use them; and oftentimes the end result is ... not very pretty.
The Solution is the RocketDrive
The GateRocket RocketDrive was uniquely developed to solve debugging problems with the traditional FPGA design process. The RocketDrive bridges the gap between the RTL and the FPGA.
Consider, for example, a design comprising say 100 functional blocks. Some of these blocks will be your own internally-developed, proven IP from previous projects; some will be IP from third party vendors; and some will be your newly-created "secret sauce" that will differentiate your design from all others.
Using the RocketDrive and its associated software, you can immediately move the gate-level representations of any "known good" blocks (your existing internally-developed IP and trusted third-party IP cores, for example) into the same type of FPGA you are targeting for your real-world design. Next, you can verify these blocks in conjunction with the rest of the design running in your software simulator of choice. Right-from the start, you are dramatically speeding your verification runs.
As each new block is verified at the RTL (or behavioral) level in the context of your full-chip design, its synthesized/gate-level equivalent can be moved over into the physical FPGA in the RocketDrive. As soon as a problem manifests itself, the verification run can be repeated with the RTL version of the suspect block resident in the simulation world running in parallel with the gate-level version realized in the physical FPGA. By means of a special software application, the signals from the peripheries of these blocks (along with any designated signals internal to the blocks) can be compared "on-the-fly."
Using this technology—combining conventional simulation with physical hardware and an appropriate debugging environment—it is possible to very quickly detect, isolate, identify, and resolve bugs, irrespective of where they originated in the FPGA design flow.
Comment on this blog entry
Read Previous Programmable Logic DesignLine Blog Entries
