The Verilog Synthesis Process (v1.0) (According to the 470 GSIs)

Transcription

1 The Verilog Synthesis Process (v1.0) (According to the 470 GSIs) 1 Introduction Janurary 20, 2008 The purpose of this document is to teach you about Makefiles and the Verilog synthesis process. The synthesis process will take your handwritten Verilog code and translate it into a gate level design. It will then optimize the translation to meet certain timing constraints that you set. It is an extremely complex process so writing simpler code will more likely produce working synthesized code. 2 Makefiles Trying to type all the file names needed to compile your code can be a very long and error prone procedure; Makefiles are used to automate the compiling process. They consist of two basic building blocks: variables and rules. A variable is usually set equal to a list of files or commands. It can then be used in place of the list. Variables are useful when the same set of commands/files is used for multiple rules. Variables are defined as follows: <name> = <commands/file names> All commands/file names must be separated by white space. If the list is too long to fit on the screen a forward slash, \, can be used to continue to the next line. Examples of variable definitions are given below, which are found in every Makefile we provide: VCS = vcs +v2k +vc -Mupdate -line -V INTFLAGS = -I +memcbk -full64 To use a variable you must use the following structure: $(<name>). Rules are used to run a command based on a set of dependencies. Rules are structured as follows: <name>: <dependencies> <tab> <command to execute> Note that <tab> is an actually tab, Makefiles complain if spaces are used instead of a single tab. To execute any rule type make <name> on the command line. When executing any rule the dependencies are checked to see if they have changed since the previous execution. If they haven t then nothing will execute. The dependencies can be a

2 mix of files, variables, and other rules. An example of a rule is given below, which is found in every Makefile we provide: simv: $(SIMFILES) $(TESTBENCH) $(VCS) $(TESTBENCH) $(SIMFILES) -o simv R This rule is called simv and is dependent on the variables $(SIMFILES) and $(TESTBENCH). An explanation of all the variables and rules we use is given below: Variables: VCS INTFLAGS TESTBENCH SIMFILES SYNFILES program complier flags needed to run interactive windows files needed for the testbench, will not be synthesized files needed for behavorial execution, will be synthesized files needed for synthesized execution Rules we use and how we have defined them: all compiles and runs behavioral code and pipes output to program.out <name>.vg compiles synthesized code for <name> simv compiles behavioral code but will not pipe output to program.out int compiles behavioral code and opens interactive windows using compiled behavioral code syn_simv compiles and runs synthesized code but will not pipe output to syn_program.out syn compiles and runs synthesized code and pipes output to syn_program.out syn_int compiles and runs synthesized code and opens interactive window using synthesized code clean removes all files created during the behavioral compiling process nuke removes all files created during the behavioral and synthesis compiling process For additional help with generic makefiles (usually for C/C++) see: 2

3 3 Synthesis 3.1 TCL Script We use a script, the tcl file, to tell the synthesizer all the commands for the synthesis process. The first few lines of the script tell the synthesizer which files to read, which modules to synthesize, and what cycle time to shoot for. These are the only lines that need to be changed for any new module you synthesize. read_file -f verilog [list "one_bit_addr.v"] set design_name one_bit_addr set clock_name clock set reset_name reset set CLK_PERIOD 4.0 The first line will read all the Verilog files needed to synthesize the module. The list of files should be separated by a space and enclosed in double quotes. The second line tells the synthesizer what the top level module is called. (*Note this is the MODULE name not the FILE name). If a hierarchy of modules is created only the very top level module needs to be named here. For example, if you created an one_bit_addr and used this module to create an eight_bit_addr only the eight_bit_addr would need to be named. This is because in creating the eight_bit_addr the synthesizer knows that it needs to create the one_bit_addr since it was instantiated inside the eight_bit_addr. The third and fourth line will name the clock and reset signals but most of the time this will never change. The fifth line is the clock period you would like the synthesizer to aim for. 3.2 Don t Touch Sometimes synthesizing a module is too daunting a task for the tools the handle leading to hours of waiting for the synthesizer to finish. There is however a way to speed up the process. It involves synthesizing in a bottom up manner and telling the synthesizer don t touch the modules I have already synthesized. This reduces synthesizing time greatly as there are fewer paths available to optimize the design. This is a double edge sword however because with fewer paths available to optimized the less likely it will achieve the optimum clock period. Also be aware that the modules higher up in the hierarchy can not have a clock period faster than modules below them. For example, if you wanted to synthesize the one_bit_addr first and use it to synthesize eight_bit_addr because it takes too long to synthesize (which it doesn t) then the one_bit_addr must have a lower clock period than the eight_bit_addr. In general it is a good idea to scale the clock period based on the complexity of the design. An example of a synthesis script for the above example (eight_bit_addr) is shown below, note that after synthesis a DDC file is created that can be used for multilevel synthesis rather than using the associated V file: 3

4 read_file -f ddc [list "one_bit_addr.ddc"] set_dont_touch one_bit_addr read_file -f verilog [list "eight_bit_addr.v"] set design_name eight_bit_adder set clock_name clock set reset_name reset set CLK_PERIOD Synthesis Output Since the synthesis process produces so much output and scrolls that output across the screen so fast we grab this output and put in into a file, usually the file <module>_synth.out. This file is the first place to look if there is a problem with your synthesis Common Errors/Warnings At the start of the process there are a few errors during Initialization that can be ignored. They occur before processing your design therefore it won t affect your synthesis. All other errors during synthesis must be addressed otherwise your design will not synthesize. Some warnings however may be ignored. When the synthesizer is processing your design files you will see a large number of warnings that look like this: Intraassignment delays for nonblocking assignments are ignored. (VER-130) These warnings are normal as the synthesizer is stating that you are using a delay for nonblocking assignments. Another warning that can be ignored is the following: signed to unsigned assignment occurs. (VER-318) As long as you are aware of the implications of assigning a signed variable to an unsigned one then these warnings can be ignored. The following warning should be addressed: the undeclared symbol '<name>' assumed to have the default net type, which is 'wire'. (VER-936) This warning usually occurs when you used a variable called <name> but you never stated what type the variable was, a reg or wire Timing Arc A timing arc is created when circular logic exists in your design. This means that you have a variable A that depends on variable B but variable B depends on variable A. Most likely the timing arc will have a much longer chain of dependent variables. The 4

5 synthesizer will detect these loops immediately before the Beginning Implementation Selection section. A timing loop will look like the following: Information: Timing loop detected. (OPT-150) U18519/DIN U18519/Q U18515/DIN5 U18515/Q U18514/DIN5 U18514/Q U18306/DIN2 U18306/Q The synthesizer will break the loop by cutting the connection from one gate so that the circular logic no longer exists. However, this will likely prevent your synthesized code from operating correctly. Finding the timing loop is one of the hardest bugs to pinpoint as the output is very non-helpful. It is very important to synthesize each module separately to pinpoint any timing loops more effectively Flip-Flops/Latches After the synthesizer processes all your files it will distinguish what the memory elements of the design are. You should see all the registers you created (all variables used in a clock) block). It will look like the following: Register Name Type Width Bus MB AR state_reg Flip-flop 2 Y N N Another memory element you might see is the latch. Latches create unpredictable problems with your synthesis design and therefore should be eliminated. Most of the time they are created when you do not set a variable on every logical path in a combinational always block They will look like the following: Register Name Type Width Bus MB AR AS next_state_reg Latch 2 Y N N N 3.2 Timing Report The timing report, usually <module>.rep, lists all the critical paths through your design. Each critical path will be listed with a starting point and an ending point. It will also list all of the elements to get from one to the other and the time required to do so. It will then state the amount of slack left from the clock period you specified in your TCL script. All of the slacks should be positive or zero (MET) and never negative (VIOLATED). In understanding the limit of your clock period be aware that a MET clock period does not mean that it could not be lower, even if the slack was zero. Maximum effort is given by the synthesizer when the clock period is barely VIOLATED, on the order of hundredths of a nanosecond. This is because there is no need to optimize the 5

6 design any more if the timing requirements have already been met. Below is an example critical path from the tutorial: startpoint: state_reg[1](rising edge-triggered flip-flop clocked by clock) endpoint: gnt_b (output port clocked by clock) Point Fanout Trans Incr Path state_reg[1]/clk (dffcs1) r state_reg[1]/qn (dffcs1) f n5 (net) f state_reg[1]/q (dffcs1) r gnt_b (net) r gnt_b (out) r data arrival time 0.42 max_delay clock uncertainty output external delay data required time data required time 5.80 data arrival time slack (MET) Computing cycle time For programming projects: o Take the CLOCK_PERIOD you have in the tcl file and subtract the worstcase slack found in the.rep file. Ignore slack times associated with the reset line. You will likely notice you always get something like a slack in something with a Startpoint: reset. You should ignore those. For the class project: o This won't actually be enough. There you will use the best (lowest) CLOCK_PERIOD that has no negative slack times (other than reset). 6