ASIC Design Flow - II
We will now look at each stage depicted in the ASIC flowchart .
- MRD (Marketing Requirements Document) - As the name indicates, a list of desirable features catering to a particular market is documented by the Marketing Director or Product Line Manager. The key features are evaluated based on customer’s expectations and requests, competitor products in the same segment, innovation and value “add-on” etc. The MRD is a fascinating document to study! It explores opportunities in the market, time to market, projects revenue estimates and net profit margins over the product’s lifetime, building costs, interested customers and distinguishing features over a rival’s ASIC
. The upper management gathers together for a “Project Commit” to evaluate the business proposition based on this MRD.
- Architecture Spec - The Architecture team based on the MRD evaluates the feasibility of implementation, performance issues and documents the architecture at a very high and abstract level. The Architecture spec is “forward looking” and one of the challenges is scalability - where the architecture is retained for entire generation of multiple ASICs (each chip is progressive in terms of features). The architecture model is usually a transaction level model (TLM) where each event is not explicitly defined but defines communicating processes. An example is a Bit Accurate Model (BAM) written in ‘C’
- Architecture Validation - Helps in detecting architectural flaws ahead in the design cycle to meet the time-to-market. Directed testcases are written to stress the architectural model for any performance issues, protocol violations and bugs. This stage is optional and is often seen only in complex chips.
- Design Spec - delves into details of the design. Partitioning of functions into blocks, clock/reset requirements, pipelining of registers, memory buffers, state machines and interface details. A well written design spec is crucial to ASIC design so that there are no underlying assumptions that need to be made by the verification
team or the designer whose block interfaces with it.
- RTL Design - coded in Verilog
or VHDL. The design is segregated into different modules based on clock domains, functionality and reuse. Instantiates library elements, memories and FIFOs.
- Linting - Lint checks for syntax/semantic errors in the design and is often useful in debugging connectivity issues early in the cycle. Several vendors like Atrenta offer lint tools that is capable of detecting combinational loops, latches and also clock domain crossings in the design without proper synchronization.
- Design Verification - The Design Verification team based on the architecture/micro-architecture spec identifies the testcases that need to be written to verify the features and documents it in a Verification Testplan. The verification team in parallel to the RTL design effort builds testbenches and verification platform including bus functional models (BFM), transactors, scoreboards, checkers and coverage items. An entire regression testsuite (with hundreds of random and directed testcases) is developed to stress the RTL. Coverage metrics from the regression results (line, fsm, code and functional coverage) indicate the verification progress.
- Synthesis - compiles the RTL Design and maps the logic to library elements like NAND gates and memories. The synthesis engine reads in the input constraints (defining IO input/output delays, clock frequencies, multicycle/false paths) and optimizes the logic to meet timing. Area reports are generated for floorplanning activity, power estimates and package selection. The output netlist and constraints are inputs to timing driven layout.
- Physical Design - The PD team read in the netlist/constraints and floorplan the memories, hard macros like PLL, Serdes, optimize pin placement, power nets, build clock trees to minimize skew. The physical design engine being cognizant of placement of gates/macros optimizes the design further to meet timing. Seven layers of metal are common in routing the design and any congestion and crosstalk aggressors/victims are fixed in the physical database. DRC/LVS checks are run on the database to report any shorts/opens and metal spacing/width violations.
- Static Timing Analysis - The PD engine after routing the design outputs a placed netlist along with parasitics (interconnect delays and gate delays) in SPEF/SDF format for timing analysis. The design owner runs static timing analysis to check setup/hold timing and verifies that the design conforms to specifications. Timing analysis also takes noise analysis into account and any delays induced by it.
- Package Selection and Ballmap - is a parallel activity with design/verification and is used to map the chip IO pins to balls on the package. A package selection depends on costs, power requirements, parasitics and routability. For eg - a flipchip package is more expensive than the normal wirebond package.
- Tapeout - Once timing is closed and verification process is complete, the chip is ready to be taped out to a fab foundry like TSMC, UMC. The chip is fabricated on a wafer, packaged and is ready to be validated at the board level also known as post silicon validation ! The board level design is based on system design kit (SDK) requirements document that describes the board components like SDRAM, DDR, EEPROM memories, power supply, and clock sources, reset sequencer, jumpers etc.
6 Comments
ASIC Design Flow
The flowchart thumbnail below depicts the sequence an ASIC chip usually goes through - from concept to tapeout. It is not necessary that all ASICs subscribe to the same flow: Based on each chip design/verification
complexity and time to tapeout, a few steps in the flow may be integrated with each other or skipped altogether.
ASIC Design Flow - from concept to tapeout
We will look at each step in detail in the next post.
Sphere: Related Content