[Cryptech Tech] [Cryptech-Commits] [core/platform/novena] 21/21: Sick hacks to compensate for sparse MUX within TRNG core.

[Joachim Strömbergson]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Aloha!

Pavel Shatov wrote:
> On 01.10.2015 15:32, Joachim Strömbergson wrote:
>> 
>> Most of our HW design has async active low reset (all hash cores,
>> aes, cha, trng, entropy providers, parts of eim etc). The big one
>> that does't do this is modexp6s.
> 
> If you look carefully, you'll see, that this core doesn't have a
> reset signal at all, reset is only used in the wrapper module. I see,
> that we have two voices for active-low and one for active-high.
> Joachim, can you rewrite the wrapper for modexps6 or do you want me
> to modify it for active-low?

Unless you want me to, I'll stay out of your core. As you wrote before:

"2) We start a voting process and decide, what kind of reset we will be
using from now on. Everyone will then modify his cores accordingly."

I would also suggest that you add reset clauses to the functionality of
the core. A fast glance at modexps6_modinv32.v for example seems to
suggest that cnt, power_reg gets initialized at definition time. At
least synthesis tools for ASICs will happily ignore those values and the
registers would have an undefined state at first start.

Also, If you update the core, how about adding a short README it is the
only core that doesn't have one. Just state what the functionality of
the core, and possibly a note that it uses instantiated Xilinx macros.


> Wait, the signal eim_cs0_n is chip select, and it is indeed
> active-low. Now EIM arbiter has an FSM, that should be reset, when
> FPGA is deselected (i.e. eim_cs0_n == 1'b1), that is why there is
> posedge in that module. Well, I think you can treat this signal as an
> active-high reset, but it is specific to EIM arbiter module, it
> should not be used anywhere else.

Keep calm, the note was just related to the suffix "_n", which generally
implies active low. Which is in itself kinda weird since "n" is for
negative flank, not signal level. But "_n" for something that reacts on
positive flank and high level. Very confusing. Not named by us though I
think...


> Joachim, one more important thing to consider is the clock manager 
> module. We have a PLL there, so we must wait for it to lock before 
> releasing reset. PLL has an active-high output named LOCKED. In
> theory this signal can be directly used as reset, but I remember,
> that doing so gives very weird timing issues, that's why I added a
> synchronizer there.

As I wrote in a previous mail, I think for technology specific things
like clock generation and management we should do what is best on that
technology. It is the application specific cores and utilities that we
try to design in a platform agnostic way. These are the cores we
hope/expect people want to borrow and port to other technologies. They
´are important to use unified interfaces including reset strategy. If
the tech specific stuff matches that strategy its good, but we shouldn't
spend a lot of work there. imho.


> Right now `sys_rst' (which is generated by clock manager) behaves 
> exactly as you want: it gets asserted asynchronously whenever PLL has
> no lock, and then released synchronously. The only problem is
> polarity, since I coded it to be active-high. To convert it to
> active-low, you need to preload the shift with register with zeroes
> instead of ones, and feed 1 instead of 0 into the first flip-flip. Do
> you want me to modify novena_clkmgr.v or you can handle this
> yourself?

Please do. Thanks!


- -- 
Med vänlig hälsning, Yours

Joachim Strömbergson - Alltid i harmonisk svängning.
========================================================================
 Joachim Strömbergson          Secworks AB          joachim at secworks.se
========================================================================
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCAAGBQJWDjFjAAoJEF3cfFQkIuyNs1YQALf17Oezgv15FtstqgZXbEd5
qbYzA9L/881Ya0rUTtMNAU0Wz+SHPCc9M1b8NJqEWioTFqQA7QT4BCzwMDmKD2i8
L/VOSABLop5KDvUGPQIrKWB/QRJGj0i0cIzGCK85UGYftXBnDXD/uEdud4iagT4C
GrIutG2xBvQAN4OazUoJgIH/MiKPgz8JGtIxT1WA86A8/3ssmigD8XRf4iQ7ahVP
PtAt0/0LiZJkV63SnFLJR8MRvbAWKYZGBrePpE8EawiVhgh3xeKNY4EPm8NC51Ga
GeDok48NHi9mInOChHAhqA/rJvDWimw8CWokA+ldbbTBzzkAs6V+8eAG17QhtA24
yzrV6QP0KEef82Bo8X4g0fYn5RS9jtmA79cmoHk0iHBg6NOrKeEQIUjuOl/O/NP1
JArjTQ2lu1gTAtGqeQwlufKKnu1xWLdVm67jt+FdEfN2G77KHx2Yf5EyhDqwDRWq
f9W//ZGhVjp+oweeWIlOxVs3wULFkCHdpP++AzHH02CEWrIZ+3Pfp3pNioN4FSqv
zOff0AlvWOyj/1J8Am0ouj7UIkzKQlbmgknxRrTITw1GTp2+fEgt7xBWIpAtz6q+
umIiwK9uTYyQV1TFVEcVF7lhYPSg0HbJuKwHZ6OPx+aB0R9oUcvzpAUx31SeKLFQ
TPqJmgyLWtq2PPVQrpCk
=BV3f
-----END PGP SIGNATURE-----