PCIe Webinar Banner
WP_Term Object
    [term_id] => 157
    [name] => EDA
    [slug] => eda
    [term_group] => 0
    [term_taxonomy_id] => 157
    [taxonomy] => category
    [description] => Electronic Design Automation
    [parent] => 0
    [count] => 3971
    [filter] => raw
    [cat_ID] => 157
    [category_count] => 3971
    [category_description] => Electronic Design Automation
    [cat_name] => EDA
    [category_nicename] => eda
    [category_parent] => 0

Verification with Tcl for what? – part 2

Verification with Tcl for what? – part 2
by Anatoly Myshkin on 11-10-2015 at 7:00 am

In Orion Bytes we use Tcl both for the internal research, product and different verification services. We use also SystemVerilog UVM and Python based Cocotb for different approaches. I think it’s no need to deep into the SystemVerilog and UVM principles here – today’s main verification fashion is well described through the web and books.

 About the Cocotb it’s great to read main documentation here –

and to see those introductions:

And I highly recommend to take a look at Cocotb for everyone in verification world because of it’s Python nature and nice architecture. What’s good about it:

  • existing tool with friendly community
  • rich Python possibilities from the box
  • it’s possible to use it with all (or near so) popular simulators

What’s special and better to know about:

  • it works through Generic Programming Interface (GPI) (VPI, VHPI, FLI)
  • it uses GCC/Makefiles in addition to Python

It seems to be no way to get UVM support out of the box – local modification needed, but it’s fully possible and some people already do it for the different use-cases.

Of course, It’s possible to use Tcl too for dealing with simulators through interfaces like Cocotb https://books.google.ad/books?id=QG0ECAAAQBAJ&pg=PA271&lpg=PA271&dq=tcl+verilog&source=bl&ots=lzUq5azNw9&sig=cOn6htHH_CnrdQOTtO3ehguAZkA&hl=uk&sa=X&redir_esc=y#v=onepage&q=tcl%20verilog&f=false

However I know nothing about the modern tools supporting different simulators. Why and for what services we use Tcl, for what SystemVerilog (and even Python sometimes) are not good?

One of the very important cases – modernizations (or quick fixes) and production for the large old and dead code base – when it’s a big project with many IPs (written in Verilog, SystemC, VHDL, SystemVerilog, who knows what) with Perl insertions, testbenches, documentation hell around – and it’s need to be good verified, with re-use in plans.

This situation is not something enormous in scientific / reincarnation projects. The customer understand the need of reorganization for such case – but in future, after needed production stage.
Another ones – verification flow with hardware emulation in parallel, software co-emulation, remote verification hardware interfacing, etc.

At all – there are many situations when only clear hooks with automation as close as possible to simulator / EDA tool can make everyone happy and keep things simple at the same time.
When the hard days come with no time to market – the only way is to take existing design, tool, hardware, surrounding soft and to verify fast and paranoidly.

Important tasks with some description links:

  • Infrastructure for remote (or in cloud) verification


Tcl and cloud computing automation
http://www.plunify.com/en/platform.php (understand Tcl)

  • Easy multi-threaded verification scripts


  • Hardware emulation control

Synopsys ZeBu™, Aldec HES-DVM™, etc. scripting with Tcl

  • Software driven verification (many EDA tools use Tcl, own tools are builded around it)


  • Simulators GUI / flow modifications, automation


  • DSL around the whole system


All in one language. With different OOP systems and flexible functional paradigm possibilities. But there is some special things about Tcl also:

  • The “Quoting Hell” – it’s easy to fall into it for newbies, it’s important to read this to avoid: http://wiki.tcl.tk/1726



And, of course, Tcl is not a silver bullet:

  • It’s better to know what Tcl version is embedded in your tool, here is releases changes info:


  • Different tools support different internal commands, usually internals have C/C++ basis (Tcl extensions), but it’s better to check in official documentation
  • DSLs are everywhere – usually good, but not always
  • Not so much batteries as in Python, many batteries work in other way
  • Not the only one OOP/Functional system for Tcl (it’s an advantage, but it’s not usual after Python, f.e.)

You can find the first part here –

Don’t forget to follow SemiWiki on LinkedIn HERE…Thank you for your support!

Share this post via:


There are no comments yet.

You must register or log in to view/post comments.