Avalon MM "sniffer" connections in QSYS

Will investigate ... so QSYS thinks it is a bridge but is really a component with some Avalon MM signals being monitored as well.

Thanks, Bob.

BTW: I asked the other FPGA vendor how to do that with the AXI bus and they said it would have to referred back to the tool developers.

A few more ideas;

1. Create an Avalon-MM master that is not instantiated in the Qsys system. What this does is create a _hw.tcl file that you can use in Qsys, which results in master ports appearing in the top-level design. I had to do this to instantiate an Avalon-MM master that had VHDL entity port types that were not supported by Qsys (VHDL records).

Given that the master port is then outside of Qsys, you can do whatever you like with it, eg., instantiate whatever master you originally had, along with your probe logic.

2. Have you considered just using SignalTap II to look at the transactions you want to see?

3. Verilog allows you to probe signals within a hierarchy, so that means you could determine the name within the Qsys system, and then probe it directly ... this works in Modelsim, but I'm not sure about synthesis.

4. Use Modelsim to do your performance analysis (since you have more flexibility to probe signals).

Cheers,

Dave

Thanks Dave.

1. sounds promising.

2. would work but I want the component to be "stand alone" and report ordering errors to the NIOS via regulat registers and NIOS will report errors back to the Linux ( RC ) host system.

3. possible

4. Will work but the intention is to test actual hardware to catch ordering issues in the RC bridges / fabric .

The easy solution is to edit the top.v and mahd connect the data and datawrite signals out of the masters to the corresponding sniffer ports in my component. I am trying this now but I wanted to start with QSYS ...since

it generates the testbench for Modelsim ... it complains about there being no BFM for my conponent ( another problem ) ... but so far, the only way I can get QSYS to pass generate is to have my component sniffer ports

unconnected and back in QUARTUS make the connectiosn my self ... sysnthesis works on that but will simulation know about the connections ?

Thanks, Bob.

--- Quote Start ---

... I want the component to be "stand alone" and report ordering errors to the NIOS via regulat registers and NIOS will report errors back to the Linux ( RC ) host system.

... the intention is to test actual hardware to catch ordering issues in the RC bridges / fabric .

--- Quote End ---

Then as Josy suggests, just create a bridge component. That bridge component would have three Avalon-MM interfaces;

1. Avalon-MM slave that you connect to the master you are sniffing

2. Avalon-MM master, the pass through connection from the master

3. Avalon-MM slave for performance monitoring registers access

You can then test your bridge component using the Altera Verification IP Suite (I've posted examples that use the BFM master and slave components, qsys_vip.zip);

http://www.alteraforum.com/forum/showthread.php?t=32952&page=3

Cheers,

Dave

Dave,

Many thanks , will look up the URL you have provided.

Best Regards, Bob.

Sounds like Josy's solution wins.

I had hoped to just specify my sniffer component with a "partial" set of Avalon MM inputs on the sniffer port ie data, data_write and be, but had no success on trying that .

I will need to research the "bridge + control port " component.

Two additional questions.

1) The local Altera support suggested going into the top.vhdl in Quartus and making the connections I need directly, however , this is awkward since the Quartus rtl is then out of synch with the Qsys. I really want to get Qsys generate to generate the synthesizable code, testbench etc. Would it be correct to say that modifying the Quartus code would break simulation or is there a method for getting the modified rtl design back into the simulation environment ?

2) Even if I don't connect the "sniffer" ports of my new component, in Qsys, when I try to run generate with the testbench and simulation sections selected as well as synthesized code, I get an error mentioning that no BFM or similar exists for the new component ... not sure what this error means .. see below ... any ideas ? Thanks, Bob.

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

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

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

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

Error: There were errors creating the testbench system.

Sounds like Josy's solution wins.

I had hoped to just specify my sniffer component with a "partial" set of Avalon MM inputs on the sniffer port ie data, data_write and be, but had no success on trying that .

I will need to research the "bridge + control port " component.

Two additional questions.

1) The local Altera support suggested going into the top.vhdl in Quartus and making the connections I need directly, however , this is awkward since the Quartus rtl is then out of synch with the Qsys. I really want to get Qsys generate to generate the synthesizable code, testbench etc. Would it be correct to say that modifying the Quartus code would break simulation or is there a method for getting the modified rtl design back into the simulation environment ?

2) Even if I don't connect the "sniffer" ports of my new component, in Qsys, when I try to run generate with the testbench and simulation sections selected as well as synthesized code, I get an error mentioning that no BFM or similar exists for the new component ... not sure what this error means .. see below ... any ideas ? Thanks, Bob.

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

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

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

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

Error: There were errors creating the testbench system.

Dave,

Thanks, I have started to work through your qsys_vip example ... I believe you are suggesting to use that environment to test the new "bridge component" that I am to incorporate my Avalon bus sniffer into ?

1. Avalon-MM slave that you connect to the master you are sniffing

2. Avalon-MM master, the pass through connection from the master

3. Avalon-MM slave for performance monitoring registers access

I have to get a better understanding of the bridge-> master component ... are we saying that as a bridge, I can connect the bridge slave to the Avalon master port to be monitored

and Qsys will just repeat all master traffic to the bridge and the pass through part just propogates say write data, datawrite and be's to my bus tracking logic. The regular Avalon

slave interface will access the internal registers that the bus tracking logic drives.

I will try tr research the bridge class of components . to see what I can come up with .. what is not obvious is how the read path would be handled for a bridge unless Qsys expects

the local slaves or the slaves behind the bridge will respond to reads but not both ... that would be handled by address mapping usually, and I don't have a read path back from my bus sniffer so no read requests would be decoded.