#apertus IRC Channel Logs

off to bed now ... have a good one everyone!

Hi Bertl,

you said yesterday "[0e3] is the value read from another register" ,which register is this ?

http://ww1.microchip.com/downloads/en/DeviceDoc/20005386B.pdf

on addresses 0x48-0x4d and five more on addresses 0x29-0x2d

some of those need to be written to, but most are read ony

According to the usage you specified yesterday. I think it would be better to have commands like:

`get ZED_5v_info` ,`get HDN_info` ,`get HDS_info` .. and similar for individual sensor info.

that's fine with me, as long as there is some way to do low level settings as well

i.e. for somebody working with the pac1720 (e.g. for doing specific power measurements) there needs to be some direct register access to the I2C register map

You want these control in daemon ?

the main purpose of the daemon is to have a central place for coordinated access to registers

but if the daemon has some mechanisms to interpret this data, that is fine as well, as long as it doesn't interfere with low level access

If that's what you mean

in the future, it might be useful to 'claim' exclusive access to a chip to make sure that nobody else is messing with it

Thanks for the help :)

btw, last time, se6astian just didn't receive your request because of technical problems

we had a brief chat already yesterday

have to leave in about 30 minutes though

great

evening Bertl

I'm ready :)

please go ahead

here is the slides I made

okay, let's hear then ...

JTAG is a protocol that is used for verifying designs ,

slide 2

JTAG devices can be set with 2 ways

slide 3

TCK is the shared clock between all devices (Input)

TDI is the data input to our module (Input)

so its called a Daisy-chained

all the devices are in chain !

continue ?

and the TDO is shifted out

its an optional because we can achieve resetting our device without using it as we will see

slide4

the connection of devices is a star connections

1149.7 vs 1149.1

yeah

slide 6 is swaping with slide 5 so

here is our architecture of the JTAG

TAP : select from the (Instruction Register)IR or (Data Register)DR

we will dive in each one

the Test Access Port(TAP)

for illustration slide 7

with a 6 stable state that we can stay in it more than one cycle

the value on arches is the value of TMS

so what can we do with this state machine?

we have 2 ways we can access the IR or the DR

so let's say we want to write something into the IR, how would we go about that?

so if we sent 5 1s at most we would be in the rest state

in the test-logic-rest i can send TMS in that order 01100 I reached the shift-IR

the number of cycles I'll loop depends on the size of the IR

if it is of length 4 bits so i'll loop 4 times ie shifting 4 bits into the IR so I change its value

ok

how can you reach the test logic reset state?

hmm, when on Capture DR for example

the the first 1 brings me to Exit-DR, the next to Updat-DR

I think yes

because you cannot check the state of the state machine

so sending enough '1's through TMS will ensure that you reach the Reset

so IIRC, last time we had the question: how do you know how many devices are in the chain?

okay, fair enough ...

I forgot to mention that all the taps in the devices are all in the same state every time

OK

the IR value will be the selection of the desired DR

for example the ID register

ok what are the types of IR instructions

what's the purpose of shifting in 32bit via TDI when we have the ID register selected?

I didn't write on it

maybe let's look at the bypass instruction/register first

as in slide 11

which has a register of 1 bit that shifts the TDI in and out that value to the TDO

okay, so this can be used to discover how many devices there are

followed*

when the master(host) receives the one again he will count the number of devices connected

well, it can also be used to 'bypass' a device

and usually you do not want the other devices to do strange things

then you shift in the 'instructions' for all devices (in a long string)

if your instructions are properly arranged, all but one device goes to bypass

sorry

which is usually done via the IDCODEs but as they are optional, sometimes you need additional information

and I hope you now have a rough idea what JTAG requires for the FPGA to FPGA protocoll

how to specify the length of IR

what is the standard ?

1149.1 is the 'normal' JTAG

or you can 'guess' it with some tricks via testing

so, for the protocol, the length of the IR register(s) needs to be variable

So is it all for today's meeting?

(where next week means for the next 6 days :)

no

how the progress is compared to the proposed timeline

it is also a good time to check and potentially adjust your personal schedule for the rest of GSoC

as the evaluation starts on Monday and ends on Friday, it would be a good idea to finish preparations on the weekend and be responsive regarding feedback during the week

where the problems were and what solutions have been found, etc

off to bed, good night