Nios® V/II Embedded Design Suite (EDS)
Support for Embedded Development Tools, Processors (SoCs and Nios® V/II processor), Embedded Development Suites (EDSs), Boot and Configuration, Operating Systems, C and C++

Tightly Coupled Memory

Altera_Forum
Honored Contributor II
1,942 Views

I am developing a custom Nios system and I have a number of questions 

 

In my system I have an EPCS controller and custom interfaces to an ASRAM, Dual Port Ram and Custom Logic. I have also instantiated an on chip memory (max 20 K). Up until now we have not used tightly coupled memory and have tried different methods to bypass the CACHE through software. However the system is not working properly. We have also tried different configurations for the auto-generated linker script in the system properties for our project in the IDE. My questions are as follows :- 

 

1. Is it true that the CACHE can be removed from within the SOPC by instantiating tightly coupled memory (it sounds that way from the NIOS documentation) ? It appears from the documentation that I can run parts of the code within tightly coupled memory and other parts in the other memory devices that I have instantiated. In such a case, are all accesses to the different memory devices CACHE free ? 

 

2. Where can I find more information on how to use Custom Linker Scripts? Examples ? I need a bit more information that what is provided in the NIOS II Software Developer’s Handbook. 

 

3. When I instantiated tightly coupled instruction memory I noticed that within the SOPC builder, the branch that extends from the tightly coupled instruction master only allows a connection to the tightly coupled on chip memory. Also within the IDE system library for my project, within the System Properties settings, for the program memory (.text) I was only able to choose the tightly coupled memory. My question is, if the Auto-Generated Linker Script was only able to run the code from the tightly coupled memory (which also seems to be apparent from the SOPC tightly coupled instruction master branch limitation outlined above) how can a custom linker script place part of the code in the tightly coupled memory and the rest in another memory device ?
0 Kudos
6 Replies
Altera_Forum
Honored Contributor II
648 Views

 

--- Quote Start ---  

originally posted by shmueld@Jul 5 2006, 08:29 AM 

i am developing a custom nios system and i have a number of questions 

 

in my system i have an epcs controller and custom interfaces to an asram, dual port ram and custom logic. i have also instantiated an on chip memory (max 20 k). up until now we have not used tightly coupled memory and have tried different methods to bypass the cache through software. however the system is not working properly. we have also tried different configurations for the auto-generated linker script in the system properties for our project in the ide. my questions are as follows :- 

 

1. is it true that the cache can be removed from within the sopc by instantiating tightly coupled memory (it sounds that way from the nios documentation) ? it appears  from the documentation that i can run parts of the code within tightly coupled memory and other parts in the other memory devices that i have instantiated. in such a case, are all accesses to the different memory devices cache free ? 

 

2. where can i find more information on how to use custom linker scripts? examples ? i  need a bit more information that what is provided in the nios ii software developer’s handbook. 

 

3. when i instantiated tightly coupled instruction memory i noticed that within the sopc builder, the branch that extends from the tightly coupled instruction master only allows a connection to the tightly coupled on chip memory. also within the ide system library for my project, within the system properties settings, for the program memory (.text) i was only able to choose the tightly coupled memory. my question is, if the auto-generated linker script was only able to run the code from the tightly coupled memory (which also seems to be apparent from the sopc tightly coupled instruction master branch limitation outlined above) how can a custom linker script place part of the code in the tightly coupled memory and the rest in another memory device ? 

<div align='right'><{post_snapback}> (index.php?act=findpost&pid=16669) 

--- quote end ---  

 

--- Quote End ---  

 

 

I&#39;ll answer the parts I can and leave the rest for someone else. 

 

For a /f core, you can remove the data cache but not the instruction cache. Do this by double-clicking on the CPU entry in SOPC builder. If you&#39;re talking about removing the cache at all that&#39;s probably what you want to do anyway. Alternatively you can set the high bit of all memory accesses you want to bypass the cache for (so | 0x80000000) and leave the data cache for everything else.  

 

So you don&#39;t remove the cache by instantiating tightly-coupled memory, the two are separate. Look at the full-featured example to see how to hook up a TCM that you can run code from. It involves connecting the TCM to the regular data master and the tightly-coupled instruction master, since the TCIM can&#39;t write to memory. 

 

When I ran a program out of TCM I had two, an instruction and data memory. In the IDE I assigned .text to the instruction memory and everything else to the data memory.  

 

I don&#39;t know anything about custom linking scripts but I know I&#39;ve seen examples on the forum so a search should turn up some useful information.
0 Kudos
Altera_Forum
Honored Contributor II
648 Views

You can remove the instruction cache but you have to be careful. You&#39;ll loose the instruction master which forces you to have a system as follows: 

 

1) All instructions be placed in an onchip RAM that&#39;s 32 bits wide and has a read latency of 1 

 

2) OCI core is not present (OCI core hooks up the the instruction master however without a cache you don&#39;t have an instruction master). 

 

3) You don&#39;t have any other memory that needs an instruction master (you can have multiple tightly coupled instruction masters however they can only connect to onchip memories) 

 

So in short you need to have a system that&#39;s well tested before jumping to this method. By the way if you need prototype a system like this and just wanted the OCI core to download your code you can always use the GERMS monitor as an alternative (it&#39;s posted somewhere in this forum).
0 Kudos
Altera_Forum
Honored Contributor II
648 Views

Dear BadOmen, 

Thanks for your informative answer. Could you please clarify a few things :- 

 

2) OCI core is not present (OCI core hooks up the the instruction master however without a cache you don&#39;t have an instruction master). 

 

What is this OCI core ? What does it do ? 

 

3) You don&#39;t have any other memory that needs an instruction master (you can have multiple tightly coupled instruction masters however they can only connect to onchip memories) 

 

I realised this when I removed the cache and instantiated a single tightly couple instruction master, as I outlined in my observation in Qu: 3.  

When I re-instantiated a small instruction cache and the instruction master returned with its extended branch to the other memories within my SOPC system. I was also able to choose the different types of memories within the IDE system library for my project, within the System Properties settings, for the program memory (.text).  

 

My question now is :- 

If we use a custom linker script, where can we get more information about this file and how to use it ? Is it possible with such a file and system, to change which code is stored in a speific memory device on the fly. That is, as we run our code, when we want to run a specific part of the code, can we then copy it to the tightly coupled memory ?  

When we tried to store all of our code into the tightly coupled memory, the IDE compiler gave an error that we needed approx 9k more space in our tightly coupled memory (which is at it MAX of 22K)! Thus we thought that as we require a specific mode within our custom system, we might be able to copy that part of the code to the TCM - is this possible ? How ? 

 

Thanks again for all info
0 Kudos
Altera_Forum
Honored Contributor II
648 Views

OCI is the Nios II JTAG debug module. 

 

Be careful when using small caches since the smaller they are the more likely you are to thrash them and hurt your performance instead of helping. As for your question about custom linker scripts typically I just use the generated one, modify that, and point the system library properties to use the modified one. For more info on the linker script I would do a search for it since you&#39;ll find a lot with a google search. 

 

As for your code changing on the fly..... otherwise known as self modifying code you can do it but you have to be really careful (I would strongly caution you against this). If possible you may want to split your algorithm into smaller chunks that can fit into the tightly coupled memory then use a boothold to populate the memory (i.e. smaller algorithms that are stand-alone programs). A boothold keeps the processor paused so that you can copy code into its memory space for it to boot when you take it out of hold (hence the name). There is an example of a boothold component in this forum so searching for "boot" or "boothold" should find it.
0 Kudos
Altera_Forum
Honored Contributor II
648 Views

Dear BadOmen, 

 

Be careful when using small caches since the smaller they are the more likely you are to thrash them and hurt your performance instead of helping.  

 

 

In our code we are trying to bypass the cache when accessing these other memories, so does the size of the cache still matter ?  

 

 

As for your question about custom linker scripts typically I just use the generated one, modify that, and point the system library properties to use the modified one. For more info on the linker script I would do a search for it since you&#39;ll find a lot with a google search. 

 

As for your code changing on the fly..... otherwise known as self modifying code you can do it but you have to be really careful (I would strongly caution you against this).  

 

Qu: 2. Where could I find more information about doing this ?  

 

If possible you may want to split your algorithm into smaller chunks that can fit into the tightly coupled memory then use a boothold to populate the memory (i.e. smaller algorithms that are stand-alone programs). A boothold keeps the processor paused so that you can copy code into its memory space for it to boot when you take it out of hold (hence the name). There is an example of a boothold component in this forum so searching for "boot" or "boothold" should find it. 

<div align='right'><{post_snapback}> (index.php?act=findpost&pid=16687)</div> 

 

--- Quote End ---  

 

 

Thanks again for all the info
0 Kudos
Altera_Forum
Honored Contributor II
648 Views

Hi, 

 

Have you obtained some useful information about custom linker scripts? 

If yes, could you share with us? 

 

Thanks in advance, 

David
0 Kudos
Reply