[Cryptech Tech] Happier RSA timing numbers

[Michael]

Where would I confirm the clock speed after editing these lines? I did a 
grep for frequency on the build dir and came up with two files using

.CLK_OUT_MUL      (20.0),    // 2..64
.CLK_OUT_DIV      (10.0)     // 1..128

alpha_fmc_err.twr and

alpha_fmc.srp

"grep -r frequency
alpha_fmc_err.twr:   Minimum period:  14.724ns   (Maximum frequency:  
67.916MHz)
_xmsgs/xst.xmsgs:<msg type="info" file="Xst" num="1767" delta="old" >HDL 
ADVISOR - Resource sharing has identified that some arithmetic 
operations in this design can share the same physical resources for 
reduced device utilization. For improved clock frequency you may try to 
disable resource sharing.
alpha_fmc.srp:INFO:Xst:1767 - HDL ADVISOR - Resource sharing has 
identified that some arithmetic operations in this design can share the 
same physical resources for reduced device utilization. For improved 
clock frequency you may try to disable resource sharing.
alpha_fmc.srp:  Clock period: 1.684ns (frequency: 593.665MHz)
alpha_fmc.srp:  Clock period: 8.163ns (frequency: 122.498MHz)
alpha_fmc.srp:  Clock period: 0.648ns (frequency: 1542.496MHz)"


I believe if you make either value 30 the build complains, in one case I 
remember seeing 2000MHz in the error msg. I will try again at 30/10.



On 05/23/2018 11:37 AM, Joachim Strömbergson wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Aloha!
>
> Rob Austein wrote:
>> On Wed, 23 May 2018 01:34:28 -0400, Joachim Strömbergson wrote:
>>> Since you are running w parallel AES cores that way of improving
>>> things is already used. The next thing should be double sys_clk to
>>>   100 MHz. That should drop the wait time.
> I think I can shave off one more cycle/ECB operation (whoopie!).
>
> But lets focus on getting 100 MHz to work. Pavel pointed to
> alpha_fmc_top.v and two lines to change. Those lines are 78 and 79:
>
>    .CLK_OUT_MUL      (20.0),    // 2..64
>    .CLK_OUT_DIV      (20.0)     // 1..128
>
> As I see it, changing either one should be enough, as long as we stay
> within the given limits. For example dropping DIV to 10.0. I asked Pavel
> several days ago to confirm or correct this. But haven't gotten a response.
>
> Pavel: Would dropping DIV to 10.0 be ok? Or do we need to adjust both,
> for example to 32.0 for MUL and 16.0 for DIV?
>
> I can create a branch for this for you Rob to check out and use when we
> know.
>
> - -- 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/
>
> iQIcBAEBCAAGBQJbBZisAAoJEF3cfFQkIuyNYTAQANmlZcZliDYNTLp/16L62Fol
> jcZVZSXWGRkgbPOdftjObD/qQ17W62jbyw1ev5OQl26Z5p5e6N4Qa3umHknUn98/
> ZlSVfF+oWDNz52XFgHMO89PF0Fg8Ks8nwLBHZoWkpznw9LsOv0MYD8xckan5G2L5
> laol3v0u/v/JTuhlFWHmVWwiUiliK0+rb+KqK2gCMCuDSJl/zktB6Mm3vKgKCwS9
> KM5b0SX55Oj0Keg0xNLYhYRrRgcJVGJwiKJZPkAsx6+dBqB3XJx1JJtILMZLARQg
> U85bwzH0TrERxjn8kfdC1oi7UOUHj6PYq+N07iYl15dUlNvHLoRrWB8oauibqUjf
> VEnAxu7exfvQBc3vc1ZnJdiS3UG34BywlOx1RwYCQMaM8CaJ/GdUb1CVa3nQTqmM
> XPrUKHBeUmkIZ+iGnPutqXz+a1BkTYu7ji7xfFcVRCVeEyhYqM9dIoGCfn6xhuZO
> joZt9L+FCUnTEmVWYZ3m0LSQZHMK/mK1ba0vtUrMEDM0q01YCtdOXNoFHSOsZrwN
> w9MqTuUcLJ19bhoQeDdggs3kx+Q3Mn+KQ27AKmEWNTLjwZLXasvmCNH/Torc7hku
> T9WsWX7xDDOTUs2bkivR8olO0Ohxz03u9odT4rQIMR0eubFwxNBfE9+i/TEFtM88
> ntgE9aTqYOoLoBSsxnkL
> =DFav
> -----END PGP SIGNATURE-----
> _______________________________________________
> Tech mailing list
> Tech at cryptech.is
> https://lists.cryptech.is/listinfo/tech