Getting waveform simulation to work sounds simple until you stare at a blank waveform window with no signals loaded. The configuration files control everything \u2014 which signals appear, how they are grouped, what radix they display in, and whether your simulation even knows where to look for the dump file. Getting this wrong means wasted hours chasing ghosts in the waveform viewer.<\/p>\n\n\n\n
Every simulator writes simulation data into a dump file. The two most common formats are VCD (Value Change Dump) and FSDB (Fast Signal Database). VCD is plain text, universally supported, and slow for large designs. FSDB is binary, much faster, but not every free tool reads it natively.<\/p>\n\n\n\n
When you write your testbench, you need to explicitly tell the simulator to dump signals. In Verilog, this looks like:<\/p>\n\n\n\n
1initial begin\n2 $dumpfile(\"sim.vcd\");\n3 $dumpvars(0, top_module);\n4end\n5<\/code><\/pre>\n\n\n\nThe first argument to $dumpvars<\/code> is the depth. Zero means dump everything recursively. If you set it to 1, you only get the top-level signals. For debugging, zero is almost always what you want.<\/p>\n\n\n\nIn VHDL, the equivalent uses the VPI package or a simulator-specific procedure. Check your tool’s documentation for the exact syntax, but the concept is identical \u2014 you must open a file, then register every signal hierarchy you want to capture.<\/p>\n\n\n\n
Setting Up the Waveform Configuration File<\/h2>\n\n\n\n
Most simulators let you save a waveform configuration file so you do not have to manually add signals every time you rerun a simulation. This file stores signal names, groupings, radix settings, and cursor positions.<\/p>\n\n\n\n
Organizing Signals Into Groups<\/h3>\n\n\n\n
A flat list of 200 signals is unreadable. Group them by function. Put all clock and reset signals in one group. Put data buses in another. Put state machine signals in a third. This is not cosmetic \u2014 it changes how you debug.<\/p>\n\n\n\n
When a bug appears, you expand the relevant group, zoom in on the time window, and see exactly what happened. Without groups, you are scrolling through a wall of noise.<\/p>\n\n\n\n
To create groups in the configuration file, use the add wave command with a group flag. The exact syntax varies by simulator, but the pattern is consistent:<\/p>\n\n\n\n
1add wave -group \"Clock Domain\" -divider \"System Clocks\"\n2add wave -group \"Clock Domain\" sim\/clk_100m\n3add wave -group \"Clock Domain\" sim\/rst_n\n4<\/code><\/pre>\n\n\n\nThe divider creates a visual separator inside the group. Use it to split clocks from resets, or data from control signals.<\/p>\n\n\n\n
Choosing the Right Radix for Each Signal<\/h3>\n\n\n\n
Displaying everything in binary looks neat in screenshots but is useless for debugging. Configure each signal with the radix that makes sense for its role.<\/p>\n\n\n\n
Clocks and resets: binary or hex. Counters: unsigned decimal. Address buses: hexadecimal. Data buses: hexadecimal or binary depending on whether you are tracking individual bits or the whole word. Signed values: decimal.<\/p>\n\n\n\n
Set this in the configuration file so it persists across simulation runs. Otherwise you are manually changing radix every time you reload a waveform.<\/p>\n\n\n\n
Loading the Dump File Into the Viewer<\/h2>\n\n\n\n
This step fails more often than it should. The simulator writes the dump file to a specific directory. The waveform viewer looks in a different directory by default. If the paths do not match, you get an empty window and a cryptic error message.<\/p>\n\n\n\n
Always specify the full path to the dump file when opening it. Better yet, add a command to your simulation script that automatically opens the waveform file after the run completes. This eliminates the manual step entirely.<\/p>\n\n\n\n
If you are running batch simulation without a GUI, skip the waveform viewer and use a command-line tool to convert the dump file into a text report. This is slower for debugging but useful for regression testing where you just need to verify that a signal toggled at the right time.<\/p>\n\n\n\n
Writing a Testbench That Dumps Useful Data<\/h2>\n\n\n\n
The configuration file is only as good as what the testbench dumps. A common mistake is dumping every internal signal in a large design. The dump file becomes gigabytes in size, and the simulator slows to a crawl.<\/p>\n\n\n\n
Dump only what you need to see. Internal registers inside a module that works correctly do not need to be in the waveform. Focus on module boundaries \u2014 inputs, outputs, and any internal state that directly affects the bug you are chasing.<\/p>\n\n\n\n
Use $dumpon<\/code> and $dumpoff<\/code> to control when dumping starts and stops. If your testbench has a long initialization phase that generates millions of signal transitions, turn dumping off during that phase and turn it on only when the actual test begins.<\/p>\n\n\n\n1initial begin\n2 $dumpfile(\"sim.vcd\");\n3 $dumpvars(0, top_module);\n4 $dumpoff;\n5 #1000;\n6 $dumpon;\n7end\n8<\/code><\/pre>\n\n\n\nThis single change can reduce your dump file size by 90 percent.<\/p>\n\n\n\n
Handling Multi-Module Simulations<\/h2>\n\n\n\n
When your testbench instantiates multiple sub-modules, the dump file contains the full hierarchy. Referencing signals in the configuration file requires the full path.<\/p>\n\n\n\n
For a module named uart_tx<\/code> instantiated inside top_module<\/code>, the signal path is \/top_module\/uart_tx\/tx_data<\/code>. Typing this manually every time is painful. Use wildcard patterns in the configuration file to load entire modules at once.<\/p>\n\n\n\n1add wave -group \"UART\" \/top_module\/uart_tx\/*\n2<\/code><\/pre>\n\n\n\nThis loads every signal inside uart_tx<\/code> under the UART group. You can then collapse the group when you are not debugging that module, keeping the waveform window clean.<\/p>\n\n\n\nCommon Configuration Mistakes That Waste Time<\/h2>\n\n\n\n
Forgetting to re-dump after code changes. The waveform viewer caches the dump file. If you modify the testbench and rerun without deleting the old dump file, the viewer loads stale data. Always delete the dump file before a fresh run, or use a timestamped filename.<\/p>\n\n\n\n
Using relative paths in the configuration file. If you move your project directory, all the signal paths break. Use absolute paths or path variables that the simulator resolves at runtime.<\/p>\n\n\n\n
Not saving the configuration file. If you spend 20 minutes arranging signals into groups and the simulator crashes, you lose all of it. Save the configuration file after every major edit. Treat it like source code \u2014 it is.<\/p>\n\n\n\n
Quick Checklist Before Running Simulation<\/h2>\n\n\n\n
Confirm the dump file path in the testbench matches where the viewer expects it. Verify that $dumpvars<\/code> depth is set to zero for full visibility. Check that the configuration file loads the correct top-level module. Make sure all signal groups are named and all radix settings are intentional. Delete any old dump files from previous runs. Then run.<\/p>\n\n\n\nChipApex is a global distributor of electronic components: ICs, semiconductors, passives & interconnects. Source active & obsolete parts with wholesale pricing, fast RFQ response, and worldwide delivery.Official website address:chipapex.com<\/p>\n","protected":false},"excerpt":{"rendered":"
FPGA Waveform Simulation File Configuration: How to Set …<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-3660","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"_links":{"self":[{"href":"http:\/\/manufacturing.wiki\/index.php\/wp-json\/wp\/v2\/posts\/3660","targetHints":{"allow":["GET"]}}],"collection":[{"href":"http:\/\/manufacturing.wiki\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/manufacturing.wiki\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/manufacturing.wiki\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/manufacturing.wiki\/index.php\/wp-json\/wp\/v2\/comments?post=3660"}],"version-history":[{"count":1,"href":"http:\/\/manufacturing.wiki\/index.php\/wp-json\/wp\/v2\/posts\/3660\/revisions"}],"predecessor-version":[{"id":3661,"href":"http:\/\/manufacturing.wiki\/index.php\/wp-json\/wp\/v2\/posts\/3660\/revisions\/3661"}],"wp:attachment":[{"href":"http:\/\/manufacturing.wiki\/index.php\/wp-json\/wp\/v2\/media?parent=3660"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/manufacturing.wiki\/index.php\/wp-json\/wp\/v2\/categories?post=3660"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/manufacturing.wiki\/index.php\/wp-json\/wp\/v2\/tags?post=3660"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}