Signal Tap II Input Excitation

[Altera_Forum]

Hey guys, 

  I have a Verilog DSP core that is fully functional. I would like to implement it into an FPGA and test it.    To monitor the outputs I plan to use the Signal Tap II Logic Analyzer. For the inputs, I can set up some memory with test vectors and write some Verilog to input the numbers to the DSP core within the FPGA.    But, I was wondering if there was some way to send inputs to the core via Signal Tap II? I know how to use it to monitor outputs, but I would like to know if you can use it to drive input pins.    If so, I could write a program that would excite the inputs. Any suggestions would be appreciated.

[Altera_Forum]

Signal can't generate stimulus signals. You can connect Source&Probe as signal source, but it only generates static signals, not sequences.

[Altera_Forum]

So what could be used to send data vectors to the inputs of a downloaded circuit? It would be nice if a MATLAB program could be written that could somehow drive the inputs of the circuit.

[Altera_Forum]

--- Quote Start ---  So what could be used to send data vectors to the inputs of a downloaded circuit? It would be nice if a MATLAB program could be written that could somehow drive the inputs of the circuit.  --- Quote End ---    You can use dual-ported RAM and an SOPC/Qsys System.  1) JTAG-to-Avalon-MM bridge 2) Avalon-MM slave interfaces to one side of a pair of RAMs. 3) Your DSP component between the other ports of the RAMs; one as the data source, the other as the data sink. 4) A controller to read data out of one RAM, pass it through your DSP logic, and capture the output in the other RAM.  You then fill the source RAM with data, enable your controller, and read the results out of the sink RAM.  This is a common enough question that I'll try to write up an example.  See if you can figure out how to do it yourself first.  Cheers, Dave

[Altera_Forum]

Thanks for the reply Dave. I considered using a similar setup, but instead I would use two memory components that were auto initialized. I would then write some verilog to control the memory, and then I would use Signal Tap II/Matlab to read the output. 

 I really don't want to create any additional memory or Verilog. I would like to just tie the inputs directly to the jtag some kind of way, and then let MATLAB communicate with it. But it seems that the Altera designers never included such a feature.

[Altera_Forum]

--- Quote Start ---  Thanks for the reply Dave. I considered using a similar setup, but instead I would use two memory components that were auto initialized. I would then write some verilog to control the memory, and then I would use Signal Tap II/Matlab to read the output.   I really don't want to create any additional memory or Verilog. I would like to just tie the inputs directly to the jtag some kind of way, and then let MATLAB communicate with it. But it seems that the Altera designers never included such a feature.  --- Quote End ---  Altera provides sufficient tools to achieve what you want. It just depends how familiar you are with them, and how much work you want to put into it. Once you have one control interface working, it'll be useful for other designs.  Your verilog to 'control the memory' needs to be commanded to start capture to RAM, and then generate an indicator that Signaltap can be triggered on. That command needs to come from your PC or MATLAB, and one way to do that is via a JTAG-to-Avalon-MM component, or via a NIOS II processor and JTAG-UART or real UART. Once you've implemented that logic, SignalTap is not really needed, since you can directly read a status bit from your controller and then read the capture RAM.  Cheers, Dave

[Altera_Forum]

A processor based system to send stimulus and capture data is the ideal solution but obviously takes some effort. 

 If you don't need to go for such task then I will use three onchip ram blocks. one ram to store stimulus(can be editable through insystem editor), the other ram to store captured data and the third to store reference output data from a model. You then compare internally and send flag through signaltap.   But remember hardware bit true testing is not that easy. You need to use valid out and synchronise rams to compare at right time. You also need to take care of bit true issues like saturation, rounding methods and their locations in the design and match them to your model.  edit: you may use two rams only as well. One to store stimulus, the other to store reference data then you read ref data aligned with data output by your module. Other issues that may arise is the start and tail of filtered outputs which may differ between model and realtime hardware, issues of NCO phase...etc.