5 replies to this topic

[Eric Guo]

I met a problem with optimizing an algorithm with large look-up tables (LUTs). By default, the LUT will be converted to RAM in Impulse C, but since some processes in my algorithm will access multiple data in the LUTs concurrently, it would be much more efficient if I can control the HDL generation function to generate register arrays instead of RAMs. The LUTs can be very large (e.g. including 128 elements).

Is there a smart way to achieve my goal? Any suggestion is welcome.

Thanks!

[etrexel]

I met a problem with optimizing an algorithm with large look-up tables (LUTs). By default, the LUT will be converted to RAM in Impulse C, but since some processes in my algorithm will access multiple data in the LUTs concurrently, it would be much more efficient if I can control the HDL generation function to generate register arrays instead of RAMs. The LUTs can be very large (e.g. including 128 elements).

Is there a smart way to achieve my goal? Any suggestion is welcome.

Thanks!

Hi,
Currently even a global array shared across processes is limited in processes that access the RAM to the maximum number of ports of the RAM implementing the array, which will be two for a dual-port RAM. And of course a single RAM port will not allow access to multiple RAM locations simultaneously. The only real way of doing this across processes would be to manually create individual global variables, but depending upon how and how often in the code that the variables are indexed, the generated logic and necessary routing may become large (and slow) quite quickly due to all the multiplexing that may be required.

Depending upon how and how often the LUT is written, an alternate approach to using global variables may be to use a configuration stream to populate a local array(arrays and/or individual variables) within a process.

Best Regards,
Ed

[Eric Guo]

Thanks to Ed.

If the array is only within one process, is there a way to force Impulse C only generate register arrays instead of RAMs? For example, is there a pragma or an option in the CoDeveloper that I can turn on to achieve that? Rewriting the arrays using global variables and multiplexers requires too many changes.

Regards,

Eric

[etrexel]

Thanks to Ed.

If the array is only within one process, is there a way to force Impulse C only generate register arrays instead of RAMs? For example, is there a pragma or an option in the CoDeveloper that I can turn on to achieve that? Rewriting the arrays using global variables and multiplexers requires too many changes.

Regards,

Eric

Hi Eric,
Currently there is no way of forcing a register array and the requirements for the "scalarize" option in CoDeveloper that does something similar are likely to be too stringent to activate. The simplest and least extensive coding method may be to use C macros to select elements within the register array.

Best Regards,
Ed

[gchow]

Hi Eric,
Currently there is no way of forcing a register array and the requirements for the "scalarize" option in CoDeveloper that does something similar are likely to be too stringent to activate. The simplest and least extensive coding method may be to use C macros to select elements within the register array.

Best Regards,
Ed

How would you loop through each element in the array with a macro ? I suppose if Impulse support Boost Preprocessor then it would be easy. Short of that you will have to write some pretty fancy macro code, or spell out the loop step by step by lot of cutting and pasting and string substitution. The only other way I can think of doing it is via a Perl script and that will be a software maintenance nightmare... So any chance ImpulseC will be Boost compliant soon

Gloria

[etrexel]

Impulse will need to evaluate such a change to the CoDeveloper release, however technically replacing the current preprocessor (which is just gcc -E) that creates the '<project name>.i' may be accomplished by editing the Makefile.rules of the CoDeveloper installation.

Best Regards,
Ed