WP_Term Object
(
    [term_id] => 119
    [name] => Altair
    [slug] => altair
    [term_group] => 0
    [term_taxonomy_id] => 119
    [taxonomy] => category
    [description] => 
    [parent] => 157
    [count] => 15
    [filter] => raw
    [cat_ID] => 119
    [category_count] => 15
    [category_description] => 
    [cat_name] => Altair
    [category_nicename] => altair
    [category_parent] => 157
)
            
PBS 2020 Webinar Semiconductor 800x100 1
WP_Term Object
(
    [term_id] => 119
    [name] => Altair
    [slug] => altair
    [term_group] => 0
    [term_taxonomy_id] => 119
    [taxonomy] => category
    [description] => 
    [parent] => 157
    [count] => 15
    [filter] => raw
    [cat_ID] => 119
    [category_count] => 15
    [category_description] => 
    [cat_name] => Altair
    [category_nicename] => altair
    [category_parent] => 157
)

The Art of Flows, Part II

The Art of Flows, Part II
by Paul McLellan on 03-31-2012 at 3:00 pm

 Part I (here) looked at a bit of the history of scripting, makefiles and other approaches to more formally specify and institutionalize EDA design flows.

The most sophisticated tool I know that looks at this issue is RTDA’s FlowTracer.

One big difference between FlowTracer and other approaches is that it does not depend on the user accurately specifying which output files are dependent on which input files. FlowTracer can dynamically track this as tasks are run, and so the manual input is really just some hints about dependencies to get things started. This is especially important for inputs that don’t change all that often, such as technology files, but when they do, you don’t just get shot in the foot, you blow your whole leg off.

Another aspect of FlowTracer is that it is aware of EDA tool licenses and can cope with them not being available. Whereas in principle a lot of jobs might be run in parallel if there are enough servers available, the number of licenses may be the limiting factor and FlowTracer knows not to try and start more concurrent executions than there are licenses.

In a similar way, the limiting factor might not be the number of licenses but the number of servers available. In fact, since FlowTracer allows you to specify hardware requirements it is possible that there are plenty of servers available, just none that are big enough. It is no use running a big place and route on a small server, and it is wasteful to tie up a big server with a generic job with no significant resource limits.

A modern SoC might involve a hundred major blocks, each of which involves hundreds of files and dozens of steps. FlowTracer has two levels of detail to make looking at all this data manageable. You can look at the low level detail of individual tools and individual files, or at the higher level when a lot of this detail is abstracted away leaving “just” the top levels and how far they have progressed.

This combination of two-level abstraction, a lot of automation, awareness of server capacities, licenses, how to handle errors, automatic dependency detection and other features makes for a very robust environment to encapsulate the design methodology of a company and deploy it from the methodology experts to the designers themselves.

Watch the 5 minute video demo.

Download the free e-book The Art of the Flow from here. Or download the FlowTracer white paper “Two weeks to tapeout, do you know where your files are?


Comments

There are no comments yet.

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