Lynx Design System? – It’s The Flow, Stupid!

(This is the 2nd in a 3 part series on the newly introduced Synopsys Lynx Design System. You can find Part 1 here) .

When Pilot was introduced some years back, one of the bigger discussion points concerned what to call this thing. I’m not talking about whether to call it Pilot or some other name. I’m talking about what-the-heck-is it.

  • Is it a flow?
  • Is it an environment?
  • Is it a system?
  • Is it a platform?

In the end, the marketing folks decided that it was an environment, which included a flow and other stuff like:

  • Tools for prepping IP and libraries
  • A configuration GUI
  • A metrics reporting GUI

Lynx adds a Runtime Manager to the product, so now it is no longer an environment. It’s a Design System. Well, with all due respect to the marketing folks who wrung their hands making this decision, I’d like to say one thing:

It’s the flow, stupid!

Sure, the metrics GUI can create pretty color-coded dashboards that even a VP can understand. “We’re red, dammit. Why aren’t we green”. And the Runtime Manager can configure the flow, and launch jobs, and monitor progress, also with pretty colors. And the “Foundry Ready System” … well, I’m still trying to figure out what that even means, even though I know what it is. But it’s the flow at the core of Lynx (nee Pilot nee Tiger nee Bamboo) that is the real guts of the product and the reason you’d want to buy it or not buy it. It’s the engine that makes Lynx run. So let’s take a tour.

At the core, the Lynx flow is a set of makefiles and Perl scripts that invoke Synopsys tools with standardized tcl scripts. (Clarification: All the scripts in the flow are tcl – one tiny bit of perl which comes with ICC-DP is re-used but anything the user touches is going to be in Tcl). Together, these scripts implement a flow that has been designed to produced very good results across a large number of designs.  The flow operates with a standard set of naming conventions and standard directory structures. In all, the Lynx flow covers all the steps from RTL to GDSII implementation.

There are actually 5 major “steps” in the flow:

  1. Synthesis
  2. Design-for-Test (may now be combined with #1)
  3. Design Planning
  4. Place and Route Optimization
  5. Chip Finishing

Lynx Flow

Each of these steps is further broken down into smaller tasks. For instance, Place and Route might be divided into:

  • Placement Optimization
  • Clock Optimization
  • Clock Routing
  • Routing
  • Routing Optimization
  • Post Route Optimization
  • Signal Integrity Optimization

The scripts also implement the analysis tasks such as parasitic extraction, static timing analysis, formal verification, IR drop analysis, etc. In all, they cover everything a design team needs to go from an RTL design to tapeout. If there is a task that is missing (e.g. Logic Bist insertion), you can add an entire new step to the flow by modifying the makefiles by hand, or using the GUI to create a new task. If you want it to use a 3rd party tool, you can do that too by having the makefile call that tool. Third party tools actually are a little more complicated than that, but that gives you the idea. (Clarification from Synopsys: Third party tools can be executed. The system is very open to including other tools – Synopsys just doesn’t promote this loudly. A key thing about the Lynx flow is that you do not ever need to even look at a Makefile, or execute a make command  – “no Makefile knowledge required” – since it is all handled graphically through the GUI – people should not be worried that they have to learn make).

So, you may ask, what’s the big deal? After all, isn’t this the way that most design teams / CAD teams implement their flows, more or less. What is so special about a set of makefiles and tcl scripts?

Honestly, you probably could go off and design something very similar on your own. And it might be better or more closely suited to your needs than this standard flow from Synopsys. Only you can make that choice because only you know what is important to you. The advantages of using a flow like Lynx from Synopsys are:

  • 90-95% of what you need you can get off-the-shelf and you can modify the rest if you need to.
  • The flow is being constantly updated with each new major release of the Synopsys tools so you don’t suffer from “flow inertia” and find yourself with an outdated flow.
  • The flow is being constantly tested, not just through regressions, but by the Synopsys consultants using it on real customer projects. So the quality is high.
  • In areas such as power, Synopsys can optimize the flow across multiple tasks and steps and tools, something that it would be hard for non tool experts to do.
  • You can use the engineers who would have been designing your flow to do real work.

Of course there are disadvantages as well:

  • It’s an all Synopsys flow, so you have to use Synopsys tools to get the most benefit. If you currently use other 3rd party tools, then the benefit is reduced proportionately. Or you can convert to the Synopsys tool, but that costs money and time and maybe it’s not the best-of-breed as a point tool.
  • The scripts are actually divided into many pieces of scripts that call each other. Although very modular, this can be confusing for a novice user if he is trying to modify the flow or debug a problem.
  • Lynx has a “strongly preferred” directory structure that is very deep. They do this for some good reasons, but this might go against the norm at your company and ignite a “religious feud”.
  • Once you’ve invested in this flow by training up your organization and building your own scripts and utilities on top, you’re pretty committed to Synopsys. Not a problem if Synopsys is your long term partner, but if you want to fool around or have a fear of commitment, not so good.

The bottom-line is that Lynx provides you with the same tool flow that the Synopsys consultants use on their own projects. If you are using an all or predominantly Synopsys flow, then I think it’s worth looking at.

(Friday: What I like. What I don’t like. And What Could Be Better)

Part 1 – Synopsys Lynx Design System Debuts at SNUG

Part 3 –  Strongest Lynx

Part 4 –  The Weakest Lynx

Part 5 – The Mising Lynx – The ASIC Cloud

harry the ASIC guy

Tags: , , ,

4 Responses to “Lynx Design System? – It’s The Flow, Stupid!”

  1. Jeremy Ralph says:

    >>>the Lynx flow is a set of makefiles and Perl scripts that invoke Synopsys tools with standardized tcl scripts.

    I believe many engineers would appreciate the choice to work with cleaner languages like Ruby, Python, and Java. In the web domain, API providers have figured out how to make customization and extension a language independent exercise. It would be good if EDA could do that too.

    >>>There are actually 5 major “steps” in the flow: 1. Synthesis

    I was wondering how high up the RTL this Lynx flow went. I was hoping for some front-end flow automation/metrics for simulation, SoC modularity, and maybe a touch of virtual prototyping. Synthesis is pretty low level in terms of RTL.

    >>>Sure, the metrics GUI can create pretty color-coded dashboards that even a VP can understand.

    I used to joke with co-workers that the main reason e/Specman was so successful was because it gave the decision makers some good graphs.
    On a similar note, I recently purchased 97 tips for doing business in tough times and interestingly #23 was “measure everything”.

  2. harry says:

    Hi Jeremy,

    Yes, I think that Python would be the language of choice today. If I were to create my own vendor neutral flow, that’s what I’d use. And the flow would not only support traditional job distribution, but virtualization for cloud computing as well. Ah, but that’s getting into my next post 😉

    No. There is nothing in Lynx further up the food chain than RTL. I’ve asked them about incorporating the Synplicity tools for FPGA prototyping which would be very useful, but that is not on the roadmap.

    For verification, they did have some capability under TIGER some years ago, but I think the product BUs have supplanted the whole verification management offering with their own products.

    As for the “color-coded dashboards”, I was probably too glib in an effort to prove a point and be humorous at the same time. Visualization of data can certainly help in extracting useful information and spotting trends and gaining insights that would otherwise go un-noticed from a sheet of numbers. Unfortunately, I have only used the old metrics GUI so I could not comment on the new GUI or the runtime manager. And the point was that the flow is the real value. A Ferrari without the engine is not very useful in the end.

  3. John Eaton says:

    No. There is nothing in Lynx further up the food chain than RTL. I’ve asked them about incorporating the Synplicity tools for FPGA prototyping which would be very useful, but that is not on the roadmap.


    We do a lot of fpga prototyping and target our asics for multiple vendors. We have even done dual sourced asics with two vendors. You cannot treat fpga prototyping as a step on the road to making an asic. You have to treat it as if it were a completely separate vendor. You start with the same rtl source files but you then split into two paths. One gives you an asic and the other gives you fpgas.

    Where does floorplanning fit into lynx? That tends to be very interactive and involves several different groups. It also needs to feedback modifications back into the rtl. Where is this loop?

    John Eaton

  4. harry says:

    Hi John,

    1) WRT FPGA prototyping, I agree that it’s a pretty different flow and sometime different RTL (e.g. replacing SRAMs and IO, partitioning, etc.). Still, I think having a common root RTL and being able to fork the different flows would be good.

    2) WRT multiple ASIC vendors, that can be handled in Lynx by creating multiple “nodes”. You’d then basically have 2 separate projects with the similar flows.

    3) Floorplanning is done in IC-Compiler in the Lynx flow. I’m not sure where the manual floorplanning is done, but the placement feedback between IC-Compiler and synthesis is done using the DC-Topographical and/or DC-Graphical capabilities of DC-Ultra. As for feedback into the RTL, I assume you are referring to hierarchical changes. That must be a manual process I’m thinking.


Leave a Reply