If you’re like most engineers you’ve probably seen or will likely see a Tcl script and say, “What the hell am I looking at?” Don’t worry, this is a pretty common reaction among most engineers. In fact, you’ll hear many seasoned engineers complain about Tcl’s syntax and rules. I’ve even heard that everything using Tcl should just be changed to use Python! What do all these engineers have in common? They never tried to learn Tcl.
Tcl, pronounced tickle, stands for Tool Command Language and was first developed in 1988 by a Berkley professor named John Ousterhout. All major Electronic Design Automation (EDA) tools can be controlled using Tcl scripts. A common question is, “Why should I learn Tcl when I can go through the entire build and simulation flow manually in the EDA tool?” While the manual approach works great for one-off builds or figuring out the settings for the first time it is not ideal when aiming for speed and consistency.
When projects get big build times can be many hours to even days. Getting just one thing wrong in the build cycle could mean a significant loss of time and money, not to mention any extra effort trying to debug something you thought was built correctly. Tcl scripts solve this problem for you by building with the same settings and order every time. You can also access powerful features of the EDA tools that are only available through Tcl (like running place and route multiple times with different options to improve timing). When Tcl scripts are built right, there is generally little maintenance required.
Tcl scripts are a must if planning to build and automate nightly regression testing. Imagine making a change to your design and kicking off your Tcl script. You forget about it and turn your attention to other important tasks. Finally, you head out after a long day of work but your Tcl script keeps plugging along, launching all of your tests, recording results, building your design, checking timing, place, and route etc. and in the morning you come back to a clean report of success and failures. Without Tcl scripts, these things would have to be done manually.
Source control gets a lot easier too as you no longer need to source control an entire EDA project but can instead source control the Tcl script that creates the project from scratch. It becomes much easier to see changes between revisions and revert back if something breaks (and stuff always breaks).
Lucky for you, you can become the go-to guy. Not many engineers are actually good with Tcl. Yes, they’ve been able to hack scripts together and get it to work over time but they’re not interested in becoming proficient. And as any engineer knows, being the go-to guy increases your job security and can help you get raises.
In this tutorial, we’re going to build the foundation necessary to later automate our FPGA build and simulation process. This means focusing on the language syntax and nuances but only covering what an engineer needs to know about Tcl to start automating their process. Who is this introductory tutorial for? I’m glad you asked. It’s meant for those who recently graduated college and have no or very little Tcl experience. If you just transferred to a new group that uses Tcl and are feeling confused and behind then this course is for you. Who is it not for? If you’ve got a few years of writing Tcl scripts or have already taken other Tcl scripting courses then don’t use an introductory Tcl tutorial. Obviously, you’re more advanced than those for whom this tutorial was created.
