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.
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 ?
JMG,
I'm certainly still dealing with it. See comments at end of source:
'monitor loop
'==============
rep @.monend, #0 'loop forever (REP reduces monitor loop by two instructions)
.monl
waitx delay '2 WAITX reduces monitor loop by one instruction
jse1 #.keyboard '4 branch on event reduces monitor loop by one instruction
'decimator
rdlut samp, #(monitor & $1ff) '7
sub samp, diff1 '9
add diff1, samp '11
sub samp, diff2 '13
add diff2, samp '15
sub samp, diff3 '17
add diff3, samp '19
sub samp, diff4 '21
add diff4, samp '23
'spit to DAC for scope
add samp, offset '25 offset centring
wypin samp, #1 '27 smartpin 16-bit dither into DAC1
.monend
'This code is workaround for intermittent problem with event branching out from REP loops
'occasionly it just drops the JSE1 branch and falls out the bottom of the REP
add dbg, #1
wxpin dbg, #dpin 'mailbox for reporting occurances
jmp #\.keyboard
jmp #\.keyboard 'needs double JMP to recover
cogstop cid
Yeah, that works fine but I wanted to minimise the loop size and the workaround is reliably achieving this. Also, just experimenting with the flaw for fun.
There's no lasting effect from any spurious extra instructions so the recovery is as good as no flaw. The main thing is having an exact loop length to calculate WAITX amount with.
Yeah, that works fine but I wanted to minimise the loop size and the workaround is reliably achieving this. Also, just experimenting with the flaw for fun.
There's no lasting effect from any spurious extra instructions so the recovery is as good as no flaw. The main thing is having an exact loop length to calculate WAITX amount with.
mov delay, period
sub delay, #27
hmm.. what is the failure rate, and does that vary with time or temperature ?
If you remove the WAIT, does that change the failure rate at all ?
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.
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
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.
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 )
Comments
Ok. Good to know. I will fix this.
You shouldn't need to set the TT bits.
You do have to allow 4 lcoks though for a valid IN status.
Cog #1 writes to repository and Cog #0 reacts to IN raise.
Tested and working as documented now. Thanks for the example Brian.
I guess the only question mark is why does, with DIR low, RDPIN work when TT=1 but not when TT=0.
I need to look into that. It shouldn't matter.
I haven't been able to replicate this behaviour.
All combinations of TT has same result.
The only way I can get RDPIN to work is when DIRx = 1
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.
It's not as bad as me BBQ'ing my P2 chip! <:(
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 ?
I'm certainly still dealing with it. See comments at end of source:
Did you try it without the JSE1 instruction?
There's no lasting effect from any spurious extra instructions so the recovery is as good as no flaw. The main thing is having an exact loop length to calculate WAITX amount with.
hmm.. what is the failure rate, and does that vary with time or temperature ?
If you remove the WAIT, does that change the failure rate at all ?
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.
What about for other test-&-jump opcodes, do they all have the same issue ?
Use PX.EXE to program the board.
1. Set switch to "prog" 2. Run PX.exe (e.g. COM7) px Prop123_A9_Prop2_v32i.rbf /7 /p 3. Switch to "run" when done.Thanks Brian. That will get me started on P2. I want to do some P1V later on also.
I am only running Quartus 17. Works with a BeMicroCV-A9.
Quartus cannot program the P123-A7/A9 boards.
These boards use custom Parallax programming hardware (a Propeller 1) and custom software (PX.exe).
IIRC Quartus version 15 onwards supports the larger CV-A9 device.
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:
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.
A visible signal is not actually needed to get the corruption problem. My sinc3 filter ignores any MCLK so cycles happily without any signal.
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 )