feature article
Subscribe Now

Sticking to Plan

Javelin and Magma Move Floorplanning Towards Production

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.”

Leave a Reply

featured blogs
Oct 4, 2022
We share 6 key advantages of cloud-based IC hardware design tools, including enhanced scalability, security, and access to AI-enabled EDA tools. The post 6 Reasons to Leverage IC Hardware Development in the Cloud appeared first on From Silicon To Software....
Oct 4, 2022
Anyone designing a data center faces complex thermal management challenges . Yes, there's a large amount of electrical power required, but the other side of that coin is that almost all the power gets turned into heat, putting a tremendous strain on the airflow and cooling sy...
Sep 30, 2022
When I wrote my book 'Bebop to the Boolean Boogie,' it was certainly not my intention to lead 6-year-old boys astray....

featured video

PCIe Gen5 x16 Running on the Achronix VectorPath Accelerator Card

Sponsored by Achronix

In this demo, Achronix engineers show the VectorPath Accelerator Card successfully linking up to a PCIe Gen5 x16 host and write data to and read data from GDDR6 memory. The VectorPath accelerator card featuring the Speedster7t FPGA is one of the first FPGAs that can natively support this interface within its PCIe subsystem. Speedster7t FPGAs offer a revolutionary new architecture that Achronix developed to address the highest performance data acceleration challenges.

Click here for more information about the VectorPath Accelerator Card

featured paper

Algorithm Verification with FPGAs and ASICs

Sponsored by MathWorks

Developing new FPGA and ASIC designs involves implementing new algorithms, which presents challenges for verification for algorithm developers, hardware designers, and verification engineers. This eBook explores different aspects of hardware design verification and how you can use MATLAB and Simulink to reduce development effort and improve the quality of end products.

Click here to read more

featured chalk talk

HARTING's HAN® 1A Connector Series

Sponsored by Mouser Electronics and HARTING

There is a big push in the electronics industry today to make our designs smaller and more modular. One way we can help solve these design challenges is with the choice of connector we select for our designs. In this episode of Chalk Talk, Goda Inokaityte from HARTING and Amelia Dalton examine the role that miniaturized connectivity plays in the future of electronic design. They also how HARTING's Han 1A connectors can help reduce errors in installation, improve serviceability and increase modularity in your next design.

Click here for more information about HARTING Han® 1A Heavy Duty Power Connectors