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]

--- Quote Start ---   Say I take your example design with the ram, leds and buttons, and instead of buttons I use switches. I run this design on two boards. On one board I put the switch to high / one, meaning Master. On the other board I put the switch to low/zero, meaning Slave.   --- Quote End ---     I have a similar setup with two Stratix IV GX Development kits.  The first thing I did was download FTDI's FT_PROG tool  http://www.ftdichip.com/support/utilities.htm  and I reprogrammed the Serial Number in the on-board USB-Blaster to have a unique value for each board, eg., S4GXDK01 and S4GXDK02. This ensures that Windows does not have issues when seeing two devices attached with the same USB serial numbers (in my experience all boards ship with a common serial number).    --- Quote Start ---    I connect two usb-byteblaster to my pc and start System Console Situation 1: How do I: - Scan for all available jtag2avalon master?   --- Quote End ---     The Tcl code in jtag_open ...   # Get the list of masters set masters if { == 0} { error "Error: No JTAG-to-Avalon-MM device found!" } # Access the first master in the masters list set jtag(master) open_service master $jtag(master)   Always accesses the first master in the list. In your code, you would modify this code to be something like  1. Add an argument which is the switch ID, eg., 0 or 1  2. Has the switch ID to master index mapping been created? If no, go to step 3, else go to step 4  3. Identify the two boards  - Open the first master, read its ID switch setting, store that info in the jtag global  - Open the second master, read its ID switch setting, store that info in the jtag global  4. Based on the switch ID argument, open_service on the master  Its been a while since I've played with my hardware setup, but I recall that System Console did not allow multiple JTAG masters to be accessed at the same time, i.e., you had to close one before opening the other. To deal with that, your JTAG read/write procedures need an extra argument, i.e., the master index, and then inside the read/write procedures you need to open the master perform the read/write, and then close the master.  In Tcl you can use a default value, eg.,   proc jtag_read {addr {master 0}} { # Read from addr on JTAG master 0 by default }     --- Quote Start ---   Situation 2: This should be dynamic. When I have this running, I want to be able to switch both boards in the other mode. Meaning, the master becomes slave, and the slave becomes master.   --- Quote End ---   If you want it to be dynamic, then the mapping between ID and master would not be cached as described above, but determined for every access, i.e., read/write would be  1. Open the first master, is it the correct ID? Yes, go to step 3 2. Open the second master, is it the correct ID? (It should be) 3. Perform the read/write 4. Close the master    --- Quote Start ---   I would like to run the same script without modifying it, and detect the new master and new slave board. Is that possible?   --- Quote End ---   Once you have modified the read/write procedures to open, detect the board, perform the read/write, and then close the board, then yes, this is all automated.    --- Quote Start ---   Situation 3: Now I start debugging, and add sometimes a NIOS with a jtag_uart, sometimes signaltap, sometimes both and sometimes none. Can this script then still identify the jtag2avalon master and detect the master board and the slave board? I assume that the nios has certain "jtag_identifier_code", and the signaltap as well.   --- Quote End ---   You'll have to try it and see.  I've had problems initializing SignalTap II triggers if I do not first "open" the JTAG master that is the source of the trigger, eg., it writes to a particular location.  Cheers, Dave

[Altera_Forum]

--- Quote Start ---   How do I: - Scan for all available jtag2avalon master?   --- Quote End ---    This code should do it  foreach m { array set info puts "Found master at $info(FULL_HPATH)" }    --- Quote Start ---   - How do I assign a tcl variable MASTER, to the board that has the switch to one? So that I can use that MASTER in my other procedures for doing master_functions. For example "lit led 0 if you are a master board" - And the same question for the slave.   --- Quote End ---    I assume you have a PIO slave which can read the value of the switch, and that this slave is mastered by an altera_jtag_avalon_master or altera_usb_debug_master.  Maybe something like this (I think I got the brackets right but please check):  foreach m { array set info if {$info(FULL_HPATH) == "my|expected|hpath"} { set mm set v if {$v == 1} { set master_on_master_board $m } else { set master_on_slave_board $m } close_service master $mm } }    --- Quote Start ---     Situation 2: This should be dynamic. When I have this running, I want to be able to switch both boards in the other mode. Meaning, the master becomes slave, and the slave becomes master. I would like to run the same script without modifying it, and detect the new master and new slave board. Is that possible?   --- Quote End ---    Yes, this is possible, you'll need to keep reading from the PIO slaves and arrange to swap your masters over when the roles change. The Tcl after (http://www.tcl.tk/man/tcl8.5/tclcmd/after.htm) command can be used to do this sort of thing (but make sure you have a way to cancel the after).    --- Quote Start ---   Situation 3: Now I start debugging, and add sometimes a NIOS with a jtag_uart, sometimes signaltap, sometimes both and sometimes none. Can this script then still identify the jtag2avalon master and detect the master board and the slave board? I assume that the nios has certain "jtag_identifier_code", and the signaltap as well.   --- Quote End ---    Each debug node has an identifier code which is used by the tools to work out which drivers need to be used to control it. SignalTap, JTAG UART, Nios II processor, JTAG debug link etc all have different IDs.

[Altera_Forum]

--- Quote Start ---   Thanks! When was this function introduced (which Quartus release?)?  I doubt that it will be faster at the JTAG layer (since the JTAG traces show that master_read/write_memory are as efficient as possible), but at least it saves Tcl performing binary->string and string->binary conversions.  --- Quote End ---    It was first introduced in ACDS 12.1 I think.  Tcl is actually pretty good at conversions providing you use the right data structures. Where master_read_to_file and write_from_file really win is that they can do overlapped I/O (starting the second transfer while the hardware is processing the first one). For big transfers this hides the latency of the transfer and leads to a big performance improvement.  Out of interest, which tool are you using for your JTAG tracing?

[Altera_Forum]

--- Quote Start ---   Out of interest, which tool are you using for your JTAG tracing?  --- Quote End ---    The JTAG traces in this analysis document are from SignalTap II  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

[Altera_Forum]

Hi wombat, 

master_get_info in your code doesn't work.   foreach m { array set info puts "Found master at $info(FULL_HPATH)" }  When I type   % info commands master*  I get   master_read_memory master_write_from_file master_write_8 master_write_memory master_read_8 master_read_to_file master_read_16 master_write_16 master_read_32 master_write_32 %   What should this be?  Rgds, Kimberley

[Altera_Forum]

Sorry, the command should be marker_get_info. I'll edit my post in case people find it in future. Thanks for spotting that.

[Altera_Forum]

Folks, 

 Sorry for the late reply, but just to let you know I've got it working. I can now recognize the two phy's on the two boards. Thanks again for all the support.  Rgds, Kimberley

[Altera_Forum]

Thank you very much for this tutorial. It got me pretty far. However, I did this in Quartus II 13.0 sp1 and there are some differences, two of which result in errors. I didn't go through the SOPC Builder chapter since that tool isn't available anymore. 

 

1. There are 33 warnings, not 3, when generating the Verilog files in Qsys. These are all Warning: qsys_system: "No matching role found for rst_controller:reset_out:reset_req (reset_req)". According to support solution spr371633 (http://www.altera.com/support/kdb/solutions/spr371633.html), these can be ignored. 
2. The logic element counts are different (e.g. 1106 at the top level, not 1058). I suppose Altera changed the library components. 
3. The Quartus II Handbook is different (e.g. the system console commands in table 10-3 mentioned in section 5.1 is on pages 10-9 through 10-11 of version 13.0 of the handbook). 
4. When compiling the simulations, the vlog command's -L argument that worked for me is libraries/altera_avalon_vip_pkgs_lib, not qsys_system_bfm_master. 
5. $TUTORIAL/hdl/qsys_system/scripts/sim.tcl contains the above error.

  Section 4.5.1 talks about generating the code but I almost didn't do it because that discussion is formatted as regular text. All of the other directions are given in a list format.  The tutorial says nothing about how to use Quartus II to program the device. Perhaps you can add something about programming?

[Altera_Forum]

--- Quote Start ---  Thank you very much for this tutorial. It got me pretty far.  --- Quote End ---   Great!    --- Quote Start ---   However, I did this in Quartus II 13.0 sp1 and there are some differences, two of which result in errors. I didn't go through the SOPC Builder chapter since that tool isn't available anymore.   --- Quote End ---   Darn! I guess its time for me to revise the tutorial ... its been on my TODO list for a while :)  I'll take a look at it this week.    --- Quote Start ---   The tutorial says nothing about how to use Quartus II to program the device. Perhaps you can add something about programming?  --- Quote End ---    Ok, I'll add a walk through.  Cheers, Dave

[Altera_Forum]

I haven't had a chance to revise the tutorial yet, however, I did have a look at resolving the issues with Modelsim simulation. 

 The Qsys Verification IP Suite zip file (qsys_vip.zip) in this thread:  http://www.alteraforum.com/forum/showthread.php?t=32952&page=3  walks through the simulation of a Qsys system under Quartus 12.1sp1 and 13.1.  Cheers, Dave

[Altera_Forum]

Hello Dave, I would like to take a look at your tutorial but the sadly the links doesn't work for me. 

Can you take a look at it? Can you provide another download links?   Thank you!

[Altera_Forum]

The links work fine for me. Check your internet connection.

[Altera_Forum]

--- Quote Start ---  I would like to take a look at your tutorial but the sadly the links doesn't work for me. Can you take a look at it? Can you provide another download links?    --- Quote End ---   The Altera Wiki link is: http://www.alterawiki.com/wiki/using_the_usb-blaster_as_an_sopc/qsys_avalon-mm_master_tutorial  That page links to documents that are stored here (along with other tutorials you may be interested in); http://www.ovro.caltech.edu/~dwh/correlator/cobra_docs.html  Cheers, Dave

[Altera_Forum]

What an excellent tutorial! Immensely useful! 

 Just a couple of thoughts/questions...  1) Not sure if the term 'BFM' is an industry standard, but even Avalon's Verification IP document doesn't list what it stands for. The only thing I could see is "Bus Functional Model" is this correct?  2) In section 3.5.1, it says the test_bench generated by Altera is not recommended, in favor of the custom 'sopc_system_bfm_master_tb.sv'. Any pointers on the thought process when designing that file? Similarly for the contraints file called in the synthesis script.  3) Regarding simulation, isn't the Avalon-MM Master BFM a subset of the JTAG-to-Avalon-MM Master? If so, aside from running slower, wouldn't running just the single JTAG-to-Avalon-MM Master simulation cover JTAG and the Avalon-MM, and be closer to how the real application operates?  4) Section 4.2 says that using verilog specific includes is bad practice because among other reasons it's synthesized over-and-over even though it never changes, but in Section 4.5.1 it says that copying the library source into the working project folder is also disadvantageous... wouldn't that be solving the 'include' issue?  5) Finally, if a system already has a MM master (i.e. a soft processor), does the inclusion of the JTAG master cause potential access issues? Especially if for example an avalon slave is running from a clock that is not the same as the jtag_master peripheral? I would also imagine that if using the jtag for debugging nios code, then the quartus_stp / jtag client cannot be run simultaneously, correct?  Thanks again for making a great tutorial!!

[Altera_Forum]

--- Quote Start ---  What an excellent tutorial! Immensely useful!   --- Quote End ---   Glad you enjoyed it!    --- Quote Start ---   Just a couple of thoughts/questions...  1) Not sure if the term 'BFM' is an industry standard, but even Avalon's Verification IP document doesn't list what it stands for. The only thing I could see is "Bus Functional Model" is this correct?   --- Quote End ---   Yep, that is correct. Its an industry standard term.  http://en.wikipedia.org/wiki/bus_functional_model    --- Quote Start ---   2) In section 3.5.1, it says the test_bench generated by Altera is not recommended, in favor of the custom 'sopc_system_bfm_master_tb.sv'. Any pointers on the thought process when designing that file? Similarly for the contraints file called in the synthesis script.   --- Quote End ---   The default testbench Altera generates has "nothing" in it, except for a clock generator and a comment to "add your code here".  The thought process is that Altera's code is a wrapper, and its hidden inside the generated system file. You're much better off ignoring that module, and just instantiating the component in your own testbench. That way your testbench is a separate file, and you can check it into your code versioning system (git, CVS, subversion, etc).    --- Quote Start ---   3) Regarding simulation, isn't the Avalon-MM Master BFM a subset of the JTAG-to-Avalon-MM Master? If so, aside from running slower, wouldn't running just the single JTAG-to-Avalon-MM Master simulation cover JTAG and the Avalon-MM, and be closer to how the real application operates?   --- Quote End ---   Nope. The BFM is non-synthesizeable code.  The JTAG simulation procedures I "found" in the JTAG-to-Avalon-MM mean that you can simulate using it, and get "closer" to the objective of testing something alot closer to what you implement in hardware.    --- Quote Start ---   4) Section 4.2 says that using verilog specific includes is bad practice because among other reasons it's synthesized over-and-over even though it never changes, but in Section 4.5.1 it says that copying the library source into the working project folder is also disadvantageous... wouldn't that be solving the 'include' issue?   --- Quote End ---   Nope. If you write lots of code, you want to keep it in a versioning system. Modelsim is quite happy to compile that code once into a library, and then use the built (binary) copy for as many different designs/projects that use it. Quartus and Qsys annoyingly *copy* your component code into the Qsys system simulation and synthesis subfolders, and then the Modelsim scripts point to those *copies*. If you edit the component code in your development area (where you can check code in or out), your changes never get seen (unless you re-run Qsys), since the Altera simulation script is looking at the copy! Very annoying. I get around this now using .qip files, which contain pointers to the source, and Quartus then just copies the .qip files. I also ditched using the msim_setup.tcl scripts, and just copy the Qsys component build instructions into my own Modelsim script.  When I update the tutorial, I'll describe this in detail.    --- Quote Start ---   5) Finally, if a system already has a MM master (i.e. a soft processor), does the inclusion of the JTAG master cause potential access issues? Especially if for example an avalon slave is running from a clock that is not the same as the jtag_master peripheral? I would also imagine that if using the jtag for debugging nios code, then the quartus_stp / jtag client cannot be run simultaneously, correct?   --- Quote End ---   The Avalon-MM bus allows multiple masters, so that is never an issue.  So long as the JTAG interface is accessed via Quartus (programmer, SignalTap II, system console, NIOS II debug), then the software multiplexes the access. You do need to make sure you "allow" the access to take place though, for example, when accessing JTAG via system console, you sometimes need to close the JTAG access to allow another tool to use it, eg., to capture a SignalTap II trace.  Cheers, Dave

[Altera_Forum]

--- Quote Start ---     --- Quote Start ---   3) Regarding simulation, isn't the Avalon-MM Master BFM a subset of the JTAG-to-Avalon-MM Master? If so, aside from running slower, wouldn't running just the single JTAG-to-Avalon-MM Master simulation cover JTAG and the Avalon-MM, and be closer to how the real application operates?   --- Quote End ---   Nope. The BFM is non-synthesizeable code.  The JTAG simulation procedures I "found" in the JTAG-to-Avalon-MM mean that you can simulate using it, and get "closer" to the objective of testing something alot closer to what you implement in hardware.   --- Quote End ---    Thanks! I understand the BFM is strictly for simulation/verification, but isn't the simulation mechanism for the JTAG-to-Avalon-MM you 'found', also meant for testing the system before actually synthesizing to hardware? If so, is it that the BFM simulation is more exhaustive in coverage than the coverage in JTAG-To-Avalon-MM?  BTW, even though it's not one of the targeted boards, I thought I'd give all this a try on my oldy DE1 (Cyclone II) board. While I don't get any error messages, I'm not seeing the correct values read back. Are the master_read_32 , master_write_32, commands that you created in a .tcl file for the BeMicro/SDK/DE2 boards specifically, or are these commands part of a generic tcl library from Altera?   Since all the commands complete fine, I don't think it's an issue of paths... basically, I open the system console (invoked via the Nios Command shell by typing 'system_console'), I list then set the master to the device that shows .../phy_0/master , open the service, and do reads/writes. (As a sanity check, if I disconnect the blaster, and try to open the service, I get an error message!)  On the top level I have a 16-bit constant driving a PIO to Qsys, but when I do a master_read_32 it's looks like random data.. but it's consistent, different base memory addresses always report different values from each other, but always the same with respect to itself.   As another data point I thought I'd try using the command line tool quartus_stp, but this seems to open SignalTap... not an interactive shell. I tried copying all the tcl files to quartus/common/tcl/packages but still no luck.  In short, I figured the high level procedures in jtag_cms_sc.tcl (pb, sw, led_read) would need porting if using a different board, but perhaps there's something else that's board specific that I need to change first?

[Altera_Forum]

--- Quote Start ---  I understand the BFM is strictly for simulation/verification, but isn't the simulation mechanism for the JTAG-to-Avalon-MM you 'found', also meant for testing the system before actually synthesizing to hardware? If so, is it that the BFM simulation is more exhaustive in coverage than the coverage in JTAG-To-Avalon-MM?   --- Quote End ---   Its likely the JTAG-to-Avalon-MM stuff was put there for testing by someone, but its undocumented, and does not exist for the VHDL version of the component. Ideally Altera would provide testing hooks into all of their JTAG code, but they do not. The difference between testing with the BFM and with the JTAG-to-Avalon-MM bridge is that you are generating Avalon-MM transactions differently. The BFM can generate a much richer set of transactions and so is more useful for testing your custom Avalon-MM components before you use them.    --- Quote Start ---   even though it's not one of the targeted boards, I thought I'd give all this a try on my oldy DE1 (Cyclone II) board   --- Quote End ---   The instructions are board-agnostic. I don't have a DE1 (so can't test your code), but the procedure works fine on every board I've tried. Which version of Quartus are you using? (Perhaps something has been broken).  Did your simulation work ok?    --- Quote Start ---   As another data point I thought I'd try using the command line tool quartus_stp, but this seems to open SignalTap... not an interactive shell.    --- Quote End ---   You should be able to use quartus_stp -t (or is it -s?) to start the shell. But in that case you need to use a different set of Tcl procedures to access the hardware (the script is in the zip).  Check your simulation first, and if its ok, let me know what version of Quartus you used and I'll do a hardware check with the BeMicro-SDK or DE0-nano.  Cheers, Dave

[Altera_Forum]

I goofed.. 

 The nios connects to the peripherals in qsys via a clock crossing bridge (master port). So, the nios runs at 100mhz, while the I/Os, leds, are connected on a 10mhz clock to the clock crossing bridge's slave port. When I connected the JTAG Bridge, I assumed it should connect to the same master port as the nios, i.e. to the clock crossing bridge. Nope. I moved the jtag to connect to each peripheral directly, and it worked! Kinda strange though, because the Nios has no problem accessing the peripherals only via the clock crossing bridge connection. C'est la vie!  Regarding the gui, I've never used Tcl/Tk before, but it's absolutely amazing that a windows application can be generated/modified in seconds with just a few lines of text (I know of course there's a framework lurking underneath, but still!) I'd love to play with making a continuous graph showing the value of a memory address as it changes over time!  Are there any resources you recommend for designing tk guis (there seems to be quite a few, VisualTcl, VisualCamel, SpecTcl, etc). And apparently there's also a python wrapper for Tcl/Tk called TKInter, for which there's even more gui builders for (Rapid-Tk, pygubu. ptkgb,etc)... although not sure how easy it is to convert TKinter (python) GUIs to run on TK (tc). Any suggestions?

[Altera_Forum]

--- Quote Start ---  I goofed..   --- Quote End ---   You're not the first :)    --- Quote Start ---   Regarding the gui, I've never used Tcl/Tk before, but it's absolutely amazing that a windows application can be generated/modified in seconds with just a few lines of text (I know of course there's a framework lurking underneath, but still!) I'd love to play with making a continuous graph showing the value of a memory address as it changes over time!  Are there any resources you recommend for designing tk guis (there seems to be quite a few, VisualTcl, VisualCamel, SpecTcl, etc). And apparently there's also a python wrapper for Tcl/Tk called TKInter, for which there's even more gui builders for (Rapid-Tk, pygubu. ptkgb,etc)... although not sure how easy it is to convert TKinter (python) GUIs to run on TK (tc). Any suggestions?  --- Quote End ---   I just use the Tcl book by Brent Welch. Looks like he has a few sample chapters ...  http://www.beedub.com/book/  Cheers, Dave

[Altera_Forum]

Hi Guys, I add my own custom hardware design to this system on the tutorial.(Altera JTAG-to-Avalon-MM Tutorial)(http://www.alteraforum.com/forum/showthread.php?t=34787) 

but my hardware which i successfully tested it last time by DE2 board has this input and outputs: https://www.alteraforum.com/forum/attachment.php?attachmentid=10027  last time i communicate with my accelerator through NIOS in this way:   # ifndef GCD_FW_H_ # define GCD_FW_H_ # include "system.h" # include "altera_avalon_pio_regs.h" # ifndef reg_gcd_status # define reg_gcd_status 0x0 //Register Offset = 0, control/status register # endif # ifndef reg_gcd_control # define reg_gcd_control 0x1 //Register Offset = 1, MSW input register # endif # ifndef reg_gcd_input1 # define reg_gcd_input1 0x2 //Register Offset = 2, MSW-1 input register # endif # ifndef reg_gcd_input2 # define reg_gcd_input2 0x3 //Register Offset = 3, MSW-2 input register # endif # ifndef reg_gcd_output # define reg_gcd_output 0x4 //Register Offset = 4, MSW-3 input register # endif enum { np_gcdcontrol_reset_mask = (1<<1), //reset the GCD coprocessor np_gcdcontrol_enable_mask = (1), // perform gcd computation np_gcdcontrol_clear_mask = 0, // clear the control signals np_gcdstatus_done_bit = (1), //GCD has finish computation }; /* prototypes */ unsigned long GCD_FW (unsigned long in1, unsigned long in2); # endif /*GCD_FW_H_*/ ///////////////////////////////////////////////////////////////////////// # include "system.h" # include "altera_avalon_pio_regs.h" # include "GCD_FW.h" unsigned long GCD_FW (unsigned long in1, unsigned long in2) { // Reset the 32-bit GCD Calculator unsigned long output = 0; // De-aseert the reset signal to ready computation IOWR(GCD_0_BASE, reg_gcd_control, np_gcdcontrol_reset_mask); // Keep looping if ready signal not yet asserted //IOWR(GCD_0_BASE, reg_gcd_control, np_gcdcontrol_clear_mask); //while (np_gcdstatus_done_bit != IORD(GCD_0_BASE,reg_gcd_status) ); // Send 1st random number to GCD IOWR(GCD_0_BASE, reg_gcd_input1, in1); // Send 2nd random number to GCD IOWR(GCD_0_BASE, reg_gcd_input2, in2); // Aseert the GCD enable signal to start calculation IOWR(GCD_0_BASE, reg_gcd_control, np_gcdcontrol_enable_mask); // Keep waiting if the computation not yet completed while (IORD(GCD_0_BASE,reg_gcd_status)==0 ); // Read the GCD output output = IORD(GCD_0_BASE,reg_gcd_output); // De-assert the enable signal for next set computation IOWR(GCD_0_BASE, reg_gcd_control, np_gcdcontrol_clear_mask); return output; }  But now I dont know how to talk to my hardware through "avalon_write" syntax since i dont access the HW I/O directly(input clk, reset; input chipselect; input [2:0] address; input write; input [31:0] writedata; output [31:0] readdata; ) regards

[Altera_Forum]

I am a relative newbie to FPGA and soft processor design. I am using a Cyclone III Development Kit and Quartus II v13.1. I was able to get through section 4 of the tutorial, but now I am stuck at trying to use System Console. I did have to modify the Qsys design and tcl script in ModelSim (as shown in the qsys_vip tutorial file) to get everything to run correctly. When I open System Console, there are red x boxes by the "connections" and "devices" items in the System explorer. When I try to run the master_write_32 command shown in Figure 13 of the tutorial pdf, I get the following error:  

 error: master_write_32: This transaction did not complete in 60 seconds. System Console is giving up.  Does anyone know what the issue is and how to fix this?  Erin