hrm.... yeah been doing more testing... and it seems liek I have high LUT usage because some of the "RAM" is being inferred as LUTs?
do you get any of these messages when you compile?
INFO:Xst:3218 - HDL ADVISOR - The RAM will be implemented on LUTs either because you have described an asynchronous read or because of currently unsupported block RAM features. If you have described an asynchronous read, making it synchronous would allow you to take advantage of available block RAM resources, for optimized device usage and improved timings. Please refer to your documentation for coding guidelines.
-----------------------------------------------------------------------
| ram_type | Distributed | |
-----------------------------------------------------------------------
| Port A |
| aspect ratio | 64-word x 32-bit | |
| weA | connected to signal | high |
| addrA | connected to signal | |
| diA | connected to signal | |
| doA | connected to signal | |
-----------------------------------------------------------------------
really odd.... it's not happening to all of the sha_transform modules though... it only seems to be one.... the 2nd one with the NUM_ROUNDS set to 61 it appears
also, I see things like this when it's synthesizing:
Found 6x6-bit multiplier for signal created at line 120.
Found 6x32-bit multiplier for signal created at line 127.
line 120 is:
assign K = Ks_mem[(NUM_ROUNDS/LOOP)*cnt+i];
line 127 is:
assign K_next = Ks_mem[(NUM_ROUNDS/LOOP)*((cnt+i) & (LOOP-1)) +i+1];
hrm... there has to be a better way to use those generate blocks to parse these values not as signals/wires to be used at runtime, but rather generate constant integers or look up tables/mux's to generate these...
If you go for fully-unrolled, which you probably should on an LX150, the K memory can (and usually will, at least with my code) be completely eliminated.