This is quite dated from a modern chip development perspective. If you are interested in learning more of where the industry is today on functional verification look at things like SystemVerilog and Contrained random verification. Things are moving to use libraries/methodologies on top of SystemVerilog like UVM (or OVM and VMM before it).
Doulous has quite good introductions:
https://www.doulos.com/knowhow/sysverilog/uvm/
I haven't gotten a chance to learn UVM yet; is it as awful as VMM? VMM is (arguably) better than nothing, but there's a lot about it that's really broken [1], which can be very frustrating if you're trying to build large-scale exercisers.
If you're interested in the subject, I also recommend reading the book "SystemVerilog for Verification" [2]; it is "the book" on the subject, and although it teaches VMM, it's an excellent reference on the concept of verification to begin with. (It suffers some from the same problem that Kent Beck's Test Driven Development book has -- it verifies excessively simple things -- but IMO, the techniques that it teaches scale much better than Beck's techniques inasmuch as they're actually possible to use in real world applications.)
[1] For instance, for some laughs, take a look at the API reference for the channel datastructure, vmm_channel: http://www.vmmcentral.org/uvm_vmm_ik/files2/vmm_channel-sv.h... -- there is just so much bizarrely wrong that I can't even list it all. "Sneak" is a good place to start, though...
I believe its more of the same. For developers that have to support all the simulation flows the largest benefit is to use something that compiles everywhere.
For history, UVM (the Universal Verification Methodology -- gee that's original) is basically the same as OVM, which was a SystemVerilog port of eRM (aka Specman). VMM is the SystemVerilog equivalent of RVM (from Vera).
I loved working with RVM and VMM, as to me channel-based transaction (and transactor and scoreboard) programming is very natural and simple to understand. And it's the route that newer languages like Go have taken.
UVM (and all the predecessors) have gone the route of TLM (transaction-level modeling), which has no explicit channels. So many of the objects talk directly to other objects, which adds unnecessary coupling.
However, the big thing that I dislike with UVM is that it is basically Enterprise Java for SystemVerilog. They have made the API's into this cookie-cutter complex enterprise abstraction, where you have to follow the macros and recipes per the book. Everyone must use the built-in macros, and use packages and factories and sequences and agents and virtual components. And your employees start talking in UVM-speak ("oh that's in his UVC").
Have you checked out the two-process method described in [0]? I used it to implement a dual-core MIPS subset with some relative ease. It was definitely better than dataflow style! Using records and enums also greatly improves ModelSim waveforms.
Verilog is more commonly used especially in the ASIC industry. VHDL is disappearing in Europe as well were it used to have some foothold. That said most chip developers are very conservative only using a subset of already limited languages like Verilog so switching between them should come easy.
Its my understanding that VHDL is limited to mostly military contractors. The rest of the world uses SystemVerilog. I think UVM is a far better methodology to learn.
High level synthesis for C is not quite there yet to be used as a replacement for Verilog or VHDL, especially for high performance hardware. Verilog and VHDL are still commonly used for hardware design.
11 comments
[ 4.5 ms ] story [ 36.0 ms ] threadIf you're interested in the subject, I also recommend reading the book "SystemVerilog for Verification" [2]; it is "the book" on the subject, and although it teaches VMM, it's an excellent reference on the concept of verification to begin with. (It suffers some from the same problem that Kent Beck's Test Driven Development book has -- it verifies excessively simple things -- but IMO, the techniques that it teaches scale much better than Beck's techniques inasmuch as they're actually possible to use in real world applications.)
[1] For instance, for some laughs, take a look at the API reference for the channel datastructure, vmm_channel: http://www.vmmcentral.org/uvm_vmm_ik/files2/vmm_channel-sv.h... -- there is just so much bizarrely wrong that I can't even list it all. "Sneak" is a good place to start, though...
[2] http://www.amazon.com/SystemVerilog-Verification-Learning-Te...
I loved working with RVM and VMM, as to me channel-based transaction (and transactor and scoreboard) programming is very natural and simple to understand. And it's the route that newer languages like Go have taken.
UVM (and all the predecessors) have gone the route of TLM (transaction-level modeling), which has no explicit channels. So many of the objects talk directly to other objects, which adds unnecessary coupling.
However, the big thing that I dislike with UVM is that it is basically Enterprise Java for SystemVerilog. They have made the API's into this cookie-cutter complex enterprise abstraction, where you have to follow the macros and recipes per the book. Everyone must use the built-in macros, and use packages and factories and sequences and agents and virtual components. And your employees start talking in UVM-speak ("oh that's in his UVC").
</rant>
What is the applicability of this skill in the modern chip development industry?
A project done in dataflow: https://github.com/jevinskie/aes-over-pcie/tree/master/sourc...
The MIPS project in two-process: https://github.com/jevinskie/mips--/tree/master/project4/sou...
[0]: http://www.gaisler.com/doc/vhdl2proc.pdf
http://dlnmh9ip6v2uc.cloudfront.net/datasheets/Dev/FPGA/Intr...