Team FED Blog

How-to Plans for ECOs - Advice From Experts

Team FED — Thu, 15 Oct 2009 13:00:00 GMT

By Bassilios Petrakis

I often wonder whether designers plan out well in advance their ECO methodology and strategy for a project. For instance, how do they determine how many spare gates to add, what type, where to place them, how to connect them. Or, what is the impact of RTL coding style, aggressive design optimization, and hierarchy ungrouping on ECO predictability

We recently conducted a Webinar on this exact topic based on customer experience, and would like share these useful tips and recommendations with you to increase ECO predictability in your flow. The Webinar is titled: "Best Practices and Considerations for Accelerating Implementation of Pre-Mask and Post-Mask ECO".

You may play back this archived webinar by visiting: http://www.cadence.com/cadence/events/pages/archive.aspx

If you have any feedback, we would love to hear about it.

Automatically Identify, Fix, and Prevent Congestion With RTL Compiler Physical

Team FED — Tue, 11 Aug 2009 15:30:00 GMT

By Ankush Sood
Principal Product Engineer

Congestion is at the heart of the design closure challenge today. With smaller cell dimensions, increased chip-size and an inclination of design houses to reduce metal layers available for routing (to save costs), designs are getting more congested. The normal approach to solve congestion has been to increase the die size which increases design cost. Hence it is desirable to have a comprehensive implementation flow in place which tackles congestion from RTL to detailed routing.

Congestion is caused primarily due to two reasons:

Connectivity - this is manifested in the RTL itself. E.g. a cross-bar switch design tends to be more congested than a basic processor design.
Floorplan - essentially how your hard macros are placed. Since the macro placement is sometimes a direct outcome of higher-level chip planning, one has no option but to live with sub-optimal macro placement.

Traditionally congestion has not been something front-end designers have worried about and nor have the commercially available front-end synthesis tools addressed the problem.

There are many reasons for this:

Congestion is really a manifestation of placement and synthesis tools have stayed away from placement
A floorplan is not available at synthesis stage or tools don't support reading one
Synthesis tools have been weak in supporting multi-objective optimizations
Techniques to estimate congestion in front-end (e.g. pin count, net-count etc.) have been generally ineffective

But, the fact of the matter is that synthesis tools create the circuit topology and connectivity and hence have a significant impact on how congested a design will be in the back-end.

Why should the front-end engineer care?

The front-end designer is the only link between the RTL developer and the implementation team. As described above congestion in the design core is a direct result of the RTL architecture. Although there are various techniques designed to alleviate congestion in the implementation tools, it often requires a RTL change. Back-end tools do not provide links to the RTL and it makes it extremely difficult to analyze and identify the root cause. Hence, it is desirable that the front-end designer be able to identify congestion hot-spots and give feedback to the RTL designer early in the development cycle. In addition, the front-end engineer really doesn't want to spend time doing DFT, verification etc. on a RTL code which would be changed frequently. Early identification of congestion saves a lot of effort and design cycles.

RTL Compiler Physical has a comprehensive set of technologies to estimate, analyze and optimize congestion at various stages in the design flow from RTL to placed gates. It looks at congestion both in global terms during RTL synthesis and also at the local level post placement.

Global estimate for congestion:

At the global level, pin-count, net-count etc. have been used before to estimate congestion but they are not nearly enough. A much better estimate is net-length. RC uses patented PLE (physical layout estimation) technology to estimate net-length even before placement. RC-Physical uses PLE to estimate total net-length and uses it as a cost factor in the technology mapping phase. In our internal benchmarks this methodology has proved a lot more effective than other global cost functions.

Post Placement:

A real congestion map can only be generated post-placement. This is very design- and floorplan-specific and hence the first requirement is to have a production quality placement engine. RC-Physical uses Encounter placement which allows it to give an accurate view of congestion. There are various techniques which are employed for a congestion analysis and optimization:

Native routing technology allows RC-Physical to estimate congestion natively. It identifies both core logic congestion and macro placement related congestion. Being able to dynamically update the congestion information is crucial in driving optimization
Congestion-aware placement using Encounter placement engine
Congestion optimization during incremental placement to relieve local hot-spots. RC-Physical uses a unique "Global Whitespace Redistribution" methodology to create and distribute whitespace around standard cells based on various parameters like local congestion, pin density and global interconnect.
Congestion-aware incremental optimization - a unique ability to cost each incremental optimization move for congestion.
Advanced congestion analysis features using a physical viewer. Not only can one analyze, but also drive congestion optimization using the RC-Physical GUI.
Cross-probing of congested regions in the design with the RTL code to find opportunities for better RTL coding.
RC-Physical can also remove cells which have been identified as bad for congestion from congested areas automatically.

The back-end engineer lives and breathes congestion, but with these new techniques, front-end engineers can start looking at more of the physical characteristics of a design, especially congestion. Catching congestion early in the design process will allow for huge turnaround time savings. One would require less iteration between front-end and back-end due to better convergence of the flows.

Do You Also Need to be a DFT, STA, Verification, Low-Power, and Library Expert? Not Anymore!

Team FED — Tue, 04 Aug 2009 13:00:00 GMT

By Jack Marshall
Sr. Tech Leader, Solutions

Our R&D team has just released a major new feature in RTL Compiler 9.1.100. It is called "Quality Analyzer". I call it "RC QA" for short - since that's how you invoke the feature (rc -qa). It's our first attempt at producing an integrated, multi-checking, front end design, signoff, analysis, and debug tool. It works at the RTL block level, the RTL Chip Level and at the Gate level.

RC QA utilizes, organizes and analyzes information from different checking operations from several successful Cadence tools: Conformal Constraint Designer, Conformal Clock Domain Crossing, Conformal Low Power, RTL Compiler and HAL. It brings all this information to one centrally organized graphical user interface and enables the RTL designer to selectively check different aspects of their design prior to signing off their design at different levels of development.

Oh, and did I mention that it's a free feature? You must have the licenses to operate the different aforementioned Cadence tools - but if you do - then RC QA can access them for you automatically. RC QA can also help you invoke the different checking tools individually (assuming that you are familiar with the tools), by creating a dofile for each tool with all of your design information loaded into the dofile.

By centralizing all the information in one tool, RC QA can become an integral and important step in every design team's implementation flow. RC QA's rulesets can be customized, the severity of each violation can be chosen, and the users only have to learn one interface to check their design against several different critical design areas (Clock domain crossing, constraints, libraries, Design for Test, low power intent, synthesizeability etc).

Today I'm just going to talk about how to invoke the tool, how to create a configuration file - since it's different than how you usually invoke and use RTL Compiler and how to run some checks. I'll let you check out the user manual "clds_user.pdf" (in the doc directory under the 9.1.100 RTL Compiler executable path) to learn more about the different aspects of the tool (reports, analysis, debug, messages, filtering, customizing etc).

You can also read about all the different checks RC QA performs in "clds_rules.pdf" (also in the doc directory). Then for my next blog article I'll write about a design debug flow I use that utilizes RC QA.

To invoke RC QA:

Type "rc -qa" from the linux or unix prompt. This will automatically invoke the GUI - so make sure you have your "DISPLAY" environmental variable defined (setenv DISPLAY <machine_name:0>). Note: you typically run the checks in "batch mode" (i.e. no gui) then use the GUI to analyze & debug & fix the violators.

To configure RC QA:

This is different. RC QA does not currently use the same attributes and variables that RTL Compiler uses. RC QA was developed separately and uses a very simply formatted Tcl configuration file to load up the libraries, HDL files, and constraints to be checked by RC QA.

A sample configuration file looks like this:

set LIB_SEARCH_PATH "./library"
set STD_LIBRARY_LIST "slow.lib"
set CHECKS_ON_NETLIST false
set VHDL_FILE_LIST ""
set VERIFICATION_SETUP_FILE ""
set HDL_SEARCH_PATH "./rtl"
set VERILOG_FILE_LIST "channelarb.v clock_divider.v dma.v dma_mac_pwr.vdmacontrol.v dmaextdevbridge.v dmaslave.v"
set TOP_MODULE "dma_mac"
set LEF_FILE_LIST ""
set SDC_FILE_LIST "./MODS/rc.dma_mac_m.sdc"
set CPF_FILE_LIST "./dma_mac.cpf"
set CAP_TABLE_FILE_LIST ""
set INC_DIR "./rtl"
set HDL_LINT_CHECK_OPTIONS ""
set CONSTRAINTS_RULE_FILE ""
set CLOCK_RULE_FILE_SETUP ""
set CLOCK_RULE_FILE_VERIFY ""
set DFT_SETUP_FILE "./dft_setup.tcl"

You also have the option to create a configuration file interactively using a menu choice from the GUI. To create a configuration file interactively in the GUI select the menu item:

File -> Configuration File -> Create

That will open a multi-tabbed window with blank slots for where you can enter your design data information. After you create the configuration file you will need to read it in - saving it off to a file is not enough.

File -> Configuration File -> Read

Or you can use the command:

read_config_file <config.file>

Check the monitor window to insure that your config file and all of your design data was read in succesfully - if not - go back and edit the file and re-read it. Once the configuration file has been properly loaded - you are ready to run some checks:

Running RC QA Checks:

You have a choice of 7 different types of checks to run on your design data, I purposely used the phrase "design data" since these checks can analyze more than just your HDL files - they check your HDL files, library files, CPF file, SDC file or dft setup files.

The 7 checks are:

Library Checks
HDL Lint Checks
Clock Domain Crossing Checks
Constraint Checks
Low Power Checks
DFT Checks
Physical Checks

You can activate the checks via GUI menu:

Tools -> Signoff Checks

Or you can execute them via command:

signoff_checks

Either way, once a check has been run - it can not be repeated unless the configuration file is re-read (which is easy to do - just re-read the configuration file).

I'll leave the rest of the operation of the tool up to you to explore. I'll write about a practical flow using RC QA in my next blog where I'll explain how to use the filters to cut down on information overload and how to systematically go through the violators in a straightforward manner.

Until then,

Good luck designing.

RTL Compiler's New "Spatial Technology"

Team FED — Tue, 28 Jul 2009 17:50:00 GMT

By Jeff Flieder
Sr. Solutions Manager

Over the last few years, RTL Compiler has added a significant number of features targeted toward users that require more physical awareness in their synthesis flow. We first introduced the PLE (Physical Layout Estimation) flow that allows a very low impact way to accurately model 80-90% of the wires in a design in order to take the most advantage of RC's advance global optimization algorithms in a physical context.

We then introduced RC-Physical (RCP), which provides the ability to run silicon virtual prototyping within RC in order to accurately model all the wires and perform both logical and physical optimization based on detailed physical information. This includes the ability to natively measure and optimize for congestion. In addition, RCP allows the user to write out a full placed DEF as a starting seed for physical design, ensuring that the physical design team will see things exactly how the logic design team saw them at handoff.

RTL Compiler spatial technology is the latest advance of physically aware synthesis in the RTL Compiler toolbox. This methodology fits in between a PLE based flow and an RCP flow in terms of how much physical modeling is performed. In addition to the initial synthesis with PLE, RC-Spatial runs a fast placement on the design in order to better predict the remaining 10% to 20% of nets that are difficult to predict with PLE alone. Since RC-Spatial is running a fast placement with a production placement engine, all of the information in the floorplan is used in order to achieve the most accurate results. These include things like die box, core box, aspect ratio, preplaced instances, pin locations, blockages, rows, power routing and pre-routes.

RC-Spatial will result in better prediction of the pre-CTS results and would be expected to have some positive effect on QoS due to more accurate wire modeling. It will also work without a floorplan, although having a floorplan is highly recommended and will improve the quality of prediction. It is important to note that the QoR measured in the synthesis environment may in fact "look" worse than PLE alone, as the PLE estimates for longer nets are by definition optimistic.

The RC-Spatial flow is expected to greatly improve physical prediction, providing better guidance to logic optimizations, and RC-Spatial will also apply some basic optimization techniques for congestion alleviation. For heavily congested or over-utilized designs, you'll want to use the full capabilities of the RC-Physical solution. RC-Spatial is available in all packages of RC. As with any new technology, make sure you're using the latest update release of RC when you try this.

DesignWare and AmbitWare Demystified - Why and When to Avoid?

Team FED — Fri, 24 Jul 2009 13:23:00 GMT

By Diego Hammerschlag
Sr. Technical Leader
Team FED

Most, if not all, synthesis tools today support the use of Synopsys DesignWare or a vendor specific brand of <vendor>Ware such as Ambit's AmbitWare, Cadence's ChipWare and others. I have been frequently asked on the purpose of <vendor>Ware being that many of the functions implemented by DesignWare and its derivatives are readily supported by the tools today using much simpler higher level constructs.

<vendor>Ware is used primarily in the following situations:

To address shortcomings of legacy synthesis tools and/or specifications
Reduce implementation time & risk for modules with limited or no value-add
Purchased IP
Legacy support

I will first cover (2), (3), and (4) while (1) will be covered later in more detail

(2) Reduce implementation time & risk for modules with limited or no value-add:

<vendor>Ware not only covers simple design that can be easily coded using higher level constructs, but it also includes slightly more complex designs such as Error Code Correction(ECC), Cyclic Redundancy Checker(CRC), as well as others. These types of designs are well defined and well understood and frequently provide little opportunity for companies to differentiate their product hence it is sometimes attractive for users to take advantage of the pre-implemented benefits of <vendor>Ware. Not only that, but one could argue, and EDA vendors certainly do, that the reuse of such designs by many customers results in less likelihood of bugs and issues with their implementation.

(3) Purchased IP

Several vendors also market larger IP as <vendor>Ware. This is slightly different than what (1) and (2) cover. It refers to larger designs as well as associated verification environments or additional verification IP. This kind of vendor<Ware> includes PCI cores, USB cores, and others. These kinds of <vendor>Ware can have a substantial cost associated with it.

(4) Legacy support

Frequently <vendor>Ware is used and supported as a result of legacy designs and usage in third party IP

(1) To address shortcomings of the tools and/or specifications

To understand the main purpose of <vendor>Ware we need to go back some time. Early synthesis technology did a poor job, or was simply not capable, of optimizing datapath components such as adders and multipliers. Moreover, standards like IEEE1364-1995(Verilog HDL) did not have comprehensive support of signed arithmetic at the time. As a result, coding certain operations may have been cumbersome and error-prone at times. EDA vendors came up with <vendor>Ware to address these shortcomings in their tools and the specifications of the time. <vendor>Ware essentially addressed the issue by hard-coding and parametrizing certain operations. The recent "designWare minpower" announcement by Synopsys is a good illustration of an application of the <vendor>Ware solution. In that case, <vendor>Ware addresses Design Compiler's power optimization shortcomings.

When & Why to Avoid <vendor>Ware?

<vendor>Ware was an adequate solution at the time but it has several drawbacks.

Restricts portability:
EDA vendors would love you to use their brand of <vendor>Ware (DesignWare, AmbitWare, etc.) since to a large extent, it ties your implementation to their tools.

Equivalence checking challenges:
It is a well-documented issue that equivalency checking is a weakness of the <vendor>Ware solution. Vendors normally provide a behavioral model for functional verification as well as logic equivalency. This model is different from the synthesis model used internally by the tools and hence there is always a chance for non-equivalency issues.

ECO difficulties:
Another aspect of <vendor>Ware that can present challenges is that of ECOs since the synthesis model is, from a user perspective, a black box hence making it difficult (or impossible in some cases) for a user to implement and verify an ECO.

It is unnecessary!!!
Modern synthesis tools have addressed the original challenges, and coding without the use of vendor<Ware> allows the tools the greatest degree of flexibility to optimize. Modern synthesis tools can perform complex CSA transformations, speculation, and many other optimizations. By keeping coding at a higher level, the tool has more flexibility to optimize in the context of the overall design goals and the surrounding logic and therefore yielding better results. A frequently overlooked aspect of <vendor>Ware is highlighted by "DesignWare minPower" - the original <vendor>Ware was not created with power in mind so now you have to manually choose if you want the version that gives the best area or the one that gives the best power. Higher level constructs do not have this issue since the tools will optimize according to the goals specified by the user as well as the context of where it is used.

The main benefits of avoiding <vendor>Ware are:

Ability to use traditional EC & verification flows
No linkage to any specific vendor or tool
Ability for tools to fully optimize resulting in better Quality of Silicon
Goal-agnostic implementation of the target design
Portable code (across technologies, tools, etc.)
Reduction in legacy issues
Increased ability to implement ECOs

Please send me your comments and questions if you have any.

Good luck with your project.

RC Design Explorer: Find the Right Balance of Power and Performance

Team FED — Fri, 24 Jul 2009 13:00:00 GMT

By Paul Weil
Sr. Product Engineer

You might be aware that RTL Compiler has had the ability to synthesize top-down to multi-supply multi-voltages (MSMV) and optimize across them. Lowering voltage levels can be a great way to reduce switching power, but it comes at the cost of reducing performance. As we have talked to customers, we have found that many do not take advantage of this opportunity to reduce power because they do not know how to find the right minimum voltage levels that still allow them to meet their performance goals.

This is why we developed Design Explorer or "DEX" as we call it, in RTL Compiler 9.1. The concept is simple - you just tell RC what range of voltage levels to explore for each domain, and RC will execute a bunch of exploration runs that generate a tabulated summary of the performance, power, and area for each exploration scenario. These runs are what we call exploration runs - the runtime is about 60% of a full synthesis run, but you get performance and power numbers within about 5% of what the full synthesis run would be. This allows you to exhaustively explore your options and see which one(s) you would want to take through full synthesis.

If you consider a trivial example of a library with 3 possible voltage levels, and a design with 2 power domains, the possible MSMV architectures are 3²=9. That's a lot of scenarios to explore, and it's an extremely trivial example. Even a more "typical" design that would have 4 power domains would result in 3⁴=81 scenarios to explore. There is just no way you would do this manually. DEX enables this to be done automatically, and in parallel if you have the resources for it.

To get started, you would read all your normal design information - HDL, constraints, etc, including your library CPF - then specify the exploration domains. In this example, our library has three voltages to explore - 0.8v, 0.9v, and 1.08v:

dex_define_exploration_power_domain -name default -default -voltage_range {0p8 1p08}

dex_define_exploration_power_domain -name macs -voltage_range {1p08 1p08} [find / -maxdepth 4 -inst ethernet_mac*]

dex_define_exploration_power_domain -name bridge_pcm -voltage_range {0p08 0p9} {bridge pcm_inst dma_mac_mult}

This defines the exploration domains - the first two will explore all three voltage levels, the third will only explore across 0.8v and 0.9v. Then we need to create and execute the exploration scenarios:

dex_create_exploration_scenarios -design ${DESIGN}

dex_execute_exploration_scenarios -design ${DESIGN}

Once the runs are done, the summary report and detailed reports for each scenario will be available. The summary report is generated by:

dex_report qor_summary -design ${DESIGN}

Specific scenario reports can be generated as-needed. For a specifc thread/scenario:

dex_report thread_info -design ${DESIGN} -thread thread_3

Once you have decided what scenario looks like it will give you the balance of performance, power, and area that you're looking for, you can run it through a full synthesis by writing out the scripts and CPF for that scenario (scenario #3 in this case):

dex_write_scenario -scenario scenario_3

From there you could do a full synthesis in RC or even with RC-Physical.

This was a quick overview - there is a full chapter on this capability in the Low Power in Encounter RTL Compiler user guide. But hopefully it gives you an idea of how you can take advantage of this new capability to get started with an MSMV approach to greatly reduce power without compromising your performance or schedule.

How to Pick a Synthesis Tool - The Right One for You - Part 2

Team FED — Tue, 07 Jul 2009 13:00:00 GMT

By Kenneth Chang, Core Comp AE, Team FED.

In my previous blog, I had written about how "Synthesis matters." Snippet below.

<snip> I had a boss that once said that all synthesis tools are same. This guy knew his stuff, been in the industry forever. He said "synthesizing with Tool X may give different results from Tool Y, but once it gets into P&R, it was all the same, P&R will take care of the rest." In a heavy benchmark, I proved him wrong. Synthesis does matter (and I'll give more details in a future blog). <snip>

Now, why does synthesis matter? Isn't a netlist just a netlist? Who cares right? Doesn't P&R tools just fix the synthesis netlist as long as it meets timing, make it all fine and dandy in the end anyways? Specifically, what can synthesis Tool A give that Tool B can't? The key is, it's not about just Tool A vs. Tool B. It's about an entire design flow.

We always talk about garbage in garbage out. Literally, if you feed garbage into your P&R backend tools, you will get garbage out.

So, let's define garbage designs. These are designs that are over-constrained. These design have become over-sized because of so called 'intelligent' margin built-in by over-clocking the design. Margin your clocks by 15%-30% to make sure you meet timing in the backend - right? Not a good idea. Now you pass on some headaches to your backend team. Maybe create congestion issues which may not have happened if you didn't add these extra budgets. Even worst, maybe your design won't fit in the floorplan that was created for it. Great, now you have to change or grow your floorplan. Hopefully, you don't have to grow your die. I've seen this before having been a designer before joining Cadence ... which is why I believe synthesis matters.

Now let's define quality designs, with a seed netlist that matters for P&R work. These are desgins constrained as specified. No extra clock margining needed, so the design created is as expected. This synthesis netlist is received by the P&R tools with open arms. At this point, this honest netlist goes through transformations in the backend if needed, where it should happen. Buffering, increasing cell drive strengths, some restructuring. Quality in, quality out.

So, the key to success is picking a synthesis tool that will give you the best end P&R results. It shouldn't be measured after just synthesizing with Tool A or Tool B. RTL Compiler is architected to help achieve this goal. (for more aggressive needs, there has always been the discussion and the option of using physical synthesis, for example, with RTL Compiler Physical, which takes this a step further with even better correlation up front to backend results)

Synthesis does matter. So pick your tool wisely!

Kenneth Chang

Free Online Training: Conformal LEC

Team FED — Mon, 22 Jun 2009 13:30:00 GMT

By Kenneth Chang
Core Comp AE
Team FED.

If you didn't know, Conformal's very own AE team put together some cool training materials for their customers based on large demand to help both new and intermediate users.

It's free. And it's personal with Clay and Bruce. You may have even worked with them in the past!

Click here to get free Conformal LEC Training and give it a try! (if you don't have a Sourcelink account, it's easy to apply. Sign-up here)

Of Rights & Wrongs: The Bottom-up vs. Top-down Methododology Debate

Team FED — Mon, 22 Jun 2009 13:15:00 GMT

By Diego Hammerschlag
Sr. Technical Leader
Team FED

The top-down vs. bottom-up methodology decision is one that design engineers should not take lightly. It carries ramifications throughout the hole flow and can certainly make or break a project if not careful. Such methodology decision can impact:

Quality of Silicon (QoS)
Equivalency Checking
DFT implementation
Reuse methodology
ECO methodology
Schedule

These are only a few important parameters of the many that the top-down / bottom-up debate can impact hence the decision should only be made after carefully review of trade-offs and goals. Ultimately there is no right or wrong since many of the answers change depending on the design and the goals of the design team. In the CDNlive Paper, "From RTL to Tapeout with your ASIC vendor", Omer Ansari(Ubicom) and Kenneth Chang(Cadence) discuss some of the trade-offs involved in making this top-down vs. bottom-up methodology decisions. The paper also delves into a hybrid methodology used successfully at Ubicom. Finally, the paper discusses some of the challenges of SI closure. Please follow the link above for the full paper.

Low Power Guide from Industry Leaders

Team FED — Thu, 28 May 2009 13:00:00 GMT

By Kenneth Chang, Core Comp AE, Frontend Solutions.

Low power concerns continue to drive companies' needs for optimized ASIC methodologies, which is why one of the Si2 key initiatives continues to be the standardization of Low Power Intent.

Below is just a couple of snapshots of posters which show the value that the Power Forward Initiative members, Si2's committee and its standards bring to the ASIC community, including a downloadable free Low Power Guide. Actually, it's more than just a guide - it's a comprehensive reference methodology manual. Even if you haven't started to work on Low Power designs today, this guide is an excellent guide to keep on your desktop to keep abreast of the happenings in the Low Power world, and how to create solid flows, just in case you need it one day.

Once you register, you gain access to a wealth of information(it's an entire book), including practical information from top ASIC industry leaders as shown below and their take on what is important to survive in the ever growing Low Power world.

Check it out and download the free LP reference methodology manual at www.powerforward.org!