Resource Collisions when installing PCIe DD

Hi Bob,

--- Quote Start ---

on re-reading your suggestion to load the NIOS code via the PCIe link ... I now understand you are saying to load up the SRAM data and the SRAM controller will be in reset ... upon releasing that reset the NIOS core will start ... does that mean that the NIOS core will be stalled with a fetch to the reset vector memory location, until the SRAM controller is active and can honor the first Avalon MM bus read request ?

--- Quote End ---

If you assert the NIOS II processor reset pin, it will sit there doing absolutely nothing. If the NIOS II processor is supposed to boot from SRAM or an external SDRAM, then it will not boot until reset is released.

I use a "similar" scheme for booting a DSP. The DSP external bus routes through an FPGA. The "memory map" of that FPGA normally locates flash at the DSP reset location, however, by changing an FPGA register, I can remap SDRAM over the flash locations. This allows me to copy DSP boot code into SDRAM, reset the DSP, flip the DSP address decoding bit, and then release the DSP reset, and viola, it boots from SDRAM (none the wiser). This allows the flash to contain a basic image, whereas my run-time code gets delivered from a version controlled file-system. I never have to wonder which version of code is running on the DSP, as I know for certain it is the latest code.

Cheers,

Dave

Hi Dave, I have the "producer / consumer" test running with my thin Linux device driver ...

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.

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

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

Thanks, Bob

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

If the nios is in 'soft reset' it actually fetches the first instruction every few clocks.

This doesn't matter - but can be confusing in traces.

It ought to be valid to write the outbound address translation memory from the PCIe master (I'm pretty sure we have a system that does it).

I am wanting to get the ModelSim running for the PCIe endpoint design I have.

I have the ModelSim GUI up after going through the Arria PCIe user guide steps ...but am missing the following.

1) I would like to run the sample testbench against the endpoint to go through training and some basic operations but can't find the sample testbench.

2) If I find the sample testbench ... how to start the simulation.

Best Regards. BCD.

--- Quote Start ---

Awesome!

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

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.

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

--- Quote End ---

Dave the example device I have sets the Cra translation table entries up via a BAR register at the end of the DD probe code .. just before the endpoint is enabled.

The NIOS system I have only has IMEM ... I have IMEM at 0x00010000 - 0x0001ffff and CRA at 0x00020000 - 0x00023fff somehow when I trie to set the CRA tables at 0x00021000 the table entry gets written to IMEM at 0x00011000 .. I think this may be due to the BAR1 offset I am giving which is the absolute offset

and not a relative offset . Thanks Bob.

--- Quote Start ---

Thanks! :)

I haven't tried a class code of 0, so hadn't had that one trip me yet :)

In what way?

The tests I did in this thread (see the PDF)

http://www.alteraforum.com/forum/showthread.php?t=35678

have pre-fetchable regions.

Why IOCTL codes? You can use the mailboxes and interrupts to create an inter-locked handshake. Here's an old PCI example ...

http://www.ovro.caltech.edu/~dwh/correlator/pdf/cobra_driver.pdf

Why do you need this? If you are DMAing data, then use an interrupt to indicate the end of the transfer.

Here's what I would do (assuming you have SDRAM on the board for the NIOS II processor);

1. Instantiate a NIOS II core that boots from SDRAM.

This core powers-on with its reset asserted. The reset register would be something the host can toggle, eg., an Avalon-MM register.

2. Use the host to copy the NIOS II images into SDRAM.

3. Use the host to release (deassert) the reset line.

The NIOS II processor would then boot. The host can wait for a message from the NIOS II in the mailbox.

Here I assume that you have a "mailbox" for the host-to-device and another for device-to-host transfers, and that these two mailboxes generate interrupts at their respective device.

Cheers,

Dave

--- Quote End ---

Hi Dave, been working on this for almost a year now on and off.

I am interested in your statement that the NIOS II core powers-on with reset asserted ... possibly that is the reason the NIOS II doesn't start up automatically when I commit both the FPGA configuration to FLASH and the NIOS II software to FLASH . I can't see any mention in the examples of having to explicitly release the NIOS II reset ( or to generate a reset "interrupt " to force execution at the reset vector ... Can you point me to anything there as I believe I am close to running the FPGA + NIOS II out of FLASH.

Anyhow ... I had an idea on the NIOS II software load via the host. Can you comment on this.

1. Since the Altera cards all have FLASH, start the NIOS II out of flash executing boot loader code .

2. Modify the boot loader expect the code to be found at SSRAM location x.

3. Modify the boot loader to poll a doorbell register set by the host via some register mapped to a BAR.

4. Have the host load the code at SSRAM loaction x .

5. Have host set the doorbell indicating to the boot loader to go and load code in SSRAM and begin execution of user code.

The alternative would be to have the FLASH accessed via a BAR register and when the user SW FLASH is to be updated, have the

host update the user FLASH code and then restart the NIOS II core ... that may be more straight forward.

Regards, Bob.

Dave

re-reading your post ... I think you indicate the NIOS II core is held in reset ... then released via the host to allow NIOS II to fetch the first instruction .

Let me look at that also which sounds simple ... I just have to have the host load the SSRAM the same way the Eclipse system woudl process the .elf file to get it

loaded into SSRAM.

Are there any tricks in converting from an environment controlled via Eclipse ( debug JTAG port ), to a system that is stand-alone, and starts without any Eclipse interaction ?

I would just like the JTAG UART to still communicate with the a NIOS terminal window or something similar.

Thanks, Bob.

--- Quote Start ---

Are there any tricks in converting from an environment controlled via Eclipse ( debug JTAG port ), to a system that is stand-alone, and starts without any Eclipse interaction?

I would just like the JTAG UART to still communicate with the a NIOS terminal window or something similar.

--- Quote End ---

There is a NIOS II host-side console (command-line) program; nios2-terminal.

Depending on your hardware setup, you may find it easier to move away from using JTAG for your UART (since it is inherently polled) to an FPGA-based UART connected to a UART-to-USB bridge (meaning that do you not have to have RS232 level translators). For example, FTDI has cables ...

http://www.digikey.com/product-detail/en/c232hm-ddhsl-0/768-1106-nd/2714139

http://www.digikey.com/product-detail/en/c232hd-ddhsp-0/768-1011-nd/2767783

Cheers,

Dave