summaryrefslogtreecommitdiff
path: root/94/22b233ca21a0494c42c0b36aebff7597b906f5
blob: 5251a16fce66ac912966242e21d90991d050635d (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
Return-Path: <lkcl@lkcl.net>
Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 12F92C013A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 13 Feb 2021 09:30:21 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by whitealder.osuosl.org (Postfix) with ESMTP id F2CFF877FB
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 13 Feb 2021 09:30:20 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from whitealder.osuosl.org ([127.0.0.1])
 by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id YiZ1GBNRhWjo
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 13 Feb 2021 09:30:19 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from lkcl.net (lkcl.net [217.147.94.29])
 by whitealder.osuosl.org (Postfix) with ESMTPS id 49B4187764
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 13 Feb 2021 09:30:19 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lkcl.net;
 s=201607131; 
 h=Content-Transfer-Encoding:Content-Type:Cc:To:Subject:Message-ID:Date:From:In-Reply-To:References:MIME-Version;
 bh=clAdbDlm5Cou+NrMCkKxelT1BrtQ5Igos4yDwul5mdE=; 
 b=YXJVhsqeknF6WQv8vwJCrBJHOBCWB90pm7VKnLl+tGGx+/0/gj5hGm/xP/JVItHeQWMLbfBnbAAv2AvGyqyxudXYbuGoFyXX0JH/h/CWMBPXvTUUfhF06gk74C1YYK+DRT4yQnKGFd3+rpUdjQLTcLbnL9THFJA64PglvD//BZE=;
Received: from mail-lj1-f174.google.com ([209.85.208.174])
 by lkcl.net with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
 (Exim 4.84_2) (envelope-from <lkcl@lkcl.net>) id 1lArFo-0002uH-6f
 for bitcoin-dev@lists.linuxfoundation.org; Sat, 13 Feb 2021 09:30:16 +0000
Received: by mail-lj1-f174.google.com with SMTP id g11so1883948ljj.7
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 13 Feb 2021 01:29:55 -0800 (PST)
X-Gm-Message-State: AOAM530nPGUncM90STwlShbFhdQUrjFHVzXJ8k4TyQB5Ewn5Q32c3T8b
 QPGqBiZyZ8IXu6hzj+5TMepMSu+VsnKLkLRmH2o=
X-Google-Smtp-Source: ABdhPJz3j7UNCu0t3/BldYuDCtzRb1sDhy9Z9FgK36CaiXiFSupdmzIeA8ngRDu9QsTVBnHskhFYHSJIapJ+7inDjj0=
X-Received: by 2002:a2e:860a:: with SMTP id a10mr4007148lji.158.1613208590141; 
 Sat, 13 Feb 2021 01:29:50 -0800 (PST)
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
X-Gmail-Original-Message-ID: <CAPweEDyLwHt0xOty-eVdOvnB5LXezcw=0vNbt6keL0+FirXy1w@mail.gmail.com>
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
X-Mailman-Approved-At: Sat, 13 Feb 2021 14:55:51 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Libre/Open blockchain / cryptographic ASICs
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Sat, 13 Feb 2021 09:30:21 -0000

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