[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 #9 from Andrey Miroshnikov <andrey at technepisteme.xyz> ---
(In reply to Luke Kenneth Casson Leighton from comment #6)
> this is taking TDI into the top bit (MSB) and dropping the
> first bit (LSB). in software:

This is what I tried to describe (I probably didn't make too much sense did
I?).

I understood the behaviour, however my question is why are the IDBypassBlock
and IRBlock shifting new data from the top of their internal shift registers,
while the IOBlock shifts new data from the bottom?
IRBlock:       tdo <- ir[0] ir[1] ... ir[-1] <- tdi
IDBypassBlock: tdo <- sr[0] sr[1] ... sr[-1] <- tdi
IOBlock:       tdi -> sr[0] sr[1] ... sr[-1] -> tdo

The answer is probably, this is legacy/complicated/etc. so I won't press it
further.

Actually, just checked the old VHDL files TAP was based of, looks like they
have done the same arrangement:
https://git.libre-soc.org/?p=c4m-jtag.git;a=blob;f=c4m/vhdl/jtag/c4m_jtag_idblock.vhdl;h=a8c4ac995da3a787e3a75d10e94bf47018defa81;hb=fe7f74ad4ece0471a90bd4181f15ff678a844b07#l50



(In reply to Luke Kenneth Casson Leighton from comment #7)
> Andrey, each Shift Register created and used in
> one area for one task has absolutely nothing to
> do with any other shift register.

I know, I should've been more explicit in my wording. The names such as "io_sr"
clearly implied that the signals were completely separate.

> a module could decide to insert bits in an order related
> to phases of the moon and the spot trading price of matured
> smoked Edam if they wanted.

Pretty much.

> 
> therefore the bitreversal should i feel be done by the
> caller, i.e. call a explicit reverse() on the data in and
> out of the test function.
> 
> if you really want to do reversal in the test function,
> (which is fine btw) then
> the only "safe" way to do it is to add extra named parameters
> at the end of the paramlist, defaulting to values which do
> NOT change the current behaviour.
> 
> so e.g. reverse=False

Sure, sounds like a plan. I can add a "reverse" optional arg to
tms_data_getset()

The proposed change to test_jtag_tap.py:
1. Add the function:
def reverse_bit_order(word, wordlen):
    rev_word = 0
    for bit in range(wordlen):
        rev_word += ((word >> bit) & 0x1) << (wordlen - 1 - i)
    return rev_word

2. Modify input arg and add if statement:
def tms_data_getset(dut, tms, d_len, d_in=0, reverse=False):
    if reverse:
        # Reverse the data word to transmit MSB-first
        d_in = reverse_bit_order(d_in, d_len)

3. Add "reverse" argument to jtag_read_write_reg()

> this is standard practice in well-maintained SQL databases and
> in any code providing optional args (java, c++, python) but python
> in particular has to watch out because it is interpreted.
> 
> welcome to your first experience of maintaining backwards compatibility
> in software.

Hahahahaha :)

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