PC <-> S530Dev. Bd. Reg R/W interface?

--- Quote Start ---

I'm guessing/hoping that the building blocks for this structure exist and I just have to paste them together. (PC-based USB driver -> USB interface on FPGA, or maybe Rj45 Ethernet?)

Can anyone point me in the right direction?

--- Quote End ---

The JTAG interface can be used to implement communications. However, you are then limited to using Altera applications on the host. This is not too much of a pain for simple tests, but it does get annoying. I'm looking into a better solution and will post my results. Start by using an Avalon-MM JTAG master along with the SystemConsole Tcl functions to access the device. Design your custom logic as an Avalon-MM slave device.

If you use the RJ45 interface, then you'll need a network interface controller. There is an Altera TSE IP core, but I have yet to test it. I'm not sure how much work it would be to code your own. Once you have the ethernet connected as an Avalon-MM/ST device, then you can code up a server on a NIOS II processor. This would provide a higher-bandwidth interface.

If you have the board plugged into a PCIe motherboard, then you can use a PCIe-to-Avalon-MM bridge IP core, and then communicate from the host as if the board is a PCI device. This is simple under Linux, and you can probably use the Jungo driver under Windows.

I have the same kit as you, but with the 230 devices. I've been using JTAG for testing up until now, but the ethernet and PCIe tests are on my TODO list. If you get stuck, ask, and I'll help if I can.

Cheers,

Dave

Hi Dave - that's a start - thanks!. Can higher level applications (like LabView) talk to the Altera application on the host?

/j

Also - something about your explanation confuses me. I think you're telling me to put the Avalon-MM JTAG Master device on the FPGA as a piece of IP, and design my logic as an Avalon slave. So far so good, but I don't quite understand the path from the JTAG Master IP on the FPGA to the PC - will it "bind" to the JTAG port automatically? What SW App do I run on the PC to get a command-line interface to it?

If there's like, a good tutorial on this (or a few manual section), I'm game to RTFM.

Thanks very much!

/j

--- Quote Start ---

Can higher level applications (like LabView) talk to the Altera application on the host?

--- Quote End ---

Not without a little extra work.

There are effectively two separate methods to create JTAG interfaces; low-level access via the Virtual JTAG IP core, and access via SOPC Builder components such as the JTAG to Avalon-MM master bridge. Both of these IP components come with a corresponding set of Tcl procedures.

The Tcl procedures access the JTAG interface via DLLs with unpublished APIs. There are posts explaining how to use some of these directly, but I have not tried this.

I've used both the Virtual JTAG and Avalon-MM IP cores. I'd recommend playing with the Avalon-MM IP first. Using Qsys or SOPC Builder, create a system with a JTAG to Avalon-MM master, a RAM block, and a GPIO block, and use SystemConsole Tcl commands to access this system.

I recall a fairly decent webinar on the topic ... perhaps it was one of these

http://www.altera.com/support/examples/on-chip-debugging/on-chip-debugging.html

Have a look at that stuff, and if it becomes too confusing, I'll create a design and some scripts for you to play with.

Back, to your original question; Labview cannot talk to any of these IP cores directly, since the access is via a console in an Altera application. However, you can write a Tcl server, start that using the appropriate quartus command-line tool and then use sockets from Labview. Not ideal, but not too ugly either.

Cheers,

Dave

--- Quote Start ---

I don't quite understand the path from the JTAG Master IP on the FPGA to the PC - will it "bind" to the JTAG port automatically? What SW App do I run on the PC to get a command-line interface to it?

If there's like, a good tutorial on this (or a few manual section), I'm game to

--- Quote End ---

Its all about knowing the right terminology, eh. Look in the Quartus Handbook at System Console. This tool is a Tcl console with Tcl procedures that can be used to find your device on the JTAG chain, and then send read/write commands. The Virtual JTAG interface is accessed from a different tool, quartus_stp, with different Tcl procedures. Start with System Console, as this seems like the tool Altera wants you to use.

Cheers,

Dave

Hi Dave - a lot to chew on here - I'll be back after digestion is complete 8-}

Thanks VERY much

/j

Hmmm - so many choices. It seems like i could get pretty far with In-System Sources and Probes (i.e., peek and poke), and this has the advantage of being "lighter" than system console (and defers the rampup on Qsys/sw driver stuff, etc), but it does sound like it eventually runs out of steam and I'll want to switch to System Console (and the more-SW-like paradigm, as well as Qsys). So I'm wondering how much wasted effort there is in starting with ISSP as it will get me up and running quicker.....

/j

--- Quote Start ---

So I'm wondering how much wasted effort there is in starting with ISSP as it will get me up and running quicker.....

--- Quote End ---

The System Console approach is not too bad. Rather than doing a lot of reading, start with 'doing'. Create a Quartus project, select the Stratix IV part, start Qsys, create a new Qsys design, add the JTAG Avalon-MM master, the RAM, and the PIO component. Put the LED at address 0, and the RAM at say address 0x1000. Instantiate the system in a top-level VHDL or Verilog design. Synthesize it. Assuming your PIO has 8-bits, go into the pin assignments editor and assign these pins to the LEDs on the board. Re-synthesize the design; check the .pin file to confirm that only the LED pins are used and the others are reserved (tri-stated).

Start system console, eg., in Quartus v11.0 Tools->Transceiver Toolkit, and then type 'source {<windows path to>/jtag_cmds.tcl}', where the curly braces pass the path to the 'source' command as a Tcl list. Look at the jtag_cmds.tcl file to see the procedures in there (the .tcl file is in the .zip attachment).

Now type 'jtag_read_32 0' to read the LEDs, 'jtag_write_32 0 0x55' to write to them, or 'jtag_read_32 0x1000' and 'jtag_write_32 0x1000 0x12345678'

to access the RAM. There are also LED Tcl procedures defined, eg. led_read and led_write 0x55.

That should give you enough of an incentive to go this route :)

Cheers,

Dave

good advice, and I think the right path to take. But you forgot step 0 - "learn enough about Qsys to use it" which is where I need to start 8-}.

Thanks for all your help. I may have to focus elsewhere for the next day or two but will be back on this next week.

best

/j

--- Quote Start ---

But you forgot step 0 - "learn enough about Qsys to use it" which is where I need to start 8-}.

--- Quote End ---

I didn't want to spoil the fun part ...

Cheers,

Dave