Hardware oddity: Dual-Port Hazard
Wuerfel_21
Posts: 5,353
This is something I noticed a long while ago, but here's a proper demo:
Reading a dual port RAM cell at the same time it is written returns an indeterminate value.
(The stored value is fine, it's just a momentary glitch)
CON
_CLKFREQ = 10_000_000 ' Higher speeds are more suceptible
HAZARD_CELL = $004 ' Which cogRAM cell to test - can't go lower than 3 with this
DAT
org
long 0[HAZARD_CELL-3]
.outer
rep @.inner,testlen
xor .hazard,#31 ' ---\
nop ' | XOR result written on same cycle as BITH opcode fetch
.hazard bith val,#0 ' <-----/
.inner
cmp val,expect wz
if_nz jmp #.cought
add loopctr,#1
test loopctr,##1023 wz
if_nz jmp #.outer
debug("Nothing yet... ",udec(loopctr))
jmp #.outer
.cought
debug("Hazard cought! ",ubin_long(val),udec(loopctr),uhex_long(.hazard))
jmp #$
val long 0
expect long $80000001
loopctr long 0
testlen long 1024
fit 496
You may need to try different HAZARD_CELL values or increase _CLKFREQ to get a hit.
It should also be possible to reproduce this with LUT (only streamer and pair sharing use the 2nd LUT port, so it's harder to run into this).
Comments
Guess one need two NOPs with self-modifying code to be safe?
Yes, but that's documented and (I hope) well known.
(it most usually will give you the old value, so there'd be a bug, anyways)
I was looking around for such "documentation" but couldn't find anything on self-modifying code... Have you seen it somewhere?
P2 silicon doc, but I don't think where I originally got it.
Ok, thanks. Know what happened... Tried to use the Edge search, but that doesn't work in Google Docs, have to use their search
Still seems like there should be a section titled "Sefl-Modifying Code" with that note in it...
New p2docs page: https://p2docs.github.io/errata.html
Featuring all the favorites!
Good to have all this in the one place. Nice work.