Hacker News Reader

Comment by abfan1127 | Hacker News Reader

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.

View on HN

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.

http://en.wikipedia.org/wiki/Magic_(software)

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.

Very good point, especially the GPL license one.

have you ever seen a GUI interface for EDA tool scripts?

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)

sorry, I meant a GUI written for in-house scripts, not from the vendor.

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.

> it lacks OOP data structures.

Untrue. Part of the point of the referenced article is to dispel such outdated misconceptions.

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

And that's a good thing. Scripting EDA tools OO style? No thanks. Simple procedural code is all that's needed for that kind of stuff.

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 :)

The newer versions of Tcl have OOP. Even the older ones support it through addons like itcl [incr Tcl].

I quite like Tcl. Many of the 3D graphics packages have a Tcl console (at least the older ones do) and the OBJ file format is basically a Tcl file.

Tcl/Tk was a fast and easy way to get a GUI up and running on Unix/Linux. Expect is still extremely useful at times.

It may not be the greatest, but at least it's a (pseudo)standard. Once upon a time each tool used its own language- Tcl, scheme, skill, vpx, etc.

It lacks some advanced features, but so does bash- to me, Tcl makes the most sense when you think of it as a shell.

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.

> Tcl makes the most sense when you think of it as a shell.

I think of it as lisp's rather less clever little brother.

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 agree, but it still leaves a bad taste in my mouth...

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.

I think its a good analogy of "executable JSON with shades of Lisp". Can you share the TCL clone?

Tcl 8.5 should still support [incr Tcl] (a.k.a. iTcl).

Reply on news.ycombinator.com