Hierarchical Design Flow - part 2

We have discussed in the last post  (Hierarchical Design Flow: Part1) that the important step in the Hierarchical flow is the “Setting block level constraints” and these are of 2 types- “Physical Constraints” and “Timing Constraints”. Related to Physical Constraints, basic idea is already mentioned in the last post.  Now we will discuss the basics of timing constraints.

Timing Constraint for Block is equivalent to the “Timing Budgeting” or say “Block timing Budget allocation” for example the delay at the input port / output port and all.

Timing Budgeting:

Timing budgeting is an important step in achieving timing closure in a physically hierarchical design. The timing budgeting determines the corresponding timing boundary constraints for each block in a design. If the timing boundary constraints for each block are met when they are implemented, the top-level timing constraints are satisfied.

To understand it clearly again consider the scenario of your house. You want to place your

·         Drawing room close to main entrance (reason being you don’t want that any new person travel all through the bedroom-kitchen and then finally sit in drawing room),

·         Travel time between Kitchen and Dining room should be as less as possible.

·         Bathroom should be as close to your bed room (so that you should not spend much time before going to office just in to and fro between bedroom and bathroom.

So, all these are timing constraints during the finalizing of layout of your house. Think what will happen if Kitchen is in 3^rd floor and Dining room is in ground floor. 

Similarly, in the chip designing, while you divide the design into small blocks, you have to take care about timing between block’s I/O to other block’s I/O, block’s I/O to chip I/O. If a data is required by a block A for doing some processing and this data is generated by block B, so Block A should know when it will receive the data from the Block B. Since at the top level these blocks are Black Box, so during timing budgeting we have to define the constraint at input of Block A that it will receive the data after X time (this X we have to estimate correctly on the basic of experience and knowledge of the block, usually we constraint with X+x amount where x is the margin we are keeping in case of wrong estimation).

Hahahaha … Confusing…  I know … You have read above paragraph 2-3 times to understand what I am saying. Even I have done several times after composing this. But it’s okay for the time being.

The main point which I am trying to clarify you is – if you have a meeting with your client in the evening at 6:00PM but you don’t know the traffic condition on road. So you will estimate the traveling time and add some margin which can take care the traffic condition and all.  Similarly when you are providing some timing constraint to block, you add some margin just to make sure that you will not face any problem in future.

Even if you are not clear, just read next few paragraphs and I am sure you will get the clear picture.

The block-level timing constraints are in the form of one or more “logical timing constraint points” at the input and output ports of block-level circuits. Each logical timing constraint points

·         Specifies a clock source used to clock data through the port,

·         A delay parameter specifying data propagation delay backward from an input port and forward from an output port,

·         And any timing exception associated with the data path.

Using the logical timing constraint point, the circuit design system performs independent timing analysis and optimization of each block-level circuit.

Let me explain this timing budgeting concept in other way also.

Let us suppose that you have a design and as per the specification, date should reach from port x1 to x2 with in 3sec. Now in the flat design you can meet this timing very easily because you are aware about the no of cells, types of cells and wire length between the x1 and x2 also. So it’s very easy to estimate the delay between x1 and x2.

 

Now compare it with the hierarchical design. You have figured out that there are 3 blocks in between x1 and x2. Now the block owners are different, so you want to make sure that everyone gets proper information before designing their own block. Like how much maximum delay should be there for b1/b2/b3 (like we get the specification from x1 to x2 at the top level). So it’s our job to provide the proper specification to the block owner. If I will miss this, it will be a near-to-impossible task to integrate it at the top level without any iteration. So, dividing this available 3 sec time into these 3 blocks is known as Time Budgeting in this example (On the big design also the definition is similar – Distribute the top level timing constraint effectively to the block level is known as Time Budgeting.)

Now, randomly you have assigned the 1sec delay to each block. But the cell delay (cells present inside the blockb1) of block b1 itself is exceeding 1sec ( if you will add the net delay after layout – it will be much more than 1 sec), so such type of timing budgeting is known as Under-Budgeted Timing. Similarly, if the cell delay of block b2 is very less (let’s assume 0.2sec), then estimating the 0.8sec for the net delay may be too much. And in such cases this type of timing budgeting is known as Over-budgeted Timing. So it’s very important to estimate the timing very accurately.

Now let’s assume that you have estimated the delay (timing budgeting) correctly for each block (e.g 1.5sec, 0.5 sec, 1 sec). There is a processing in block b2 on the data which is coming from the block b1, so for that, block b2 should know that when it is going to receive the data (after how much time with reference to system clock it will receive the data). Since both the blocks are handling by different person and they are closing their blocks independently, so we have to define few constraints at the input and output ports of each block in terms of timing and all. These constraints can be with respect to clock or data or both.

For example, we can define one constraint at the input of block b2 that for all calculation within the block, it can assume that data has a delay of 1.5sec (in PT it will be like – set_input_delay ). So this will be the constraint for this block with respect to this particular data and at this particular port.

Similar logic is applied to all the hierarchical design. And similar type of timing constraint you have to define for all the sub-blocks. Mostly these constraints are in the form of SDC (Synopsys delay Constraint). At a bare minimum, a design will have clock constraints, and input and output delay constraints. As a design gets more complicated, you may tend to add exception constraints. However, the fewer the exceptions the better in terms of tool run time.  Anyways the details about the timing constraints are in the different post.

What should be required to do an efficient timing Budgeting:

·         All Cells and blocks should be floor-planned. So that at least you can figure out the location of the I/O pins. If you can get a globally routed design, then it is wonderful.

·         Timing Constraint for top level should be available.

·         If you are using any hard block, the timing constraints/specification should be properly known.

Challenges in the timing budgeting:

·         Chip level constraints must be mapped correctly to block level constraints.

·         For allocating the timing budgeting to all the subblocks, we have to predict reasonable delay for global interconnects. Which is difficult before the design is physically constructed.

·         Because of not able to predict accurate delay of global nest, lots of iterations are required to close the timing in the design.

·         If you over budgeted any block, you are wasting the timing slack.

·         If you under budgeted, you will get negative slack means timing violation. It may be possible that under budget of one block is because of over-budgetting the other block. Because at the end timing should be as per specification of chip.

·         Unfortunately, the delay budgeting problem will only become more difficult as more wires become global wires whose pin-to-pin delays are strongly dependent on their actual implementation by detailed routing tools.

Once “timing budgeting” is done, each and every block act like a small chip/design. Once every block is done, these are integrated at the top level and then the timing of top level is verified.  For timing verification at the top level we only need the timing information corresponding to each block, so we can ignore other details (which can create a problem in terms of huge memory and runtime). For this purpose, we use the timing models corresponding to each sub-blocks. A timing model contains information about the timing characteristics, but not the logical functionality, of sub-module/blocks.

After generating a timing model of a block, we use that model in place of the original netlist for timing analysis at higher levels of hierarchy. This technique makes whole-chip analysis run much faster. 

Another use of timing models is to protect intellectual property. If you supply a chip sub-module to a customer for integration into the customer’s larger chip, you can provide the timing model without the original netlist. This method allows the customer to perform accurate timing analysis with the sub-module, without having access to the netlist.

There are different types of timing models which we will discuss in separate post. But most popular are QTM (Quick Time Model), ETM (Extracted Timing Model), ILM (Interface logic model) and Liberty Model.

Now in the last, as you know that there is nothing 100% perfect, Hierarchical Flow also have some limitations.

Limitation in Hierarchical Design:

·         When you place the block in toplevel, they can act as routing obstruction and due to which it may be that you have to route the wire more than your estimation and it will create timing violation.

·         Nets that interconnect the blocks have to be routed through channels between blocks. These routes tend to be long and can cause timing and signal integrity problems.

·         Routing Congestion in some place and some place is not utilized properly. So it may happen that hierarchical design requires more chip area that flat design.

·         Timing of block I/O can’t be changed during top-level optimization. so blocks must be optimized with a good I/O budget.

·         Prediction of I/O budget should be very accurate, else there may be a lot of iterations between I/O budgeting and closing the timing of block.