--- Quote Start ---
Hi Dave, I have the "producer / consumer" test running with my thin Linux device driver ...
--- Quote End ---
Awesome!
--- Quote Start ---
You may have an idea on this ... and I assume it is a simple case of understanding how NIOS AVALON MM slave space is reached via
BAR addresses in the Linux device driver.
--- Quote End ---
If you look in the Qsys memory map (use the memory map tab), it will show you the addresses for each Avalon-MM master. The BAR registers are a PCIe slave, but an Avalon-MM master. If you have a BAR that maps to a 4K block of Avalon-MM registers, then the PCIe 64-byte address should map to an Avalon-MM master address, and then that will map to your slave (with address LSBs dropped depending on whether its an 8-bit, 16-bit, or 32-bit slave).
--- Quote Start ---
"The second issue I have relates to setting up the PCIe core Avalon MM -> PCIe address translation .. this is at a table with 2 entries of 4k bytes each.
I am trying to track it down . This Cra register space is accessed via BAR1 and contains the physical address of the system DMA memory address.
--- Quote End ---
Huh? The CRA registers are for your Avalon-MM masters to use, I don't think it was intended for you to loop back onto a BAR register for PCIe access.
--- Quote Start ---
For some reason , that BAR1 write is ending up at a different location in IMEM that is just below the Cra space . I have an idea it could be something
to do with the BAR address matching scheme and reference to NIOS address map. The IMEM is at 0x00010000 - 0x0001ffff and the CRA slave is at
0x00020000 - 0x00023fff ... the write to the translation tables at offest 0x00021000 in the CRA space seems to end up at 0x00011000 in the IMEM."
--- Quote End ---
Sorry, I'm not sure what the IMEM you are referring to is.
Modelsim simulation of the system would help resolve addressing issues like this.
Cheers,
Dave
Honored Contributor
