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.

Harry

Harry,

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

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.

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”.