[Libre-soc-bugs] [Bug 763] Work on I/O Core Pad JTAG Tests

[bugzilla-daemon at libre-soc.org]

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

--- Comment #5 from Andrey Miroshnikov <andrey at technepisteme.xyz> ---
(In reply to Luke Kenneth Casson Leighton from comment #4)
> if you do not understand it, insert some print statements into that code.

Yep, that was indeed helpful.

In addition I had to bite the bullet and study the TAP FSM. Now it makes a lot
more sense. Who would've thought? XD

> 
> again, a reminder: stop thinking that you do not have the right to do
> anything you want to, to find out what is going on.

Sure. Now I've even found a discrepancy that doesn't really makes sense in
tap.py
The TDI data for sr is shifted in *MSB first*. See:
https://git.libre-soc.org/?p=c4m-jtag.git;a=blob;f=c4m/nmigen/jtag/tap.py;hb=dfa012c0a884274f2ec5866ce0ac49e271a0bde5#l624

Now, there's another interesting discrepancy. The Instruction Register (ir) is
loaded from TDI *LSB first*. See:
https://git.libre-soc.org/?p=c4m-jtag.git;a=blob;f=c4m/nmigen/jtag/tap.py;hb=dfa012c0a884274f2ec5866ce0ac49e271a0bde5#l150

This is important because in tms_data_getset(), which is used in
jtag_read_write_reg(), the TDI data is sent *LSB first*!!!
https://git.libre-soc.org/?p=soc.git;a=blob;f=src/soc/debug/test/test_jtag_tap.py;hb=67ee79592f304b48e424a92e09a9fbd3a7fff751#l29

This means tms_data_get_set() works for setting the instruction (SAMPLE,
EXTEST, BYPASS, etc.), but is NOT correct for setting the data.

Both ID and IR blocks shift in word LSB first,
while IO shifts in word MSB first.
Is this expected behaviour?

If the issue is with tap.py, ID and IR could be changed to use MSB first
shifting.
Alternatively, what I propose is
- add a function tms_instr_set() which will load data *LSB first* for use with
the setting the TAP instruction.
- modify tms_data_get_set() for-loop to start from the MSB and count down:
    for i in range(d_len-1, -1, -1)
This change also ensures the TDO data is correct (it is shifted out MSB first
as well)

I made those changes locally, but if you give me access to soc repo, I could
pull them in.


As for the issues I had with the tests. The above issue was only affecting me
now, once I got TDO to output the boundary scan registers.

To read the resulting boundary scan chain values after an EXTEST, the TAP FSM
has to be moved to the Capture state (as you've explained in comment #2, but I
didn't understand significance of until I studied the FSM). I will cover this
in more detail on the wiki page.

Importantly for this bug, all 4 test cases are working and producing results
that are expected.

To remind of the cases:
1. Pad inputs and core outputs low, EXTEST, send 2^N-1 (0xFFFFF) test vector.
2. Pad inputs and core outputs low, SAMPLE, send 0xFFFFF test vector.
3. Pad inputs and core outputs high, EXTEST, send 0x00000 test vector.
4. Pad inputs and core outputs high, SAMPLE, send 0x00000 test vector.

Results:
1. Pad outputs and oe are high, core inputs are high.
2. All signals low.
3. All pad inputs and core oe signals high.
4. Pad outputs and core inputs high (as well as pad inputs and core outputs).

Cases 1 and 2 check control from JTAG only, cases 3 and 4 test a system where
signals are controlled externally (by pads or peripherals).

The core inputs values are determined by sampling the core outputs, since they
are connected via an XOR gate internally.
The reason core output oe's are high in case 3 is because the core oe's are
only controlled by the oe test vector inputs, while all core outputs are an XOR
of the core input and a test vector (core_i ^ test)

Can this bug now be closed and RFP sent?

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