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++
12589 Discussions

non-cacheable instruction memory

Altera_Forum
Honored Contributor II
3,072 Views

Hi at all, I'm new in this forum. 

I create a Nios II system containing a Nios II/f core, with 2k data cache and 2k instruction cache, and 128k of on chip-memory. 

I want to run on this system an assembly code, but i need to use both cacheable and non-cacheable instruction. How can I define a non-cacheable sector of instruction memory?:confused: 

 

Thanks at all. 

 

Daniele.
0 Kudos
16 Replies
Altera_Forum
Honored Contributor II
757 Views

You can't, instructions read from an Avalon slave have to read into the instruction cache first. 

What you can do is use a tightly coupled memory block for the instructions. You'll probably need to make the memory blocks second port a slave to the avalon bus and give the cpu data access to it. 

If you want to use the jtag debugger, you'll still need the instruction master and a minimal instruction cache.
0 Kudos
Altera_Forum
Honored Contributor II
757 Views

Thank you for fast reply. I'm a master student and I have to realize a project on which I must to load a part of assembly program in cacheable instruction memory and the other on non-cacheable instruction memory. 

From your reply I understand that all instructions load into tightly coupled memory block are not loaded into instruction cache and the instructions into on-chip memory are loaded in cache, is correct?:confused: 

 

If it is correct, how can I load a part of the assembly program into on-chip memory and the other part on tightly coupled memory block?:confused: 

 

Thank you for your helpfullness.:) 

 

Daniele.
0 Kudos
Altera_Forum
Honored Contributor II
757 Views

That's correct, if you want some of your code to be cacheable and the rest be uncacheable using the instruction master for cacheable accesses (need a Nios 's' or 'f' core) and the tightly coupled instruction master for the uncacheable accesses is what you'll need to do. 

 

Determining where code winds up in memory is done by the linker. Both your main memory and on-chip tightly coupled memories should each show up in BSP editor along with their linker section names. There is a gcc attribute called "section" which you can use in your code to inform the linker what section your code should be placed in. If you take a look at the tightly coupled memory design example on altera.com you'll see an example of this for some C code. I would imagine there is a way to do this with assembly code as well.... not sure though since I typically write assembly at a function level which I could just use the C prototype to do this type of linking. 

 

There might be easier ways, if you explained more about what you are trying to do maybe we can make a better suggestion.
0 Kudos
Altera_Forum
Honored Contributor II
757 Views

Thank you, I must implement a test for instruction cache, for this reason I must jump from the cacheable section of the assembly program to the non cacheable one. My problem is to know the instruction useful to inform the linker using a assembly code. 

 

My first problem is error given during the NiosII Application and BSP from Template. 

 

In this application I include a .sopciifo file relative to a system like the one in attach. 

 

During the creation of the application I receive this error: 

Failed to execute: ./create-this-bsp --cpu-name cpu_0 --no-make 

SEVERE: nios2-bsp-create-settings failed. 

SEVERE: Tcl script "bsp-set-defaults.tcl " failed: Section ".rodata" has no memory region mapping. 

nios2-bsp: nios2-bsp-create-settings failed 

 

:confused::confused::confused: 

What does it means?????
0 Kudos
Altera_Forum
Honored Contributor II
757 Views

.....up.......

0 Kudos
Altera_Forum
Honored Contributor II
757 Views

That means your read only data section isn't mapped to memory. You can correct this using BSP editor.

0 Kudos
Altera_Forum
Honored Contributor II
757 Views

Thank you for the answer, but now I have another problem. When I map the .text section into tightly coupled memory and I debug an assembler code on hardware the Nios II IDE gives this error: 

--------------------------------------------------------------------------------- 

Downloading 02100020 ( 0%) 

Downloading 04000000 ( 1%) 

Downloading 06000000 (21%) 

Downloaded 39KB in 0.6s (65.0KB/s) 

 

Verifying 02100020 ( 0%) 

Verifying 04000000 ( 1%) 

Verifying 06000000 (21%) 

Verify failed between address 0x6000000 and 0x6007923 

Leaving target processor paused 

 

-------------------------------------------------------------------------------- 

0x6000000 is the starting address of the tightly coupled memory. 

 

What does it mean??? 

How can I solve it??? 

 

Thank you. 

 

Rolfo Daniele.
0 Kudos
Altera_Forum
Honored Contributor II
757 Views

How big is the memory area - looks like you need at least 32kb. 

Did you give the cpu data access to the instruction memory (via the Avalon bus and it's second port) that access is needed to allow the JTAG to download code, it is also needed if there is any data (eg .rodata or switch statement jump tables (esp. gcc4)) in the code.
0 Kudos
Altera_Forum
Honored Contributor II
757 Views

Like DSL said you need to make sure a CPU data master is hooked up to the other port of the tightly coupled memory (dual port the memory first). You can use the Nios II data master or a tightly coupled data master for this purpose.

0 Kudos
Altera_Forum
Honored Contributor II
757 Views

Thank for the answers, now I'm able to debug assembler code corresponding to the non-cacheable instruction memory.  

Another problem is related to creation of a new .section, called .cacheable, into the cacheable instruction memory. 

I tried to insert a new line into the .stf file like: 

 

<section memory="ddr_sdram_0" name=".cacheable"/> 

 

In order to put some code in cacheable memory and some code in non-cacheable memory, but when I jump to the code inserted into this section the program counter jump to another location, that doesn't correspond to the label indicated into the program. 

 

How can I solve this problem????:confused::confused::confused: 

 

 

Thank you for helpfulness. 

 

Rolfo Daniele.
0 Kudos
Altera_Forum
Honored Contributor II
757 Views

You might be having problems with the way the linker is configured to handle multiple code (and initialised data) sections. Although it usually causes different problems! 

I'd run 'objdump -p <program>' on the linked elf image and have a look at the virtual and physical addresses of the various segments. Also look at the symbol table (nm -n <program>, or from objdump) to see what the linker put where. If things aren't where you expect the you need to fix the compile/link phases. 

 

The linker script altera used to default to (might have changed since I last used it) puts all the initialised code/data physically following the end of the main code/data sections and expects initialisation code to copy it to the correct place. This is fine if you have a simple 'boot from flash' booter and are basing everything in external DRAM. It doesn't work otherwise! 

The JTAG boot code will load all the loadable elf sections to their correct physical addresses (link with phys == virt). It wouldn't be hard to make a flash loader that did the same...
0 Kudos
Altera_Forum
Honored Contributor II
757 Views

I use NiosII IDE tool because I have to write assembler code, and I debug step by step the assembler code. For these reasons I don't start from a C/C++ application and I haven't the objdump file. Is it correct??? 

 

How can I see section memory location of my system????:confused::confused::confused: 

 

Thank you for helpfulness. 

 

Rolfo Daniele.
0 Kudos
Altera_Forum
Honored Contributor II
757 Views

You can run objdump by hand, I've NFI where Altera hide it in their install! 

In fact, almost any copy of objdump will do - doesn't need to be a nios2 version.
0 Kudos
Altera_Forum
Honored Contributor II
757 Views

Thank you for the answer.  

After the creation of the .objdump file I see that new section isn't created. :mad::mad: 

I read that a new section can be created using BSP Editor, usins SBT tool, but I don't know how to create a bsp file using the NiosII IDE tool. 

How can I import the information contained into the BSP file into a NiosII IDE project???:confused::confused: 

 

Thank you for the helpfulness. 

 

Daniele Rolfo.
0 Kudos
Altera_Forum
Honored Contributor II
757 Views

I solved the problem using the section .ddr_sdram_0 (name of section corresponding to my on-chip memory) to load the cacheable part of the code. 

The instruction is: 

.section .ddr_sdram_0 

inserted before the part of code to load on that memory. 

 

Now observing the content of my .elf file the instructions corresponding to cacheable and not cacheable parts of my code are loaded at correct addresses. 

 

But when I debug the code on my board, when the code jumps to cacheable part there aren't the same instructions listed in .elf file. 

At the same address the .elf file contains a different instruction compared to the disassembly of the debugging code. 

 

What does it means?:confused::confused::confused::confused: 

 

Thank you. 

 

Rolfo Daniele
0 Kudos
Altera_Forum
Honored Contributor II
757 Views

.......up....

0 Kudos
Reply