From: ZmnSCPxj <ZmnSCPxj@protonmail•com>
To: Luke Kenneth Casson Leighton <lkcl@lkcl•net>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Libre/Open blockchain / cryptographic ASICs
Date: Sat, 13 Feb 2021 06:10:08 +0000 [thread overview]
Message-ID: <rYmUVDf2a5W3sUoLcai_8Iy48f-vEUgC8xZ6J7W5A-3hFBQwt4W5LhO1hgc3v0P-3qfij_ocWno852Ig_vc_pn7WiBK8_YcJ4eYpHQTfp8E=@protonmail.com> (raw)
In-Reply-To: <puUth0RIvY16I3ghjUiTkIPJQEKETPLZrm2QiiELW8AheIGIin29u5RkztTXIeYIK0xg2UIbsx6m-TpkJU2BvmVyYYr_BYbCdIQSk2t7TkU=@protonmail.com>
Good morning Luke,
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
next prev parent reply other threads:[~2021-02-13 6:10 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-25 18:00 Luke Kenneth Casson Leighton
2021-01-26 10:47 ` Pavol Rusnak
2021-02-03 2:06 ` ZmnSCPxj
2021-02-03 13:24 ` Luke Kenneth Casson Leighton
2021-02-11 8:20 ` ZmnSCPxj
2021-02-13 6:10 ` ZmnSCPxj [this message]
2021-02-13 9:29 ` Luke Kenneth Casson Leighton
[not found] ` <CAPweEDymve0zRaqN9yEGHyOeuaSLEYWQ0K2h6usWbXiV=HkOzA@mail.gmail.com>
2021-02-13 14:59 ` Bryan Bishop
2021-02-13 16:44 ` Luke Kenneth Casson Leighton
2021-02-13 17:19 ` Luke Kenneth Casson Leighton
2021-02-14 0:27 ` ZmnSCPxj
2021-02-03 3:17 ` ZmnSCPxj
2021-02-03 14:07 ` Luke Kenneth Casson Leighton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='rYmUVDf2a5W3sUoLcai_8Iy48f-vEUgC8xZ6J7W5A-3hFBQwt4W5LhO1hgc3v0P-3qfij_ocWno852Ig_vc_pn7WiBK8_YcJ4eYpHQTfp8E=@protonmail.com' \
--to=zmnscpxj@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=lkcl@lkcl$(echo .)net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox