The Heidelberg ASIC lab design submission procedure

Purpose

This text is a basis of discussion for a design submission procedure defined for all groups participating in the ASIC lab Heidelberg. The aim is to streamline the submission procedure and to minimize stress from the designer(s) to make sure a design has been properly verified before submission.

The design submission procedure defines a submission readiness review that is held with the help of a small group of reviewers and the designer(s). The review's aim is to identify potential problems in the design that would make the chip useless.

The design review may conclude to

1. submit the design after completing the design work according to B.3.a-e.
2. submit the design after some items have been worked on. In this case at least one of the reviewers should meet with the designers again in the remaining time
3. Not to submit the design at the foreseen date because too many items were not covered. In this case another (realistic) submission date should be estimated.

Procedure definition

1. Designs have undergo a "submission readiness review" 4 weeks before the actual submission date. Members of this review are:
   1. The designer(s)
   2. The project group's senior designer (e. g. post-doc)
   3. If applicable at least one user of the chip that knows the specification of the chip
   4. At least one of: the ASIC lab design department engineer, a senior designer from a different project group, the ASIC lab manager.
   5. The minimum for a review are all members of 1) and one of 4).
2. The submission readiness review must present the following:
   1. Design overview
      1. Design specification
      2. General overview of the design, main ideas
      3. Identified critical components
   2. Components verification
      1. Schematics or source code of all major components, especially those identified as critical, must be at least accessible at the time of the review It should be the consent of all reviewers that the layout work not presented at the review meeting could be completed in the remaining time. Components which might be strongly (related to the specifications) influenced by parasitics must be simulated either a) with extracted parasitics or b) with the major parasitics inserted by hand In case of b) the designer should be able to comment those parasitics.
      2. Functionality of the module must be proven by test beds that verify the specification. The module instantiated in the test beds must be the same as on the final chip. Design corners must be taken into consideration.
      3. Results from the test bed must be presented by simulation output, i. e. printouts or similar. If the printouts are too complex an item list of the specification must be given with each item marked that was verified by simulation.
   3. Overall design verification. This is not part of the review meeting, but the tasks 1, 4 and 5 must be completed prior to submission. They are mandatory for the submission and must be checked by one of the reviewers who is not a participating designer.
      1. Testbed that proves the functionality of the complete design. The definition of 'complete design' is part of the review meeting. It should at least cover the top-level I/O functionality, e.g. the simulation must include the I/O pads
      2. Printout or saved logfile of the DRC report on the original database
      3. Printout or saved logfile of the LVS report on the original database
      4. Printout or saved logfile of the DRC report on the GDS2 database
      5. Printout or saved logfile of the LVS report on the GDS2 database

Help for being prepared

To save time for preparing the review, the following guidelines can be given, that should be followed during design work:

1. Follow the style guide
2. Organize your design hierarchically
3. For each non-trivial module in the design hierarchy create testbeds that reference this module and verify the specification. You may have several testbeds (for each specification item).
4. Store these testbeds in the same way as the designs (You can think of the testbeds being part of the design).
5. Save the results of the testbeds in a proper way (e. g. commented Postscript or similar pictures of analogue simulations). Save the results in a consistent way such that you can retrieve them later for the review.

How to allocate the chip area on an MPW run

and

how to obtain a "Device Number" from the foundry?

If the "submission readiness review" concluded to proceed according to 1. or if the second meeting according to 2. concludes that the design can be submitted within the proposed schedule, the technical coordinator of the ASIC lab will contact the fab. He will obtain the "Device Number" for the design and allocate the required area in an MPW run.

If a designer decides not to follow this procedure, e.g. because he/she belongs to an external group and the project was reviewed by members of their home institute, documents B.3.d and B.3.e together with a GDSII file of the design have to be presented to the ASIC-Lab's technical coordinator in order to to obtain the "Device Number" and to allocate the required wafer space.