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

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!

--- 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

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!!

--- 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

--- 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?

--- 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

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?

--- 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

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