chickenbit.net

Use divided clock for timers

Timers are a usual feature/requirement in several applications of digital design. Fundamentally, timers are implemented as counters that increment/decrement at the rate of provided clock. It’s very common to find a large number of different timers distributed throughout design, each ticking with base clock.

There’s a nice opportunity for area saving in such cases. The idea is very simple, let me illustrate with example:

Imagine, your clock’s base frequency is 4MHz (a period of 0.25us). In the design, three timers are required for 1us, 2us and 16us. If you were to implement these timers by clocking them at 4MHz, that would need 14 (3+4+7) bits.

Here’s the idea, you divide the base 4 MHz clock down to 1 MHz, and then use divided clock for implementing timers. Now, you’ll need 8 (1+2+5) bits. Now of course, we would also need some additional bits for clock-division (in this example 2 more)

The area savings can be significant if a large number of timers can be brought into this divided-clock domain, and especially if the base frequency is high. Also, consider the power savings from reduced switching activity…So whenever possible, it can be a good practice to try and identify as many timers as possible that have the potential to be moved under a shared divided clock domain.

Simulation stuck – no progress in simulation time?!

To understand why simulation might get stuck, let’s first understand what the simulator is doing at every time step. Whenever some signal changes value, the simulation time is stopped. While time still being stopped, simulator proceeds with “delta cycle” and changes the values of all other signals that are affected with this change. If any signal is affected, simulation proceeds with another “delta cycle” checking for all other signals that are affected and the process continues in this manner, until all signal values get static. At this point, the simulation time is advanced.

So, based on the above description, we can say that the root-cause for a simulation to get stuck is that there are infinitely many “delta cycles” being inserted. There are two reasons (at least that I know) why it might be happening: i) Combinational Loops, or ii) HDL Coding style. Lets go over both in detail.

Combinational Loops

A combinational loop in the design may cause continuous updates of signal values (think ring oscillator), and hence the simulator keeps inserting delta cycles.

Note that running simulations is not the way to detect design combinational loops, because not all combinational loops ocillate! (think about the back to back inverter configuration e.g. an SRAM cell). So, it is possible to simulate designs containing combinational loops if all nodes eventually reach stable values on presentation of new inputs.

HDL coding style

This one is more annoying as it is not caused by a design issue, but rather by how the code is written and what simulator is being used. Here is an example:

// Design
module stuck (
  input  logic     in,
  output logic     out
);
  
  logic net_a, net_b;
  
  always_comb begin
    net_a   = 1'b0; // default assignment
    net_a   = in;
    out = net_b;
  end
  
  always_comb begin
    net_b = 1'b0; // default assignment
    net_b = net_a; 
  end
  
endmodule

There is no combinational loop here, and of course it is just a simple buffer which we could have done with a direct assignment of out = in. However, that’s not the point. What is shown above is a very common coding style: in an always block we start out with a default assignment and then follow that with subsequent assignments to same variables. Think of the next-state logic for example, where a frequently used coding style is to start out by assigning current state at the top of always block and then make subsequent assignments depending on inputs.

With certain simulators (at least I tried with Cadence Xcelium 19), the simulation will hang up. Lets say, the current state of variables is in=net_a=net_b=out=1’b0. When in transitions to 1’b1, f0llowing sequence of events will happen:

in is within the sensitivity list of top always_comb and so this block will get triggered.
net_a is assigned the default value 1’b0
net_a is assigned new value of in i.e. 1’b1
out is assigned the current value of net_b i.e. 1’b0
Because of events 2-3, there was an update to net_a, and as net_a is in the sensitivity list of bottom always_comb, this block gets triggered
net_b is assigned the default value 1’b0
net_b is assigned the new value of net_a i.e. 1’b1
Because of events 6-7, there was an update to net_a, and as net_a is in the sensitivity list of bottom always_comb, this block gets triggered
net_a is assigned the default value 1’b0
net_a is assigned value of in i.e. 1’b1
out is assigned the new value of net_b i.e. 1’b1
Because net_a glitched from 1’b1->1b’0->1’b1 during events 9-10, this glitch will trigger the bottom always_comb block
net_b is assigned the default value 1’b0
net_b is assigned the new value of net_a i.e. 1’b1
Because net_b glitched from 1’b1->1b’0->1’b1 during events 13-14, this glitch will trigger the top always_comb block
The back-and-forth triggering of the two always_comb blocks continues infinitely, and so we get a hang up in simulation at the time in had transtioned to 1’b1.

Best take-away recommendation from here is to avoid combinational blocks to feed back to each other, even if the signals involved are unrelated. Although there is nothing wrong with the design, it would be necessary to adjust the HDL code (maintaining logical-equivalence ) so that your simulator does not get stuck with infinite delta cycles. If the code cannot be reformatted, check if the simulator provides switches (e.g. -delay_trigger in case of Xcelium) which makes the blocks not sensitive to “zero width glitches”.

The -delay_trigger tells the simulator to wait until it’s evaluated the entire always block before deciding on whether or not there has been an event on any particular variable, and thus whether or not it should be added to the event queue. Setting this flag prevents the simulator from hanging in this case because variables which don’t change after a complete pass of the always block are not added to the event queue.

You can try out what we discussed at EDA Playground on this link: https://edaplayground.com/x/43ce. If you have the access, run Xcelium simulator and experiment using the -delay_trigger switch.

I want to leave you with a question: the sequence of events in the above analysis was initiated by in transitioning to 1’b1. What do you think if in was assigned 1’b0 at the start of simulation (check out the testbench in the playground linked), would the simulation still hang up? The default assignment is equal to value of in, surely there are no glitches?

Why a flip-flop needs Setup Time?

Let’s begin from the definition: setup time is the minimum time before active edge of the clock that the input data of flip-flop needs to become stable to its new value.

Why do the flip-flops need a setup time in the first place, and what’s actually going on during this time? Flip-flops (and other logic based memory elements) usually have a loop to lock the value in, this provides retention even when the input has changed. In short, its the settling time delays for nodes in the loops that dictate setup time.

I’ll try to illustrate setup time requirement with a concrete example, using a Master-Slave D flip-flop. The circuit schematic is shown in Figure 1.

Figure 1. A transmission gate based Master-Slave D Flip-Flop

While CLK=0 i.e. a positive edge is about to occur, the flip-flop transmission gates are in the state shown in Figure 2.

Figure 2. How a D flip-flop looks during CLK=0

Before the clock goes to 1, the D input needs to propagate through the two inverters and nodes a, b. This path is what determines the setup time of a flip-flop, and is shown highlighted in Figure 3.

Figure 3. The path in red needs to settle before positive edge. This path determines the setup time of flip-flop

Now, let us consider an example of a setup time failure. Imagine enough setup time was not allowed and the node b is still at old value when the positive clock edge arrives. This situation is shown in Figure 4, notice that second inverter on the path has not yet driven node b to its new value.

Figure 4. The value of different nodes in the circuit just before positive clock edge arrives

When the positive clock edge arrives, the Master Latch can go metastable as the node b attempts to drive old value and has contention against node a. This metastability will propagate out on the Q of flip-flop. Figure 5 shows the possible situation after positive clock edge.

Figure 5. Metastability caused by setup time failure after clock goes to 1

A quick follow-up question: do you think setup time failure is dangerous if the D of flip-flop was equal to Q?

During an interview, I also like to test using various other flavors and implementations of a flip-flop.

Floating nets in your schematic

There are some pins, or more generally nets, in your schematic which you don’t plan to use. Would it be okay to leave them floating?

What is a ‘floating net’ anyways? The following discussion is based on the terminology where I define ‘input floating net’ as an undriven but loaded net; while ‘floating output net’ is defined as a driven but unloaded net. Lets take separately the situations where a floating net is input to some logic, and where it is output (quick question: can’t it be both?)

For the case of input: it is a big NO! Never assume that an input you left floating is automatically at ground voltage. It can easily ‘float’ to any voltages across the range and affect functionality of circuit. Another disadvantage is power consumption: in worst case, the net’s voltage oscillates frequently around the threshold voltage of gates it is driving. This would lead to power draw not only in the logic directly connected to this net, but also all the switching activity propagates to downstream circuit.

The recommended approach is to cleanly tie all the floating input nets to a known voltage level.

Finally, I leave you to think about nets that are purely output, is it okay to have them floating?

Hello world!

This site will be mostly about VLSI interview questions for entry and intermediate level job positions. Along the way, I will also share some general tips, best practices and pitfalls…