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 –
http://cocotb.readthedocs.org/en/latest/introduction.html
and to see those introductions:
https://www.youtube.com/watch?v=CMhimp7SxrI
https://www.youtube.com/watch?v=M2rAOF4EvVI
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
http://expect.sourceforge.net/
Tcl and cloud computing automation
http://www.plunify.com/en/platform.php (understand Tcl)
https://core.tcl.tk/jenglish/gutter/packages/tclcloud.html
- Easy multi-threaded verification scripts
http://www.tcl.tk/doc/howto/thread_model.html
http://www.beedub.com/book/4th/Threads.pdf
https://books.google.ad/books?id=gaJ_AwAAQBAJ&lpg=PA99&ots=_ulRIlgT_4&dq=tcl%20dsl%20examples&hl=uk&pg=PA173#v=onepage&q&f=false
- 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)
http://www.eejournal.com/archives/articles/20080826_vmm/
https://github.com/wltr/o7eda
- Simulators GUI / flow modifications, automation
http://www.tclcommunityassociation.org/wub/proceedings/Proceedings-2009/proceedings/guis/ModelsimGUI.pdf
https://www.youtube.com/watch?v=sjUNUiy7jVU
http://caiusproject.com/
- DSL around the whole system
http://eprints.cs.univie.ac.at/2430/1/spe09.pdf
http://www.tclcommunityassociation.org/wub/proceedings/Proceedings-2008/proceedings/nuclearDSL/stukdsl.pdf
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
- Code is data – homoiconicity often is not a usual thing, but it’s just a great benefit: http://wiki.tcl.tk/19496
- And code is data is code 🙂http://wiki.tcl.tk/21556
- Escaping style (one of the most painful aspects for Python programmers in Tcl): http://wiki.tcl.tk/41378
- And Tcl style guide at all:http://wiki.tcl.tk/708
- Common problems:http://wiki.tcl.tk/65
- Performance aspects: http://wiki.tcl.tk/348
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:
https://www.tcl.tk/software/tcltk/choose.html
http://wiki.tcl.tk/405
- 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 –
https://www.legacy.semiwiki.com/forum/content/5148-verification-tcl-what.html
Don’t forget to follow SemiWiki on LinkedIn HERE…Thank you for your support!
Share this post via:
Next Generation of Systems Design at Siemens