How to reduce required clock multiplier (oversampling) in VHDL code generation.

3 visualizaciones (últimos 30 días)
A routine compiles into VHDL fine and runs in the simulation, however, it requires the clock to run at a high multiplier:
##MESSAGE: The design requires 9 times faster clock with respect to the base rate = 1.
I tracked this down to the following lines of code:
...
c = mod(ndx,4096)+1;
buf1(c) = buf1(c) + sample * w4;
buf1(c+4096) = buf1(c+4096) + sample * w3;
buf1(c+8192) = buf1(c+8192) + sample * w2;
buf1(c+12288) = buf1(c+12288) + sample * w1;
...
The first add-mult ads 3 to the clock multiplier and every subsequent ones add another 2 and we get to 1x3+3x2=9 times.
Our constraint is to be no more than 2x. No matter what I do, I cannot get below 9x. I tried things like hdlcfg.EnableRate = "DUTBaseRate"; and similar options to no avail:
My questions:
  • The 4 add-mult statements are all independent and should be perfectly parallelizable in hardware. Why is this not happening and how can I make it happen?
  • what are some general principles to keep these multipliers under control?
  2 comentarios
Bharath Venkataraman
Bharath Venkataraman el 19 de Dic. de 2022
Are you able to share the files here or through MathWorks support?
The higher clock request is typically due to a resource sharing request.
Anze Slosar
Anze Slosar el 20 de Dic. de 2022
It turns out we solved the problem by recoding the above as:
c = mod(ndx,4096)+1;
w = [w4 w3 w2 w1];
for i=1:4
buf1(c+4096*(i-1)) = buf1(c+4096*(i-1)) + sample*w(i);
end
It seems that written in a loop matlab can unroll it is happy to do it, but wouldn't do it otherwise.
I suspect it does not recognize that the second line does not actually depend on the first line finishing, despite both accesing buf1.

Iniciar sesión para comentar.

Respuestas (0)

Productos


Versión

R2022a

Community Treasure Hunt

Find the treasures in MATLAB Central and discover how the community can help you!

Start Hunting!

Translated by