The current methodology in design in most companies, and certainly many of the biggest, is that front end RTL design is done by one team with a limited set of front-end design tools. This is then eventually passed off to the physical design team who run all the scripts, do the “real” synthesis, place & route and timing verification. Essentially we have two separate groups with RTL handoff between them. This methodology worked fine for 1M gate designs a couple of process nodes ago. It doesn’t work for 10M and 100M gate designs.
In practice what happens is that everything looks fine to the front-end designers who are looking at individual blocks without the true physical information. They may be using approximate synthesis and are certainly using approximate physical information. When the back end team put the whole design together there are dozens if not hundreds of violations that need to be resolved by passing the design back to the front end designers to change the RTL. Simply redoing the design using different constraints or different scripts is not good enough.
Add to this the increasing tendency to use an offshore group of comparatively inexperienced designers to do all the front end design and this is a recipe for trouble. It takes about 3 days or so to run a design all the way through the back end, although sometimes the engineers just are not available (especially during a critical tapeout) and it can take weeks to get anything beyond the most basic feedback.
RTL engineers, not just the back end team who run the real synthesis of the entire design, need to be able to visualize and interact with the physical RTL results of their synthesis. But, critically, not at the block level but the entire design. Since RTL level blocks will be grouped into the physical hierarchy, block level information is fundamentally incorrect. This enables them to produce higher quality RTL that is free of top-level timing violations, routing congestion, designs that are too big for the floorplan or the power budget.
Of course the two things to make this possible are capacity (so that the entire design can be synthesized and analyzed as a whole) and speed (since RTL designers aren’t going to sit around for days waiting to find out what they need). Oasys’s RealTime technology, already used in RealTime Designer, is now available in RealTime Explorer, which is targeted specifically at making the front-end designer more effective and eliminating iterations between the frontend and backend design teams.
A simple-to-explain example is when a very wide multiplexor causes routing congestion. This cannot be fixed effectively in the back end. Someone who understands what the multiplexor is really doing needs to alter the RTL to something better. Just tightening the timing constraints isn’t going to do it.
Bottom line: RTL engineers can eliminate their dependence on physical design teams for top level timing & routability analysis.
More information on Oasys’s (new) website here.
UPDATE: there is a webinar on RealTime Explorer every couple of days from January 15th to 31st. Details on the webinar page here.
Podcast EP267: The Broad Impact Weebit Nano’s ReRAM is having with Coby Hanoch