Interfacing to sld_hub

Why would you want to? The components are design to be interfaced from the JTAG port. Replacing the JTAG port with I/O pins that duplicate the function of the JTAG port is not very productive. You can control a USB-Blaster directly using FTDI's D2XX driver, so if your argument is that you want "total control" of the JTAG interface, I can help you with that.

Read these:

http://www.ovro.caltech.edu/~dwh/correlator/pdf/vjtag.pdf

http://www.ovro.caltech.edu/~dwh/correlator/pdf/altera_jtag_to_avalon_analysis.pdf

http://www.ovro.caltech.edu/~dwh/correlator/pdf/altera_jtag_to_avalon_analysis.zip

Cheers,

Dave

Hi Dave,

The question why I want to do it is different. Let's just say that replacing JTAG controller with my own custom component as shown in the drawing would be very productive. There is nothing to do with USB-Blaster.

Thanks,

Evgeni

--- Quote Start ---

The question why I want to do it is different. Let's just say that replacing JTAG controller with my own custom component as shown in the drawing would be very productive. There is nothing to do with USB-Blaster.

--- Quote End ---

I'm not sure that you can get to the SLD_HUB JTAG I/O, as its effectively a black box, eg., there's no way for you to intercept TDI/TDO, other than to use an SLD_HUB component and insert your multiplexer between the hub and your JTAG component. I suspect you could insert logic on the hub output to each of the nodes. Its pretty easy to 'sniff' the JTAG traffic from the SLD_HUB JTAG outputs - see the SignalTap traces in the documents above.

But as soon as you're modifying the JTAG interface at that level, there's really no need to use Altera's IP at all.

If you want to discuss what you're doing, but take it off-list, just send an email to my forum name, or if you like, describe what you are really trying to do :)

Cheers,

Dave

The diagram makes sense for me.

I have a similar situation in a design, where it would be interesting to connect several virtual JTAG functions used for service and debug purposes (e.g. source and probe, in-system memory content editor, signal tap) to a network interface instead of JTAG.

But SLD hub and related components are protected Altera IP and not available for modifications.

--- Quote Start ---

The diagram makes sense for me.

--- Quote End ---

It also makes sense to me too, but I was more interested in the ultimate goal, rather than this specific idea. There may be an alternative solution that does not require trying to get into "black box" IP.

--- Quote Start ---

I have a similar situation in a design, where it would be interesting to connect several virtual JTAG functions used for service and debug purposes (e.g. source and probe, in-system memory content editor, signal tap) to a network interface instead of JTAG.

--- Quote End ---

This is the situation I am facing with regards to a new design. Rather than trying to break into the IP, its easier to take over the JTAG interface. In your case, is there a host with network interface that can always access the JTAG USB-Blaster interface? If that host is an x86, then you could conceivable run the JTAG server on that machine. Then a remote machine running Quartus can be used to access the device.

I have done some testing using a PowerPC host (which cannot run Quartus). I plugged a BeMicro into a PowerPC USB interface, then used USB-over-IP to export the USB-Blaster over the network. A remote x86 host running Quartus and the USB-over-IP client software then connected to the USB-Blaster as a local USB device (the USB-over-IP client software converts the IP packets back to USB packets). This enabled the x86 to run the Quartus GUI and tools without having to break into the "black box" IP or reverse the protocols for their tools.

Cheers,

Dave

--- Quote Start ---

Rather than trying to break into the IP, its easier to take over the JTAG interface. In your case, is there a host with network interface that can always access the JTAG USB-Blaster interface? If that host is an x86, then you could conceivable run the JTAG server on that machine. Then a remote machine running Quartus can be used to access the device.

--- Quote End ---

I agree that connecting through the JTAG pins seems to be the only way to get access to the virtual JTAG resources.

In a system with the FPGA as only intelligent device that also performs all external communication, it might require a JTAG loopback, multiplexing the external JTAG connector with a JTAG master build in the FPGA.

I should mention, that the system wasn't originally designed to route the FPGA JTAG interface through a remote connection. But some years after launching the new hardware platform, we recognize that it would really ease the live of developers and service engineers. Although I know pretty well that Altera doesn't provide the option, I still think that simply reconnecting the virtual JTAG interface in the logic fabric looks like a straightforward solution.

Thanks for your suggestions,

Frank

--- Quote Start ---

I still think that simply reconnecting the virtual JTAG interface in the logic fabric looks like a straightforward solution.

--- Quote End ---

This would be fairly easy to do with a user SLD_Vitual_JTAG component, since you could introduce a mux on the JTAG signals at that component. But it would be a lot more difficult on say something like a SignalTap instance, where you really don't get to "see" any of the code Quartus generates.

Cheers,

Dave

There are two internal features in 12.1 which might solve your problems.

The first is a direct solution to your problem - instantiate an altera_soft_core_jtag_io module within your alternative controller. The sld hub will be connected to the tck/tms/tdi/tdo pins on the jtag io module instead of being connected to the JTAG pins.

The second is basically SignalTap over TCP. Attach an altera_sld_hub_controller_system to a Nios II (or similar) processor, route data from a TCP connection into the hub controller and set up Quartus correctly and then the Altera tools will talk to SignalTap (and In-System-Sources-and-Probes) over the TCP connection. This will be fully released in 13.0 (I hope) but if you want the reference design and instructions then send me a personal message with your email address. It doesn't have to be TCP for the last few mm - any 8 bit clean bidirectional pipe can be used with a bit of effort.

There is no official support on either feature but I'm sure you can make them work.

I didn't yet review the new features in Quartus V12.1. The altera_soft_core_jtag_io seems to solve the problem in the original post, and the planned extensions with my designs as well.

Thank you for the suggestion.