Verilog Simulator

[Ahmed Alfadhel]

Hi @D@n

Thanks for your replies to my questions . They are very helpful . 

I just want to know does it possible to download Verilator on Windows? 

If not possible , what are the available options for me to download a Verilog Simulator on Windows? 

Thanks.

[D@n]

@Ahmed Alfadhel,

I put instructions together for that some time ago.

Let me know if they need to be updated any.

Dan

[Ahmed Alfadhel]

Hi @D@n,

3 hours ago, D@n said:

I put instructions together for that some time ago.

I read your article, and I didn't know how to install Verilog on Windows. So I installed Oracle VM then Kali Linux and then Verilator.

However, when I came back to your lecture lsn-01 and tried to build the first design by using Verilator, an error exist when I carried out the commands in Terminal window (as shown in the 2nd attached picture). 

Pls, see the attached picture. 

Looking forward your help.

Thanks

 

[D@n]

@Ahmed Alfadhel,

Don't put spaces between the "-" and "Wall", or between the "-" and the "cc" and you'll do better,

Dan

[xc6lx45]

As a 2nd opinion, I would not recommend Verilator to learn the language. It does work on Windows (MSYS) but I'd ask for a good reason why you need Verilator in the first place instead of a conventional simulator.

Have a look at iverilog / gtkwave: http://iverilog.icarus.com/

It works fine from standard Windows (no need to create a virtual machine). You'd call it through the command line though (hint: create a .bat file with the simulation commands to keep them together with the project. Hint, the abovementioned MSYS environment is pretty good for this, e.g. use a makefile or shell script).

[D@n]

@xc6lx45,

6 hours ago, xc6lx45 said:

As a 2nd opinion, I would not recommend Verilator to learn the language. It does work on Windows (MSYS) but I'd ask for a good reason why you need Verilator in the first place instead of a conventional simulator.

This is a valid question, and a common response I get when recommending Verilator.  Let's examine a couple of points here.

1. Verilog is a very large language, consisting of both synthesizable and non-synthesizable subsets.  I've seen more than one student get these two subsets mixed up, using constructs like "always @* clk <= #4 !clk;" and struggling to figure out why their design either doesn't work or fails to synthesize.
2. I've seen a lot of student/beginners try to use these non-synthesizable constructs to generate "programs" rather than "designs".  Things like "if (reset) for(k=0; k<MEMSIZE; k=k+1) mem[k] = 0;", or "always @(*) sum = 0; @(posedge clk) if (A[0]) sum = B; @(posedge clk) if (A[1]) sum = sum + (B<<1)", etc.
3. Since verilator doesn't support #delay's, nor does it support 'x values, in many ways it does a better job matching what the synthesizer and the hardware will do together, leaving less room for confusion.
4. C++ Verilator based wrappers can be used just as easily as Verilog for bench testing components.  That said, ...
5. The Verilog simulation language is a fairly poor scripting language for finding bugs in a module when compared to formal methods.  There's been more than once that I've been deceived into thinking my design works, only to find a couple cases (or twenty) once I get to hardware where it didn't work.  Indeed, both Xilinx and Intel messed up their AXI demonstration designs--designs that passed simulation but not a formal verification check.  As a result, many individuals have posted unsolved bugs on the forums, complained about design quality, etc.  (Xilinx has been deleting posts that aren't flattering to their methodology.  I'm not yet sure about Intel in this regard)  Formal methods tend not to have this problem.  Why waste a student's time teaching a broken design methodology?
6. So, if you aren't using Verilog for your bench test, then what other simulation based testing do you need?  Integration testing where all the modules come together to interact with the hardware in some (potentially) very complex ways.  At this point, you need hardware emulation, and Verilator provides a much better environment for integrating C/C++ hardware emulators into your design.

My favorite example of this is building a VGA.  VGA's are classically debugged using a scope and a probe since the definition of "working" tends to be "what my monitor will accept."  The problem with this is that you lose access to all of the internal signals when abandoning your simulation environment.  On one project I was working on, this one for the Basys3 where there was a paucity of memory for a video framebuffer, I chose to use the flash and to place prior compressed frames onto the flash.  I would then decompress these frames on the fly as they were being displayed.  My struggle was then how to debug decompression failures, since I could only "see" them when the design ran from hardware.  Verilator fixes this, by allowing you to integrate a display emulator with your design making it easier to find where in the VCD/trace output file the bug lies.

Another example would be a flash simulation.  Most of my designs include a 16MB flash emulation as part of their simulation.  This allows me to debug flash interactions in a way that I doubt you could using iverilog.  This allows me to simulate things like reading from flash, erasing and programming flash--even before I ever get to actual hardware, or perhaps after I've taken my design to hardware and then discovered a nasty bug.  More than once is the time where I've found a bug after reading through all 16MB of flash memory, or in the middle of programming and something doesn't read back properly.  I'm not sure how I would do debug this with iverilog.

A third example would be SD-card simulation.  I'm currently working with a Nexys Video design with an integrated SD card.  It's not a challenge to create a 32GB FAT based image on my hard drive and then serve sectors from it to my running Verilator simulation, but I'm not sure how I would do this from iverilog.  So far in this project, I've been able to demonstrate an ability to read a file from the SD card--FAT system and all, and my next step will be writing data files to it via the FATFS library.  I find this to be an important simulation requirement, something provided by Verilator and quite valuable.

Finally, I tend to interact with many of my designs over the serial port.  I find it valuable to interact with the simulation in (roughly) the same way as with hardware, and so I use a program to forward the serial port over a TCP/IP link.  I can do the same from Verilator (try that with iverilog), and so all of the programs that interact with my designs can do so in the same fashion regardless of whether the design is running in simulation or in hardware.

Yes, there are downsides to using Verilator.

1. It doesn't support non-synthesizable parts of the language.  This is the price you pay for getting access to the fastest simulator on the market--even beating out the various commercial simulators out there.
2. Verilator is an open source simulator, and so it doesn't have the encryption keys necessary to run encrypted designs--such as the Vivado's FFT or even the FIFO generator that's a core component of their S2MM, MM2S, and their interconnect ... and probably quite a few other components as well.  This is one of the reasons why I've written alternative, open source designs to many of these common components. [FFT, S2MM, MM2S, AXI interconect, etc.]  As to which components are "better", it's a mixed bag--but that's another longer story for another day.
3. Verilator does not support sub-clock timing simulations, although it can support multi-clock simulations.  At the same time, most students don't need to know the details of sub-clock timing in their first course.  (I'm not referring to clock-domain crossing issues here, since those are rarely simulated properly anyway.)

Still, I find Verilator to be quite a valuable choice and one I highly recommend learning early on in the learning process.  This is the reason why my beginners Verilog tutorial centers around using both Verilator and SymbiYosys.

Dan

[zygot]

I've worked as a consultant or employee for a lot of companies that have years of accrued experience developing programmable logic based products that have been deployed by customers. All of them use the standard logic simulator tools. Some only use the free tools that come with the FPGA vendors' toolset. Some buy the full versions of ModelSim or other logic simulators. This isn't by accident or lack of sophistication.

It's true that only a subset of Verilog and VHDL are supported by programmable logic synthesis tools. Verilog and VHDL were developed to do simulation long before the IEEE added standard libraries to them so that programmable logic vendors would adapt them for use as a synthesis source. All FPGA vendors provide documentation on what exactly their synthesis tools support for these languages. Logic simulators, even Xilinx's home grown one, support most of Verilog and VHDL. After all they are simulators! All of my testbenches use non-synthesizable Verilog or VHDL. Beginners and self-taught people often get into FPGA development with a lot of bad assumptions and conceptualizations. They also don't read the documentation provided by the vendors of the products that they want to use. I'd agree that finding good guidance on how to write a testbench is hard to come by. Beginners should start off using the minimal features of Verilog or VHDL until they've mastered those and then add to their repertoire as the gain experience.  

Verilator is a cycle based simulator. That makes if fast; but it's fast because it simulates a greatly simplified model of digital logic. If you're simulating a PDP11 it's a good tool. If you're simulating the latest Intel Xenon processor I'm pretty sure that you don't have a tool that has complete code or behavioral coverage. I strongly disagree that sub-clock timing isn't important to beginners. I would argue that simplifying logic design into a cycle based conceptualization is more confusing and counter-productive. There certainly are valid reason to use a cycle based simulator; even for logic design. These types of simulators are not preferred nor should they be the first option though. They are simply not capable of performing all of the simulator duties required for a complete programmable logic design flow. Use the simulator provided by your FPGA vendor. Learn basic simulator language concepts. Learn about limits of FPGA device resources and support for  whatever source format you choose to submit to their syntheses tools. Most importantly, take some time to develop a basic understanding of digital design using real devices and real wires. I realize that LUT based programmable logic devices aren't a bunch of gates but the same concepts important to designing circuits with LSI and MSI devices on a PCB apply to FPGA design. If you find that ModelSim or Vivado simulator is taking too long you can adjust the sample unit of time to speed things up. A one pico-second timescale isn't necessary for most designs. You can finds ways to work around a lot of simulation time that isn't important to your analysis.

All of the applications that you mention above are relatively simple designs in terms of timing analysis. At some point you may want to do something more challenging and will have to provide proper timing and even placement constraints in order to get the vendor's tools to properly synthesize and place logic so that your design will work. at some point sub-clock timing considerations will dominate the timing analysis of a high clock rate design. Verilator and SymbiYosys can't help you do that. Time based simulators can. You can only go so far with simple models of real things. My advice is to become reasonably expert with the tools recommended by the vendors who make the devices and make the tools to develop designs for. Once you have a level competence with those logic simulation tools then branch out and try other options.

I would agree with anyone suggesting that Intel and Xilinx have done a poor job with code coverage, as you say, formal analysis of HDL source code. This is one area that needs to be addressed. There are companies that address this shortcoming.

[edit] I forgot to mention that a lot of people resist post-route timing simulation because it often involves a bit more work. In the commercial environment where teams are working in parallel to make integration and delivery schedules having this analysis is vital to success. You need traditional logic time based simulators like the one that comes with your vendor's tools to do this. One more reason to become adept at using them.

[xc6lx45]

>> student/beginners try to use these non-synthesizable constructs to generate "programs" rather than "designs". 

Students, beginners and most of industry for testbenches, making pitiful noises from the pain but using it nonetheless.
Yes, Verilog is horrible and could be improved in oh-so-many ways, like most successful languages engineers use to get their work done before the deadline (perl, Matlab, C, Excel / Visual Basic, ...).

I think you are driving a methodology that is very different from typical industrial use (where designers must deal with a large number of simple problems instead of working on a single hard one for weeks and months). Maybe you should add a disclaimer, like "warning: following this to the letter may make you look really stupid in a non-academic job interview".