TransEDA, for example, hit upon the notion that coverage measurement tools-those things that ride along with your simulation via the PLI and tell you which lines of your HDL source have been exercised-might be measuring the wrong thing. Node coverage tools would be great-and those are available. But, TransEDA suggests, how about a tool that lets you build a set of formal properties to define the intent of a block, and then test the properties and record coverage during simulation?

Formal properties, encoded in a property language like IBM's Sugar or Intel's ForSpec, were conceived to capture design intent so that formal verification tools could analyze a design against the intent. TransEDA's notion, given the limited range of formal provers at the moment, is to use the property description during simulation to see whether any of the vectors tried break any of the property declarations. Tracking to make sure all the properties have been tested seems like a good idea too.

That's the idea behind VN-Property, a tool that instruments an HDL file to link it to properties before simulation, uses the PLI to monitor simulation and then postprocesses the log to extract violations and statistics.

But that leaves unanswered the question of which language to use for the properties. TransEDA's first answer was the politically correct one: whatever the Accellera Formal Verification Technical Subcommittee comes up with. That's OK, but it would make release of VN-Property dependent on the completion of the subcommittee's task-at the moment, a hazy bet.

The alternative would be, perhaps, to pick one of the languages already donated to the committee, such as Sugar or ForSpec. You could also choose to extend an existing language that was created for a different purpose, such as Verilog or "e." Or you could do the traditional EDA thing and make up a language. Any of these choices would narrow your market by excluding folks who don't know the language and by risking offense to supporters of another one.

So TransEDA decided on a finesse. Along with a pledge that VN-Property will eventually support whatever Accellera settles on, the company chose Perl. Yeah, that Perl. Perhaps nobody has thought of Perl as a property language, but it is widely known, can be used for the purpose and isn't likely to make enemies. To get the ball rolling, TransEDA is providing libraries of prewritten properties for PCI, the Amba buses and some other interface specs in the near future. If a commonly understood language is more powerful than an optimized language, as history seems to suggest, it might just work.

Building SoC in FPGA
With the growing list of vendors including a diffused CPU core in an FPGA, there is growing curiosity about just how to use one of these things to build an SoC. At its worst, this could be a very complex question: how to get sufficient documentation on the physical connections between the CPU core and the FPGA interconnect fabric to design a complex, tightly coupled coprocessor, for instance. But most SoC designs fit into the simpler category of CPU plus a few types of memory and peripherals, and for this category the FPGA vendors have been working to make the process nearly pushbutton.

Altera, for example, recently announced SoPC Builder for its ARM-based Excalibur FPGA family. The wizardlike tool lets you pick IP out of an extensive preverified library, assign the blocks to buses and push the "go" button. Pretty simple.

But some interesting questions get hidden beneath the surface of such a pushbutton tool. For instance, how are IP blocks handled, as RTLs that are resynthesized each time, or as hard macros? And exactly what does it mean in an FPGA to hook a block of IP to an Amba bus segment? There are some interesting answers.

One surprise is just how effective the standard mapping and routing tools are. Under normal operation, SoPC Builder just puts together a big Verilog file, including bus connections, and passes it into the Altera tool chain. After synthesis, most designs can be mapped and routed as flat structures and still hit their performance goals, the company said.

For certain performance-critical blocks, a utility called Logic Lock lets the designer lock down the mapping and routing of a block without locking down its location. That means you can do your best optimization of the block and then move it around within the logic cell array (respecting the grain boundaries of the hierarchical interconnect, of course), without changing the performance much. In a pushbutton design environment, Logic Lock becomes important, said Tim Allen, director of Altera's Santa Cruz Technical Center. "We've used Logic Lock to good effect internally. It has made a pretty big difference in performance on SoPC designs."

Those Amba buses pose another interesting question. It's been a long time since buses were implemented as actual tristate bus lines in FPGAs. These days they are done ASIC-fashion-as banks of multiplexers. So Altera designers put a lot of thought into implementing banks of fairly wide muxes efficiently. Muxes, said Allen, "happen to pack very well into our 4-LUTs using the carry input." So buses too have a clean implementation that lies well within the skills of the existing tool chain.

As long as you don't push the envelope too far, SoPC Builder and its close relatives from QuickLogic and Xilinx appear to be a capable approach. When critical speed paths or nasty data flows really need custom attention, then the fun starts.

Leopard shows spots
Speaking of systems on programmable chips, startup Leopard Logic has been silently stalking a few key accounts in the lush jungle of programmable logic. Now the company is about to pounce, and as a result folks without nondisclosure agreements are spying some of the details of a very interesting architecture.

Leopard is an IP provider that licenses embeddable programmable-logic arrays, in various sizes, for incorporation into SoCs produced in a conventional ASIC or COT design flow. They impose no special process requirements and conform to existing tool flows. Integration starts out with Liberty Libraries and is currently tuned for a Synopsys flow. A system designer can drop an array of field-reprogrammable logic into any critical spot in an SoC more or less at will.

This capability is available from several vendors, but there are some unique ideas in the Leopard scheme. "The requirements for an embedded FPGA are quite different from those of a discrete device," said president and CEO Chris Phillips. "To start with, discrete FPGAs are almost inevitably pad-limited, and all connection between the array and the outside world has to go through the pad ring. That is not the case for an embedded array, and that changes everything."

Also, said Phillips, "expectations are different. In a board-level environment, users adjust to the speed of the FPGA." But inside an SoC, "you have to conform to the speed of the surrounding circuitry; you can't be slowed down by pass transistors and long interconnect segments."

Such considerations led to some significant departures in the Leopard design. To begin with, no I/O cell ring surrounds the Leopard arrays as in standard FPGAs. The interconnect simply routes into the surroundings.

Internally, there are other differences. Most obvious is in the construction of the interconnect itself.

In most FPGAs, the interconnect is built as a hierarchy of broken segments-short ones span a few adjacent cells, longer segments span a cluster of cells and, usually, very long segments span some or all of the die. In Leopard's scheme, these segments are terminated in structures somewhat like switch boxes, where the switching elements are high-current pass transistors. Often there are buffers as well in strategic locations. Where the length of the segments is constrained and the process is strictly ASIC-like, the segments are point-to-point wired into multiplexers instead of pass transistor arrays.

That, Phillips said, eliminates substantial delays caused by the pass transistors, as well as the need for a special implant step in processing. The result, Leopard claims, is to increase operating speeds well beyond what would be possible with a conventional FPGA in the same process.

Also, rather than route all traffic between the logic array and the rest of the SoC through fixed I/O cells, each logic cell gets a direct link to the outside of the block. Thus, the bandwidth between the rest of the SoC and the Leopard array is potentially enormous-limited more by the implementation of the functions than by the availability of I/O wires.

The Leopard architecture presumes a particular approach to SoC design, Phillips said. The obvious route toward configurability is to simply plop down a large FPGA structure, but Leopard thought SoC designers should use programmable arrays in smaller instances, placed where they made the most sense for the floor plan in much the same way as memory is used.

That could be a challenge to the systems thinking of some design teams, but it has strong logic to it.

http://www.isdmag.com

Copyright 2002 CMP Media LLC
4/1/02, Issue # 14154, page 8-12.