Accessing JTAG_UART from Matlab

Hi JoBird,

I just got done putting together a tutorial on my blog about how to use the Virtual JTAG MegaFunction, with a Tcl TCP/IP Server (which runs in the quartus_stp.exe). From there you can talk to the FPGA's design using just about any programming language that supports TCP/IP connections.

Might be a possible option for you:

http://idle-logic.com/2012/04/15/talking-to-the-de0-nano-using-the-virtual-jtag-interface/

After making the tutorial, I found that Dave wrote a more rigorous tutorial on this sort of solution here:

http://www.alterawiki.com/wiki/using_the_usb-blaster_as_an_sopc/qsys_avalon-mm_master_tutorial

It would be nice to find a way to get rid of the Tcl middle layer, but I assumed I would have the same problems as you of trying to reverse engineer the Altera DLL's.

Maybe someone else knows the trick...

Regards,

Chris

--- Quote Start ---

It would be nice to find a way to get rid of the Tcl middle layer, but I assumed I would have the same problems as you of trying to reverse engineer the Altera DLL's.

Maybe someone else knows the trick...

--- Quote End ---

You can use the FTDI drivers under Linux and add the USB-Blaster to its list of devices. You can then access the USB-Blaster directly as a digital I/O device. The USB-Blaster USB byte-stream protocol was reverse-engineered a while back:

http://sourceforge.net/apps/mediawiki/urjtag/index.php?title=cable_altera_usb-blaster

I reverse-engineered the JTAG-to-Avalon-ST/MM protocol (the FPGA-side)

http://www.ovro.caltech.edu/~dwh/correlator/pdf/altera_jtag_to_avalon_analysis.pdf (http://www.ovro.caltech.edu/%7edwh/correlator/pdf/altera_jtag_to_avalon_analysis.pdf)

So that I could control the hardware directly, with no Altera code involved.

Under Windows, the FTDI DLL won't let you add another VID/PID to the list of devices it'll allow you to control, but I think you could get around that by erasing the EEPROM on your USB-Blaster (you can always program it back again using FTDI's FT_PROG).

If you've got more time to waste on this than me, feel free to email me directly and we can chat :)

Cheers,

Dave

Hey Dave,

I wonder if using the open-source libftdi drivers instead of the FTDI D2XX ones would work under Windows?

I'm glad to see there is a glimmer of hope on this.

--- Quote Start ---

I wonder if using the open-source libftdi drivers instead of the FTDI D2XX ones would work under Windows?

--- Quote End ---

I love open-source stuff, but libusb and libftdi are the classic case of "Open-source is free, assuming your time is worthless".

There's libusb, libusb-win32, libusb-1.0, libftdi, libftdi-1.0, and probably several other variants. Some of them work well under Linux, sort of work under Windows, some of them have crummy APIs, etc.

As I said, if you have more time to waste than I do ... :)

Cheers,

Dave

I've been subscribed to the libftdi mail-serv for awhile and they are fairly active on development, so slowly it is becoming more refined.

I have some other projects up first in the pipeline, but if I tackle this I'll touch base with you first to get up to speed. Hopefully JoBird will have it all figured out by then :)

Thanks for the replies. All of this seems an awful overkill just to implement a serial interface. It's beyond my comprehension why Altera doesn't provide a virtual com-port driver for this component. In the end that's exactly the purpose of a UART.

Unfortunately I also don't have much time to waste on this, but I contacted Altera and will post any updates I receive from them. In the meantime I will check out your proposals and see if I can get them to work.

Wish me luck. ;-)

--- Quote Start ---

It's beyond my comprehension why Altera doesn't provide a virtual com-port driver for this component. In the end that's exactly the purpose of a UART.

--- Quote End ---

My 2c on why they do not implement a Virtual COM Port; the JTAG port is too limited.

The JTAG interface is TCK, TMS, TDI and TDO. This interface is operated much like an SPI interface in that every write is a read. When an SPI device wants to communicate with the host it first generates an interrupt and then the host performs a read (and write) of the SPI status register to determine the source of the interrupt.

Why not do the same with the JTAG interface? ... Oh bummer, there is no interrupt pin defined. Why not add it? Because its too much work to implement, even more work to support, and better solutions exist.

To emulate a UART, the Altera software polls the JTAG interface. You can see this polling if you trace the USB traffic using Wireshark under Linux. There's a lot of traffic.

Ideally Altera software developers could have hidden this under a driver layer which in turn passes characters off to a COM port or serial driver, however, the fact that their USB-Blaster driver is essentially the FTDI driver, and their PCIe drivers are implemented using Jungo, leads me to believe that they don't really have Windows/Linux driver developers on staff (or they are too busy with NIOS Linux work).

If you take a step back, you'll realize that Altera is simply being practical. What would be nice though, is if Altera just opened up the software interface for JTAG, so Windows/Linux driver developers could implement these much more convenient/natural interfaces.

If you really want a USB-to-Serial port, just use an FTDI expansion cable (C232HD or C232HM). They're $26 on Digikey.

Cheers,

Dave

As a first point, I want to add a comment about the jtag_atlantic problems addressed in the initial post. I'm not working with Matlab dll interfaces, but I guess the problem is caused by the nature of jtag_atantic being a C++ dll with decorated names. See below a listing of the exported names.

LIBRARY     JTAG_ATLANTIC.DLL
EXPORTS
    ?jtagatlantic_cable_warning@@YAHPAUJTAGATLANTIC@@@Z
    ?jtagatlantic_close@@YAXPAUJTAGATLANTIC@@@Z
    ?jtagatlantic_flush@@YAHPAUJTAGATLANTIC@@@Z
    ?jtagatlantic_get_error@@YA?AW4JATL_ERROR@@PAPBD@Z
    ?jtagatlantic_get_info@@YAXPAUJTAGATLANTIC@@PAPBDPAH2@Z
    ?jtagatlantic_open@@YAPAUJTAGATLANTIC@@PBDHH0@Z
    ?jtagatlantic_read@@YAHPAUJTAGATLANTIC@@PADI@Z
    ?jtagatlantic_wait_open@@YAHPAUJTAGATLANTIC@@@Z
    ?jtagatlantic_write@@YAHPAUJTAGATLANTIC@@PBDI@Z

This makes is difficult to import the dll with a compiler that doesn't use exactly the same (Microsoft VC) name mangling. At least you need to be familiar with the import library generation procedure.

--- Quote Start ---

My 2c on why they do not implement a Virtual COM Port; the JTAG port is too limited.

--- Quote End ---

The JTAG port is surely limited. I can't follow however the "polling" point as a serious argument against JTAG UART usability. Altera JTAG is polling the UART usually with 6 MBPS. So what? A FTDI chip is polled through USB with 12 MBPS. O.K., there's a kind of bottleneck in the JTAG protocol itself and VJTAG on top of it.

Choosing a suitable communication method is a matter of data throughput, possibly intended utilization of existing VJTAG IP (e.g. Source&Probe, In-System Memory Editor, JTAG UART) and applications enviroment. According to my experience, the VJTAG tools are well suited for various calibration and test purposes. My ultimate product improvement suggestion is still a fully documented sld_hapi interface.

Regards,

Frank

Hi Frank,

--- Quote Start ---

The JTAG port is surely limited. I can't follow however the "polling" point as a serious argument against JTAG UART usability. Altera JTAG is polling the UART usually with 6 MBPS. So what? A FTDI chip is polled through USB with 12 MBPS. O.K., there's a kind of bottleneck in the JTAG protocol itself and VJTAG on top of it.

--- Quote End ---

I'll clarify this point, since there is polling done by the USB interface (to get data that is ready at the device) and there is polling at the application layer (performed by SystemConsole).

Polling done by the USB layer is just how USB works, so we can consider that 'for free', whereas polling by SystemConsole makes the interface less than ideal for use as a high-performance communications interface.

(Frank - I know you know most of the following, I'm just explaining the details for other readers of this post ...)

The USB-Blaster is implemented using an FTDI FT245 and a CPLD. The FT245 is operated in FIFO mode, where USB bytes are presented in parallel to the CPLD. Logic in the CPLD then interprets the bytes according to the protocol on the UrJTAG web site, and initiates JTAG serial activity. JTAG writes are always reads. A bit in one of the USB command bytes indicates whether the serial bits read by the CPLD should be packed into bytes and sent back over USB.

If you interface an FT245 directly to an FPGA in FIFO mode, you can stream bytes to/from the host computer at about 1MB/s. In this mode, the fpga can initiate data transfer to the host, by writing a byte directly to the FT245 FIFO interface. That byte gets sent over USB (USB polling collects it from the device) into the USB serial driver layer, and eventually your application 'read' call succeeds.

Using the USB-Blaster, to read bytes from your hardware, the host needs to send a stream of write (host-to-USB-Blaster) bytes, which are read by the USB-Blaster CPLD serialized to the JTAG interface on the FPGA. The TDO serial stream from from the FPGA is packed into bytes, and then sent back over JTAG. Because there is a CPLD between the FT245 and the FPGA, and the FPGA has no way of initiating data transfer to the host. The host has to poll the fpga jtag internal logic for data that the FPGA logic would like to send to the host.

The key difference for FPGA initiated transfers between these two cases, is for the FT245, the byte is sent directly when it is ready, and for the USB-Blaster, a host-to-FPGA data stream is needed to poll for that byte, the data stream has to be sent repeatedly until the byte is determined to be ready.

Arguably both cases are ultimately limited by the polled nature of USB. However, the direct connection between the FT245 and USB is a cleaner and higher-performance interface.

Cheers,

Dave