Bug 764 - Documentation of I/O Core/Pad JTAG Tests
Summary: Documentation of I/O Core/Pad JTAG Tests
Status: CONFIRMED
Alias: None
Product: Libre-SOC's first SoC
Classification: Unclassified
Component: Documentation (show other bugs)
Version: unspecified
Hardware: PC Linux
: --- enhancement
Assignee: Andrey Miroshnikov
URL: https://libre-soc.org/docs/pinmux/
Depends on:
Blocks: 50
  Show dependency treegraph
 
Reported: 2022-01-13 01:27 GMT by Andrey Miroshnikov
Modified: 2022-06-15 22:06 BST (History)
2 users (show)

See Also:
NLnet milestone: NLnet.2019.02.012
total budget (EUR) for completion of task and all subtasks: 1500
budget (EUR) for this task, excluding subtasks' budget: 1500
parent task for budget allocation: 50
child tasks for budget allocation:
The table of payments (in EUR) for this task; TOML format:
[andrey] amount = 1500 submitted = 2022-06-10 paid = 2022-06-14


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Andrey Miroshnikov 2022-01-13 01:27:41 GMT
Separate bug for documentation task of the core/pad JTAG tests.

For the tests, see bug #763

The temporary documentation can be found here:
https://libre-soc.org/docs/pinmux/temp_pinmux_info/

Plan:
- Merge general overview information about JTAG/GPIOs with the main pinmux page (https://libre-soc.org/docs/pinmux/)
- Reword the explanation of the core/pad JTAG tests
- Expand on the pinmux (with diagrams and proposals)
- Add any missing references to useful sources (GPIO, JTAG, etc.)
Comment 1 Andrey Miroshnikov 2022-01-22 22:08:24 GMT
I've updated the GPIO section of my temporary documentation page:
https://libre-soc.org/docs/pinmux/temp_pinmux_info/

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)?

For example, the current section 4 which covers the GPIO block can go into the main page, however the testing and brief code explanation can be on the second page.

Also, let me know if 500EUR is an appropriate budget, and what else should be documented before the bug can be closed.
Comment 2 Luke Kenneth Casson Leighton 2022-01-22 22:20:45 GMT
(In reply to Andrey Miroshnikov from comment #1)
> I've updated the GPIO section of my temporary documentation page:
> https://libre-soc.org/docs/pinmux/temp_pinmux_info/

looks great

> 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.
[btw can you put a width on this
https://libre-soc.org/docs/pinmux/io_mux_bank_planning.JPG
in the tag you can set width=800 or size=800x something
like that, there's loads of examples, grep the mdwn files]
 
> For example, the current section 4 which covers the GPIO block can go into
> the main page, however the testing and brief code explanation can be on the
> second page.

yeah go for it

> Also, let me know if 500EUR is an appropriate budget, and what else should
> be documented before the bug can be closed.

it can always go up later

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.  if this is _not_ done.
the only other way is to have double-MUXing, which introduces yet more
gate delay.

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.  but, whatever
is done, it needs to be documented because it will surprise the heck out
of people otherwise
Comment 3 Andrey Miroshnikov 2022-01-22 23:11:01 GMT
(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.
Comment 4 Andrey Miroshnikov 2022-06-08 22:10:32 BST
Updated the documentation related to the pinmux block (Section 4):
https://libre-soc.org/docs/pinmux/
Comment 5 Luke Kenneth Casson Leighton 2022-06-08 23:03:43 BST
(In reply to Andrey Miroshnikov from comment #4)
> Updated the documentation related to the pinmux block (Section 4):
> https://libre-soc.org/docs/pinmux/

looks great, the only thing the numbering in each cell is wrong, here
https://libre-soc.org/docs/pinmux/xgpio-mem-layout.jpg.pagespeed.ic.p5E850LcdR.webp

it should be

add/row
0          7  6  5  4  3  2  1  0
1         15 14 13 12 11 10  9  8

and here:

For example, if 16 GPIOs are instantiated and 64-bit data bus is used, GPIOs 0-7 are accessed via address 0, whereas GPIOs 8-15 are accessed by address 0.

should be:

For example, if 16 GPIOs are instantiated and 64-bit data bus is used, GPIOs 0-7 are accessed via address 0, whereas GPIOs 8-15 are accessed by address 1.