Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
11 years ago

PCIe Hard IP returning stale data for Cyclone IV

I have recently ported a PCIe endpoint design working on Arria V to Cyclone IV , ( Transciever Starter Kit ) .

I need to go back but don't believe I see the problem on Arria V which is a very similar FPGA configuration.

PCIe, IMEM, NIOS II , JTAG_UART. For Cyclone IV I enabled the SSRAM since there isn't enough IMEM to

fit even a small application in a "free standing" environment.

Anyhow, BAR1 references IMEM.

NIOS sets a status word in IMEM to 0x5555AAAA and the RC is polling the status word via BAR1 reads.

When the RC gets a the read completion indicating the status is 0x5555AAAA, it issues a write to the

status word of 0x00000000 then polls the status word to make sure the status was reset.

The problem I see on the PCIe link is that the polling of the status word by the RC after the write of 0x00000000

still returns the original data 0x5555AAAA. I am thinking the only way this can occur is if the write of 0x00000000

on the Avalon MM interconnect is posted and "somehow" delayed while the polling reads after the write somehow

make it through to the IMEM.

Has anyone seen anything like this ? Do I have some issue at the Avalon MM interconnect ? I could add

SignalTap to examine the BAR1 master writes and reads. I could take the NIOS II out of the design and

see if I have the same issue just with IMEM and PCIe Hard IP. I have heard that if NIOS II and PCIe are

sharing access to IMEM, then it may need to be dual ported to keep everything balanced and not have

a given master locked out.

Thanks , Bob.

PS: I can't think of anything else that would be accessing the IMEM .

14 Replies

Show More
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    11 years ago

    I'm half-remembering the diagrams for the (IIRC) avalon streaming interfaces to the PCIe block. I think you can use them instead of the Avalon master interface. I'm sure there are separate tx and rx streams (I might just be thinking of the fpga being a PCIe master).

    If I'm remembering correctly then it is likely that the avalon master is built on top of that interface.

    In which case nothing on the fpga will actually enforce that a write finishes before a read to the same address - even though the actual PCIe cycles have to be ordered.

    Hmmm... I've just realised you are talking about very long delays between the write and read cycles - not ones that are back to back on the pcie bus.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    11 years ago

    Hi Peter,

    I have been snowed under and think I may need to go to a second shift ... anyhow I am trying tpo go back to when I had a Windows system and was running the sample application you mentioned.... It was roughly 12 months ago .. but I am recalling some of it.

    Did you use the same Arria V starter board and did you use the altpcie_demo_64 too?

    No ...I used the Stratix V card ... I can try the Arria V GX Starter Kit card tomorrow.

    I have access to a Microsoft machine ...

    I recall the GUI came up and searched for the DeviceID / VendorID and complained iif it was not found.

    I can't recall any crashes, but know it leverages the Juno Device Driver ... can you say if that is installed OK ?

    Let me try to run it on the Arria V card and get back to you.

    Bob
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    11 years ago

    --- Quote Start ---

    Hi Bob,

    I'm trying to create a PCIe endpoint on my Arria V starter board and trying to use the altpcie_demo_64.exe from the altera ref design to enumerate and do read/write to the fpga endpoint, but I'm getting all kinds of problems from the altpcie_demo not working...to the blue screen followed by my pc crashing. Can you assist since you've gotten the endpt working on your Arria V?

    Here's some of the things I'm doing:

    1) following the Arria V Hard IP PCI express users guide (v.13.1 - Ch 3) I created the PCIe endpt and instantiated it making sure that I mapped to the correct fpga pins for the hard pcie IP.

    2) Before, configuring the fpga I run the altpcie_demo_64 and the gui reports 78 devices. I also checked the device manager and only see the Jungo driver installed.

    3) I program the fpga and then run the altpcie which reports 79 devices with one of the devices having the correct PCIe device and vendor ID - so this kinda tells me the PC has enumerated the fpga, right? However, the gui is greyed out so I can't do any read or write transactions to the fpga. Also, I noticed that the device manager has detected the Arria V dev kit - so that's good. However, sometimes I get the msg that the device doesn't have enough memory when I look at the devkit in the pc's device manager. Does this make any sense???? Sometimes it says the driver for the kit is working fine.

    Did you use the same Arria V starter board and did you use the altpcie_demo_64 too?

    I'd appreciate it a lot if you could share your wisdom in getting me past this hurdle of getting actual traffic going between the pc and the fpga.

    Thanks,

    Peter

    --- Quote End ---

    Peter, are you saying you developed the FPGA code yourself ...

    1) following the Arria V Hard IP PCI express users guide (v.13.1 - Ch 3) I created the PCIe endpt and instantiated it making sure that I mapped to the correct fpga pins for the hard pcie IP.

    And didn't use the sample HW configuration ...? I can't see a Arria V design when I look at the altpci demo designs. I see a Arria II design. Let me try to down load the Arria II design ... If you did design up an example from the user guide ... how would you know where to map the SG DMA registers to work in concert with the device driver that comes with the example .. or am I missing something ?

    I will try to download the .zip exaample for Arria II and see what it contains.

    Best Regards, Bob.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    11 years ago

    All this gets resolved if the RC and the EP card are reset each time I believe.

    I don't have root cause but am monitoring it.

    It is possibly in emulation to reset the RC and maybe not all the EP state. I think the PCIe slot reset propagates to the Avalon MM fabric and internal IP but need to check.

    So I believe this is related to resetting the RC without a corresponding full reset of the FPGA EP.