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

Nios - control the cache

GK4
Beginner
1,029 Views

Scenario:

Custom slave which uses waitrequest and bursts. Memory map: 0x200000 - 0x3FFFFF.

I want to write 256 Bytes to the slave, it's a spi controller so the master (NIOS f) should write the data without doing anything in between, I want to check the status register in software.

Problem: When accessing 0xXXXD00 and 0XXXF00 with memcpy I get the following (doesn't matter if 0xXX1D00, 0xXX2D00 and so on):

I use the following code to write to the slave (Avalon slave):

memcpy((alt_u8*)(mem_base+addr),(alt_u8*)(src_cached_ptr),length); alt_dcache_flush_all();

avs_mem_xxx is the signal from the master to the slave after the interconnect component. The system is generated in the Platform Designer.

 

0xD00:

memcpy0xD00.png

The write is splitted into 3 parts: 1st part and 3rd part happens when I use flush, the 2nd part is written while executing memcpy.

 

When accessing 0xF00 I get this:

memcpy0xF00.PNG

 

and when writing to any other 0xX00 address with memcpy and 256 Bytes I get the wanted result:

memcpy256OK.PNG

 

I tried to flush before executing a memcpy:

alt_dcache_flush_all(); alt_remap_cached(src_cached_ptr,length); memcpy((alt_u8*)(mem_base+addr),(alt_u8*)(src_cached_ptr),length); alt_dcache_flush_all();

But got the same result (haven't checked all scenarios with this), 0xD00 behaves the same as 0xF00 now.

 

This src_cached_ptr is a alt_u32* pointer which is passed to this function.

At first I defined the pointer as a pointer to a reserved memory area, afterwards I changed it to a defined array (no dynamic memory allocation). When I do that then 0xD00 and 0xF00 look ok, but 0xE00 looks like the previous 0xF00.

 

In the BSP Editor and preferences, the optimizations are turned off.

 

In the Platform Designer:

qsys_qspi_controller.PNG

so no tightly coupled memory, just the zim_qspi_controller (the slave where I want to use the memcpy) and a nios ram (onchip memory) where my heap and stack is allocated.

 

How can I force the memcpy to write without any interruptions?

 

 

0 Kudos
5 Replies
Ahmed_H_Intel1
Employee
673 Views

Hi,

What I understood that you have two questions (correct me if I am wrong). First the memcpy works fine with all addresses but the 0XF00, plus you want to keep the memcpy moving data without interruption.

For the first question I will try to replicate this issue on a board I have and see why this happens.

For the second, I advise you to use the MSGDMA or any DMA IP (MM to MM). This will solve your problems and give the targeted results.

Here is a design example of the MSGDMA with a video link show you how to use it.

Design reference:

https://fpgacloud.intel.com/devstore/platform/17.0.0/Standard/multi-core-nios-ii-processors-reference-design-based-on-arria-10-soc-development-board/

 

Videos:

https://www.youtube.com/watch?v=GTKLU2UR3bA

https://www.youtube.com/watch?v=DUNAemGhUTE

 

Regards,

 

0 Kudos
GK4
Beginner
673 Views

Yes I want to make memcpy without any interrupt. I haven't tried to see if signaltap or the debug component in the NIOS is causing the interrupts, but I made auto write enable to solve my problem, but if I reactivate this project, I will try the DMA solution and look if debugging components caused the interrupts.

 

Regards,

0 Kudos
Ahmed_H_Intel1
Employee
673 Views

Hi Georg K,

When you try to use the DMA or MSGDMA, please look at these references and example, I've created these myself long time ago.

 

0 Kudos
Ahmed_H_Intel1
Employee
673 Views

Here are the attachments.

 

0 Kudos
Ahmed_H_Intel1
Employee
673 Views

Another design for memory to memory using MSGDMA.

 

0 Kudos
Reply