Hi all, I placed a function in a section different from the main code. More exactly, my code is mapped to sdram and I linked a function testcall() into a tightly coupled memory section which I previoulsy defined in sopc builder. So I declared: int testcall(int n) __attribute__ ((section (".tc_code"))); Then, following the suggestion I found in another thread I called ALT_LOAD_SECTION_BY_NAME(tc_code) before calling testcall(). My questions are: - is the ALT_LOAD_SECTION_BY_NAME(tc_code) mandatory? The code seems to work even if I don't use it. - if tc_code section is located in internal fpga memory (cyclone III M9k blocks), how much is the code speed improvement I could roughly obtain with respect to sdram (assume I'm using 2 tse with sgdma). Thank you Cris

I guess that ALT_LOAD_SECTION_BY_NAME(tc_code) copies the code from where ever the normal loader put it into the M9K block. Whether this is necessary depends on how the program image was linked, and how it was loaded. The JTAG loader reads the elf program headers - so can write into multiple disjoint areas - in which case no copy is required (if the program headers are 'correct'). In other cases, a more simple loader might have written the code somewhere else - so the copy is needed. Putting code (and data) in tightly coupled memory areas gives the same access times as if the data were resident in the instruction/data cache.

Thank you for your answer and the explanation of the ALT_LOAD_SECTION behavior. --- Quote Start --- Putting code (and data) in tightly coupled memory areas gives the same access times as if the data were resident in the instruction/data cache. --- Quote End --- This was already clear to me. I simply wondered if I can expect any significative speed improvement in placing frequently accessed code/data in a dedicated tightly coupled memory. Note that I already use a Nios II/f code with cache: anyway I want very fast execution of this function, so I'd like to exclude cache delays due to loading/flushing. I add one more issue to this thread: I tried to place in tc_code section a more complex function, namely the actual function I need to speed up. Now the processor gets stuck whenever this funciton is called! The previous call to testcall() is still present and it has no problem. Why? Regards Cris

If you want a function to execute as fast as possible you probably need to inspect the generated code and examine the control flow and memory accesses to avoid execution stalls and unwanted memory accesses. Depending on the code I'd guess you can gain 20-30% by optimising the C so that gcc generates better code.

I want give just my experience on working with tightly coupled memory. I'm using TCM for an ISR and a few time critical functions. First I forgot to put the variables used by the functions in TCM also outside from SDRAM to TCM ( __attribute__ directive just as for the variables). In my case it was necessary to disable IRQs during functio execution: alt_irq_context context __attribute__ ((section (".onchip_ram"))); context = alt_irq_disable_all(); //time critical code alt_irq_enable_all(context); Apart from performance increase another benefit of transfering functions in TCM is an uninterrupted access to SDRAM for other (custom) bus masters. Jens

hi Jens, In your case, was disabling interrupts for TCM code necessary for the correct execution of code itself or only for performance? In my case I'd allow interrupts since I need to speed up the "average" function execution time and I don't mind if it is sometimes interrupted; think that this function is almost always running, so it DOES need to be interrupted. Can this be the reason why the simple function works while the complete one doesn't? Same question above about placing variables in TCM. I finally agree with your last remark: I'd expect performance increase not for the TCM itself but because sdram is now intensively accessed by other masters through dma. Cris

Code in tightly coupled memory | Altera Community

37 Replies

Altera_Forum
Honored Contributor
15 years ago
For a single variable I need in TCM I simply use the attribute directive after declaration.
int array_in_tcm[128] __attribute__ (section (".tc_data"));
Same for a single function:
int function_in_tcm(int param) __attribute__ (section (".tc_code"));
tc_data and tc_code are the names I assigned to tcm blocks in sopc builder.

I'm not sure, but don't think exception stack placement is so important for performance. This is executed only in case of exceptions, not in normal operation.
Application runtime stack is important, since its data is continuosly accessed in function calls, especially if you use a lot of local variables.
Altera_Forum
Honored Contributor
15 years ago
Ok, now I know how to address tc_data, thanks.

But I intend to use TCM for ISRs (Interrupt Service Routine). I need to know, how to define an "Separate Hardware Interrupt Stack". I haven't found any examples.

Better I explain my intentions in more detail.

My ISR looks like this:

static void handle_CPU2_interrupts(void* context, alt_u32 id) __attribute__ ((section (".exceptions")));

static void handle_CPU2_interrupts(void* context, alt_u32 id)
{
OSSemPost(IRQSem); // <-- benefit from a seperated exception stack ?
IOWR_ALTERA_AVALON_PIO_EDGE_CAP(CPU1_INTHAND_BASE, 0x1);
}

void task(void* pdata)
{
[... init ...]
while (1) {
OSSemPend(IRQSem, 0, &err); <-- event waiting
[ ... do something ... ]
}
}

SoPC:
I set the exception address, on the Core Nios II tab, in the
Exception Vector: Memory: list, to tightly_coupled_instruction_memory_s1.

RTOS:
I use µC/OS-II.

Problems:
1. ISR response takes ~16 µs.
2. From OSSemPost, in the ISR, to OSSemPend, in task, it takes ~34 µs.
Any chances to reduce these times ?

My possible solutions:
-> Try TCM
-> Try VIC -> will reduce ISR response certainly (<<16µs)

If I had examples I wouldn't struggle with TCM and I can test possible performance improvements. I would appreciate any comments / suggestions. I need this for my bachelor thesis.

Thanks any help very much.

Regards,
R2-D2

@chris72
your thread "timer interrupt with rtos-ii"
similar to my project.
Altera_Forum
Honored Contributor
15 years ago
--- Quote Start ---
Problems:
1. ISR response takes ~16 µs.
2. From OSSemPost, in the ISR, to OSSemPend, in task, it takes ~34 µs.
Any chances to reduce these times ?

--- Quote End ---

Did you use the custom opcode for interrupt vectors? It changes interrupt response an opcode to do the dispatch from a C function to lookup the vector.

OSSemPost and OSSemPend delays are part of uC/OS-II. Unless you don't have compiler optimization on (-O2 or -O3) there's not much you can do - unless you put OSSemPost and OSSemPend in TCM.

Bill
Altera_Forum
Honored Contributor
15 years ago
Hi R2-D2,
I have exactly the same situation you described: code placement, RTOS, even same isr and OSSem usage.
So, my response times are similar, too.
In addition, I use NicheStack for TCP/IP and when I load the system with network traffic I have worst case response times up to 150us.
In these cases I also see an increase in isr response to about 40us: I think this is due to OS (or TCP stack) disabling irq in some critical pieces of code.
I wrote a post asking if this behaviour is normal, but I had no answers.

For BillA
I use custom opcode for int vectors and O3 optimization level.
Then I believe R2-D2 does, too.

Regards
Cris
Altera_Forum
Honored Contributor
15 years ago
--- Quote Start ---

Did you use the custom opcode for interrupt vectors? It changes interrupt response an opcode to do the dispatch from a C function to lookup the vector.

--- Quote End ---
Sry, I don't understand this. What do you mean with custom optcode ? Taking the whole bunch of the ISR directly in the VIC, so that I don't need alt_irq_register ?

--- Quote Start ---

OSSemPost and OSSemPend delays are part of uC/OS-II. Unless you don't have compiler optimization on (-O2 or -O3) there's not much you can do - unless you put ossempost and ossempend in tcm.

--- Quote End ---
Sounds good to me! Can you explain me in few words how to accomplish this, please ?

--- Quote Start ---

I use custom opcode for int vectors and O3 optimization level.
Then I believe R2-D2 does, too.

--- Quote End ---
The timings are based on standard IIC (no VIC) and -O0 optimations. So, I haven't done any optimations yet.

Thanks for your comments

Regards,
R2-D2
Altera_Forum
Honored Contributor
15 years ago
--- Quote Start ---
Sry, I don't understand this. What do you mean with custom optcode ? Taking the whole bunch of the ISR directly in the VIC, so that I don't need alt_irq_register ?
--- Quote End ---

Maybe this helps? http://www.alteraforum.org/forum/showthread.php?p=65073

And Google: ALT_CI_EXCEPTION_VECTOR_N

--- Quote Start ---
Sounds good to me! Can you explain me in few words how to accomplish this, please ?
--- Quote End ---
That's covered in this thread in fact: http://www.alteraforum.com/forum/showpost.php?p=92691&postcount=19

--- Quote Start ---
The timings are based on standard IIC (no VIC) and -O0 optimations. So, I haven't done any optimations yet
--- Quote End ---
Don't bother timing anything until you're using -O2 or -O3 - the difference is night and day.

Bill
Altera_Forum
Honored Contributor
15 years ago
Actually, I know these links ;) I will take a closer look then. I will post my results when finished or earlier when something strange happens :eek:.

Thank you very much

Forum Discussion

Code in tightly coupled memory

37 Replies

Recent Discussions

NiosV µC/OS-II TCP-IP debug

NiosV and juart-terminal

NiosV µC/OS-II

NIOS interface to HPS in Agilex 5 for communication.

Nios-V on Cyclone IV