1. Kazi ECE 6811 ECE 681 VLSI Design Automation Khurram Kazi Lecture 8 Thanks to Automation press THE button outcomes the Chip !!! Reality or Myth

2. Kazi ECE 681 2 Some general observations of assignment 1 Hierarchy was not clean. Great deal of logic was inferred at all levels of hierarchy. This approach does not fit well with the bottom up synthesis process. Partitioning of the blocks was sub-optimal (e.g. no need to create a separate file for the de- scrambler) Took the easy way out in the generation of the slow speed clocks by simply gating the serial clock. Some did not initialize the circuits to known state Always bring your logic to known state (always use reset or set to do this)

3. Kazi ECE 681 3 Observations (continued) Keep the fan out of the high speed signal to a minimal –Better approach would have been to convert serial data (after A1A2 detection and possibly de-scrambling) into parallel and then do the SPE and the DCOM data extraction. Use serial to parallel conversion. Have a separate block for all internally generated clocks. –Makes the synthesis process easier to manage –Allows ease of clock tree insertion –Makes it a clean design

4. Kazi ECE 681 4 Test bench Observations The development of the test bench should start with some picture of the peripheral circuit the ASIC is going to be connected to. Keep in mind which type of a device is the data is coming from and which device the data going to. Synchronize the generation of data with the clock. –This allows using the test bench to generate functional test vector –Race conditions are avoided. –Possibly add programmable delay to the data being transported out of the test bench to the ASIC with respect to the clock. Always have all your output signals initialized to a known state. For example, use reset to drive these signals

5. Kazi ECE 681 5 Test bench Observations (continued) On the analyzer –Use the clock generated by the ASIC to clock in the associated data. For example use the d1_3_clk to clock in the d1_3_sof and d1_3_data signals. –This technique avoids race conditions and mimics the real behavior of the system.

6. Kazi ECE 681 6 Let us review some of the fundamental design related issues we had discussed in the previous lectures

7. Kazi ECE 681 7 Fundamental Steps to a Good design If you have a good start, the project will go smoothly Partitioning the Design is a good start Partition by: –Functionality Don’t mix two different clock domains in a single block –Don’t make the blocks too large (or too small) –Optimize for Synthesis

8. Kazi ECE 681 8 Recommended rules for Synthesis When implementing combinatorial paths do not have hierarchy Register all outputs Do not implement glue logic between block, partition them well Separate designs on functional boundary Keep block sizes to a reasonable size

9. Kazi ECE 681 9 Avoid hierarchical combinatorial blocks The path between reg1 and reg2 is divided between three different block Due to hierarchical boundaries, optimization of the combinatorial logic cannot be achieved Synthesis tools (Synopsys) maintain the integrity of the I/O ports, combinatorial optimization cannot be achieved between blocks (unless “grouping” is used).

10. Kazi ECE 681 10 Recommend way to handle Combinatorial Paths All the combinatorial circuitry is grouped in the same block that has its output connected the destination flip flop It allows the optimal minimization of the combinatorial logic during synthesis Allows simplified description of the timing interface

11. Kazi ECE 681 11 Register all outputs Simplifies the synthesis design environment: Inputs to the individual block arrive within the same relative delay (caused by wire delays) Don’t really need to specify output requirements since paths starts at flip flop outputs. Take care of fanouts, rule of thumb, keep the fanout to 16 (dependent on technology and components that are being driven by the output)

12. Kazi ECE 681 12 NO GLUE LOGIC between blocks Due to time pressures, and a bug found that can be simply be fixed by adding some simple glue logic. RESIST THE TEMPTATION!!! At this level in the hierarchy, this implementation will not allow the glue logic to be absorbed within any lower level block.

13. Kazi ECE 681 13 Optimization based on design requirements Use different entities to partition design blocks Allows different constraints during synthesis to optimize for area or speed or both.

14. Kazi ECE 681 14 Pay extra attention to the verification efforts In large complex ASICs, at times 70% of the project time is spent on ASIC verification. So pay close attention to it while designing. This is a relatively new field (so to speak) where newer ways have to be used in order to verify the design for 1 st time success. Verification effort can be reduced through abstraction –However, this requires additional training. Specman ‘e’ will be used for this purpose. Verification time can be reduced by using automation

15. Kazi ECE 681 15 When should the verification efforts start During the specification of the device, verification methodology should begin also. Develop the verification architecture and build a comprehensive environment. Think carefully how testbenches need to be developed. Just don’t throw code at it. Have systems perspective in mind, along with various stages of verification

16. Kazi ECE 681 16 Levels of verification System Board Multiple ASICs or FPGAs Single ASIC or FPGA Top level Block Sub-blocks Most likely ASIC designers will have to make provisions for all these levels of verification Try to develop testbench such that it can be re- used at various levels or verification

17. Kazi ECE 681 17 Example of a Multi ASIC verification environment Pattern Generator Rx of ASIC 1 ASIC 4Rx of ASIC 1 Rx of ASIC 1 Tx of ASIC 1 Tx of ASIC 1 Tx of ASIC 1 Analyzer

18. Kazi ECE 681 18 Sample architecture of a generator and analyzer Transmitter.vhd Global signals and control of tests; Global signals values are set at this level Analyzer.vhd Global signals can be used to as expected values of out of ASIC ASIC Tb_dcom1 Tb_dcom2 Tb_frame_length …. Tb_testcase1.vhd

19. Kazi ECE 681 19 How to automate simulation (especially during regression testing) Build warning/error messages when writing the analyzer. –At the analyzer level or at the tb_filename.vhd level –Create separate files that record these messages –Write a script (Pearl, TCL..) to parse these files and see if the key words are in the files that suggest passing or failing of a test. –Generate a report after parsing. –Finally generate a pass or fail.

20. Kazi ECE 681 20 How do you know if the verification is complete In complex ASICs more than likely you cannot say for sure that your functional verification is 100% complete due to enormous combinations that can happen. Try to achieve good confidence in the working of the design by using several metrics. There is no single answer! Due to time pressures you may have to cut corners or come up with innovative verification solutions

21. Kazi ECE 681 21 Some metrics in achieving good functional coverage Start with the code coverage –Statement coverage Did all the statements get exercised in simulations –Path coverage Measures all possible ways you can execute a sequence of statements. Especially in the “if then else” conditional statements. –Expression Coverage Measures the various ways paths through the code are executed. It is tough to reach 100% path or expression coverage

22. Kazi ECE 681 22 How to monitor your progress Specman ‘e’ allows you to monitor your code coverage. Monitor functional coverage –Measures the progress of your verification effort against a test plane (which must be derived from specifications, other related documents and customer requirements) –Avoid creating redundant tests that waste simulation cycles

23. Kazi ECE 681 23 What is the minimum that must be done You and your company’s reputation will be at stake so tread carefully under market pressures. 1) Identify the key features that the prospective customers are really interested in and make sure they work under normal operating circumstances 2) Use the specifications to ensure proper functionality. 3) If the ASIC is trying to comply with some standard then use the standard’s document to ensure its correct implementation 4) Have an independent point of view try and base it on the specifications and standard’s documents. 5) Identify the key tests in the test plan that were written during the design process.

24. Kazi ECE 681 24 Ethernet frame

25. Kazi ECE 681 25 Ethernet Frame 3 Ethernet frame encapsulated in SONET frame A1 A2 Ethernet Frame 1IPG Ethernet Frame 2IPG Ethernet Frame 3 IPG Ethernet Frame 4 IPG Ethernet Frame n

26. Kazi ECE 681 26 OC-3 (STS-3 Frame) 3 STS-1 frames make up 1 STS-3 frame 1 2 3

27. Kazi ECE 681 27 STS-3 Frame format A1(1) A1(2)A1(3) A2(1)A2(2)A2(3) BIP-1 Header bytes BIP-1 is calculated over entire frame Similar to header bytes the payload is in same order

28. Kazi ECE 681 28 Assignment 3 Extend your existing SONET assignment and this time the payload is variable size Ethernet frames. There are 3 sets of Output ports which transport out of the ASIC, the Ethernet frames from the appropriate STS-1 within the STS-3

29. Kazi ECE 681 29 Output Ports Data1(7:0) Data1_valid Clk1 Data2(7:0) Data2_valid Clk2 Data3(7:0) Data3_valid Clk3 Serial_data_in Serial_clk_in (150 Mhz)

30. Kazi ECE 681 30 Assignment 3 (continued) Write RTL Code, develop (extend existing) testbench, verify design, synthesize and Hopefully do formal verification (RTL vs Gates)