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)
Top Related