1) What is antenna violation & ways to prevent it?
Answer:
During the process of plasma etching, charges accumulate along the metal strips. The longer the strips are, the more charges are accumulated. If a small transistor gate connected to these long metal strips, the gate oxide can be destroyed (large electric field over a very thin electric) , This is called as Antenna violation.
The ways to prevent is , by making jogging the metal line, which is at least one metal above the layer to be protected. If we want to remove antenna violation in metal2 then need to jog it in metal3 not in metal1. The reason being while we are etching metal2, metal3 layer is not laid out. So the two pieces of metal2 got disconnected. Only the piece of metal connected to gate have charge to gate. When we laydown metal3, the remaining portion of metal got charge added to metal3. This is called accumulative antenna effect.
Another way of preventing is adding reverse Diodes at the gates.
It's true that the diode will 100% solve your "violation" but watch out that, in certain conditions, the leakage this diode will have could actually kill your circuit... Conclusion... As always, this is a trade of...
additional interview-questions-and-answers
Friday, January 29, 2010
Asic Flow
Asic Design Flow
Step 1: Prepare an Requirement Specification
Step 2: Create an Micro-Architecture Document.
Step 3: RTL Design & Development of IP's
Step 4: Functional verification all the IP's/Check whether the RTL is free from Linting Errors/Analyze whether the RTL is Synthesis friendly.
Step 6: To Perform Synthesis for the IP, the inputs to the tool are (library file(for which synthesis needs to be targeted for, which has the functional/timing information available for the standard-cell library and the wire-load models for the wires based on the fanout length of the connectivity), RTL files and the Design Constraint files, So that the Synthesis tool can perform the synthesis of the RTL files and map and optimize to meet the design-constraints requirements. After performing synthesis, as a part of the synthesis flow, need to build scan-chain connectivity based on the DFT(Design for Test) requirement, the synthesis tool (Test-compiler), builds the scan-chain.
Step 7: Check whether the Design is meeting the requirements (Functional/Timing/Area/Power/DFT) after synthesis.
Step 9: The next step is the Floor-planning, which means placing the IP's based on the connectivity,placing the memories, Create the Pad-ring, placing the Pads(Signal/power/transfer-cells(to switch voltage domains/Corner pads(proper accessibility for Package routing), meeting the SSN requirements(Simultaneous Switching Noise) that when the high-speed bus is switching that it doesn't create any noise related acitivities, creating an optimised floorplan, where the design meets the utilization targets of the chip.
Step 11: After performing Routing then the routed Verilog netlist, standard-cells LEF/DEF file is taken to the Extraction tool (to extract the parasitics(RLC) values of the chip in the SPEF format(Standard parasitics Exchange Format), and the SPEF file is generated. ( Tool: STARRC )
Step 12: Check whether the Design is meeting the requirements (Functional/Timing/Area/Power/DFT/DRC/LVS/ERC/ESD/SI/IR-Drop) after Placement and Routing step.
Step 13: Once the routed design is verified for the design constraints, then now the next step is chip-finishing activities (like metal-slotting, placing de-coupling caps).
Step 14: Now the Chip Design is ready to go to the Fabrication unit, release files which the fab can understand, GDS file.
Step 15: After the GDS file is released , perform the LAPO check so that the database released to the fab is correct.
Step 16: Perform the Package wire-bonding, which connects the chip to the Package.
For more detail, check this website
Step 1: Prepare an Requirement Specification
Step 2: Create an Micro-Architecture Document.
Step 3: RTL Design & Development of IP's
Step 4: Functional verification all the IP's/Check whether the RTL is free from Linting Errors/Analyze whether the RTL is Synthesis friendly.
- Step 4a: Perform Cycle-based verification(Functional) to verify the protocol behaviour of the RTL
- Step 4b: Perform Property Checking , to verify the RTL implementation and the specification understanding is matching.
Step 6: To Perform Synthesis for the IP, the inputs to the tool are (library file(for which synthesis needs to be targeted for, which has the functional/timing information available for the standard-cell library and the wire-load models for the wires based on the fanout length of the connectivity), RTL files and the Design Constraint files, So that the Synthesis tool can perform the synthesis of the RTL files and map and optimize to meet the design-constraints requirements. After performing synthesis, as a part of the synthesis flow, need to build scan-chain connectivity based on the DFT(Design for Test) requirement, the synthesis tool (Test-compiler), builds the scan-chain.
Step 7: Check whether the Design is meeting the requirements (Functional/Timing/Area/Power/DFT) after synthesis.
- Step 7a: Perform the Netlist-level Power Analysis, to know whether the design is meeting the power targets.
- Step 7b: Perform Gate-level Simulation with the Synthesized Netlist to check whether the design is meeting the functional requirements.
- Step 7c: Perform Formal-verification between RTL vs Synthesized Netlist to confirm that the synthesis Tool has not altered the functionality.( Tool: Formality )
- Step 7d: Perform STA(Static Timing Analysis) with the SDF(Standard Delay Format) file and synthesized netlist file, to check whether the Design is meeting the timing-requirements.( Tool: PrimeTime)
- Step 7e: Perform Scan-Tracing , in the DFT tool, to check whether the scan-chain is built based on the DFT requirement.
Step 9: The next step is the Floor-planning, which means placing the IP's based on the connectivity,placing the memories, Create the Pad-ring, placing the Pads(Signal/power/transfer-cells(to switch voltage domains/Corner pads(proper accessibility for Package routing), meeting the SSN requirements(Simultaneous Switching Noise) that when the high-speed bus is switching that it doesn't create any noise related acitivities, creating an optimised floorplan, where the design meets the utilization targets of the chip.
- Step 9a : Release the floor-planned information to the package team, to perform the package feasibility analysis for the pad-ring .
- Step 9b: To the placement tool, rows are cut, blockages are created where the tool is prevented from placing the cells, then the physical placement of the cells is performed based on the timing/area requirements.The power-grid is built to meet the power-target's of the Chip .
Step 11: After performing Routing then the routed Verilog netlist, standard-cells LEF/DEF file is taken to the Extraction tool (to extract the parasitics(RLC) values of the chip in the SPEF format(Standard parasitics Exchange Format), and the SPEF file is generated. ( Tool: STARRC )
Step 12: Check whether the Design is meeting the requirements (Functional/Timing/Area/Power/DFT/DRC/LVS/ERC/ESD/SI/IR-Drop) after Placement and Routing step.
- Step 12a: Perform the Routed Netlist-level Power Analysis, to know whether the design has met the power targets.
- Step 12b: Perform Gate-level Simulation with the routed Netlist to check whether the design is meeting the functional requirement .
- Step 12c: Perform Formal-verification between RTL vs routed Netlist to confirm that the place & route Tool has not altered the functionality.
- Step 12d: Perform STA(Static Timing Analysis) with the SPEF file and routed netlist file, to check whether the Design is meeting the timing-requirements.
- Step 12e: Perform Scan-Tracing , in the DFT tool, to check whether the scan-chain is built based on the DFT requirement, Peform the Fault-coverage with the DFT tool and Generate the ATPG test-vectors.
- Step 12f: Convert the ATPG test-vector to a tester understandable format(WGL)
- Step 12g: Perform DRC(Design Rule Check) verfication called as Physical-verification, to confirm that the design is meeting the Fabrication requirements.
- Step 12h: Perform LVS(layout vs Spice) check, a part of the verification which takes a routed netlist converts to spice (call it SPICE-R) and convert the Synthesized netlist(call it SPICE-S) and compare that the two are matching.
- Step 12i : Perform the ERC(Electrical Rule Checking) check, to know that the design is meeting the ERC requirement.
- Step 12j: Perform the ESD Check, so that the proper back-to-back diodes are placed and proper guarding is there in case if we have both analog and digital portions in our Chip. We have seperate Power and Grounds for both Digital and Analog Portions, to reduce the Substrate-noise.
- Step 12k: Perform seperate STA(Static Timing Analysis) , to verify that the Signal-integrity of our Chip. To perform this to the STA tool, the routed netlist and SPEF file(parasitics including coupling capacitances values), are fed to the tool. This check is important as the signal-integrity effect can cause cross-talk delay and cross-talk noise effects, and hinder in the functionality/timing aspects of the design.
- Step 12l: Perform IR Drop analysis, that the Power-grid is so robust enough to with-stand the static and dynamic power-drops with in the design and the IR-drop is with-in the target limits.
Step 13: Once the routed design is verified for the design constraints, then now the next step is chip-finishing activities (like metal-slotting, placing de-coupling caps).
Step 14: Now the Chip Design is ready to go to the Fabrication unit, release files which the fab can understand, GDS file.
Step 15: After the GDS file is released , perform the LAPO check so that the database released to the fab is correct.
Step 16: Perform the Package wire-bonding, which connects the chip to the Package.
For more detail, check this website
Prime Time Questions
1) What's PrimeTime?
Answer:
PrimeTime is a full chip static analysis tool that can fully analyze a multimillion gate ASIC in a short
amount of time.
2) What files are required for PrimeTime to run?
Answer:
PrimeTime needs four types of files before you can run it:
1. Netlist file: Verilog, VHDL, EDIF
2. Delay file: SPEF(standard parasitic format, it's from STARRC or place&route tool), SPF, SDF(standard delay format)
3. Library file: DB ( From library vendors)
4. Constrains file: Synopsys Design Constraints(SDC) include 3 min requirement, clock, input delay and output delay
3) Can I use script in PrimeTime?
Answer: Yes, you should use tcl( Tool command language) whenever possible.
4) What PrimeTime check?
Answer:
PrimeTime will check the following violations:
1. Setup violations: The logic is too slow compare to the clock.
With that in mind there are several things a designer can do to fix the setup violations.
To fix hold violations in the design, the designer needs to simply add more delay
to the data path. This can be done by
the chip is made, more there is nothing that can be done post fabrication to fix hold problems unlike setup violation where the clock speed can be reduced.
3. Transition Violations:
When a signal takes too long transiting from one logic level to another, a transition violation is reported. The violation is a function of the node resistance and capacitance.
The designer has two simple solutions to fix the transitions violations.
The capacitance on a node is a combination of the fan-out of the output pin and
the capacitance of the net. This check ensures that the device does not drive more
capacitance than the device is characterized for.
5) What conditions are used to check setup violation?
Answer:
WorstCase => setup violations
BestCase => hold violations
We use the worst case delay when testing for setup violations and then we use the best case delay when testing for hold violations.
6) How to run PrimeTime in the unix?
[Linux] user@gmu>> pt_shell –f pt_script.tcl |& tee pt.log
Here are the sample PrimeTime script :
A total of three scripts must be created, one for each timing corner.
# ------------------------------------------------------------
# Library Declarations.
# ------------------------------------------------------------
set search_path ". /proj/timing/etc"
set link_path "*"
lappend link_path "stdCell_tt.db"
# ------------------------------------------------------------
# Read in Design
# ------------------------------------------------------------
# Read in netlist
read_file -f verilog top_level.v
# Define top level in the hierarchy
current_design "top_level"
# Combine verilog and db files and identify any errors.
link_design
# Read in SPEF file
read_parasitics -quiet -format SPEF top_level.spef.gz
# ------------------------------------------------------------
# Apply Constraints
# ------------------------------------------------------------
# Read in timing constraits
read_sdc -echo top_level.sdc
# Propagate clocks and add uncertainty to setup/hold calculations
set_propagated_clock [all_clocks]
set_clock_uncertainty 0.2 [all_clocks]
21
# ------------------------------------------------------------
# Time
# ------------------------------------------------------------
set_operating_conditions -min WORST -max WORST
# Register to Register
report_timing -from [all_registers -clock_pins] \
-to [all_registers -data_pins] -delay_type max \
-path_type full_clock –nosplit \
-max_paths 1 -nworst 1 \
-trans -cap -net > tc_reg2reg_setup.rpt
report_timing -from [all_registers -clock_pins] \
-to [all_registers -data_pins] -delay_type min \
-path_type full_clock –nosplit \
-max_paths 1 -nworst 1 \
-trans -cap -net > tc_reg2reg_hold.rpt
# Register to Out
report_timing -from [all_registers -clock_pins] \
-to [all_outputs] -delay_type max \
-path_type full_clock –nosplit \
-max_paths 1 -nworst 1 \
-trans -cap -net > tc_reg2out_setup.rpt
report_timing -from [all_registers -clock_pins] \
-to [all_outputs] -delay_type min \
-path_type full_clock –nosplit \
-max_paths 1 -nworst 1 \
-trans -cap -net > tc_reg2out_hold.rpt
# In to Register
report_timing -from [all_inputs]
-to [all_registers -data_pins] \
-delay_type max \
-path_type full_clock –nosplit \
-max_paths 1 -nworst 1 -trans \
–cap -net > tc_in2reg_setup.rpt
report_timing -from [all_inputs] \
-to [all_registers -data_pins] \
-delay_type min -path_type full_clock \
-nosplit -max_paths 1 -nworst 1 \
-trans -cap -net > tc_in2reg_hold.rpt
# All Violators – Find Cap/Tran Violations
# Summary of Setup/Hold Violations
report_constraints -all_violators > tc_all_viol.rpt
# Clock Skew
report_clock_timing -type skew -verbose > tc_clockSkew.rpt
exit
Answer:
PrimeTime is a full chip static analysis tool that can fully analyze a multimillion gate ASIC in a short
amount of time.
2) What files are required for PrimeTime to run?
Answer:
PrimeTime needs four types of files before you can run it:
1. Netlist file: Verilog, VHDL, EDIF
2. Delay file: SPEF(standard parasitic format, it's from STARRC or place&route tool), SPF, SDF(standard delay format)
3. Library file: DB ( From library vendors)
4. Constrains file: Synopsys Design Constraints(SDC) include 3 min requirement, clock, input delay and output delay
3) Can I use script in PrimeTime?
Answer: Yes, you should use tcl( Tool command language) whenever possible.
4) What PrimeTime check?
Answer:
PrimeTime will check the following violations:
1. Setup violations: The logic is too slow compare to the clock.
With that in mind there are several things a designer can do to fix the setup violations.
- Reduce the amount of buffering in the path.
- Replace buffers with 2 inverters place farther apart
- Reduce larger than normal capacitance on a book’s output pin
- Increase the size of books to decrease the delay through the book.
- Make sure clock uncertainty is not to large for the technology library that you
are using. - Reduce clock speed. This is a poor design technique and should be used as a
last resort.
To fix hold violations in the design, the designer needs to simply add more delay
to the data path. This can be done by
- Adding buffers/inverter pairs/delay cells to the data path.
- Decreasing the size of certain books in the data path. It is better to reduce the books closer to the capture flip flop because there is less likely hood of affecting other paths and causing new errors.
- Add more capacitance to the output pin of books with light capacitance.
the chip is made, more there is nothing that can be done post fabrication to fix hold problems unlike setup violation where the clock speed can be reduced.
3. Transition Violations:
When a signal takes too long transiting from one logic level to another, a transition violation is reported. The violation is a function of the node resistance and capacitance.
The designer has two simple solutions to fix the transitions violations.
- Increase the drive capacity of the book to increase the voltage swing or decrease the capacitance and resistance by moving the source gate closer to sink gate.
- Increase the width of the route at the violation instance pin. This will decrease the resistance of the route and fix the transition violation
The capacitance on a node is a combination of the fan-out of the output pin and
the capacitance of the net. This check ensures that the device does not drive more
capacitance than the device is characterized for.
- The violation can be removed by increasing the drive strength of the book
- By buffering the some of the fan-out paths to reduce the capacitance seen by the output pin.
5) What conditions are used to check setup violation?
Answer:
WorstCase => setup violations
BestCase => hold violations
We use the worst case delay when testing for setup violations and then we use the best case delay when testing for hold violations.
6) How to run PrimeTime in the unix?
[Linux] user@gmu>> pt_shell –f pt_script.tcl |& tee pt.log
Here are the sample PrimeTime script :
A total of three scripts must be created, one for each timing corner.
# ------------------------------------------------------------
# Library Declarations.
# ------------------------------------------------------------
set search_path ". /proj/timing/etc"
set link_path "*"
lappend link_path "stdCell_tt.db"
# ------------------------------------------------------------
# Read in Design
# ------------------------------------------------------------
# Read in netlist
read_file -f verilog top_level.v
# Define top level in the hierarchy
current_design "top_level"
# Combine verilog and db files and identify any errors.
link_design
# Read in SPEF file
read_parasitics -quiet -format SPEF top_level.spef.gz
# ------------------------------------------------------------
# Apply Constraints
# ------------------------------------------------------------
# Read in timing constraits
read_sdc -echo top_level.sdc
# Propagate clocks and add uncertainty to setup/hold calculations
set_propagated_clock [all_clocks]
set_clock_uncertainty 0.2 [all_clocks]
21
# ------------------------------------------------------------
# Time
# ------------------------------------------------------------
set_operating_conditions -min WORST -max WORST
# Register to Register
report_timing -from [all_registers -clock_pins] \
-to [all_registers -data_pins] -delay_type max \
-path_type full_clock –nosplit \
-max_paths 1 -nworst 1 \
-trans -cap -net > tc_reg2reg_setup.rpt
report_timing -from [all_registers -clock_pins] \
-to [all_registers -data_pins] -delay_type min \
-path_type full_clock –nosplit \
-max_paths 1 -nworst 1 \
-trans -cap -net > tc_reg2reg_hold.rpt
# Register to Out
report_timing -from [all_registers -clock_pins] \
-to [all_outputs] -delay_type max \
-path_type full_clock –nosplit \
-max_paths 1 -nworst 1 \
-trans -cap -net > tc_reg2out_setup.rpt
report_timing -from [all_registers -clock_pins] \
-to [all_outputs] -delay_type min \
-path_type full_clock –nosplit \
-max_paths 1 -nworst 1 \
-trans -cap -net > tc_reg2out_hold.rpt
# In to Register
report_timing -from [all_inputs]
-to [all_registers -data_pins] \
-delay_type max \
-path_type full_clock –nosplit \
-max_paths 1 -nworst 1 -trans \
–cap -net > tc_in2reg_setup.rpt
report_timing -from [all_inputs] \
-to [all_registers -data_pins] \
-delay_type min -path_type full_clock \
-nosplit -max_paths 1 -nworst 1 \
-trans -cap -net > tc_in2reg_hold.rpt
# All Violators – Find Cap/Tran Violations
# Summary of Setup/Hold Violations
report_constraints -all_violators > tc_all_viol.rpt
# Clock Skew
report_clock_timing -type skew -verbose > tc_clockSkew.rpt
exit
Thursday, January 28, 2010
Design Constraints and Synthesis Questions
What are the various Design constraints used while performing Synthesis for a design?
Ans:
Synopsys Design Constraints (SDC) is a standard time file format for the synthesis and prime time.
They are 3 basic requirements for the SDC files:
Clock, input delay and output delays.
There are 4 timing path:
Register to register
input to register
register to output
input and output
1. Create the clocks (frequency, duty-cycle).
e.g.
create_clock -period 100 clk
create_clock -period 100 -waveform {0 50} [get_ports {clk}]
2. Define the transition-time requirements for the input-ports
e.g.
set_max_path_delay delay_value
3. Specify the load values for the output ports
set_load [expr 5 * [load_of $REFLIB/$DFFCELL/$DFFCELL_IN_PIN]] [all_outputs]
4. For the inputs and the output specify the delay values(input delay and ouput delay), which are already consumed by the neighbour chip.
e.g.
set_output_delay [-add_delay] -clock [-clock_fall] [-fall] [-max] [-min]
[-reference_pin] [-rise] [-source_latency_included]
set_output_delay -clock clk 0.5 [all_outputs]
set_input_delay [-add_delay] -clock [-clock_fall] [-fall] [-max] [-min]
[-reference_pin] [-rise] [-source_latency_included]
set_input_delay -clock clk 1.5 [get_ports myin*]
set_input_to_register_delay [-from inp_port];
set_input_to_register_delay 22 -from I*;
set_register_to_output_delay -to out_port;
5. Specify the case-setting (in case of a mux) to report the timing to a specific paths.
6. Specify the false-paths in the design
e.g.
set_false_path [-from from_port] [-through any_port] [-to to_port];
set_false_path -from resetd -through const2/*;
7. Specify the multi-cycle paths in the design.
e.g.
set_multicycle_path -from reg_port [-through_ any_port] [-to_port];
set_multicycle_path 2 -from /us/u1/dff*.q -to /u4/mem1/*.D";
8. Specify the clock-uncertainity values(w.r.t jitter and the margin values for setup/hold).
e.g.
set_clock_uncertainty [-add] [-fall_from] [-fall_to ]
[-from] [-hold] [-rise_from ] [-rise_to ]
[-setup] [-to]
set_clock_uncertainty -setup -rise_from clk1 -fall_to clk2 200ps
set_clock_uncertainty 0.3 [get_clocks clk]
9. Specify few verilog constructs which are not supported by the synthesis tool.
Sample Sdc files
mips32.s0.tcl: (constraints)
echo "** LOG(mips32.s0.tcl): SCENARIO (S0)"
set PERIOD 10 ;# 10 ns clock period -> 100 MHz max
set INPUT_DELAY 1.0
set OUTPUT_DELAY 1.0
set CLOCK_LATENCY 1.5
set MIN_TO_DELAY 1.0
set MAX_TRANSITION 0.5
# Preserve all heirarchy (set to true when RTL is in development)
set NO_UNGROUP false
echo "** LOG(mips32.s0.tcl): S0 PERIOD: ${PERIOD}"
# Clock basics
# Set clk period
create_clock -name "clk" -period $PERIOD [get_port clk]
# Set clk latency: time it takes for clk signal to get from source to FF sync pin.
set_clock_latency $CLOCK_LATENCY [get_clocks clk]
# Set clk uncertainity (jitter/skew): maximum time difference between two pins on
# a chip receiving the same clk signal
set_clock_uncertainty 0.3 [get_clocks clk]
# Set clk transition: time for clk to go 0->1 or 1->0
set_clock_transition 0.4 [get_clocks clk]
# Grouping clk/inputs/outputs for better optimization
group_path -name CLK -to clk
group_path -name INPUTS -through [all_inputs]
group_path -name OUTPUTS -to [all_outputs]
# Set I/O names
set INPUTPORTS [remove_from_collection [all_inputs] [get_ports clk]]
set OUTPUTPORTS [all_outputs]
# Set delay constraints on I/O boundaries
set_input_delay -clock "clk" -max $INPUT_DELAY $INPUTPORTS
set_input_delay -clock "clk" -min $MIN_TO_DELAY $INPUTPORTS
set_output_delay -clock "clk" -max $OUTPUT_DELAY $OUTPUTPORTS
set_output_delay -clock "clk" -min $MIN_TO_DELAY $OUTPUTPORTS
# Set the load and driving cell
set REFLIB [file rootname $TARGET_LIBRARY_FILES]
set DFFCELL "DFFARX1"
set DFFCELL_IN_PIN "D"
set DFFCELL_OUT_PIN "Q"
# Set maximum load to be 5X the input capacitance of a DFFARX1 cell
set_load [expr 5 * [load_of $REFLIB/$DFFCELL/$DFFCELL_IN_PIN]] [all_outputs]
# Set a DFF flip flop as the driving cell for all inputs (pipelined stages)
set_driving_cell -library $REFLIB -lib_cell $DFFCELL -pin $DFFCELL_OUT_PIN [all_inputs]
# Driving cell does not drive clk so remove it
remove_driving_cell [get_ports clk]
# Set maximum transition time of any net in design to be 1 ns.
set_max_transition $MAX_TRANSITION [current_design]
# Set the maximum capacitance on any net in the design to be 1 pF.
set_max_capacitance 1.0 [current_design]
# Set maximum fanout of any net in the design
set_max_fanout 20 [current_design]
# Minimize the area
set_max_area 0
Sample Design Compiler Synthesis script
common-setup.tcl:
Name of top-level design
set DESIGN_NAME "mips32"
# Set Design Path
set DESIGN_PATH [file normalize ~/cad/mips32]
# Aboslute path prefix variable for library/design data. Use this variable to
# prefix the common absolute path to the common variables defined
# below. Absolute paths are mandatory are mandary for heirarchical RM flow.
set DESIGN_REF_DATA_PATH "${DESIGN_PATH}/ref"
# List of hierarchical block design names "DesignA DesignB" ...
set HIERARCHICAL_DESIGNS ""
# List of hierarchical block cell instance names "u_DesignA u_DesignB" ...
set HIERARCHICAL_CELLS ""
# Additional search path to be added to the default search path
set ADDITIONAL_SEARCH_PATH "${DESIGN_PATH} \
${DESIGN_REF_DATA_PATH}/icons \
${DESIGN_REF_DATA_PATH}/itf \
${DESIGN_REF_DATA_PATH}/models \
${DESIGN_REF_DATA_PATH}/plib \
${DESIGN_REF_DATA_PATH}/tech \
${DESIGN_REF_DATA_PATH}/tluplus"
# Target libraries
set TARGET_LIBRARY_FILES "saed90nm_typ.db"
# Symbol library
set SYMBOL_LIBRARY_FILES "saed90nm.sdb"
# Extra link logical libraries not included in TARGET_LIBRARY_FILES
set ADDITIONAL_LINK_LIB_FILES ""
# List of max/min library pairs
set MIN_LIBRARY_FILES "saed90nm_max.db saed90nm_min.db"
# Milkyway refere libraries (include IC compiler ILMs here)
set MW_REFERENCE_LIB_DIRS "${DESIGN_REF_DATA_PATH}/saed90nm_fr"
# Reference control file to define the MW reference libraries
set MW_REFERENCE_CONTROL_FILE ""
# Milkyway technology file
set TECH_FILE "${DESIGN_REF_DATA_PATH}/tech/saed90nm.tf"
# Mapping file for TLUplus
set MAP_FILE "saed90nm.map"
# Max/Min TLUplus file
set TLUPLUS_MAX_FILE "saed90nm_1p9m_1t_Cmax.tluplus"
set TLUPLUS_MIN_FILE "saed90nm_1p9m_1t_Cmin.tluplus"
# Names for power/ground nets
set MW_POWER_NET "VDD"
set MW_POWER_PORT "VDD"
set MW_GROUND_NET "VSS"
set MW_GROUND_PORT "VSS"
# Min/Max routing layer
set MIN_ROUTING_LAYER ""
set MAX_ROUTING_LAYER ""
# Tcl file with library modificatiosn for don't use
set LIBRARY_DONT_USE_FILE ""
# Multi-Voltage Common Variables
#
# Define the following MV common variables for the RM scripts for multi-voltage
# flows. Use as few or as many of the following definitions as needed by your
# design.
set PD1 "" ;# Name of power domain/voltage area 1
set PD1_CELLS "" ;# Instances to include in power domain/voltage area 1
set VA1_COORDINATES {} ;# Coordinates for voltage area 1
set MW_POWER_NET1 "VDD1" ;# Power net for voltage area 1
set MW_POWER_PORT1 "VDD" ;# Power port for voltage area 1
set PD2 "" ;# Name of power domain/voltage area 2
set PD2_CELLS "" ;# Instances to include in power domain/voltage area 2
set VA2_COORDINATES {} ;# Coordinates for voltage area 2
set MW_POWER_NET2 "VDD2" ;# Power net for voltage area 2
set MW_POWER_PORT2 "VDD" ;# Power port for voltage area 2
# Timestamp
sh date
# Apply the dc-setup.tcl to setup libraries, paths, variables, etc
source ./dc/dc-setup.tcl
# Design Compiler Reference Methodology Script for Top-Down Flow
# Add any additional variables here
# No additional flow variables are being recommended
# Setup for Formality verification: SVF should always be written to allow
# Formality verification for advanced optimizations
set_svf ${RESULTS_DIR}/${DESIGN_NAME}.mapped.svf
# Setup SAIF name mapping database: Include an RTL SAIF for better power
# optimizaiton and analysis
saif_map -start
# Read in the RTL design: read in either RTL source files or an elaborated
# design (DDC)
define_design_lib WORK -path ./work
analyze -format verilog ${RTL_SOURCE_FILES}
elaborate ${DESIGN_NAME}
write -hierarchy -format ddc -output ${RESULTS_DIR}/${DESIGN_NAME}.elab.ddc
# OR read an elaborated design from the same release. Using an elaborated design
# from an older release will not give best results.
#
# read_ddc ${DESIGN_NAME}.elab.ddc
# current_design ${DESIGN_NAME}
# Resolve design/modules references by linking design to logical libraries
link
# Apply logical design constraints
source ${DESIGN_NAME}.s0.tcl
# We can enable analysis and optimization for multiple clocks per register. To
# use this, we must constrain to remove false interactions between mutually
# exclusive clocks. This is needed to prevent unnecesasry analysis that can result
# in a significant runtime incrase with this feature enabled.
#
# For mips32, it is unnecessary since we have a single clock.
# set_clock_groups -physically_exlucive | -logically_exclusive | -asynchronous \
# -group {CLKA, CLKB} -group {CLKC, CLKD}
#
# set timing_enable_multiple_clocks_per_reg true
# Apply operating conditions on top level. Set min/max for delay analysis and
# typical for normal usage.
set_operating_conditions -max WORST \
-max_library [file rootname $max_library] \
-min BEST -min_library [file rootname $min_library]
set_operating_conditions TYPICAL
# Create default path groups: separating these paths can help improve optimization.
# Remove these path group settings if user path graoups have already been defined.
set ports_clock_root [get_ports [all_fanout -flat -clock_tree -level 0]]
group_path -name REGOUT -to [all_outputs]
group_path -name REGIN -from [remove_from_collection [all_inputs] $ports_clock_root]
group_path -name FEEDTHROUGH -from [remove_from_collection [all_inputs] $ports_clock_root] -to [all_outputs]
# Power optimization
# Clock gating setup
# Default clock_gating_style suits most designs. Change only if necessary.
# set_clock_gating_style ...
# Clock gate insertion is now performed during compile_ultra -gate_clock
# so insert_clock_gating is no longer recommended at this step.
# For better timing optimization of enable logic, clock latency for
# clock gating cells can be optionally specified.
# set_clock_gate_latency -clock -stage \
# -fanout_latency {fo_range1 latency_val1 fo_range2 latency_val2 ...}
# Apply power optimization constraints
# Include a SAIF file, if possible, for power optimization. If a SAIF file
# is not provided, the default toggle rate of 0.1 will be used for propagating
# switching activity.
# read_saif -auto_map_names -input ${DESIGN_NAME}.saif -instance < DESIGN_INSTANCE > -verbose
# Remove set_max_total_power power optimization constraint from scripts in 2008.09
# Enable both of the following settings for total power optimization
set_max_leakage_power 0
# set_max_dynamic_power 0
if {[shell_is_in_topographical_mode]} {
# Setting power constraints will automatically enable power prediction using clock tree estimation.
# If you are not setting any power constraints and you still want to report
# correlated power, you can use the following command to turn on power prediction.
set_power_prediction true
}
if {[shell_is_in_topographical_mode]} {
# Apply physical desigin constraints
# Optional: Floorplan information can be read in here if available.
# This is highly recommended for irregular floorplans.
#
# Floorplan constraints can be extracted from DEF files using
# extract_physical_constraints OR provided from Tcl commands.
#
# DEF is the recommended input format to maximize the use of the latest
# floorplan read capabilities of Design Compiler topographical mode.
# Specify ignored layers for routing to improve correlation
# Use the same ignored layers that will be used during place and route
if {${MIN_ROUTING_LAYER} != ""} {
set_ignored_layers -min_routing_layer ${MIN_ROUTING_LAYER}
}
if {${MAX_ROUTING_LAYER} != ""} {
set_ignored_layers -max_routing_layer ${MAX_ROUTING_LAYER}
}
report_ignored_layers
# If the macro names change after mapping and writing out the design due to
# ungrouping or Verilog change_names renaming, it may be necessary to translate
# the names to correspond to the cell names that exist before compile.
# During DEF constraint extraction, extract_physical_constraints automatically
# matches DEF names back to precompile names in memory using standard matching rules.
# Modify fuzzy_query_options if other characters are used for hierarchy separators
# or bus names.
# set_fuzzy_query_options -hierarchical_separators {/ _ .} \
# -bus_name_notations {[] __ ()} \
# -class {cell pin port net} \
# -show
# Note: The -site_row or -pre_route options are not needed to extract this info
# from the DEF file. These are extracted automatically and saved in DDC.
# Only use these options if you want this info to be included in the
# ASCII output from "extract_physical_constraints -output".
if {[file exists [which ${DESIGN_NAME}.def]]} {
extract_physical_constraints ${DESIGN_NAME}.def
}
# OR
# For Tcl constraints, the name matching feature must be explicitly enabled
# and will also use the set_fuzzy_query_options setttings. This should
# be turned off after the constraint read in order to minimize runtime.
# set fuzzy_matching_enabled true
# source -echo -verbose ${DESIGN_NAME}.physical_constraints.tcl
# set fuzzy_matching_enabled false
# Note: Include the -site_row or -pre_route options with either
# write_physical_constraints or report_physical_constraints if you also
# want to include these in the ASCII output files. Site rows and pre-routes
# are automatically extracted from the DEF and saved in the DDC even if these
# options are not specified.
# You can save the extracted constraints for fast loading next time.
# write_physical_constraints -output ${DESIGN_NAME}.physical_constraints.tcl
# Verify that all the desired physical constraints have been applied
report_physical_constraints > ${REPORTS_DIR}/${DESIGN_NAME}.physical_constraints.rpt
}
# Apply additional optimization constraints
# Prevent assignment statment in the Verilog netlist
set_fix_multiple_port_nets -all -buffer_constants
# Insert level-shifters on all clocks
set auto_insert_evel_shifters_on_clocks all
# Preserve subdesign interfaces
# NOTE; when design is matured, we can turn this off so it does heirarchical
# optimization by pushing subdesign constants (pins connected to logic 0/1) to
# the external environment and optimizing that.
#set compile_preserve_subdesign_interfaces true
# Write out all unconnected pins in verilog netlist
set verilogout_show_unconnected_pins true
# Fix hold-time violations on clock by slowing down data signals
set_fix_hold [get_clocks clk]
# Fix timing violations if not in topographical mode
if {![shell_is_in_topographical_mode]} {
set compile_top_all_paths true
}
# Compile the Design
#
# Recommended Options:
#
# -scan
# -gate_clock
# -retime
# -timing_high_effort_script
# -area_high_effort_script
# -congestion
# -num_cpus
#
# Use compile_ultra as your starting point. For test-ready compile, include
# the -scan option with the first compile and any subsequent compiles.
#
# Use -gate_clock to insert clock-gating logic during optimization. This
# is now the recommended methodology for clock gating.
#
# Use -retime to enable adapative retiming optimization for further timing
# benefit without any runtime or memory overhead.
#
# The -timing_high_effort_script or the -area_high_effort_script option
# may also be used to try and improve the optimization results at the tradeoff
# of some additional runtime.
#
# The -congestion option (topographical mode only) enables specialized optimizations that
# reduce routing related congestion during synthesis and scan compression insertion
# with DFT Compiler. Only enable congestion optimization if required.
# This option requires a license for Design Compiler Graphical.
#
# Use -num_cpus to enable multi-core optimization to improve runtime. Note
# that this feature has special usage and license requirements. See the following
# article for more info: https://solvnet.synopsys.com/retrieve/024947.html
if {[shell_is_in_topographical_mode]} {
# Use the "-check_only" option of "compile_ultra" to verify that your
# libraries and design are complete and that optimization will not fail
# in topographical mode. Use the same options as will be used in compile_ultra.
compile_ultra -check_only
}
if {$NO_UNGROUP} {
compile_ultra -gate_clock -area_high_effort_script -no_autoungroup -retime
} else {
compile_ultra -gate_clock -area_high_effort_script -retime
}
# Write Out Final Design and Reports
#
# .ddc: Recommended binary format used for subsequent Design Compiler sessions
# Milkyway: Recommended binary format for IC Compiler
# .v : Verilog netlist for ASCII flow (Formality, PrimeTime, VCS)
# .spef: Topographical mode parasitics for PrimeTime
# .sdf: SDF backannotated topographical mode timing for PrimeTime
# .sdc: SDC constraints for ASCII flow
#
change_names -rules verilog -hierarchy
# Check the design for consistency
check_design
# Write and close SVF file and make it available for immediate use
set_svf off
# Write out design
write -format ddc -hierarchy -output ${RESULTS_DIR}/${DESIGN_NAME}.mapped.ddc
write -f verilog -hierarchy -output ${RESULTS_DIR}/${DESIGN_NAME}.mapped.v
# Write out design data
if {[shell_is_in_topographical_mode]} {
# Note: Include the -site_row or -pre_route options with write_physical_constraints
# if you also want to include these in the ASCII output files. Site rows and pre-routes
# are automatically extracted from the DEF and saved in the DDC even if these
# options are not specified.
write_physical_constraints -output ${RESULTS_DIR}/${DESIGN_NAME}.mapped.physical_constraints.tcl
# Write parasitics data for static timing analysis
write_parasitics -output ${RESULTS_DIR}/${DESIGN_NAME}.mapped.spef
# Write SDF back annotation data from DCT placment for static timing analysis
write_sdf ${RESULTS_DIR}/${DESIGN_NAME}.mapped.sdf
# Do not write out net RC info onto SDC
set write_sdc_output_lumped_net_capacitance false
set write_sdc_output_net_resistance false
}
write_sdc -nosplit ${RESULTS_DIR}/${DESIGN_NAME}.mapped.sdc
# If SAIF is used, write out SAIF name mapping file for PrimeTime-PX
saif_map -type ptpx -write_map ${RESULTS_DIR}/${DESIGN_NAME}.mapped.SAIF.namemap
# Generate final reports - qor, timing, area, congestion, power, clock gating
report_qor > ${REPORTS_DIR}/${DESIGN_NAME}.mapped.qor.rpt
report_timing -nworst 10 -transition_time -nets -attributes -nosplit > ${REPORTS_DIR}/${DESIGN_NAME}.mapped.timing.rpt
report_hierarchy -nosplit > ${REPORTS_DIR}/${DESIGN_NAME}.mapped.hierarchy.rpt
report_resources -nosplit -hierarchy > ${REPORTS_DIR}/${DESIGN_NAME}.mapped.resources.rpt
report_constraint > ${REPORTS_DIR}/${DESIGN_NAME}.mapped.constraints.rpt
if {[shell_is_in_topographical_mode]} {
report_area -physical -nosplit > ${REPORTS_DIR}/${DESIGN_NAME}.mapped.area.rpt
# report_congestion (topographical mode only) reports estimated routing related
# congestion after topographical mode synthesis. This command requires a
# license for Design Compiler Graphical.
# report_congestion > ${REPORTS_DIR}/${DESIGN_NAME}.mapped.congestion.rpt
} else {
report_area -nosplit > ${REPORTS_DIR}/${DESIGN_NAME}.mapped.area.rpt
}
# Use SAIF file for power analysis
#read_saif -auto_map_names -input ${DESIGN_NAME}.saif -instance < DESIGN_INSTANCE > -verbose
report_power -nosplit > ${REPORTS_DIR}/${DESIGN_NAME}.mapped.power.rpt
report_clock_gating -nosplit > ${REPORTS_DIR}/${DESIGN_NAME}.mapped.clock_gating.rpt
# Write the shell command script to save current settings
write_script -out ${RESULTS_DIR}/${DESIGN_NAME}.script
# Write out Milkyway Design for Top-Down Flow
# NOTE: This should be the last step in the script
if {[shell_is_in_topographical_mode]} {
write_milkyway -overwrite -output ${DESIGN_NAME}_DCT
}
# Timestamp
sh date
# Terminate
exit
dc-setup.tcl
# Source the file that is common to ALL Synopsys tools to setup commmon variables
source common-setup.tcl
# Setup variables: Portions of the dc_setup.tcl may be used by other tools, so
# do check for DC only commands
if {$synopsys_program_name == "dc_shell"} {
# Change alib_library_analysis_path to point to a centeral cache of analyzed
# libraries to save some runtime and disk space. The following setting only
# reflects the default value and shoudl be changed to a central location for
# best results.
set alib_library_analysis_path .
# Add any other DC variables here
}
# List of source files to read if reading from RTL
set RTL_SOURCE_FILES "${DESIGN_PATH}/src/mips32.v";
# The following directories are created and used by DC scripts to direct the
# location of the output files
set REPORTS_DIR "syn-reports"
set RESULTS_DIR "syn-results"
set LOG "syn-log"
file mkdir ${REPORTS_DIR}
file mkdir ${RESULTS_DIR}
file mkdir ${LOG}
# Library Setup: Define all the library variables shared by all the front-end
# tools. It is designed to work with the settings in common-setup.tcl without
# any additional modification.
set search_path ". ${DESIGN_PATH}/synopsys/syn \
${DESIGN_PATH}/synopsys/syn/dc \
${ADDITIONAL_SEARCH_PATH} $search_path"
# Milkyway variable settings: make sure to define the variables mw_logic1_net,
# mw_logic0_net and mw_design_library as they are need by write_milkway command.
set mw_logic1_net ${MW_POWER_NET}
set mw_logic0_net ${MW_GROUND_NET}
set mw_reference_library ${MW_REFERENCE_LIB_DIRS}
set mw_design_library ${DESIGN_NAME}_lib
set mw_site_name_mapping [list CORE unit Core unit core unit]
# The remainder of the seutp should only be performed in Design Compiler
if {$synopsys_program_name == "dc_shell"} {
# Include all libraries for multi-Vth leakage power optimization
set target_library ${TARGET_LIBRARY_FILES}
set symbol_library ${SYMBOL_LIBRARY_FILES}
set synthetic_library dw_foundation.sldb
set link_library "* $target_library $ADDITIONAL_LINK_LIB_FILES $synthetic_library"
# Set min libraries if they exist
foreach {max_library min_library} $MIN_LIBRARY_FILES {
set_min_library $max_library -min_version $min_library
}
# If in topological mode, create/open milkway library and setup TLU+ files for
# RC extraction
if {[shell_is_in_topographical_mode]} {
# Only create new Milkyway design library if it doesn't already exist
if {![file isdirectory $mw_design_library]} {
create_mw_lib -technology $TECH_FILE \
-mw_reference_library $mw_reference_library $mw_design_library \
-hier_separator {/}
} else {
# If Milkyway design library already exists, ensure that is consistent with
# specified Milkyway reference libraries
set_mw_lib_reference $mw_design_library -mw_reference_library $mw_reference_library
}
open_mw_lib $mw_design_library
check_library
set_tlu_plus_file -max_tluplus $TLUPLUS_MAX_FILE \
-min_tluplus $TLUPLUS_MIN_FILE \
-tech2itf_map $MAP_FILE
check_tlu_plus_files
}
# Library modifications: Apply library modifications here after the
# libraries are loaded.
if {[file exists [which ${LIBRARY_DONT_USE_FILE}]]} {
source -echo ${LIBRARY_DONT_USE_FILE}
}
}
dc.tcl:
# Timestamp
sh date
# Apply the dc-setup.tcl to setup libraries, paths, variables, etc
source ./dc/dc-setup.tcl
# Synopsys auto setup mode
set synopsys_auto_setup true
# Note: The Synopsys Auto Setup mode is less conservative than the Formality
# default mode, and is more likely to result in a successful verification
# out-of-the-box.
#
# Using the Setting this variable will change the default values of the variables
# listed here below. You may change any of these variables back to their default
# settings to be more conservative. Uncomment the appropriate lines below to
# revert back to their default settings:
# set hdlin_ignore_parallel_case true
# set hdlin_ignore_full_case true
# set verification_verify_directly_undriven_output true
# set hdlin_ignore_embedded_configuration false
# set svf_ignore_unqualified_fsm_information true
# Other variables with changed default values are described in the next few sections.
# The Synopsys Auto Setup mode sets undriven signals in the reference design to "0" similar to DC.
# Undriven signals in the implementation design are set to "X".
# Uncomment the next line to revert back to the more conservative default setting:
set verification_set_undriven_signals BINARY:X
# The Synopsys Auto Setup mode will produce warning messages, not error messages,
# when Formality encounters potential differences between simulation and synthesis.
# Uncomment the next line to revert back to the more conservative default setting:
set hdlin_error_on_mismatch_message true
# The Synopsys Auto Setup mode, along with the SVF file, will appropriately
# set the clock-gating variable. Otherwise, the user will need to notify
# Formality of clock-gating by uncommenting the next line:
# set verification_clock_gate_hold_mode any
# Set this variable ONLY if your design contains instantiated DW or function-inferred DW
# set hdlin_dwroot "" ;# Enter the pathname to the top-level of the DC tree
# If the design has missing blocks or missing components in both the
# reference and implementation designs, uncomment the following variable
# so that Formality can complete linking each design:
# set hdlin_unresolved_modules black_box
# Set SVF file to read
set_svf ${RESULTS_DIR}/${DESIGN_NAME}.mapped.svf
# Read in libraries
foreach tech_lib "${TARGET_LIBRARY_FILES} ${ADDITIONAL_LINK_LIB_FILES}" {
read_db -technology_library $tech_lib
}
# Read in the reference (original) design as verilog/vhdl source
read_verilog -r ${RTL_SOURCE_FILES} -work_library WORK
# Set reference design
set_top r:/WORK/${DESIGN_NAME}
# Read in the mapped design
# For verilog
# read_verilog -i ${RESULTS_DIR}/${DESIGN_NAME}.mapped.v
# For DDC
read_ddc -i ${RESULTS_DIR}/${DESIGN_NAME}.mapped.ddc
# Or Milkyway
# read_milkyway -i -libname ${mw_design_library} -cell_name ${DESIGN_NAME}_DCT ${mw_reference_library}
# Set implementation design
set_top i:/WORK/${DESIGN_NAME}
# Or for Milkyway
# set_top i:/${mw_design_library}/${DESIGN_NAME}
# Configure constant ports. When using the Synopsys Auto Setup mode,
# the SVF file will convey information automatically to Formality about
# how to disable scan.
#
# Otherwise, manually define those ports whose inputs should be assumed constant
# during verification.
#
# Example command format:
#
# set_constant -type port i:/WORK/$DESIGN_NAME/
# Match compare points and report unmatched points
match
report_unmatched_points > ${REPORTS_DIR}/${DESIGN_NAME}.fmv_unmatched_points.rpt
# Verify and report
if {![verify]} {
save_session -replace ${REPORTS_DIR}/${DESIGN_NAME}
report_failing_points > ${REPORTS_DIR}/${DESIGN_NAME}.fmv_failing_points.rpt
report_aborted > ${REPORTS_DIR}/${DESIGN_NAME}.fmv_aborted_points.rpt
}
# Timestamp
sh date
# Terminate
exit
Ans:
Synopsys Design Constraints (SDC) is a standard time file format for the synthesis and prime time.
They are 3 basic requirements for the SDC files:
Clock, input delay and output delays.
There are 4 timing path:
Register to register
input to register
register to output
input and output
1. Create the clocks (frequency, duty-cycle).
e.g.
create_clock -period 100 clk
create_clock -period 100 -waveform {0 50} [get_ports {clk}]
2. Define the transition-time requirements for the input-ports
e.g.
set_max_path_delay delay_value
3. Specify the load values for the output ports
set_load [expr 5 * [load_of $REFLIB/$DFFCELL/$DFFCELL_IN_PIN]] [all_outputs]
4. For the inputs and the output specify the delay values(input delay and ouput delay), which are already consumed by the neighbour chip.
e.g.
set_output_delay [-add_delay] -clock
[-reference_pin
set_output_delay -clock clk 0.5 [all_outputs]
set_input_delay [-add_delay] -clock
[-reference_pin
set_input_delay -clock clk 1.5 [get_ports myin*]
set_input_to_register_delay
set_input_to_register_delay 22 -from I*;
set_register_to_output_delay
5. Specify the case-setting (in case of a mux) to report the timing to a specific paths.
6. Specify the false-paths in the design
e.g.
set_false_path [-from from_port] [-through any_port] [-to to_port];
set_false_path -from resetd -through const2/*;
7. Specify the multi-cycle paths in the design.
e.g.
set_multicycle_path
set_multicycle_path 2 -from /us/u1/dff*.q -to /u4/mem1/*.D";
8. Specify the clock-uncertainity values(w.r.t jitter and the margin values for setup/hold).
e.g.
set_clock_uncertainty [-add] [-fall_from
[-from
[-setup] [-to
set_clock_uncertainty -setup -rise_from clk1 -fall_to clk2 200ps
set_clock_uncertainty 0.3 [get_clocks clk]
9. Specify few verilog constructs which are not supported by the synthesis tool.
Sample Sdc files
mips32.s0.tcl: (constraints)
echo "** LOG(mips32.s0.tcl): SCENARIO (S0)"
set PERIOD 10 ;# 10 ns clock period -> 100 MHz max
set INPUT_DELAY 1.0
set OUTPUT_DELAY 1.0
set CLOCK_LATENCY 1.5
set MIN_TO_DELAY 1.0
set MAX_TRANSITION 0.5
# Preserve all heirarchy (set to true when RTL is in development)
set NO_UNGROUP false
echo "** LOG(mips32.s0.tcl): S0 PERIOD: ${PERIOD}"
# Clock basics
# Set clk period
create_clock -name "clk" -period $PERIOD [get_port clk]
# Set clk latency: time it takes for clk signal to get from source to FF sync pin.
set_clock_latency $CLOCK_LATENCY [get_clocks clk]
# Set clk uncertainity (jitter/skew): maximum time difference between two pins on
# a chip receiving the same clk signal
set_clock_uncertainty 0.3 [get_clocks clk]
# Set clk transition: time for clk to go 0->1 or 1->0
set_clock_transition 0.4 [get_clocks clk]
# Grouping clk/inputs/outputs for better optimization
group_path -name CLK -to clk
group_path -name INPUTS -through [all_inputs]
group_path -name OUTPUTS -to [all_outputs]
# Set I/O names
set INPUTPORTS [remove_from_collection [all_inputs] [get_ports clk]]
set OUTPUTPORTS [all_outputs]
# Set delay constraints on I/O boundaries
set_input_delay -clock "clk" -max $INPUT_DELAY $INPUTPORTS
set_input_delay -clock "clk" -min $MIN_TO_DELAY $INPUTPORTS
set_output_delay -clock "clk" -max $OUTPUT_DELAY $OUTPUTPORTS
set_output_delay -clock "clk" -min $MIN_TO_DELAY $OUTPUTPORTS
# Set the load and driving cell
set REFLIB [file rootname $TARGET_LIBRARY_FILES]
set DFFCELL "DFFARX1"
set DFFCELL_IN_PIN "D"
set DFFCELL_OUT_PIN "Q"
# Set maximum load to be 5X the input capacitance of a DFFARX1 cell
set_load [expr 5 * [load_of $REFLIB/$DFFCELL/$DFFCELL_IN_PIN]] [all_outputs]
# Set a DFF flip flop as the driving cell for all inputs (pipelined stages)
set_driving_cell -library $REFLIB -lib_cell $DFFCELL -pin $DFFCELL_OUT_PIN [all_inputs]
# Driving cell does not drive clk so remove it
remove_driving_cell [get_ports clk]
# Set maximum transition time of any net in design to be 1 ns.
set_max_transition $MAX_TRANSITION [current_design]
# Set the maximum capacitance on any net in the design to be 1 pF.
set_max_capacitance 1.0 [current_design]
# Set maximum fanout of any net in the design
set_max_fanout 20 [current_design]
# Minimize the area
set_max_area 0
Sample Design Compiler Synthesis script
common-setup.tcl:
Name of top-level design
set DESIGN_NAME "mips32"
# Set Design Path
set DESIGN_PATH [file normalize ~/cad/mips32]
# Aboslute path prefix variable for library/design data. Use this variable to
# prefix the common absolute path to the common variables defined
# below. Absolute paths are mandatory are mandary for heirarchical RM flow.
set DESIGN_REF_DATA_PATH "${DESIGN_PATH}/ref"
# List of hierarchical block design names "DesignA DesignB" ...
set HIERARCHICAL_DESIGNS ""
# List of hierarchical block cell instance names "u_DesignA u_DesignB" ...
set HIERARCHICAL_CELLS ""
# Additional search path to be added to the default search path
set ADDITIONAL_SEARCH_PATH "${DESIGN_PATH} \
${DESIGN_REF_DATA_PATH}/icons \
${DESIGN_REF_DATA_PATH}/itf \
${DESIGN_REF_DATA_PATH}/models \
${DESIGN_REF_DATA_PATH}/plib \
${DESIGN_REF_DATA_PATH}/tech \
${DESIGN_REF_DATA_PATH}/tluplus"
# Target libraries
set TARGET_LIBRARY_FILES "saed90nm_typ.db"
# Symbol library
set SYMBOL_LIBRARY_FILES "saed90nm.sdb"
# Extra link logical libraries not included in TARGET_LIBRARY_FILES
set ADDITIONAL_LINK_LIB_FILES ""
# List of max/min library pairs
set MIN_LIBRARY_FILES "saed90nm_max.db saed90nm_min.db"
# Milkyway refere libraries (include IC compiler ILMs here)
set MW_REFERENCE_LIB_DIRS "${DESIGN_REF_DATA_PATH}/saed90nm_fr"
# Reference control file to define the MW reference libraries
set MW_REFERENCE_CONTROL_FILE ""
# Milkyway technology file
set TECH_FILE "${DESIGN_REF_DATA_PATH}/tech/saed90nm.tf"
# Mapping file for TLUplus
set MAP_FILE "saed90nm.map"
# Max/Min TLUplus file
set TLUPLUS_MAX_FILE "saed90nm_1p9m_1t_Cmax.tluplus"
set TLUPLUS_MIN_FILE "saed90nm_1p9m_1t_Cmin.tluplus"
# Names for power/ground nets
set MW_POWER_NET "VDD"
set MW_POWER_PORT "VDD"
set MW_GROUND_NET "VSS"
set MW_GROUND_PORT "VSS"
# Min/Max routing layer
set MIN_ROUTING_LAYER ""
set MAX_ROUTING_LAYER ""
# Tcl file with library modificatiosn for don't use
set LIBRARY_DONT_USE_FILE ""
# Multi-Voltage Common Variables
#
# Define the following MV common variables for the RM scripts for multi-voltage
# flows. Use as few or as many of the following definitions as needed by your
# design.
set PD1 "" ;# Name of power domain/voltage area 1
set PD1_CELLS "" ;# Instances to include in power domain/voltage area 1
set VA1_COORDINATES {} ;# Coordinates for voltage area 1
set MW_POWER_NET1 "VDD1" ;# Power net for voltage area 1
set MW_POWER_PORT1 "VDD" ;# Power port for voltage area 1
set PD2 "" ;# Name of power domain/voltage area 2
set PD2_CELLS "" ;# Instances to include in power domain/voltage area 2
set VA2_COORDINATES {} ;# Coordinates for voltage area 2
set MW_POWER_NET2 "VDD2" ;# Power net for voltage area 2
set MW_POWER_PORT2 "VDD" ;# Power port for voltage area 2
# Timestamp
sh date
# Apply the dc-setup.tcl to setup libraries, paths, variables, etc
source ./dc/dc-setup.tcl
# Design Compiler Reference Methodology Script for Top-Down Flow
# Add any additional variables here
# No additional flow variables are being recommended
# Setup for Formality verification: SVF should always be written to allow
# Formality verification for advanced optimizations
set_svf ${RESULTS_DIR}/${DESIGN_NAME}.mapped.svf
# Setup SAIF name mapping database: Include an RTL SAIF for better power
# optimizaiton and analysis
saif_map -start
# Read in the RTL design: read in either RTL source files or an elaborated
# design (DDC)
define_design_lib WORK -path ./work
analyze -format verilog ${RTL_SOURCE_FILES}
elaborate ${DESIGN_NAME}
write -hierarchy -format ddc -output ${RESULTS_DIR}/${DESIGN_NAME}.elab.ddc
# OR read an elaborated design from the same release. Using an elaborated design
# from an older release will not give best results.
#
# read_ddc ${DESIGN_NAME}.elab.ddc
# current_design ${DESIGN_NAME}
# Resolve design/modules references by linking design to logical libraries
link
# Apply logical design constraints
source ${DESIGN_NAME}.s0.tcl
# We can enable analysis and optimization for multiple clocks per register. To
# use this, we must constrain to remove false interactions between mutually
# exclusive clocks. This is needed to prevent unnecesasry analysis that can result
# in a significant runtime incrase with this feature enabled.
#
# For mips32, it is unnecessary since we have a single clock.
# set_clock_groups -physically_exlucive | -logically_exclusive | -asynchronous \
# -group {CLKA, CLKB} -group {CLKC, CLKD}
#
# set timing_enable_multiple_clocks_per_reg true
# Apply operating conditions on top level. Set min/max for delay analysis and
# typical for normal usage.
set_operating_conditions -max WORST \
-max_library [file rootname $max_library] \
-min BEST -min_library [file rootname $min_library]
set_operating_conditions TYPICAL
# Create default path groups: separating these paths can help improve optimization.
# Remove these path group settings if user path graoups have already been defined.
set ports_clock_root [get_ports [all_fanout -flat -clock_tree -level 0]]
group_path -name REGOUT -to [all_outputs]
group_path -name REGIN -from [remove_from_collection [all_inputs] $ports_clock_root]
group_path -name FEEDTHROUGH -from [remove_from_collection [all_inputs] $ports_clock_root] -to [all_outputs]
# Power optimization
# Clock gating setup
# Default clock_gating_style suits most designs. Change only if necessary.
# set_clock_gating_style ...
# Clock gate insertion is now performed during compile_ultra -gate_clock
# so insert_clock_gating is no longer recommended at this step.
# For better timing optimization of enable logic, clock latency for
# clock gating cells can be optionally specified.
# set_clock_gate_latency -clock
# -fanout_latency {fo_range1 latency_val1 fo_range2 latency_val2 ...}
# Apply power optimization constraints
# Include a SAIF file, if possible, for power optimization. If a SAIF file
# is not provided, the default toggle rate of 0.1 will be used for propagating
# switching activity.
# read_saif -auto_map_names -input ${DESIGN_NAME}.saif -instance < DESIGN_INSTANCE > -verbose
# Remove set_max_total_power power optimization constraint from scripts in 2008.09
# Enable both of the following settings for total power optimization
set_max_leakage_power 0
# set_max_dynamic_power 0
if {[shell_is_in_topographical_mode]} {
# Setting power constraints will automatically enable power prediction using clock tree estimation.
# If you are not setting any power constraints and you still want to report
# correlated power, you can use the following command to turn on power prediction.
set_power_prediction true
}
if {[shell_is_in_topographical_mode]} {
# Apply physical desigin constraints
# Optional: Floorplan information can be read in here if available.
# This is highly recommended for irregular floorplans.
#
# Floorplan constraints can be extracted from DEF files using
# extract_physical_constraints OR provided from Tcl commands.
#
# DEF is the recommended input format to maximize the use of the latest
# floorplan read capabilities of Design Compiler topographical mode.
# Specify ignored layers for routing to improve correlation
# Use the same ignored layers that will be used during place and route
if {${MIN_ROUTING_LAYER} != ""} {
set_ignored_layers -min_routing_layer ${MIN_ROUTING_LAYER}
}
if {${MAX_ROUTING_LAYER} != ""} {
set_ignored_layers -max_routing_layer ${MAX_ROUTING_LAYER}
}
report_ignored_layers
# If the macro names change after mapping and writing out the design due to
# ungrouping or Verilog change_names renaming, it may be necessary to translate
# the names to correspond to the cell names that exist before compile.
# During DEF constraint extraction, extract_physical_constraints automatically
# matches DEF names back to precompile names in memory using standard matching rules.
# Modify fuzzy_query_options if other characters are used for hierarchy separators
# or bus names.
# set_fuzzy_query_options -hierarchical_separators {/ _ .} \
# -bus_name_notations {[] __ ()} \
# -class {cell pin port net} \
# -show
# Note: The -site_row or -pre_route options are not needed to extract this info
# from the DEF file. These are extracted automatically and saved in DDC.
# Only use these options if you want this info to be included in the
# ASCII output from "extract_physical_constraints -output".
if {[file exists [which ${DESIGN_NAME}.def]]} {
extract_physical_constraints ${DESIGN_NAME}.def
}
# OR
# For Tcl constraints, the name matching feature must be explicitly enabled
# and will also use the set_fuzzy_query_options setttings. This should
# be turned off after the constraint read in order to minimize runtime.
# set fuzzy_matching_enabled true
# source -echo -verbose ${DESIGN_NAME}.physical_constraints.tcl
# set fuzzy_matching_enabled false
# Note: Include the -site_row or -pre_route options with either
# write_physical_constraints or report_physical_constraints if you also
# want to include these in the ASCII output files. Site rows and pre-routes
# are automatically extracted from the DEF and saved in the DDC even if these
# options are not specified.
# You can save the extracted constraints for fast loading next time.
# write_physical_constraints -output ${DESIGN_NAME}.physical_constraints.tcl
# Verify that all the desired physical constraints have been applied
report_physical_constraints > ${REPORTS_DIR}/${DESIGN_NAME}.physical_constraints.rpt
}
# Apply additional optimization constraints
# Prevent assignment statment in the Verilog netlist
set_fix_multiple_port_nets -all -buffer_constants
# Insert level-shifters on all clocks
set auto_insert_evel_shifters_on_clocks all
# Preserve subdesign interfaces
# NOTE; when design is matured, we can turn this off so it does heirarchical
# optimization by pushing subdesign constants (pins connected to logic 0/1) to
# the external environment and optimizing that.
#set compile_preserve_subdesign_interfaces true
# Write out all unconnected pins in verilog netlist
set verilogout_show_unconnected_pins true
# Fix hold-time violations on clock by slowing down data signals
set_fix_hold [get_clocks clk]
# Fix timing violations if not in topographical mode
if {![shell_is_in_topographical_mode]} {
set compile_top_all_paths true
}
# Compile the Design
#
# Recommended Options:
#
# -scan
# -gate_clock
# -retime
# -timing_high_effort_script
# -area_high_effort_script
# -congestion
# -num_cpus
#
# Use compile_ultra as your starting point. For test-ready compile, include
# the -scan option with the first compile and any subsequent compiles.
#
# Use -gate_clock to insert clock-gating logic during optimization. This
# is now the recommended methodology for clock gating.
#
# Use -retime to enable adapative retiming optimization for further timing
# benefit without any runtime or memory overhead.
#
# The -timing_high_effort_script or the -area_high_effort_script option
# may also be used to try and improve the optimization results at the tradeoff
# of some additional runtime.
#
# The -congestion option (topographical mode only) enables specialized optimizations that
# reduce routing related congestion during synthesis and scan compression insertion
# with DFT Compiler. Only enable congestion optimization if required.
# This option requires a license for Design Compiler Graphical.
#
# Use -num_cpus to enable multi-core optimization to improve runtime. Note
# that this feature has special usage and license requirements. See the following
# article for more info: https://solvnet.synopsys.com/retrieve/024947.html
if {[shell_is_in_topographical_mode]} {
# Use the "-check_only" option of "compile_ultra" to verify that your
# libraries and design are complete and that optimization will not fail
# in topographical mode. Use the same options as will be used in compile_ultra.
compile_ultra -check_only
}
if {$NO_UNGROUP} {
compile_ultra -gate_clock -area_high_effort_script -no_autoungroup -retime
} else {
compile_ultra -gate_clock -area_high_effort_script -retime
}
# Write Out Final Design and Reports
#
# .ddc: Recommended binary format used for subsequent Design Compiler sessions
# Milkyway: Recommended binary format for IC Compiler
# .v : Verilog netlist for ASCII flow (Formality, PrimeTime, VCS)
# .spef: Topographical mode parasitics for PrimeTime
# .sdf: SDF backannotated topographical mode timing for PrimeTime
# .sdc: SDC constraints for ASCII flow
#
change_names -rules verilog -hierarchy
# Check the design for consistency
check_design
# Write and close SVF file and make it available for immediate use
set_svf off
# Write out design
write -format ddc -hierarchy -output ${RESULTS_DIR}/${DESIGN_NAME}.mapped.ddc
write -f verilog -hierarchy -output ${RESULTS_DIR}/${DESIGN_NAME}.mapped.v
# Write out design data
if {[shell_is_in_topographical_mode]} {
# Note: Include the -site_row or -pre_route options with write_physical_constraints
# if you also want to include these in the ASCII output files. Site rows and pre-routes
# are automatically extracted from the DEF and saved in the DDC even if these
# options are not specified.
write_physical_constraints -output ${RESULTS_DIR}/${DESIGN_NAME}.mapped.physical_constraints.tcl
# Write parasitics data for static timing analysis
write_parasitics -output ${RESULTS_DIR}/${DESIGN_NAME}.mapped.spef
# Write SDF back annotation data from DCT placment for static timing analysis
write_sdf ${RESULTS_DIR}/${DESIGN_NAME}.mapped.sdf
# Do not write out net RC info onto SDC
set write_sdc_output_lumped_net_capacitance false
set write_sdc_output_net_resistance false
}
write_sdc -nosplit ${RESULTS_DIR}/${DESIGN_NAME}.mapped.sdc
# If SAIF is used, write out SAIF name mapping file for PrimeTime-PX
saif_map -type ptpx -write_map ${RESULTS_DIR}/${DESIGN_NAME}.mapped.SAIF.namemap
# Generate final reports - qor, timing, area, congestion, power, clock gating
report_qor > ${REPORTS_DIR}/${DESIGN_NAME}.mapped.qor.rpt
report_timing -nworst 10 -transition_time -nets -attributes -nosplit > ${REPORTS_DIR}/${DESIGN_NAME}.mapped.timing.rpt
report_hierarchy -nosplit > ${REPORTS_DIR}/${DESIGN_NAME}.mapped.hierarchy.rpt
report_resources -nosplit -hierarchy > ${REPORTS_DIR}/${DESIGN_NAME}.mapped.resources.rpt
report_constraint > ${REPORTS_DIR}/${DESIGN_NAME}.mapped.constraints.rpt
if {[shell_is_in_topographical_mode]} {
report_area -physical -nosplit > ${REPORTS_DIR}/${DESIGN_NAME}.mapped.area.rpt
# report_congestion (topographical mode only) reports estimated routing related
# congestion after topographical mode synthesis. This command requires a
# license for Design Compiler Graphical.
# report_congestion > ${REPORTS_DIR}/${DESIGN_NAME}.mapped.congestion.rpt
} else {
report_area -nosplit > ${REPORTS_DIR}/${DESIGN_NAME}.mapped.area.rpt
}
# Use SAIF file for power analysis
#read_saif -auto_map_names -input ${DESIGN_NAME}.saif -instance < DESIGN_INSTANCE > -verbose
report_power -nosplit > ${REPORTS_DIR}/${DESIGN_NAME}.mapped.power.rpt
report_clock_gating -nosplit > ${REPORTS_DIR}/${DESIGN_NAME}.mapped.clock_gating.rpt
# Write the shell command script to save current settings
write_script -out ${RESULTS_DIR}/${DESIGN_NAME}.script
# Write out Milkyway Design for Top-Down Flow
# NOTE: This should be the last step in the script
if {[shell_is_in_topographical_mode]} {
write_milkyway -overwrite -output ${DESIGN_NAME}_DCT
}
# Timestamp
sh date
# Terminate
exit
dc-setup.tcl
# Source the file that is common to ALL Synopsys tools to setup commmon variables
source common-setup.tcl
# Setup variables: Portions of the dc_setup.tcl may be used by other tools, so
# do check for DC only commands
if {$synopsys_program_name == "dc_shell"} {
# Change alib_library_analysis_path to point to a centeral cache of analyzed
# libraries to save some runtime and disk space. The following setting only
# reflects the default value and shoudl be changed to a central location for
# best results.
set alib_library_analysis_path .
# Add any other DC variables here
}
# List of source files to read if reading from RTL
set RTL_SOURCE_FILES "${DESIGN_PATH}/src/mips32.v";
# The following directories are created and used by DC scripts to direct the
# location of the output files
set REPORTS_DIR "syn-reports"
set RESULTS_DIR "syn-results"
set LOG "syn-log"
file mkdir ${REPORTS_DIR}
file mkdir ${RESULTS_DIR}
file mkdir ${LOG}
# Library Setup: Define all the library variables shared by all the front-end
# tools. It is designed to work with the settings in common-setup.tcl without
# any additional modification.
set search_path ". ${DESIGN_PATH}/synopsys/syn \
${DESIGN_PATH}/synopsys/syn/dc \
${ADDITIONAL_SEARCH_PATH} $search_path"
# Milkyway variable settings: make sure to define the variables mw_logic1_net,
# mw_logic0_net and mw_design_library as they are need by write_milkway command.
set mw_logic1_net ${MW_POWER_NET}
set mw_logic0_net ${MW_GROUND_NET}
set mw_reference_library ${MW_REFERENCE_LIB_DIRS}
set mw_design_library ${DESIGN_NAME}_lib
set mw_site_name_mapping [list CORE unit Core unit core unit]
# The remainder of the seutp should only be performed in Design Compiler
if {$synopsys_program_name == "dc_shell"} {
# Include all libraries for multi-Vth leakage power optimization
set target_library ${TARGET_LIBRARY_FILES}
set symbol_library ${SYMBOL_LIBRARY_FILES}
set synthetic_library dw_foundation.sldb
set link_library "* $target_library $ADDITIONAL_LINK_LIB_FILES $synthetic_library"
# Set min libraries if they exist
foreach {max_library min_library} $MIN_LIBRARY_FILES {
set_min_library $max_library -min_version $min_library
}
# If in topological mode, create/open milkway library and setup TLU+ files for
# RC extraction
if {[shell_is_in_topographical_mode]} {
# Only create new Milkyway design library if it doesn't already exist
if {![file isdirectory $mw_design_library]} {
create_mw_lib -technology $TECH_FILE \
-mw_reference_library $mw_reference_library $mw_design_library \
-hier_separator {/}
} else {
# If Milkyway design library already exists, ensure that is consistent with
# specified Milkyway reference libraries
set_mw_lib_reference $mw_design_library -mw_reference_library $mw_reference_library
}
open_mw_lib $mw_design_library
check_library
set_tlu_plus_file -max_tluplus $TLUPLUS_MAX_FILE \
-min_tluplus $TLUPLUS_MIN_FILE \
-tech2itf_map $MAP_FILE
check_tlu_plus_files
}
# Library modifications: Apply library modifications here after the
# libraries are loaded.
if {[file exists [which ${LIBRARY_DONT_USE_FILE}]]} {
source -echo ${LIBRARY_DONT_USE_FILE}
}
}
dc.tcl:
# Timestamp
sh date
# Apply the dc-setup.tcl to setup libraries, paths, variables, etc
source ./dc/dc-setup.tcl
# Synopsys auto setup mode
set synopsys_auto_setup true
# Note: The Synopsys Auto Setup mode is less conservative than the Formality
# default mode, and is more likely to result in a successful verification
# out-of-the-box.
#
# Using the Setting this variable will change the default values of the variables
# listed here below. You may change any of these variables back to their default
# settings to be more conservative. Uncomment the appropriate lines below to
# revert back to their default settings:
# set hdlin_ignore_parallel_case true
# set hdlin_ignore_full_case true
# set verification_verify_directly_undriven_output true
# set hdlin_ignore_embedded_configuration false
# set svf_ignore_unqualified_fsm_information true
# Other variables with changed default values are described in the next few sections.
# The Synopsys Auto Setup mode sets undriven signals in the reference design to "0" similar to DC.
# Undriven signals in the implementation design are set to "X".
# Uncomment the next line to revert back to the more conservative default setting:
set verification_set_undriven_signals BINARY:X
# The Synopsys Auto Setup mode will produce warning messages, not error messages,
# when Formality encounters potential differences between simulation and synthesis.
# Uncomment the next line to revert back to the more conservative default setting:
set hdlin_error_on_mismatch_message true
# The Synopsys Auto Setup mode, along with the SVF file, will appropriately
# set the clock-gating variable. Otherwise, the user will need to notify
# Formality of clock-gating by uncommenting the next line:
# set verification_clock_gate_hold_mode any
# Set this variable ONLY if your design contains instantiated DW or function-inferred DW
# set hdlin_dwroot "" ;# Enter the pathname to the top-level of the DC tree
# If the design has missing blocks or missing components in both the
# reference and implementation designs, uncomment the following variable
# so that Formality can complete linking each design:
# set hdlin_unresolved_modules black_box
# Set SVF file to read
set_svf ${RESULTS_DIR}/${DESIGN_NAME}.mapped.svf
# Read in libraries
foreach tech_lib "${TARGET_LIBRARY_FILES} ${ADDITIONAL_LINK_LIB_FILES}" {
read_db -technology_library $tech_lib
}
# Read in the reference (original) design as verilog/vhdl source
read_verilog -r ${RTL_SOURCE_FILES} -work_library WORK
# Set reference design
set_top r:/WORK/${DESIGN_NAME}
# Read in the mapped design
# For verilog
# read_verilog -i ${RESULTS_DIR}/${DESIGN_NAME}.mapped.v
# For DDC
read_ddc -i ${RESULTS_DIR}/${DESIGN_NAME}.mapped.ddc
# Or Milkyway
# read_milkyway -i -libname ${mw_design_library} -cell_name ${DESIGN_NAME}_DCT ${mw_reference_library}
# Set implementation design
set_top i:/WORK/${DESIGN_NAME}
# Or for Milkyway
# set_top i:/${mw_design_library}/${DESIGN_NAME}
# Configure constant ports. When using the Synopsys Auto Setup mode,
# the SVF file will convey information automatically to Formality about
# how to disable scan.
#
# Otherwise, manually define those ports whose inputs should be assumed constant
# during verification.
#
# Example command format:
#
# set_constant -type port i:/WORK/$DESIGN_NAME/
# Match compare points and report unmatched points
match
report_unmatched_points > ${REPORTS_DIR}/${DESIGN_NAME}.fmv_unmatched_points.rpt
# Verify and report
if {![verify]} {
save_session -replace ${REPORTS_DIR}/${DESIGN_NAME}
report_failing_points > ${REPORTS_DIR}/${DESIGN_NAME}.fmv_failing_points.rpt
report_aborted > ${REPORTS_DIR}/${DESIGN_NAME}.fmv_aborted_points.rpt
}
# Timestamp
sh date
# Terminate
exit
Wednesday, January 27, 2010
CAM related Questions
1) What is CAM?
Content-addressable memory (CAM) is a special type of computer memory used in certain very high speed searching applications. It is also known as associative memory, associative storage, or associative array.
A CAM is designed such that the user supplies a data word and the CAM searches its entire memory to see if that data word is stored anywhere in it. If the data word is found, the CAM returns a list of one or more storage addresses where the word was found (and in some architectures, it also returns the data word, or other associated pieces of data). Thus, a CAM is the hardware embodiment of what in software terms would be called an associative array.
2) What is difference between TCAM and Binary CAM ?
Binary CAM is the simplest type of CAM which uses data search words comprised entirely of 1s and 0s. Ternary CAM allows a third matching state of "X" or "Don't Care" for one or more bits in the stored dataword, thus adding flexibility to the search. For example, a ternary CAM might have a stored word of "10XX0" which will match any of the four search words "10000", "10010", "10100", or "10110". The added search flexibility comes at an additional cost over binary CAM as the internal memory cell must now encode three possible states instead of the two of binary CAM. This additional state is typically implemented by adding a mask bit ("care" or "don't care" bit) to every memory cell.
3) What is associative array?
An associative array (also associative container, map, mapping, dictionary, finite map, and in query-processing an index or index file) is an abstract data type composed of a collection of unique keys and a collection of values, where each key is associated with one value (or set of values). The operation of finding the value associated with a key is called a lookup or indexing, and this is the most important operation supported by an associative array. The relationship between a key and its value is sometimes called a mapping or binding. For example, if the value associated with the key
Content-addressable memory (CAM) is a special type of computer memory used in certain very high speed searching applications. It is also known as associative memory, associative storage, or associative array.
A CAM is designed such that the user supplies a data word and the CAM searches its entire memory to see if that data word is stored anywhere in it. If the data word is found, the CAM returns a list of one or more storage addresses where the word was found (and in some architectures, it also returns the data word, or other associated pieces of data). Thus, a CAM is the hardware embodiment of what in software terms would be called an associative array.
2) What is difference between TCAM and Binary CAM ?
Binary CAM is the simplest type of CAM which uses data search words comprised entirely of 1s and 0s. Ternary CAM allows a third matching state of "X" or "Don't Care" for one or more bits in the stored dataword, thus adding flexibility to the search. For example, a ternary CAM might have a stored word of "10XX0" which will match any of the four search words "10000", "10010", "10100", or "10110". The added search flexibility comes at an additional cost over binary CAM as the internal memory cell must now encode three possible states instead of the two of binary CAM. This additional state is typically implemented by adding a mask bit ("care" or "don't care" bit) to every memory cell.
3) What is associative array?
An associative array (also associative container, map, mapping, dictionary, finite map, and in query-processing an index or index file) is an abstract data type composed of a collection of unique keys and a collection of values, where each key is associated with one value (or set of values). The operation of finding the value associated with a key is called a lookup or indexing, and this is the most important operation supported by an associative array. The relationship between a key and its value is sometimes called a mapping or binding. For example, if the value associated with the key
"bob" is 7, we say that our array maps "bob" to 7. Associative arrays are very closely related to the mathematical concept of a function with a finite domain. As a consequence, a common and important use of associative arrays is in memoization.
Network Questions & Answer
1) What's the OSI reference model?
OSI (Open System Interconnection) Reference Model is the systems that are open for coummunication with other systems.
They are 7 Layers:
Layer 1: Physical Layer
The physical layer is concerned with transmitting raw bits over a communication channel.
Layer 2: Data Link Layer
The main task of the data link layer is to take a raw transmission facility and transform it into a line that appears free of undetected transmission errors to the network layer.
Layer 3: Network Layer
The network layer is concerned with controlling the operation of the subnet. A key design issue is determining how packets are routed from source to destination. It included the table lookup, forwarding and other protocols to help routing packets.
Layer 4: Transport Layer
The basic function of the transport layer is to accept data from the session layer, split it up into smaller units if need be, pass these to the network layer, and ensure that the pieces all arrive correctly at the other end.
Layer 5: Session Layer
The session layer allows users on different machines to establish sessions between them. A session allows ordinary data transport , as does the transport layer, but it also provides enhanced service useful in some applications.
Layer 6: Presentation Layer
The presentation layer performs certain functions that are requested sufficiently often to warrant finding a general solution for them, rather than letting each user solve the problems.
Layer 7: Application Layer
The application layer contains a variety of protocols that are commonly needed.
What's the function of Network layer?
The Network Layer is Layer 3 of the seven-layer OSI model of computer networking.
The Network Layer is responsible for end-to-end (source to destination) packet delivery including routing through intermediate hosts, whereas the Data Link Layer is responsible for node-to-node (hop-to-hop) frame delivery on the same link.
The Network Layer provides the functional and procedural means of transferring variable length data sequences from a source to a destination host via one or more networks while maintaining the quality of service and error control functions.
Functions of the Network Layer include:
OSI (Open System Interconnection) Reference Model is the systems that are open for coummunication with other systems.
They are 7 Layers:
Layer 1: Physical Layer
The physical layer is concerned with transmitting raw bits over a communication channel.
Layer 2: Data Link Layer
The main task of the data link layer is to take a raw transmission facility and transform it into a line that appears free of undetected transmission errors to the network layer.
Layer 3: Network Layer
The network layer is concerned with controlling the operation of the subnet. A key design issue is determining how packets are routed from source to destination. It included the table lookup, forwarding and other protocols to help routing packets.
Layer 4: Transport Layer
The basic function of the transport layer is to accept data from the session layer, split it up into smaller units if need be, pass these to the network layer, and ensure that the pieces all arrive correctly at the other end.
Layer 5: Session Layer
The session layer allows users on different machines to establish sessions between them. A session allows ordinary data transport , as does the transport layer, but it also provides enhanced service useful in some applications.
Layer 6: Presentation Layer
The presentation layer performs certain functions that are requested sufficiently often to warrant finding a general solution for them, rather than letting each user solve the problems.
Layer 7: Application Layer
The application layer contains a variety of protocols that are commonly needed.
What's the function of Network layer?
The Network Layer is Layer 3 of the seven-layer OSI model of computer networking.
The Network Layer is responsible for end-to-end (source to destination) packet delivery including routing through intermediate hosts, whereas the Data Link Layer is responsible for node-to-node (hop-to-hop) frame delivery on the same link.
The Network Layer provides the functional and procedural means of transferring variable length data sequences from a source to a destination host via one or more networks while maintaining the quality of service and error control functions.
Functions of the Network Layer include:
- Connection model: connection-oriented and connectionless communication
- Host addressing
- Message forwarding
Basic OPP questions, SystemVerilog Interview Question 1
What is object oriented programming :
OOP Can be described with following concepts :- Follows bottom up approach.
- Emphasis is on data.
- Programs are divided into objects.
- Functions and data are bound together.
- Communication is done through objects.
- Data is hidden.
Classes, Objects, Data abstraction and encapsulation, Polymorphism, Inheritance, Message Passing, and Dynamic Binding.
Q. What is a class?
Class is an entity which consists of member data and member functions which operate on the member data bound together.
Q. What is an object?
Objects are instances of classes. Class is a collection of similar kind of objects. When a class is created it doesn’t occupy any memory, but when instances of class is created i.e., when objects are created they occupy memory space.
Q. What is encapsulation?
A1. Encapsulation is welding of code and data together into objects.
Q. What is inheritance?
A2. Inheritance is a mechanism through which a subclass inherits the properties and behavior of its superclass. The derived
class inherits the properties and method implementations of the base class and extends it by overriding methods and adding additional properties and methods.
Q. What is polymorphism?
A3. In Greek this means "many shapes."As a consequence of inheritance and virtual functions, a single task (for example, drawing
a geometrical shape) can be implemented using the same name (like draw()) and implemented differently (via virtual functions) as each type in object hierarchy requires(circle.draw() or rectangle.draw()). Later, when a polymorphic object (whose type is not known at compile time) executes the draw() virtual function, the correct implementation is chosen andexecuted at run time.
Q. What is the difference between function overloading and function overriding?
A. Overloading is a method that allows defining multiple member functions with the same name but different signatures. The compiler will pick the correct function based on the signature. Overriding is a method that allows the derived class to redefine the behavior of member functions which the derived class inherits from a base class. The signatures of both base class member function and derived class member function are the same; however, the implementation and, therefore, the behavior will differ
Q. What are the advantages of OOP?
- Data hiding helps create secure programs.
- Redundant code can be avoided by using inheritance.
- Multiple instances of objects can be created.
- Work can be divided easily based on objects.
- Inheritance helps to save time and cost.
- Easy upgrading of systems is possible using object oriented systems.
Q. Explain about the virtual task and methods .
Virtual tasks and functions are the ways to achieve the polymorphism in system verilog. Try to fun the following example and see it will help you understand the concept.
class base ;
virtual function int print;
$display("INSIDE BASE \n");
endfunction : print
endclass : base
class derived extends base;
function int print;
$display("INSIDE DERIVED \n");
endfunction : print
endclass : derived
program test ;
derived d1;
initial
begin
d1 = new();
d1.print();
callPrint (d1);
end
task callPrint (base b1);
$display("Inside callPrint \n");
b1.print;
endtask : callPrint
endprogram
What is the use of the abstract class?
A virtual class is a temple or place holder for the child classes. A virtual class is also called as the abstract class. A virtual class is declared with a virtual keyword like :
virtual class base;
endclass;
A virtual class instance or object can not be constucted but you can define the hadle to the virtual class.
A virtual class is a temple or place holder for the child classes. A virtual class is also called as the abstract class. A virtual class is declared with a virtual keyword like :virtual class base;
virtual task1;
endtask;
virtual task2;
endtask;
endclass;
A virtual class instance or object can not be constucted but you can define the hadle to the virtual class.
virtual class baseframe;
...
virtual function void iam();
endfunction
...
endclass
class shortframe extends baseframe;
...
function void iam();
$display ("Short Frame");
endfunction
endclass
class longframe extends baseframe;
...
function void iam();
$display ("Long Frame");
endfunction
endclass
baseframe two; // OK
initial begin
two = new(4); // ERROR
...
What is the need of virtual interfaces ?
Virtual interfaces provide a mechanism for separating abstract models and test programs from the actual signals that make up the design. A virtual interface allows the same subprogram to operate on different portions of a design and to dynamically control the set of signals associated with the subprogram. Instead of referring to the actual set of signals directly, users are able to manipulate a set of virtual signals. Changes to the underlying design do not require the code using virtual interfaces to be rewritten. By abstracting the connectivity and functionality of a set of blocks, virtual interfaces promote code reuse.
Virtual interfaces can be declared as class properties, which can be initialized procedurally or by an argument to new(). This allows the same virtual interface to be used in different classes. The following example shows how the same transactor class can be used to interact with various different devices:
interface SBus; // A Simple bus interface
logic req, grant;
logic [7:0] addr, data;
endinterface
class SBusTransctor; // SBus transactor class
virtual SBus bus; // virtual interface of type Sbus
function new( virtual SBus s );
bus = s; // initialize the virtual interface
endfunction
task request(); // request the bus
bus.req <= 1'b1;
endtask
task wait_for_bus(); // wait for the bus to be granted
@(posedge bus.grant);
endtask
endclass
module devA( Sbus s ) ... endmodule // devices that use SBus
module devB( Sbus s ) ... endmodule
module top;
SBus s[1:4] (); // instantiate 4 interfaces
devA a1( s[1] ); // instantiate 4 devices
devB b1( s[2] );
devA a2( s[3] );
devB b2( s[4] );
initial begin
SbusTransactor t[1:4]; // create 4 bus-transactors and bind
t[1] = new( s[1] );
t[2] = new( s[2] );
t[3] = new( s[3] );
t[4] = new( s[4] );
// test t[1:4]
end
endmodule
In the preceding example, the transaction class SbusTransctor is a
simple reusable component. It is written without any global or
hierarchical references and is unaware of the particular device with
which it will interact. Nevertheless, the class can interact with any
number of devices (four in the example) that adhere to the interface’s
protocol.
System Verilog Interview Questions 2
1) What's the OpenVera?
Its an intuitive, easy to learn language that combines the familiarity and strengths of HDLs, C++ and Java with additional constructs targeted at functional verification that makes it ideal for developing testbenches, assertions and properties.
2) What is SVA?
Answer: SVA is System Verilog Assertion.
3) What is Callback?
Callback in system verilog or verification : Callback is mechanism of changing to behavior of a verification component such as driver or generator or monitor without actually changing to code of the component.
It's used for functional coverage, inject error and output transaction in a scoreboard.
4) What is "factory pattern" concept?
The term factory method is often used to refer to any method whose main purpose is creation of objects.
e.g.
5) What's the difference between data type logic, reg and wire?
6) What is the need of clocking blocks?
- It is used to specify synchronization characteristics of the design
- It Offers a clean way to drive and sample signals
- Provides race-free operation if input skew > 0
- Helps in testbench driving the signals at the right time
- Features
- Clock specification
- Input skew,output skew
- Cycle delay (##)
- Can be declared inside interface,module or program
e.g.
Module M1(ck, enin, din, enout, dout);
input ck,enin;
input [31:0] din ;
output enout ;
output [31:0] dout ;
clocking sd @(posedge ck);
input #2ns ein,din ;
output #3ns enout, dout;
endclocking:sd
reg [7:0] sab ;
initial begin
sab = sd.din[7:0];
end
endmodule:M1
7) What are the ways to avoid race condition between testbench and RTL using SystemVerilog?
There are mainly following ways to avoid the race condition between testbench and RTL using system verilog
1. Program Block
2. Clocking Block
3. Using non blocking assignments.
According to the eRM and OVM monitors and drivers should always be completely separate. This approach was adopted mainly in order to facilitate reuse of block level agents in a top level testbench: at block level both driver and monitor are used, while at top level only the monitor is used.
8) Explain Event regions in SV?
A systemverilog event is now a handle to a synchronization object that can be passed around to routines. The events can be shared across objects without having to make the events global.
9) What are the types of coverages available in SV?
Both Code Coverage and Functional Coverage are available in SV. You can use the following examples:
Using covergroup : variables, expression, and their cross
Using cover keyword : properties
class eth_frame;
// Definitions as above
covergroup cov;
coverpoint dest {
bins bcast[1] = {48'hFFFFFFFFFFFF};
bins ucast[1] = default;
}
coverpoint type {
bins length[16] = { [0:1535] };
bins typed[16] = { [1536:32767] };
bins other[1] = default;
}
psize: coverpoint payload.size {
bins size[] = { 46, [47:63], 64, [65:511], [512:1023], [1024:1499], 1500 };
}
sz_x_t: cross type, psize;
endgroup
endclass
module Amod2(input bit clk);
bit X, Y;
sequence s1;
@(posedge clk) X ##1 Y;
endsequence
CovLavel: cover property (s1);
...
endmodule
Its an intuitive, easy to learn language that combines the familiarity and strengths of HDLs, C++ and Java with additional constructs targeted at functional verification that makes it ideal for developing testbenches, assertions and properties.
2) What is SVA?
Answer: SVA is System Verilog Assertion.
3) What is Callback?
Callback in system verilog or verification : Callback is mechanism of changing to behavior of a verification component such as driver or generator or monitor without actually changing to code of the component.
It's used for functional coverage, inject error and output transaction in a scoreboard.
4) What is "factory pattern" concept?
The term factory method is often used to refer to any method whose main purpose is creation of objects.
e.g.
// Normal Type based object creation// Class objectclass my_class; int i;endclass
program main; // Create object type my_class my_class obj1; obj1 = newendprogram
// Using Factory I should be able to do the followingprogram main; base_class my_class_object; base_class = factory.create_object("my_class"); // See here the type of the object to be created is passed as a string so we dont know the exact type of the objectendprogram5) What's the difference between data type logic, reg and wire?
Data Type | Wire | Reg | Logic |
| Assignments | Continuous assignments | blocking/non blocking assignment | Both continuous assignment or blocking/non blocking assignment |
| Limitation | Wire, cannot hold data | Storage element, store data until next assignment | extends the rand eg type so it can be driven by a single driver such as gate or module. |
6) What is the need of clocking blocks?
- It is used to specify synchronization characteristics of the design
- It Offers a clean way to drive and sample signals
- Provides race-free operation if input skew > 0
- Helps in testbench driving the signals at the right time
- Features
- Clock specification
- Input skew,output skew
- Cycle delay (##)
- Can be declared inside interface,module or program
e.g.
Module M1(ck, enin, din, enout, dout);
input ck,enin;
input [31:0] din ;
output enout ;
output [31:0] dout ;
clocking sd @(posedge ck);
input #2ns ein,din ;
output #3ns enout, dout;
endclocking:sd
reg [7:0] sab ;
initial begin
sab = sd.din[7:0];
end
endmodule:M1
7) What are the ways to avoid race condition between testbench and RTL using SystemVerilog?
There are mainly following ways to avoid the race condition between testbench and RTL using system verilog
1. Program Block
2. Clocking Block
3. Using non blocking assignments.
According to the eRM and OVM monitors and drivers should always be completely separate. This approach was adopted mainly in order to facilitate reuse of block level agents in a top level testbench: at block level both driver and monitor are used, while at top level only the monitor is used.
8) Explain Event regions in SV?
A systemverilog event is now a handle to a synchronization object that can be passed around to routines. The events can be shared across objects without having to make the events global.
9) What are the types of coverages available in SV?
Both Code Coverage and Functional Coverage are available in SV. You can use the following examples:
Using covergroup : variables, expression, and their cross
Using cover keyword : properties
class eth_frame;
// Definitions as above
covergroup cov;
coverpoint dest {
bins bcast[1] = {48'hFFFFFFFFFFFF};
bins ucast[1] = default;
}
coverpoint type {
bins length[16] = { [0:1535] };
bins typed[16] = { [1536:32767] };
bins other[1] = default;
}
psize: coverpoint payload.size {
bins size[] = { 46, [47:63], 64, [65:511], [512:1023], [1024:1499], 1500 };
}
sz_x_t: cross type, psize;
endgroup
endclass
module Amod2(input bit clk);
bit X, Y;
sequence s1;
@(posedge clk) X ##1 Y;
endsequence
CovLavel: cover property (s1);
...
endmodule
Clock Domain Crossing Timing Q&A
1) What are the major issues for Clock Domain Crossing ?
Answers:
They are 3 major problems for clock domain crossing:
A. Metastability - the transaction of data violated the setup or hold time of the destination FF. It caused the ouput may oscillate for an indefinite amount time.
The Metastability may lead to the high current or even burn out of the chip. It also caused functional issue and timing issue.
B. Data Loss - whenever a new source data is generated, it may not be captured by the destination domain in the very first cycle of the destination clock because of metastability. Plus the different clock frequency of source and destination may also caused the data loss.
C. Data Incoherency - whenever new data is generated in the source clock domain, it may take 1 or more destination clock cycles to capture it, depending on the arrival time of active clock edges.
Solutions:
There are 4 common method to solve the clock domains crossing problems:
1. MUX recirculation technique
The MUX recirculation technique is shown as below:
A control signal EN, generated in the source domain is synchronized in the destination domain using a multi-flop synchronizer. The synchronized control signal EN_Sync drives the select pin of the muxes, thereby controlling the data transfer for all bits of the bus A. In this way, individual bits of the bus are not synchronized separately, and hence there is no data incoherency. However, it is important to ensure that when the control signal is active, the source domain data A[0:1] should be held constant.
2. Handshake synchronization
A very common and robust method for synchronizing multiple data signals is a handshake technique as shown in Figure. This is popular because the handshake technique can easily manage changes in clock frequencies, while minimizing latency at the crossing.
3. FIFO synchronization
FIFO is used when you need to transfer data from one clock domain (clock domain at which you store data) to another clock domain, it grantees that the data will cross from that domain to the other (smoothly) if the Asynchronous FIFO is designed right (Async FIFO usually will include Synchronizers or similar approaches) FIFO will introduce latency to assure that the data crosses the domain approriately
4. Multi-Flop Synchronizer
The synchronizers allow sufficient time for the oscillations to settle down and ensure that a stable output is obtained in the destination domain. A commonly used synchronizer is a multi-flop synchronizer as shown in
Answers:
They are 3 major problems for clock domain crossing:
A. Metastability - the transaction of data violated the setup or hold time of the destination FF. It caused the ouput may oscillate for an indefinite amount time.
The Metastability may lead to the high current or even burn out of the chip. It also caused functional issue and timing issue.
B. Data Loss - whenever a new source data is generated, it may not be captured by the destination domain in the very first cycle of the destination clock because of metastability. Plus the different clock frequency of source and destination may also caused the data loss.
C. Data Incoherency - whenever new data is generated in the source clock domain, it may take 1 or more destination clock cycles to capture it, depending on the arrival time of active clock edges.
Solutions:
There are 4 common method to solve the clock domains crossing problems:
1. MUX recirculation technique
The MUX recirculation technique is shown as below:
A control signal EN, generated in the source domain is synchronized in the destination domain using a multi-flop synchronizer. The synchronized control signal EN_Sync drives the select pin of the muxes, thereby controlling the data transfer for all bits of the bus A. In this way, individual bits of the bus are not synchronized separately, and hence there is no data incoherency. However, it is important to ensure that when the control signal is active, the source domain data A[0:1] should be held constant.
2. Handshake synchronization
A very common and robust method for synchronizing multiple data signals is a handshake technique as shown in Figure. This is popular because the handshake technique can easily manage changes in clock frequencies, while minimizing latency at the crossing.
FIFO is used when you need to transfer data from one clock domain (clock domain at which you store data) to another clock domain, it grantees that the data will cross from that domain to the other (smoothly) if the Asynchronous FIFO is designed right (Async FIFO usually will include Synchronizers or similar approaches) FIFO will introduce latency to assure that the data crosses the domain approriately
4. Multi-Flop Synchronizer
The synchronizers allow sufficient time for the oscillations to settle down and ensure that a stable output is obtained in the destination domain. A commonly used synchronizer is a multi-flop synchronizer as shown in
Wednesday, January 20, 2010
Ethernet Questions
1) What is GbE?
Gigabit Ethernet (GbE or 1 GigE) is a term describing various technologies for transmitting Ethernet frames at a rate of a gigabit per second, as defined by the IEEE 802.3-2008 standard. Half-duplex gigabit links connected through hubs are allowed by the specification but in the marketplace full-duplex with switches are normal.
detail of Gigabit Ethernet
What is 10GbE?
The 10 Gigabit Ethernet or 10GE or 10GbE or 10 GigE standard was first published in 2002 as IEEE Std 802.3ae-2002 and is the fastest of the Ethernet standards. It defines a version of Ethernet with a nominal data rate of 10 Gbit/s, ten times as fast as Gigabit Ethernet.
detail of 10GbE
What is G.709 OTN?
ITU-T Recommendation G.709 "Interfaces for the optical transport network (OTN)" describes a means of communicating data over an optical network. It is a standardized method for transparent transport of services over optical wavelengths in DWDM systems. It also known as Optical Transport Hierarchy (OTH) standard.
detail of G.709
What is Fibre Channel?
Fibre Channel, or FC, is a gigabit-speed network technology primarily used for storage networking. Fibre Channel is standardized in the T11 Technical Committee of the InterNational Committee for Information Technology Standards (INCITS), an American National Standards Institute (ANSI)–accredited standards committee. It started use primarily in the supercomputer field, but has become the standard connection type for storage area networks (SAN) in enterprise storage. Despite its name, Fibre Channel signaling can run on both twisted pair copper wire and fiber-optic cables.
detail of Fibre_Channel
Gigabit Ethernet (GbE or 1 GigE) is a term describing various technologies for transmitting Ethernet frames at a rate of a gigabit per second, as defined by the IEEE 802.3-2008 standard. Half-duplex gigabit links connected through hubs are allowed by the specification but in the marketplace full-duplex with switches are normal.
detail of Gigabit Ethernet
What is 10GbE?
The 10 Gigabit Ethernet or 10GE or 10GbE or 10 GigE standard was first published in 2002 as IEEE Std 802.3ae-2002 and is the fastest of the Ethernet standards. It defines a version of Ethernet with a nominal data rate of 10 Gbit/s, ten times as fast as Gigabit Ethernet.
detail of 10GbE
What is G.709 OTN?
ITU-T Recommendation G.709 "Interfaces for the optical transport network (OTN)" describes a means of communicating data over an optical network. It is a standardized method for transparent transport of services over optical wavelengths in DWDM systems. It also known as Optical Transport Hierarchy (OTH) standard.
detail of G.709
What is Fibre Channel?
Fibre Channel, or FC, is a gigabit-speed network technology primarily used for storage networking. Fibre Channel is standardized in the T11 Technical Committee of the InterNational Committee for Information Technology Standards (INCITS), an American National Standards Institute (ANSI)–accredited standards committee. It started use primarily in the supercomputer field, but has become the standard connection type for storage area networks (SAN) in enterprise storage. Despite its name, Fibre Channel signaling can run on both twisted pair copper wire and fiber-optic cables.
detail of Fibre_Channel
Monday, January 18, 2010
Memory Interface Questions
1) What's DDR2 interface?
Acronym for Double-Data-Rate Two, which refers to a computer memory technology as it applies to synchronous dynamic random access memory (SDRAM). Standards are defined for the ICs as well as the DIMMs they enable. A single-data-rate SDRAM transfers data on every rising edge of the clock pulse 100MHz. Both DDR and DDR2 are double pumped—they transfer data on the rising and falling edges of the clock, achieving an effective rate of 200MHz with the same clock frequency. The difference between DDR2 to DDR is a doubled bus frequency for the same physical clock rate, which doubles the data rate yet another time.
2) What's DDR3 interface?
DDR3 offers a substantial performance improvement over previous DDR2 memory systems. New DDR3 features, all transparently implemented in the memory controller, improve the signal integrity characteristics of DDR3 designs so that higher performance is achieved without an undue burden for the system designer. If proper consideration is given to any new DDR2 memory design, it can be a relatively easy upgrade to support DDR3 in the next generation design. This paper identified the key differences between DDR2 and DDR3 and illustrated some of the key issues that need to be addressed to easy migration to DDR3.
Detail DDR3 interface information
What's ethernet?
Ethernet (the name commonly used for IEEE 802.3 CSMA/CD) is the dominant cabling and low level data delivery technology used in local area networks (LANs). First developed in the 1970s, it was published as an open standard by DEC, Intel, and Xerox (or DIX), and later described as a formal standard by the IEEE. Following are some Ethernet features:
* Ethernet transmits data at up to ten million bits per second (10Mbps). Fast Ethernet supports up to 100Mbps and Gigabit Ethernet supports up to 1000Mbps. Many buildings on the Indiana University campus are wired with Fast Ethernet and the campus backbone is Gigabit Ethernet.
* Ethernet supports networks built with twisted-pair (10BaseT), thin and thick coaxial (10Base2 and 10Base5, respectively), and fiber-optic (10BaseF) cabling. Fast Ethernets can be built with twisted-pair (100BaseT) and fiber-optic (100BaseF) cabling. Currently, 10BaseT Ethernets are the most common.
* Data is transmitted over the network in discrete packets (frames) which are between 64 and 1518 bytes in length (46 to 1500 bytes of data, plus a mandatory 18 bytes of header and CRC information).
* Each device on an Ethernet network operates independently and equally, precluding the need for a central controlling device.
* Ethernet supports a wide array of data types, including TCP/IP, AppleTalk, and IPX.
* To prevent the loss of data, when two or more devices attempt to send packets at the same time, Ethernet detects collisions. All devices immediately stop transmitting and wait a randomly determined period of time before they attempt to transmit again.
What is PCI_Express?
PCI Express (Peripheral Component Interconnect Express), officially abbreviated as PCIe (or PCI-E, as it is commonly called), is a computer expansion card standard designed to replace the older PCI, PCI-X, and AGP standards. PCIe 2.0 is the latest standard for expansion cards that is available on mainstream personal computers.[1]
PCI Express is used in consumer, server, and industrial applications, as a motherboard-level interconnect (to link motherboard-mounted peripherals) and as an expansion card interface for add-in boards. A key difference between PCIe and earlier buses is a topology based on point-to-point serial links, rather than a shared parallel bus architecture.
The PCIe electrical interface is also used in a variety of other standards, most notably the ExpressCard laptop expansion card interface.
PCI Express Detail information
What is 10GigE?
The 10 Gigabit Ethernet or 10GE or 10GbE or 10 GigE standard was first published in 2002 as IEEE Std 802.3ae-2002 and is the fastest of the Ethernet standards. It defines a version of Ethernet with a nominal data rate of 10 Gbit/s, ten times as fast as Gigabit Ethernet.
What is QDRII?
It's the same as DDR2
What's RLDRAM II ?
RLDRAM II memory definitely has its advantages for networking applications. For starters, it beats even leading-edge DDR3 for sustainable high bandwidth. It is, after all, a memory device that was originally conceived and designed for networking and L3 cache, high-end commercial graphics, and other applications that require back-to-back READ/WRITE operations or completely random access.
How does RLDRAM memory deliver this kind of performance-critical bandwidth? Significantly lower latency, for one, is a key enabler of random access. Ultra-low bus turnaround time enables higher sustainable bandwidth with near-term balanced read-to-write ratios. And a separate I/O feature reduces turnaround time even further and provides 100% data bus utilization at 1:1 read-to-write ratios. Then there’s bank scheduled auto refresh, which improves bandwidth by enabling the controller to hide refresh commands behind normal operation. And lastly, RLDRAM memory offers more burst length options—2-, 4-, and 8-bit bursts—than DDR3.
Acronym for Double-Data-Rate Two, which refers to a computer memory technology as it applies to synchronous dynamic random access memory (SDRAM). Standards are defined for the ICs as well as the DIMMs they enable. A single-data-rate SDRAM transfers data on every rising edge of the clock pulse 100MHz. Both DDR and DDR2 are double pumped—they transfer data on the rising and falling edges of the clock, achieving an effective rate of 200MHz with the same clock frequency. The difference between DDR2 to DDR is a doubled bus frequency for the same physical clock rate, which doubles the data rate yet another time.
2) What's DDR3 interface?
DDR3 offers a substantial performance improvement over previous DDR2 memory systems. New DDR3 features, all transparently implemented in the memory controller, improve the signal integrity characteristics of DDR3 designs so that higher performance is achieved without an undue burden for the system designer. If proper consideration is given to any new DDR2 memory design, it can be a relatively easy upgrade to support DDR3 in the next generation design. This paper identified the key differences between DDR2 and DDR3 and illustrated some of the key issues that need to be addressed to easy migration to DDR3.
| DDR | DDR2 | DDR3 | |
| Data Rate | 200-400Mbps | 400-800Mbps | 800-1600Mbps |
| Interface | SSTL_2 | SSTL_18 | SSTL_15 |
| Source Sync | Bidirectional DQS (Single ended default) | Bidirectional DQS (Single/Diff Option) | Bidirectional DQS (Differential default) |
| Burst Length | BL= 2, 4, 8 (2bit prefetch) | BL= 4, 8 (4bit prefetch) | BL= 4, 8 (8bit prefetch) |
| CL/tRCD/tRP | 15ns each | 15ns each | 12ns each |
| Reset | No | No | Yes |
| ODT | No | Yes | Yes |
| Driver Calibration | No | Off-Chip | On-Chip with ZQ pin |
| Leveling | No | No | Yes |
Detail DDR3 interface information
What's ethernet?
Ethernet (the name commonly used for IEEE 802.3 CSMA/CD) is the dominant cabling and low level data delivery technology used in local area networks (LANs). First developed in the 1970s, it was published as an open standard by DEC, Intel, and Xerox (or DIX), and later described as a formal standard by the IEEE. Following are some Ethernet features:
* Ethernet transmits data at up to ten million bits per second (10Mbps). Fast Ethernet supports up to 100Mbps and Gigabit Ethernet supports up to 1000Mbps. Many buildings on the Indiana University campus are wired with Fast Ethernet and the campus backbone is Gigabit Ethernet.
* Ethernet supports networks built with twisted-pair (10BaseT), thin and thick coaxial (10Base2 and 10Base5, respectively), and fiber-optic (10BaseF) cabling. Fast Ethernets can be built with twisted-pair (100BaseT) and fiber-optic (100BaseF) cabling. Currently, 10BaseT Ethernets are the most common.
* Data is transmitted over the network in discrete packets (frames) which are between 64 and 1518 bytes in length (46 to 1500 bytes of data, plus a mandatory 18 bytes of header and CRC information).
* Each device on an Ethernet network operates independently and equally, precluding the need for a central controlling device.
* Ethernet supports a wide array of data types, including TCP/IP, AppleTalk, and IPX.
* To prevent the loss of data, when two or more devices attempt to send packets at the same time, Ethernet detects collisions. All devices immediately stop transmitting and wait a randomly determined period of time before they attempt to transmit again.
What is PCI_Express?
PCI Express (Peripheral Component Interconnect Express), officially abbreviated as PCIe (or PCI-E, as it is commonly called), is a computer expansion card standard designed to replace the older PCI, PCI-X, and AGP standards. PCIe 2.0 is the latest standard for expansion cards that is available on mainstream personal computers.[1]
PCI Express is used in consumer, server, and industrial applications, as a motherboard-level interconnect (to link motherboard-mounted peripherals) and as an expansion card interface for add-in boards. A key difference between PCIe and earlier buses is a topology based on point-to-point serial links, rather than a shared parallel bus architecture.
The PCIe electrical interface is also used in a variety of other standards, most notably the ExpressCard laptop expansion card interface.
PCI Express Detail information
What is 10GigE?
The 10 Gigabit Ethernet or 10GE or 10GbE or 10 GigE standard was first published in 2002 as IEEE Std 802.3ae-2002 and is the fastest of the Ethernet standards. It defines a version of Ethernet with a nominal data rate of 10 Gbit/s, ten times as fast as Gigabit Ethernet.
What is QDRII?
It's the same as DDR2
What's RLDRAM II ?
RLDRAM II memory definitely has its advantages for networking applications. For starters, it beats even leading-edge DDR3 for sustainable high bandwidth. It is, after all, a memory device that was originally conceived and designed for networking and L3 cache, high-end commercial graphics, and other applications that require back-to-back READ/WRITE operations or completely random access.
How does RLDRAM memory deliver this kind of performance-critical bandwidth? Significantly lower latency, for one, is a key enabler of random access. Ultra-low bus turnaround time enables higher sustainable bandwidth with near-term balanced read-to-write ratios. And a separate I/O feature reduces turnaround time even further and provides 100% data bus utilization at 1:1 read-to-write ratios. Then there’s bank scheduled auto refresh, which improves bandwidth by enabling the controller to hide refresh commands behind normal operation. And lastly, RLDRAM memory offers more burst length options—2-, 4-, and 8-bit bursts—than DDR3.
Memory Module Definitions
| DDR: | Double Data Rate [Data moves which each edge of the clock] |
| DDR2: | Double Data Rate NOTE [On-Die-Termination, ODT, Architecture Changes] |
| DDR3: | Double Data Rate, third generation |
| DDR-FCRAM: | Double-Data-Rate, Fast-Cycle Random Access Memory [Different core memory arrangement then DDR RAM] |
| DIMM: | Dual In-Line Memory Module. The front side PWB pins are not connected to the rear side pins, pins used for different functions. |
| DRAM: | Dynamic Random Access Memory (Requires Refresh) |
| DRSL: | Differential Rambus Signaling Levels |
| FB-DIMM: | Fully-Buffered DIMM [utilizes JEDEC-standard DDR2 SDRAM] |
| GDDR: | Graphics DDR I/II/III/IV; GDDR1, GDDR2, GDDR3, GDDR4, GDDR5 - 1.25GHz Clock for GDDR4 |
| PSRAM | pseudo-SRAM |
| QBM2 | Quad Band Memory, DDR Compatible at increased speed |
| QDRII: | Quad Data Rate [also called DDR2, DDRII, QDRSRAM, and QDR-2 SRAM] |
| RDIMM | Registered DIMM |
| RIMM | Rambus DIMM [RDRAM], In-stalled in pairs. 16-bit modules are 184-pin or 32-bit modules at 232-pins |
| SDR DRAM: | Single Data Rate SDRAM |
| SIMM: | Single In-Line Memory Module. Data width is 32 bits per memory stick, the front 72 pins and back 72 fingers on the card are connected together. While DIMM pins are not. |
| SODIMM: | Small Outline Dual In-Line Memory Module [used in Laptops / Notebooks] |
| SOCDIMM: | Small-Outline Clocked DIMM, ultra-narrow SODIMM form factor |
| SORDIMM: | Small-Outline Registered DIMM, ultra-narrow SODIMM |
| SRAM: | Static Memory; Faster than DRAM, but more expensive |
| UDIMM | UnBuffered DIMM |
| ULP-DIMM | Ultra Low Profile DIMM [small form factor DDR/DDR2 Server/Routers/Switch memory] |
| VLP-DIMM | Very Low Profile DIMM [small form factor DDR/DDR2 Server/Routers/Switch memory] |
| XDR: | Memory sticks using DRSL [also called XDIMM], Memory type from RAMbus |
| XDR2: | Memory type from RAMbus |
| ZB-DDR: | Zero-Buffer DDR |
| HDIMM | .... |
| CAS Latency: | Column Access Strobe, is the relationship between Column Access Time and Clock Cycle Time. |
| CAS-2: | wait 2 clock cycles after the Column Address before the data appears. CAS-3, wait 3 clock cycles. |
| ECC: | Error Correcting Code, an additional 8 bits [to 64-bit data] of ECC for a total of 72-bits [72-bit wide data] |
| Bank | The DRAMs on a module are organized into a number of Banks that can be accessed simultaneously. |
| Rank | Defines a set of DRAM chips (on a module) comprising 8 byte wide (64 bits) data, or 9 bytes (72 bits) with ECC. All devices in a Rank are connected by a single Chip-Select. The actual memory size is not defined. Single-sided memory modules are always Single-Rank. Double-sided unbuffered DIMMs and SODIMMs are always Dual-Rank. Server DIMMs may have up to 4 ranks. |
| Dual Rank | Defines 2 sets of DRAM chips (on a module) each comprised of 8 byte wide (64 bits) data, or 9 bytes (72 bits) with ECC. All devices in a Rank are connected by a single Chip-Select. The actual memory size is not defined. Normally a module will have one rank per PWB side. |
| Quad Rank | Defines 4 sets of DRAM chips (on a module) each comprised of 8 byte wide (64 bits) data, or 9 bytes (72 bits) with ECC. All devices in a Rank are connected by a single Chip-Select. The actual memory size is not defined. Normally a module will have two ranks per PWB side. |
| Registered DIMM | Buffers the Address and Clock signals on each DIMM to enhance the signal quality. RDIMM |
| SO: | Small Outline (Memory Module), as in SO-DIMM |
Subscribe to:
Posts (Atom)
