Actions
Forum Thread Details
  • State Not Answered
  • Replies 2 replies
  • Subscribers 273 subscribers
  • Views 271 views
  • Users 0 members are here
Related

Python 1300C reference designs with faster PLL clock?

Former Member

We've been adapting the Avnet Python 1300C HDMI / framebuffer reference design into a pure DMA design (no HDMI) and have run into a couple of questions -

- The Avnet design drives the Python PLL clock at 27MHz, much slower than the 72MHz called for in the Python data sheet. This significantly limits the frame rate as the PLL clock governs the per-frame readout time. The data sheet says 72MHz is required to achieve its rated frame rates (165fps @ 1280x1024), and doing the math on the frame reset_length bears this out.

Are there any reference designs that drive the Python PLL clock at 72MHz?


- When we set a ROI sub-window via Python registers, we're seeing frames partially corrupted. The corruption only happens when we set X bounds to something other than [0,1279]. (Y bounds work fine.)  The corruption gets worse the smaller the total width.  Below are two examples of a corrupted test pattern:

https://s3-us-west-1.amazonaws.com/pythonsamples/roi1264x1024.png
https://s3-us-west-1.amazonaws.com/pythonsamples/roi1200x1024.png

Any ideas what might be causing this?  I have combed through the data sheet and tried many settings but nothing changes it.


Thank you,

Nick

Parents
  • 0

    Hi there,

    I've asked our Video Specialist if he is aware of any other video designs with a faster clock.

    In the mean time, looking at your images my FIRST reaction is that you might be capturing a mismatch of pixels.  That is, if your are filling your buffers and are just packing bits, then are off by say 1 or more pixels, too many pixels will push you off in a positive rolling pattern similar to what you have screen captured and posted (thank you that was REALLY helpful to quickly see your issue).  Too few and the NEXT line ends up in the current line's buffer.

    It could also be clock alignment.  If the clocks are not timed at the correct placement in pixel read, you could also be causing this.  I think this less likely, but a possibility none the less.

    Do you have a way to bring the clocks out to a logic analyzer?  Or you could try using built in Vivado tools to try to see what is going on.

    --Dan

Reply
  • 0

    Hi there,

    I've asked our Video Specialist if he is aware of any other video designs with a faster clock.

    In the mean time, looking at your images my FIRST reaction is that you might be capturing a mismatch of pixels.  That is, if your are filling your buffers and are just packing bits, then are off by say 1 or more pixels, too many pixels will push you off in a positive rolling pattern similar to what you have screen captured and posted (thank you that was REALLY helpful to quickly see your issue).  Too few and the NEXT line ends up in the current line's buffer.

    It could also be clock alignment.  If the clocks are not timed at the correct placement in pixel read, you could also be causing this.  I think this less likely, but a possibility none the less.

    Do you have a way to bring the clocks out to a logic analyzer?  Or you could try using built in Vivado tools to try to see what is going on.

    --Dan

Children
No Data