[pinmux] Add strap sampling and TAP qualification logic

[msfschaffner]

This implements the strap sampling logic and the TAP qualification with life cycle signals.

Signed-off-by: Michael Schaffner [email protected]

[msfschaffner]

Related feature tracker: #5221

[cindychip]

nice syntax!
I wonder if keyword strong is needed here.
I think strap_en_i |=> !strap_en_i [*], once found strap_en_i, from next cycle, strap_en_i has to stay low on every clock cycle until next reset.
Also a quick question: does the strap_en_i pulse only set high for one cycle?

[msfschaffner]

Hey @cindychip, you are probably right that we do not need the strong modification here.
Let me remove that.
RE your question regarding the enable signal: yes, it is expected that this is a single cycle pulse.

[tjaychen]

dumb question from me... what would the strong modification imply here..?

[msfschaffner]

it ensures that the sequential property holds only if the sequence has matched (e.g., you can't have sequences that have started evaluation but have not matched yet at the end of a simulation).

this is needed for things like testing that eventually, an FSM returns to a certain state (especially in FPV, although simulation can sometimes also check this).

I placed it here although it was not necessary in this context, since the sequence always matches after pulse deassertion.

[cindychip]

Thanks for tagging me on the PR michael! I mainly read through and focused on the assertions. LGTM but would be good to have some RTL engineers approve it.

[tjaychen]

quick question, since the flash technically also has a jtag connection to pinmux (however it is muxed and nothing special), should i just do that as part of normal cio_'s?

[msfschaffner]

Hm... let me see... Afaik, the flash JTAG has a different LC qualification signal (the NVM debug one, right)? So we can't daisy chain the DFT TAP with the flash one?

We could technically add a strap pin bit to allow selection of other TAPs here as well...

Otherwise, if it is fine from a test-flow perspective that the JTAG is functionally muxed in the pinmux ( (and therefore requires a pinmux configuration), then we could go for that, yes.

[tjaychen]

yeah it's a different signal, and I do the controls for that directly in flash_phy already, so we don't have to expose anything to pinmux. Maybe that's better then, I just stick with the vanilla pinmux flow and we don't have to do anything extra here.

[msfschaffner]

ok SGTM!

[tjaychen]

lgtm with a few clarifying questions.
They don't need to be addressed in this PR.

[tjaychen]

ah nice! monorail to the rescue!

…

On Fri, Feb 19, 2021 at 3:57 PM Michael Schaffner ***@***.***> wrote: ***@***.**** commented on this pull request. ------------------------------ In hw/ip/pinmux/rtl/pinmux_strap_sampling.sv <#5301 (comment)>: > + if (lc_hw_debug_en[0] == lc_ctrl_pkg::On) begin + rv_strap_sample_en = 1'b1; + end + if (lc_dft_en[0] == lc_ctrl_pkg::On) begin + dft_strap_sample_en = 1'b1; + end + end + + // In case DFT is enabled, and in case + // the TAP straps where set to 11 (DFT) upon + // the first sampling event, we continue sampling + // all straps until system reset. This is used + // during the DFT-enabled life cycle states only. + if (lc_dft_en[0] == lc_ctrl_pkg::On) begin + if (strap_en_q && + tap_strap_t'(tap_strap_q) == DftTapSel) begin I quickly checked our notes in Monorail: More precisely, if we are in TEST and the strap sampling circuitry determines at POR that the strap pins are non-zero, we shall keep on sampling the strap pins continuously to enable switching between different TAPs during one test run. So I guess the preconditioning should be on straps != 0. let me fix that. — You are receiving this because your review was requested. Reply to this email directly, view it on GitHub <#5301 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAH2RSVDYNVYDUNRIBDIBP3S733F3ANCNFSM4X3R6Z7Q> .