initial version of SCAN_INSERTION bus definition #21
Conversation
Good point. Is it a viable case? Same with TEST_MODE being a vector? |
I think we should have one interface per chain. SE, SI, SO to be unique. |
How about this: Example 1:{
TEST_MODE: 'test_mode' // active high test mode input
}Example 2:{
TEST_MODE: '~test_mode_n' // active low test mode input
}Example 3:{
// 0, 1, 0 -- values should be applyed to the inputs in scan mode
TEST_MODE: ['~test_ce', 'TestMode', '~powerdown']
} |
|
@drom yes that looks good. What about SI and SO? What if you have test_si0,..., test_si499 and what if you have a bus like test_si[0:499]? |
Something like this? {
SI: ['test_si0', 'test_si1', ..., 'test_si499']
}{
SI: 'test_si' // 500-bit vector
} |
|
So if you have a bus like Yes I think that would work! |
For vectors you don't need to slice and reconcatenate them back. {
SI: 'test_si' // 500-bit vector signal
} |
|
Yes but I can't define the scan input as a bus. I have to define it like this to the scan insertion tool:
So I need to know the beginning and the end of the bus index. Where is that information in the spec below? |
|
Also @drom how do you do linebreak in a code snipet? When I write code line 1 in between backticks I get |
https://www.markdownguide.org/extended-syntax/#fenced-code-blocks |
|
@drom explained that another section of the DUH file specifies the bus width. What if we have a test_mode [0:2] bus that needs to be 010 in scan mode? How would this be expressed? Like this? |
|
@fferhani do you think we should capture active-low reset as: {
RESET: '~reset_n'
}Similar to |
|
@fferhani do we need to capture synchronous resets? |
|
@fferhani |
|
I don't agree that the scan interface should have clock or reset in it. First off it's not just 1 clock or reset. Instead for each clock/reset that is input to the IP you need Thus, I believe the scan interface should just be mapping to the IPs, test_mode and clockgate_en signals. IT's not clear if there should also be a dedicated reset_bypass_en or if test_mode is always sufficient. For clock/reset handling, we need to instead publish the algorithm that needs to be implemented for proper DFT. That algorithm for clocks is something like: foreach clk_pin in ip.clocks: the point of the first line is to find the actual clock source and make sure it can be muxed with the test_clk. If the thing found generates a clock, I believe the "mux" is called a test clock controller. The point of the second line is to ensure that any muxes in the path to the ip's clock pin get their fastest input clock selected whenever the chips is in test_mode. The algorithm runs at SoC creation time. At IP onboarding time, we need to know the mapping to test_mode and clockgate_en (and maybe resetbypass_en) As for the SI and SO ports, if an IP has those pins, we need to explicitly know their widths. If what's passed in is a vector, that's not possible today. I think this is a good example of where a pararameter on the interface needs to exist to either control or convey the width of an interface signal |
|
@rpadler I think I need the clock and reset info in the scan insertion interface. Before stitching a flip-flop in a scan chain the scan insertion tool will check that its clock or reset input is directly connected to clock or reset input of the IP. So I need to specify an IP's clock and reset inputs to the scan insertion tool. If the IP is a hard macro I also need to specify those to a rule checker like Spyglass if I want to check that scan is properly inserted. In addition, I also need the SoC stitcher to implement your algorithm to properly "wire up" the test clocks and resets at the SoC level. |
|
No ;o)
You don’t need the explicit linkage between clock, reset, and scan_mode in
the interface definition.
You do need the full list of clocks and resets. Our intent is to have
other interfaces that are attached to the IP that enable the full list of
clocks and resets to be figured out. I don’t see a need to capture the
same information in another place.
*From:* François-Fabien Ferhani <[email protected]>
*Sent:* Thursday, April 23, 2020 1:32 PM
*To:* sifive/duh-bus <[email protected]>
*Cc:* Robbie Adler <[email protected]>; Mention <
[email protected]>
*Subject:* Re: [sifive/duh-bus] initial version of SCAN_INSERTION bus
definition (#21)
@rpadler <https://github.com/rpadler> I think I need the clock and reset
info in the scan insertion interface. Before stitching a flip-flop in a
scan chain the scan insertion tool will check that its clock or reset input
is directly connected to clock or reset input of the IP. So I need to
specify an IP's clock and reset inputs to the scan insertion tool. If the
IP is a hard macro I also need to specify those to a rule checker like
Spyglass if I want to check that scan is properly inserted.
In addition, I also need the SoC stitcher to implement your algorithm to
properly "wire up" the test clocks and resets at the SoC level.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#21 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/ANZ4FMDBHVFQQKRFUWLQSKDROCQVXANCNFSM4MKH46UQ>
.
|
|
Ah OK @rpadler so DUH would provide the list of clocks and resets to be used during test, but in another interface. You always try to use the same clocks and resets in functional and test modes, but sometimes it's not possible and you end up with clocks and resets you should only use in test mode and others you should only use in functional mode. How would DUH capture this information? |
|
If it’s a clock or reset on an IP, I expect it to be indicated as such
through some clock/reset interface. We then will still have to hook it up
to some appropriate clock source and reset source just like any other clock
and reset.
*From:* François-Fabien Ferhani <[email protected]>
*Sent:* Thursday, April 23, 2020 2:38 PM
*To:* sifive/duh-bus <[email protected]>
*Cc:* Robbie Adler <[email protected]>; Mention <
[email protected]>
*Subject:* Re: [sifive/duh-bus] initial version of SCAN_INSERTION bus
definition (#21)
Ah OK @rpadler <https://github.com/rpadler> so DUH would provide the list
of clocks and resets to be used during test, but in another interface. You
always try to use the same clocks and resets in functional and test modes,
but sometimes it's not possible and you end up with clocks and resets you
should only use in test mode and others you should only use in functional
mode. How would we capture this information?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#21 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/ANZ4FMAC7HMH7YBBL7KZZMTROCYNHANCNFSM4MKH46UQ>
.
|
|
OK @rpadler. I think you are saying that even if a clock or reset is only to be used in test mode it still has to be specified in DUH through some clock/reset interface and it needs to be wired up properly at the SoC level. I agree. But look at case 3 in @drom Observable notebook: https://observablehq.com/@drom/scan-bus-definition . There are three clocks: |
|
Case 3 is where the IP internally put their own clock muxes. It’s not
something we have any control over, so we have to rely on them to have done
the right thing.
When we instantiate such an IP, we have to functionally connect up all of
the IP’s clock inputs. During scan if we end up having more clocks than
necessarily running, no big deal – we’re still getting our scan coverage
and the previously discussed algorithm (once we figure out all the details)
is what will ensure that we get all the clocks running, properly muxed, etc
*From:* François-Fabien Ferhani <[email protected]>
*Sent:* Thursday, April 23, 2020 3:05 PM
*To:* sifive/duh-bus <[email protected]>
*Cc:* Robbie Adler <[email protected]>; Mention <
[email protected]>
*Subject:* Re: [sifive/duh-bus] initial version of SCAN_INSERTION bus
definition (#21)
OK @rpadler <https://github.com/rpadler>. I think you are saying that even
if a clock or reset is only to be used in test mode it still has to be
specified in DUH through some clock/reset interface and it needs to be
wired up properly at the SoC level. I agree. But look at case 3 in @drom
<https://github.com/drom> Observable notebook. There are three clocks: pll,
clk1, and clk2, but only one clk1 needs to be specified to the scan
insertion tool. How would DUH capture that?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#21 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/ANZ4FMCJ6BGA77HD27NJZI3ROC3P3ANCNFSM4MKH46UQ>
.
|
|
Actually @rpadler I think there might be a problem if during scan if we end up having more clocks than |
Here are some problems with using functional interfaces to capture SCAN information:
|
For SCAN, you don't need |
we know all |
|
You quoted the following statement from me:
“Thus, I believe the scan interface should just be mapping to the IPs,
test_mode and clockgate_en signals. IT's not clear if there should also be
a dedicated reset_bypass_en or if test_mode is always sufficient.”
I didn’t say anything about scan information in any other functional
interface. I am already assuming that we fully capture all clock and
reset pins on the IP - and as I’ve stated elsewhere, I think that’s
through dedicated instantiations of a clock+reset definition.
A true synchronous reset is just a mux on the d-input of a DFLOP -it
doesn’t need to be controlled for scan.
…-Robbie
*From:* Aliaksei Chapyzhenka <[email protected]>
*Sent:* Thursday, April 23, 2020 4:57 PM
*To:* sifive/duh-bus <[email protected]>
*Cc:* Robbie Adler <[email protected]>; Mention <
[email protected]>
*Subject:* Re: [sifive/duh-bus] initial version of SCAN_INSERTION bus
definition (#21)
I don't agree that the scan interface should have clock or reset in it.
First off it's not just 1 clock or reset. Instead for each clock/reset that
is input to the IP you need
1.) the fastest clock source that is attached to the clock pin to be the
muxable/overridable/controllable one
2.) any/all resets must be bypassable.
Thus, I believe the scan interface should just be mapping to the IPs,
test_mode and clockgate_en signals. IT's not clear if there should also be
a dedicated reset_bypass_en or if test_mode is always sufficient.
Here are some problems with using functional interfaces to capture SCAN
information:
- multiple functional interfaces can share the same clock. Should we
provide SCAN information in every interface? or just one? is it optional?
- We can't require that every functional interface busDefinition include
a bunch of SCAN related signals. It is a significant overhead. Also,
different people will be responsible on the functional interface and DFT.
- Functional reset can be synchronous or asynchronous. SCAN reset is
always asynchronous.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#21 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/ANZ4FMBKI66M376UWYOPFPTRODIVTANCNFSM4MKH46UQ>
.
|
|
AR for @rpadler to clear the interface |
New bus definition.
To be consumed by DFT scan insertion tools.
See examples here: https://observablehq.com/@drom/scan-bus-definition