2 replies to this topic

[zje]

As part of my program, I want to convert an array of 8 64bit big endian integers to 16 32bit little endian integers.

Here is my loop:

CODE

for(i=0; i<8; i++) {
    #pragma CO UNROLL
    w[i*2] = SWEND((co_uint32)nSample[i]);
    w[i*2+1] = SWEND((co_uint32)(nSample[i]>>32));
}

When I try to generate HDL, I get this error:

CODE

Assertion failure in file "..\transform.cc" at line 655:
test_hw.c:62: Unroll pragma found on malformed loop
make: *** [TEST.pk0] Error 1

I actually tried an empty loop and that didn't work...

FYI, SWEND is defined as:

CODE

#define SWEND(i) ((i&0xff)<<24)|((i&0xff00)<<8)|((i&0xff0000)>>8)|((i>>24)&0xff)

As a side note, I accomplished this in VHDL by connecting signals. I'm going to assume that there's little hope this will compile to do so and will end up doing all the bit masking and ORing... is there a way to some sort of wire mapping type stuff in impulse?

Thanks!

[RalphBodenner]

The unroll pragma has some limitations, documented in a section of the CoDeveloper User's Guide entitled "Understanding Loop Unrolling". Until version 3.50, one of these limitations was that the loop being unrolled must have an index of type 'int'--this could be the source of the error message you're seeing. With 3.50, however, all integer types can serve as the index of an unrolled loop.

It is likely that your SWEND macro will turn into shifting and masking logic in the generated hardware, rather than simply connecting wires. You can, however, use your VHDL version of SWEND in your Impulse C program. The CO IMPLEMENTATION pragma lets you tell the Impulse C hardware compiler to use a user-defined HDL implementation for a given C function. See the section "Using External HDL Hardware Functions" in the CoDeveoper User's Guide (accessible from the Help menu in CoDeveloper).

Regards,
Ralph

[zje]

I'm using 3.5, but converting to int was still required, I was originally using co_uint3 to save resources since I only needed 0-7. But, I guess since I'm unrolling the loop that really doesn't matter. Also, thanks for the pointer to CO IMPLEMENTATION, sounds like exactly what I was looking for!

Thanks again!