synthesis
- Details
- Last Updated: Thursday, 04 March 2021 22:27
- Published: Wednesday, 26 September 2018 05:24
- Hits: 2393
General Synthesis Flow:
Synthesis transforms RTL into gate netlist. Since the goal of synthesis tool is not only to map the RTL into gates, but also to optimize the logic to meet timing, power and area requirements, it needs few other inputs to do the job.
Input = RTL (with pragmas), constraints (sdc) and timing libraries in Liberty format(.lib) needed.
Output = gate level verilog netlist.
Good Synthesized netlist needed as when die utilization approaches 95% to 100% (red zone), meeting timing becomes difficult. So, 3-5% reduction in area keeps the design away from red zone.
Synthesis Tools:
2 most widely used tools for synthesis are provided by Synopsys and Cadence. Synopsys provides DC (design compiler), while Cadence provides RC (RTL compiler)
Synthesis Inputs:
1. RTL:
We write RTL in any HDL language as verilog, system verilog or VHDL, and all synthesis tools are able to synthesize it.
Synthesis pragmas: These are special helper comments. They are put inside comments (og verilog or vhdl file) preceeded by synopsys or cadence word so that DC/RC can identify them.
cadence pragmas: 2 places to put it in
// cadence pragma_name => single line comment
/* cadence pragma_name */ => mutliline comment
synopsys pragmas: Similarly Synopsys pragmas can also be put in 2 ways:
//synopsys pragma_name => single line comment
/* synopsys pragma_name */ => mutliline comment
pragma names:
I. parallel_case: used in case stmt to specify that case stmt are non-overlapping (1 hot).
ex:
case(1'b1) //cadence parallel_case
sel[0]: out = A[0]; //when sel[1:0]=01 or 11, out=A[0], as 1st matching case stmt is executed.
sel[1]: out = A[1]; //when sel[1:0]=10, out=A[1]. when sel[1:0]=00, then latch inferred, since no default case defined.
endcase
if the pragma wasn't there, then priority logic would be built, since if both sel[0] and sel[1] are 1, then the first matching case stmt is executed, so out=A[0] in such a case. All case stmt are treated as non-paallel for synthesis purpose, since that is how RTL is simulated.
out= (sel[0] and A[0]) or (!sel[0] and sel[1] and A[1]);
however, since pragma is there, no priority logic is built as shown. So if sel[1:0]=11, out=A[0] or A[1]; So, having the prgma saves unneeded priority logic, so keeps gate count lower.
out= (sel[0] and A[0]) or (sel[1] and A[1]); => this may result in mismatches in formal verification or simulation if sel[1:0]=11 is applied.
II. map_to_mux or infer_mux: used in case and if-then-else stmt to force RC to use MUX from library.
case (sel) //map_to_mux => forces mux, meaning RC doesn't optimize this logic to seek other logic
2'b00: out = A;
2'b01: out = B;
2'b10: out = C;
2'b11: out = D;
III. infer_multi_bit pragma => maps registers, multiplexers and 3 state drivers to multibit libraray cells.
2. Timing Library (in liberty or other proprietary format):
The gate library that we use during synthesis is the timing gate library. It's in liberty format. It has timing info for each gate, as well as the functionality of each gate. Using the functionality info, the synthesis tool is able to map the gates to RTL logic, and using the timing info, it's able to check if it's meeting the timing requirement of the design. The question is which timing librrary should we use? Should we use timing for typical corner or max or min corner? Since we want to design out chip such that it meets timing even in worst possible scenario, we choose "worst case" timing library, which is the max delay library.
Example of max delay lib: Let's assume the chip runs at 1.8V typical. Since we design the chip so that it should also run at +/-10% voltage swings (due to IR drop, overshoot, etc). our worst case PVT corner would be Process=weak, Voltage=1.65V amd Temperature=150C (since high temp slows transistors). So, liberty file such as W_150C_1.65V.lib would be used. Not all lib cells may be in one library. So, we may use multiple libraries. As an ex, al core cells may be in *CORE.lib, while all Clock tree cells may be in *CTS.lib
NOTE: no tech/core lef or cap tables provided, as net delay estimated based on WLM (wire load model) which has resistance/cap defined per unit length (length is estimated based on Fanout). If physical synthesis is done, which tries to do physical placement during synthesis itself, then WLM is not used (as in RC PLE or DC-topo, both of which do physical based synthesis). In such a case, core lef file and cap table files are provided.
3. Constraints (in sdc format):
In constraints file, we specify all the constraints that our synthesis tool will try to honor. Constraints are of 2 types: Environment constraints and Design constraints. Both of these are provided via an SDC file.
Timing constraints: One of the most important design constraints in sequential digital design is clock frequency. The tool tries to meet timing once clk freq or lk waveform is given. For input/output ports, we also provide the IO delay
Invalid paths: We provide false paths or multicycle paths for paths that a re not valid 1 cycle paths. In false_paths, we define all false paths on gate level netlist.
While synthesizing, Synthesis tool optimizes setup for all data paths and clk gating paths. No hold checks or async recovery/removal checks done.
Once the tool synthesizes RTL, and meets setup time, it's done. No clk propagation done, and no hold fix done (although both setup and hold timing reports are produced). Hold rpt should have no failure as clk is ideal, and c2q of flop is enough to meet hold time as hold time for most flops is -ve (This is because of extra delay in data path, which makes setup time more +ve and hold time less +ve. worst case for hold time is very small +ve number. NOTE: more delay in data path inc setup time, dec hold time while more delay in clk path dec setup time, inc hold time).
Optimization priority: Not all constraints that we specify have equal priority. Highest priority is given to constraints that can make a chip malfunction (i.e timing constraint), while lowest prioroty is given to constraints that are good to meet, but don't make a chip malfunction (i.e power constraint0
Below are various cost types for various constraint. Basically all these constraints end up as some cost in a big cost function, and the tool's job is to minimise this cost. DC from synopsys uses cost types to optimize design. Cost types are design rule cost and optimization cost. By default, highest priority to design rule cost (top one) and then priority goes down as we move to bottom ones.
1. design rule cost => constraints are DRC (max_fanout, max_trans, max_cap, connection class, multiple port nets, cell degradation)
2. optimization cost:
A. delay cost => constraints are clk period, max_delay, min_delay
B. dynamic power cost => constraints are max dynamic power
C. leakage power cost => constraints are max lkg power
D. area cost => constraints are max area
Power optimization:
Above 90nm, power opt used to be a low priority. But with leakage power increasing, and desire to have chips last longer on battery power, optimizing chip power has become a high priority for chips going into handheld devices. These are the few of the techniques for reducing power:
1. Clock gating: Here clock gating logic is insertef for register banks (i.e a collection of flops). This reduces switching of clk every cycle, since we disable the clk when data is not being written into registers. Clock gating is inserted either when RTL has clock gating coded, or the tool can automatically infer a clock gating logic and insert clk gating logic.
ex: See clk gaters below
2. Leakege power opt: Lkg power is becoming a larger portion of overall power for low nm tech (<90nm). Multiple threshold voltages are used to reduce lkg power.
3. Dynamic power opt: Dynamic power opt consists of 2 power components: 1. short circuit power 2. switching power due to charging/discharging of net/gate caps (due to transistors switching)
4. Advanced Power management techniques: Here we employ advanced power techniques. These techniques are captured in a UPF/CPF file (see Power intent and standards).
- MSV: Using multiple supply voltages (MSV) in design: This technique is most widely used. We use lower voltages to power parts of design, which don't need to run that fast, while use higher voltages for logic that are performance critical. This can result in huge power savings as dynmaic power varies as square of voltage.
- PSO: Using power shut off (PSO) methodology: Here, some parts of design are switched on and off internally depending on their usage at that time. This saves both leakage and dynamic power.
- DVFS: Using Dynamic voltage frequency scaling (DVFS): Here, voltage and frequency of parts of chip or whole chip are scaled down when peak peak perf is not required. DVFS can be seen as a special case of MSV design operating in multiple design modes.
FLOW:
Below is the flow for running synthesis. Specific flow scripts will be explained in detail in the sections for DC and RC/Genus. This is more general explanation.
- In init file, specify lib, lef, etc. Set other attr/parameters.
- Read RTL, elaborate, and check design.
- Set Environment Constriants using SDC file => op_cond (PVT), load (both i/p and o/p), drive (only on i/p), fanout(only on o/p) and WLM. dont_touch, dont_use directives also provided here.
- Do Initial synthesis with low effort, since we just need gate netlist from RTL to write our false path file. Write initial netlist.
- Set design constraints using SDC file => case_analysis, i/p,o/p delays, clocks/generated clocks, false/multicycle paths. We use case_analysis to set part in func mode (set scan_mode to 0, since we are not interested in timing when part is in scan mode). Strictly speaking, this is not required, but then reports may become difficult to read. So, over here we set scan_mode to 0 to see func paths only. Later during PnR, we run timing separately with scan_mode set to 1, so that we see timing paths during scan_mode. Thus we are covered for both cases of scan_mode.
IMP: Do NOT force scan_en to 0, as that's real path and we want to see paths both during scan_capture mode as well as during scan_shift mode. If we force scan_en to 0, then scan_shift paths are removed from analysis altogether. Many of these paths fail hold time, so it's OK in synthesis flow, but in PnR flow, we want these paths to be fixed for both setup and hold violations. Since we use the same case_analysis file in PnR, we don't want to set scan_en to 0. - Do Final synthesis with high effort. Report timing, area and other reports. Write Final non-scan netlist.
- For SCAN designs, we need to add scan pins, convert flops to scan flops, stitch them, and spit out a scan netlist. Below are the additional steps needed.
- set below scan related settings:
A. set ideal_network attr for scan_en_in pin, so that DC/RC doesn't buffer it. We let PnR tool buffer it.
B. set false_path from scan_en_in pin (ending at clk of all flops). Otherwise large tr on scan_en_in causes huge setup/hold viol.
C. set other dft attr. define test protocol, and define scan_clk, async set/reset, SDI, SDO, SCAN_EN and SCAN_MODE.
D. do dft DRC checking and fix all violations. - Replace regular FF with scan flops, connect chain, do dft DRC checking, print timing, area and other reports. Write Final scan netlist. Synthesize again if needed (not needed since timing is usually met).
- set below scan related settings:
NOTE: clock, reset and scan_enable should not be buffered in DC/RC, as that's taken care of in PnR much better as layout is avilable. However, most of the times, synthesis scripts end up buffering the reset path during synthesis, which is not a good practise.
Library cells:
Below are some examples of RTL and their synthesized netlist. This or a very similar netlist would most likely be spit out of any Synthesis tool. i generated the netlist using Synopsys DC tool.
1. Flop:
RTL:
module flop (input Din, input clk, output reg Qout);
always @(posedge clk) Qout<=Din;
endmodule
Synthesized Gate:
module flop (input Din, input clk, output Qout); //NOTE: Qout is no more a reg, it's a wire.
FLOP2x1 Qout_reg (.D(Din), .CLK(clk), .Q(Qout), .QZ()); //name of flop is output port followed by _reg
endmodule
2. Clk Gaters:
RTL:
always @(posedge clk) begin
if (En) Qout <= Din;
end
Synthesized Gate:
module SNPS_CLOCK_GATE_HIGH_spi_0 ( CLK, EN, ENCLK, TE );
input CLK, EN, TE;
output ENCLK;
CGPx2 latch ( .TE(TE), .CLK(CLK), .EN(EN), .GCLK(ENCLK) );
endmodule
module AAA ( ... );
SNPS_CLOCK_GATE_HIGH_spi_0 clk_gate_Qout_reg ( .CLK(clk), .EN(En), .ENCLK(n38), .TE(n_Logic0) ); //Test Enabme tied to 0, since non-scan design
FLOP2x1 Qout_reg ( .D(Din), .CLK(n38), .Q(Qout) );
endmodule
3. Adders:
RTL: Z = A + B; //assume 6 bits
Synthesized Gate:
module add_unsigned_310(A, B, Z);
input [5:0] A;
input [6:0] B;
output [7:0] Z;
wire [5:0] A;
wire [6:0] B;
wire [7:0] Z;
wire n_0, n_2, n_4, n_6, n_8;
assign Z[7] = 1'b0;
FA320 g97(.A (n_8), .B (B[5]), .CI (A[5]), .CO (Z[6]), .S (Z[5])); //Full adder, S = (A EXOR (B EXOR CI)) and CO = (A & B) + (B & CI) + (CI & A), 2X Drive
FA320 g98(.A (n_6), .B (B[4]), .CI (A[4]), .CO (n_8), .S (Z[4]));
FA320 g99(.A (n_4), .B (B[3]), .CI (A[3]), .CO (n_6), .S (Z[3]));
FA320 g100(.A (n_2), .B (B[2]), .CI (A[2]), .CO (n_4), .S (Z[2]));
FA320 g101(.A (n_0), .B (A[1]), .CI (B[1]), .CO (n_2), .S (Z[1]));
HA220 g102(.A (A[0]), .B (B[0]), .CO (n_0), .S (Z[0])); //Half adder, S = (A EXOR B), CO = (A & B), 2X Drive
endmodule
module aaa ( ... );
add_unsigned_310 add_115_47(.A (A[5:0]), .B ({1'b0,B[5:0]}), .Z ({UNCONNECTED1,Z[6:0]}));
endmodule
4. Division:
RTL: Y = A / B; assume A[15:0], B[5:0], Y[15:0]
Synthesized Gate: Not yet done. FIXME??
-------------------
Difference in DC(design compiler) vs EDI(encounter digital implementation):
-----------------------
1. many of the cmds work on both DC and EDI. Biggest difference is in the way they show o/p. in all the cmds below, if we use tcl set command to set a variable to o/p of any of these cmds, then in DC it contains the actual object while in EDI, it contains a pointer and not the actual object. We have to do a query_objects in EDI to print the object. DC prints the object by using list.
2. Unix cmds don't work directly in EDI, while they do in DC. So, for EDI, we need to have "exec" tcl cmd before the linux cmd, so that it's interpreted by tcl interpreter within EDI.
3. Many new tcl cmd like "lassign", etc don't work in EDI.
4. NOTE: a script written for EDI will always work for DC as it's written as pure tcl cmds.
Design compiler:
---------------------
Register inference: (https://solvnet.synopsys.com/dow_retrieve/F-2011.06/dcrmo/dcrmo_8.html?otSearchResultSrc=advSearch&otSearchResultNumber=2&otPageNum=1#CIHHGGGG)
-------
On doing elaborate on a RTL, HDL compiler (PRESTO HDLC for DC) reads in a Verilog or VHDL RTL description of the design, and translates the design into a technology-independent representation (GTECH). During this, all "always @" stmt are looked at for each module. Mem devices are inferred for flops/latches and "case" stmt are analyzed. After that, top level module is linked, all multiple instances are uniqified (so that each instance has unique module defn), clk-gating/scan and other user supplied directives are looked at. Then pass 1 mapping and then opt are done. unused reg, unused ports, unused modules are removed.
#logic level opt: works on opt GTECH netlist. consists of 2 processes:
A. structuring: subfunctions that can be factored out are optimized. Also, intermediate logic structure and variables are added to design
B. Flattening: comb logic paths are converted to 2 level SOP, and all intermediate logic structure and variables are removed.
This generic netlist has following cells:
1. SEQGEN cells for all flops/latches (i/p=clear, preset, clocked_on, data_in, enable, synch_clear, synch_preset, synch_toggle, synch_enable, o/p= next_state, Q)
2A. ADD_UNS_OP for all unsigned adders/counters comb logic(i/p=A,B, o/p=Z). these can be any bit adders/counters. DC breaks large bit adders/counters into small bit (i.e 8 bit counter may be broken into 2 counters: 6 bit and 2 bit). Note that flops are still implemented as SEQGEN. Only the combinatorial logic of this counter/adder (i.e a+b or a+1) is impl as ADD_UNS_OP, o/p of which feeds into flops.
2B. MULT_UNS_OP for unsigned multiplier/adder?
2C. EQ_UNS_OP for checking unsigned equality b/w two set of bits, GEQ_UNS_OP for greater than or equal (i/p=A,B, o/p=Z). i/p may be any no. of bits but o/p is 1 bit.
3. SELECT_OP for Muxes (i/p=data1, data2, ..., datax, control1, control2, ..., controlx, o/p=Z). May be any no. of i/p,o/p.
4. GTECH_NOT(A,Z), GTECH_BUF, GTECH_TBUF, GTECH_AND2/3/4/5/8(A,B,C,..,Z), GTECH_NAND2/3/4/5/8, GTECH_OR2/3/4/5/8, GTECH_NOR2/3/4/5/8, GTECH_XOR2/3/4, GTECH_XNOR2/3/4, GTECH_MUX*, GTECH_OAI/AOI/OA/AO, GTECH_ADD_AB(Half adder: A,B,S,COUT), GTECH_ADD_ABC(Full adder: A,B,C,S,COUT), GTECH_FD*(D FF with clr/set/scan), GTECH_FJK*(JK FF with clr/set/scan), GTECH_LD*(D Latch with clr), GTECH_LSR0(SR latch), GTECH_ISO*(isolation cells), GTECH_ONE/ZERO, for various cells. DesignWare IP (from synopsys) use these cells in their implementation. NOTE: in DC gtech netlist, we commonly see GTECH gates as NOT, BUF, AND, OR, etc. Flops, latches, adders, mux, etc are rep as cells shown in bullets 1-4 above.
5. All directly instantiated lib components in RTL.
6. If we have designware license, then we also see designware elemnets in netlist. All designware are rep as DW*. For ex: DW adder is DW01_add (n bit width, where n can be passed as defparam or #). Maybe *_UNS_OP above are designware elements.
#gate level opt: works on the generic netlist created by logic level opt to produce a technology-specific netlist. consists of 4 processes:
A. mapping: maps gates from tech lib to gtech netlist. tries to meet timing/area goal.
B. Delay opt: fix delay violations introduced during mapping. does not fix design rule or opt rule violations
C. Design rule fixing: fixes Design rule by inserting buffers or resizing cells. If necessary, it can violate opt rules.
D. Opt rule fixing: fixes opt rule, once the above 3 phases are completed. However, it won't fix these, if it introduces delay or design rule violations.
-------
In GTECH, both registers and latches are represented by a SEQGEN cell, which is a technology-independent model of a sequential element as shown in Figure 8-1. SEQGEN cells have all the possible control and data pins that can be present on a sequential element.
FlipFlop or latch are inferred based on which pins are actually present in SEQGEN cell. Register is a latch or FF. D-Latch is inferred when resulting value of o/p is not specified under all consditions (as in incompletely specified IF or CASE stmt). SR latches and master-slave latches can also be inferred. D-FF is inferred whenever sensitivity list of always block or process includes an edge expression(rising/falling edge of signal). JK FF and Toggle FF can also be inferred.
#_reg is added to the name of the reg from which ff/latch is inferred. (i.e count <= .. implies count_reg as name of the flop/latch)
o/p: Q and QN (for both flop and latch)
i/p:
1. Flop: clear(asynch_reset), preset(async_preset), next_state(sync data Din), clocked_on(clk), data_in(1'b0), enable(1'b0 or en), synch_clear(1'b0 or sync reset), synch_preset(1'b0 or sync preset), synch_toggle(1'b0 or sync toggle), synch_enable(1'b1)
2. Latch: clear(asynch_reset), preset(async_preset), next_state(1'b0), clocked_on(1'b0), data_in(async_data Din), enable(clk), synch_clear(1'b0), synch_preset(1'b0), synch_toggle(1'b0), synch_enable(1'b0)
Ex: Flop in RTL:
always @(posedge clkosc or negedge nreset)
if (~nreset) Out1 <= 'b0;
else Out1 <= Din1;
Flop replaced with SEQGEN in DC netlist: clear is tied to net 0, which is N35. preset=0, since no async preset. data_in=0 since it's not a latch. sync_clear/sync_preset/sync_toggle also 0. synch_enable=1 means it's a flop, so enable if used, is sync with clock. enable=0 as no enable in this logic.
\**SEQGEN** Out1_reg ( .clear(N35), .preset(1'b0), .next_state(Din1), .clocked_on(clkosc), .data_in(1'b0), .enable(1'b0), .Q(Out1), .synch_clear(1'b0), .synch_preset(1'b0), .synch_toggle(1'b0), .synch_enable(1'b1) );
Ex: Latch in RTL
always @(*)
if (~nreset) Out1 <= `b0;
else if(clk) Out1 <= Din1;
Latch replaced with SEQGEN in DC netlist: all sync_* signals set to 0 since it's a latch. synch_enable=0 as enable is not sync with clk in a latch. enable=clk since it's a latch.
\**SEQGEN** Out1_reg ( .clear(N139), .preset(1'b0), .next_state(1'b0), .clocked_on(1'b0), .data_in(Din1), .enable(clk), .Q(Out1), .synch_clear(1'b0), .synch_preset(1'b0), .synch_toggle(1'b0), .synch_enable(1'b0) );
NOTE: flop has both enable and clk ports separate. sync_enable is set to 1 for flop (and 0 for latch). That means, lib cells can have Enable and clk integrated into the flop. If we have RTL as shown below, it will generate a warning if there is no flop with integrated enable in the lib.
ex: always @(posedge clk) if (en) Y <= A; //This is a flop with enable signal.
warning by DC: The register 'Y_reg' may not be optimally implemented because of a lack of compatible components with correct clock/enable phase. (OPT-1205). => this will be implemented with Mux and flop as there's no "integrated enable flop" in library.
#Set the following variable in HDL Compiler to generate additional information on inferred registers:
set hdlin_report_inferred_modules verbose
Example 8-1 Inference Report for D FF with sync preset control (for a latch, type changes to latch)
======================================================================
|Register Name | Type |Width | Bus | MB | AR | AS | SR | SS | ST |
==========================================================
| Q_reg | Flip-flop | 1 | N | N | N | N | N | Y | N |
======================================================================
Sequential Cell (Q_reg)
Cell Type: Flip-Flop
Width: 1
Bus: N (since just 1 bit)
Multibit Attribute: N (if it is multi bit ff, i.e each Q_reg[x] is a multi bit reg. in that case, this ff would get mapped to cell in .lib which has ff_bank group)
Clock: CLK (shows name of clk. For -ve edge flop, CLK' is shown as clock)
Async Clear(AR): 0
Async Set(AS): 0
Async Load: 0
Sync Clear(SR): 0
Sync Set(SS): SET (shows name of Sync Set signal)
Sync Toggle(ST): 0
Sync Load: 1
#Flops can have sync reset (there's no concept of sync reset for latches). Design Compiler does not infer synchronous resets for flops by default. It will see sync reset signal as a combo logic, and build combo logic (with AND gate at i/p of flop) to build it. To indicate to the tool that we should use existing flop (with sync reset), use the sync_set_reset Synopsys compiler directive in Verilog/VHDL source files. HDL Compiler then connects these signals to the synch_clear and synch_preset pins on the SEQGEN in order to communicate to the mapper that these are the synchronous control signals and they should be kept as close to the register as possible. If the library has reg with sync set/reset, then these are mapped, else the tool adds extra logic on D i/p pin (adds AND gate) to mimic this behaviour.
ex: //synopsys sync_set_reset "SET" => this put in RTL inside the module for DFF. This says that pin SET is sync set pin, and SEQGEN cell with clr/set should be used.
#Latches and Flops can have async reset. DC is able to infer async reset for flop (by choosing SEQGEN cell with async clear and preset connected appr), but for latches, it's not able to do it (it chooses SEQGEN cell with async clear/preset tied to 0). This is because it sees clear/preset signal as any other combo signal, and builds combo logic to support it. DC maps SEQGEN cell (with clr/preset tied to 0) to normal latch (with no clr/set) in library, and then adds extra logic to implement async set/reset. It actually adds and gate to D with other pin connected to clr/set, inverter on clr/set pin followed by OR gate (with other pinof OR gate tied to clk). So, basically we lose advantage of having async latch in .lib. To indicate to the tool that we should use existing latch (with async reset), use the async_set_reset Synopsys compiler directive in Verilog/VHDL source files.
ex: //synopsys async_set_reset "SET" => this says pin SET is async set/reset pin, and SEQGEN cell with clr/set should be used.
#stats for case stmt: shows full/parallel for case stmt. auto means it's full/parallel.
A. full case: all possible branches of case stmt are specified. otherwise latch synthesized. non-full cases happen for state machines when states are not multiple of 2^n. In such cases, unused states opt as don't care.
B. parallel case: only one branch of case stmt is active at a time (i.e case items do not overlap). It may happen when case stmt have "x" in the selection, or multiple select signals are active at same time (case (1'b1) sel_a:out=1; sel_b: out=0;). If more than 1 branch active, then priority logic built (sel_a given priority over sel_b), else simple mux synthesized. RTL sim may differ from gate sim, for a non-parallel case.
#The report_design command lists the current default register type specifications (if we used "set_register_type" directive to set flipflop/latch to something from library) .
dc_shell> report_design
...
Flip-Flop Types:
Default: FFX, FFXHP, FFXLP
#MUX_OPs: listed in report_design. MUXOPs are multiplexers with built in decoders. Faster than SELECT_OPs as SELECT_OPs have decoding logic outside.
ex:
reg [7:0] flipper_ram[255:0]; => 8 bit array of ram from 0 to 255
assign p1_rd_data_out = flipper_ram[p1_addr_in]; => rd 7 bits out from addr[7:0] of ram. equiv to rd_data[7:0] = ram[addr[7:0] ].
this gives the following statistics for MUX_OPs generated from previous stmt. (MUX_OPs are used to implement indexing into a data variable, using a variable address)
===========================================================
| block name/line | Inputs | Outputs | # sel inputs | MB |
===========================================================
| flipper_ram/32 | 256 | 8 | 8 | N | => 8 bit o/p (rd_data), 8 bit select (addr[7:0]), 256 i/p (i/p refers to distinct i/p terms that mux is going to choose from, so here there are 256 terms to choose from, no. of bits for each term is already indicated in o/p (8 bit o/p) )
===========================================================
#list_designs: list the names of the designs loaded in memory, all modules are listed here.
#list_designs -show_file : shows the path of all the designs (*.db in main dir)
------------------------
#terminology within Synopsys. https://solvnet.synopsys.com/dow_retrieve/F-2011.06/dcug/dcug_5.html
#designs => ckt desc using verilog HDL or VHDL. Can be at logic level or gate level. can be flat designs or hier designs. It consists of instances(or cells), nets (connects ports to pins and pins to pins), ports(i/o of design) and pins (i/o of cells within a design). It can contain subdesigns and library cells. A reference is a library component or design that can be used as an element in building a larger circuit. A design can contain multiple occurrences of a reference; each occurrence is an instance. The active design (the design being worked on) is called the current design. Most commands are specific to the current design.
#to list the names of the designs loaded in memory
dc_shell> list_designs
a2d_ctrl digtop (*) spi etc => * shows that digtop is the current design
dc_shell> list_designs -show_file => shows memory file name corresponding to each design name
/db/Hawkeye/design1p0/HDL/Synthesis/digtop/digtop.db
digtop (*)
/db/Hawkeye/design1p0/HDL/Synthesis/digtop/clk_rst_gen.db
clk_rst_gen
#The create_design command creates a new design.
dc_shell> create_design my_design => creates new design but contains no design objects. Use the appropriate create commands (such as create_clock, create_cell, or create_port) to add design objects to the new design.