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.

 

Hierarchical Design Flow - part 1

Again its not possible to explain it in a single post- so divided into multiple post. I am not sure how many of you are aware about the Hierarchical Design Flow, but now a days its very common in the Design Companies. So in short, you should be aware about the basics of this approach/flow.

Whenever we start any big work, we try to break down that work into the small-small work. In software terminology – A big program is divided into the sub-program and sub-programs into the modules (example-OOPs is based on similar approach -People those aren’t aware about this approach- skip this line).

Now, similar type of approach, when you are going to implement in the VLSI design – That Design is known as Hierarchical Design. As the size increases, complexity increases and then it become very difficult for a single person to do the routing/timing closure/ optimization etc of such a big-complex design. Apart of this there are limitation with respect to the Memory of the computer device and runtime of the EDA tools. So it is good to break/divide such a complex task into small-small task.  For example, Let us suppose, you have to replace 10 4-input-AND Gates with 20 2-input-AND gates, so for that you have to load the whole design (which has almost millions of gate). So for such a small task, you have to waste a big chunk of memory.

To resolve these issues, hierarchical design methods come into picture.

The basic flow of hierarchical design is simple…

1. Dividing a design into multiple blocks (sometimes referred to as sub-chips, sub-blocks, modules, hierarchical blocks, etc.).
2. Designers can work on the blocks separately and in parallel from RTL through physical implementation. 
3. Working with smaller blocks keeps tool run-time short.
4. Block-level timing closure should be relatively easy to achieve compared to the timing closure for the entire chip.
5. Once all blocks are finished, they are integrated to create the final chip. Here these blocks are treated as Black-box (only few specific information available at the top level).
6. Close the timing of the final chip or you can say that close the timing between the blocks. If proper work has done in the starting, it should be close in first iteration (Ideally).

Pictorial view of the Hierarchy based Design Flow is as … (Source: EEtime)

 

-->

In the above fig we have mentioned 2 types of hierarchy.

• Physical Hierarchy: Physical hierarchy is based on back-end considerations such as cell placement, I/O placement, macro placement, interconnect routing and associated timing issues.
• Logical Hierarchy: Based on the function of the design modules/blocks, which is usually determined by the designers and their HDL coding methods.

These 2 are different but still there should be a correlation between these 2 so that we can reduce the time needed to achieve the timing of the chip. 

 

-->

Hierarchical design Flow benefits:

1. Improved Productivity when designing complex chips.
2. Run time is fast because you can work over individual block and those will be small in size in comparison to the full design.
3. In case of any timing issue, you can fix individual block.
4. Incremental functional and timing fixes is possible after timing closure.

In the traditional flat ASIC flow,

1. If there is any problem in the timing after routing, then there are equal chances that you have to go back to the architecture level design for correcting that. 
2. Memory limitation can also create problem
3. Run time in the case of multi-million gate design is huge.

One thing keep in mind, I am not saying that Full-flat design is useless or Hierarchical design has replaced that approach completely. But Hierarchical design offloads the burden of Full-flat flow (traditional flow) during the implementation phase. Even now, at the signoff stage, most of the companies (even I can say 99% companies) are using Full-flat-flow for rechecking everything and to make sure nothing is messed up in between. But after using hierarchical approach, even in implementation phase, designers have saved a significant time.

 

Now if you pay attention, you come to know that as per the pictorial diagram, there is only 1 important step in the Hierarchical flow and that is the “Setting block level constraints”.

Block Level Constraints are of 2 types:

1. Physical Constraint: These constraints depend on the floor-plan of the top level. Means where exactly this block will be placed on the top level.
• Size and shape of the block
• Pin placement with in the block
2. Timing Constraint: Block timing Budget allocation or say timing budgeting. Like the delay at the input port / output port and all.

 

-->

Always remember that these constraints can’t be decided in a single iteration. For setting these constraints we have to use both the top-down and bottom-up approaches. Like position of the pin in the block depends on the position of the pins required in the final chip. In the similar way, if there is any hard macro (you can’t change the position of the pin in that), so you have to place that block in such a way that it should be closer to the pin position of the final chip. So in the complex design with large number of blocks, you have to do few iteration and you have to use both the approaches in parallel. 

During deciding these constraints, in most of the cases we add enough margins so that we can cover any inaccuracy in estimating (which we have done in early phase of the design) at the end of design cycle.

A uniquely identifiable element.

Physical Constraint:

List of physical constraints are: (it contain all the top level and block level constraints)

• Die area
• Core Placement area
• Utilization
• Aspect Ratio
• Port side
• Port Location
• Cell location
• Pin Location
• Placement Blockage
• Wiring keepout
• Voltage Area
• Site Row

If you have notice, all physical constraints are related to the location. It’s like when you are designing a layout of your house, then you are applying a lot of constraints like window should be in left, door should be in North, some corner is fixed for Kitchen. So similarly in chip designing, you have to place a lot of constraints as per the requirement/specification of the chip or sometime as per the specification of the IP blocks.

In the next part we will study about the Timing Constraint.