Device synthesis strategy

Device synthesis strategy

development flow

Synthesis is an essential stage in every chip design project and is a key for constraint definition and backend flow baseline netlist. The partitioning of the design in the synthesis stage will have major impact on the device floor-plan, the complexity of the physical design and the clock tree.

When your device contains many logical entities, of different complexity levels and size, the strategy for synthesis should be given deep consideration. You will need to weigh the impact of many aspects of the design flow such as constraints definition, backend preparation, block reviews, place-and-route, timing closure and tape-out reviews.

The following point should be considered when planning the design synthesis:

1.       What is the right number of blocks to be synthesized, this decision should take into account the need to manage, review, define and maintain the constraints for each block and the need to address each signal in the interface of the block in order get a result useful for backend. Considering the overhead it is advisable to reduce the number of blocks as much as possible.

2.       The number of blocks should be limited by the design size and in special cases by the complexity of the design and the capability of the tools to handle the hard timing paths. Typically the blocks should not be bigger than the tool capabilities on one hand but must be as big as possible on the other hand.

3.        Physical placement and floor-planning considerations should determine which blocks should be grouped together for synthesis. Alignment of the synthesized blocks with the physical blocks of the design has the potential to reduce the overall complexity of the project and speed up the design convergence.

4.       Clock and power domains should be considered, striving to concentrate clock and power domains into minimal number of blocks and reducing the complexity of the top level clock structure.

5.       The expertise required to define constraints correctly considering physical design impact, clock balancing and the ability to port the constraint to the place and route tools is not trivial and inexperienced engineers may get this task wrong. It is better to reduce the number of blocks and concentrate the task at the hands on more capable team members

Selecting to synthesize too many blocks can have bad consequences on your ability to sign-off the device and hand it off to the backend team or ASIC vendor for the following reasons:

1.       Running multiple synthesis and formal verification runs when the final netlist is ready, may require a lot of resources and tool licenses. The need to run many parallel runs, review all the results and manage the delivery of all blocks may prove to be inefficient

2.       Integration of constraints from multiple blocks into a bigger block at late stages of the design cycle may prove to be inefficient as most constraints would need to be modified to fit the bigger blocks and serve as a base for physical design.

3.       The deep logical understanding of the block clocking structure required in order to define correctly the constraints of the larger block is not available to the engineers performing the integration.

In order to overcome the difficulties and unexpected issues resulting from running too many block level synthesis, the following synthesis strategy defined at early stages of the design cycle can be used

1.       Use lower block synthesis only for the purpose of cleaning up the timing and clocking of the individual block by the block designer. For the integrative blocks, define everything again according to strict and well defined methodology covering the sensitive aspects of timing closure using a clear and concise methodology.

2.       Align the synthesis blocks to the physical blocks as much as possible, taking into account all physical aspects, floor planning and clocking. This practice would enable you to maintain a constant integration of all the physical blocks of the device, ready to be delivered when the RTL is stable enough to be delivered.

3.       Using fewer blocks would enable better assignment of engineers to the synthesis and backend preparation task. The task of preparing a block for physical design requires experience and an integrative view of the device functionality, floor plan, clock balancing and full-chip timing closure.

4.       Strict management of the interfaces between the blocks, external interfaces of the device, reset propagation, memory connectivity and CDC, using a unified methodology across all the blocks of the device.

5.       When working with an ASIC vendor, it is essential to align the design synthesis and closure methodology with the vendor requirements. Simple changes at early stages of the process for the purpose of alignment with the implementation team can reduce potential schedule risks.

In conclusion, the need to plan the synthesis stage of the flow in advance and prepare for the challenge of delivering multiple blocks in a short time should not be ignored. The consequences of synthesizing too many blocks may impact the project schedule and the robustness of the delivered netlist. Assuming the backend team can resolve timing and clocking issues without guidance from the design team is often proven wrong as timing and clocking issues are sent back from the backend team.


Amnon Parnass