![]() I use the TRACE define to determine whether or not I generate a. Definiting it this way allows me to use the self-same testbench with several different DACS. So let’s start with a very simple 1st-order DAC: module sigma_delta_dac_1storderĭACHEADER is externally defined in the Makefile but it’s a header file which verilator generates, describing the module under test as a class with the various ports defined as members. I also have the option of saving a trace file which can be examined in GTKWave, though I’m not going to do that just yet. For this project this is ideal, since I can use all tools of the C or C++ languages to inject signals into the DACs (even from files if I wish), process the output and log it to a file. Rather than merely simulate a testbench written in verilog and output the signals to a trace file, Verilator takes a slightly different approach: the component under test is compiled into a link library which can directly interact with a testbench written in C++. ![]() Having rambled on a little longer than I intended while setting the scene for these experiments, I’m going to set up a simple testbench with verilator to evaluate the performance of several different DACs. ![]() Exploring audio DACs in simulation – Part 2 – ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |