Path: ...!weretis.net!feeder9.news.weretis.net!news.nk.ca!rocksolid2!i2pn2.org!.POSTED!not-for-mail
From: mitchalsup@aol.com (MitchAlsup1)
Newsgroups: comp.arch
Subject: Re: control co-processor
Date: Tue, 6 May 2025 22:17:40 +0000
Organization: Rocksolid Light
Message-ID: <2334329dd6846efa526ce35573d64d8c@www.novabbs.org>
References: <vbgdms$152jq$1@dont-email.me> <f5e5bf81ac2c7e2066d2a181c5a70baf@www.novabbs.org> <2025Apr23.194456@mips.complang.tuwien.ac.at> <126700f99b6f97d7483bb5355d68c361@www.novabbs.org> <vucbbe$mvlc$1@dont-email.me> <vul4r4$n19o$1@dont-email.me> <0b410ad93124778a2b1b3ab8fb6ec62c@www.novabbs.org> <vumpcl$2a0rl$1@dont-email.me> <54dcb50f7a378240447d3565f083f0bc@www.novabbs.org> <vupbrk$jpqb$1@dont-email.me> <vv9ffe$3lupq$1@dont-email.me> <vva299$7csk$1@dont-email.me> <5j3SP.1331$RXsc.334@fx36.iad> <jwvikmfupga.fsf-monnier+comp.arch@gnu.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: i2pn2.org;
	logging-data="3434903"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="o5SwNDfMfYu6Mv4wwLiW6e/jbA93UAdzFodw5PEa6eU";
User-Agent: Rocksolid Light
X-Rslight-Site: $2y$10$L4DOWnKNy.gBZ.gobK9zNezEy3s0wbIqHKKuuDbg60Hmlri5ptx5.
X-Rslight-Posting-User: cb29269328a20fe5719ed6a1c397e21f651bda71
X-Spam-Checker-Version: SpamAssassin 4.0.0
Bytes: 3232
Lines: 41

On Mon, 5 May 2025 14:02:58 +0000, Stefan Monnier wrote:

>> Even state-of-the-art CPUs today commonly use scan-chains (via JTAG)
>> for debuggin.
>
> Is there some blog somewhere that explains how scan-chains work (not
> how they're used, but how they're implemented inside the CPU)?
> Intuitively they sound very costly to me, because of things like the
> need to run extra wires all over the place.  I'm obviously
> missing something.

To a good first order:: designers don't think of scan paths, we just
select scannable flip-flops, and the tools build the scan paths for
us. At (or near) tape-out, we have the scan path tools emit the scan
path-of-the-moment so we can adjust the SW that will drive the scan
paths at testing and debug.

Large blocks (such as a whole core or L2) have their own scan path
that will be individually addressable at the scan path controller
to keep the paths down to several Killo-bits each.

For the most part this is entirely automated--abut all the designers
ever do is break huge scan paths into several not-so-huge scan paths.

Design for test engineers use the simulators to figure out the bit
captured by any-random flip-flop via the Verilog model and use said
model to build many tests and then examine what happened to verify
that the design is operating as expected (or not). DFT engineers
use the simulators at least as much as the designers themselves.

-------------

In the distant path, I had the select lines (the heavy loads that
cross the data path and select things for it to do) captured at
the other end of the data path with a skewable scan clock so we
could (essentially) see the timing of the select lines after
crossing the data path. This made it possible to use the scan
path as an oscilloscope.

>
>
>         Stefan