SOPC builder - connect a custom component to tightly coupled i/f?

Question

Hi, is there any way to get SOPC to accept a custom component instead of the "on-chip RAM" as the tightly coupled instruction memory interface?

I've tried everything I can think of but SOPC builder (9.1) seems to disconnect the Nios from the component during the system generation without giving any useful message. It then complains that there is nothing connected to the tightly couple instruction master port.

Background: I am trying to create a protected instruction RAM, where write access from the Nios can be disabled from outside the SOPC builder system in order to prevent accidental overwriting of the image. So all I need to do is qualify the RAM write enable with an external (exported) "allowWrite" signal.

I know I can just manually modify the RTL but would really really prefer a more elegant solution...

altera_forum · Answer

I don't believe the tightly coupled memory interfaces are documented (or usable by anything other than memory.

But do you need to change it?

You should be able to leave the instruction memory interface alone, and intercept the avalon bus accesses to the memories other port.

altera_forum · Answer

Thank you very much for your reply.

I need to connect the other port to the Nios data master in order to allow the debugger to work. However I want this path to be disabled in the field.

So I suppose I could try to insert some sort of arbiter in between the data master and the ITCM which can be disabled.

altera_forum · Answer

Insert a simple 'conduit' block with an avalon master and avalon slave interface between the nios data master and the actual code memory block.

I actually run a system that doesn't have data access to the code memory at all, this does require a non-standard linker script, and can't be done with the gcc4 compiled by altera (unless you code has no switch statement jump tables).

You probably want to move the .rodata (and strings) into tightly coupled data memory - especially if you have to real reason to enable the data cache.

altera_forum · Answer

Thanks. Up to now I have been running with RO and RW data sections located in DTCM, with alt_load() copying disabled.

However for resilience in-service I need to be able to guarantee that the Nios SW can be re-booted without re-programming the FPGA. So I'm going to use the ITCM like a boot device, copying the RO and RW data sections to DTCM in the alt_load() phase, and protecting it from corruption.

But (I think) I also need to connect the ITCM to the Nios data master in order to allow debugging via JTAG.

The idea then is to protect ITCM from inadvertent writes unless debugging is specifically enabled via an externally programmed register.

I'll try creating the conduit component.

altera_forum · Answer

Depending on the amount/type of debugging you need to do I think there is a JTAG -> avalon master block somewhere which might be enough for you.

I can imagine a system where you expose the nios soft reset bits, and have a piece of vhdl that copies code/data from a pre-initialised memory block into the nios code/data memory areas prior to removing the soft reset.

You might then be able to use the jtag->avalon master block to update that 'pre-initialised' memory area and force a reset for development build and load.

Forum Discussion

SOPC builder - connect a custom component to tightly coupled i/f?

8 Replies

Recent Discussions

Ashling IDE scripted project creation

NiosV and juart-terminal

Nios V license

NIOS does not start after SW download (timing issue?)

DK-DEV-AGI027-RA: JTAG chain broken after Nios V Hello, FPGA recovery fails