800x100 static WP 3
WP_Term Object
(
    [term_id] => 157
    [name] => EDA
    [slug] => eda
    [term_group] => 0
    [term_taxonomy_id] => 157
    [taxonomy] => category
    [description] => Electronic Design Automation
    [parent] => 0
    [count] => 3886
    [filter] => raw
    [cat_ID] => 157
    [category_count] => 3886
    [category_description] => Electronic Design Automation
    [cat_name] => EDA
    [category_nicename] => eda
    [category_parent] => 0
)

Is the RTL Design Flow Broken?

Is the RTL Design Flow Broken?
by Daniel Payne on 01-15-2013 at 11:02 am

I’ve taught Verilog classes and used logic synthesis tools for ASIC and FPGA designs, so was interested to hear about Oasys Design Systems. I attended their webinar at 9AM today, so I’ll share what I learned about their approach to logical and physical synthesis. This approach competes with tools like Design Compiler Graphicalfrom Synopsys and Encounter RTL Compiler from Cadence.

Dan Ganousis
from Oasys Design Systems opened up the webinar on time and dove right into the presentation.



Is the RTL Design Flow Broken?

  • Top-level timing issues cannot be identified and resolved by RTL engineers
  • Routing congestion issues cannot be identified and resolved until placement is completed
  • Long synthesis runtimes limit the ability to “change and check” (ie 3 days) RTL code and constraints
  • Power estimation at early architectural state needs to be based on implementation accuracy

A 28nm customer got silicon back and measured power at 2X over budget, then had to fix and re-spin to get power under control.

Can I get my SoC design done correct first time, and done on time?

RTL Design Flow
During early RTL development you don’t have the physical feedback on what the power might be, unless you have a workable physical synthesis tool.

What Does Oasys Offer?
A high capacity logic synthesis tool based on top-level synthesis, not starting at gate optimization like tools created in the 1980’s (capacity limited). Up to 10X faster RTL synthesis run time, with 100 million instance capacity.

How does it work?
Place the RTL first, to make a virtual physical partition.

After placement, then do gate level optimization.

Top-Level Timing
Since placement is already done virtually, you can now see more accurate timing at the top-level, early in the design process at the front end where RTL code changes are easy to implement. Congestion can also be addressed early on because hot-spots can be detected and fixed in days, not months at the back-end.

Using traditional synthesis and P&R it can take 48 hours to get a physical design implemented, while with Oasys a front-end designer can get results in 8 hours with similar floor plans. Physical knowledge is imperative early on with front-end RTL designers, not waiting for a back-end designer.

Now, RTL engineers can explore early floorplan options.

RealTime Explorer
This new approach gives front-end RTL designers a physically awareness early on in the design process, reducing iterations at a higher and earlier level. A GUI makes this physical feedback easier for front-end designers to understand.

How many nets don’t meet timing (Timing histogram in Green, unmet timing in Red)?

Highlight timing violations, then see them in physical layout, then find Source code.

The RTL engineer has actual physical design that can be cross-probed back to RTL.

Find and fix congestion by using the GUI.

SPARC core floor plan, with critical timing map, leakage power map, routing congestion map, and the scan chain map.

Demo used the UltraSPARC T1 processor (Takes < 2 GB of RAM).

Live Demo
Shankar Vellanthurai did the live demo of RealTime.

Physical view, netlist view, source code view, detailed timing, easy to cross-probe between the physical implementation with netlist and RTL source code. A front-end RTL design can quickly see the consequences of RTL source code on the physical implementation.

It’s still up to the RTL designer to fix timing violations by re-factoring their source code.

Power map (swapped transistor power types). Visualize UPF / CPF power values. Congestion view in physical view will then trace back to RTL source code, so you can make re-factoring changes to decrease congestion.

You can cross-probe from the physical views to discover what RTL source code is causing an issue.

Because you have a virtual physical placement you can run timing reports and identify early violations.

Timing paths are also displayed showing the RTL endpoints.

In the physical view you can see the timing violations in red.

After physical synthesis and virtual placement you can cross-probe between layout and RTL source.

Routing congestion is another physical view choice.

Leakage analysis can be visualized in the GUI.

Root cause analysis of timing violations, DFT violations.

Dan
People have completed 28nm tape-outs with RealTime Designer, they are also doing 20nm designs now.

50% of the top 10 Semi companies are using RealTime today.

Summary
The approach to logical and physical synthesis taken by Oasys is different than that of Cadence and Synopsys, so it’s something worth considering if your present RTL design flow feels like it is broken or just takes way too much time.

Register for the next Oasys Webinar HERE.

Share this post via:

Comments

0 Replies to “Is the RTL Design Flow Broken?”

You must register or log in to view/post comments.