#apertus IRC Channel Logs

morning folks!

off for now ... bbl

evening folks!

IIRC, you are going to tell us about JTAG today?

then please go ahead when you're ready

apurvanandan[m]: are you here ?

Yes, sorry for delay

and programming devices in-circuit

1- Debugging

3- Boundary scan testing

we can debug what is the state of our component with a software to get what values for example BTS (Branch Trace Storage), LBR (Last Branch Record)

(maybe explain how JTAG communication works first and then let's look at use cases

we can program our device using JTAG to write on the SRAM or Flash

yes, let's start with that

the JTAG has 5 pins interface:

2- TDO (Test Data Out)

4- TMS (Test Mode Select)

we can not use the TSRT as we will see next

we can assign the values of the I/O pins in order to test our design or the program on the board

no i didn't reharse sorry !

here what i'm talking from:

okay, so looking at this diagram, what can we do here?

good, how do we do that?

how?

so the tap controller controls the tap controller?

its a sequence of states that we can assign from the TMS so we can shift for ex. the data register

can anybody help aSobhy out with the basics of JTAG?

looping=0

now everything is clear ...

I doubt that anybody can understand JTAG from this description

as you mentioned, there are four central signals involved

TCK is the clock for serial data and on every clock cycle, data is shifted in from TMS and TDI and shifted out via TDO

i.e. every bit on TMS decides in the JTAG TAP state engine what the next step is going to be

there are several shift registers of certain length in a JTAG device

ly one clock cycle delay

(switch the last two lines :)

do you mean the state machine ?

but I was more referring to the commands in the instruction register

SAMPLE

PRELOAD

SAMPLE : reading pin values into the boundary scan register

PRELOAD : loading pin output values before EXTEST (sometimes combined with SAMPLE)

BYPASS and IDCODE

BYPASS : an opcode of all ones regardless of the TAP's instruction register size, must be supported by all TAPs. The instruction selects a single bit data register (also called BYPASS). The instruction allows this device to be bypassed (do nothing) while other devices in the scan path are exercised

okay, how can this be used for device discovery?

no I don't know

where TDO of one device is connected to TDI of the next device

TCK and TMS is routed to each of the devices in the JTAG chain

by sending a long sequence of zeros/ones one can calculate the length of the instruction and data registers

and with IDCODE, it is possible to figure out what device is connected

aSobhy: okay, so I'm not really happy with the JTAG presentation, but you probably figured that from my comments ...

apurvanandan[m] managed to program the MachXO2 on the plugin module yesterday

so I expect the coming days to see some test code for the MachXO2s regarding data transfer

sure

I want to talk about the protocol ?!

Bertl you said to do one more session on remote beta ?

When can we arrange that

well, we haven't decided that yet, as it depends on the performance we can achieve over the available connections

we might need to do some scheduling to avoid timeouts etc

and in general the packets will probably be of moderate size mainly because there isn't that much data to transfer and we want to keep low latencies for important stuff

as planned, first step should be to evaluate what the communication channel can do in the Beta

I have a problem didn't understand

slow clocks

well, clock need to be generated locally (they can be based on a common high speed clock of course)

and if, on the other hand, the FPGA provides a slave/bridge interface, a clock domain crossing mechanism (e.g. FIFO) is required

so this problem should not be relevant

thanks Bertl

and sorry of what happened today :(

off to bed

nn