As a PnR engineer, I liked following things “specifically” about lynx:

- Looks like a mature GUI, with synopsys famillier stuff..
- Making Parallel flows, just by drag - drop and connect them. It gives a great flexibilty to designer. I think thats quite good about lynx.The same customization in Makefile based flows, becomes error prone and limited in features.
- Management cockpit, which gives a comprehensive report collection for managers, even in absence of the design engineers.

- dev.

I spent some time consulting to Intel in Chandler, AZ as did one of the Synopsys members of the flow team. As I recall, Intel’s objective was to hire very junior engineers and so they developed a flow that was very easy to run in that all the tool expertise resided in the flow. It was easy, that is, until something did not run and you had to debug. Then it was impossible

Regarding your questions:

1) Lynx works with both LSF and GRD and may work with other job queuing software. At Synopsys, it resides on Synopsys’ compute farm called DesignSphere which has hundreds of CPUs.
2) The extensibility is mainly in adding new or swapping out existing pieces of the flow. To do that, you need to know Make, and perl. Once that piece of the flow is in place, however, the person using the flow does not need to know either. If this were done today, I think Python might be the language of choice.
3) As for version management, Lynx does not natively implement source control management but integrates with existing source control like RCS, CVS, SVN. They feel that customers have their own preferences and they would rather sit on top of revision control than replace it.

As for SpectaReg, I think you exist earlier in the flow. Lynx is basically RTL2GDSII, so you could add a step in the flow to create code. Might be worth talking to them

harry

I think this is a good step forward. This will allow the engineering teams to focus more on their core competencies rather than scripting infrastructure. It is a tough problem though, since every case is different.

Having worked with some crazy flow scripting environments at Intel, for everything from front-end thought synthesis, I’m a bit weary of any flow that can do it all for all possible cases. There is a lot of custom stuff that happens in scripting environments… also there is a big concern with converting incumbent scripting and vendor lock-in.

Hence, I have some questions:
How extensible is it? Can it work with compute-farms and load balancing? In what language does it get extended? Perl and Make are nasty languages especially after getting used to ant and java based scripting. At previous employers our scripting used to integrate with our source control system to do version dependency management of the SoC hierarchy… can that be integrated? For example, chipY uses version 1.1.4 of the UART, but chipZ uses version 1.1.9 of the UART and the build process takes care of all this.

Maybe Synopsys is interested in integrating support for a web-based register automation tool named SpectaReg for capturing register spec and auto-gen of code…

Seriously though, looking forward to learning more about Lynx. It sounds like something that is long overdue.