Driving the Adoption of Model-Based Design for Communications System Development at Hitachi
By Noritaka Kosugi, Kazuyuki Hori, and Yuji Ishida, Information & Telecommunication Systems Company Telecommunications & Network Systems Division, Hitachi, Ltd., and Makoto Hasegawa, Hitachi Information & Telecommunication Engineering, Ltd.
Signal processing algorithms are incorporated into most Hitachi products, including wireless base stations, access points, and transmitters for telecommunication services, and IP-PBX and video conferencing systems for enterprise networks. Traditionally, these algorithms have been implemented as ASICs. As the communications market diversifies and moves to high-mix, low-volume production, Hitachi is increasingly relying on FPGAs.
We have adopted Model-Based Design with MATLAB® and Simulink® as our standard development workflow for FPGA design. As a result, we have improved communication between teams, reduced development time, and reduced risk by evaluating system performance early in the design process.
Limitations of Our Previous Workflow
A typical FPGA development project for a communication system at Hitachi involves three teams:
- The system design team develops signal processing algorithms to fulfill functional requirements and creates a specification using block diagrams, algorithm code, state transition tables, and so on.
- The FPGA design team creates functional diagrams and HDL code, including test benches for verification of the final algorithms. This team also performs logic synthesis and place-and-route steps, as well as verifying the FPGA implementation.
- The functional test team tests a physical prototype of each component. They then integrate the components and test the entire system, including radio RF and analog components.
In our previous, document-based design workflow, each team developed its own specification. This created a communication gap between the teams, as well as delays and the increased risk of error.
Both the system design team and the FPGA design team worked from a functional diagram based on the FPGA design team's specification (Figure 1). We had to use this functional diagram to determine whether the system design team required clarification or additional information to describe the required functionality in HDL code. This resulted in unnecessary delays and duplication of effort, making the process a bottleneck, especially for the FPGA design team.
Bridging the Communication Gap with Model-Based Design
We adopted Model-Based Design to enable the teams to verify the specification via a model in a shared simulation environment. In this new workflow, we use MATLAB and Simulink to model the signal processing algorithm. The system design and FPGA design teams use the model as an executable specification. The model is refined and elaborated throughout the design process. HDL code is automatically generated from the model for logic synthesis, place and route, and hardware implementation.
We found that the FPGA implementation developed with Model-Based Design resulted in almost the same level of processing performance and resource efficiency that we had achieved with the conventional workflow. Power consumption was also almost equivalent.
In addition, the FPGA design team was able to handle this project with almost half the number of engineers they needed for the traditional workflow. One reason we could not reduce head count further was the time required for refining the Simulink model.
Applying Model-Based Design: Critical Considerations and Examples
In many respects we found Model-Based Design to be an ideal workflow (Figure 2). When evaluating this approach on an actual FPGA design, we identified three elements that are key to a successful outcome: model refinement, test pattern generation, and simulation after synthesis.
Simulink Model Refinement
Usually, the system design team creates the signal processing algorithm. For accuracy, the algorithm is modeled with double-precision floating-point data. Since the target FPGA can only handle fixed-point data, the model has to be converted to fixed point. Preparing the algorithms for hardware implementation involves additional considerations, including quantization errors, bit width and word length configurations, and vector data handling. Furthermore, in preparation for code generation the algorithm model must be refined to optimize processor performance while effectively using resources such as DSP units or RAM on an FPGA device.
Test Pattern Generation
HDL Coder™ lets you generate HDL test pattern data automatically with an interface to a Simulink model. This greatly reduces the time and effort required to create a test bench manually.
Simulation After Logic Synthesis
Running simulations after logic synthesis is an indispensable though time-consuming way to verify the implementation. This task must be carried out as a substitute for the conventional design-rule check to the hand-coded HDL. We found that using FPGA-in-the-loop (FIL) simulation with HDL Verifier™ reduces the time required for this task (Table 1).
|Simulation after logic synthesis (gate-level netlist simulation)
|About 200 hours
|4 minutes 30 seconds
In FIL the Simulink model is connected directly to a standard FPGA test board (Figure 3).
Reducing the verification time means we can run more test cases. At Hitachi, we used this approach effectively to detect errors, including errors from the timing controller circuit and the initialization circuit.
Figure 4 shows the outcome of introducing Model-Based Design to our wireless communication system development process.
Example 1: Using DSP Units in a FIR Filter
In this example, we describe DSP units in a finite impulse response (FIR) filter using a vector expression (Figure 5).
However, when we implemented the HDL code generated directly from this model, we used adders outside the DSP units. As a result, the design did not meet the 110 MHz clock rate requirement.
To use the built-in adder chain in DSP units most effectively, we refined the model according to the FPGA vendor's recommendations. The result was a performance improvement from 78 MHz to 340 MHz (Figure 6).
Example 2: Using DSP Units for a Complex Multiplier
In this example, we describe a complex multiplier implementation block in Simulink (Figure 7).
Note that a unit delay is inserted right after the output. For this unit delay implementation, we activated a flip-flop (FF) outside a DSP unit. Our goal was to implement the unit delay on a flip-flop in a built-in DSP unit located between the multiplier and the adder.
We refined the model by changing the FF structure. Using DSP System Toolbox™ we added a second delay block (Figure 8). We configured the additional constraint for the logic synthesis to prohibit retiming and to permit pipelining. As a result, the FF was implemented on the DSP unit effectively.
Easing the Transition to Model-Based Design
To ensure the successful implementation of Model-Based Design, we held technical seminars to help system designers and FPGA designers understand the concepts and benefits of Model-Based Design. We also developed a comprehensive set of guidelines to standardize the FPGA design workflow and help algorithm designers and FPGA design teams use Simulink effectively as a shared executable specification. These guidelines include the following:
Simulink Specifications. This guide provides approximately 50 rules prescribing how to create a Simulink model. It contains general rules, such as the conditions of operation and naming rules for signals and data, as well as rules specifying model structure, hierarchy, and the format of block diagrams.
Verification Standards. This guide covers hardware detail design verification, FPGA implementation, and FPGA unit verification. It includes processes, required checks, and verification documents.
HDL Coder Tips. This document summarizes our knowledge of how to use HDL Coder effectively. It contains about 40 items, including how to operate and configure HDL Coder.
FIL User Manual. This document summarizes our experience with using the FIL feature in HDL Verifier, including how to set up and operate the FIL simulation environment.
Driving the Adoption of Model-Based Design
Our team took the initiative to drive the adoption of Model-Based Design within Hitachi. Sometimes we completed entire projects by ourselves, from circuit selection to hardware testing, to familiarize ourselves with Model-Based Design and to prove various development concepts.
To date, we have adopted Model-Based Design for over 10 product development projects at Hitachi, including designing and developing the signal processing components in a wireless base station, optical communications equipment, and image processing systems. We hope to extend the adoption of Model-Based Design to new development projects and to share our accumulated experience with other departments, both within Hitachi and at our partner companies.
Published 2013 - 92144v00