From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 12F92C013A for ; 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 ; 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 ; 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 ; 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 ) 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 ; 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: In-Reply-To: From: Luke Kenneth Casson Leighton Date: Sat, 13 Feb 2021 09:29:38 +0000 X-Gmail-Original-Message-ID: Message-ID: To: ZmnSCPxj 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Feb 2021 09:30:21 -0000 On Sat, Feb 13, 2021 at 6:10 AM ZmnSCPxj 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