Search the Community
Showing results for tags 'verilator'.
Found 1 result
All, I'd like to continue an ongoing discussion that's now taken place across many forum threads, but I'd like to offer for everyone a simple place to put it that ... isn't off topic. (Thank you, @JColvin for inviting my ... rant) For reference, the tools I use include: Verilator: for simulating anything from individual components (such as this UART), to entire designs (such as my Arty design, CMod S6 design, XuLA2-LX25 design, or even my basic ZipCPU design). (Read about my debugging philosophy here, or how you can use Verilator here.) Drawbacks: Verilator is Verilog and System Verilog only, and things the Verilate don't always synthesize using Vivado. Pro's: compiling a project via Verilator, and finding synthesis errors, can be done in seconds, vice minutes with Vivado. Further, it's easy to integrate C++ hardware co-simulations into the result to the extent that I can simulate entire designs (QSPI flash, VGA displays, OLEDrgb displays, simulated UART's forwarded to TCP/IP ports, etc) using Verilator and (while it might be possible) I don't know how to do that with any other simulation tool. Time is money. Verilator is faster than Vivado. GTKWave: for viewing waveform (VCD) files yosys: Because 1) it's open source, and 2) it supports some (the iCE40 on my icoboard), though not all, of the hardware I own wbscope (or its companion, wbscopc): for any internal debugging I need to do. (Requires a UART to wishbone bus converter, or some other way to communicate with a wishbone bus within your design ...) Vivado: for synthesis, implementation, and any necessary JTAG programming wbprogram: to program bit files onto FPGA's. I use this after Vivado has placed an initial load onto my FPGA's. I also use wbicapetwo to switch between FPGA designs contained on my flash. zipload: to load programs (ELF files), and sometimes bit files, onto FPGA's ... that have an initial load on them already. While the program is designed to load ZipCPU ELF files, there's only two internal constants that restrict it to ZipCPU programs. ZipCPU, as an alternative to MicroBlaze (or even NiOS2, OpenRISC, picorv, etc). (GCC for compiling programs for the ZipCPU) The only program above that requires a license to use is Vivado, although some of the above are released under GPL Further, while I am solidly pro-open source, I am not religiously open source. I believe the issue is open for discussion and debate. Likewise, while my work has been very much Verilog focused, I have no criticisms for anyone using VHDL. To start off the discussion, please allow me to share that I just spent yesterday and today looking for a problem in my own code, given one of Vivado's cryptic error messages. Vivado told me I had two problems: a timing loop, and a multiply defined variable. The problem turned out to be a single problem, it's just that the wires/nets Vivado pointed me to weren't anywhere near where the error was. Indeed, I had resorted to "Voodoo hardware" (fix what isn't broken, just to see if anything changes) to see if I could find the bug. (Didn't find it, many hours wasted.) Googling sent me to Xilinx's forum. Xilinx's staff suggests that, in this case, you should find the wire on the schematic (the name it gave to the wire wasn't one I had given to any wires). My schematic, however, is .... complicated. Finding one wire out of thousands, or tens of thousands, when you don't know where to look can be frustrating, challenging, and ... not my first choice to finding the result. I then synthesized my design with yosys this morning and found the bug almost immediately. +1 for OpenSource. Time is money, I wish now I'd used yosys as soon as I knew I had a problem. Did I implement the design yosys synthesized? No. I returned to Vivado for ultimate synthesis, implementation, and timing identification.. If you take some time to look through OpenCores, or any other OpenSource FPGA component repository for that matter, you will quickly learn that the quality of an OpenSource component varies from one component to another. Even among my own designs, not all of them are well documented. Again, your quality might vary. +1 for proprietary toolchains, ... when they are well documented, and when they work as documented. There's also been more than one time where I've had a bug in my code, often because I've mis-understood the interface to the library component it is interacting with, and so I've needed to trace my logic through the library component to understand what's going on. This is not possible when using proprietary components--whether they be software libraries or hardware cores, because the vendor veils the component in an effort to increase his profit margin. Indeed, a great number of requests for help on this web site involve questions about how to make something work with a proprietary component (ex. MicroBlaze, or it's libraries) that the user has no insight into. +1 for OpenSource components, in spite of their uncertain quality, and the ability you get to find problems when using them. Another digital designer explained his view of proprietary CPUs this way, "Closed source soft CPUs are the worst of two worlds. You have to worry about resource use and timing without being able to analyze it". (Olof's twitter feed) In other words, when you find a bug in a proprietary component, you are stuck. You can't fix the bug. You can request support, but getting support may take a long time (often days to weeks), and it might take you just as long to switch to another vendor's component or work around the bug. +1 for OpenSource that allows you to fix things, -1/2 for OpenSource because fixing a *large* design may be ... more work than it's worth. Incidentally, this is also a problem with Xilinx's Memory Interface Generated (MIG) solutions. When I added a MIG component to my OpenArty design, I suddenly got lots of synthesis warnings, and it was impossible for me to tell if any were (or were not) valid. +1 for OpenSource components, whose designs allow you to inspect why you are getting synthesis warnings. I could rant some more, but I'd like to hear the thoughts others of you might have. For example, @Notarobot commented at the end of this post that, "using design tools introduces additional additional unnecessary risk. I'd like to invite him to clarify here, as well as inviting anyone else to participate in the discussion, Dan