Forum Discussion
Stable argument doesn't work in simulation
- 2 years ago
Thanks for sharing the report, @DorianL .
It looks like the loop at line 137 was pipelined with II=1, but it was constrained to serial execution.
This means that this outer loop is effectively un-pipelined. This doesn't explain the gaps you are seeing in the simulation waveform though.
I also see that you are getting a memory system with lots of arbitration:After some experimenting, I discovered that the warning about the variable 'fenetre' is a bit of a red herring here. I would expect for a line buffer like you are describing to have a memory system with multiple banks, and each bank having a dedicated load/store unit (LSU). From the image above, we can see that the memory system is not efficiently selecting banks. I tried using the bank_bits attribute to constrain this, but it appears the compiler is ignoring this attribute now.
I was able to get the compiler to partition your 2d array by swapping the dimensions (transposing) so that the dimension to be split into banks (i.e. accessed simultaneously by different unrolled loop iterations) was in the least significant place. This appears to result in the desired memory system (don't forget to swap the accesses too!!)OLD:
// Ligne a retard [[intel::fpga_memory("BLOCK_RAM")]] // memory unsigned int line_buffer[8][NB_COLONNE_MAX];NEW:
// Ligne a retard [[intel::fpga_memory("BLOCK_RAM")]] // memory unsigned int line_buffer[NB_COLONNE_MAX][8];* Note that I changed the dimension from 5 to 8: the compiler complains if you try to create a memory system with a non-power-of-2 number of banks. Changing to 8 is ok because the compiler sees that the extra 3 banks aren't used and it optimizes them away.
The new memory system looks a lot better now:
The sim looks a lot better too:
I think i know how to solve these 2-cycle dips but I'm still waiting for the test to finish.
I suspect it's a side-effect of using a loop nest instead of using a while(1) loop to iterate across image pixels.
Your screenshot mixes the ready/data signals from flux_in with the valid signal from flux_out.
It almost looks like the compiler was not able to schedule your loop with II=1. You can upload your report.zip so we can look at it.
https://www.intel.com/content/www/us/en/docs/oneapi-fpga-add-on/developer-guide/current/review-the-report-html-file.html
You may want to consider the max_reinvocation_delay attribute (code sample)
You can replace the images but make sure they have the same filenames as the originals. (test_0.bmp, test_1.bmp. etc.). I think all test images must be the same size too, since the testbench passes a sequence of images but only sets the image dimensions once.
Hi @whitepau_altera,
Thank you for your answer, I was just talking about the read_rdy from flux_in wich is not constant. I just uploaded the report with this post if you can find something wrong in it, but suprisingly the compiler can reach a II=1 whereas it is clearly not the case in simulation.
I tried with the max_reinvocation_delay pragma but it doesn't change anything on it and it is still slow.
Thank you for the information about the convolution_2d example, I will try to replace images and keep you in touch !
DorianL