Question about Monitor

--- Quote Start ---

Is it okay to leave the pcie_core_clock and pcie_core_reset floating ?

--- Quote End ---

No! How would you expect the core to work if it does not have a clock and reset?

Cheers,

Dave

Good Morning Dave,

I am talking about the outputs. The pcie_core_clock and pcie_core_reset are the outputs form the PCIe IP core.

Thanks,

Aditya

--- Quote Start ---

I am talking about the outputs. The pcie_core_clock and pcie_core_reset are the outputs form the PCIe IP core.

--- Quote End ---

Are they outputs from the 'root complex' (your BFM design) or from the 'end-point device' (your FPGA design).

The reference clock from the root complex might be required by the end-point device if the two are to be synchronous ... or that same connection could be via a common clock in your testbench. I would look at Altera's examples to see what they do.

This webcast implies that Altera's examples have a PCIe BFM

http://www.altera.com/education/webcasts/all/source-files/wc-2011-pcie-technology-design-fpga/player.html

Earlier you implied that Altera did not.

Setting up the testbench I have described is a good exercise in learning the tools. Once you've got it working, you should go back and check out the newest Altera PCIe examples ... perhaps they have improved.

Cheers,

Dave

Hello Dave,

They are the outputs of the 'Root Port'. The 'End Point' also has the clock and the reset output. I have added two PCIe IPs in my qsys system [one for the BFM and other for the DUT] Also, when I connect the corresponding conduits[between the BFMs and the DUT] together I get errors [error increases as I connect the conduits together]

Thanks,

Aditya

Hello Dave,

What exactly does a PCIe IP inside a FPGA do? PCIe is a bus and let us assume that one of the devices connected to the bus is FPGA.

The signals from the PCIe bus enter the PCIe IP inside FPGA and then the signals enter the avalon fabric and then the RAM right?

Thanks,

Aditya

--- Quote Start ---

What exactly does a PCIe IP inside a FPGA do?

--- Quote End ---

If you do not understand PCIe at this level, then you need to listen to the Altera webinar's before attempting to simulate a system containing them.

PCIe is a specification that involves an electrical interface (the high-speed SERDES lanes), and a configuration/programming interface (borrowed from the PCI specification).

The FPGA IP core implements the physical interface using its SERDES channels, and Altera has implemented the configuration interface. Your designs can add custom functions to the BAR regions. The root complex version of the IP core needs to 'setup' the PCIe bus. The BIOS or Bootloader running on the device with the root complex would go out and 'enumerate' the PCIe bus, i.e., find all the devices and give them base addresses in the memory map of the root complex. The FPGA IP configured as end-points respond to the root complex with details about what they require in terms of resources on the PCIe bus.

If you do not understand the details of this, then you will not be able to get your simulation working, since your testbench code has to perform the functions of the BIOS/Bootloader to configure the PCIe bus before you can issue transactions.

--- Quote Start ---

The signals from the PCIe bus enter the PCIe IP inside FPGA and then the signals enter the avalon fabric and then the RAM right?

--- Quote End ---

According to the webinar link I posted you, the PCIe IP can implement an Avalon-ST interface where you see transaction packets, and you have to write code for it, or it can implement a simple Avalon-MM master. In your case, it sounds like you are using the IP configured as an Avalon-MM master, which in turn connects to the RAM.

What is happening at the system level is you issue a high-level command from your fake host system, eg. a read, which in C code could be the dereferencing of a pointer, that read targets the PCIe root complex, which converts it into a PCIe packet destined for your end-point. The end-point captures the PCIe packet, converts it back into a read command, issues that read as an Avalon-MM master, and captures the read data. The PCIe core in the end-point then converts the read data into a PCIe packet, sends it back to the root-complex, the root-complex converts it back to a data value to return as read data. Its all very complicated :) Its even trickier if you look at a Qsys system, given that the transactions between masters and slaves are also converted into packets, but this time Qsys packets.

Cheers,

Dave

Thanks a lot Dave. I think I know what the IP's are doing [they do the signal translation to PCIe standard between the end point and the root port]. I too want to understand things in depth, its more fun.

In your design you have two PCIe IPs. How do you connect those IP's, I connected the conduits together. I get errors.

Thanks,

Aditya

--- Quote Start ---

I kind of understand what you are talking about, but I haven't understood things as deeply as you have. I want to understand things in depth, its more fun.

--- Quote End ---

My comments should be taken as encouragement to learn more. The Altera webinars are pretty good, so go and look at their online training and listen to a few of them.

--- Quote Start ---

In your design you have two PCIe IPs. How do you connect those IP's, I connected the conduits together. I get errors.

--- Quote End ---

The PCIe IPs should be connected exactly as you would on a PCB.

The SERDES links would connect as; root_tx => endpoint_rx, and root_rx <= endpoint_tx.

What other signals are there?

Cheers,

Dave

Hello Dave,

Oh yes, I am taking your comments in a positive way:-P. I will look at the webinars.

I will email you an image of the PCIe IP. When I click on edit how do I configure the IP to be root port or end point port. [in qsys]

thanks,

Aditya

--- Quote Start ---

When I click on edit how do I configure the IP to be root port or end point port. [in qsys]

--- Quote End ---

Sorry, I have not used this IP. The IP users guide and examples should tell you how to do it. The PCIe webinar indicated the component could be configured for both root complex and end point, so the feature exists.

Perhaps try this webinar:

http://www.altera.com/education/training/courses/opci1010

Here's the IP page:

http://www.altera.com/products/ip/iup/pci-express/m-alt-pcie8.html

Did you happen to read this:

--- Quote Start ---

The PCI Express Compiler includes an endpoint testbench that incorporates a simple root-port bus functional model (BFM) and multiple endpoint example designs. You can use these example designs, available in clear-text source-code (VHDL) and Verilog (HDL), as references to kick-start your design, while the simple root-port BFM is geared to provide an "out of the box" PCI Express experience.

--- Quote End ---

The PCIe compiler includes a PCIe root complex BFM ... so technically you could have used that in your design.

The PCIe hard-IP page:

http://www.altera.com/technology/high_speed/protocols/pcie-hard-ip/pro-hard-ip.html

has these comments

--- Quote Start ---

Dual mode to support both endpoint (legacy and native) and root port functionality

--- Quote End ---

You need to read the documentation.

http://www.altera.com/literature/ug/ug_pci_express.pdf

Chapter 15 has testbench examples for both root and endpoints.

Cheers,

Dave