Shop OBEX P1 Docs P2 Docs Learn Events
Question regarding WaitVid data handoff timing — Parallax Forums

Question regarding WaitVid data handoff timing

shiny_Bobshiny_Bob Posts: 5
in Propeller 1

Hey,
I am recently trying to understand the synchronization process of the cogs and their video generators, for a project of my university.

In the manual/data sheet it says:
"WAITVID consumes 4 clocks itself; however, complete data handoff requires 7 clocks
(6 at some frequencies) between frames..."

I do not understand how a different frequency ( from system clock ? ) affects the number of cycles used for the data handoff in the waitvid instruction, so that it may take only 6 cycles on some frequencies.

Is it because of the synchronization process, so that some systemclock/PLLA frequencies in combination lead to 6 cycles for the waitvid command and others lead to 7 cycles ?

Or is it just bound to the systemclock frequency and has other reasons ?

Eighter way for my project it would be interesting, if there is a way to calculate if 6 or 7 cycles will appear and thats why I am thankful for any hint and help from you :)

Comments

  • Wuerfel_21Wuerfel_21 Posts: 5,049
    edited 2022-02-14 21:32

    I think the documentation is just somewhat misleading there.

    So from the beginning:

    • The video generator is clocked by the output from PLLA, which doesn't necessarily line up with CPU cycles.
    • When the video frame has run out, it latches VSCL and the CPUs internal operand buffers for the next frame, regardless of what the CPU is currently doing (if you line up the code just right, any instruction that is in the right place at the right time can become a "WAITVID").
    • WAITVID simply halts the CPU until the video generator has fetched new data (edge case: when the CPU has missed the previous video frame, WAITVID will wait for the next one!), thus ensuring that the intended data (the operands to WAITVID) end up getting latched. Like all the other WAITxxxx instructions, it always takes at least 6 cycles (I think, anyways). However, due to the asynchronous nature of the video hardware, there may be a 1 cycle window where the waitvid completes in 6 cycles, but the data is latched just a bit too early (in video, this manifests as sparkling pixels (as opposed to unstable sync when the WAITVID is missed entirely)).
    • In practice, none of this really matters since everything is sooner or later aligned to the 16 cycle hub timeslot.
  • shiny_Bobshiny_Bob Posts: 5

    Ah okey yes I think I get this, so when waitvid at least takes 6 cycles this means the 7 clocks in "...complete data handoff requires 7 clocks..." refers to the moment, when the new data is already availbale in the video generator, but the cog is not blocked anymore by the wait vid instruction ?
    This may be not important in practice, but my project includes writing a simulation for the video generator, the logic is not that difficult, but I need to find out, for how long the CPU is blocked by the "handoff" procedur, at the time, the video generator is ready for new data, thus loads the new Pixels and Colors values from the source and destination busses,...

  • Wuerfel_21Wuerfel_21 Posts: 5,049

    If you need exact details, examine the Verilog code.

  • shiny_Bobshiny_Bob Posts: 5

    Haha yes I also thought about that, but I was a bit overwhelmed by the complexity of it, because I am not used to verilog code and so I thought I'll ask here first.
    Thank you!

Sign In or Register to comment.