Hmm, my code is too big and messy. Thanks again Brian. Looks like this was a total wild goose.

I can't remember the exact details of when what happened now. I ended up with that pin dual purposed. There is a DRVNOT instruction for pulsing the scope trigger, the scope probe had been on there for days. Obviously this is setting DIR high.

Feeling sheepish now.

"There's no huge amount of massive material
hidden in the rings that we can't see,
the rings are almost pure ice."

Hmm, my code is too big and messy. Thanks again Brian. Looks like this was a total wild goose.

I can't remember the exact details of when what happened now. I ended up with that pin dual purposed. There is a DRVNOT instruction for pulsing the scope trigger, the scope probe had been on there for days. Obviously this is setting DIR high.

Feeling sheepish now.

Is there still an issue with erratic exit on a conditional jump ? (not the last line, special case, which is not erratic)
Is there code to prove that on a real P2 ?

Well, the event trigger is only the key repeat rate of my desktop PC. But even a single key press has fluked it already.

Period is always an even number sysclocks. So far, multiples of either 10 or 8 with shortest down at 30. So that's a WAITX of only 3 (30 - 27). Now you mention it, fault occurrences are more common when period is below 100.

"There's no huge amount of massive material
hidden in the rings that we can't see,
the rings are almost pure ice."

Period is always an even number sysclocks. So far, multiples of either 10 or 8 with shortest down at 30. So that's a WAITX of only 3 (30 - 27). Now you mention it, fault occurrences are more common when period is below 100.

If you remove the waitx, is the effect still there ? Any difference for even/odd delay values ?
What about for other test-&-jump opcodes, do they all have the same issue ?

Well, I've been slowly getting around to working on the real silicon. The problem with branch-on-event inside a REP block is still present!

What's more, if I change that event type to edge detect instead of level detect then that event stops dead 100%. Although I'm still seeing the trap tripping as the execution drops through the bottom of the REP block on rare occasions. Removing the REP and adding a looping JMP then the edge detect immediately works perfectly.

So, event branching from within a REP block:
- Level detect works most of the time with a crazy mode of failure.
- Edge detect never works at all, but still has the crazy failure mode.
- True for both FPGA and real ES silicon.

Here's the two alternate event setup lines:

setse1 #%110_000000|rx_pin 'high IN from smartpin

setse1 #%001_000000|rx_pin 'rising IN from smartpin

"There's no huge amount of massive material
hidden in the rings that we can't see,
the rings are almost pure ice."

The data corruption from simultaneous R/W in lutRAM sharing also seems to be present in the real silicon.

Again, this is with the same code base as above. In this case it depends on the alignment timing of the decimation sampling against the emulated sinc3 filter. I have the decimator loop calculated to cycle in-sync on a multiple of the emulated sinc3 filter loop time - which itself is running on the paired cog. But there is no attempt to know the phase timing.

By repeatedly pressing keys on the keyboard, each one triggers the adjustments on the decimation loop, it breaks the regular loop to recalculate then re-enters the loop at a different phase timing to the sinc3 filter with a possibility of landing bang on top of the lutRAM update. So I presume that is exactly what is occurring when the read lutRAM data goes 100% random. The scope display just fills with blanket noise.

Press one more keypress, even one that makes no adjustment, and the signal comes back as normal.

Edited for clarity.

"There's no huge amount of massive material
hidden in the rings that we can't see,
the rings are almost pure ice."

For anyone that wants to hook up a scope probe, here's the ES silicon version full source configured for no glitches. Pin9 is the DAC output. To see an interesting signal from that you'd also need a bitstream coming in on pin0. I'm using my AD7400 evaluation board.

I'm not quite following, are there multiple issues here, and do you have minimal, portable test cases yet for Chip to zero in on ?

I think you mean 2 issues ?
1) The problem with branch-on-event inside a REP block is still present
2) The data corruption from simultaneous R/W in lutRAM sharing also seems to be present in the real silicon.

in 2 the address or data being corrupted ? Is the issue transient ? (eg bad data read, but write succeeded, so next read is valid data )