cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
engsci
Adventurer
Adventurer
1,240 Views
Registered: ‎04-22-2016

Direct connections between hardware blocks

Jump to solution

I have a three functions which do some image processing and I want the output from one to be directly chained to the output of the subsequent and so forth.

 

In my top-level main file, I have the three functions called back to back like in the following:

 

     func1(Image1, Image2, Result1_pre, Result2_pre)
#pragma SDS resource(1)
     func2(Result1_pre, Result1_mid)
#pragma SDS resource(2)
     func2(Result2_pre, Result2_mid)
     func3(Result1_mid, Result2_mid, FinalResult)

Additionally, I add the following pragmas before the function declarations in each of the functions' header files, e.g. func2.hpp:

#pragma SDS data copy(Input, Output)
#pragma SDS data access_pattern(Input:SEQUENTIAL)
#pragma SDS data access_pattern(Output:SEQUENTIAL)
#pragma SDS data mem_attribute(Input:PHYSICAL_CONTIGUOUS)
#pragma SDS data mem_attribute(Output:PHYSICAL_CONTIGUOUS)

void func2(ap_uint<8> Input[rows*cols], ap_uint<8> Output[rows*cols]);

However, despite my best efforts, looking at the data_motion.html shows that SDX (2018.1) refuses the chain these functions directly with one another and instead connects every input and output back to the global memory (either through ACP/HP) with a DMA (simple). 

 

 

 

Tags (2)
0 Kudos
1 Solution

Accepted Solutions
engsci
Adventurer
Adventurer
1,270 Views
Registered: ‎04-22-2016

I've found a solution to my problem by building with an earlier version of the SDx/SDSoC tool (2016.4). I'm listing my solution in case anyone else ever stumbles upon the same problem.

 

When trying to build the exact same source code with 2016.4, the compiler threw an error when analyzing the top level cpp file. The description of the error was that func2's 0 and 1 arguments were identical. These were instantiated as separate pointers earlier in the code, but were not sds_alloc'ed any space in memory as I didn't think this would be necessary (seeing as the data would be passed directly from one accelerator to the next - not requiring/touching the RAM in the meantime). This assumption was wrong and the fix involved just making sure I had sds_alloc'ed the right size space for these intermediate "result" pointers nonetheless. This was necessary despite having already used the required #pragmas and set array input sized to specify the presence and size of the FIFOs in the header files and function arguments.

 

Oddly, the newer version of the tool (2018.1) did not pick up this error and built to completion. Once these changes were made, both the 2016.4 version of the builds as well as the 2018.1 versions built the desired direct connections between hardware blocks.

View solution in original post

0 Kudos
2 Replies
engsci
Adventurer
Adventurer
1,150 Views
Registered: ‎04-22-2016

Note: I initially thought that perhaps it was due to func1 having a different Initiation Interval (II)  than func2 & func3 (II=4 instead of II=1). However, after re-attempting with a build in which func2 & func3 have been forced to an II=4 instead (to match func1's) - it didn't solve the issue. 

0 Kudos
engsci
Adventurer
Adventurer
1,271 Views
Registered: ‎04-22-2016

I've found a solution to my problem by building with an earlier version of the SDx/SDSoC tool (2016.4). I'm listing my solution in case anyone else ever stumbles upon the same problem.

 

When trying to build the exact same source code with 2016.4, the compiler threw an error when analyzing the top level cpp file. The description of the error was that func2's 0 and 1 arguments were identical. These were instantiated as separate pointers earlier in the code, but were not sds_alloc'ed any space in memory as I didn't think this would be necessary (seeing as the data would be passed directly from one accelerator to the next - not requiring/touching the RAM in the meantime). This assumption was wrong and the fix involved just making sure I had sds_alloc'ed the right size space for these intermediate "result" pointers nonetheless. This was necessary despite having already used the required #pragmas and set array input sized to specify the presence and size of the FIFOs in the header files and function arguments.

 

Oddly, the newer version of the tool (2018.1) did not pick up this error and built to completion. Once these changes were made, both the 2016.4 version of the builds as well as the 2018.1 versions built the desired direct connections between hardware blocks.

View solution in original post

0 Kudos