Guest
fpga_toys@yahoo.com wrote:
http://web.nps.navy.mil/~dcanrig/pub/sboxalg.c
Which after some serious hacking to reduce to define macros compiles
into just over a hundred luts or so, about a 15-20% savings over using
LUT rams and MUX's which would be a little over 128 LUT's per Sbox. I
suspect with some floorplanning that's faster than routing to use
BRAMs.
He has some HDL for the same algorithm, so when I'm done we can do a
head to head with XST.
Well after a few hours of google I did find:Allan Herriman wrote:
How about inferring BRAM for the sboxes? That's what many
implementations do. (I'm assuming the point of the exercise is to
compare the results of an implementation written in C with one written
in a more conventional HDL.)
May seem strange, but the point wasn't to do a head to head comparison
with other HDL's. I've some interest in crypto algorithms and have been
on a search for "projects" which I can use as examples for the FpgaC
release. The changes for technology mapping F5/F6 muxes has been on my
list since last summer. AES and PCI examples just drove the point home
it should be now, not later.
http://web.nps.navy.mil/~dcanrig/pub/sboxalg.c
Which after some serious hacking to reduce to define macros compiles
into just over a hundred luts or so, about a 15-20% savings over using
LUT rams and MUX's which would be a little over 128 LUT's per Sbox. I
suspect with some floorplanning that's faster than routing to use
BRAMs.
He has some HDL for the same algorithm, so when I'm done we can do a
head to head with XST.