07-28-2014 09:59 AM
Thanks in advance.
07-28-2014 02:14 PM
first of all thank you for fast response. Below I described what I have done so far.
1. I have added FMC board with hdmi in/out (Avnet DVI/IO) and have done video pass-through (mz_avnet_dvi_io) - works fine.
2. After that I have changed vtc configuration to detector/generator (to reproduce signals from camera, I needed vblank and hblank signals for osd as I recall) - works ok
3. I have connected xsvi stream from camera to third vdma - also works.
After this steps I wanted to add two axi4s to video out IP's after two VDMA cores becouse I have to connect my own video processing core which have three xsvi inputs (two vdma and one from camera) and two xsvi outputs (inputs must be synchronous - axi4s to video out IP in master mode).
08-06-2014 12:51 PM
Hmm okay. Well here are the things I usually check:
- Clocks, resets, and clock enables
- Make sure to generate BOTH syncs and blanks out of VTC and connect them to AXI Stream to Video Out
- When VDMA or TPG in the path, use master mode for the AXIS to Video Out and do not connect the gen_clken to vtg_ce
- Check for locked status of VTC and AXI Stream to Video Out
- VTC generator should run at pixel clock that vid_io_clk is connected to on AXI Stream to Video Out
- Probe VTIMING, AXIS, and video out interfaces on the AXI Stream to Video out core to make sure you are getting properly formatted data on all interfaces
08-25-2014 02:08 PM
You said do not connect gen_clken to vtg_ce when a VDMA is in the path. So, what do you do with that port. Should it always be enabled ? (tied high, when a VDMA in the path), that isn´t clear on the documentation.
08-27-2014 04:30 PM
08-27-2014 04:31 PM
08-27-2014 04:56 PM
Thanks for doing your research!
One thing that seems to be confusing most folks about the core is the two different modes: master and slave. The general rule of thumb for most applications is:
- Master mode
* Used if there is a VDMA in the design (or some other source that can accomodate arbitrary throttling on the AXIS interface)
* Do not connect the VTG_CE to gen_clken port. This will prevent locking. Just tie VTG_CE high
- Slave mode
* Used if there is no VDMA in the system or the system can not otherwise handle arbitrary throttling
* The assumption is generally that there is no clock crossing happening in the datapath
* In this mode, rather than throttling the AXIS interface, the AXI Stream to Video Out core 'throttles' the VTC generator by toggling the VTG_CE signal until they line upj
One other important assumption for either case: Your video output clock (on the Video Out to AXI Stream core) must be the correct output pixel clock rate! If your timing generator is generating 1080p60 video, your output clock (AND the clock that the VTC generator runs at) better be ~148.5MHz. Otherwise, you won't lock.
One last tip: for first bringup, just use the VTC generator in constant mode for the timing that you're testing. Once you bring up the system, you can add the AXI lite interface and add the ability to change the frame size or whatever. The reason I say that is because the VTC has a lot of registers to setup and a bit of a learning curve. Simplify by using constant mode for a standard frame size which will just work out of the box.
08-28-2014 02:48 PM
08-28-2014 04:57 PM
Hmm, okay. A few other things:
- Make sure your VDMA size and stride registers are correct. In particular, HSIZE and STRIDE are in bytes per line, not pixels
- Probe the timing interface out of the VTC (going to the AXI Stream to Video) and make sure both vsync and vblank are toggling
- Check clocks, resets, clock enables in the post-implementation schematic
- Try increasing the AXIS2Vid buffer depth
If you want to post some data (hardware core connections/configurations, register dumps, etc), I'll take a look