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