Help with a test

[Gusvinhal]

[jar]

[Gusvinhal]

Hi!

This code don't have any parallellism because I want just test the comunication between the zynq and the core of epiphany =-] The code just transfers a data to core (via shared memory), change the value and transfers back.

Matrix with sizes less than 5x5, works. Matrix with sizes greater or equal 5x5 the core can not write the values in matrix.

[GreggChandler]

[Gusvinhal]

[GreggChandler]

[Gusvinhal]

[GreggChandler]

The Epiphany SDK, or eSDK, installed on my Parallella (2016.11) ships with three separate .ldf files: internal.ldf, fast.ldf, and legacy.ldf. Table 5.3 (page 49 in REV 5.13.09.10) of the Epiphany eSDK Manual (found here: http://adapteva.com/docs/epiphany_sdk_ref.pdf ) defines the differences between the various .ldf files. Sections 5.5 and 5.6 give a brief explanation of why these different .ldf files are necessary. In summary, the Epiphany III supports two different types of memory: core memory, and external shared memory. (In the table these are referred to as: "Internal SRAM" and "External SDRAM". The difference between the "internal.ldf" and "fast.ldf" is where the various parts of you program are located. Understanding the differences is essential to writing a good Parallella/Epiphany program. I would discourage the use of the installed "legacy.ldf" as it appears broken.

In your program the "vet" array is allocated on the stack. That will severely limit the maximum size that your program will support. An integer array of 100x100 elements will require 10,000x4 bytes of memory. Since the "Internal SRAM" is limited to 32KB, your array will not fit in internal memory--much less on the stack. This means you will need to return to the "fast.ldf" model. When you return to "fast", you must be careful not to allocate your external memory buffer where other program memory components are located. The art of Epiphany programming lies in correctly managing these resources efficiently.

There are a host of other issues that you will need to consider in writing your program, not the least of which is the performance of "External SDRAM" (it is slower than "Internal SRAM",) and the "weak memory-order model" (it is non-standard and non-intuitive, although it only affects external memory). You also might want to review Section 4 (page 17 of REV 14.03.11) of the Epiphany Architecture manual, found here: http://www.adapteva.com/docs/epiphany_arch_ref.pdf .

It is my understanding that sample applications have been provided by Adapteva and/or community members to address the issues involved in writing an application such as yours. I am not familiar with the samples, as my programs have been written from scratch. Additionally, you might consider using some of the helper libraries that may assist in managing external/internal memory. Again, I am not generally familiar with them, as I have built my own. If you choose to build from scratch, don't under-estimate the work involved. If you choose to use a library, remember that will add more to the learning curve and consider support. If you choose to modify a sample, carefully consider the quality of the code before you modify it.

[Gusvinhal]

[GreggChandler]

You can start by searching for the "SECTION()" attribute macro. It is described in one of the manual sections that I suggested you study. SECTION() will facilitate allocating a variable in any section of memory, including the "external SDRAM". The problem with using SECTION() is that you will need to determine where the data is stored so that your ARM/host program can initialize/access the data. Some libraries take care of such things for you. I wrote my own library that supports allocating/freeing external memory from either the ARM or Epiphany cores. I believe that e_shm is available with the eSDK, however, I haven't used it. I believe that e_shm can be used to manage external memory. I used my own shared memory libraries.

The other consideration that I mentioned in a prior post is the "weak memory-order model". I have successfully written code that accesses external memory directly, although, I don't use e_read() or e_write(). From the Epiphany cores it is very straightforward to access external memory via pointers. I use e_alloc() to access the external memory from the ARM as well. The tricky part is that the pointer values on the ARM side do not match the pointer values on the Epiphany side. "The "weak memory-order model" implies that no matter how you access external memory, you must be careful when ordering reads and writes.