UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Adventurer
Adventurer
461 Views
Registered: ‎05-04-2018

Artix 7 Nexys Video Clocking Wizard/MIG

Jump to solution

I am using Vivado 2019.2 with a Digilent Nexys Video board (https://reference.digilentinc.com/reference/programmable-logic/nexys-video/start).I have included my block diagram (first picture). I am dragging board components into the design to make sure I get the right pins (second picture).I am getting errors complaining about invalid sys_clk_i and mismatching reset polarity. (third picture)

 

The board has a 100 MHz oscillator that is attached to pin R4. I want this to drive a 74.25 MHz pixel clock for the Video IP as well as a 300 MHz sys_clk_i input clock for my MIG controller (MIG requires >= 200 MHz). How can I do this with Clocking Wizard in order to produce a valid clock for my MIG?

 

I also want to properly set up my reset polarity correctly. You can see that my reset port is active low (third picture), my Clocking Wizard is active low (fourth picture), and my MIG controller is active low (fifth picture). I do not have the slightest clue as to why Vivado throws this error. Is this a bug or am I missing something?

 

My last question may be solved via the first two, but how do I properly set my System Clock in my MIG controller? I selected Single Ended for my clock (fifth picture) and set R4 as the designated sys_clk_i (sixth picture). Should I be doing this? If I am to leave my MIG controller configured this way, then why is there an external input port for sys_clk_i? Shouldn't this be done internally? How would this actually provide >= 200 MHz if the oscillator is only 100 MHz?

0_Block_Diagram.png
1_Board Components.png
2_Active Low Error_Pin.png
Clocking Wizard.png
MIG Active Low.png
MIG sys_clk_i.png
0 Kudos
1 Solution

Accepted Solutions
Explorer
Explorer
219 Views
Registered: ‎07-18-2011

Re: Artix 7 Nexys Video Clocking Wizard/MIG

Jump to solution

@doverstreet6 

Before worrying about timing closure, you should fix the video path first, as it will likely change the timing results. 

Timing closure is an entire subject in itself, I suggest you read the Vivado manuals here:

https://www.xilinx.com/support/documentation-navigation/design-hubs/dh0006-vivado-design-analysis-and-timing-closure-hub.html

A couple of things I see:

(1) Your AXI4-Stream to Video Out IP block should have the active-high vid_io_reset pin connected to the proc_sys_reset_0 peripheral_reset pin, which is the reset associated with the 74.25MHz clock on the vid_io_out_clk pin.    The aresetn pin should be connected to the peripheral_aresetn pin of the rst_mig_7_eries_0_100M IP, which is the reset block associated with the 100MHz axi clock on the aclk pin.   All resets should come from their associated clock reset IP.

(2) Your AXI4-Stream to Video Out IP block should be configured for slave mode, and the vtg_ce pin should be connected to the Video Timing Controller gen_clken pin.   Carefully read PG044, the product guide for the AXI4-Stream to Video Out IP, in particular, slave mode operation as described on page 21.

(3) Don't worry about the underflow and overflow pins, you should instead be monitoring the locked pin.   It will tell you if the AXI4-Stream to Video Out has locked onto a proper AXI video stream input.   It is an active-high output, which you can either monitor on an LED or by reading an input pin of an AXI GPIO IP block using your MicroBlaze code.     If locked doesn't go high, you either have the VTC timing set wrong, the TPG configured incorrectly, or the AXI4-Stream to Video Out IP configured incorrectly.  

Getting locked to go high is the first step in debugging a video project output. It is important to learn the workings of these three IP blocks, so carefully read the product guides associated with each of them.   There are registers you can read in the AXI4-Stream to Video Out IP to tell you what is wrong if locked doesn't go high, but after working with the IP a bit, it is usually fairly easy to spot the issue just by reviewing the setup of the TPG, VTC, and AXI4-Stream to Video Out blocks.   Things to watch out for: Make sure you have the pixels per clock correct, make sure your active pixels and lines in the TPG match the active pixels and lines in the VTC, make sure your clocks and resets are all correct.

(4) For debug, you can use the ILA IP block to view signals in Vivado.   This IP block is a logic analyzer that can be configured to view internal signals in the Vivado Hardware Manager.  It stores states and transitions in block ram after a trigger, and allows you to view them to verify correct operation.   There is also a VIO IP block, which is a virtual IO that has inputs and outputs that can be used to set or read pins on IP blocks.  You could, for instance, connect a VIO input to your locked output signal and see if it goes high.  Alternately, you could configure an ILA to view the state of the locked pin to see when it goes high in relation to the reset.

(5) At a minimum, you should have a clock period constraint in your constraints file.  It should look something like this if your 100MHz external system clock is on pin R4:

set_property -dict {PACKAGE_PIN R4 IOSTANDARD LVCMOS33} [get_ports sys_clk]
create_clock -period 10.000 -name sys_clk -waveform {0.000 5.000} -add [get_ports sys_clk]

(6) That CLOCK_DEDICATED_ROUTE BACKBONE statement scares me a bit.  Make sure you're not hiding a critical clock routing warning that should instead be fixed in the hardware.

 

View solution in original post

5 Replies
Mentor watari
Mentor
427 Views
Registered: ‎06-16-2013

Re: Artix 7 Nexys Video Clocking Wizard/MIG

Jump to solution

Hi @doverstreet6 

 

>The board has a 100 MHz oscillator that is attached to pin R4. I want this to drive a 74.25 MHz pixel clock for the Video IP as well as a 300 MHz sys_clk_i input clock for my MIG controller (MIG requires >= 200 MHz). How can I do this with Clocking Wizard in order to produce a valid clock for my MIG?

 

Would you use two MMCMs to generate pixel clock and MIG clock ?

In this case, you conisder toletant of clock frequency, if you use one MMCM.

 

Best regards,

0 Kudos
Adventurer
Adventurer
369 Views
Registered: ‎05-04-2018

Re: Artix 7 Nexys Video Clocking Wizard/MIG

Jump to solution

@watari 

 

I am having the same error as this post: https://forums.xilinx.com/t5/Implementation/Place-30-575-Sub-optimal-placement-for-a-clock-capable-IO-pin/td-p/978904

 

I added the set_property CLOCK_DEDICATED_ROUTE BACKBONE [get_nets design_1_i/clk_wiz1/inst/clk_in1_design_1_clk_wiz_1] line to "ignore" the error. This allowed me to generate bitstream, but I want to make my system properly. Could you look at my implementation and see which constraints are the problem? I have highhighted the MMCMs that are used. It looks like maybe there is no way around having them split. The two lone MMCMs are system clock and USB-UART.

 

 

Selection_001.png
0 Kudos
Highlighted
Explorer
Explorer
335 Views
Registered: ‎07-18-2011

Re: Artix 7 Nexys Video Clocking Wizard/MIG

Jump to solution

@doverstreet6 

Let me tell you the way I would approach the clocking, it may help. 

There are many ways you can do this, I find this the easiest, but don't take it as the only way, there are sometimes reasons you would need to do it another way.

When starting a project, do the following steps:

(1) Create a project for the specific device you are using and create a new block diagram

(2) Go to the settings icon in the upper right corner of the bd and enable pin tieoffs

(3) Right-click and go to the IP setting and add any custom IP repositories you may have, such as the Nexys Video IP directory

(4) Add any constraints files or board files you may need for the design

(5) Place an instance of the MIG IP

(6) Double-click the MIG and configure it for your application.   In the case of the Nexys Video board, you would configure it for DDR3, with a clock period of 2500ps (400MHz) using a 16-bit DDR datawidth and 1.5V memory voltage.   On the Memory options page of the MIG setup, select an input clock period of 10000pS (100MHz) to match the oscillator used on the Nexys Video card.

(7) Check the Select Addtional Clocks box and add a 100MHz clock for Clock0 (used for general-purpose clocking as you will see further down), a 200MHz clock for Clock1 (used for MIG ref), a 200MHz clock for Clock2 (used for iodelay timing refs if you have any, otherwise not connected), and any addtional general purpose clocks you may want, such as a 12MHz clock for low-speed stuff, like blinking LEDs and PWM controllers that don't need to waste power running at 100MHz.

(8) Disable the Controller Chip Select Pin to free up a pin

(9) On the System Clock page, select Single-Ended for the Nexys Video card, or Differential if you have a differential system clock (recommended)

(10) Select No Buffer for Reference clock

(11) Select Internal Vref to free up 2 more pins

(12) Assign your DDR pinout, verify, assign the clock pin, and exit

(13) Connect the MIG clk_ref_i pin to ui_addn_clk1 (200MHz clock ref for MIG)

(14) Right-click the DDR3 pin and make it external

(15) Right-click the sys_clk_i and sys_rst pins and make them external, then select the ports and change the name to match the name used in your constraints file

(16) Place a MicroBlaze IP instance, connect the Clk pin to the ui_clk pin of the MIG

(17) Click Run Block Automation and set Local Memory for whatever you need (I typically use 32k when running out of BRAM or 8k when running out of DDR3), and select OK

(18) Add an  AXI UARTlite IP for a debug UART, right click the UART pin and make it external.  Double-click the IP block to set the desired baud rate (I typically use 115,200 for debug).

(19) Run Connection Automation again and select the S_AXI box under axi_uartlite_0,  and the S_AXI box under mig_7_series_0, then select OK

(20) Right-click on the block diagram name in the Sources Window to the left, and select Create HDL Wrapper. and let Vivado manage it.

(21) Check your constraints file names to make sure they match the port names on your block diagram.  If in doubt, open the wrapper file to see the names Vivado assigned to the ports.

 

At this point, you will have a complete design that can run the simple "Hello World" app in SDK.  Validate the design (F6), generate the bitstream, export the hardware, and generate an SDK "Hello, World" app to test the functionality before adding anything else to the design.

 

MIG_test1.jpg

 

Once you have that working, start adding your other project IP.  For video projects, I like to start at the back and work towards the front, so I can incrementally test each stage or group of IP blocks to make sure they work before the design gets too complex.  Use the test pattern generator at each stage to test for a valid output image.  If you try to add everything to the block diagram first, and it doesn't work, you'll be stuck staring at a design with no idea where to start debugging.

In your case, I would add a Clocking Wizard IP block next.  Double-click to configure it, select the source as global buffer, set the clock frequency to 74.25MHz, name it clk_74r25 and select Active Low reset.  Connect the clk_in_1 pin to the 100MHz ui_addn_clk_0 pin you created on the MIG, and connect the clock active-low resetn pin to the perpheral aresetn pin of the mig Processor System Reset that was created in block automation.  This will insure the clock is held in reset until the MIG starts up.

Add a new Processor System Reset IP block and connect the slowest_sync_clk pin to the 74.25MHz clock output you created., the dcm_locked pin to the locked output of the clocking IP, and the ext_reset_in pin to the same external reset port you have the MIG sys_rst connected to  

Now you have a 74.25MHz clock and a reset block that has both active-high and active-low resets that can be used for your video IP running off the clk_74r25 clock.  

If you need to create additional clocks, you can either add them to the 74.25MHz clock IP, since it can have multiple outputs, or better yet, add another clocking IP block and reset IP, because you will probably want the 74.25MHz clock to be dynamically reconfigurable using the AXI4 Lite bus.   There are routing rules for concatenating PLL and MMCM blocks that you may run into, so plan your clocking carefully.

Use the 100MHz MIG ui_clk for all your AXI bus clocks, and the clk_74r25 clock from the clocking IP for your video clocks, along with the corresponding resets.

 

MIG_test2.jpg

 

There you have it, an easy way to generate system clocks and resets. 

As I mentioned, there are other ways.  For instance, you could do as the Nexys Video board does and run the external clock directly into a clocking IP block and run the MIG off that, but I prefer using the MIG as the main controller, so the MIG is running directly off the external low-jitter clock oscillator source and everything gets reset and started after the MIG configures.

Resets are very important, don't skimp on them, add Processor System Reset IP blocks as needed for any clocks you use.

Try to run all your AXI bus off of a single clock, this will reduce resources, as you will not need clock crossing FIFOs and multiple clock routing.  Only convert to the video in or out clock domains at the AXI-Stream to Video in and out IP. blocks.  Keep everything synchronous to the clock domains.

Adventurer
Adventurer
278 Views
Registered: ‎05-04-2018

Re: Artix 7 Nexys Video Clocking Wizard/MIG

Jump to solution

@reaiken 

 

Thank you so much for your detailed instructions. I believe I have implemented them and was able to generate bitstream and have my Microblaze print out "Hello World". My only error was that I failed timing and I would appreciate your insight in identifying why the timing has failed.

 

I then tried running the code from video 23 in the video series and I do not see any output on my monitor.  I have underflow/overflow attached to LEDs and neither light up. Underflow does occur when I use the reset button, so it's at least responsive.

 

Do you have any recommendations or getting started guides for running simulation using a Microblaze? I would like to debug this in Vivado prior to using my board. I believe this will save me a decent bit of time. I will share my constraints, SDK code, block diagram, and error codes. If you can point me to the clocking solution in particular and guides/tips for simulation with Microblaze I'd greatly appreciate it.

 

 

 

#include <stdio.h>
#include "platform.h"
#include "xil_printf.h"

#include "xv_tpg.h"

XV_tpg tpg_inst;
XV_tpg_Config *tpg_config;

int main()
{
int Status;
init_platform();

print("Hello World\n\r");

Status = XV_tpg_Initialize(&tpg_inst, XPAR_V_TPG_0_DEVICE_ID);
if(Status!= XST_SUCCESS)
{
xil_printf("TPG configuration failed\r\n");
return(XST_FAILURE);
}

// Set Resolution to 1680x1050
//XV_tpg_Set_height(&tpg_inst, 600);
XV_tpg_Set_height(&tpg_inst, 1050);
//XV_tpg_Set_width(&tpg_inst, 800);
XV_tpg_Set_width(&tpg_inst, 1680);


// Set Color Space to RGB
XV_tpg_Set_colorFormat(&tpg_inst, 0x0);

// Change the pattern to color bar
XV_tpg_Set_bckgndId(&tpg_inst, XTPG_BKGND_COLOR_BARS);

//Start the TPG
XV_tpg_EnableAutoRestart(&tpg_inst);
XV_tpg_Start(&tpg_inst);
xil_printf("TPG started!\r\n");

cleanup_platform();
return 0;
}

 

 

 

 

set_property CONFIG_VOLTAGE 3.3 [current_design]
set_property CFGBVS VCCO [current_design]

set_property PACKAGE_PIN R3 [get_ports {TX_Enable[0]}]
set_property IOSTANDARD LVCMOS33 [get_ports {TX_Enable[0]}]
set_property PACKAGE_PIN AB3 [get_ports {hdmi_out_data_p[2]}]
set_property PACKAGE_PIN AA1 [get_ports {hdmi_out_data_p[1]}]
set_property PACKAGE_PIN W1 [get_ports {hdmi_out_data_p[0]}]
set_property PACKAGE_PIN T1 [get_ports hdmi_out_clk_p]

set_property PACKAGE_PIN T14 [get_ports led0]
set_property IOSTANDARD LVCMOS25 [get_ports led0]
set_property PACKAGE_PIN T15 [get_ports led1]
set_property IOSTANDARD LVCMOS25 [get_ports led1]
set_property PACKAGE_PIN T16 [get_ports led2]
set_property IOSTANDARD LVCMOS25 [get_ports led2]
set_property PACKAGE_PIN U16 [get_ports led3]
set_property IOSTANDARD LVCMOS25 [get_ports led3]
set_property PACKAGE_PIN V15 [get_ports led4]
set_property IOSTANDARD LVCMOS25 [get_ports led4]
set_property PACKAGE_PIN W16 [get_ports led5]
set_property IOSTANDARD LVCMOS25 [get_ports led5]

#set_property CLOCK_DEDICATED_ROUTE BACKBONE [get_nets design_1_i/clk_wiz1/inst/clk_in1_design_1_clk_wiz_1]

set_property IOSTANDARD LVCMOS33 [get_ports sys_clock]

New Block Design.png
Timing Errors.png
Timing Errors 2.png
Timing Errors 3.png
0 Kudos
Explorer
Explorer
220 Views
Registered: ‎07-18-2011

Re: Artix 7 Nexys Video Clocking Wizard/MIG

Jump to solution

@doverstreet6 

Before worrying about timing closure, you should fix the video path first, as it will likely change the timing results. 

Timing closure is an entire subject in itself, I suggest you read the Vivado manuals here:

https://www.xilinx.com/support/documentation-navigation/design-hubs/dh0006-vivado-design-analysis-and-timing-closure-hub.html

A couple of things I see:

(1) Your AXI4-Stream to Video Out IP block should have the active-high vid_io_reset pin connected to the proc_sys_reset_0 peripheral_reset pin, which is the reset associated with the 74.25MHz clock on the vid_io_out_clk pin.    The aresetn pin should be connected to the peripheral_aresetn pin of the rst_mig_7_eries_0_100M IP, which is the reset block associated with the 100MHz axi clock on the aclk pin.   All resets should come from their associated clock reset IP.

(2) Your AXI4-Stream to Video Out IP block should be configured for slave mode, and the vtg_ce pin should be connected to the Video Timing Controller gen_clken pin.   Carefully read PG044, the product guide for the AXI4-Stream to Video Out IP, in particular, slave mode operation as described on page 21.

(3) Don't worry about the underflow and overflow pins, you should instead be monitoring the locked pin.   It will tell you if the AXI4-Stream to Video Out has locked onto a proper AXI video stream input.   It is an active-high output, which you can either monitor on an LED or by reading an input pin of an AXI GPIO IP block using your MicroBlaze code.     If locked doesn't go high, you either have the VTC timing set wrong, the TPG configured incorrectly, or the AXI4-Stream to Video Out IP configured incorrectly.  

Getting locked to go high is the first step in debugging a video project output. It is important to learn the workings of these three IP blocks, so carefully read the product guides associated with each of them.   There are registers you can read in the AXI4-Stream to Video Out IP to tell you what is wrong if locked doesn't go high, but after working with the IP a bit, it is usually fairly easy to spot the issue just by reviewing the setup of the TPG, VTC, and AXI4-Stream to Video Out blocks.   Things to watch out for: Make sure you have the pixels per clock correct, make sure your active pixels and lines in the TPG match the active pixels and lines in the VTC, make sure your clocks and resets are all correct.

(4) For debug, you can use the ILA IP block to view signals in Vivado.   This IP block is a logic analyzer that can be configured to view internal signals in the Vivado Hardware Manager.  It stores states and transitions in block ram after a trigger, and allows you to view them to verify correct operation.   There is also a VIO IP block, which is a virtual IO that has inputs and outputs that can be used to set or read pins on IP blocks.  You could, for instance, connect a VIO input to your locked output signal and see if it goes high.  Alternately, you could configure an ILA to view the state of the locked pin to see when it goes high in relation to the reset.

(5) At a minimum, you should have a clock period constraint in your constraints file.  It should look something like this if your 100MHz external system clock is on pin R4:

set_property -dict {PACKAGE_PIN R4 IOSTANDARD LVCMOS33} [get_ports sys_clk]
create_clock -period 10.000 -name sys_clk -waveform {0.000 5.000} -add [get_ports sys_clk]

(6) That CLOCK_DEDICATED_ROUTE BACKBONE statement scares me a bit.  Make sure you're not hiding a critical clock routing warning that should instead be fixed in the hardware.

 

View solution in original post