The flexibility offered by field-programmable gate arrays (FPGAs) has made design iterations an integral part of the FPGA design process. Traditionally, engineers quickly wrote hardware description language (HDL) for their design, ran synthesis and place-and-route on it, programmed the FPGA and tested design functionality directly in hardware. If a performance issue or a functional bug was discovered, appropriate modifications were made to the HDL, followed by re-synthesis and re-place-and-route to obtain a new FPGA bit-stream and re-testing the hardware. This flow was fast enough to easily allow a few iterations in one day.
With the increasing size and complexity of the latest generation of FPGAs and the system designs targeted towards these FPGAs, achieving timing closure has increased the need for iterations even more. However, using the iterative process as before has become extremely challenging now. A key issue is the significant increase in runtime for these designs – both during synthesis, and especially during place-and-route. It is no longer feasible to turn-around more than one run of a FPGA in a day.
I have this recurring nightmare. I’m supposed to write a chapter for a book. I’ve pretty much got it done, doing some final editing on the last paragraph, and then on review realize that the first paragraph has changed mysteriously. So I fix it, but then another paragraph changes. I never seem to be able to get all the paragraphs right. And then someone else submits his chapter, and for some reason my chapter gets all screwed up. Of course, that’s about the time I also realize that I forgot that I had signed up for a college class that, of course, I never attended, and the final is tomorrow, and I wake up in a cold sweat.
While I can sigh my sigh of relief that it was all a bad dream, this can be the real-life nightmare of the FPGA designer trying to achieve timing closure on a tight design. Each tweak on one path screws up another path, all too often in a manner that doesn’t seem to converge. This whack-a-mole problem is but one of a number of challenges that can be addressed by a so-called incremental design flow. The goal of an incremental flow is to be able to lock down the things that are complete and change only the things that need to be changed. While the promise has been around for a while, it appears that much of this is now real – but of course, there are some caveats, not to mention that not all tools do all things.
Look It Up
Webster’s Dictionary defines “Platformification” as – OK, you got us. It’s not in Webster’s. Even Microsoft Word gives us the squiggly red line telling us we’re treading on dangerous ground. Wikipedia – no better. We got diverted to some articles about Mario Brothers and other games where characters jump around from platform to platform – not unlike embedded systems designers choosing and then abandoning various combinations of processors, operating system, and peripherals powering their creations.
Intel tried to stick us with the word “Platformization”, and we briefly considered that, but their definition – the combination of several chips into a standardized platform, is too specific. “Platforming” is apparently a long-recognized method for separating petroleum products during refining, so that one was out as well. We decided on “Platformification,” and a quick Google search validated our decision. Our hope, of course, is that Google will list this article among the authorities on Platformification soon enough, with Webster’s and the other Luddites to follow. So, with apologies to both Intel and the English Language – here we go.
Building a house used to be so easy. You found some flat land. You chopped down some trees. You sawed them up and put them together. Voilà! Honey, I’m home! And if a big storm knocked it down, you built another one, perhaps a bit stronger.
OK, maybe that’s not easy; it actually sounds like a lot of work, but it was conceptually simple. Today just try building a house. You’ve got permit after permit. Are the electricals up to snuff? Did the wallboard get nailed up properly? Where does the runoff from the gutters go? Wanna add a few windows to that windowless wall? OK, does that screw up the shear strength of the wall in case there’s an earthquake? How does the extra glass affect the energy rating of the house? Nobody ever cared about this stuff before; now it’s routine.
This didn’t happen overnight. It was a gradual process of trial and error, and as mistakes were made and needs changed, guidelines were added, and guidelines became rules, and more guidelines were added and they eventually became rules. And all of the rules are presumably there for some good reason (that may or may not be readily apparent). And this made building a house more expensive, so that the economics meant fewer house designs, and more houses from each design - as evidenced by row upon row of identical houses in modern tracts.
New ProASIC3L Family
For a long time, the messages coming out of Actel were diverse – their two flavors of non-volatile programmable logic devices, some flash-based and others antifuse-based, had distinctive characteristics that differentiated them from mainstream SRAM-based FPGAs. They tended to have better resistance to radiation and better design security, they were live at power-up, they were a true single-chip solution because they didn’t require configuration circuitry to support them…
Today, that’s all changed. There is only one marketing word coming out of Actel these days, and it’s Power - less of it. Actel has focused their development efforts, their messaging, and their minds on low-power programmable logic, and the other subtle differences have fallen by the wayside.
Not too long ago, secure software was the sole domain of the military and a few select governmental and financial agencies. Safe software was the sole domain of industries such as aerospace, medicine, and transportation. Software was either safe or secure, but in most cases, there was never a need to have both safe and securesoftware. But the times they are a changing. As digital devices become more ubiquitous and the convergence of multiple applications on a single device continues, safe and secure software now has a place in automotive, aerospace, and in industrial applications to name a few.
Growing complexity and multiple features have expanded to the point where today, keeping electronic data secure is critical to the safe operation of electronic devices.
Software Secure Systems – Then and Now
As with many technologies, the military was one of the first industries to use computers within both its communication infrastructure and mobile equipment. It was a natural evolution for software to move into civilian applications, such as avionics. First used in communication, diagnostics and guidance systems, software control systems have moved into the arena of flight control systems. The European Airbus 380 is a perfect example of an aircraft flown entirely by computer. Can you imagine the massive group collaboration that must have been formed to ensure the safe and secure operation of software in this context?