Friday, 7 July 2017

Introduction to Static Timing Analysis

For any design, let it be Analog or digital, timing is one of the specification that has to be met.

Timing arcs like Combinational delay, setup & hold are measured for a block generally by simulating them, i.e stimulate the block with dynamic signal and measure the output (Dynamic Timing Analysis). This would get cumbersome if the block is huge like SOC, because 

1. it involves manual identification of combinational path, Data path, Clock Path, Clock gating path & Asynchronous path and measure corresponding timings between the Pin & Related Pin for each of the path.
2. Simulating the huge block will be a burden and time consuming for simulator.
3. Requires more memory for simulation.  
4. Time to market factor will be affected tremendously.

How do we automate the identifying and measuring the timing arcs for Large blocks?

 Automation industry has employed conventional Module technique, module a top SOC into simpler blocks whose timings are very easy to interpret and measure. Yes, our instinct says Gates are that lower modules. Once the timings for Gates are measured, we integrate those timings in the top level. Integration of timings of Gates are Automated, it requires each lower module's timing information in a particular syntax, this gave rise to library generation or Characterization.  

And delay modle for the routings between modules are taken from Unified routing modle.

How does lower modules behave with different load?

We know that timing measurements change with change in loads. How do we account for that in the library generation? .lib files incorporate input capacitance for each input pin, and timing arcs are measured by sweeping the output load from lower to upper defined value (it's usually decided with smallest & largest input load that can possibly connect).

How modules are integrated and timings are measured in the top level ?

Now we know that .lib files are written for modules. It has pin information, input capacitance for all input pins, all timing arcs between Pin & Related Pin. Netlist gives the connectivity information between these modules in the top level. So, a netlist (preferred is verilog) with stop level to Gates should be generated. .lib files are used as look-up table and connectivity is established using netlist generated. Algorithms are written now to dump timing information for the Top block.

Tools like Prime Time of Synopsys and Encounter timing system of Cadence are preferred in industry for this.

 How should analog blocks be handled?

Unfortunately since Analog blocks are comprised of complex different topology with transistors, it has to be treated just like Gates, where manual computation of timings has to be done. However there are automation emerging for bringing down the manual computation in these cases also like Liberate/MX/AMS from Cadence.





Monday, 1 May 2017

How to run linux software on windows?

1> Cygwin.
 This link gives you everything about Cygwin.
https://www.physionet.org/physiotools/cygwin/
Installation -> https://cygwin.com/install.html
User Guide  -> https://cygwin.com/cygwin-ug-net.html

2>MSYS.
 This link gives you everything about MSYS.
http://www.mingw.org/wiki/msys

3>WSL (Windows subsystem for Linux).
https://msdn.microsoft.com/en-us/commandline/wsl/install_guide

Save internal net's voltages from a DSPF netlist in Spectre

Most often i come across people saying that voltages of internal nets can't be saved from the dspf netlist or layout generated netlist. Extracted view is the solution to save internal nets, because they can go click on the net in GUI to instruct tool to save it, they believe.

While i agree they have found a solution to save an internal net for a layout generated solution, but the downside of generating and using an extracted view are given below:
1> Extraction runs (like QRC, Starrc etc.,) take longer to dump the extracted view since the tool has to map the extracted components to the PDK component and retain the connectivity and to restructure the layout looks out of it.
2>Consumes more disk space.
3>Simulation time is longer since simulator has to regenerate netlist from the extracted view.

Also i have come across people saying, a pin has to be brought out from the desired net to be probed. I would say it's pretty simple to save internal nets form the layout generated netlist. Before heading to give to the solution please do " spectre -h save" in your terminal. That would give you some idea about saving an internal nets.

In this blog i am taking DSPF as an example, because that's what people find most difficult to deal with. To know the DSPF format please refer to this DSPF link.
Find for "|NET" in the shared link. In the shared link "BF" is an internal net. Just add below given code in your spectre netlist, DSPF netlist has to be included in it, if |NET BF voltage has to be saved.

save BF

If there is a test bench about it and it's instance is, let's say, I45 then add below line in your netlist.

save I45.BF

If the DSPF netlist having internal net deep-down hierarchy like "|NET XAnatop/XSwitchedcap/out" and there is a testbench,I45, for it. Below is the line to save that net to be put in spectre netlist

save I45.XAnatop/XSwitchedcap/out

I hope i was helpful. Please drop comments if you need any further help :)