Avalon MM "sniffer" connections in QSYS

[Altera_Forum]

I seem to be stuck in connecting a new QSYS component into my system that I have generated. 

The new component, lets call it bus_tracker, monitors the data output of an Avalon MM master  for things like transaction ordering , performance etc. from a given QSYS IP component.   The bus_tracker component essentially "sniffs" data out of the master but doesn't need any more than the  writedata and the write_n qualifier.   When I try to make the connections I get stuck with reset connections ... There is a regular  Avalon MM slave port into the bus_tracker to monitor internal registers, counters and state machines and I get  errors associated with resets and QSYS want's to assign address ranges even though there is no address associated with the data only connection.  Is there an approved way to make this connection ? A suggestion was to make the connection at the Verilog level , that will work but how does the simulation environment work in that case ?   Thanks, Bob.

[Altera_Forum]

I'm not sure whether this is an 'approved' way but I suggest you disguise your component as an 'MM Bridge' where you essential forward the MM signals from Slave to Master and vice versa. You then 'tee off' the signals you want to monitor.

[Altera_Forum]

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.

[Altera_Forum]

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

[Altera_Forum]

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.

[Altera_Forum]

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

[Altera_Forum]

Dave,  

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

[Altera_Forum]

For what it's worth, I did a similar thing back on SOPC Builder and ended up with the "bridge + control port" model as Josy, Dave suggested. I believe the only trick is knowing to set the "bridgesToMaster" attribute in the _hw.tcl

[Altera_Forum]

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.

[Altera_Forum]

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.

[Altera_Forum]

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.

[Altera_Forum]

Hey Bob, 

 For your "first" implementation of your sniffer, simply create a component with an Avalon-MM slave interface, an Avalon-MM master interface, and a conduit. Connect the slave interface directly to the master interface, and extend the address bits appropriately, eg., the addresses on a 32-bit interface need to have the two LSBs of the master address zeroed. Then via your conduit interface probe all the slave signals.  Once you see how "easy" that is, you may decide to register the slave-to-master path, and then add logic to monitor transaction ordering, and convert the conduit to an Avalon-MM slave interface set of registers that you can read the transaction monitoring results from.  If you're totally confused by how to create the slave/master Tcl scripts, let me know, and I'll put something together and post it.  Cheers, Dave

[Altera_Forum]

Hi Dave and Bob, 

 I got intrigued and did just that: a simple test.

[Altera_Forum]

Hi Bob and Josy, 

   --- Quote Start ---   I got intrigued and did just that: a simple test.  --- Quote End ---    Yep, this is perfect.  What I would then normally do, is to start deleting as many entries as I can from _hw.tcl until only the values that "make sense" remain. I do this by looking for the documentation on the entries, and in cases where I cannot find info, I just delete them, and see if Qsys complains. Unfortunately to get Qsys to re-read the _hw.tcl file requires shutting down and re-starting the Qsys GUI. Having a minimum _hw.tcl file does make life easier in the long run though ...  Cheers, Dave

[Altera_Forum]

--- Quote Start ---  Hi Bob and Josy,  Unfortunately to get Qsys to re-read the _hw.tcl file requires shutting down and re-starting the Qsys GUI.   --- Quote End ---    Dave,  press 'F5' (refresh)  Regards,  Josy

[Altera_Forum]

Hi Josy, 

  --- Quote Start ---   press 'F5' (refresh)   --- Quote End ---   Thanks for the hint, I'll try it next time I'm hacking _hw.tcl files :)  Cheers, Dave

[Altera_Forum]

Dave and Josy, 

 I attempted to commit NIOS user code to flash using the update portal method. After that the card , Arria V starter kit, would not detect the JTAG if the factory_load switch was in teh normal position... I believe I did something wrong with the addresses in the user_sw.flash file . I tried the restore fastory defaults procedure and am still dead in th water. I have 2 cards but need to get the card going again as I need to get the NIOS user code into FLASH. The other symptom is that with the factory_load switch in the normal position, trying some JTAG operation or debug tool , the green LED , D8, SC_TX out of the MAXII chip comes on an stays on. Normally, JTAG_RX stays on during programming.  Any ideas ? I also sent something out on the Kits Forum.

[Altera_Forum]

Thanks for the nexample Josy, 

 I have captured it and will have a go at implementing your example in Verilog. I worked VHDL for the past 10 + years and before that Verilog..... now I ma back to Verilog.... phew !!  It looks too easy , but I see you have a MM slave connecting across to a MM master and that exposes the MM slave signals I am interested in.  Somewhere back there or on another thread, there was mention of setting the "Bridge" attribute. I figure this tells the QSYS that somehow the bridge component takes all transactions ... I guess the memory map on the other side of the "bridge" can't conflict with the memory map on the primary side of the bridge . ?

[Altera_Forum]

It should be that easy! 

 In the MMM_hw.tcl file the line: set_interface_property slave bridgestomaster 1 does the trick. And if effectively maps the addresses just like Altera's pipelinedBridge does. I made a small Qsys project to see how it all went down :)   Why would you go back to Verilog? To simulate it all? I am currently transitioning to myhdl (http://www.myhdl.org/) - simulating with the power of Python, and get VHDL-code (or Verilog for that matter) to plug into Qsys

[Altera_Forum]

Ok replicated into Verilog ... but the I thought the "bridgesToMaster" set to "1" attribute would mean everything was forwarded on ... that appeared on the bridge slave port to the bridge master port. I need this inorder to monitor the all the master output ... but QSYS is trying to make the bridge I have not intersect addresses with the slave ports of intererst. 

 Do I need to do something else or is the QSYS allocating address map to the bridge ? When I have looked at the AVALON interconnect fabric , the fabric generates a chip select based on the addresws map of the slave ... so ... is this address allocation just a placeholder ? I guess running simulation will say if the address and data makes it to the bridge ?  It was ted who was mentioning bridgesToMaster back on page 1. That property seemed to get auto generated when the hw.tcl file was generated.    #  # connection point mms1 #  add_interface mms1 avalon end set_interface_property mms1 addressUnits WORDS set_interface_property mms1 associatedClock clock set_interface_property mms1 associatedReset reset set_interface_property mms1 bitsPerSymbol 8 set_interface_property mms1 bridgesToMaster 1 set_interface_property mms1 burstOnBurstBoundariesOnly false set_interface_property mms1 burstcountUnits WORDS set_interface_property mms1 explicitAddressSpan 0 set_interface_property mms1 holdTime 0 set_interface_property mms1 linewrapBursts false set_interface_property mms1 maximumPendingReadTransactions 0 set_interface_property mms1 readLatency 0 set_interface_property mms1 readWaitTime 1 set_interface_property mms1 setupTime 0 set_interface_property mms1 timingUnits Cycles set_interface_property mms1 writeWaitTime 0 set_interface_property mms1 ENABLED true set_interface_property mms1 EXPORT_OF "" set_interface_property mms1 PORT_NAME_MAP "" set_interface_property mms1 CMSIS_SVD_VARIABLES "" set_interface_property mms1 SVD_ADDRESS_GROUP ""

[Altera_Forum]

I can generate for Synthesis only... but when I try to generate simulation and the testbench I get this ... is there a trick or do I need to provide some BFM or monitor ? 

(the errors below are not very helpful ). The goal here is to have QSYS generate the synthesis and testbench so I can do the right thing and run some simulation first.   Error: monitor_1_0: monitor_1 does not support generation for Verilog Simulation. Generation is available for: Quartus Synthesis. Error: Generation stopped, 7 or more modules remaining Error: ip-generate failed with exit code 1: 2 Errors, 2 Warnings Error: monitor_1_0: monitor_1 does not support generation for Verilog Simulation. Generation is available for: Quartus Synthesis. Error: Generation stopped, 7 or more modules remaining Error: ip-generate failed with exit code 1: 2 Errors, 4 Warnings Error: There were errors creating the testbench system.