Verilator 4.0 - Open Simulation Goes Multithreaded - Wilson Snyder - ORConf 2018

Everything in engineering tends to be a trade off of some sort. In many cases, there's no FOSS support for Vendor libraries. This is true. (There are also workarounds to this.) The other half of this trade is that Verilator is the fastest simulator on the market. Pick your poison. It's not just a Vendor vs FOSS issue either. Some vendor tools support some language constructs by the spec, other tools try to "fix" the spec, and so I tend to get uneven support for the exact same design when moving from one tool to the next. In this case, OP is also likely to find the library he wants will be unsupported when he switches Vendors as well.

- SymbiYosys: I use SymbiYosys to verify most of my modules and most definitely anything that ever touches the bus. - Verilator: is my simulator of choice. Beware that it's not a true Verilog simulator (it's faster). Still, I appreciate how easy it is to integrate with operating system functions, and so to be able to draw graphics to my screen, or simulate an SD-card. - IVerilog: If I need an open source Verilog simulator I've been known to use IVerilog. - XCellium: I've also used the (proprietary) XCellium when IVerilog wasn't up to the task. You can read more about the tools I use and why here. What things are lacking with the current tools? Hmm ... I think my three biggest com…

There are various reasons to choose or not choose Verilator. It depends on the system under test, and your testing needs. This conference talk on Verilator by Wilson Snyder may be of interest to you (Wilson Snyder is one of the maintainers of Verilator). Here are some reasons I use Verilator: - Fast. - Free. (Running sims in parallel is nice) - 64-bit simulator (Allows you to use 64-bit python. 32-bit can be a pain.) Also, Verilator can be a little complicated to use because it's not a traditional simulator, so I'd recommend avoiding it if you're a newbie. Icarus Verilog and Modelsim are more beginner-friendly simulators. If you'd like to decide for yourself, the best place to start is t…

Not to take you off topic, but let me answer with respect to the IP associated with that tool chain ... if it's open source, you can debug it. - Xilinx's demonstration designs have been broken for years, in spite of requests to fix them and promises of the same. Ref 1, 2 - Xilinx's ethernet-lite controller has the bug that, if ever a read and write arrive at the same time, the write will get applied to the read address. A second bug might cause reads from the core to hang the entire design. - Xilinx's Stream to Memory DMA has several known problems associated to it, problems that will hang a user design. Stream writes to the core before it is set up will get swallowed up into neve…

Lots of good recommendations here. Let me summarize some of the better ones and add some of my own thoughts: 1. As with anything, start with the AXI specification. 2. I've written several AXI blog articles. To find a list of them, check out my site topics page. There's an "AXI bus" section within that lists all of my AXI articles. 3. Why would you write your own AXI interface? Easy: because Xilinx's demonstration AXI interfaces are broken. See here, for the bugs in their AXI-lite slave demonstration implementation, and here, for the bugs in their AXI (full) slave demonstration implementation. Even Intel's AXI3 demo slave is broken--but you'll have to look at the backup slides from t…

There are better tools for Verilog. 1. There is a free formal verification tool for Verilog called SymbiYosys. The VHDL tool is not nearly so free. Formal verification makes finding bugs very easy--so much so that with as little as 20minutes with someone else's AXI-lite code, I can find bugs in someone else's design. What sort of bugs? Bugs that even Xilinx never found within their own code. Further, with just a little bit more work I can build a compliant AXI-lite bus slave. Even better, I can standardize interface implementations across enterprise using well-defined interface property files. 2. Yet formal goes well beyond just interfaces ... imagine one piece of code with many impl…