ginngi engineering

Leveraging Experience to Reduce Risk

FPGAs have quickly overtaken ASICs for many chip designs because of its flexibility and cost-effectiveness. Many companies, who would normally not have the means to consider a chip design, are now able to leverage the significantly lower chip costs in their products. However, the cost of FPGA development has not changed and remains the same as ASIC design. As FPGAs become larger and more and more companies are considering implementing complete System-On-Chip designs (SOC) the risks and costs associated with FPGA design rivals ASIC design. With all of the good intentions these companies have the bottom line is that they often lack the resources and/or the experience to undertake FPGA designs despite the temptations.

Ginngi has amassed a great deal of experience in designing FPGAs and is able to offer customers on-time and on-schedule designs for any FPGA size. By using professionally accepted methodologies and management techniques each project is cleanly broken down into phases. Each phase is a sub-project in its own right with specifications defining expectations, macro-management techniques guaranteeing clean execution, and clearly defined deliverables upon completion. Documentation is of paramount importance in any complex project especially FPGA design. Ginngi provides comprehensive documentation covering every phase of the project including: Customer Requirements, Hardware Specification, Programming Model, and Verification Test Plan.

Project Design Phases

Requirements Analysis

Requirements analysis involves carefully defining the functional expectations of the customer from the proposed design. This can be a difficult phase because in many cases the customer has not thoroughly defined their requirements to the point where a design can be started. Ginngi takes the time to collect all of the existing documents the customer may have, to talk to all relevant customer personnel and only then do we write a first draft of the Requirements Specification. One or more design reviews may take place with as many people as possible involved in the project. Then a final specification is drafted and approved by the customer. The requirements specification is used at the end of the project to demonstrate a working design and to obtain final sign-off on the project.

Architectural Design

The requirements are analyzed and one or more architectures are defined that provide potential design solutions. An Architectural Design Specification is drafted which includes both a detailed set of block diagrams and a written description of each block. One or more design reviews are then held with the customer and at the conclusion the architecture is closed with the sign-off of the specification.

Detailed Design

The architecture is designed block by block. VHDL modules are defined and a detailed system block diagram is drawn reflecting the exact modules to be implemented and their interfaces. A detailed functional timing analysis is performed to determine timing bottlenecks and required scheduling mechanisms. During this phase it may become clear that we may need to add an arbiter to arbitrate a resource (such as a DDR memory). FIFOs may be added to relieve data flow bottlenecks or to decouple between different clock domains. Clock domain analysis is performed and the coupling mechanisms to pass data between the different domains. Debouncing mechanisms are used to ensure data integrity between clock domains and to correctly transform external asynchronous signals to their synchronous equivalent.

Synchronous Design Techniques

Ginngi adheres to strict usage of synchronous design rules for all of its FPGA designs. Each clock domain is carefully isolated and signals that need to pass between domains are processed using debouncing mechanisms or decoupling FIFOs.

Pipeline Design Techniques

Often the amount of asynchronous logic between two flip-flops may be so large that timing constraints cannot be met. To relieve this bottleneck pipelining techniques are used to split the logic in smaller chunks isolate with additional flip-flops. A trade-off exists between the timing constraints and the additional latency introduced by the flip-flops.

DSP Algorithm Implementation

FPGAs often have built in DSP resources (addr-multiplier blocks) that provide effective implementation of complex DSP algorithms on an FPGA. Ginngi has extensive experience in implementing digital signal processing (DSP) in FPGAs. The steps used to implement a DSP algorithm in an FPGA includes the following steps:

Modeling

This phase is usually performed by the DSP engineer using high level tools such as Matlab, Simulink, or C/C++.

C-Bit Accurate Model

Depending on the algorithm it may be pertinent to write the module in a low level C that functionally emulates the final implementation without the overhead of a strict FPGA/VHDL implementation. In this way the algorithm can be tested using software scripts on a host machine to demonstrate accuracy. Ginngi's high quality Video Deinterlacer IP is an example of this approach. The C-Bit Accurate model is a Windows executable that can accepts an interlaced video file and produces a deinterlaced progressive video file.

Specialized DSP FPGA Tools

Today's high profile FPGA families (Xilinx, Altera) have extensive tools that allow quick implementation of DSP blocks into the FPGA architecture. This includes DSP compilers from Xilinx and C to FPGA tools from companies such as Impulse C (http://www.impulsec.com/). Ginngi has extensive experience using such tools to provide fast and efficient DSP implementations in FPGAs (see our article by Dov Stamler: http://www.xilinx.com/publications/xcellonline/xcell_60/xc_pdf/p53-55_60... in Xilinx XCell Journal, issue #60).

RTL Coding

Each block is coded using VHDL, Verilog, SystemVerilog or a specialized C such as ImpulseC. Synchronous design is strictly adhered to with all signal processing performed within a clocked process.

Verification

Bus Functional Models to emulate the external environment for the Device Under Test (DUT). Instead of using test vectors real transaction, as they would appear in a real system, are used. For example, if a CPU bus is implemented then a BFM module would be used to emulate the bus transactions but the test code would use high level functions such as WRITE and READ. Device models are used in order to build a testbench environment as closely as possible to the real system. Most such models may originate from the manufacturer and some have to be written from scratch.

Verification occurs both on the individual model level and on the system level. The testbench may be written in VHDL, Verilog or SystemVerilog, depending on the project.