Tutorial: Using the USB-Blaster as an SOPC/Qsys Avalon-MM master

[Altera_Forum]

Hi all, 

 I've put together a tutorial on how to use the Altera JTAG-to-Avalon-MM master and Altera Verification IP Avalon-MM BFM Master under both SOPC builder and Qsys.  http://www.ovro.caltech.edu/~dwh/correlator/pdf/altera_jtag_to_avalon_mm_tutorial.pdf (http://www.ovro.caltech.edu/%7edwh/correlator/pdf/altera_jtag_to_avalon_mm_tutorial.pdf) http://www.ovro.caltech.edu/~dwh/correlator/pdf/altera_jtag_to_avalon_mm_tutorial.zip (http://www.ovro.caltech.edu/%7edwh/correlator/pdf/altera_jtag_to_avalon_mm_tutorial.zip)  The tutorial walks the user through the creation of an SOPC or Qsys system design, and provides scripts that automate the re-generation of the system. The tutorial shows how to simulate using Modelsim-ASE, and shows how to communicate with the hardware using System Console, quartus_stp, and then how to run a TCP/IP server under System Console or quartus_stp, and then communicate with that server from client code written in Tcl/Tk (a simple GUI) and a command-line C interface.  Let me know if you like it, or have feedback/suggestions on how to improve the document.  Cheers, Dave

[Altera_Forum]

Hi Dave, 

 sorry for the bad image quality. I should have ckecked this. Now, I uploaded the screenshots in a zip archive. Hopefully the shots are untouched now by the forum system....  I only use one client at a time. I need that one client in order to access the GX FPGA on my board. I think, by looking at the console output of the server, the server is connected to that FPGA correctly and the awaits the client to connect. This is also functioning as expected (judging the server console output). For the console output, please refer to the screenshot that is now in the zip archive.  After that, I think, I have not many options to do something wrong. I just enter an address and a data value in the jtag_client.tcl GUI and press "write". The server reflects the entered address and data correctly in its console but tells me that there is an error with that command. I don't think that I have any hardware access, because I signal tap my system but see no avalon signals toggling while I try to send my command.  Nevertheless, I will try the debug mode and see if I can find the error myself.  My hardware (the GX FPGA) is just meant to be a co-processor for the SX FPGA. So it only has some xsvr lines as communication interface and JTAG. That is the reason why I would like to use this JTAG-To-Avalon-Master thing for board test and firmware debug. Later on, if everything works as expected in the final design, I just need the xsvr link in order to send commands and data to the GX FPGA via a custom phy xsvr link.  I'm pretty confident that my design is on the right path because I use the same avalon slave component in the SX FPGA that I also use in the GX FPGA. The only difference is that my avalon master in the SX ist the LWH2F Bridge of the HPS, while in the GX, my avalon master ist the JTAG bridge. In the SX FPGA I have no problems to access the component via avalon.  So basically the question right now is if you have an idea why the command that is formed in the jtag_client.tcl GUI ist invalid for the jtag_sever.tcl process?  Regards, Maik

[Altera_Forum]

Hi Maik, 

 Here's the procedure I just used to check the server+client tcl code.  1. Start a NIOS II IDE Console (Cygwin shell) and start the server   quartus_stp -t jtag_server.tcl 2540 1  2. Start a NIOS II IDE Console (Cygwin shell) and start the first client   quartus_stp -t jtag_client.tcl  3. Start a NIOS II IDE Console (Cygwin shell) and start the second client   quartus_stp -t jtag_client.tcl  4. Write and read to addresses from both clients, and look at the messages in the server console   For example, in the first client write (addr, data) = (0, 1111), (1, 2222), (2, 3333), (3, 4444)   Then in the second client, read all of those addresses.  It worked fine for me.  When using a JTAG-to-Avalon device, you might want to make sure the addresses are 4-bit aligned, eg., write to addresses 0, 4, 8, 0xC, etc.  Have you confirmed your JTAG-to-Avalon-MM bridge interface works with SystemConsole?  Cheers. Dave

[Altera_Forum]

Hey Dave, 

 I'm still struggling with the client/server applications, but had no time to continue on that for since the beginning of the week.....  I use the transceiver toolkit on our custom board succesfully, so I think the JTAG-to-Avalon-MM bridge does work correctly from system console because I can control all transceivers in both FPGAs without any problems. Since it seems that I have a major misunderstanding in transceivers, I will focus on that first and come back to this issue in a couple of days.....  By the way, you are talking about using the cygwin shell.... I'm using a Debian Linux anyway, so I try to perform everything from the linux console, but in my opinion that should not be the cause for my problems.... what do you think?  Regards, Maik

[Altera_Forum]

Hi Maik, 

 What kind of transceiver problems are you suffering from? I've suffered from a few myself :)  Using Debian should be fine. I typically check my stuff with Centos to make sure things work under Linux.  Cheers, Dave

[Altera_Forum]

--- Quote Start ---  Hey Dave,  I'm still struggling with the client/server applications, but had no time to continue on that for since the beginning of the week.....  I use the transceiver toolkit on our custom board succesfully, so I think the JTAG-to-Avalon-MM bridge does work correctly from system console because I can control all transceivers in both FPGAs without any problems. Since it seems that I have a major misunderstanding in transceivers, I will focus on that first and come back to this issue in a couple of days.....  By the way, you are talking about using the cygwin shell.... I'm using a Debian Linux anyway, so I try to perform everything from the linux console, but in my opinion that should not be the cause for my problems.... what do you think?  Regards, Maik  --- Quote End ---    Probably you could further elaborate on your transceiver problem.

[Altera_Forum]

Hi Dave, hi tiny007 

 I have posted a thread over here http://www.alteraforum.com/forum/showthread.php?t=50316&p=206893#post206893 (http://www.alteraforum.com/forum/showthread.php?t=50316&p=206893#post206893).  The main question really is, if I have to take care about anything but my data I would like to transmit? e.g., do I have to check myself for word alignment patterns although I have set this up in the transceiver phy component in QSys.  Regards, Maik

[Altera_Forum]

Hi Maik, 

  --- Quote Start ---   The main question really is, if I have to take care about anything but my data I would like to transmit? e.g., do I have to check myself for word alignment patterns although I have set this up in the transceiver phy component in QSys.   --- Quote End ---   The answer is "it depends". Since it depends on how you've setup the transceiver. If you control both ends of the link, then you can use the 8/10B encoders and have the transceiver recover the synchronization.  If you do not use 8/10B encoding, then you have to synchronize the links yourself. For example, I have used the transceiver sync pattern detect logic, and hard-coded it to the start of a PRBS sequence and used that to synchronize lanes.  The main thing is, get it working in simulation first! :)  Cheers, Dave

[Altera_Forum]

Hey Dave, 

 Thanks for the answer...  I know I should use simulation. If you take a look at the other thread I mentioned above, you see that I test everything using signal tap. Maybe you have something to add to the questions, I asked over there.  Since I don't use 8/10b encoding just like the transceiver toolkit examples, I wonder how I perform alignment myself. I haven't found that particular part in the TTkit until now, where the alignment takes place....  Thanks, Maik

[Altera_Forum]

Hi Maik, 

  --- Quote Start ---   I know I should use simulation. If you take a look at the other thread I mentioned above, you see that I test everything using signal tap. Maybe you have something to add to the questions, I asked over there.   --- Quote End ---   I'll take a look now (I didn't have time last night).    --- Quote Start ---   Since I don't use 8/10b encoding just like the transceiver toolkit examples, I wonder how I perform alignment myself. I haven't found that particular part in the TTkit until now, where the alignment takes place....   --- Quote End ---   The TTK examples do not use alignment *at all*.  The TTK examples use a pattern generator based on a linear feedback shift-register (LFSR), which is also referred to as a pseudo-random binary sequence (PRBS) (Technically the PRBS is the bit-stream and the LFSR is the bit-stream generator). Read all about LFSRs/PRBSs here:  https://www.ovro.caltech.edu/~dwh/correlator/pdf/lfsr_tutorial.pdf https://www.ovro.caltech.edu/~dwh/correlator/pdf/lfsr_tutorial_src.zip  An LFSR can be loaded from the bits in a PRBS sequence, and then the contents of the LFSR used to predict what the next bits in the sequence should be. That is the feature the TTK uses.  What does that mean? The TTK receive side simply gathers 32-bits or 40-bits from the parallel output of the receiver, loads those into the matching LFSR (an LFSR in the receiver that matches the transmitter polynomial), and then the output of the LFSR should match the next 32-bits or 40-bits from the parallel output. The receiver parallel bits are XORed with the expected PRBS bits, and any differences are counted as bit errors.  The TTK receiver is dumb ... that is the beauty of the TTK ... if it doesn't work, you know you're in trouble :)  If you want to transfer actual data over a link, then you need to take care of the alignment. The simplest method is to use 8/10B encoding.  Cheers, Dave

[Altera_Forum]

Hi Dave, 

   --- Quote Start ---  I'll take a look now (I didn't have time last night).  --- Quote End ---   a big thanks, that you take care for the communities problems, the way you do! So now worries, I can wait! (escpecially because it ist weekend, I haven't expected to get an answer at all....)    --- Quote Start ---  The TTK examples do not use alignment *at all*.  --- Quote End ---   Well, that explains a lot, at least for me ...... :rolleyes:    --- Quote Start ---  What does that mean? The TTK receive side simply gathers 32-bits or 40-bits from the parallel output of the receiver, loads those into the matching LFSR (an LFSR in the receiver that matches the transmitter polynomial), and then the output of the LFSR should match the next 32-bits or 40-bits from the parallel output. The receiver parallel bits are XORed with the expected PRBS bits, and any differences are counted as bit errors.  The TTK receiver is dumb ... that is the beauty of the TTK ... if it doesn't work, you know you're in trouble  If you want to transfer actual data over a link, then you need to take care of the alignment. The simplest method is to use 8/10B encoding.  --- Quote End ---    Those are the sentence of explanation I was looking for for a couple of days. I wonder, why Altera puts tens of thousands pages of documentation together, but often lacks the simplest form of explanation. Well, maybe it is my own stupidity to not realize or know about all those PRBS facts, but anyway, thank you Dave, this clears up so much in my misunderstanding and really helps to focus on the main target now (->implementing alignment in my own design instead of trying to understand how alignment works in the TTK....)  Thanks, Maik

[Altera_Forum]

--- Quote Start ---   a big thanks, that you take care for the communities problems, the way you do!    --- Quote End ---   I know how frustrating it can be when you hit a wall and have no one to ask questions of.    --- Quote Start ---   Those are the sentence of explanation I was looking for for a couple of days. I wonder, why Altera puts tens of thousands pages of documentation together, but often lacks the simplest form of explanation. Well, maybe it is my own stupidity to not realize or know about all those PRBS facts, but anyway, thank you Dave, this clears up so much in my misunderstanding and really helps to focus on the main target now (->implementing alignment in my own design instead of trying to understand how alignment works in the TTK....)   --- Quote End ---   Lots of technology companies do not have people that can actually explain the technology :)  I've got into the habit of writing my 'debugging' of new hardware (development kits) as a tutorial ... for my "future self" and for anyone else who is interested :)  Cheers, Dave

[Altera_Forum]

Hi Dave! Thanks for a really good tutorial. Would it be possible to move the jtag server logic into C in a Nios II processor. I'd like to remove the need to run a tcl script. Thanks!

[Altera_Forum]

--- Quote Start ---  Hi Dave! Thanks for a really good tutorial. Would it be possible to move the jtag server logic into C in a Nios II processor. I'd like to remove the need to run a tcl script. Thanks!  --- Quote End ---   If you're going to use a NIOS II processor, then I would advise you to use a regular UART connected to GPIO pins. There is a JTAG UART component, but I am not sure that it is easy to write C/C++ code to interact with since it is not visible as a COM port or /dev/tty port. There are several FTDI cables that allow you to connect a USB-to-serial UART to your PC, and then you can connect that cable to GPIO headers on your development board. The FTDI devices can be used in synchronous modes too, and can achieve much higher performance. Check out the FTDI documentation I've written here:  https://www.ovro.caltech.edu/~dwh/correlator/cobra_docs.html  This describes the SPI-like modes you can use (MPSSE mode is the best) https://www.ovro.caltech.edu/~dwh/correlator/pdf/ftdi_spi.pdf  This has some more advanced uses of the FIFO interface https://www.ovro.caltech.edu/~dwh/correlator/pdf/ftdi.pdf  In your case, start with a UART, and just connect the pins from a cable like this ... http://www.ftdichip.com/products/cables/usbmpsse.htm http://www.digikey.com/product-detail/en/ftdi-future-technology-devices-international-ltd/c232hm-ddhsl-0/768-1106-nd/2714139  Cheers, Dave

[Altera_Forum]

--- Quote Start ---  Would it be possible to move the jtag server logic into C in a Nios II processor. I'd like to remove the need to run a tcl script. Thanks!  --- Quote End ---   Re-reading your question, I wonder if you really understand what is going on.  The Tcl script communicates from the host to the FPGA. There is no option to move this into the NIOS processor. You could replace this logic with C-code, but you would have to use libusb or libftdi and communicate with the Altera USB-Blaster directly. Since this interface is not published, I had to use the Tcl script. There is some information on the web, and it is possible to communicate from C, but that C code runs on the host processor, not on the NIOS processor.  Hopefully my previous answer was what you were really looking for, but if not, ask your question again, and I'll see if I can answer it clearer next time.  Cheers, Dave

[Altera_Forum]

Thanks for both of your replies!  

 Re-reading my question, I realize I didn't actually mean a Nios II processor. (All this work with Altera tools lately has tied C to Nios in my mind) I wanted to move away from needing to run a tcl script in SystemConsole. For a clearer picture, the board I am working with only has a JTAG to USB connection to the connecting PC. I was hoping to use this connection to do reads/writes to the Avalon MM. Your tutorial accomplishes the second part of my goal but not the ability to not need the Altera toolset. I think your second answer where you talk about replacing this logic with C-code is what I need to do and have it run on my host computer.

[Altera_Forum]

--- Quote Start ---   Re-reading my question, I realize I didn't actually mean a Nios II processor. (All this work with Altera tools lately has tied C to Nios in my mind) I wanted to move away from needing to run a tcl script in SystemConsole. For a clearer picture, the board I am working with only has a JTAG to USB connection to the connecting PC. I was hoping to use this connection to do reads/writes to the Avalon MM. Your tutorial accomplishes the second part of my goal but not the ability to not need the Altera toolset. I think your second answer where you talk about replacing this logic with C-code is what I need to do and have it run on my host computer.  --- Quote End ---    Both answers provide options. The question is, which is the least amount of work?  Does your board have GPIO pins connected to 100-mil headers? If so, then using an FTDI cable is by far the simplest solution.  If you really like beating yourself up, then I can give you some links to the reverse-engineered USB-Blaster protocol ... but honestly, the interface is not that fast, so it is a lot of work, for very little gain.  Which board are you using?  Cheers, Dave

[Altera_Forum]

Hi Dave, 

 Thanks again for your response. The board I am using is a board created for the group that I work with. We are trying to consolidate and only have one communication interface, hence my interest in moving things to the jtag port.   The main usage of the communication interface will be to grab some data that I've stored in the Avalon-MM. The interface speed won't really be an issue but from what I've looked at it's going to be pretty difficult to implement. Would you mind sending me the links?   Thanks!!

[Altera_Forum]

--- Quote Start ---   Would you mind sending me the links?    --- Quote End ---   The protocol was first reverse-engineered by Kawk (Kolja Waschk)  http://ixo-jtag.sourceforge.net/ https://github.com/swetland/jtag/blob/master/usb-blaster-protocol.txt  The protocol has been used in other projects to interface to the USB-Blaster, eg., open-cores debug core.  Under Windows I have used libftd2xx and under Linux I have used libusb and confirmed some basic Avalon-MM operations work fine.  Did you read both the JTAG tutorial and the JTAG analysis documents? Scroll down to "Altera JTAG-to-Avalon Analysis"  https://www.ovro.caltech.edu/~dwh/correlator/cobra_docs.html  The JTAG-to-Avalon-MM tutorial source contains a Tcl script that implements the SystemConsole equivalent commands for the JTAG Avalon-MM protocol ...   altera_jtag_to_avalon_mm_tutorial\tcl\altera_jtag_to_avalon_stp\altera_jtag_to_avalon_stp.tcl  Look at this source along with the analysis document, as well as running a few SignalTap II traces using a second FPGA board, and you should be able to understand the protocol at the bytes layer once inside the FPGA. The USB-Blaster protocol tells you how to send packets to the USB-Blaster circuit to produce these byte streams.  You can re-implement the quartus_stp commands easily enough using the USB-Blaster protocol commands.   Before implementing the USB-Blaster command protocol, go and write some C/C++ code that implements the FTDI MPSSE protocol. You'll find that it contains similar concepts to the USB-Blaster protocol.  You can actually connect an MPSSE cable to the USB-Blaster 10-pin JTAG header and produce the byte-streams shown in my JTAG analysis document.  Note that the USB-Blaster logic itself is not that complicated either. You can implement the control state machine based on a knowledge of the protocol. I've created versions with the FT245 and FT232H device. Unfortunately Altera has bugs in their software that makes the FT232H devices fail (my guess is a hard-coded buffer size somewhere in the Altera USB-Blaster interface code). Anyway, the work started to be an effort in futility, so I moved on :)  Cheers, Dave

[Altera_Forum]

Any suggestions on how (or if) the usb-blaster avalon jtag master could be used to transfer a block of memory that sits on the avalon bus? I'm trying to debug a video buffer, and it would be super useful if I could pull the raw binary data directly from memory, repeatedly, and as fast as the blaster protocol allows.

[Altera_Forum]

--- Quote Start ---  Any suggestions on how (or if) the usb-blaster avalon jtag master could be used to transfer a block of memory that sits on the avalon bus? I'm trying to debug a video buffer, and it would be super useful if I could pull the raw binary data directly from memory, repeatedly, and as fast as the blaster protocol allows.  --- Quote End ---    Just use the JTAG-to-Avalon-MM bridge and connect it as another master to the memory.  Cheers, Dave

[Altera_Forum]

Very useful. Thanks for sharing!