没有合适的资源?快使用搜索试试~ 我知道了~
资源推荐
资源详情
资源评论
RTL-to-Gates Synthesis using Synopsys Design Compiler
6.375 Tutorial 4
March 2, 2008
In this tutorial you will gain experience using Synopsys Design Compiler (DC) to perform hardware
synthesis. A synthesis tool takes an RTL hardware description and a standard cell library as
input and produces a gate-level netlist as output. The resulting gate-level netlist is a completely
structural description with only standard cells at the leaves of the design. Internally, a synthesis tool
performs many steps including high-level RTL optimizations, RTL to unoptimized boolean logic,
technology independent optimizations, and finally technology mapping to the available standard
cells. A synthesis tool is only as good as the standard cells which it has at its disposal. Good
RTL designers will familiarize themselves with the target standard cell library so that they can
develop a solid intuition on how their RTL will be synthesized into gates. In this tutorial we will
use Synopsys Design Compiler to elaborate RTL, set optimization constraints, synthesize to gates,
and prepare various area and timing reports.
Synopsys provides a libr ary called Design Ware which includes highly optimized RTL for arithmetic
building blocks. For example, the Design Ware libraries contain adders, multipliers, comparators,
and shifters. DC can automatically determine when to use Design Ware components and it can
then efficiently synthesize these components into gate-level implementations. In this tutorial we
will learn more about what Design Ware components are available and how to best encourage DC
to use them.
It is important to carefully monitor the synthesis tool to identify issues which might negatively
impact the area, power, or performance of the design. We will learn how to read the various DC
text reports and h ow to use the graphical Synops y s Design Vision tool to visualize the synthesized
design.
The following documentation is located in the course locker (/mit/6.375/doc) and provides addi-
tional information about Design Compiler, Design Vision, the Design Ware libraries, and the Tower
0.18 µm Standard Cell Library.
• tsl-180nm-sc-databook.pdf - Databo ok for Tower 0.18 µm Standard Cell Library
• presto-HDL-compiler.pdf - Guide for the Verilog Complier used by DC
• dc-user-guide.pdf - Design Compiler user guide
• dc-quickref.pdf - Design Compiler quick reference
• dc-constraints.pdf - Design Compiler constraints and timing reference
• dc-opt-timing-analysis.pdf - Design Compiler optimization and timing analysis ref
• dc-shell-basics.pdf - Basics of using the DC shell
• dc-tcl-user-guide.pdf - Basics of writing TCL scripts for Design Compiler
• design-ware-quickref.pdf - Design Ware quick reference
• design-ware-user-guide.pdf - Design Ware user guide
• design-ware-datasheets - Directory containing datasheets on each DW component
• dv-tutorial.pdf - Design Vision Tutorial
• dv-user-guide.pdf - Design Vision User Guide
6.375 Tutorial 4, Spring 2008 2
Getting started
Before using the 6.375 toolflow you must add the course locker and run the course s etup script with
the following two commands.
% add 6.375
% source /mit/6.375/setup.csh
For this tutorial we will be using an unpipelined SMIPSv1 processor as our example RTL d esign.
You s hould create a working directory and checkout the SMIPSv1 example project from the course
CVS repository using the following commands.
% mkdir tut4
% cd tut4
% cvs checkout examples/smipsv1-1stage-v
% cd examples/smipsv1-1stage-v
Before starting, take a look at the subdirectories in the smips1-1stage-v project directory. Figure 1
shows the sys tem diagram which is implemented by the example code. When pushing designs
through the physical toolflow we will often refer to the core. The core module contains everything
which will be on-chip, wh ile blocks outside the core are assume to be off-chip. For this tutorial
we are assuming that the processor and a combinational memory are located within the core. A
combinational memory means that the read address is specified at the beginning of the cycle, and
the read data returns during the same cycle. Building large combin ational memories is relatively
inefficient. It is much more common to use synchronous memories. A synchronous memory means
that the read address is specified at the end of a cycle, and the read data returns during the
next cycle. From Figure 1 it should be clear that the unpipelined SMIPSv1 pr ocessor requires
combinational memories (or else it would turn into a f ou r stage pipeline). For this tutorial we will
not be using a real combinational memory, but instead we will use a dummy memory to emulate
rd0
rd1
Reg
File
>> 2
Sign
Extend
ir[15:0]
Reg
File
Data
Mem
val
rw
Cmp
eq?
Instruction Mem
val
pc+4
branch
+4
Decoder
Control
Signals
tohost
tohost_en
testrig_tohost
ir[25:21]
ir[20:16]
Add
wdata
addr
rdata
rf_wen
wb_sel
ir[20:16]
PC
pc_sel
Figure 1: Block diagram for Unpipelined SMIPSv1 Processor
6.375 Tutorial 4, Spring 2008 3
the combinational delay throu gh the memory. Examine the source code in src and compare
smipsCore
rtl with smipsCore synth. The smipsCore rtl module is used for simulating the
RTL of the SMIPSv1 processor an d it includes a functional model f or a large on-chip combinational
memory. The smipsCore synth module is used for synthesizing the SMIPSv1 processor and it uses
a dummy memory. The dummy m emory combinationally connects the memory request bus to
the memory response bus with a series of standard-cell buffers. Obviously, this is not fun ctionally
correct, but it will help us illustrate more reasonable critical paths in the design. In later tutorials,
we will start us ing memory generators which will create synchronous on-chip SRAMs.
Now examine the build directory. This directory will contain all generated content including
simulators, synthesized gate-level Verilog, and final layout. In this course we will always try to keep
generated content separate from our source RTL. This keeps our project directories well organized,
and helps prevent us f rom unintentionally modifying our source RTL. There are subdirectories in
the build d ir ectory for each major step in the 6.375 toolflow. These subdir ectories contain scripts
and configuration files for runn ing the tools required for that step in the toolflow. For this tutorial
we will work exclusively in the dc-synth directory.
Synthesizing the Processor
We will begin by running several DC commands manually before learning how we can automate the
tool with scripts. DC can generate a large number of output files, so we will be running DC within
a build directory beneath dc-synth. Use the following commands to create a build directory for
DC and to start the DC s hell.
% pwd
tut4/examples/smipsv1-1stage-v
% cd build/dc-synth
% mkdir build
% cd build
% dc_shell-xg-t
Initializing...
dc_shell-xg-t>
You should be left at the DC shell prompt from which you can can execute various commands to
load in your design, specify constraints, synthesize your design, print reports, etc. You can get more
information about a specific command by entering man <command> at the dc
shell-xg-t prompt.
We will now execute some commands to setup your environment.
dc_shell-xg-t> lappend search_path ../../../src
dc_shell-xg-t> lappend search_path /mit/6.375/install/vclib
dc_shell-xg-t> define_design_lib WORK -path "work"
dc_shell-xg-t> set link_library \
[list /mit/6.375/libs/tsl180/tsl18fs120/db/tsl18fs120_typ.db]
dc_shell-xg-t> set target_library \
[list /mit/6.375/libs/tsl180/tsl18fs120/db/tsl18fs120_typ.db]
These commands point to your Verilog source directory, create a Synopsys work directory, and point
to th e stand ard libraries we will be using for th is class. T he DB files contain wireload models and
6.375 Tutorial 4, Spring 2008 4
Information: Building the design ’smipsProcDpathRegfile’. (HDL-193)
Inferred memory devices in process
in routine smipsProcDpathRegfile line 27 in file
’../../../src/smipsProcDpathRegfile.v’.
=============================================================================
| Register Name | Type | Width | Bus | MB | AR | AS | SR | SS | ST |
=============================================================================
| registers_reg | Flip-flop | 32 | Y | N | N | N | N | N | N |
...
| registers_reg | Flip-flop | 32 | Y | N | N | N | N | N | N |
=============================================================================
Statistics for MUX_OPs
===================================================================
| block name/line | Inputs | Outputs | # sel inputs | MB |
===================================================================
| smipsProcDpathRegfile/23 | 32 | 32 | 5 | N |
| smipsProcDpathRegfile/24 | 32 | 32 | 5 | N |
===================================================================
Figure 2: Output from the Design Compiler elaborate command
timing/area information for each standard cell. DC will use this information to try and optimize
the synthesis process. You can now load your Verilog design into Design Compiler with the analyze
and elaborate commands. Executing these commands will result in a great deal of log output as
the tool elaborates some Verilog constructs and starts to infer some high-level components. Try
executing the commands as follows.
dc_shell-xg-t> analyze -library WORK -format verilog \
{ vcMuxes.v vcStateElements.v vcRAMs.v vcArith.v smipsInst.v \
smipsProcCtrl.v smipsProcDpathRegfile.v smipsProcDpath_pstr.v \
smipsProc.v smipsCore_synth.v }
dc_shell-xg-t> elaborate smipsCore_synth -architecture verilog -library WORK
Take a closer look at th e output during elaboration. DC will report all state inferences. This is a
go od way to verify that latches and flip-flops are not being accidentally inferred. You should be
able to check that the only inferred state elements are the PC, the tohost register, a one-bit reset
register, and the register file. DC will also note information about inferred muxes. Figure 2 shows
a fragment from the elaboration output text. From this output you can see that DC is inferring
32-bit flip-flops for the register file and two 32 input 32-bit muxes for the register file read ports. See
the Presto HDL Compiler Reference Manual (presto-HDL-compiler.pdf) for more inform ation
on the output from the elaborate command and more generally how DC infers combinational and
sequential hardware elements.
After reading our design into DC we can use the check
design command to check th at the design
is consistent. A consistent design is one which does not contain any errors such as unconnected
ports, constant-valued ports, cells with no input or output pins, mismatches between a cell and its
reference, multiple driver nets, connection class violations, or recursive hierarchy definitions. You
will not be able to synthesize your design u ntil you eliminate any errors. R un the check design
command as follows and take a look at the warnings. Many of these warning are obviously not an
issue, b ut it is still useful to skim through this ou tp ut.
剩余15页未读,继续阅读
资源评论
chinaren1945
- 粉丝: 0
- 资源: 3
上传资源 快速赚钱
- 我的内容管理 展开
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功