Avalon MM "sniffer" connections in QSYS

Hey Bob,

One more piece of advice that you can take-or-leave, I've never used a testbench created by Altera's tools. For my Qsys designs, I use the Generate pull-down to create a simulation/ folder, and use msim_setup.tcl to figure out what libraries need to be built, but then I take it from there. Its likely that had you taken the same approach, all the BFM errors you were seeing, would all disappear :)

Cheers,

Dave

--- Quote Start ---

I modified my "sniffer" to match the address and data widths and believe the simulation model is only generated if there are zero errors and zero warnings at the Qsys generate step. I may have been thinking warnings were Ok when they are not.

--- Quote End ---

Maybe it depends on the specific warnings you are dealing with? But in general, your statement is not true: Qsys will generate simulation and testbench files if warnings are present. It won't do anything if errors are present.

--- Quote Start ---

I will work with what I have and need to get the "sniffer" slave be able to monitor all traffic from a given master. The address is really a don't care since I am only intereated in write data and completion data at the "sniff" but I need to get Qsys to honor the BridgesToMaster = 1 attribute ... I really need that to happen and not have the interconnect fabric route certain data to certain slaves based on address map. If that happens, then the "sniffer" will never get any data to monitor. In that case I will need to make manual connections to the mm slave input across the the "sniffer" and somwhow push that back to the simulation environment.

--- Quote End ---

Yes, you definitely need the nios->slave connection to happen "across the sniffer". i.e. nios->sniffer->(all your slaves).

My systems normally look like nios->clock_crossing_bridge->(all my slaves) so inserting/removing my own "sniffer" is just two connections between the NIOS and the regular bridge.

If you don't do this, then you are correct that your component will not see any traffic.

i.e. it is not simply a bus that you are tacking wires onto like you might have hoped when you first started.

--- Quote Start ---

Hey Bob,

One more piece of advice that you can take-or-leave, I've never used a testbench created by Altera's tools. For my Qsys designs, I use the Generate pull-down to create a simulation/ folder, and use msim_setup.tcl to figure out what libraries need to be built, but then I take it from there. Its likely that had you taken the same approach, all the BFM errors you were seeing, would all disappear :)

Cheers,

Dave

--- Quote End ---

At the risk of muddying the waters with another anecdote that can also be taken or left, I've never created my own testbench or scripts that do the heavy lifting and rely largely upon the Qsys generated files. The top level TCL consists of "source msim_setup.tcl" then compiling my additional test program .sv files after executing the 'com' that Qsys generated. This is basically the flow described in the Altera tutorial in section VII of http://www.altera.com/literature/ug/ug_avalon_verification_ip.pdf

e.g. here is one of my top TCL scripts.

set TOP_LEVEL_NAME "test_top"
set SYSTEM_INSTANCE_NAME "tb"
set QSYS_SIMDIR "./../foo_core_tb/simulation"
# # new 'mycom' command executes the main compile and also adds our
# # local testbench files.
alias mycom {
   # # Execute the 'com' defined by the Qsys-generated msim_setup.tcl
    com
    echo "\ mycom"
    vlog -sv "../../../../../v/altera/vip/av_st_video_classes.sv"
    vlog -sv "./test_top.sv"     
    vlog -sv "./foo_test_program_vip.sv"
}    
#  Source Qsys-generated script and set up alias commands used below
source $QSYS_SIMDIR/mentor/msim_setup.tcl

Thanks Ted,

I will check the tutorial ... It seems that my msim_setup.tcl needed some changes after the Qsys generated it to get to some libraries as Dave indicates in his example ... I noticed that if I re-generate from Qsys , I looe those manual edits .

I want to leverage Qsys as much as possible to atlease get a simulation environment and some kind of sample test bench.

I completely misunderstood this ... I was hoping that my sniffer would be on the side of the existing logic and as a bridge , would just pass on to the "other side" all MM tranactions from a slave. When I ran that in the simple qsys_vip environemnt, I still get an error where the sniffer slave address map can't conflict with other slaves that are real and no transactions get to the sniffer.

What you say above make sense in I have PCIe_BAR1_MM _master -> IMEM and PCIe_TX_MM_slave -> IMEM .

The BAR1 master has writes that I want to monitor with respect to the TX which has read completions.

So .. I think there are 2 alternatives.

1) mm_slave-> mm_master bridge/ monitor for the BAR1 and mm_slave -> mm_master bridge/ monitor for the TX .

OR

2) Just edit the top level rtl and probe the IMEM data write and the NIOS data read ports with a non-Avalon MM component and

somehow get that pushed back into simulation. This approach seems more straightforward, but means there is a manual

operation. The sniffer would still be a Qsys component with a MM slave port to allow NIOS to read tracking state machines and set up

data only pattern matching values but there would be IMEM and NIOS data in ports with the necessary controls as qualifiers.

This seems simpler since the sniffer is more "passive" with respect to the system and no new bridges are involved.

Any ideas on the best approach ? Thanks.

Hey Ted,

--- Quote Start ---

At the risk of muddying the waters with another anecdote that can also be taken or left ...

--- Quote End ---

So how do you deal with the annoying fact that the msim_setup.tcl script creates the code in an absolute path ./libraries?

I have Modelsim-ASE and Modelsim-SE setup on my development machines (multiple versions of each to match the respective versions of Quartus). Each tool gets a tool-specific build directory, so that I can build/simulate my Qsys systems with Modelsim-ASE and Modelsim-SE. This is important when dealing with simulations that include transceivers and DDR interfaces, since ASE is soooo slooooowwwwww ....

It would be much nicer if Altera's msim_setup.tcl just created Tcl lists of source that you could then just pass to a build procedure that you could customize.

Cheers,

Dave

Up and running ... choose option 1) where I have an Avalon MM "bridge" that acts as a bus monitor. ( slave in -> master out ).

Thanks to Dave's sample testbench, I was able to run a 32 bit simulation, followed by a 64 bit simulation. After that

I added the 64 bit bus monitor component to the actual design and ran some simulation , but I need to do some more

work on the PCIe RC testbench to generate the necessary patterns. The current testbench stores addresses and I want to

store random data ... which should not be too much work.

The other monitor has to check PCIe read completions for reads initiated by NIOS II. I believe this will be a dual of the above there

PCIe BAR master writes were monitored.

In the lab, I see the "data" pattern match output to a LED on the scope while running the producer / consumer test.

Thanks Bob.

Once I have both monitors in place , one take pattern match inputs via conduits and track both activities via a state machine that can then report errors to NIOS II via a regular slave interface. The regular slave interface can also define "data" and "flag" patterns

per the producer / consumer test definition.

--- Quote Start ---

Up and running ...

--- Quote End ---

Awesome!

--- Quote Start ---

Thanks to Dave's sample testbench

--- Quote End ---

Another happy customer :)

--- Quote Start ---

The current testbench stores addresses and I want to

store random data ... which should not be too much work.

--- Quote End ---

The Altera pattern generator/checker cores can be used for generating patterns with random statistics. If you want more control, here's a VHDL tutorial plus source for LFSR/PRBS generators

http://www.ovro.caltech.edu/~dwh/correlator/pdf/lfsr_tutorial.pdf

http://www.ovro.caltech.edu/~dwh/correlator/pdf/lfsr_tutorial_src.zip

You could use that the generate randomized transaction types (read/write single/burst), and random transaction data (for the writes).

Cheers,

Dave

I seem to have gone backwards here ... I added the second "sniffer" which monitors the read completion data and in the Generate phase in QSYS get an error I have seen before but can't figure out how to resolve .

I then tried going back to what worked with one sniffer only monitoring data writes and got the same error ... that I didn't get before. I have tried several things and don't seem to be able to get back to where I was.

Seems to be complaining about an exported signal BRM ... any ideas?

Thanks Bob.

Error: get_instance_interface_property top_inst_data_dec_l_bfm CLASS_NAME: No interface named top_inst_data_dec_l_bfm..

Error: can't read "matching_intf()": no such element in array

Error: get_instance_interface_property top_inst_data_dec_l_bfm CLASS_NAME: No interface named top_inst_data_dec_l_bfm..

can't read "matching_intf()": no such element in array

Error: There were errors creating the testbench system.