MIME-Version: 1.0
References: <CAPweEDx4wH_PG8=wqLgM_+RfTQEUSGfax=SOkgTZhe1FagXF9g@mail.gmail.com>
 <oCNGbVElAQCJ1bEmwLXLzIVec0ZoOA2Ar3vkOc1a0GW12h78bhMi_W4n3pCdDt7hJyPFoMRb0U1T5Wx5uQl4oo6zeQtjKs0MdAXGtvLw1SQ=@protonmail.com>
 <CAPweEDy7Xf3nD1mfyX5MmtsGX=1sd5=gsLosZ=bYavJ0BZyy3g@mail.gmail.com>
 <puUth0RIvY16I3ghjUiTkIPJQEKETPLZrm2QiiELW8AheIGIin29u5RkztTXIeYIK0xg2UIbsx6m-TpkJU2BvmVyYYr_BYbCdIQSk2t7TkU=@protonmail.com>
 <rYmUVDf2a5W3sUoLcai_8Iy48f-vEUgC8xZ6J7W5A-3hFBQwt4W5LhO1hgc3v0P-3qfij_ocWno852Ig_vc_pn7WiBK8_YcJ4eYpHQTfp8E=@protonmail.com>
In-Reply-To: <rYmUVDf2a5W3sUoLcai_8Iy48f-vEUgC8xZ6J7W5A-3hFBQwt4W5LhO1hgc3v0P-3qfij_ocWno852Ig_vc_pn7WiBK8_YcJ4eYpHQTfp8E=@protonmail.com>
From: Luke Kenneth Casson Leighton <lkcl@lkcl.net>
Date: Sat, 13 Feb 2021 09:29:38 +0000
Message-ID: <CAPweEDyLwHt0xOty-eVdOvnB5LXezcw=0vNbt6keL0+FirXy1w@mail.gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Libre/Open blockchain / cryptographic ASICs
Precedence: list

On Sat, Feb 13, 2021 at 6:10 AM ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote:
>
> Good morning Luke,

morning - can i ask you a favour because moderated (off-topic)
messages are being forwarded
https://lists.ozlabs.org/pipermail/bitcoin-dev-moderation/

could you send these instead to libre-soc-dev@lists.libre-soc.org?

many thanks,

l.

> Another thing we can do with scan mode would be something like the below =
masking:
>
>     input CLK, RESET_N;
>     input TESTMODE;
>     input SCANOUT_INTERNAL;
>     output SCANOUT_PAD;
>
>     reg gating;
>     wire n_gating =3D gating && TESTMODE;
>     always_ff @(posedge CLK, negedge RESET_N) begin
>       if (!RESET_N)   gating <=3D 1'b1; /*RESET-HIGH*/
>       else            gating <=3D n_gating; end
>
>     assign SCANOUT_PAD =3D SCANOUT_INTERNAL && gating;
>
> The `gating` means that after reset, if we are not in test mode, `gating`=
 becomes 0 permanently and prevents any scan data from being extracted.
> Assuming scan is not used in normal operation (it should not) then inadve=
rtent ESD noise on the `gating` flip-flop would not have an effect.
>
> Output being combinational should be fine as the output is "just" an AND =
gate, as long as `gating` does not transition from 0->1 (impossible in norm=
al operation, only at reset condition) then glitching is impossible, and wh=
en scan is running then `TESTMODE` should not be exited which means `gating=
` should remain high as well, thus output is still glitch-free.
>
> Since the flip-flop resets to 1, and in some technologies I have seen a r=
eset-to-0 FF is slightly smaller than a reset-to-1 FF, it might do good to =
invert the sense of `gating` instead, and use a NOR gate at the output (whi=
ch might also be smaller than an AND gate, look it up in the technology you=
 are targeting).
> On the other hand the above is a tiny circuit already and it is unlikely =
you need more than one of it (well for large enough ICs you might want more=
 than one scan chain but still, even the largest ICs we handled never had m=
ore than 8 scan chains, usually just 4 to 6) so overoptimizing this is not =
necessary.
>
>
> Regards,
> ZmnSCPxj