Forum Discussion

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

Best way to implement a bank of memory mapped registers?

Hi,

I'm relatively new to FPGA design but have been at it for a couple years now in my spare time, and I've spent a long time trying to figure out how to even ask this question...

I've done a lot of searching and it could be that I've got all the wrong terminology.

A "clean" solution is not obvious to me.

I'm pretty comfortable with the basics of the avalon bus now having created some modules that work on it, working with hard memory controllers and various other widgets, debugging via jtag and the system console.

I'm working on a cyclone V design where I'm at the point where I want to build in some reconfigurable options and settings. I would be great if I could drop a bank of registers on the avalon bus so that I could get to them by jtag (and probably eventually by a not-yet-implemented SPI slave interface).

I think of the example of various off the shelf SPI/I2C configurable chips, I want similar functionality. I don't plan on having tons of settings changing, but I would like a clean way to implement registers that I can then connect those signals to the various blocks in the FPGA design to change modes, constants, settings. If I want to add a dozen more registers for coefficients for something, it would be nice if it was a straightforward code change (i.e. something that scales well).

The ways I could think of doing it as a qsys module:

-if it is only a few bits the PIO core might be OK. Beyond 32 bits I don't see how to do it without adding more than one. The individual signals could be exported as conduits for the rest of the design, and this would all exist at one 32 bit address on the avalon bus.

-roll my own avalon-MM slave with an address range and simply create an appropriately sized array of registers. I would then interconnect these signals to the rest of the system using conduits where appropriate. This is pretty much the same as the PIO core but without the limitation of being at a single address. Actually writing to the registers would be done by jtag or anything else translated to the avalon-mm bus, that part I'm not so worried about.

Hopefully someone can understand the question. I think the answer must be so simple that most people already know how to do this and that maybe there are some common approaches that work well.

thanks for your time!

Lance

2 Replies

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

    What's the problem? You already presented the two common solutions. As you pointed out, you must choose between them depending on the number of settings you need.

    Anyway it's not clear what settings you mean to change. You refer to "modes, constants, settings" in the fpga design.

    First of all, constants, as such, should not change.

    Regarding other settings, it must be clear to you that this way you can only change the 'status' of fpga signals, not the actual functions, which are defined by HDL design and would require rebuilding and reconfigurating the fpga.

    For example, if you have a HDL block (VHDL entity or Verilog module), your 'software' setting can only act on block inputs, not on HDL parameters which affect the synthesis of the described logic.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    10 years ago

    Cris,

    Thanks for the response. I simply asked if there was a better/more common/accepted way of accomplishing this, not that I couldn't blaze forward with one of the options I mentioned.

    constant was a bad choice; I guess i meant more of a coefficient (offset, multiplier, filter tap weight, memory block size, number of samples).

    By modes I meant things like turning on and off a block that derandomizes data from an ADC for experimentation (an LTC ADC I'm working with has this feature as well as an alternate-bit-polarity function for similar reasons. Recompiling is annoying when you want to repeat experiments. In the end indeed only one option would probably be compiled in.

    So yes, I know the on-the-fly behavior changes can only happen with muxing different signal paths and modifying basic operations, I have a realistic expectation there.

    Thanks again, I guess there just isn't anything else to it, no "template" of sorts that somehow makes managing it more elegant.

    Lance