Floorplanning has become an important step in SoC design because it lets designers and managers get an early sense of what can be accomplished on a given piece of silicon. This is, of course, critical during the never-ending negotiation between design and marketing as to who’s on drugs and who’s sandbagging. It’s more or less the equivalent of doing furniture planning, where you draw a picture of a room and cut out rough scale versions of the furniture and move them around to get a rough sense of what will fit. Not particularly accurate, certainly not good enough for production, but much better than those back-of-the-envelope calculations that get more and more ambitious with every beer.
As such, however, floorplanning has been something of a dead-end operation. The design gets partitioned and assigned, and that part of the work most likely follows the design through to completion. But then the approximations and calculations start, with rough synthesis and placement and a high level of reliance on familiar blocks that have already been done before, so you kind of know what they’ll require. This work contributes to the planning and commitments of feature set, die size, and performance, but then it is largely abandoned as the “real” design gets going in earnest. Floorplanning is freely touted as a prototyping tool, not as a development tool.
There are some changes afoot, however, that are moving floorplanning either closer to or directly into the full production design flow. This is happening, not so much through any magic that improves overall prescience, but rather through the tool infrastructure and data structures that the tools can comprehend. Two recent announcements attest to this trend, the Hydra floorplanner from Magma, one of the big four EDA guys, and j360 from a small company called Javelin. Magma, being a full-flow provider, can offer a floorplanner integrated into their entire offering, but both floorplanners are available as point-solutions that can be integrated into flows populated by tools from other vendors.
When you start diving into the details of floorplanning tools, it’s easy to lose sight of the big picture; the space is replete with incomprehensible TLAs* and fine-granularity concepts that are important mostly to those that spend every moment doing floorplanning. But backing out a bit, there are three major aspects that appear to contribute to the move from a planning backwater into the development mainstream: accuracy, abstraction, and – with apologies for being at a complete and tragic loss to come up with a third word starting with “a” – refinement.
To help put those three items into perspective, let’s start by looking at the typical flow of tasks as a project progresses from the early planning stage. Designs of this magnitude can in no way be handled by a single person; chunks of the design are parceled out to individual team members. So there’s a key role, what I’ll call the “dispatcher/integrator,” that holds the pieces together. Now the exact role, skillset, and identity of this individual may vary by project and even throughout the project, but the element in common throughout is that this person gets the full view of the design from the highest level. Everyone else looks only at their own portion.
To begin with, this role acts as system designer and dispatcher, doing a high-level partitioning and relative placement of key high-level blocks, and then assigning the blocks to different designers to achieve the next level of refinement. This breaking of the overall design into blocks is critical in that each block is assigned a set of “pins” – signals that will talk to other blocks, and this interconnect has an important impact on the number of global signals that will be needed.
Given a block with a specified set of pins as an interface, a designer can use knowledge of existing blocks or high-level behavioral code to describe behavior and then give that back to the dispatcher, who can use the floorplanning tool to estimate the impact of these blocks on the overall die. The floorplanner uses various engines to run the estimates, but the key here is that these engines are not the same engines that would be used for full-on development. Why not use the actual engines? Well, generally, for improved performance: when you’re trying to do up-front planning, you want to be able to get quick results, make changes and do what-if scenarios, and iterate quickly. Production-level placers-and-routers take far too long. So the floorplanning engines provide speed at the expense of accuracy, and then – as traditionally implemented – the results of these engines are discarded once design starts in earnest.
The development proceeds with RTL designers specifying and confirming the functionality of their blocks, handing that back to the dispatcher/integrator, who stitches it all together and works with verification folks to make sure it all appears to work. Then the design gets assigned to physical designers, who take the logic functions and turn them into silicon structures. Each block is laid out and verified within the bounds allocated by the dispatcher/integrator, and then the whole thing can be tied together and “finished.” Obviously there’s a lot more in the details, but in order to avoid getting lost in those details, let’s leave it there for now.
This path from system designer to RTL designer back to integrator to physical design back to final integration still applies with the newer tools. The first thing that changes is accuracy. This has been approached in two different ways for obvious reasons. Because Magma has a full flow, they use their production-quality engines in the floorplanner. This means that if you are using Hydra integrated into a Magma flow, the work done up front during planning is equivalent to what would be done in full development, subject only to the completeness of the design. Based on this, Magma makes the distinction that their floorplanner is the first one designed not to be just for prototyping, but to be valid for actual production.
Because Javelin doesn’t make production synthesis or place-and-route tools, it can’t offer the complete flow, but they tout the accuracy of their engines as having been demonstrated to lie within 5% of what the final number would be. Used as a point tool within a flow using engines from someone other than Magma, Hydra’s results also would not reflect what final production would be. So as a point tool, even though these floorplanners are more accurate, they are still positioned as prototype tools – explicitly so by Javelin.
The second critical issue is abstraction. At the beginning of the design flow, there’s only so much information known about the various components of the circuit. Where a block is being reused, it might be known rather accurately; other blocks may be macros or IP visible only as black boxes. And new circuitry is known only at a very abstract level. What has changed is that these new floorplanners can accommodate designs at various levels of abstraction. It’s no longer the case where the floorplanner takes abstract rough input and the production engine takes a complete design: Hydra and j360 can accept high-level design specs or low-level implementation specs. And various blocks may have different levels of abstraction based on the starting point or simply on how progress is being made.
The third issue is related to abstraction, specifically the progressive refinement of the level of abstraction. While not eliminating the distinction between prototype and production, that line is very much blurred by the ability to refine the abstraction of the various blocks as more detail becomes available. So the same floorplanner can work with the early partially-populated blocks, and then, as the blocks are designed and implemented, the early representations can be replaced by the newer, more accurate ones for refinement.
This allows for better real-time optimization between the integrator and the teams. For example, in the early stage where the system designer partitions the design and defines the interfaces, Hydra creates the global routing that will be used throughout. The physical designers will hook into those global nets when they route their blocks. But by doing the global routing early, the interfaces can be optimized early. With either tool, if later modifications are required due some change or issue with a block as it’s being designed, that information comes back into the floorplanner, and the floorplan – and any other block’s specifications – can be adjusted. As logic is completed, and as physical designs are completed, performance, power, and die size expectations can be validated or adjusted, shapes can be refined, and any global net changes can be made, all using the same tool and database as were used in the early planning stages.
So whereas the older break between the prototype floorplan and the production floorplan happened early in the flow, now it has to happen only when moving to physical design, and only if the tool is used as a point tool. That transition never happens if Hydra is integrated into a Magma flow.
This capability helps to eliminate a big flow discontinuity during the progression from abstract idea to concrete embodiment, saving time and reducing the opportunities for introducing new errors. As to whether Javelin or Magma has the better mousetrap, well, that will be for users to decide as they review not only the broad flow and integration issues, but ease of use, price, support, and all those other things that truly separate the winners and the losers.
*Seriously?? You didn’t know that?? How uncool are you anyway?… <eyes roll, patient sigh>
It stands for “three-letter acronym.”
