• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 97 subscribers
  • Views 594 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Different clock rate, different count?

Anonymous
Anonymous

Hi All,

If DM6437 can work at different clock rates, does this necessitate change in clock cycle count in order to synchronize with external data stream?

As a concrete example, VPFE can accept BT.656 NTSC stream which gives 60 fields per second, so each field occupies 1/60 second. If the clock rate is 600M (nominal; the actual number is 594M), for every 100,000 cycles there is a new field coming in.

But if we change the clock rate to 700M, the if we still wait for 100,000 cycles, then this time will obviously be less then 1/60 second. If we keep this 100,000 unchanged and synchronize in this manner, then every minute we have:

700M / 100,000 = 70

Then we are expecting 70 fields, which is incorrect. In order to get the synchronization work correctly at 60 fields per second, we need to wait

700M / 60 = 116667 clock cycles (all calculation based on nominal value)

Therefore, any change in the clock rate must be accompanied by a concomitant clock cycle count change for various external devices. Is this correct? Does

  1. the programmer need to do it manually
  2. or an OS is required to do it
  3. or the hardware does it automatically? Put in more detail: once the chips detects any command (register setting: is it possible?) for changing the internal PLL multiplication factor, it will also automatically reset timers(clock cycle counters) related to VPFE / VPBE, audio peripheral and so on?

This is not restricted to the DSP realm. Game players does overclocking frequently, but what they usually do is only to adjust either the fundamental clock rate or the multiplier factor. However, after the adjustment they can still get a connected audio audio or video device (either input or output) working properly and there is no "speeding up" phenomenon. Because of this observation which means that the synchronization is still working properly, we can infer from this that either the hardware itself or the operating system (Windows, etc.) has already done the clock cycle count adjustment work automatically without requiring the user to do set manually (which is also impractical for ordinary users).

Is this correct?




Sincerely,
Zheng

  • 0
    TI__Guru*** 125430 points

    Zheng Zhao said:
    As a concrete example, VPFE can accept BT.656 NTSC stream which gives 60 fields per second, so each field occupies 1/60 second. If the clock rate is 600M (nominal; the actual number is 594M), for every 100,000 cycles there is a new field coming in.

    BT.656 consists of a clock and data.  In other words the incoming video stream has its own independent clock source.  Generally the video peripheral will interrupt the CPU at specific times (e.g. start of a new frame).  In this way the CPU speed can change independent of the video.  The number of CPU cycles between interrupts will change as a result.

    If you change the CPU speed there are other things you would need to take care of.  You mentioned in one of your other posts that xdctools platform wizard specifies the frequency as 594 MHz for DM6437.  That's because the OS has its own internal time base and so it needs to know how fast it is being clocked.  If you were to configure the DSP for a different speed you would need to tell the OS about it.

  • Anonymous
    0 Anonymous in reply to Brad Griffis

    Dear Brad,

    Brad Griffis said:

    That's because the OS has its own internal time base and so it needs to know how fast it is being clocked.

     

    What is "own internal time base"? I could thought of things like a "timer". Consider a very typical scenario: the initialization program sets the memory-mapped register value of on-board (EVM) device and would wait for 10ms before issuing the next command. In order to do this we need a "timer".

    But how is "timer" implemented? There should be two ways possible:

    1. By software
      1. By a library routine
      2. By OS
    2. By hardware timer

     

    The analogy is that if we intend to use a ticking device to count time, we need to know the time period for a single tick. So if the software (library routine or OS) is charged with the task, it needs to first translate "10ms" into number of clock ticks by dividing 10ms with the tick period. Therefore, this information must be somehow provided.

    Another candidate is a hardware timer, but the principle remains the same: the hardware must know precisely how long a single tick is.

    But can software or the hardware(chip) know this without external information? The PLL multiplication factor should be visible to both the software and hardware (read the register or query the PLL for that), but there is no way for them to know the external reference crystal oscillator rate. It is just like if the period of earth's rotation around the sun changes, we might not be able to perceive it. So if the earth now speed up two times, the elapsed time of two days equals that of one in the past. This however, must be told by an observer out of the solar system.

    So are we the external observer here? Only we, not the hardware or software, could know the actual speed of the reference oscillator. So we must provide this information to the software/hardware, or else the timer (software or hardware) might not work properly.

    I found this could be a plausible explanation for why need to supply this the clock rate information in the RTSC platform configuration. Is this correct?

     

     

    Sincerely,

    Zheng

     

     

     

     

     

     

  • 0 in reply to Anonymous
    TI__Guru*** 125430 points

    Zheng Zhao said:
    So are we the external observer here? Only we, not the hardware or software, could know the actual speed of the reference oscillator. So we must provide this information to the software/hardware, or else the timer (software or hardware) might not work properly.

    Correct.

  • Anonymous
    0 Anonymous in reply to Brad Griffis

    Dear Brad,

    Could you have a look at this post Timer source difference on C6000, C5000 and AM1x? Filling in wrong clock rate information in the RTSC wizard might not necessaritly result in OS timing error, especially on DM6437.

     

    Zheng