[Libre-soc-bugs] [Bug 764] Documentation of I/O Core/Pad JTAG Tests

[bugzilla-daemon at libre-soc.org]

https://bugs.libre-soc.org/show_bug.cgi?id=764

--- Comment #3 from Andrey Miroshnikov <andrey at technepisteme.xyz> ---
(In reply to Luke Kenneth Casson Leighton from comment #2)
> > As for merging with the main pinmux page, is it worthwhile to have a page on
> > the theory (the pinmux), and the implementation (temp_pinmux_info, but with
> > a new name)?
> 
> yyeah i think that's a good idea.
Nice, I'll do some more re-arranging on it next week.

> [btw can you put a width on this
Funny thing is I did add the width statement, I just wrote "px" instead of "x"
(esoteric ikiwiki syntax hahaha)

> yeah go for it
Moved the GPIO block explanations to main pinmux page, will do the same to the
JTAG ones next week.
https://libre-soc.org/docs/pinmux/

> it can always go up later
Ok, then this bug can cover both 763 and 762 development documentation.

> the idea i had was that when setting to "mux bank 7" this indicates that
> the IOpad is to be connected to JTAG boundary scan.
>From my understanding, we'll just need access to all bits of the bank select to
choose the connected peripheral during the JTAG testing, and perhaps the
wishbone bus to adjust puen/pden.
How will the specific bank select of 7 (111) help?
Does the GPIO need to know it's being controlled by the JTAG BS?

Now that I think about it, I didn't consider where the JTAG chain will be.
Is it going to be:
1. Between the GPIO block outputs and the IO pad
2. Or between the peripherals and the GPIO block

The first case means that we'll need a lot more of the GPIO block's signals to
be in the BS chain (including the WB bus). As for the second, the tester still
has to be able to send WB transactions.
Is this why you specified using "mux bank 7"? As a way to control the block
without the WB bus? There probably needs to some kind of shift register, or the
chain needs to be long enough to control all the GPIO parameters.

>if this is _not_ done.
> the only other way is to have double-MUXing, which introduces yet more
> gate delay.
Gate delay is unfortunately unavoidable (unless you have some optimisation
tricks up your sleeve), as there's a lot of MUXing going on regardless.

> i haven't fully thought this through, i'd have to see it as an actual
> diagram, when we get to combining the pinmux with JTAG BS.
Thanks for the suggestion, I'll do some brainstorming and make a scary diagram
>:) (will go in a subsection 4.5 of the main pinmux page)

> but, whatever
> is done, it needs to be documented because it will surprise the heck out
> of people otherwise
Very much so. This topic took me waaaaay too long to understand, hopefully the
new docs will improve the onboarding time.

-- 
You are receiving this mail because:
You are on the CC list for the bug.