Contents:
There are various aspects of synthesis which are needed to be taken care beyond getting successful compilation and this workshop ensured we will get to know that and more. We started off with an introduction to invoking DC shell and, then Design Vision for a GUI flavor. Since the shell environment employs TCL commands, we were given a primer on utilising it in general and especially in Synopsys environment with an introduction to Synopsys propietary file formats, data structures and TCL commands. There are various flavours of the cells provided as for setup constraints you might need a performance oriented or fast implementation, but to take care of hold violations, you might require a slower variant of the same.
Here we realize as seen in the snippet, that Synopsys already loads a dummy library for mapping some standard designs using their propietary GTECH library, so that the user in question, gets some results out of synthesizing the design.
Since Synopsys doesn't support .lib files, we have to provide it with .db library file, the library file in question being the sky130 for typical corner (tt) at 1.8V nominal voltage, has been read here.
The target library is set, which is then linked with tool memory, which is used for further linking design with it.
Linking and compiling yields the following on the terminal.
As per our instructor, here you can see the beauty, 😄, the mapped netlist as per the following snippet, after writing the netlist out after compilation.
Since, we have now acquired the netlist, it is natural to have curiosity to see the schematic. For that we invoke Design Vision, which provides a Graphical User Interface to the user for viewing the resultant schematic, for which we create a .ddc file, which consists of all the commands and the library used there, before creating the .ddc file. Also, we have to make note that our synthesized design might involve an inverter in input for an active-low input, and although that is not a significant change, it topogrphically does represent a change.
It is important for us to configure our own .synopsys_dc.setup file so that repetitive tasks like associating a target and link library is taken care of. We need to create it in home directory of the terminal, which is an important and necessary step.
After re-initializing DC shell, here's the magic! The library is already associated for us with relevant, link and target moniker.
Having seen basic steps for getting started with DC, for getting serious with it, it is important to know how to script in TCL.
A basic tutorial for setting the value of a variable, calling it out using echo and then using for loop in TCL is shown below. The point worth noting here is that while setting the value and using it in 'incr', we don't provide '$' in front of it.
For the same functionality using while, we have the following code snippet.
Here the 'incr' function is expanded upon in the fashion i=i+1 using 'expr'.
Initializing the list is done as follows using TCL.
Illustrating the foreach command here.
Here we have used a Synopsys command to get the standard cells containing 'and' in their reference name, the '/' wildcard ensures that we have any other text attached to it, so we have 'nand' here as well. The curly braces, signify that this is a Synopsys datatype called 'collection'.
For accessing collection elements we have to make use of foreach_in_collection, but it is not as straighforward as foreach, as the variable yields a pointer like representation, and therefoe we have to dereference it using get_object_name and assign it to another varible.
We can save the above as a .tcl file and source it in our shell environment to use it repeatedly.
The command list_lib gives us the library loaded in tool library.
Similarly,for getting the pins for the cells, we have to use get_lib_pins as shown below.
Here, we have written a script, which utilized get_lib_attribute to get the direction of the pins of the cells, and listing it out with the respective cell names, 1 specifying an input and 2 an output.
After that we used the function attribute to yield the functionality in boolean terms with respective cells.
Similarly, we can see the area (in um^2), by using the area attribute in following fashion.
Some more attributes showcased here, pin capacitance, a port being a clock, and a cell being sequential showcased below:
We can list out the attributes and understand their use case as per our needs.
For carrying out STA based operations, we focus on the following design.
We see the area and have a look at our design's ports here.
Since it is easier to access the collection objects after being de-referenced, here we have a script to list it out in an item by item basis.
Only port names, are not much useful, listing out their pin direction is pretty useful to get a general idea of our design.
The following command helps us in identifying whether we have a flt design or a hierarchical one.
Since, all of our cells aren't hierarchical in nature, we expectedly get the following on setting up a filter checking for non-hierarchical entries.
If we want to get the reference name for our instantiated unit, we can use the following attribute as shown. There's information in the name, df, signifies d-flip flop, r-asynchronous reset and t-true output, i.e. Q not Q', and p signifying positive edge is taken as clock-reference.
As a natural progression of our scripting prowess, we write a script yielding the cells with their reference names.
After reading in the verilog file and generating the ddc file, we take a look at the schematic on Design Vision.
It is a crime to have multiple drivers, and we can ensure over an net, that there be one input and multiple outputs, not in excess though as we will discuss later.
Let us make our script yield all the devices with their pin names used in the design.
Having fun with the ports and seeing how we can access them as per our convenience. It's time we add physical signficance and deal with them.
Profiling the clock, we see that it is a master clock and not a generated clock.
We can provide different waveform patterns and duty cycle as following.
We provide the source and network latency, along with the clock uncertainty as follows:
Unateness is discussed as per the timing arc characteristics the gate pins exhibit:
Here, we see how the following gates differ in their driving strengths.
The output capacitance is modelled as follows:
The delay is a function of input transition and output load.
Before providing any of the parameters as above we are reported an unconstrained design.
As we see the setup timing report, our timing is met as per the equation for setup slack.
The verbose port report tells us there are a lot of gaps to be filled in the following.
After having taken care of setup constraints, we need to provide constraints for hold timing as well.
After constraining it suitably, we have the following report for hold-timing.
Having provided input transitions, we see the following with our slack minimizing.
After having dealt with input port timing, we head onto output, while constraining it suitably without the load first, and then with load afterwards.
For our output hold timings, we make the changes as well, and it yields the following.
There is Boolean Optimization, on an algebraic level, as it simplifies down the line following the basic laws of Boolean Algebra, while resource sharing is a bit involved as it focusses on the constraint being provided, and therefore tries to optimize the design structure in a manner where if possible it will strive for minimum area and where not possible it will focus on other metrics like the overall delay.
Constant propagation is a method which basically ties down one of the inputs to either high or low voltage specified for the design, and as we see they utilize tie-cells which are further made of resistive implementation of the CMOS transistors connected in the following fashion. The retiming paradigm is a tricky one, in case you had combinational logic provided as a whole which realized a whole logic in such a manner that made sense on having a look at the logic diagram, if spreading out the logic soa s to yield a functional equivalent for timing optimization, is not problematic, one may opt for it. The Constant propagation method of simplification may also lead to a combinational logic block like an inverter, as per the implementation specified.
In the special optimization methods, we provide special commands to DC which basically provides it instruction to provide boundaries where possible by not making a melting pot of combinational logic where explicit boundaries aren't specified, so that we can basically provide better observability and controllability. The multicycle paths are dealt with explicitly specifying which path is better off considering an extra clock cycle, rather than optimizing it for a single cycle, which may lead to catastrophic results. Also, we try to isolate our output port by introducing buffer which handles the output capacitance at the boundary rather than our pin which might get loaded to a pretty high value, and so as to incorporate constraints may get lost in the optimization process.
The timing reports are taken with consideration to various max and min transitions as well as the combinational delay provided along with output, and the worst paths ay be segregated and accessed with special commands, to yield various paths, but as per our setup-path timing, we consider max's and min's in case of hold timing analysis.
When we have a High fanout network, it is important for us to structure it in a way that buffers are inserted in a tree-like fashion between various nodes yielding a load distribution which is decided upon by the max capacitance, the node sees, and we have specified as a constraint.
In summary, logical synthesis is a combination of logic translation, mapping and optimization, which require us to use the brilliant tool with a matching brilliance on each step, taking care of the following. And for ensuring a healthy slack, we have to make meaningful assignments to our constraints, so that the compilation tool, can act on it and provide us with the magical reality of having the slack met !
- Kunal Ghosh, Co-founder, VSD Corp. Pvt. Ltd.
- Shon Taware, TA for the course.
Websites
- VSD-IAT: https://vsdiat.com/