THE VLSI HOMEPAGE

A Practical guide to VLSI Design and Verification..

ASIC Design Flow - II

Posted in ASIC Design Flow by Nigam on the August 28th, 2007

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.
Sphere: Related Content

Related Posts
  • ASIC Design Flow
  • 6 Responses to 'ASIC Design Flow - II'

    Subscribe to comments with RSS or TrackBack to 'ASIC Design Flow - II'.


    1. on September 25th, 2007 at 2:58 pm

      […] We will look at each step in detail in the next post. […]

    2. RN said,

      on October 11th, 2007 at 6:43 am

      This is “one” design flow.

      If you want to design any kind of a “real” chip, you are going to have register files and caches. You will need a design flow for the small signal arrays and RFs.

      And if you really want performance, your datapath should be hand designed. Have you ever tried to route a datapath block lately? I havent, and when I evaluated tools a while ago, I was less than impressed with the datapath design features of Synthesis/APR tools.

      -RN

    3. Nigam said,

      on October 12th, 2007 at 9:48 am

      hi Rohit,

      I agree - the design flow is customized as per the chip requirements, IP integration, the market it is catering to etc. There is no one flow that fits all.

      As for “real” chips - yes, based on my exposure, I have seen chips conforming to this flow - standard products catering to consumers for example.

      The points you make are all valid for high-speed designs (network processors for example), experience in which I lack :)

      regards,
      Nigam


    4. on October 17th, 2007 at 11:24 am

      Hi Nigam,

      Good article , really appreciate your efforts.
      Regarding ASIC design flow is explained in detailed with the tools used and their roles at each stage is explained. Request you to check this .
      http://www.vlsichipdesign.com/vlsidesignflow.html

    5. Shwetha said,

      on March 20th, 2008 at 1:02 pm

      Nigam,
      This is the article that a beginner would like to appreciate.
      May I ask for the links/books that you have referred to that has given an outcome as good as the above?

      Thanks
      Shwetha

    6. Nigam said,

      on March 22nd, 2008 at 6:41 am

      thanks Shwetha !

      The post above is based on my industry exposure in part and partly books/papers I have referred to in the past. I wish I could point to any one book that covers ASIC flow in detail.

      Bening & Foster’s “principles of verifiable rtl design” is one good book I would recommend.

    Leave a Reply


    Close
    E-mail It