WAITVID 5+ clocks?!
RinksCustoms
Posts: 531
Is there any reson for spec'ing the waitvid instruction for 5 or more clocks? And does anyone know how many clocks a WAITVID-WAITVID cycle takes? ie. how many instrucions you have until the next WAITVID is ready to accept D, S ?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
E3 = Thought
http://folding.stanford.edu/·- Donating some CPU/GPU downtime just might lead to a cure for cancer! My team stats.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
E3 = Thought
http://folding.stanford.edu/·- Donating some CPU/GPU downtime just might lead to a cure for cancer! My team stats.
Comments
The settings you use determine how long each pixel takes.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Check out the Propeller Wiki·and contribute if you can.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
E3 = Thought
http://folding.stanford.edu/·- Donating some CPU/GPU downtime just might lead to a cure for cancer! My team stats.
You get the COG back while pixels and colors are being shifted out to the video interface. Ideally, your prep code runs, then a waitvid, then repeats, pausing at each waitvid, until that moment when the video generator is ready for the next frame.
Frames can be any number of pixels. The common ones are 4, 8, 16 and 32.
At TV resolutions, a 4 pixel frame allows for 2-8 instructions, depending on 160, 256, 320 pixels.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer
Parallax, Inc.
I remember that thread now. Thanks!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
The hydra manual defines waitvid as : The WAITVID D, S command halts code execution on the current cog until the VSU can grab the data from the two LONGS "D" & "S". Once it grabs the two LONGS, it then allows the Cog to continue opcode execution.
So in the statement: 5+(Prop datasheet) or 6+ clocks is saying that the WAITVID "D", "S" command takes a minimum of 5+ or 6+ clocks to complete the two-Long transfer into the VSU hardware.
I can possibly implement a pin toggle directly before and aft the Waitvid is called when i get to that point, and see if there's a cycle difference between VGA & NTSC modes, . . . . or i'm guessing you guys have already been there, done that i 'spose.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
E3 = Thought
http://folding.stanford.edu/·- Donating some CPU/GPU downtime just might lead to a cure for cancer! My team stats.
There was a thread recently, from that guy who did the cool micro demo, asking about exactly this. In his scenario, he had unrolled a tight waitvid loop, and pixel data was irregular. Anyway, when you overdrive the waitvid, everything works just fine, but for the pixel data being somewhat scrambled as the VSU just picks up the contents of D & S and goes on about it's business.
The instruction itself does not vary at all.
Once you've setup your waitvid PLLA, Frame size, etc... it just runs. In fact, it will just run over and over, even if you don't do a waitvid! In that case, when it's time for the VSU to do it's thing, it just picks up whatever it finds in D & S and shifts out another frame.
Would be interesting to see if there is a cycle difference. Doubt there is though.
The definition in the HYDRA manual suggests the transfer happens right at the end of the 5 cycles. The transfer can happen while the cog is doing whatever, so I don't think that has an impact on cycles, meaning the VGA deal is probably the same as NTSC. Could be wrong though.... Won't be the first time.
One other thing that might impact things is the frame length. Say that length ends up some odd multiple where D & S is not known to be good. Does it fail, as we saw on the thread about waitvid (and I wish I could find it), or does it wait a cycle to latch those down? I suspect the former, meaning the 5+ cycles doesn't mean anything! It's just gonna be 5 always.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
What I've used is the frame length overall minus the 5 cycles for the one waitvid.
You pay the 5 cycles to get started, then the waitvid starts doing the frame. You get the COG back, but have to execute another waitvid before the end of the frame so the VSU can latch onto D & S at the right time. Too early and it works. Right on time is questionable, and too late means you get garbage pixels, and your loop stalls for another whole frame, which is just a mess.
Can't find the thread. Perhaps it's gone. Anyway, the code shown had a series of waitvids in an unrolled loop, each happening right on time. That didn't work at the 80Mhz. The contributor was doing 800x600 VGA too. That's the basis for my "right on time is questionable" comment. Edit: I wonder if right on time being questionable has to do with PLLA not being in sync with even clock cycles. Just musing at this point, but that would explain that one case not working always for every set of pixels.
So take the clock and the frame size and do the math to get # of cycles, round down to nearest cycle, subtract 5 cycles, finaly divide by 4 and round down to the nearest instruction to get N instructions possible between waitvids, assuming you are not looking at pins or branching.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
Post Edited (potatohead) : 9/30/2008 4:52:00 AM GMT