-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Aloha!
Some more results. I have now coalesced the round operations in aes_encipher to a single cycle. This reduces the number of cycles for AES-128 ECB Encipher to 17 cycles. An improvement of 3.35 compared to the old aes core. With these changes the core implemented results are: - - 2168 slices - - 2984 regs - - 122 MHz. (8.17ns) Slightly bigger core. Still good margin to 100 MHz. I will implement similar optimization to aes_decipher. Yours JoachimS Joachim Strömbergson wrote: > Aloha! > > Joachim Strömbergson wrote: >> Aloha! > >> Rob Austein wrote: >>> For future reference: a branch of the existing aes repository >>> would have been much simpler to test than a whole new >>> repository. >> I did considered that, but decided that having two separate cores >> with different architectures would be much less confusing. > > To clarify: I expected that the aes core optimized for speed would be > so much larger (in terms of resources used) that we would never merge > it into the normal aes core. My experience is that having two quite > different architectures and designs in the same repo in different > branches that never merge will lead to confusion. Normally the one > not being the master will be lost, forgotten, not found etc. Even if > you try to be very explicit in branch naming, documentation etc. > > > But I have now done some synthesis runs of the aes_speed core and > compared it to the normal aes core. I think that we could consider > replacing the aes core with aes_speed. > > Results for Xilinx Artix7-t200. > > Old core (aes) - 2102 slices - 2991 regs - 113 MHz (8.79ns) > > New core (aes_speed) - 2019 slices - 2984 regs - 131 MHz. (7.58ns) > > The better clock speed and a few less registers isn't surprising. A > couple of MUXes to provide S-box sharing within the encipher path > and between encipher and key expansion has been removed. > > But the number of slices is a bit surprising. The mapping tool seems > to do a great job mapping the S-boxes. For reference, I've done a > similar modification of the AES core for an ASIC-implementation, and > there we could see an increase in cells as the number of S-boxes > increased. > > > So, we need to test the AES core in the actual FPGA. If it works we > should probably replace the old aes core with the design in > aes_speed. > > > One thing I will do right away is to further optimize performance and > do cycle measurements between aes and aes_speed. > > This is fun! _______________________________________________ Tech > mailing list Tech@cryptech.is > https://lists.cryptech.is/listinfo/tech - -- Med vänlig hälsning, Yours Joachim Strömbergson - Assured AB ======================================================================== -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJbA9c5AAoJEF3cfFQkIuyN+Y0QAMeDcc/oJ5TI89/kuC7D0K33 1ftvcvHdM+4fOwSQ+ipZOmXaMrdoGDb+J7Bg8HAeNYdAhsoojEQrAZoXvBVzscua TErxbZz0GyK4EIjR3/mO/Pi6birKjD3UQXjJGXC23gKJvIdcjkHHqU7bFhAXdMpc OBd5y36P1V8IVl7XAni7BQ+lzBX2mlZvyut3gHlzFMi0NJE+55uyUFuQUjRVdrKA 4vjIk4ygsE7t2r1jVIucQBiG4J8Skfd07W9DqLS/WnYEWuj0p5fWGnmoaM16VIzg PWY95WeTeD4TjuwUschzi4Z3TggeHkzuP7blbQ3RexWPlJOQPhNQlAdLtZP+y7c8 4FtRMPQyFGWuFxjCCUOIXOmpW2JVYJGPafe53z9z29pJOrZRPabJ+n5GLNZYrpQX rokFN6Na2o0WlHw9C+ZK+GH7WND4ZXQFyuJ0Q2uretUGwW8IGlEdQ3Wg2zp9Y3oy F21znDtqh8Hzn4LSlLagqnY2+TPrknWxnkeKRdJFkgHvHfrace7udSKHjR0aUAiX uL8irKDKXBAcV+dBP3qk5En8P6qrAqwxHyqdUeDZ+BCjUndvaXZleaLGwehb84yl lgdgZXpyjmbjojifGzOizRNt5ExNCOIgtJ4+vz0WsbOriQhdiXT8kS0VzM4uDzIi T+EbIH7jnhMViFhce3mG =SGRU -----END PGP SIGNATURE----- _______________________________________________ Tech mailing list Tech@cryptech.is https://lists.cryptech.is/listinfo/tech
