Forum Discussion
Altera_Forum
Honored Contributor
14 years agoTutorial: Using the USB-Blaster as an SOPC/Qsys Avalon-MM master
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, Dave119 Replies
- Altera_Forum
Honored Contributor
Hi Dave,
yes, I managed to start the server succesfully and let it connect to the JTAG Master interface in my design. I also managed to connect the client to the server. Unfortunately, I get an "Invalid command from the client" error when I try to send write requests. When I try to send read requests, the client GUI freezes. Attached is a screenshot of the client/server running with the mentioned error. In my GX FPGA, my component is connected to the JTAG to avalon Master Bridge as it is connected to the HPS in the SX FPGA, where the communication with my custom component just works from the HPS/Linux interface. I also attach a screenshot of my system. I am also not able to access the xcvr or reconfiguration component on their avalon slave interfaces... I looked for that error message in your server source and found that it was not even transmitting anything to the JTAG interface, because it already had problems before the actual write command. But I don't know, if this is the correct interpretation of the source code. Maybe you can help and tell me what I am doing wrong, here. Thanks, Maik - Altera_Forum
Honored Contributor
Hi Maik,
Take a look at the server code. If you start the server in debug mode it just accesses a Tcl variable. Use that mode to debug what the clients are doing. Start with just one client, and then check that it works. If you start a second client and it breaks, the issue could be related to the server handling of multiple clients. At some level this type of debugging gets too complicated ... not that using clients and servers is hard, but that Altera does not provide sufficient information to "design" everything nicely. If your hardware has a UART or FTDI interface, then you can write actual client/server code that will be more robust than using Altera's Tcl interfaces - some of which are broken and useless due to their use of Java. If you do want some advice on how to implement your system, feel free to ask here on the forum, or if you do not want to discuss your project in public, send an email to my forum name. Cheers, Dave PS. The forum resampled your images when you uploaded them, so they are too small and unreadable. - Altera_Forum
Honored Contributor
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
Honored Contributor
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
Honored Contributor
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
Honored Contributor
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
Honored Contributor
--- 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
Honored Contributor
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
Honored Contributor
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
Honored Contributor
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