Nowadays, verification as one of the most complex SoC, FPGA, and ASIC development flow stages always requires new approaches. The following is an introduction to TcL vs/ with SystemVerilog and VHDL, the first in a 3 part series. Part 2 will be “Tcl vs Python, Bluespec” and part 3 will be “VerTcl description”.
Of course, the industry has a traditional and common UVM and other frameworks way – too complex for a quick modifications and not for everyone – especially not for the programmers frustrated by the SystemVerilog, VHDL, etc. usage for something except design.
Many new “programming” technologies for verification (f.e. great Python-based Cocotb) are interesting but require external DPI and VPI interfacing for every simulator and are not compatible in parallel to existing UVM, OVM, OSVVM, etc.
However in enterprise new ways often needed only as help and in addition to known old methods. I will try to describe my team experience of providing new verification ways – experience with Tcl.
Just one moment – Tcl is not HDL or HVL! It is a general-purpose interpreted language useful for many practical cases – especially for scripting, DSL (domain-specific language) creation, testing and verification. Tcl is very popular as embedded EDA and CAD language in a whole industry – it is used as automation, testing, configuring, “glue” language – basically for all programming tasks needed in verification too. That’s give great benefits when it is better to work close with synthesis/compile tools, simulators, etc. But what is known about it? Tcl knowledge is not as common as knowledge of C.
In short – Tcl is powerful and expressive but a very simple programming language – experienced programmers can learn it in just a few hours or days (the syntax and semantics are completely defined in 12 rules, known as the Dodekalogue). In 2014 Tcl celebrates its 25th anniversary. There are many myths surrounding it, but the facts are:
- Interpreted language using bytecode
- Homoiconic language,metaprogramming “from the box” (all data types can be manipulated as strings, including source code)
- Fully dynamic, class-based object system, TclOO, including advanced features such as meta-classes, filters, and mixins
- Cross-platform
- Open source (based on a BSD-style license)
It is used as a testing language in many projects – f.e. SQLite, which started as a Tcl extension, relies on more than 30,000 Tcl tests.
What about main differences in general-purpose Tcl and SystemVerilog and VHDL for verification? Unlike HDLs, Tcl works outside the simulator through the interpreter which comes with EDA tool. It controls simulator through interpretation of the scripts built on defined commands – without compilation. It’s possible to control simulator in different levels – from bath (console) or GUI mode. But the most important – it is possible to put inside the simulator and control DUT or DUT with some testing environment (UVM or another) in the same way.
Vendors built-in support:
[LIST=1]
At all – simulation internals control, UVM support, extending commands to C/C++ code, configs and much more are possible from the Tcl – it is powerful and universal instrument perfect for different cases when the traditional verification methods are not the clearest way to do needed things correct. Tcl interpreter embedded in simulator provides full language support to verify clear DUT, expand existing testbenches or work with different environments.
But what are the benefits of using Tcl more intensive than simple simulator scripting/configuring like it usually done?
- It is possible to “edit, run, stop and again” Tcl scripts without recompile or exit the simulator
- Because of Tcl nature it is much more expressive and productive then SystemVerilog, etc.
- DSL support from the scratch (will be discussed later)
- Flexible creation of any data structures
- Simple static analysis automation and improvements
- The easiest way to interface with external to simulator EDA / CAD tools
- A simple way to interact with something written in other language – “golden model”, third-party library, driver draft, math model, etc.
- There is no need of anything new – Tcl is already delivered within EDA tools
Some basic figures from the “Use Scripting Language in Combination with the Verification Testbench to Define Powerful Test Cases” (Franz Pammer, Infineon).
Tcl can be used in batch mode, DO files or with GUI. It is easy to use command line or “Tools > TCL” menu. Support information about Tcl can be found in “Help > Tcl Syntax”, “Help > Tcl Man” and in official documentation. Simple Tcl examples from different vendors, more complex examples will be shown in the next parts –
[LIST=1]
Better to know that any Tcl script can control itself and all simulation process at all very flexibly – handling breakpoints and errors of simulators, setting default error actions, interrupting, etc. – the control always can be returned to the script or command line.
Share this post via:
Build a 100% Python-based Design environment for Large SoC Designs