I’ve been a big Synopsys fan since I started using Design Compiler. Using DC with home-brew tcl/tk based scripts which its recent baselines have eased maintainance for EDA engineers.
That said, I would recommend Tcl/Tk for the development of opensource (digital) EDA software for the following reasons:
- new users from the digital asic designers are already familiar with Tcl – coming from proprietary software
- more chances to get contributors in, as writing plugins becomes easier (excluding all software engineerings)
- the users of opensource EDA tools are not software developers, thereby if it is a Java/Qt/GTK based application, it will be a bit hard to build a community around the EDA tool.
- (this is very important to the opensource EDA community) : more compatibilities with other Tcl/Tk based apps such as magic, irsim,netgen, xcircuit,…
- It is also help us FEL to shape an automated test framework for all these Tcl/Tk based tools.
The latter is important for the digital oriented EDA tool because we already have a handful of tcl/tk based analog tools from opencircuitdesign and Graham Petley’s standard cells, I believe Tcl/Tk is the right choice to follow as in the future, there will be more chances to have more mixed signal simulation with opensource EDA tools.
The developers of Ngspice are planning to write a Tcl/Tk based frontend for ngspice and if your software uses Tcl/Tk, we will be able to ensure several design flows with opensource EDA tools. Knowing as well the fact that Tkgate provides verilog support with a simple tcl/tk based app, it would be nice to have easy and quick scripting interface to both design and simulation with your software.
Filed under: tcl
Chitlesh Goorah
I beg to differ. Tcl/Tk is an old school toolkit which is mainly a remnant from times where we didn't have anything better in Free Software (there was Motif, but it was proprietary). It looks ugly, the language is interpreted (=> slow, and can't catch errors at compile time) and has a bizarre syntax and it's just generally obsolescent. Qt/KDE 4 is a much better choice to develop any modern GNU/Linux or cross-platform application in.
Well the problem here is on one hand you have hardware knowledge and the other hand is how you will publish it.
Tcl/Tk has a long and robust experience in EDA environment(both opensource and proprietary). With Tcl/Tk, the advantage is that any time the user can use the application with its scripts and to automate their simulations (which will save days of man power during the design development cycle).
At the same time, allowing co-simulation based simulations (which to my point of view the most important thing). Opencircuitdesign.com provide the best opensource example right now.
While GTK/Qt compilations breaks from one version to another, this will distract both the packagers and the developers.
The main goal with EDA is not about developing software, but actually helping hardware design in the most efficient way by focussing only on implementing new hardware knowledge into the applications and not continuous syncing the EDA tools to its GTK/Qt API.
I think the best way to understand what I mean it is to download a webedition of quartus/ISE and use it for about 2 hours with a simple vhdl design.
Tcl/Tk is only remnant from times from the opensource software point of view, but not hardware point of view. See Synopsys has migrated their dc_shell to a tcl-based shell for the past couple reasons.
Chitlesh,
even though Tcl is a popular choice among commercial EDA vendora, I to not think it is the right choice for creating free software alternatives:
1. As Kevin Kofler said, it is very old, Tk apps does not look very nice and the syntax is bizarre.
2. Even though you might attract developers coming from the world of commercial sw, I do think you would discouragement developers coming from the Free SW world.
3. From my experience commercial sw vendors are also looking at more modern solutions: Xilinx is using Qt for their latest tools, and Altera is using Java and Qt. Of cause Tcl is still present in the cli-tools, but I see this as a sign of things to come…
Surely Trond, but then we have a tradeoff to make between opensource EDA developers and features across various design tools.
The more programming languages opensource EDA community uses, the more difficult it will be to implement tools for backend design flows.