Logic synthesis is a process by which an abstract form of desired circuit behavior, typically register transfer level (RTL) or behavioral is turned into a design implementation in terms of logic gates. Some tools can generate bitstreams for programmable logic devices such as PALs or FPGAs, while others target the creation of ASICs. Logic synthesis is one aspect of electronic design automation.

History of Logic SynthesisThe roots of logic synthesis can be traced to the treatment of logic by George Boole (1815 to 1864), in what is now termed Boolean algebra. In 1938, Claude Shannon showed that the two-valued Boolean algebra can describe the operation of switching circuits. In the early days, logic design involved manipulating the truth table representations as Karnaugh maps. The Karnaugh map-based minimization of logic is guided by a set of rules on how entries in the maps can be combined. A human designer can only work with Karnaugh maps containing four to six variables.

The first step toward automation of logic minimization was the introduction of the Quine-McCluskey algorithm that could be implemented on a computer. This exact minimization technique presented the notion of prime implicants and minimum cost covers that would become the cornerstone of two-level minimization. Another area of early research was in state minimization and encoding of finite state machines (FSMs), a task that was the bane of designers. The applications for logic synthesis lay primarily in digital computer design. Hence, IBM and Bell Labs played a pivotal role in the early automation of logic synthesis. The evolution from discrete logic components to programmable logic arrays (PLAs) hastened the need for efficient two-level minimization, since minimizing terms in a two-level representation reduces the area in a PLA.

However, two-level logic circuits are of limited importance in a very-large-scale integration (VLSI) design; most designs use multiple levels of logic. An early system that was used to design multilevel circuits was LSS from IBM. It used local transformations to simplify logic. Work on LSS and the Yorktown Silicon Compiler spurred rapid research progress in logic synthesis in the 1980s. Several universities contributed by making their research available to the public; most notably, MIS [13] from University of California, Berkeley and BOLD from University of Colorado, Boulder. Within a decade, the technology migrated to commercial logic synthesis products offered by electronic design automation companies.

Behavioral synthesisWith the goal of increasing designer productivity, there has been a significant amount of research on synthesis of circuits specified at the behavioral level using a hardware description language (HDL). The goal of behavioral synthesis is to transform a behavioral HDL specification into a register transfer level (RTL) specification, which can be used as input to a gate-level logic synthesis flow. Behavioral optimization decisions are guided by cost functions that are based on the number of hardware resources and states required. These cost functions provide a coarse estimate of the combinational and sequential circuitry required to implement the design.

The tasks of scheduling, resource allocation, and sharing generate the FSM and the datapath of the RTL description of the design. Scheduling assigns operations to points in time, while allocation assigns each operation or variable to a hardware resource. Given a schedule, the allocation operation optimizes the amount of hardware required to implement the design.

Next, this network is optimized using several technology-independent techniques before technology-dependent optimizations are performed. The typical cost function during technology-independent optimizations is total literal count of the factored representation of the logic function (which correlates quite well with circuit area).

Finally, technology-dependent optimization transforms the technology-independent circuit into a network of gates in a given technology. The simple cost estimates are replaced by more concrete, implementation-driven estimates during and after technology mapping. Mapping is constrained by factors such as the available gates (logic functions) in the technology library, the drive sizes for each gate, and the delay, power, and area characteristics of each gate.[edit]

Commercial logic synthesisExamples of software tools for logic synthesis are Design Compiler from Synopsys and the humorously named BuildGates, from Cadence Design Systems. Both of these target ASICs. Example of FPGA synthesis tools include Synplify from Synplicity, Leonardo and Precision from Mentor Graphics and BlastFPGA from Magma Design Automation.

The history of the Verilog HDL goes back to the 1980s, when Gateway Design Automation developed Verilog-XL logic simulator, and with it a hardware description language.Cadence Design Systems acquired Gateway in 1989, and with it the rights to the language and the simulator. In 1990, Cadence put the language into the public domain, with the intention that it should become a standard, non-proprietary language.

The Verilog HDL is now maintained by a non profit making organisation, Accellera, which was formed from the merger of Open Verilog International (OVI) and VHDL International. OVI had the task of taking the language through the IEEE standardisation procedure. In December 1995 Verilog HDL became IEEE Std. 1364-1995. A revised version was published in 2001: IEEE Std. 1364-2001. This is the current version.

Accellera have also been developing a new standard, SystemVerilog, which extends Verilog. SystemVerilog is also expected to become an IEEE standard.

We are happy to invite you as a contributor to this blog in digital electronics.Of course, you can choose to be anonymous like us or choose an alias for convenience.

Please be advised that we don't tolerate posting of proprietary information specific to any company and that you obey the copyrights. We are not responsible in anyways for any copyright infringements by the contributers. A Metastable State is the sole owner of this blog. Please avoid spam and vulgarity.

A detailed set of rules will be sent to people who are interested. Please get back in touch at "onenanometer (at)gmail(dot)com" with your details.

With wide acceptance of STA and Formal verification tools by the industry one question still arises in the minds of many, "Why do we need gate level simulation?"
The common reasons quoted by many engineers are simple..

To check if reset release, initialization sequence and boot-up is proper.

Since Scan insertions occur during and after synthesis, they are not checked by simulations.

STA does not analyze asynchronous interfaces.

Unwarranted usage of wild cards in static timing constraints set false and multi cycle paths where they dont belong. This can also be due to design changes, mis-understanding or typos.

Usage of create_clock instead of using create_generated_clock between clock domains.

For switching factor to estimate power.

X's in RTL sim can be pessimistic or optimistic. Any unintended dependencies on initial conditions can be found through GLS.

Design changes, wrong understanding of the design can lead to incorrect false paths or multicycle paths in the constraints.

Can be used to study the activity factor for power estimation.

It's an excellent feel good quotient that the design has been implemented correctly.

Some design teams use GLS only in a zero-delay, ideal clock mode to check that the design can come out of reset cleanly or that the test structures have been inserted properly. Other teams do fully back annotated simulation as a way to check that the static timing constraints have been set up correctly.

In all cases, getting a gate level simulation up and running is generally accompanied by a series of challenges so frustrating that they precipitate a shower of adjectives as caustic as those typically directed at your most unreliable internet service provider. There are many sources of trouble in gate level simulation. This series will look at examples of problems that can come from your library vendor, problems that come from the design, and problems that can come from synthesis. It will also look at some of the additional challenges that arise when running gate level simulation with back annotated SDF.

"We have a chip taped-out, working fine in 65nm. We want to add more functionality to the same chip and want to accommodate the logic within the same die-area as before. To accommodate this silicon real estate requirement, we decided to move to 45nm. Since the application as well as the technology node demands extremely low leakage, we want to shut-down some blocks in the design."

Given this, it's very very challenging to accommodate Power Gating, since this chip is not architected to accommodate Power Gating

Now, given the characteristics of Power Gating Design Style, here are some facts I think, we need to consider while Micro-Architecting the design.

RTL/Micro-Architecture requirements:-

Some of the blocks will be shut-down. Does your design have control logic that generates signals locally to shut-down the block ?

I think, if the design was architected from the beginning with power gating design style in mind, it will have a control block, which probably might make decisions on which blocks to shut-down and when and how long this has to be shut-down etc. Now the other question that comes to mind is, Is this sufficient? Do I need a separate power control block, which takes inputs from the control logic and generates the power down signals in the desired sequence ? I think it is a good practice to introduce such logic to control the complete power-down/power-on sequence.

Lets look at the control signals required:

Control Signal for the Power Switch (Switch_enable)

Control Signal for the Isolation Cell Enable (Isolate_enable)

Control Signal for the retention flops (Save_Restore)

Now, I think ideally all these control signals are derivative of each other!. Its just that these signals need to be generated in the right order for the circuit to behave as desired.

sequence could be:

Inactivity generate

Generate Save_Restore: This will indicate that the retention flops needs to transfer the contents from Master Latch to Slave and go into sleep mode.

Generate Isolate_enable: This will enable isolation cells to be active and clamp the output to a known voltage and state.

Since all the basic elements are informed of the shut-down operation, we can now generate Switch_enable, to turn off the power rails, that control specific blocks.

There could be other actions such as reduce the frequency/reduce the voltage….etc as a part of this sequencing.

As a part of this sequence definition, we should define the right Assertions too, so that if the right sequence is violated, this can be flagged up-front.

Sequence power_sequence

Save_Restore && Isolate_enable && Switch_enable ==0

##1 Save_restore ==1

##1 Save_restore && Isolate_enable == 1;

##1 Save_restore && Isolate_enable && Switch_enable ==1;

endsequence

If the above control signals exist in RTL, these are driven by power management logic but are not connected to anything!

Even though as said in bullet 2 these control signals are generated by Control Logic, these are not connected to anything outside this control logic. The reasons are:-

Power Switch that's used to cut-off power does not exist in RTL. These get added probably during Power Planning. Floor-planning/Power Planning Engineer will add these based on the specification from the Architect of the chip. Till switches are in place Switch_enable is floating.

In RTL there is nothing specifically done for Retention Flop, these are coded like any other register and Synthesis tool will infer them based on some commands. Save_restore end up floating.

Isolation cells does not exist in the RTL and hence Isolate_enable is floating.

Now the Question arises. How do we simulate them? We see them in order...

Power Switch Behaviour

Isolation Behaviour

Level Shifter Behaviour

Retention flop.

Remember, we don't have any representation of the above cells in the RTL. Firstly do we need to simulate the behavior of all of them? Typically in good old days, PLI's were written by verification teams to simulate all of them.

For example say,Power Switch Behaviour: We can write a function/pli with following specification$power(block_to_be_pd, type_of_pd(aon/shut-down)signal_used_for_shut_down(switch_enable), acknowledge signal(acknowledge))

Now this PLI should look at the "type_of_pd", which is either always_on or shut-down and act accordingly. In case the block under consideration is of type shut-down, then whenever it detects an activity on the "switch_enable" signal, it should corrupt all the signals of the block. Once all the signals are corrupted, it should generate an "acknowledge" signal after a user specified delta delay.

In my humble opinion, this should also include something like:#0 $power(block1)#20 $power(block2)

This enables us to simulate the behaviour of power sequencing. There is lot more that can be added to this PLI routine such as:

Trace through the fanout of all the outputs of this block. Flag an Error if corrupted signals are propagated till the reciever.

When switch_enable goes inactive, either reset all the logic in the block to "X" or to some random pattern.

During power up, stagger the power up of different blocks randomly!!!

Emulate Impact of IR-drop using staggering principle!

Isolation Behaviour: This is again pretty straight-forward. All we need is a PLI or a simple function in Verilog, which will be something like:

$isolate(input,early_switch_enable,output,output_sense)If "early_switch_enable" is active, maintain the output at "output_sense(1/0)" value, irrespective of the state of input.Retention Behaviour: This is again pretty straight-forward from a simulation perspective. The PLI or a simple function, which will be something like: $retain("register_names",early_early_switch_enable,wake_up)Whenever "early_early_switch_enable" is active, copy the contents of "register_names " onto a local shadow_register or a local memory, and whenever "wake_up" goes active, reload the "register_names" with contents of the shadow_register.

Now there are various complex flavors of all the above depending the circuit behaviour of these speciall cells. The major question to be answered is, are we looking at 2 different RTL? One for synthesis without any PLIs and one for simulation with PLIs. Can these PLIs be synthesized into H/W automatically by all the EDA tools available? Is this the right approach? Can these be solved using a different approach?

More Questions that need answers..

Is a proper sequence for all the control signals defined ? Examples of this could be:

Switch_enable @ 5ns

Isolate_enable @ Switch_enable "+" 10ns

Save_Restore @ Isolate_enable "+" 20ns

Now the block, which we are trying to shut-down needs to generate an Acknowledgment signal, indicating power-up or power-down. This signal is again a floating output not driven by any logic,but is processed by the power management logic!!!

Is there a requirement, such as : Block needs to be powered-up within "n" clock cycles? What if you don't receive an Acknowledge within "n" clock cycles?

If all the above are taken care of during micro-architecting, there are still few more questions that need to be answered for Logic Synthesis and Functional Simulation: – Is Isolation Cell/Level Shifter part of your RTL ? How are you coding this ? Are you instantiating it in the RTL? – Are Retention Flops part of RTL ? How are you coding this ? Are you instantiating it in RTL ? – How will the control signal get interpreted by the implementation tool, as they (the control signals) are floating? – How will Acknowledge signal get generated? Since it's required by power management logic, but is not generated by any hardware? – How will functionality of all these get verified, given that some of them are either floating or not generated ? – How will the shut-down get simulated ? Nothing special is done in RTL to simulate this behaviour. – How do we model Shut-Down to verify the functionality? – How will the retention flop behaviour get simulated ? In RTL it's coded like any other register. – When a block wakes up from shut-down, what should be the status of all the logic? Is random better or using "X" better ? Wouldn't "X" be very pessimistic ? – How to simulate the behaviour of "n" clock cycle requirement of the Acknowledge Signal from power-down block ? – If there are some always on logic residing in a shut-down block, how do we implement them? How do we verify them ?

Level Shifter: Purpose of this cell is to shift the voltage from low to high as well as high to low. Generally buffer type and Latch type level shifters are available. In general H2L LS's are very simple whereas L2H LS's are little complex and are in general larger in size(double height) and have 2 power pins. There are some placement restrictions for L2H level shifter to handle noise levels in the design. Level shifters are typically used to convert signal levels and protect against sneak leakage paths. With great care, level shifters can be avoided in some cases, but this will become less practicable on a wider scale.

Isolation Cell: These are special cells required at the interface between blocks which are shut-down and always on. They clamp the output node to a known voltage. These cells needs to be placed in an 'always on' region only and the enable signal of the isolation cell needs to be 'always_on'. In a nut-shell, an isolation cell is necessary to isolate floating inputs.There are 2 types of isolation cells (a) Retain "0″ (b) Retain "1″

Enable Level Shifter: This cell is a combination of a Level Shifter and a Isolation cell.

Retention Flops: These cells are special flops with multiple power supply. They are typically used as a shadow register to retain its value even if the block in which its residing is shut-down. All the paths leading to this register need to be 'always_on' and hence special care must be taken to synthesize/place/route them. In a nut-shell, "When design blocks are switched off for sleep mode, data in all flip-flops contained within the block will be lost. If the designer desires to retain state, retention flip-flops must be used".

The retention flop has the same structure as a standard master-slave flop. However, the retention flop has a balloon latch that is connected to true-Vdd. With the proper series of control signals before sleep, the data in the flop can be written into the balloon latch. Similarly, when the block comes out of sleep, the data can be written back into the flip-flop.

Always ON cells: Generally these are buffers, that remain always powered irrespective of where they are placed. They can be either special cells or regular buffers. If special cells are used, they have thier own secondary power supply and hence can be placed any where in the design. Using regular buffers as Always ON cells restricts the placement of these cells in a specific region.

In a nut-shell, "If data needs to be routed through or from sleep blocks to active blocks and If the routing distance is excessively long or the driving load is excessively large, then buffers might be needed to drive the nets. In these cases, the always-on buffers can be used."

Power Gating Switches/MTCMOS Switch: MTCMOS stands for multi-threshold CMOS, where low-Vt gates are used for speed, and high-Vt gates are used for low leakage. By using high-Vt transistors as header switches, blocks of cells can be switched off to sleep-mode, such that leakage power is greatly reduced. MTCMOS switches can be implemented in various different ways. First, they can be implemented as PMOS (header) or NMOS (footer) switches. Secondly, their granularity can be implemented on a cell-level (fine-grain) or on a block-level (coarse-grain). That is, the switches can be either built into every standard cell, or they can be used to switch off a large design block of standard cells.