See also:
– Part 1 (Architecture)
– Part 3 (Student Project #1 – FIR Filter)
– Part 4 (Student Project #2 – ZigBee Receiver)
– Part 5 (Student Project #3 – Image Processor)
As we discussed in Part 1 (Architecture) of this mini-series, Elemental Computing Arrays (ECAs) are a departure from classic hardware architectures. Thus, not surprisingly, they require a design methodology (programming model) that accommodates – and takes full advantage of – their unique capability.
Before we leap into action with gusto and abandon to describe the ECA design methodology, a review of some standard methodologies is appropriate...
But wait ... before we plunge headfirst into the fray, I should note that – following Part 1 – several readers emailed me to ask how Element ECAs differ from the Adaptive Computing Machine (ACM) architecture that was being promoted by the guys and gals at (now defunct) Quicksilver Technology a few years ago. Well, the two technologies are as different as apples and oranges, chalk and cheese, or girls and boys ... more details are to be found in a "sidebar" (more of an "endbar" really) at the end of this article. But we digress...
ASIC and FPGA design flows
Generally speaking, ASIC and FPGA digital designs are similar in the front-end; that is, the design entry and verification cycle. The reason we emphasize the word "cycle" here is because the process is iterative and performed many times in the course of a design as new design information is added or bugs detected during verification are fixed.
This design style is also very chip-specific. Little or no system design data is introduced. ESL-based approaches notwithstanding, in the majority of cases the design starts with the creation of an RTL functional description, typically written in VHDL or Verilog. This HDL code is simulated in an RTL simulator to insure that the specified functionality is achieved. After iterating the design and arriving at a functional simulation that meets the requirements for the target device, logic synthesis is performed to produce a gate-level netlist containing all the low-level logic gates and interconnections that comprise the target chip's functionality. This netlist is also simulated to formally insure that it is functionally correct and meets timing requirements.
The back-end process is different for ASICs and FPGAs. The ASIC back-end process consists of operations on the netlist produced in the front-end. Typically, the netlist is first further reduced to devices modeled by the particular fabrication process on which the target chip is to be manufactured. Various logic and device optimizations are performed to reduce critical paths and increase signal integrity. The layout step is then performed to physically place devices on the chip. Finally, the devices are interconnected using the available metal layers of the chosen process. Throughout the process, timing and critical path data is extracted for actual device performance analysis. Simulations are performed to insure functional and timing integrity is maintained.
By comparison, FPGAs go directly to place-and-route after a netlist is generated (Fig 1). The FPGA vendor usually supplies the place-and-route tools as this is a device-dependent operation. During place-and-route, the highly iterative business of critical path optimization and timing closure is performed. When the functionality and timing are acceptable, a binary file is generated containing all the function binding to physical resources and the interconnect information consisting of exact switch states that define the correct internal paths for signals.
1. Typical FPGA development model.
Both ASICs and FPGAs are examples of Design Time Binding, whereby all functions are physically mapped and interconnected at the time the design is finalized. ASIC binding is obviously permanent. FPGA bindings can be changed by generating multiple binary files and using an appropriate file during power up to configure the device. Some work has been done using tools like J-Bits to reconfigure only parts of an FPGA, however most designs are as static as the ASIC design. FPGAs have the advantage of using a physical platform to perform debugging. Exact performance can be obtained this way before committing a system to production. By comparison, ASICs follow the time honored tradition of sleepless nights and gastrointestinal upset until such time as the fab run is returned from the foundry for testing.
Processor-based design flows
Another tried-and-true way of getting a system to do the right thing is to use a processor-based architecture. Processors themselves are a fixed collection of hardware resources and firmware. Designing a processor-based system is a matter of using appropriate vendor-supplied or open source tools themselves designed to utilize the processor's fixed architecture and instruction set to program functionality.
A real advantage for processors is the capability for the designer (programmer) to use abstracted languages (like C, C++) to define functionality. This means that there is no more need to define things at the register level to get good results. Assemblers can be used exclusively or in conjunction with a compiler to optimize internal operations (Fig 2).
2. Typical processor development model.
The trick to processor design is the need to tailor the code to particular system-level details to maximize performance. As processors spend most of their cycles fetching or writing instructions and data rather than actually executing the program, it is possible to increase performance in processor-based systems with judicious use of processor and system architecture knowledge. This is typically achieved using an associated Interactive Development Environment (IDE), which shows how the system performs as it runs.
Good processor designs are highly dependent on memory system architecture performance and I/O type and usage. These details force the coding style used to program the processor. Large cache, small cache, no cache? Serial or parallel interface. Asymmetrical read/write? Segmented multi-port memory?
Among many other considerations are the peripherals and their associated drivers, which cause much code tweaking during the course of designing a processor-based system. The result is that code written and executing just dandy in one system may need to be ported (re-written or at least tweaked) to run well in a different system, even though it is written is a standardized language like ANSI-C. Multi-processor based systems add the significant burden of partitioning and prioritizing tasks for individual processors. This is complicated by the need to arbitrate memory and bus contention during operation.
|
