Third-party IP: placement, blocks, and clocks
By Pallab Chatterjee, Contributing Technical Editor - October 30, 2008
In the last few columns, I have discussed questions you should ask your IP (intellectual-property) providers before launching into a new design (reference 1 through reference 4). Wrapping up this topic, I’d like to discuss some questions regarding placement, rotation, embedded blocks, and clocks. These issues pertain to both hard and soft IP and have to do with some of the overall design issues in the construction and method for the SOC (system on chip) you are creating.
Most SOC designers organize the floorplan by minimizing the layout of the data bus. The key is to ensure that you optimally place and orient the pins for the blocks so that the data bus can flow with the fewest bends, branches, and changes in symmetry. Clearly, placement of the IP has implications for this pin connectivity, as well as for routing congestion, timing performance, and power consumption.
Unfortunately, some automatic-placement programs work from the physical data and pin-congestion data and do not necessarily place the same priority on timing and power constraints. So, designers have some decisions to make. Providers of soft IP must identify whether the block must be a single contiguous piece or whether the designer is free to distribute it as necessary to optimize pin locations. For hard IP, the designer must deal with the issues of placement orientation: rotation and reflection.
In some cases, such as with memory blocks, the timing and IR (current/resistance) drop for two instances of the same block may match only if you place both blocks on the same thermal plane and in the same orientation. Datapath blocks and most high-speed RAMs are sensitive to orientation, which can affect their performance on both an absolute and a relative basis. For that reason, the IP provider must provide guidelines about how to position such blocks in the SOC and what sort of blocks a designer may safely locate nearby.
Placing embedded blocks inside other IP blocks is also an issue. Soft IP for a megacell may consider instances of hard IP in other parts of the chip as stand-alone blocks. So, IP providers must identify within their IP any unique parameters associated with the design and physical-implementation issue of the embedded block and differentiate them from stand-alone applications in the same block.
Designers must also consider clocks because clock designs are as diverse as the types of SOCs that use them. Most companies have their own “hybrid” methods, which mix their preferred design styles with the trade-offs necessary for working with the design tools they have chosen. Third-party IP must conform to either the design tools or the styles in use because both typically differ from what the IP developer used originally to make the block.
So, the design team needs some more information. Should a designer extend the clocks inside the block or only to the top-level pins? If the clocks go inside the block, should the designer structure them hierarchically or place them flat at the top level and connect them in a “local-global” fashion to the buried pins inside? Is there a preferred clock-tree shape for reaching the block?
Designers also need to address many design- and process-specific questions. If an IP vendor can’t answer some basic questions, the blocks may not be robust and may have a questionable origin. Even if the IP vendor has answers, the interpretation of the answers and how those answers affect and apply to your design are issues that you must work out for yourself.
Contact me at email@example.com.