Question about Monitor

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

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

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

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

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

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

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?

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

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

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