Sorry, you need to enable JavaScript to visit this website.

Running a ON Python 1300 Module with different parameters

4 posts / 0 new
masc's picture
Running a ON Python 1300 Module with different parameters

Dear Python developers, dear Alberta/Mario!

We're trying to get a ON Python 1300 module up and running on a microZed board with avnet provided onsemi_python_cam cores and provided bare metal software (from

Reference Design works.

Due to the hardware restrictions in our future product design we would like to run the following configuration, which differs in some central parameters from the reference implementation and onsemi core configuration:
- only 1 instead of 4 LVDS data channels (because we would like to use a cable to transfer the data, therefore a low count of pairs is desired)
- 10bit instead of 8bit pixels
- external LVDS clock instead of external PLL clock (also, because we would like to use a cable)
- just bw image instead of color (not important)
- also we would like to use binning and e.g. SVGA resolution (I think only relevant for bandwidth usage)

Quick calc: 1 LVDS DDR data channel at 135MHz can transfer 27 mega 10b-pixel per second; this results in around 28fps. Good enough.

In the first run we didn't used the onsemi cores at all and designed all ourselves. But we can't get the deserialization stable. Therefore we decided to give the onsemi cores a chance.

Unfortunately this core is hardcoded to use 4 LVDS channels (especially in deserialization section).
I tried to reduce the core (hard coded) to use only one LVDS channel - but to be honest, i haven't fully understood the design architecture (especially deserialization), also my "mother tongue" is Verilog not VHDL. I essence: I'm not aware of the pitfalls while trying this.

Besides the adaption of the onsemi core, another problem is the content of the initialization sequences and configuration registers which of course also have to be altered for 1 LVDS data channel usage (reg 32 and 211?)

Has anybody done something similar to this and can give me some hints. What are the main pitfalls while deserialize the python output? Or rather the adaption of the onsemi core to the above mentioned parameters?

Work done so far (with the onsemi cores):
- changed component.xml to allow 1 LVDS data channel
- altered mainly onsemi_vita_cam_core.vhd to only use 1 LVDS data channel (best effort, don't understand the internals fully)
- setup bare metal SDK, talking to the cores and talking to python works.
- altered register uploads to use 1 LVDS channel
- unfortunately iserdes alignment fails.

Note: with my own implementation of alignment and bitslip I've seen already decoded sync channel bits and  incrementing data channel bits on my scope from the python in testpattern mode. But this seems to work only at random, it's not stable. After some powercycle it works, sometimes not...

Any help appreciated. Thanks a lot!

Bye, Marc.

AlbertaBeef's picture
Bypass the output FIFO


This sounds like excellent work !

You are correct, the core and reference design have not been implemented for a one channel implementation.

There are some portions in place that you can use.


      C_DIRECT_OUTPUT : set this to false to bypass the demux_fifo which combines the four channels into a single pixel stream


      you will not need the vita_clk_div BUFR, since you will not be re-generating the pixel stream 4x faster than the 4 parallel data channels

Hope this helps !



LulaNord's picture
Hi...i am a new user here. I

Hi...i am a new user here. I am trying to port Microzed ref design using Python and HDMI on SVDK running on Vivado 2015.2 instead of 2014.4.
I now get an image from the Sensor of HDMI but it contains artifacts. When using test pattern generator I don't get any artifacts. Those artifact are vertical repetition every centimeters of around 6 to 8 pixels width random pixel colors.

vanmierlo's picture
Artifact vertical lines

We are also experiencing the vertical line artifacts. Does anyone know where they come from and how to fix them?