Question about Monitor

[Altera_Forum]

Hello, 

 is it possible to synthesize the "monitors" on the altera fpgas'. There are Monitor IPs such as Avalon MM Monitor. Can I synthesize such "Monitors"?

[Altera_Forum]

Okay,I will do that. when I create a variation of the component using Megafunction. Can I make the new component to show up in the IP list?

[Altera_Forum]

--- Quote Start ---  when I create a variation of the component using Megafunction. Can I make the new component to show up in the IP list?  --- Quote End ---  Megafunctions and Qsys are different tools.  Not all Megafunctions have Avalon interfaces, so they cannot be used within Qsys without first creating a custom Avalon-MM or ST interface. If you used generics in your Qsys definition of the component interface, you could then pass those down to the Megafunction component.  Is that what you were asking?  Cheers, Dave

[Altera_Forum]

Yes I get what you are saying; so, using megafunctions is same as double clicking on the ip's and changing their parameters in the system contents tab [the place where you interconnect components] right? 

  I am trying to add new ports such as reset etc.. for Mega IPs such as PCI - compiler.   I guess, I have to use component editor if I need to create new IP's.   Thanks, Adi

[Altera_Forum]

--- Quote Start ---  Yes I get what you are saying; so, using megafunctions is same as double clicking on the ip's and changing their parameters in the system contents tab [the place where you interconnect components] right?    --- Quote End ---  Right. I think Altera has made several components that can be accessed either via the MegaWizard or via Qsys. I suspect that for the components you are interested in, you will have to write your own Qsys wrapper.    --- Quote Start ---    I am trying to add new ports such as reset etc.. for Mega IPs such as PCI - compiler.   I guess, I have to use component editor if I need to create new IP's.    --- Quote End ---  You will suffer less if you control the code; so just create the MegaWizard IP using the MegaWizard GUI, and then create your own Qsys components and their associated _hw.tcl. Once you get it working for your PCI component, it'll be easy to get it working for anything else.  Cheers, Dave

[Altera_Forum]

I think I just did that. This is what I did: I created a variation of PCI [actually no/very little variation] using Megafunction Wizard. I got a verilog file for that IP that contained variations [since I did not do any variations, I got a .v for that IP] and then I included that file in the component editor. Then the component editor generated the _hw.tcl file. Is this technique alright?  

 I dont know why Qsys is allowing this custom component[nothing but PCI] but not the actual PCI IP from Quartus 9.1 sp1.

[Altera_Forum]

--- Quote Start ---  This is what I did: I created a variation of PCI [actually no/very little variation] using Megafunction Wizard. I got a verilog file for that IP that contained variations [since I did not do any variations, I got a .v for that IP] and then I included that file in the component editor. Then the component editor generated the _hw.tcl file. Is this technique alright?     --- Quote End ---  If the IP has an Avalon interface, then yes, this would work fine.  The other way to do it, is to use the component editor to create the Avalon interfaces in an _hw.tcl file that does not include any Verilog/VHDL source. This then sets a flag in the Tcl telling it not to instantiate the IP inside the SOPC system.  The top-level SOPC system then has Avalon ports that you can connect your IP to. This would be useful if your Megawizard generated component had conduit ports or port widths that change based on generics, since you could edit the part with the MegaWizard tool, and not have to change anything in SOPC builder.  Cheers, Dave

[Altera_Forum]

can please you explain more about conduits? I read the manual did not help much! 

 Thanks, Adi

[Altera_Forum]

--- Quote Start ---  can please you explain more about conduits?  --- Quote End ---  Conduits are the signals from your Avalon component that are not related to the Avalon bus.  For example, a PCI core for use with the Avalon bus would technically be called a PCI-to-Avalon bridge, since it maps between the two protocols. In its simplest form, the bridge would be a PCI target. A PCI target cannot become a master of the PCI bus. The PCI-to-Avalon bridge would have a PCI target interface, and an Avalon-MM master interface. The signals for the Avalon-MM master interface would connect to the SOPC system. The signals for the PCI target interface would be marked as conduit signals in the SOPC _hw.tcl file. When you generate the SOPC system, those conduit signals will be present as signals on the top-level component. You then connect those to the PCI signals on the FPGA pins.  Is that clearer?  Cheers, Dave

[Altera_Forum]

Some clarifications before I get to conduits: 

 When I create system that can be synthesized on an FPGA the components of my system is glued by the Avalon interfaces right?  This interface is also called as System Interconnect Fabric right and is made up of Avalon Bus, right?  These conduits kick in only when the signals are going out of FPGA or if the signals are entering the FPGA right?  Now coming to what you said, If I have a PCI bus then, a conduit shows up between the PCI bus external to the FPGA and Avalon interface within the FPGA right?  When conduits show up in Qsys what should I do with them? leave them alone? since they are connected to outside of FPGA.  Also, what is the role of conduit BFMs. I am not able to imagine or get a clear mental picture of things going on with conduits!. Try simplifying it as much as possible and please explain once again. Appreciate your effort and time :-)   Thanks, Adi  Thanks, Adi

[Altera_Forum]

--- Quote Start ---  Some clarifications before I get to conduits:  When I create system that can be synthesized on an FPGA the components of my system is glued by the Avalon interfaces right?   --- Quote End ---  In SOPC Builder or Qsys, when you click connections between components, you are making Avalon connections; either MM or ST.    --- Quote Start ---   This interface is also called as System Interconnect Fabric right and is made up of Avalon Bus, right?   --- Quote End ---  Yeah, pretty much.     --- Quote Start ---   These conduits kick in only when the signals are going out of FPGA or if the signals are entering the FPGA right?   --- Quote End ---  Entering or leaving the SOPC system. You could connect them to external signals, or you could loop them back into the SOPC system, eg., control signals from a PIO component might loop back into the system via a different conduit to enable/disable another component.    --- Quote Start ---   Now coming to what you said, If I have a PCI bus then, a conduit shows up between the PCI bus external to the FPGA and Avalon interface within the FPGA right?   --- Quote End ---  Yes. All the PCI signals would be marked as conduit signals.    --- Quote Start ---    When conduits show up in Qsys what should I do with them? leave them alone? since they are connected to outside of FPGA.   --- Quote End ---  I would guess you leave them unconnected. I have not used Qsys much yet. I'm not sure why the conduits show up in the GUI. Perhaps someone else can comment.  Cheers, Dave

[Altera_Forum]

Thanks a lot. Those unconnected conduits were irritating! 

 I just figured out that the top level file ".v" that is used to program the FPGA is different when the synthesis option is turned on after the BFM's are connected [earlier, I was first doing the simulation and then i was only selecting the synthesis option. The top level file was different.  BFM's are supposed to used only for testing of individual components right? why are they synthesizable?

[Altera_Forum]

--- Quote Start ---   BFM's are supposed to used only for testing of individual components right? why are they synthesizable?  --- Quote End ---  They're not. Look at the source code, synthesis gets turned off (the BFM code gets skipped).   For a BFM Avalon-MM master named bfm_master, during synthesis you will get warnings that bfm_master nets are unconnected. Altera should have used additional synthesis directives to connect the unused interface control signals to ground, eg., by using HDL comments that get interpreted during synthesis.  However, you can ignore the warnings.  Cheers, Dave

[Altera_Forum]

Good Morning Dave, 

 If PCI-compiler is not availabe in Qsys, why does it show up in the Quartus 11-Mega Function Wizard?. Does it mean it can be added as a custom component in the Qsys?   Have a great day, Adi

[Altera_Forum]

--- Quote Start ---   If PCI-compiler is not availabe in Qsys, why does it show up in the Quartus 11-Mega Function Wizard?. Does it mean it can be added as a custom component in the Qsys?    --- Quote End ---  Qsys and MegaFunctions are separate tools/components. The existence of a MegaWizard component does not mean you can use it with Qsys. The existence of a MegaWizard component with an Avalon interface does not mean it is setup for use with Qsys either, for example, the ALTGX_RECONFIG component has an Avalon interface for its EyeQ port, however, there is no _hw.tcl component, so you have to 'figure it out for yourself'.  If you're having trouble using PCI Compiler, just ignore Qsys for now. Get a simple PCI to memory example working, and then once you are sure you understand how to configure the PCI core correctly, create your own _hw.tcl file for Qsys.  Cheers, Dave

[Altera_Forum]

get a simple pci to memory example working 

 Using PCI and PCIe I have written data to the memory in SOPC. and I have implemented the same system in Qsys using PCIe [I basically modified the mstr_tranx.v file generated the SOPC/Qsys system to read and write data to the RAM] . Is this understand sufficent to before I get on to modify the core components [_hw.tcl]?   and then once you are sure you understand how to configure the pci core correctly, create your own _hw.tcl file for qsys.   Where can I find the _hw.tcl file for PCI IP, I could not find it.  I actually haven't tried creating a new component, and haven't modified _hw.tcl filie. Will work on it and will get back if I have questions. Any suggestions before I try to create new components?   Thanks a lot, your quick replies are very much appreciated Aditya

[Altera_Forum]

--- Quote Start ---   Using PCI and PCIe I have written data to the memory in SOPC. and I have implemented the same system in Qsys using PCIe ... Is this understand sufficient to before I get on to modify the core components [_hw.tcl]?    --- Quote End ---  Its sufficient to show you know how PCIe/PCI works.    --- Quote Start ---   Where can I find the _hw.tcl file for PCI IP, I could not find it.   --- Quote End ---  There might not be one. Does the PCI IP have an Avalon interface?     --- Quote Start ---   I actually haven't tried creating a new component, and haven't modified _hw.tcl filie. Will work on it and will get back if I have questions. Any suggestions before I try to create new components?    --- Quote End ---  If the PCI IP core does not have an Avalon interface, then you will have to implement one, eg., start with a PCI target design, and add an Avalon-MM master interface internal to the FPGA. Then use the Qsys component editor to create the _hw.tcl file for you. You will need to use the GUI to correctly assign the Avalon-MM signals to read, write, byteenable, etc., and you will need to mark the PCI signals as conduit signals.   Once you have a _hw.tcl design, you can create a Qsys system with the PCI-to-Avalon-MM bridge and a memory component. Then generate PCI transactions to test your component. I assume the PCI IP core comes with a PCI BFM ...  Cheers, Dave

[Altera_Forum]

Hello Dave, 

 Yes PCI has avalon interfaces[ has two Avalon slave ports and one Avalon master port and bunch of conduits], when I wrote to the RAM I connected the PCIe Avalon Master to the slave of RAM and did not any Avalon MM master between these two components.   _hw.tcl file gets generated only for individual componets that we create right?, or does it get generated for the sopc systens aswell?   No there is no specific BFM alled PCI BFM, but there are Avalon Master BFM and Avalon Slave BFM. The slave of PCI can be driven by Master BFMs and the Master of PCI can drive slave BFMs and conduit BFM can be connected for the condiuts.    Then using API calls a test program[.sv] can be written to test PCIe.   Thanks Aditya

[Altera_Forum]

--- Quote Start ---   Yes PCI has avalon interfaces [has two Avalon slave ports and one Avalon master port and bunch of conduits]   --- Quote End ---  Ok. Then regardless of whether Altera supplies an _hw.tcl file for this component, you can create one.    --- Quote Start ---   when I wrote to the RAM I connected the PCIe Avalon Master to the slave of RAM and did not any Avalon MM master between these two components.   No there is no specific BFM alled PCI BFM, but there are Avalon Master BFM and Avalon Slave BFM. The slave of PCI can be driven by Master BFMs and the Master of PCI can drive slave BFMs and conduit BFM can be connected for the condiuts.    Then using API calls a test program[.sv] can be written to test PCIe.    --- Quote End ---  This makes no sense.  If you want to test a PCI/PCIe core you have to use a PCI BFM so that the transaction goes through the PCI/PCIe core. If you use an Avalon-MM BFM, then all you are doing is generating an Avalon-MM transaction between the BFM internal to the FPGA design and the RAM (or whatever Avalon-MM slave you are using as a test slave) internal to the FPGA design.  If you do not have a PCI/PCIe BFM, then you can easily create one using two Avalon designs;  1) The PCIe BFM design = an Avalon-MM BFM master and the PCIe core.  When you access the PCIe core, the PCIe core is a slave, and it generates PCIe master transactions on the PCIe bus, i.e., you have created a PCIe master BFM.  2) The PCIe RAM design = the PCIe core interfaced to a RAM block.  Your testbench would contain both designs. Your testcase generator would talk to the Avalon-MM BFM, and that would in turn generate PCIe transactions that, in turn, communicate to the second design. Once you get that working, you can add Avalon-MM monitors to the second design to check the Avalon-MM transactions.  Cheers, Dave

[Altera_Forum]

Oh!, ok. 

 This is where I got stuck!.   as my first exercise:  I connected the Avalon Master BFM to the slave of RAM [Then I used API to write to the RAM].This was a useless exercise.  as my second exercise:  I connected bar1_0 [Avalon master in the PCIe IP] to the slave [s1] of RAM and wrote data to the ram. This I did by using the write tasks given in the manual.   as my third exercise[got stuck]   I wanted to do exactly what you are saying but got stuck. Okay I will start implementing what you just described.   Step One: Adding IP's a) [1: number of components] Avalon MM Master BFM. b)[1] PCIe IP.[contains two slaves and one master] c) [1] on-chip RAM. [contains one slave]  Step two: Connecting IP's a) Connect [m0] of the Avalon Master BFM to the the Avalon slave of PCIe [there are two slaves, CRA (Control register Access) and Tx_interface], I will connect to the CRA  -------------------------At this point I will have a PCIe BFm right?-------------------------   b) Connect the Avalon master of PCIe [bar0] to the slave [s1] of RAM.  ------------------At this point is my design complete ?-------------------------------------  Questions:  a. Should I export any pins ?   Thanks,  Aditya

[Altera_Forum]

--- Quote Start ---   as my second exercise:  I connected bar1_0 [Avalon master in the PCIe IP] to the slave [s1] of RAM and wrote data to the ram. This I did by using the write tasks given in the manual.    --- Quote End ---  What are the 'write tasks' given in the manual? The PCI core manual? You said you did not have a PCI BFM ... this sure sounds like a BFM procedure to me ...    --- Quote Start ---   as my third exercise[got stuck]  ... Step One: Adding IP's a) [1: number of components] Avalon MM Master BFM. b)[1] PCIe IP.[contains two slaves and one master] c) [1] on-chip RAM. [contains one slave]  Step two: Connecting IP's a) Connect [m0] of the Avalon Master BFM to the the Avalon slave of PCIe [there are two slaves, CRA (Control register Access) and Tx_interface], I will connect to the CRA  -------------------------At this point I will have a PCIe BFm right?-------------------------   --- Quote End ---  Wrong. The PCIe BFM only needs two things; the Avalon-MM BFM connected to whatever interface on the PCIe core that can be used to generate bus master transactions. Its possible you might need to connect to one of the other Avalon interfaces on the core to enable some registers. That is for you to figure out.    --- Quote Start ---   b) Connect the Avalon master of PCIe [bar0] to the slave [s1] of RAM.  ------------------At this point is my design complete    --- Quote End ---  BAR0 is a decode region in PCI configuration space. If access to that configuration space generates activity on an Avalon-MM Master inside the FPGA, then that is where you would connect the RAM.     --- Quote Start ---   Questions: a. Should I export any pins ?   --- Quote End ---  How else would you connect the two separate designs? You need to export the PCI/PCIe interfaces so you can connect the two designs together!  Re-read what I told you; there are two designs, one design is your wrapper to convert an Avalon-MM BFM into a PCIe BFM, the second is the real design, the one that you would actually synthesize in hardware, its got the PCIe core, a RAM, and whatever else you want to test.  Cheers, Dave

[Altera_Forum]

Thanks Dave!.  

 Will I have to write some test programs or modify any generated codes to simulate my design [writing data to the RAM].  Is this an hierarchy system design example? [first you create a PCIe BFM, and then save that system and then connect that system to the RAM (second system)]  I am curious, how long have you been working with Quartus you have a good working knowledge about it. [I started 3 weeks ago]  Thanks, I am eager to implement your system, Adi