Data from FPGA to host

Sorry I was away for the work.

Now I'm back on this project. I instantiated a fifo, I've got a qsys system with a Nios II cpu. This system has access to the fifo but I'm lost: has the JTAG to Avalon master bridge you use to be implemented? The signals from the fifo have to go to the sdram controller or to the cpu? The commands you use (as jtag_read or jtag_write) can be used by the cpu or only in the console?

--- Quote Start ---

has the JTAG to Avalon master bridge you use to be implemented?

--- Quote End ---

Its a standard Qsys component.

--- Quote Start ---

The signals from the fifo have to go to the sdram controller or to the cpu?

--- Quote End ---

That is up to you.

--- Quote Start ---

The commands you use (as jtag_read or jtag_write) can be used by the cpu or only in the console?

--- Quote End ---

The NIOS II CPU cannot "see" the JTAG port, since it is inside the FPGA. You need to use System Console from the host. If all you need is something to generate an Avalon-MM read or write, then you can use the NIOS II processor to generate the transaction. If your SignalTap II trace is at the Avalon-MM slave interface, then either the CPU or JTAG-to-Avalon-MM master can be used.

Cheers,

Dave

--- Quote Start ---

That is up to you.

--- Quote End ---

OK but I really don't know what difference it makes. What have I to do in one case or the other?

--- Quote Start ---

If all you need is something to generate an Avalon-MM read or write, then you can use the NIOS II processor to generate the transaction. If your SignalTap II trace is at the Avalon-MM slave interface, then either the CPU or JTAG-to-Avalon-MM master can be used.

--- Quote End ---

I still can't understand what need the SignalTap II trace is.

Here's what I tried first:

Download the design in the FPGA. This design was waiting an activity on any observed input signal to start the recording in the "onchip memory" (so told qsys). This memory is too small to capture the whole process so I thought of using the sdram.

I thought of using this procedure:

1. download the design in the FPGA

2. start a waiting command in the console

3. start the observed process and record the signals in the sdram

4. detecting the end of the process and then write the content of the sdram in a file on the host computer

Does this way of doing it seem to be OK?

--- Quote Start ---

I still can't understand what need the SignalTap II trace is.

--- Quote End ---

Its a debug tool. Read the documentation. Try and use it. Once you understand how to use it, you will be able to determine if its useful to you.

--- Quote Start ---

Here's what I tried first:

Download the design in the FPGA. This design was waiting an activity on any observed input signal to start the recording in the "onchip memory" (so told qsys). This memory is too small to capture the whole process so I thought of using the sdram.

--- Quote End ---

Unfortunately SignalTap II cannot use external memory. Typically you do not need to record "all" of a transaction though, you can use Triggers to capture relevant details.

--- Quote Start ---

I thought of using this procedure:

1. download the design in the FPGA

2. start a waiting command in the console

3. start the observed process and record the signals in the sdram

4. detecting the end of the process and then write the content of the sdram in a file on the host computer

Does this way of doing it seem to be OK?

--- Quote End ---

Sure, if you can define what a "waiting command" is in your hardware design.

Have you created a simulation of your system? If not, you should. It will help you understand your design much better, since it gives you full visibility into what is going on. The simulation waveform view will also help you see why SignalTap II is useful.

Cheers,

Dave

--- Quote Start ---

Its a debug tool. Read the documentation. Try and use it. Once you understand how to use it, you will be able to determine if its useful to you.

--- Quote End ---

I used it some time ago and I know basically what it can do. I don't know it very well and I can be wrong but I don't think it could be very useful for the matter.

--- Quote Start ---

Sure, if you can define what a "waiting command" is in your hardware design.

--- Quote End ---

I was thinking of a flag that would only make the sdram writing enable when it's '1'.

--- Quote Start ---

Have you created a simulation of your system? If not, you should. It will help you understand your design much better, since it gives you full visibility into what is going on. The simulation waveform view will also help you see why SignalTap II is useful.

--- Quote End ---

You're right, I haven't done so and I'm starting to think it's a big error. I'll do it first thing tomorrow (if my work let me enough time)...

--- Quote Start ---

I tried tutorials but it doesn't run as wanted, maybe a version difference or maybe it's my fault. I'll try another time tomorrow...

--- Quote End ---

SignalTap II? I use it all the time with various version of the tools and have never had a problem.

Synthesize your design, then start SignalTap II, add signals to the SignalTap II instance, setup a clock source, setup the number of samples to capture, save the instance, add it to your project, resynthesize, download to your board, and then 'scan JTAG chain' in SignalTap II (if it doesn't auto detect that the instance is now valid).

Cheers,

Dave

OK, I didn't understand you correctly

For me "simulation" means a logical way of predicting what would happen, with Modelsim or Questa for example. SignalTap II is more a tool to analyse what really happens after downloading the design in the FPGA. Anyway it's more what I need. I used it some time ago but my knowledge (and my memory) seems to need an update. That's what I'll do next and see if it helps...

--- Quote Start ---

For me "simulation" means a logical way of predicting what would happen, with Modelsim or Questa for example. SignalTap II is more a tool to analyse what really happens after downloading the design in the FPGA.

--- Quote End ---

In general, you have to use both. For example, lets say I have a board with a microcontroller on it, and the firmware in that microcontroller implements a parallel interface to the FPGA, and I do not have access to that firmware (eg., I have this situation on a Digilent Xilinx board). Using SignalTap II (or in reality Xilinx Chipscope), I can measure the timing of that interface, and then use that timing in the bus functional model (BFM) simulation of the parallel interface. Once I have a realistic BFM, I can simulate the design until I am confident it works, and then hardware test. Working this way, I generally have no issues once I get to hardware tests.

Cheers,

Dave