The problem for Infrant Technologies, a young network storage IC company, was to figure out how to avoid the typical iterative design scenario. For our latest design, a 250-MHz network storage device with 3 million gates containing 40 macros in both Verilog and VHDL, we needed a front-end design that would enable us to produce high-quality RTL and timing constraints.
A traditional point-tool approach was not the answer. In traditional flows, it's very difficult to get an early estimate of the quality of your RTL, whether your timing constraints are clean or if your netlist is feasible. Any mistakes made in the front end don't appear until after place and route.
So we adopted an ASIC design flow that was based on Magma's integrated RTL-to-GDSII system. We would use Blast Create to synthesize the design and then hand off the netlist to our ASIC vendor to implement the design using Blast Fusion.
We entered the RTL code and timi ng constraints, which synthesized the entire design into gates, in a few hours. We then used the tool to generate an early silicon prediction-or ESL-gain report, which helps identify problematic paths in a design. Paths that contain many cells with a gain of less than 1 are likely to cause the design to miss its timing goal.
We discovered that there were several thousands paths with a gain of less than 1 in our design. We quickly determined that most of them were interpreted as single-cycle paths but should have been constrained as multicycle ones. We went back and added the constraints to make these multicycle paths.
When we ran the gain report the second time, about a hundred paths were found to have a gain of less than 1. We decided those paths should be eliminated by changes in RTL design, so we quickly modified the microarchitecture and RTL.
We repeated those steps several times before handing off a netlist in which just a handful of paths had a gain less than 1 and worst gain was over 0.90. This ability to modify the RTL and get reliable timing information quickly allowed us to do exhaustive what-if analyses and try some more-aggressive design techniques, such as trading off cost and speed and fully optimizing the RTL.
Improving timing constraints
We took on the responsibility of generating a good, complete set of timing constraints. After correcting the constraints we were able to clearly see that we would be able to achieve our target 250-MHz clock speed.
Because we were able to use a flat synthesis methodology, our timing constraints were much simpler. We did not have to divide our design into 10 to 15 blocks, we did not have to deal with one set of timing constraints for each block and we didn't have to worry about keeping all the constraints consistent with changes taking place at the block boundaries. We had just one set of constraints for the top level.
Des pite the fact that this project was the first time we had worked with this ASIC vendor, we had a smooth handoff process. Once we were satisfied with the timing predicted by the gain report, we delivered the design off to the vendor-and within about an hour the vendor had brought up the design in its environment.
We were able to achieve timing closure without any iteration between the ASIC house and our design team, and total time for ASIC implementation (synthesis with ASIC library and back-end)-including setup and learning to use the environment-was less than three months.
Yasuaki Hagiwara is vice president of IC engineering at Infrant Technologies Inc. (Fremont, Calif.).