Waitvid glitch - request for more timing information.
Linus Akesson
Posts: 22
Hi!
I would like to request more detailed information from Parallax, regarding the
internal timing of waitvid and rdlong. Let me explain why.
I'm experimenting with a true colour VGA mode, based on the following unrolled loop:
The video PLL is running at 80 MHz just like the system clock, and VSCL has
been set up with a pixel size of 4 and a frame size of 16.
In order for this to work, the hub round robin scheme has to be in perfect sync
with the video frames. This is achieved like so:
This scheme appeared to work, because my test picture showed up on the monitor
(a TFT). Furthermore, if I deliberately set up the loop measuring routine to
expect another value, the monitor wouldn't sync at all, as expected.
So far, so good. Now for the mysterious bit:
I discovered that my test picture wasn't 100% correct. For one thing, it was
offset slightly to the right and there was garbage along the left border.
Further scrutiny revealed lots of small pixel errors which I hadn't seen before
(due to the image being dithered).
To make a long story short, the video generator wasn't clocking in new data
from waitvid. It was skimming the data bus during the rdlong operation, reading
off the correct colour bytes, but getting garbage (probably the lower bits of
addr) into the pixel shifter.
I duly went on to comment out all of the waitvid instructions, and was still
able to see the picture, with the same bit errors. Fine.
This is consistent with the idea that if you miss your deadline with waitvid,
the video generator picks up whatever's on the internal buses. But in that
case, how could the waitvid instruction possibly take 5 cycles? We're measuring
it, remember!
Could there by any chance be a glitch in the system, by which waitvid fails to
deliver its bits while also failing to delay?
Of course, I'm well aware that this could be a silly little bug in my code,
staring me in the face, so I'm asking you forum people to experiment with this
as well, and see if you can come up with the same phenomenon.
But please, Parallax team, give us a more detailed specification of the
internal timing of the instruction pipeline, hub interaction and video
hardware!
Best regards,
Linus
I would like to request more detailed information from Parallax, regarding the
internal timing of waitvid and rdlong. Let me explain why.
I'm experimenting with a true colour VGA mode, based on the following unrolled loop:
rdlong r1, addr ' 7 cycles
waitvid r1, #%%3210 ' 5 cycles
add addr, #4 ' 4 cycles
rdlong r1, addr ' 7 cycles
waitvid r1, #%%3210 ' 5 cycles
add addr, #4 ' 4 cycles
... (120 times)
The video PLL is running at 80 MHz just like the system clock, and VSCL has
been set up with a pixel size of 4 and a frame size of 16.
In order for this to work, the hub round robin scheme has to be in perfect sync
with the video frames. This is achieved like so:
- 1. Make sure all video frame sizes (including sync frames and porches)
are even multiples of 16 clocks (viz. one hub cycle). - 2. Measure the unrolled loop using the system clock. If the entire loop
takes anything other than 120 x 16 cycles, then the video generator and
the hub are out of sync. In that case, temporarily adjust one of the
upcoming video frames by 1 clock (e.g. set the frame size to 15 instead
of 16). Following a boot, this could happen on 0..15 consecutive lines,
but after that, the entire system will stay in sync due to bullet 1
above.
This scheme appeared to work, because my test picture showed up on the monitor
(a TFT). Furthermore, if I deliberately set up the loop measuring routine to
expect another value, the monitor wouldn't sync at all, as expected.
So far, so good. Now for the mysterious bit:
I discovered that my test picture wasn't 100% correct. For one thing, it was
offset slightly to the right and there was garbage along the left border.
Further scrutiny revealed lots of small pixel errors which I hadn't seen before
(due to the image being dithered).
To make a long story short, the video generator wasn't clocking in new data
from waitvid. It was skimming the data bus during the rdlong operation, reading
off the correct colour bytes, but getting garbage (probably the lower bits of
addr) into the pixel shifter.
I duly went on to comment out all of the waitvid instructions, and was still
able to see the picture, with the same bit errors. Fine.
This is consistent with the idea that if you miss your deadline with waitvid,
the video generator picks up whatever's on the internal buses. But in that
case, how could the waitvid instruction possibly take 5 cycles? We're measuring
it, remember!
Could there by any chance be a glitch in the system, by which waitvid fails to
deliver its bits while also failing to delay?
Of course, I'm well aware that this could be a silly little bug in my code,
staring me in the face, so I'm asking you forum people to experiment with this
as well, and see if you can come up with the same phenomenon.
But please, Parallax team, give us a more detailed specification of the
internal timing of the instruction pipeline, hub interaction and video
hardware!
Best regards,
Linus
Comments
I don't know if this has any bearing on your problem, but if your program relies on the video PLL having any particular phase relationship with the system clock — even thought they're both the same frequency — you may encounter difficulties. Also, it was demonstrated in a different thread that the correct timing for the waitxxx instructions is 6+ clocks, not the 5+ stated in the docs. (Even though the timiing discussed there was for waitpeq, which relates to external (hence, asynchronous) events, waitvid is equally affected by asynchronicity, as I alluded to here.)
-Phil
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
'Still some PropSTICK Kit bare PCBs left!
Post Edited (Phil Pilgrim (PhiPi)) : 7/15/2008 4:30:09 PM GMT
You're quite right. That did cross my mind, actually. But it still doesn't explain why the loop completes in 16 cycles. Waitvid is supposed to wait for the video generator to drop by, so if the video generator has already fired, waitvid should take something like 16 cycles to complete.
I read that thread too, but I doubt that it's the whole truth, since I measured my loop using CNT, and got a result that was incompatible with that idea. My waitvid instructions take 5 cycles. But they fail to deliver to the video generator.
Best regards,
Linus
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer
Parallax, Inc.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer
Parallax, Inc.
-Phil
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
'Still some PropSTICK Kit bare PCBs left!
Sure thing! The VGA mode is 640x480 with active low syncs, and it's for the propeller demo board. I'm attaching the source code.
And welcome to our guilty pleasure. Your CRAFT demo was outstanding!
I've observed that if a waitvid is running...
(and just how exactly does one stop one from running, once started? I remain confused by this.)
...and the next one has been executed BEFORE the running one works through it's frame, all will be good.
So then it's a race condition of sorts, isn't it?
Say one makes changes in the VSCL. That does not impact the currently running waitvid, meaning the one it does impact has to do something to change the behavior for the next frame. That something takes some time, right?
I'll bet it needs a cycle at least to do what it does, or the next frame won't be proper.
What about this bit of code?
if_nz jmp #adjust waitvid metapixels, #0 nop <---- Can't the 'add addr, #4' go here? (adjust your constant so this works) ' Unrolled loop follows. 120 fetches of 4 pixels each. rdlong r1, addr add addr, #4 <---- and get rid of this one? waitvid r1, #%%3210▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
we tested and re-verified (with oscillograms) and it is 6+. I do not remember the thread name....
Since the extra clock in waitpeq/ne occurs after the event, could it be due to the event getting synchronized with the system clock, rather than because of the compare operation? This could explain the difference between waitpeq/ne and waitcnt, since the latter is already (inherently) synchronized, but also requires a compare.
-Phil
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
'Still some PropSTICK Kit bare PCBs left!
Ale, which instruction are you refering to, waitvid?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer
Parallax, Inc.
Welcome to the forums, great inspiring demo by the way, can't wait to see what you've got install for the prop [noparse]:)[/noparse]
Baggers.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
-Phil
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
'Still some PropSTICK Kit bare PCBs left!
Had a bit of time to run the code. I used a HYDRA board, as that is what I had handy. On my LCD monitor, I get "out of range" and no signal. [noparse]:([/noparse]
Any progress, test results from others? I'm interested in the topic.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
I'm quite sure it's my picky monitor too. Have a CRT to try it on this weekend.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net