Forum Discussion

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

Constraint Qsys IP Addressable Memory Range

Hi everyone,

A few weeks ago I migrated from Xilinx to Altera/Intel ecosystem and I am facing some problems that I don't know how to fix because of the lack of experience with Quartus tool.

I am designing a Qsys system with a Nios II processor, some peripherals (I2C, SPI, etc...), and a DDR interface. The design is really simple, I can test each interface separately and they work properly, but I am struggling with the Address Map of the system as soon as I connect everything together.

The DDR interface a 4GB SODIMM DDR4 module, and as soon as I instantiate the IP in the system it takes the whole addressable space of the Nios II processor (32bits), leaving the other peripherals unreachable. My Idea was to restrict the Nios access to the DDR to only 2GB, so I will be able to access all the devices of my system to achieve more complex test of the application software. My question is:

  • is it possible to restrict the addressable memory of a peripheral in qsys?

I tried under the address map tab in Qsys, but I can only change the base address of the peripheral and not the addressable range/high address. I assume should be a way to configure the Avalon-MM interconnects and restrict the addressable range, but I found nothing.

Surely it is really easy, but I can not find that option. Any ideas?

Thanks for your time!

2 Replies

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

    There are several ways to do this, possibly requiring another IP core instance.

    One thing you'll find when using Qsys is you end up needing an awful lot of extra blocks which do nothing more than pass signals through in different formats. For example there is no simple way of splitting conduits in Qsys, you end up with an HDL file that takes the signals in and spits them out unchanged, but then a TCL wrapper that makes Qsys think the signals have been remapped into other conduits.

    Anyway, back to your case. The simplest way is to use the "Address Span Extender" core in Qsys. It's located in "Basic Function\Bridge and Adaptors\Memory Mapped". If you set the "number of sub-windows" to 1, and the "enable slave control port" to false, you should be able to then simply set the slave address width to 31 bits (2GB), and the expanded master address width to 32bit (4GB). You can also set the "sub-window" offset to point to whatever address in the DDR you want address 0 in the slave to point to.

    Alternatively, you could make your own core which has two Av-MM interfaces and one less address bit on the slave than the master.

    Finally, possibly the simplest option, is to simply change your DDR controller so that it thinks the memory is only 2GB not 4GB. One way to do this is to half the data width in the memory parameters - in your top level design, you would then simply not bother connecting half of the memory modules data lines, effectively pretending it is a 2GB DIMM, though this would reduce your overall throughput.

    Depending on the memory arrangement, you may instead want to change the "row address width" to be 1 bit less (again Qsys thinks the memory is 2GB), and in the top level tie the MSB address pin to 0. This keeps the full throughput by retaining the full data width.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    9 years ago

    Thanks for the answer!

    The "Address Span Extender" is exactly what I was looking for.

    At the beginning, I thought also about changing the DDR controller to address only 2GB data but in the near future some SGDMAs will be streaming data from the totality of the 4G DDR and the interface must be able to handle that.

    I am going to have a look at the control port of the "Address Span Extender", knowing that I can change the base address of the subwindow in software and access the whole 4GB data is a nice add-on to my test routine.

    Thanks again for the information!