Kazi ECE 6811

ECE 681ECE 681VLSI Design VLSI Design AutomationAutomationKhurram KaziKhurram Kazi

Lecture 8Lecture 8

Thanks to Automation press Thanks to Automation press THE button outcomes the THE button outcomes the Chip !!! Reality or MythChip !!! Reality or Myth

Kazi ECE 681 2

Some general observations Some general observations of assignment 1of 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)

Kazi ECE 681 3

Observations (continued)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

Kazi ECE 681 4

Test bench ObservationsTest 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

Kazi ECE 681 5

Test bench Observations Test bench Observations (continued)(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.

Kazi ECE 681 6

Let us review some of the Let us review some of the fundamental design related fundamental design related issues we had discussed in issues we had discussed in

the previous lecturesthe previous lectures

Kazi ECE 681 7

Fundamental Steps to a Good Fundamental Steps to a Good designdesign

• 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

Kazi ECE 681 8

Recommended rules for Recommended rules for SynthesisSynthesis

• 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

Kazi ECE 681 9

Avoid hierarchical Avoid hierarchical combinatorial blockscombinatorial 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).

Not recommended Design Practice

CombinatorialLogic1

CombinatorialLogic2

CombinatorialLogic3

Block A Block B Block C

reg1 reg2

Kazi ECE 681 10

Recommend way to handle Recommend way to handle Combinatorial PathsCombinatorial 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

Recommended practice

CombinatorialLogic1 &

Logic2& Logic3

Block A Block C

reg1reg2

Kazi ECE 681 11

Register all outputsRegister 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)

Register all outputs

Block X Block Y

reg1reg2

Block Y

reg3

Kazi ECE 681 12

NO GLUE LOGIC between NO GLUE LOGIC between blocksblocks

No Glue Logic between Blocks, nomatter what the temptation

Block X

reg1

Block Y

reg3

Top

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.

Kazi ECE 681 13

Optimization based on Optimization based on design requirementsdesign requirements

reg1

Slow Logic

Top

Timecritical path

reg3

Area optimized block

Speed optimized block• Use different

entities to partition design blocks

• Allows different constraints during synthesis to optimize for area or speed or both.

Kazi ECE 681 14

Pay extra attention to the Pay extra attention to the verification effortsverification 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 1st 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

Kazi ECE 681 15

When should the verification When should the verification efforts startefforts 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

Kazi ECE 681 16

Levels of verificationLevels of verificationSystem

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

Kazi ECE 681 17

Example of a Multi ASIC Example of a Multi ASIC verification environmentverification environment

Pattern Generator

Pattern Generator

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

Analyzer

Analyzer

Kazi ECE 681 18

Sample architecture of a Sample architecture of a generator and analyzergenerator 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_dcom1Tb_dcom2Tb_frame_length….

Tb_testcase1.vhd

Kazi ECE 681 19

How to automate simulation How to automate simulation (especially during regression testing)(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.

Kazi ECE 681 20

How do you know if the How do you know if the verification is completeverification 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

Kazi ECE 681 21

Some metrics in achieving Some metrics in achieving good functional coveragegood 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

Kazi ECE 681 22

How to monitor your How to monitor your progressprogress

• 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

Kazi ECE 681 23

What is the minimum that What is the minimum that must be donemust 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.

Kazi ECE 681 24

Ethernet frameEthernet frame

                                                                                        

Preamble7 bytes

SFD1 byte

D Addr6 bytes

S Addr8 bytes

Protocoltype

2 bytes

DATA46-1500 BYTES

FCS4 bytes

Preamble7 bytes

SFD1 byte

D Addr6 bytes

S Addr8 bytes

DataLength2 bytes

DATA46-1500 BYTES

FCS4 bytes

Ethernet II Header Layout

802.3 Header Layout

This field is different in thetwo frame structures

Kazi ECE 681 25

Ethernet Frame 3

Ethernet frame encapsulated Ethernet frame encapsulated in SONET framein SONET frame

A1 A2 Ethernet Frame 1 IPG Ethernet

Frame 2 IPG

Ethernet Frame 3

Ethernet Frame 3

IPG IPG Ethernet

Frame 4

IPG

IPG

Ethernet Frame n

Kazi ECE 681 26

OC-3 (STS-3 Frame)OC-3 (STS-3 Frame)

3 STS-1 frames make up 1 STS-3 frame

1

23

Kazi ECE 681 27

STS-3 Frame formatSTS-3 Frame format

A1(1) A1(2) A1(3) A2(1) A2(2) A2(3)

BIP-1

Header bytesBIP-1 is calculated over entire frameSimilar to header bytes the payload is in same order

Kazi ECE 681 28

Assignment 3Assignment 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

Kazi ECE 681 29

Output PortsOutput PortsData1(7:0)

Data1_validClk1

Data2(7:0)

Data2_validClk2

Data3(7:0)

Data3_validClk3

Serial_data_in

Serial_clk_in(150 Mhz)

Kazi ECE 681 30

Assignment 3 (continued)Assignment 3 (continued)• Write RTL Code, develop (extend

existing) testbench, verify design, synthesize and Hopefully do formal verification (RTL vs Gates)