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...
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.
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.
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.
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.
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.
Someone was asking me about this the other day. The requirements for a TCM connection in SOPC Builder were:1) 32-bit data 2) had to be the Altera on-chip RAM component 3) master to slave connection had to be 1:1 4) fixed read latency which had to be 1 clock cycle In Qsys the restrictions where relaxed apparently and# 2 above is no longer needed (no idea if that was an oversight...) Anyway if you create a slave with properties 1, 3, and 4 above you should be able to hook it up to the master. Make sure that it's on the same clock domain as the tightly coupled master from the Nios II CPU since I'm not sure if this is being validated currently (bad things will happen if there was a clock crossing so don't do it).