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++
Announcements
The Intel sign-in experience has changed to support enhanced security controls. If you sign in, click here for more information.

Nios - control the cache

GK4
Beginner
761 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
405 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,

 

GK4
Beginner
405 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,

Ahmed_H_Intel1
Employee
405 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.

 

Ahmed_H_Intel1
Employee
405 Views

Here are the attachments.

 

Ahmed_H_Intel1
Employee
405 Views

Another design for memory to memory using MSGDMA.

 

Reply