Re: [bitcoin-dev] Libre/Open blockchain / cryptographic ASICs

[Luke Kenneth Casson Leighton <lkcl@lkcl.net>]

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 = gating && TESTMODE;
>     always_ff @(posedge CLK, negedge RESET_N) begin
>       if (!RESET_N)   gating <= 1'b1; /*RESET-HIGH*/
>       else            gating <= n_gating; end
>
>     assign SCANOUT_PAD = 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 inadvertent 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 normal operation, only at reset condition) then glitching is impossible, and when 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 reset-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 (which 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 more than 8 scan chains, usually just 4 to 6) so overoptimizing this is not necessary.
>
>
> Regards,
> ZmnSCPxj