Negative Hold Time

Negative hold time is generally seen where a delay is already added in the data path inside the flop. This is usually done by the library vendor.Assume the flop which foundry gives us as a library part that has ports named as CLK-port, Data-Port. Now, in essence this is wrapper and should be treated as one. Inside this we have the actual flop whose ports are CLK-in, data-in. CLK-port is connected directly to CLK-in, Data-port goes through some delay element (either buffer or routing net) to Data-in. So even if the actual flop has hold requirement of say 0.2ns, if the data delay element value is 0.5ns, the library will give spec as -0.3ns HOLD requirement for the above flop. This signifies that even if the data changes 0.3ns before CLK, it can still be latched and as for the actual flop(inside the wrapper) it will still meet 0.2ns HOLD. (data changes after 0.2ns from clk change).Advantage:The biggest advantage is less iteration after layout...Easy and less painful synthesis (else HOLD fixing can be an iterative process)Disadvantage:We pay the cost in bigger setup times for above flops.

Limiting cases for Number of SRAM Cells on ONE bit-line pair

1. Frequency (and hence, Power) -- Since with increased number of SRAM Cells, there will be more capacitance on the bit-lines. An increased capacitance entails an increased delay and also an increased power consumption - 0.5 x alpha x f x C x Vswing x VDD

2. Leakage -- While doing a read, only the cell that's being read is forcing a zero onto a bit-line (i.e. draining the capacitance on that bitline), but the pass transistors of other SRAM cells are OFF and if they leak such that the bit-line-bar is being pulled low -- then this can cause a problem since both the bit-line and the bit-line-bar shall be at zero voltages.

Resetting Edge Triggered Flops

Resetting edge-catcher flops will slightly change the behavior of edge triggered interrupts around reset:


1. if the edge were asserted during reset, the edge-detection would only be valid that 1-cycle and wouldn't get caught in the core because the interrupt special register is actually reset. after i reset this register, we would start detecting these sorts of edge interrupts.


2. if for some reason an edge interrupt was asserted and held, and then the proc gets a reset, we'd catch this edge again after reset. which we wouldn't have before. this is essentially the same as the first case, but considers the chance you running before the reset.

Synopsys Backend Flow

Process - Temperation Variation Effects on Timing

Reachable vs. non-reachable X statements

Rule: do not code reachable X statements. It is OK to code non-reachable X statements.

What does this mean? Basically, the designer knows when the X statement is reachable or not. Let's take case statements as an example. If it is a full case, then it's obvious that the default X statement is not reachable. If it is not a full case, there are two options:

1) Designer knows that case expression will never take certain values and synthesis can optimize for those truly don't-care situations. This is non-reachable X.
case (condition)
2'b01: A=1'b1;
2'b10: A=1'b0;
default: A='bx;

Designer knows that 'condition' will never have the values {2'b00, 2'b11} which makes the default X non-reachable. In this situation, designer should also add an SVA assertion to check his assumption so that during simulation the assertion checker will fire if 'condition' ever equals the above values.

2) Designer knows that case expression can take on all the values, but functionally only {2'b01, 2'b10} are important. This is reachable X. We do not allow synthesis to optimize for this case because the resulting gate-level will not be equal to RTL and bugs may be inadvertently introduced. There is no easy way to check the designer's assumption about the don't-care. In this situation, all case conditions should be explicitly specified to create a full case or the default statement should be assigned to a 2-state value.