14 ms·

Tcl is single handedly responsible for billions of dollars of damage in the EDA industry

by typon 7y ago

gugagore 7y ago
I wonder if you mean Tcl is bad, or that the damage is caused by Tcl being powerful and obviating the need for version upgrades of special-purpose software. Or something else.
- PhaseLockk 7y ago
  I'm not that guy, but here's my interpretation: tcl is used as the embedded scripting language in the vast majority of EDA tools. In some ways it performs this job quite well, with tool companies providing functions which parse their arguments like inputs to a shell script. For example, you can call report_timing -from ... -to ... When the commands have 50 optional parameters, this method of calling is convenient. However, the problem is that it has been pushed to its absolute limit. Massive automated design flows consisting of tens to hundreds of thousands of lines of often highly unstructured tcl are present at most semiconductor companies. All of this code is written by VLSI engineers who have not much software training. These engineers take advantage of the highly dynamic nature of tcl to solve their problems quickly... and the result is often an unmaintainable mess of code. As an example, I've almost never seen anyone use tcls module system, instead its just scripts using the `source` function to load other scripts. Since the language is not mainstream among software engineers, there is very little material on best practices, and semiconductor companies are extremely locked down meaning there is no open source tooling to speak of. So VLSI engineers continue producing spaghetti code to handle all of the implementation. Obviously I am speaking in very broad strokes, so there may be companies out there that do it right.
- seabird 7y ago
  Tcl itself isn't really the problem. EDA tooling is generally a dumpster fire (queue horror stories about checking bitstream files into VCS because there's no guarantee the compiler will ever spit the same one out again, even if nothing changed), and Tcl is used to make patchwork fixes to glaring tooling issues. This is all fine and good, but when a vendor can no longer change or fix tooling without running the risk of breaking a large customer's Tcl abomination, the flexibility that it provided is now a problem that's dragging everybody down with it. All of this goes without mentioning that electrical engineers that often get saddled with this aren't very good programmers. People are excited about SymbiFlow for a reason. The hype in spite of how unlikely it is that it will ever match vendor tooling is a testament to the situation.
  - dublin 7y ago
    The simple fact is that the vast majority of the people writing programs aren't very good programmers, even if they've been trained to be. We need more languages like Tcl and Lua that are quick and easy for beginners to pick up and become productive with. Add easy interfaces to AWS services for back-end programming, and a Tk-like interface that dumps out JS code for web app front-end programming, and you'd have a real winner...
    - blacksqr 7y ago
      I'll quote another comment on this discussion: Take a look at http://www.androwish.org/index.html/wiki?name=jsmpeg+SDL+Video+Driver http://www.androwish.org/index.html/wiki?name=jsmpeg+SDL+Vid... for an experimental approach to displaying Tcl/Tk applications in a web browser.
_sbrk 7y ago
Having written at least one tool in Tcl/IncrTcl, widely used within our company for chip-level verification, I would tend to disagree with you. Using a standard Tool Command Language to control your EDA Tools, is a wonderful concept. Tcl's numerical handling leaves something to be desired ([expr 1 + 1]), but in other aspects, such as node/list processing, it is stellar.
jhayward 7y ago
I take your comment to mean that the damage is caused by the choice of embedded scripting language being Tcl, rather than the fact that EDA engineers aren't software engineers and don't build testable, maintainable, reliable code bases. What would have been a better choice? Lisp, as in AutoCad? Something else?

Tcl is single handedly responsible for billions of dollars of damage in the EDA industry

by typon 7y ago

Tcl is single handedly responsible for billions of dollars of damage in the EDA industry

I wonder if you mean Tcl is bad, or that the damage is caused by Tcl being powerful and obviating the need for version upgrades of special-purpose software. Or something else.

PhaseLockk 7y ago
I'm not that guy, but here's my interpretation: tcl is used as the embedded scripting language in the vast majority of EDA tools. In some ways it performs this job quite well, with tool companies providing functions which parse their arguments like inputs to a shell script. For example, you can call report_timing -from ... -to ... When the commands have 50 optional parameters, this method of calling is convenient. However, the problem is that it has been pushed to its absolute limit. Massive automated design flows consisting of tens to hundreds of thousands of lines of often highly unstructured tcl are present at most semiconductor companies. All of this code is written by VLSI engineers who have not much software training. These engineers take advantage of the highly dynamic nature of tcl to solve their problems quickly... and the result is often an unmaintainable mess of code. As an example, I've almost never seen anyone use tcls module system, instead its just scripts using the `source` function to load other scripts. Since the language is not mainstream among software engineers, there is very little material on best practices, and semiconductor companies are extremely locked down meaning there is no open source tooling to speak of. So VLSI engineers continue producing spaghetti code to handle all of the implementation. Obviously I am speaking in very broad strokes, so there may be companies out there that do it right.
seabird 7y ago
Tcl itself isn't really the problem. EDA tooling is generally a dumpster fire (queue horror stories about checking bitstream files into VCS because there's no guarantee the compiler will ever spit the same one out again, even if nothing changed), and Tcl is used to make patchwork fixes to glaring tooling issues. This is all fine and good, but when a vendor can no longer change or fix tooling without running the risk of breaking a large customer's Tcl abomination, the flexibility that it provided is now a problem that's dragging everybody down with it. All of this goes without mentioning that electrical engineers that often get saddled with this aren't very good programmers. People are excited about SymbiFlow for a reason. The hype in spite of how unlikely it is that it will ever match vendor tooling is a testament to the situation.
- dublin 7y ago
  The simple fact is that the vast majority of the people writing programs aren't very good programmers, even if they've been trained to be. We need more languages like Tcl and Lua that are quick and easy for beginners to pick up and become productive with. Add easy interfaces to AWS services for back-end programming, and a Tk-like interface that dumps out JS code for web app front-end programming, and you'd have a real winner...
  - blacksqr 7y ago
    I'll quote another comment on this discussion: Take a look at http://www.androwish.org/index.html/wiki?name=jsmpeg+SDL+Video+Driver http://www.androwish.org/index.html/wiki?name=jsmpeg+SDL+Vid... for an experimental approach to displaying Tcl/Tk applications in a web browser.

_sbrk 7y ago

Having written at least one tool in Tcl/IncrTcl, widely used within our company for chip-level verification, I would tend to disagree with you. Using a standard Tool Command Language to control your EDA Tools, is a wonderful concept. Tcl's numerical handling leaves something to be desired ([expr 1 + 1]), but in other aspects, such as node/list processing, it is stellar.

jhayward 7y ago

I take your comment to mean that the damage is caused by the choice of embedded scripting language being Tcl, rather than the fact that EDA engineers aren't software engineers and don't build testable, maintainable, reliable code bases. What would have been a better choice? Lisp, as in AutoCad? Something else?