TCL is the defacto language in EDA ASIC Design Tools (synthesis, place-and-route, static timing analysis). In my opinion, its a terrible language, especially since the tool vendors all add their own flavors. The flow control is painful to use, it lacks OOP data structures. If given the opportunity, I'd avoid it at all costs.
I'm in the EDA world since 15 years at least and I'm still surprised why many (but not all) vendors have adopted TCL as their scripting language of choice for their public API; my opinion is because it is quite close to shell scripting and so more suitable than Perl or Python for engineers which are not experienced with real software development. Another reason is due probably to the good integration with the Tk UI library that allows to easily associate a UI interface to some of the scripting tasks, something that is highly appreciated by many engineers: this is not easy to accomplish if you use Pyhton or Perl. However I agree that Tcl is a terrible language that I would avoid for any modern project.
I think Tcl's popularity in EDA has to do with the fact that the very first EDA tool, Magic, was scripted in Tcl. In fact, Magic and Tcl were written by the same person.
I think there is another reason, besides Magic being scripted in Tcl. Back in the days when some EDA companies decided on Tcl there were only a few languages which could be embedded. Tcl was the only one with some popularity, documentation about embedding including sample code and a commercially viable license.
For Perl for instance the embedding feature was largely undocumented at the time (early 90s I think) and Perl is GPL which is a no-go for commercial software. Ruby did not exist yet and Python maybe just was not visible enough.
Mentor Grpahics Calibre has a very good interface written in Tk. Also some utilities from the Encounter suite have Tk interfaces (not the whole suite of course as Tk is not suitable for graphicslly intensive applications)
The other thing I use Tk for at work is writing test scripts for hardware. Often the hardware has a serial port or an ethernet connection in it somewhere. Tcl includes serial port support, and also has an event loop that supports callbacks for both serial port and sockets. I don't think _any_ other solution beats Tcl/Tk for this type of thing. In a way, it's a shame so few people know about Tcl/Tk these days ...
For my modelsim scripts, I usually incorporate a menu in the main modelsim toolbar for my projects. The menu will incorporate menu items for things like library compile, rtl compile, testbench compile, listing all available testbenches for selecting and running. Usually my menu will be organised using submenus. That sort of thing is very quick to do, and it makes developing RTL a little less painful.
I stand corrected. Added in 2013! That explains why I haven't seen it. It won't see its way into the EDA tools where I use it for 10 years. :)
http://wiki.tcl.tk/21276
I disagree. Complex scripts end up having wonky naming conventions and odd dependencies as procedural code gets longer and longer. I'd much rather see code grouped together in classes. Its clearer when code is grouped together, easier to see the purpose, and can help reduce the spaghetti I so often see... IMO at least.
OK. I'd stick with procedural, but if you want OO there are plenty of options, your best choice would depend on how OO intensive your use of OO would be. If you want to use a lot of OO features (inheritance, etc) then a Tcl extension would be your best bet. You should be able to find something suitable even for Tcl8.4, which I think is still used in some EDA tools, even though 8.4 it's no longer developed :). At the other extreme, if you were just thinking of classes for scoping variables and procedures, but aren't going to be creating more than one object of a "type", then consider using namespaces instead. Another alternative, somewhere in the middle ground, if you wanted a class for scoping and for creating multiple objects of a "type", without heavy use of other OO techniques, then you don't need a Tcl extension for that, you can do that with about half a page of code. Dare I say it, you should be able to find all that stuff on the Tclers Wiki :)
I'll give you defacto standard, but all of the vendors have their own flavor (Synposys, I'm looking at you). Cadence still actively develops their Skill language (Virtuoso). I just saw some VPX last week too. I see it as a very old language that hasn't evolved like almost every other decent language.
> I see it as a very old language that hasn't evolved
Part of the point of the referenced article is to dispel such notions. In fact, it has evolved aggressively and continues to do so; e.g.: coroutines, effective threading, Unicode, virtual filesystems, programmable channels, etc. -- many of whose features are unmatchable in other languages.
LOL, I've always wondered why TCL didn't become more popular since it has a lot of advantages, on paper. The one thing that really turned me off of it was the way it looked, really butt ugly.
oh, its hideous. Especially when hardware design engineers write it. No tests, no real comments, just code that didn't work commented out. For all of the flack PHP receives, TCL is a hammer with the steel claw removed and replaced with a picture of a butterfly.
Yeah, I'm a hardware engineer, and I've come across code like that! But it's not Tcl's fault that hardware engineers can't write code, or even comments to go with the code.
I guess beauty is in the eye in the beholder. I like the syntax, but you're right that a lot are put off by what the syntax looks. If you get past that however, it's a very, very nice bit of kit.
Many EDA tools are using outdated versions of Tcl. 8.5 and 8.6 added significant improvements with hash objects and native OO among them. I've been writing a Tcl clone for use in VHDL and I'm happy with where the language has gone. It was only meant to be used for scripting in the original sense. I like to think of it as the executable JSON with shades of lisp. Detractors should realize that it is still well suited for its niche.
