Electronics > FPGA

Hitting a breakpoint after n times!

(1/6) > >>

ali_asadzadeh:
Hi,
I want to know how we can set a break point in modlesim to be triggered after for example 100 hits? If I set some break points, every time the code reaches there it would stop for now as expected.
Thanks

BrianHG:
Something like the opposite of this:


--- Code: ---always @(posedge CLK_IN)   WDT_COUNTER = (SEQ_BUSY_t!=SEQ_CMD_ENA_t) ? WDT_RESET_TIME : (WDT_COUNTER-1'b1) ;   // Setup a simulation inactivity watchdog countdown timer.
always @(posedge CLK_IN) if (WDT_COUNTER==0) begin
                                             Script_CMD  = "*** WDT_STOP ***" ;
                                             $stop;                                           // Automatically stop the simulation if the inactivity timer reaches 0.
                                             end

--- End code ---

Once stopped, you may 'run -all' in the transcript to continue.
Also, in the second if, you may reset the WDT_*** to a preset value so it will stop again automatically after that new number of iterations.

SiliconWizard:
I would implement this in the test bench HDL as Brian suggested.

And that said, the idea of setting "breakpoints" for HDL simulation sounds pretty odd to me. Everything can be done much better, more efficiently and in a more reproductible way using HDL.

ali_asadzadeh:
Thanks BrianHG, I have designed a DSP engine, It needs quite some clocks to spit the results, But some of them are wrong, so I needed a way to break after some n times doing the loop; it's odd that they do not have provided an easy way of doing it in Modelsim, since it can be easily done in ARM toolchains like keil :palm:

Berni:

--- Quote from: ali_asadzadeh on July 13, 2021, 05:56:48 am ---Thanks BrianHG, I have designed a DSP engine, It needs quite some clocks to spit the results, But some of them are wrong, so I needed a way to break after some n times doing the loop; it's odd that they do not have provided an easy way of doing it in Modelsim, since it can be easily done in ARM toolchains like keil :palm:

--- End quote ---

An FPGA is not a ARM CPU. They are an entirely different thing so they need entirely different debugging methods.

This is a excellent use case for testbenches. Generating the test input signals to the DUT is not the only job a testbench can do. The same test bench can also verify the results and stop the simulation when it finds a wrong result. This way you can just let it run for hours on end, pumping test cases trough the DUT, yet it will halt on a problem to let you examine what happened and write down the inputs that caused it, letting you rerun the simulation with those inputs to reliably reproduce it.

If your point is to just send a single operation cycle tough the DSP and then check results then you can just write a testbench that monitors the output for some ready condition and then print the results into the console.

For example i was working on a CAN controller in a FPGA and to make testing easier i wrote a simple CAN packet parser inside the testbench that would decode the packets and print them out to the console or on a bus. This essentially gave it the functionality of a serial decode feature on a scope, yet it could be programed for any protocol, not just some list of supported protocols.

Testbenches are there to let you build your own tools for exercising and verifying the DUT. This is why simulators don't provide them out of the box. They can't possibly cover all use cases with prebuilt tools so they instead give you a tool to build your own tools that debug your code exactly the way you like.

Navigation

[0] Message Index

[#] Next page