Question on TRACE data
ozpropdev
Posts: 2,791
Hi Chip,
A qurstion on the 32 bit mode of SETRACE
The docs show only 30 bits of data. The 2 bits above the 16 bit PC are not used?
The PC for hub exec is right shifted 2 bits to fit the 16 bit space.
Possible candidates could be TLOCK,CNT rollover or the LIFO index.
Maybe the forumisters have some ideas for the spare 2 bits?
A qurstion on the 32 bit mode of SETRACE
The docs show only 30 bits of data. The 2 bits above the 16 bit PC are not used?
The PC for hub exec is right shifted 2 bits to fit the 16 bit space.
The 32-bit trace output is comprised of the following signals, from MSB to LSB:
TASK[1..0] - the executing task, 0..3
HUB - hub cycle that comes once every 8 clocks
FETCH - pipeline stall due to hub instruction fetch
GO - pipeline not stalled and instruction done
COND - execution condition
JUMP - a jump is executing
VID_ACK - WAITVID able to execute
CTRA_SYNC - CTRA is rolling over
CTRB_SYNC - CTRB is rolling over
SERA_RX_RDY - SERA's receive buffer is full, ready for SERINA
SERA_TX_RDY - SERA's transmit buffer is empty, ready for SEROUTA
SERB_RX_RDY - SERB's receive buffer is full, ready for SERINB
SERB_TX_RDY - SERB's transmit buffer is empty, ready for SEROUTB
not used
not used
PC[15..0] - full 16 bits of the program counter
Possible candidates could be TLOCK,CNT rollover or the LIFO index.
Maybe the forumisters have some ideas for the spare 2 bits?
Comments
I'm getting incorrect data on the VID_ACK and CTRA bits in 32 bit trace samples.
So I set up CTRA and CTRB and they appear in the SERA_RX_RDY and SERA_TX_RDY bits.
Are bits 24 and 23 allocated to something else?
This appears to be the correct layout.
The counters (baud generators) in the SERA & SERB circuits do not use the counters as they have their own internal counters. Could this be why you are not seeing the CTRA/B bits change???
That's right. The serial transceivers have their own counters. My test shows the CTRA and CTRB rollovers appearing in the wrong place.
I am also seeing unidentified data in the VID_ACK and CTRA_SYNC bits.
In my test I have CTRA and CTRB rolling over every 4 clocks. You can see the expected pattern appearing in SERA_RX_RDY (RXA) and SERA_TX_RDY (TXA) and junk in VID_ACK and CTRA_SYNC.
BTW. I am not using VIDEO or SERA,SERB.
I think you are saying this is a labeling/mapping document errata that Chip needs to check ?
Any chance of posting the new TRACE bit labels/definitions?
Cheers
Brian
Nothing has changed there, yet, from the prior version. I'm going to get some sleep here, but I'll post this data when I get back to work. Tomorrow I should be into that part of Prop2_Docs.txt.
wire [15:0] trace16 = { t[1:0], hub_sel[0], go, cond, v, jump, p[8:0] }; wire [31:0] trace32 = { t[1:0], hub_sel[0], stall, go, cond, v, jump, z, c, vid_ack, ctra_sync, ctrb_sync, sera_rx_ready, sera_tx_ready, serb_rx_ready, p[15:0] };t[1:0] - task number 0..3
hub_sel[0] - hub cycle
stall - high when loading icache (pipeline is stalled)
go - high on last clock of current instruction
cond - high when execution condition is true
v - high when instruction is valid, low when instruction is cancelled (trailing a jump)
jump - high when instruction is jumping
z - z flag
c - c flag
p[15:0]/p[8:0] - program counter
I'm not yet to this part of the documentation, but I can see that you need these right now.