Kazi ECE 6811

1
ECE 681VLSI Design Automation

• Khurram Kazi
• Lecture 8
• Thanks to Automation press THE button outcomes
  the Chip !!! Reality or Myth

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
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
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
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
Let us review some of the fundamental design
related issues we had discussed in the previous
lectures
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
• Dont mix two different clock domains in a single
  block
• Dont make the blocks too large (or too small)
• Optimize for Synthesis

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
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
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
Register all outputs
Simplifies the synthesis design environment
Inputs to the individual block arrive within the
same relative delay (caused by wire delays) Dont
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
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
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
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 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

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 dont throw code at it. Have
  systems perspective in mind, along with various
  stages of verification

16
Levels of verification
System
Board
Multiple ASICs or FPGAs
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
Single ASIC or FPGA
Top level Block
Sub-blocks
17
Example of a Multi ASIC verification environment
Tx of ASIC 1
Rx of ASIC 1
Pattern Generator
Analyzer
Pattern Generator
Tx of ASIC 1
ASIC 4
Rx of ASIC 1
Analyzer
Pattern Generator
Tx of ASIC 1
Rx of ASIC 1
Analyzer
18
Sample architecture of a generator and analyzer
Tb_testcase1.vhd
Global signals and control of tests Global
signals values are set at this level
Global signals can be used to as expected values
of out of ASIC
Transmitter.vhd
ASIC
Analyzer.vhd
Tb_dcom1 Tb_dcom2 Tb_frame_length .
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
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
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
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
What is the minimum that must be done

• You and your companys 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 standards document to
  ensure its correct implementation
• 4) Have an independent point of view try and base
  it on the specifications and standards
  documents.
• 5) Identify the key tests in the test plan that
  were written during the design process.

24
Ethernet frame
                                               
                                         
25
Ethernet frame encapsulated in SONET frame
A1
A2
Ethernet Frame 1
IPG
Ethernet
Ethernet Frame 3
Frame 2
IPG
Ethernet Frame 3
Ethernet Frame 3
IPG
IPG
Ethernet
Frame 4
IPG
IPG
Ethernet Frame n
26
OC-3 (STS-3 Frame)
3
2
1
3 STS-1 frames make up 1 STS-3 frame
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
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
Output Ports
Data1(70)
Data1_valid
Clk1
Serial_data_in
Data2(70)
Serial_clk_in (150 Mhz)
Data2_valid
Clk2
Data3(70)
Data3_valid
Clk3
30
Assignment 3 (continued)

• Write RTL Code, develop (extend existing)
  testbench, verify design, synthesize and
  Hopefully do formal verification (RTL vs Gates)