Self modifying code spacer instruction requirement (SETS/SETD)
ozpropdev
Posts: 2,791
Formely titled : FPGA platforms exhibit different behaviour (SETS issue)
Hi All
I've been playing around with some video stuff and have found some weird differences
between the various FPGA builds.
I have built a NTSC driver for the Nano that has minimal impact on HUB usage.
The font data is stored in cog so all that is required is a ~800 bytes text buffer.
This driver works differently on the Nano/DE2 platforms compared to the P123-A7 platform.
On the Nano/DE2 build: (see ntsc_nano.jpg)
The characters are displayed in the incorrect position (offset by 1 - see picture).
The first character displayed is actually the last character in the line buffer.
Their also is a random artifact appearing on the first character.
Otherwise picture is stable and clear.
On the P123-A7 build: (see ntsc_p123.jpg)
The characters are displayed in the correct position but several positions are
displaying the wrong characters.
Image has lots of random artifacts which can be cleaned up by inserting a single NOP
in the approprite spot (see code)
I'm guessing their might some compile/timing differences between Cyclone IV and Cyclone V.
I suspected my code (and still do) but getting two totally different results on different
platforms has got the old brain foggy again.
Any ideas?
P.S. You may notice a row of '*' and '?' missing.
These are flashing characters and I missed timed taking the picture.
Hi All
I've been playing around with some video stuff and have found some weird differences
between the various FPGA builds.
I have built a NTSC driver for the Nano that has minimal impact on HUB usage.
The font data is stored in cog so all that is required is a ~800 bytes text buffer.
This driver works differently on the Nano/DE2 platforms compared to the P123-A7 platform.
On the Nano/DE2 build: (see ntsc_nano.jpg)
The characters are displayed in the incorrect position (offset by 1 - see picture).
The first character displayed is actually the last character in the line buffer.
Their also is a random artifact appearing on the first character.
Otherwise picture is stable and clear.
On the P123-A7 build: (see ntsc_p123.jpg)
The characters are displayed in the correct position but several positions are
displaying the wrong characters.
Image has lots of random artifacts which can be cleaned up by inserting a single NOP
in the approprite spot (see code)
I'm guessing their might some compile/timing differences between Cyclone IV and Cyclone V.
I suspected my code (and still do) but getting two totally different results on different
platforms has got the old brain foggy again.
Any ideas?
P.S. You may notice a row of '*' and '?' missing.
These are flashing characters and I missed timed taking the picture.
Comments
At the core of the question is 'What exactly is Altera providing?". Altera is unlikely to enter into any discussion unless you are a business and have at least the potential to buy a licensed version of Quartus II for about $3000USD.
So the comunity of free users is pretty much left in the dark and can only speculate.
So, it pretty much leaves Parallax to working it out and communicating with Altera. We might come up with a satisfactory explaintion here, but I wouldn't waste my time trying to engage Altera in a reply.
I never expected to get Altera involved at all!
I've always found the Parallax community way more helpful.
Incorrect signal levels still doesn't explain random bytes though.
by inserting an extra NOP in .nxtc... so two nop there...
above in .loop1, I can remove the NOP... leave it as it is or have two NOPs and display is still good.
Really need to identify problems like this so we chase after the correct bugs in the FPGA image.
SETS?
mov pixels, 0-0?
I'm guessing SETS inside the REP is being delayed.
My P123 is garbage. It has artifacts everywhere. The blinking dots and ?'s are good but everything else is illegible. One NOP or 2 NOP makes no difference. In fact, my most stable P123 display is without any NOP.
For reference, Potatohead's NTSC text driver is rock solid on both DE2 and P123.
Nothing jumps out at me yet but its kind of scary that things are that different!
I had earlier suspected the REP block but changing it to a DJNZ loop made no difference.
I will keep chipping away at it, pardon the pun
It appears the problem is that SETS requires two NOP's spacing not one!
All tests so far on all three platforms now are correct and stable.
Will test on some more monitors later tonight.
We still don't know the root cause of the different behaviour between Nano/DE2 and P123-A7 builds.
Such a thing is very suspicious and should got to the bottom of. I guess only Chip is in a position to do that. Hope this is reported as a bug somewhere noticeable.
I suppose some marginal timing (multicycle or race? ) could give different ultimate failures on differing processes.
If this passed all timing checks, it would seem there is good reason to be nervous more may be hiding...
The instructions, ALTI, ALTR, ALTD and ALTS modify the NEXT instruction. This is internal to the pipeline stages.
Why isn't it called "ALTDS" ?
Because it can modify the whole instruction, not just D and S.
Actually, I don't see how ALTI could modify the whole instruction.
Guess I have to read the docs again.
I still don't like the name though.
Unless "SETI" also modifies I, D and S that is...
SELF MODIFYING CODE RULE #1 - Two spacer instructions are required to allow correct pipeline fetch.
and there are distinct differences in timing between Cyclone IV and V.
ALTINST?
Just typing these out shows a little ambiguity or difficulty in reading to me.
I personally like ALTISD the best.
Alter Instruction, Source, Destination.
If the pipeline is 2 stage? then surely one space instruction is enough.
The results from the P123-A7 (Cyclone V) were ~95% correct with one spacer.
I feel their may still be something else going on here.
Perhaps Chip can shine some light on this.
Regarding differencies for Cyclone 4 and 5:
Maybe the dual ported RAM behaves differently on read while write. Some FPGAs read the new value written and some return the old value when the same address is written and read.
Andy