As mentioned before, the use of gvim, vcs, and makefile is equivalent to writing an RTL code by yourself, which can realize compilation, simulation, and script automation control operations.
This column talks about how to synthesize an RTL code after writing it yourself, and you can see the timing report, area report and critical path of the code we wrote.
Logic synthesis (synthesis) is to map the RTL code written by the front-end design engineer to a specific process library, and to optimize the logic of the RTL code by adding constraint information to form a gate-level netlist.
The entire ASIC design can be described as follows:
Generate ideas->description document spec->write RTL code according to the document->RTL simulation/verification->generate gate-level netlist->physical layout->tape out.
For the logic synthesis step, the tool we usually use is Design Compiler. When synthesizing an RTL code in DC, the tool will first convert the code into a GTECH netlist (generic technology (GTECH) netlist), and then map The different process libraries form a true gate-level netlist.
The specific implementation idea is:
① First load the process library (is it from TSMC or SMIC, and how many nanometers is it? It is a .db file) and RTL file.
② Add timing constraints and design constraints. (After adding constraints, the tool can perform logical optimization according to your constraints)
③ After obtaining the process library + RTL design + constraint files, it can be synthesized.
④ After the synthesis is completed, it is necessary to analyze the results of the synthesis. See Timing Report, Area Report, Power Consumption Report. Look at these reports to see if there are any errors.
⑤ If there is a problem, change the design, if there is no problem, export it into a ddc netlist, and provide it to the back-end personnel for layout and routing.
There are two kinds of libraries in DC, target library and link library ; among them, the target library is the library you use when you are doing synthesis (you can use the code segment: set_app_var target_library 90nm_typical.db to specify the target library). Generally speaking, the link library and target library are specified as the same in the design, and the link library will only be changed when the integrated process of the design is to be modified. For example, if the existing design needs to be transferred from a process A to For another process B, you can set the current unit integrated library A as link_library, and set the unit integrated library B as target_library, and remap it. The reason why it is generally set to a value is because it is necessary to tape out to find the corresponding The general process of the manufacturer is determined, so there is no need to modify the process midway, just understand this.
Before using DC, if it is the first time, you need to specify a library working directory, and specify the target library and link library used.
After specifying the library to use, the DC tool needs to read the RTL file, use the command: read_verilog "TOP.v av bc", and input three .v design files.
But we usually have many RTL files, but only one top-level file , so we need to specify which one is the top-level to tell the DC tool, using the code: current_design TOP. You can specify module TOP as the top level of the entire project. It should be noted that TOP here refers to the module name, not the file name.
After reading in the design, timing constraints need to be added. There are many timing constraints to be placed, for example:
① What is the clock frequency of the desired clock? create_clock -period 10 [get_ports CLK] (Create a clock with a period of 10ns and the corresponding port name is CLK.)
② How much is the jitter of the clock? set_clock_uncertainty -setup 0.3 [get_clocks CLK] (Set the jitter of the clock edge to 0.3ns, which may be 0.3 ahead or 0.3ns behind)
③ What is the turning time of the clock? set_clock_transition -max 0.15 [get_clocks CLK] (The reason for this setting is that our ideal clock flip time is 0, straight up and down, but in fact the clock flip transition takes time, not straight up and down , this code is Set the clock rollover time to 0.15ns)
④ What is the clock delay? set_clock_latency -max 0.7 [get_clocks CLK] (The propagation of the clock has time, from the crystal oscillator that generates the clock to the module that needs the clock, what is the transmission time in the middle? It is the clock_latency set here)
⑤ What is the input delay (input_delay)? set_input_delay -max 0.6 -clock CLK [get_ports A] (this is for data, the data starts from the clock edge, how long is the longest delay to come in from the input port)
⑥ What is the output delay (output_delay)? set_output_delay -max 0.8 -clock CLK [get_ports B] (the output can accept the maximum delay, and then DC synthesizes the internal combinatorial logic according to your constraints)
⑦ What is the input transmission delay? set_input_transition 0.12 [get_ports A], the flip of the input data is not ideal, the flip from 0-1 is not straight up and down, it takes a certain amount of time.
Performs three levels of optimization Optimization is mainly carried out from three aspects
1.Architectural level synthesis --architecture optimization insertion buffer, etc.
2. Logic level or GTECH optimization -- logic optimization Karnaugh map simplification, etc.
3.Gate-level or mapping optimization --Gate-level optimization selection with large AND gate, small AND gate, etc.
Optimizing conditions: first meet the timing constraints, and then optimize the area. Minimize area while meeting timing constraints
After compiling, the following is our comprehensive report
Input: report_qor View the comprehensive overview (quality of result is qor), you can see the length, margin, period, area, etc. of the critical path.
Enter report_timing to get some reports from some DCs for STAs, such as the delay of the timing path of each path, the delay from a certain port to a certain port, and analyze the maximum delay of the entire circuit.
There will be a slack at the bottom of the report, which is the time margin. How to judge whether the timing meets the requirements depends on whether the slack is positive. If it is positive, it meets the requirements (display MET), and if it is negative, it does not meet the requirements (VIOLATE violation), that is, the time margin is not enough.
Output constraint file: write_sdc my_design.sdc
The output ddc is the constraint file and the netlist obtained after synthesis: write -f ddc -hier -output my_ddc.ddc
write -f verilog -hier -output my_design.gv outputs the gate-level design file, and generally outputs the sdf delay file, and then uses these two files for post-simulation.
Design Compiler can use interface mode or script mode. You can enter: design_vision on the terminal interface to open the interface-based DC, or you can enter dc_shell to use the DC in script mode.
OK, the above briefly talked about some pre-knowledge of using DC. Let’s combine an example to practice it. After getting a .v file, how to use DC for synthesis, and then get the timing, area report, etc. we want. A series of processes such as sdf delay file, netlist file, etc.
The first step is to write an RTL code that needs to be synthesized. Here the up uses a full adder RTL, as shown in the figure below:
Then create a library folder, and copy all the .db files in /opt/Foundary_Library/TSMC90/aci/sc-x/synopsis to the newly created library. These files are process library files, and these things need to be used in subsequent DC settings .
After copying, the folder looks like above.
At this point, the upper-level folder of the library is as follows:
Then start the DC: Enter dc_shell on the terminal interface to start the DC:
Enter set_app_var -search_path ./library to set the path for DC to read the process library to the library in our current directory. After setting the path, you need to set the target library and link library; continue to enter set_app_var target_library typical.db in the terminal to set it up Target library, continue to set_app_var link_library typical.db
After inputting, the interface of dc_shell is as follows:
The process library used is all set up. Now we need to import the RTL code we wrote before into DC, input: read_file -format verilog {/opt/bilibili_DC_pra/full_adder.v} to read in the full adder RTL file, Because the paths are different, you can change it to your own path and read again. If the reading is still wrong, then enter start gui in dc_shell, which means to start the interface operation, and then import RTL in the upper left corner of the interface. file.
After the import is successful, DC displays the following information, including the type and bit width of the output signal:
In order to verify that our current read-in code is successful, enter: check_design in dc_shell to check the design:
If it shows 1 as shown in the figure above , it means there is no error.
If there is no error, the design can be constrained. Create a new clock and enter it in dc_shell:
create_clock -period 10 [get_ports clk] As explained in the previous basic part, create a clock with a period of 10, connected to the clk port.
Set the relevant input delay for the input pin, for example, set the input_delay to 3 for all pins except the clock, and the input_delay of the input is relative to clk:
set_input_delay -max 3 -clock clk [remove_from_collection [all_inputs] clk]
Display 1 in DC, which means no problem.
Then set the output_delay of the output, for example, set the maximum output_delay of the output to 2.5:
set_output_delay -max 2.5 -clock clk [all_outputs]
Then set the transition time of all input signals: set_input_transition 0.15 [all_inputs]
Ok, so we have finished writing the constraints, and then check_design to confirm that there is no problem.
Display 1, after there is no problem, we can start running synthesis: directly enter compile in dc_shell
DC will help us run the synthesis, and output some reports, and finally show that the optimization is completed:
After the synthesis, we can let it report something we want to see. For example, we created a clock with a period of 10ns at the beginning. We can enter: report_clock to see the clock we set at that time:
Then look at the timing report we want to see, see if there will be a timing violation in the entire design under the timing constraints we set, enter: report_timing:
It can be seen that there is still a lot of time margin. Slack displays MET, indicating that the requirements are met. If not, it will display VIOLATE violations.
In addition to the timing report, we may also look at the area, enter: report_area to view the comprehensive area report
In the area report, there is no area consumed by the wire net. This is because we did not specify the comprehensively used wire net model before. If we set wire_load, then the final area report will also include the area consumed by the wiring.
In addition, if we want to print out all the constraint information we entered in dc_shell, and generate a timing constraint file ending in .sdc, we can enter in dc_shell: write_sdc full_adder.sdc
After the output is successful, you can see that there is an additional sdc file in the folder, and you can see that the sdc file contains the constraints we wrote:
In the same way, we can also output the .sdf delay file for post-imitation: write_sdf full_adder.sdf, and if we want to run post-imitation, in addition to the delay file, we also need the RTL netlist file, so we output the RTL Netlist file: write_file -format verilog -output full_adder_netlist.v
Looking at the netlist file, it can be found that the RTL code has become a gate-level thing.
When the designer interacts with the backend, they can just deliver the delay file sdf file and the RTL netlist file to them.
If the timing is violated during synthesis, how should we look at critical_path? In order to test the violation, we set the clock period to 2ns and deliberately make it violate: create_clock -period 2 [get_ports clk]
After modifying the clock, compile again to finish compiling report_timing.
We can see that when the clock period is set to 2ns, a timing violation occurs, and VIOLATED is also displayed on the time margin
In the timing report, the trend of the critical path is directly displayed. It can be seen that the data_require is 1.93ns, but the data_arrival time is -3.38ns, and a timing violation occurs.
Well, this is the end of the DC comprehensive tutorial from 0 to reading the report. Let me briefly say a few words: For beginners, they must be caught off guard when exposed to so many commands at once. How can they remember so many things? What I want to say is that although there are many commands, the most practical ones are the ones I listed. You may not remember them all at once when you first get in touch with them, but after using them a lot, you will be able to type them out proficiently. Just like the linux operating system, "cd .." is to return to the previous folder, pwd is to view the current path, rm is to delete, and cp is to copy. mkdir is to create a folder, ls is to view the contents of the current folder, you see, I have said so many commands, you are probably familiar with each of them, because these commands are too common when using the linux operating system, and DC Whether it is setting the path, setting the target process library, or setting the timing constraints, the commands used are those things. It’s okay to be confused at the beginning. Just remember, practice more and more coding, and you will be familiar with it naturally. up.