3 ms·

My only issue with Tcl is that aweful, aweful language that one way or the other managed to become the language of choice for EDA tools. I hate it with a passio

My only issue with Tcl is that aweful, aweful language that one way or the other managed to become the language of choice for EDA tools. I hate it with a passion. Other than that, it’s fine…

rluoy 2y ago
"The Tcl scripting language grew out of my work on design tools for integrated circuits at the University of California at Berkeley in the early 1980's. " History of TCL, https://web.stanford.edu/~ouster/cgi-bin/tclHistory.php https://web.stanford.edu/~ouster/cgi-bin/tclHistory.php
d_tr 2y ago
I have hated industrial automation software from a particular manufacturer, but Structured Text, while a crappy language, was the least of my issues. The tools were really bad and the provided codebase amateurish. Maybe it's a similar situatuon with these expensive proprietary EDA tools often being quirky?
- tverbeure 2y ago
  Proprietary and non-proprietary are quirky across the board. For any piece of software, you literally keep hundreds of official releases, sub releases and patch releases, and if the design support team knows what they're doing, they provide was to specify the right version for each design module. I can live with it: these tools are very complex and they don't have a lot of users. It's hard to make the bug free. But you don't make software buggy deliberately. It's different for Tcl. Some people made a conscious decision to create that POS language and others thought it was a great idea to add it to their software.
sitkack 2y ago
I understand how you feel, but if EDA had settled on Python, many of the same things we see would still be prevalent. They would be slightly reduced due to Python being a slightly less dynamic language than TCL but I am not sure it would matter. The problem with EDA automation software is that it has been historically written by people with low skill in software development. Their domain of expertise is hardware. These shops also have not had for the most part a cohesive culture that spanned projects. For an org that focuses on digital design, the other 80% of that task is verification, but this has been prone to outsourcing and has had more churn on project to project. I could be wrong, as I am outsider in this industry but this is what I see from my interaction with the EDA space. It puts up with horrible bugs, tools are hard to compose, the installers are crufty and target ancient OS versions. The secrecy within in the industry itself has made it a very late participant in open source. So much conspires against any language that EDA would adopt.
- IshKebab 2y ago
  I dunno I think the actual EDA tools are pretty good (I've used VCS and Questa mostly). Bugs are quite rare, the GUIs are pretty sophisticated and surprisingly usable given how niche software it is. They're even starting to support recent OSes (though you have to use the lowest common denominator so we're still on RHEL 8). I think they mainly just don't really care about improving the scripting interfaces. TCL is an industry standard at this point and it is a shit language but it's not the main thing you're doing. In my experience it's really the customers have low skill in software, so they won't even be asking for anything better than TCL. Hacky Bash scripts are the standard here so if anything TCL is an upgrade. This is an industry where CI is a novelty. I still have to deal with people who think CI should be a very quick sanity check and the testing should mainly be manual.
pjmlp 2y ago
It was great for us, AOL and Vignette back in 1999. But it is also the reason why I don't use any dynamic language without JIT for production code, unless I have no say in the matter. We took advantage of being a MSFT gold partner, moved into .NET when it wasn't yet known to the world, and our founders eventually moved on, and OutSystems was born out of our learnings.
robinsonb5 2y ago
Just to add an opposing viewpoint: I first encountered Tcl when tinkering with Quartus, and initially hated it with a passion. Once I eventually figured out which types of brace to use in which context, and started to appreciate having variables and conditionals available in .sdc files, the loathing started to give way to a grudging respect. Now I really appreciate the elegant simplicity, the ridiculous ease with which it can be integrated into a C/C++ project, the ability to script JTAG communication with a running project (complete with Tk-based UI), the lack of dependence on any online repository or source of truth. But especially I appreciate the lack of churn, which means the same scripts will work with the current release of Quartus as well as a version from more than a decade ago (needed because newer versions dropped support for newer devices.)
_ph_ 2y ago
The irony is, Tcl stands for Tool Control Language, it was created to control the EDA tools of the time. So it is no coincidence, that it is popular in the EDA world. I,for myself, quite like it for the intended tasks. The other irony is, considering that article, that the Cadence analog tools (Virtuoso, Allegro) are using a nice Scheme dialect called "Skill" for that purpose. So not the whole EDA world is centered around Tcl.

My only issue with Tcl is that aweful, aweful language that one way or the other managed to become the language of choice for EDA tools. I hate it with a passion. Other than that, it’s fine…

rluoy 2y ago

"The Tcl scripting language grew out of my work on design tools for integrated circuits at the University of California at Berkeley in the early 1980's. " History of TCL, https://web.stanford.edu/~ouster/cgi-bin/tclHistory.php https://web.stanford.edu/~ouster/cgi-bin/tclHistory.php

d_tr 2y ago

I have hated industrial automation software from a particular manufacturer, but Structured Text, while a crappy language, was the least of my issues. The tools were really bad and the provided codebase amateurish. Maybe it's a similar situatuon with these expensive proprietary EDA tools often being quirky?

tverbeure 2y ago
Proprietary and non-proprietary are quirky across the board. For any piece of software, you literally keep hundreds of official releases, sub releases and patch releases, and if the design support team knows what they're doing, they provide was to specify the right version for each design module. I can live with it: these tools are very complex and they don't have a lot of users. It's hard to make the bug free. But you don't make software buggy deliberately. It's different for Tcl. Some people made a conscious decision to create that POS language and others thought it was a great idea to add it to their software.

sitkack 2y ago

I understand how you feel, but if EDA had settled on Python, many of the same things we see would still be prevalent. They would be slightly reduced due to Python being a slightly less dynamic language than TCL but I am not sure it would matter. The problem with EDA automation software is that it has been historically written by people with low skill in software development. Their domain of expertise is hardware. These shops also have not had for the most part a cohesive culture that spanned projects. For an org that focuses on digital design, the other 80% of that task is verification, but this has been prone to outsourcing and has had more churn on project to project. I could be wrong, as I am outsider in this industry but this is what I see from my interaction with the EDA space. It puts up with horrible bugs, tools are hard to compose, the installers are crufty and target ancient OS versions. The secrecy within in the industry itself has made it a very late participant in open source. So much conspires against any language that EDA would adopt.

IshKebab 2y ago
I dunno I think the actual EDA tools are pretty good (I've used VCS and Questa mostly). Bugs are quite rare, the GUIs are pretty sophisticated and surprisingly usable given how niche software it is. They're even starting to support recent OSes (though you have to use the lowest common denominator so we're still on RHEL 8). I think they mainly just don't really care about improving the scripting interfaces. TCL is an industry standard at this point and it is a shit language but it's not the main thing you're doing. In my experience it's really the customers have low skill in software, so they won't even be asking for anything better than TCL. Hacky Bash scripts are the standard here so if anything TCL is an upgrade. This is an industry where CI is a novelty. I still have to deal with people who think CI should be a very quick sanity check and the testing should mainly be manual.

pjmlp 2y ago

It was great for us, AOL and Vignette back in 1999. But it is also the reason why I don't use any dynamic language without JIT for production code, unless I have no say in the matter. We took advantage of being a MSFT gold partner, moved into .NET when it wasn't yet known to the world, and our founders eventually moved on, and OutSystems was born out of our learnings.

robinsonb5 2y ago

Just to add an opposing viewpoint: I first encountered Tcl when tinkering with Quartus, and initially hated it with a passion. Once I eventually figured out which types of brace to use in which context, and started to appreciate having variables and conditionals available in .sdc files, the loathing started to give way to a grudging respect. Now I really appreciate the elegant simplicity, the ridiculous ease with which it can be integrated into a C/C++ project, the ability to script JTAG communication with a running project (complete with Tk-based UI), the lack of dependence on any online repository or source of truth. But especially I appreciate the lack of churn, which means the same scripts will work with the current release of Quartus as well as a version from more than a decade ago (needed because newer versions dropped support for newer devices.)

_ph_ 2y ago

The irony is, Tcl stands for Tool Control Language, it was created to control the EDA tools of the time. So it is no coincidence, that it is popular in the EDA world. I,for myself, quite like it for the intended tasks. The other irony is, considering that article, that the Cadence analog tools (Virtuoso, Allegro) are using a nice Scheme dialect called "Skill" for that purpose. So not the whole EDA world is centered around Tcl.