Forum Discussion
Test stimulus for FPGA validation
- 2 years ago
The tools you mention are all for on-chip debugging with the design running in hardware. This seems to be what you want to do.
If you are saying you want to toggle internal signals while the design is running, then ISSP is what you want. You can use it along with Signal Tap to see more high-speed signaling as you toggle signals (ISSP probe data is only available as fast as the JTAG connection). You can set up a Signal Tap trigger based on the ISSP source toggling or anything else that should be happening while the design is running.
In-System Memory Content Editor is for viewing and editing the contents of on-chip RAM blocks during runtime. That doesn't seem like what you want.
The tools you mention are all for on-chip debugging with the design running in hardware. This seems to be what you want to do.
If you are saying you want to toggle internal signals while the design is running, then ISSP is what you want. You can use it along with Signal Tap to see more high-speed signaling as you toggle signals (ISSP probe data is only available as fast as the JTAG connection). You can set up a Signal Tap trigger based on the ISSP source toggling or anything else that should be happening while the design is running.
In-System Memory Content Editor is for viewing and editing the contents of on-chip RAM blocks during runtime. That doesn't seem like what you want.
Hello sstrell and ShengN_Intel,
Thank you for the reply.
My problem with ISSP is that if I want to change the sources, I have to do it manually change it bit by bit.
I have 16 bit input that changes every clock cycle which presents a challenging task.
I looked at the link ShenN provided and I think I am right to assume that the GUI only allows a direct push button approach.
What I am really looking for is a way for Quartus to take in a test stimuli in some sort of file format like a text file.
I brought up the In content memory editor because I saw a tutorial about it. https://www.youtube.com/watch?v=YI34AoA74_c
At first I brushed it off, but upon looking at it more yesterday I think it actually makes sense.
Essentially, the test stimuli can be stored in a ROM, then an up counter (connected to the address of the ROM) calls the data/stimuli stored in the ROM.
It kind of reminds of a processor reading an instruction set.
So this way, I think we can just write in the MIF file and test it.
Please let me know if I misunderstood something.
Thank you.
-htolentino