Cmod A7-35T Missing CFGBVS and CONFIG_VOLTAGE Design Properties

[BYTEMAN]

Dear All,

I need to use inside the FPGA the 12 MHz clock, hence I've uncommented this two rows on the XCF file provided by Digilent.

## 12 MHz Clock Signal
set_property -dict { PACKAGE_PIN L17   IOSTANDARD LVCMOS33 } [get_ports { sysclk }]; #IO_L12P_T1_MRCC_14 Sch=gclk
create_clock -add -name sys_clk_pin -period 83.33 -waveform {0 41.66} [get_ports {sysclk}];

after that I've did the sysnthesis, my VHDL code is the following one:

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;

entity led is
    Port ( btn : in STD_LOGIC_VECTOR(1 downto 0);
           led : buffer  STD_LOGIC_VECTOR(1 downto 0);
           sysclk : in std_logic    -- system clock 12 MHz
           );
end led;

architecture Beh_arch of led is
    signal btn0s : std_logic;
    signal btn1s : std_logic;
    signal led0 : std_logic;
    signal led1 : std_logic;
begin

    -- button clock synchr
    synch_input : process (sysclk)
    begin
         if sysclk'event and sysclk = '1' then
            btn0s <= btn(0);
            btn1s <= btn(1);
         end if;
    end process synch_input;

    -- led toggle with the button
    synch_toggle_leds : process (sysclk)
    begin
        if sysclk'event and sysclk = '1' then
        
            if btn0s = '1' then
                led0 <= not led(0);
            end if;
            
            if btn1s = '1' then
                led1 <= not led(1);
            end if;
            
            led(0) <= led0;
            led(1) <= led1;
            
        end if;
    end process synch_toggle_leds;
    
end Beh_arch;

what I try to do is a simple toggle of the led when the button is pressed, countinuosly toggling at the clock frequency.

All the process going straight but on the final report I see a warning:

[DRC 23-20] Rule violation (CFGBVS-1) Missing CFGBVS and CONFIG_VOLTAGE Design Properties - Neither the CFGBVS nor CONFIG_VOLTAGE voltage property is set in the current_design.  Configuration bank voltage select (CFGBVS) must be set to VCCO or GND, and CONFIG_VOLTAGE must be set to the correct configuration voltage, in order to determine the I/O voltage support for the pins in bank 0.  It is suggested to specify these either using the 'Edit Device Properties' function in the GUI or directly in the XDC file using the following syntax:

 set_property CFGBVS value1 [current_design]
 #where value1 is either VCCO or GND

 set_property CONFIG_VOLTAGE value2 [current_design]
 #where value2 is the voltage provided to configuration bank 0

Refer to the device configuration user guide for more information.

I've did some search and I found this:

https://www.xilinx.com/support/answers/55660.html

someone could you please give me some other explanation? What should be the exact settings to use for this board:

- Configuration voltage: 1.5 / 1.8 / 2.5 / 3.3

- Configuration bank voltage selection: GND or VCCIO

where I can found this specification for the FPGA used? Datasheet I think but what parameters?

----

I've noticed the last row "Refer to the device configuration user guide for more information" then found the UG470 (v1.12)  at page 21 and 24 Table 2-4 there are some infos.

Searching for the pin-label file give me ()

V9 and G12 -> VCCO_0

V11 -> CFGBVS_0

After that searching on the electrical schematic give me:

3.3 V VCCO_0 (page 4/7)

3.3 V CFGBVS_0 (page 2/7)

Then following these data, the correct settings should be as into the attached figure (select first the Syntesis tab into the left side of the Vivado main window then into the main Vivado menu bar select Tools tab and finally the Edit Device Properties menu). After that the warning disappear and the board is also running correctly as before the warning :).

Someone can confirm?

Thanks!

Best regards

 

 

[BYTEMAN]

6 hours ago, xc6lx45 said:

PS: If this is true, my proposal

>> If you measure jitter anyway, you could route the 12M output to one pin and check that one, too.

would have caused the same issue...

Thank you, I've found the bug, in my XDC constraints I've did a typo error the correct cosntraints are the following one:

set_property -dict {PACKAGE_PIN L17 IOSTANDARD LVCMOS33} [get_ports sysclk]
create_clock -period 83.330 -name sys_clk_pin -waveform {0.000 41.660} -add [get_ports sysclk]

I wrote a period of 10 then assumed a clock of 100 MHz instead the correct one of 12 MHz.

Now after fixing this issue I've only one critical warning:

[Synth 8-4442] BlackBox module clk_div_inst has unconnected pin reset

correct because I left the reset pin of the MMCM module (used to generate the 100 MHz internal clock from the external 12 MHz) not connected, I've to fix it to 0 or to put it at global reset and in this latter case how do this?

The others non critical warning are reported below:
----------

synth_1        
"open_run impl_1"        
Opt 31-35    Warning    "Removing redundant IBUF, clk_div_inst/inst/clkin1_ibufg, from the path connected to top-level port: sysclk
Resolution: The tool has removed redundant IBUF. To resolve this warning, check for redundant IBUF in the input design."
Kindly let me know what I've to check inside my VHDL code, I've not inferred any buffer directly, the only one (I suppose) was specified into the XDC file (please see above) then I don't know what action I've to do in order to avoid this warning.

Implementation        
Design Initialization  

Constraints 18-550    Warning    "Could not create 'IBUF_LOW_PWR' constraint because net 'clk_div_inst/clk_in1' is not directly connected to top level port. 'IBUF_LOW_PWR' is ignored by Vivado but preserved for implementation tool."
I don't understand this message, the input of the MMCM module is directly connected to the sysclk net that is directly connected to the output of the IBUF at the pin L17 (GCLK on the board schematic), someone can explain it to me in a more details (my VHDL source code is written at the bottom of this post).

Opt Design        

Opt 31-6    Warning    "Deleting driverless net: clk_div_inst/inst/reset."
Opt 31-6    Warning    "Deleting driverless net: clk_div_inst/reset."

This is clear because the tool have deleted the net related to the reset input of the MMCM because I've not connected it.

Place Design        
DRC 23-20    Warning    "Rule violation (CKLD-2) Clock Net has IO Driver, not a Clock Buf, and/or non-Clock loads - Clock net sysclk_IBUF is directly driven by an IO rather than a Clock Buffer or may be an IO driving a mix of Clock Buffer and non-Clock loads. This connectivity should be reviewed and corrected as appropriate. Driver(s): sysclk_IBUF_inst/O"
About this warning I suppose that I've to put a IBUFG buffer on the pin L17 of my FPGA and connect the output of this buffer to the input of the MMCM module, I've correctly understand? Kindly let me know if this shall be do into the VHDL source code or into the XDC file or if this can be in either place what should be the best place to do it.

impl_1        
"current_design impl_1"        
Constraints 18-550    Warning    "Could not create 'IBUF_LOW_PWR' constraint because net 'clk_div_inst/clk_in1' is not directly connected to top level port. 'IBUF_LOW_PWR' is ignored by Vivado but preserved for implementation tool."
Related to the same above into the implementation section.

----------

From the Implementation timing summary I see:

I suppose that to fix it I've to insert other constraints into the XDC file.

Here below the full VHDL code implemented for this design.

----------------------------------------------------------------------------------
-- VHDL LED example
-- use of the MMCM clock module
----------------------------------------------------------------------------------

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use ieee.numeric_std.all; 

entity led is
    Port ( btn : in STD_LOGIC_VECTOR(1 downto 0);
           led : buffer  STD_LOGIC_VECTOR(1 downto 0);
           sysclk : in std_logic    -- system clock 12 MHz
           );
end led;

-- Arch definition
architecture Beh_arch of led is

-- (IP CLOCKING WIZARD) definition of the MMCM clocking module (100 MHz from 12 MHz)
component clk_wiz_0
port
    (
    clk_in1  : in  std_logic;  -- Clock in ports
    clk_out1 : out std_logic   -- Clock out ports
    );
end component;

    -- Internal signal declaratons
    signal cnt_clk : std_logic; -- 100 MHz clock signal
    
    signal btn0s : std_logic;
    signal btn1s : std_logic;
    signal led0 : std_logic := '0';
    signal led1 : std_logic := '0';
    signal count : std_logic_vector(31 downto 0) := X"00000000";
      
begin
    -- IP clock instance
    clk_div_inst : clk_wiz_0
        port map
        (
        clk_in1 => sysclk,  -- Clock in ports (12 MHz)
        clk_out1 => cnt_clk -- Clock out ports (100 MHz)
        ); 
    
    -- synch the button input signal with the 12 MHz clock
    synch_btn : process(sysclk)
    begin
        if sysclk'event and sysclk = '1' then
            btn0s <= btn(0);
            btn1s <= btn(1);
        end if;
    end process synch_btn;
    
    -- 32-bit counter to obtain a led1 blinking every 1s
    led0_blink : process(cnt_clk)
    begin
        if cnt_clk'event and cnt_clk = '1' then
            count <= std_logic_vector(unsigned(count) + 1);
            if (unsigned(count) >= to_unsigned(100000000, count'length)) then
                 led0 <= not led(0);
                 count <= (others=>'0');
            end if;
        end if;
    end process led0_blink;
    
    -- led1 output update on btn1 toggle
    synch_toggle_led1 : process (sysclk)
    begin
        if sysclk'event and sysclk = '1' then
            if btn(1) = '1' then
                led1 <= not led(1);
            end if;
        end if;
    end process synch_toggle_led1;
    
    -- outputs update
    led(0) <= led0;
    led(1) <= led1;
    
end Beh_arch;

Thank to anyone have time to answer these questions.

Best regards

[BYTEMAN]

After some testing I've found a set of constraints able to solve all the time constraints warning and violations here below summarized:

set_input_delay -clock [get_clocks sysclk] -min 1.000 [get_ports {{btn[0]} {btn[1]}}]
set_input_delay -clock [get_clocks sysclk] -max 3.000 [get_ports {{btn[0]} {btn[1]}}]

set_output_delay -clock [get_clocks sysclk] 2.000 [get_ports {led[1]}]

set_output_delay -clock [get_clocks [get_clocks -of_objects [get_pins clk_div_inst/inst/mmcm_adv_inst/CLKOUT0]]] -max -5.000 [get_ports {led[0]}]
set_output_delay -clock [get_clocks [get_clocks -of_objects [get_pins clk_div_inst/inst/mmcm_adv_inst/CLKOUT0]]] -min -1.000 [get_ports {led[0]}]

Also in attachment the VHDL code and the XDC file.

On the subject I've written a tutorial, a summary of this first try with this board and VIVADO suite, please check it and if you look some errors let me know, hope this can help.

LINK TO THE FORUM TUTORIAL

Best regards

 

Cmod-A7-Master.xdc

led.vhd

[xc6lx45]

Most likely you can false_path them. See this article (I guess the same applies to inputs and outputs).

Doing this I get a methodology warning. Which makes me feel guilty. For a while

[BYTEMAN]

19 hours ago, xc6lx45 said:

 

>> Tthen I've to remove this constraint row from my XDC?

(yes, this line).

 

Thank @xc6lx45 I've understand, the system take implicit constraints that came from the MMCM module and that is not directly written into the XDC file here is the reason because I've to comment the clock constraints into the XDC file, doing that the warning disappear!

Now I've the last think to fix, the input delay is ok, but about the output delay I've some violation I've to investigate...

Best regards

 

[BYTEMAN]

13 hours ago, xc6lx45 said:

Do you maybe use a different Vivado version than I do (2017.4 here)? ..

I'm currently working with VIVADO 2016.1 release.

Best regards

[JColvin]

Hi @xc6lx45

I believe the board tab is part of the clocking wizard as per @BYTEMAN's earlier post here. The board warning I think may be due to not all the board files being loaded (like the Kintex-7 parts) in their version of Vivado, based on this other thread here.

Thanks,
JColvin

[xc6lx45]

Do you maybe use a different Vivado version than I do (2017.4 here)? I don't have the "Board" tab at all, maybe because I didn't include any CMOD A7-specific files for this project.
I'd comment it out in constraints

>> Tthen I've to remove this constraint row from my XDC?

(yes, this line).

If that doesn't help, create a new project from scratch based on the FPGA type (not any board setup file).

There is also an odd error message on the right behind your last screenshot... board_part file invalid?

[BYTEMAN]

7 minutes ago, xc6lx45 said:

Hi,

I'm 99 % certain that the problem is caused because you specify a clock twice: Once in the constraints file, once in the frequency setting of the clocking wizard.
Solution: remove the constraints for clock frequency on the input pin.

If you look closely, you'll see that the "Inter"-clock error ("from one clock to the other") relates to two clocks on the same signal, that is clk_out_2_clk_wiz_0 with a suffix that identifies the clock. In my understanding, this makes more sense when clocks are switched / gated (which you don't do).

The constraint is meaningless and creates an impossible situation for Vivado, which it tries to resolve at best effort. Screwing up the rest of the design => failure to close timing.

 

BTW, the setting in the clocking wizard that controls the auto-generated buffer is under the "Clocking options" tab (which is for some reason the 2nd one in your screenshot).
Section "Input clock information" Input clock: Primary. Change "Source" from "single ended clock capable" to "No buffer". This is taken from clocking wizard 5.4 on an Artix.

 

 

 

Hi @xc6lx45 thank for your answer.

Tthen I've to remove this constraint row from my XDC?

create_clock -period 83.330 -name sys_clk_pin -waveform {0.000 41.660} -add [get_ports sysclk]

can you confirm?

My input settings for the clocking wizard are correct?

Last, inside the clock wizard I'm not able to change the Source mode because this one is unselectable.

could you please let me know more?

Thanks!!

[xc6lx45]

Hi,

I'm 99 % certain that the problem is caused because you specify a clock twice: Once in the constraints file, once in the frequency setting of the clocking wizard.
Solution: remove the constraints for clock frequency on the input pin.

If you look closely, you'll see that the "Inter"-clock error ("from one clock to the other") relates to two clocks on the same signal, that is clk_out_2_clk_wiz_0 with a suffix that identifies the clock. In my understanding, this makes more sense when clocks are switched / gated (which you don't do).

The constraint is meaningless and creates an impossible situation for Vivado, which it tries to resolve at best effort. Screwing up the rest of the design => failure to close timing.

 

BTW, the setting in the clocking wizard that controls the auto-generated buffer is under the "Clocking options" tab (which is for some reason the 2nd one in your screenshot).
Section "Input clock information" Input clock: Primary. Change "Source" from "single ended clock capable" to "No buffer". This is taken from clocking wizard 5.4 on an Artix.

 

 

 

[BYTEMAN]

I've did another test to try to solve the warning TIMING-2 of my previous test. Now I've did a little change into the IP Clock configuration, I've changed the Board interface option to the sysclk that is the system clock came into the FPGA pin, I think that should connect directly the MMCM clock input  directly to the IBUF related the clock in the right way.

and also I've removed from my VHDL source the BUFG buffer (see the updated source into the following of this post).

Now after the synthesis and implementation my schematic looks like this one:

then the input clock is routed directly into the input clock of the MMCM module-

Here below the updated code used in this test:

----------------------------------------------------------------------------------
-- VHDL LED example
-- use of the MMCM clock module
----------------------------------------------------------------------------------

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use ieee.numeric_std.all; 

library unisim;
use unisim.vcomponents.all;

entity led is
    Port ( btn : in STD_LOGIC_VECTOR(1 downto 0);
           led : buffer  STD_LOGIC_VECTOR(1 downto 0);
           sysclk : in std_logic    -- system clock 12 MHz
           );
end led;

-- Arch definition
architecture Beh_arch of led is

-- Clock buffer between the IBUF and the MMCM clock input
component BUFG
port( I : in  std_logic;
      O : out std_logic
     );
end component;

-- (IP CLOCKING WIZARD) definition of the MMCM clocking module (100 MHz from 12 MHz)
component clk_wiz_0
port( clk_in1  : in  std_logic;  -- Clock in ports (12 MHz)
      clk_out1 : out std_logic;  -- Clock out 100 MHz
      clk_out2 : out std_logic  -- clock out 12 MHz
    );
end component;

    -- Internal signal declaratons
    signal cnt_clk : std_logic; -- 100 MHz clock signal frpm MMCM
    signal clk_sync : std_logic; -- 12 MHz clock signal from MMCM
    
    signal led0 : std_logic := '0';
    signal led1 : std_logic := '0';
    signal count : std_logic_vector(31 downto 0) := X"00000000";
    
    -- For BUFG -> MMCM connection
    signal dclk_BUFG    : std_logic;
      
begin

    -- Buffer between IBUF and the input clock of the MMCM
   -- BUFG_1: BUFG
   -- port map(I => sysclk, O => dclk_BUFG);

    -- IP clock instance
    clk_div_inst : clk_wiz_0
        port map
        (
        -- clk_in1 => dclk_BUFG,  -- Clock in ports (12 MHz)
        clk_in1 => sysclk,  -- Clock in ports (12 MHz)
        clk_out1 => cnt_clk, -- Clock out ports (100 MHz)
        clk_out2 => clk_sync -- clock used to synch the button inputs
        ); 
    
    -- led1 output update on buttons toggle
    synch_toggle_led1 : process (clk_sync)
    begin
        if clk_sync'event and clk_sync = '1' then
            if (btn(0) = '1' or btn(1) = '1') then
                led1 <= not led(1);
            end if;
        end if;
    end process synch_toggle_led1;
    
    -- 32-bit counter to obtain a led1 blinking every 1s
    led0_blink : process(cnt_clk)
    begin
        if cnt_clk'event and cnt_clk = '1' then
            count <= std_logic_vector(unsigned(count) + 1);
            if (unsigned(count) >= to_unsigned(100000000, count'length)) then
                 led0 <= not led(0);
                 count <= (others=>'0');
            end if;
        end if;
    end process led0_blink;
    
    -- outputs update
    led(0) <= led0;
    led(1) <= led1;
    
end Beh_arch;

but now the timing situation looks not good, I've got some violations that before isn't present...

 

pushing F4 on the Path87 I can see the following schematic:

the violation is due to (I suppose) the signal from the output of the led_i_1 (LUT3) and the data input of the led1_reg (FDRE) respect the clk_out2,

I've correctly understand?

Now the question is:

#1- is correct to connect the MMCM module directy to ths sysclk without a BUFG by means of the MMCM settings used?

#2- how resolve this timing violation? Could someone please point me on the right direction?

#3- is possible to have a design without any timing warning?

Thanks

 

 

[BYTEMAN]

I've did another little change as suggested @xc6lx45, now the output of BUFG is going straight on the input of the MMCM module and the MMCM generate both the 100 MHz and 12 MHz inside the FPGA, all the used clock are sourced than from the MMCM outputs.

Here below the modified VHDL code:

----------------------------------------------------------------------------------
-- VHDL LED example
-- use of the MMCM clock module
----------------------------------------------------------------------------------

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use ieee.numeric_std.all; 

library unisim;
use unisim.vcomponents.all;

entity led is
    Port ( btn : in STD_LOGIC_VECTOR(1 downto 0);
           led : buffer  STD_LOGIC_VECTOR(1 downto 0);
           sysclk : in std_logic    -- system clock 12 MHz
           );
end led;

-- Arch definition
architecture Beh_arch of led is

-- Clock buffer between the IBUF and the MMCM clock input
component BUFG
port( I : in  std_logic;
      O : out std_logic
     );
end component;

-- (IP CLOCKING WIZARD) definition of the MMCM clocking module (100 MHz from 12 MHz)
component clk_wiz_0
port( clk_in1  : in  std_logic;  -- Clock in ports (12 MHz)
      clk_out1 : out std_logic;  -- Clock out 100 MHz
      clk_out2 : out std_logic  -- clock out 12 MHz
    );
end component;

    -- Internal signal declaratons
    signal cnt_clk : std_logic; -- 100 MHz clock signal frpm MMCM
    signal clk_sync : std_logic; -- 12 MHz clock signal from MMCM
    
    signal led0 : std_logic := '0';
    signal led1 : std_logic := '0';
    signal count : std_logic_vector(31 downto 0) := X"00000000";
    
    -- For BUFG -> MMCM connection
    signal dclk_BUFG    : std_logic;
      
begin

    -- Buffer between IBUF and the input clock of the MMCM
    BUFG_1: BUFG
    port map(I => sysclk, O => dclk_BUFG);

    -- IP clock instance
    clk_div_inst : clk_wiz_0
        port map
        (
        clk_in1 => dclk_BUFG,  -- Clock in ports (12 MHz)
        clk_out1 => cnt_clk, -- Clock out ports (100 MHz)
        clk_out2 => clk_sync -- clock used to synch the button inputs
        ); 
    
    -- led1 output update on buttons toggle
    synch_toggle_led1 : process (clk_sync)
    begin
        if clk_sync'event and clk_sync = '1' then
            if (btn(0) = '1' or btn(1) = '1') then
                led1 <= not led(1);
            end if;
        end if;
    end process synch_toggle_led1;
    
    -- 32-bit counter to obtain a led1 blinking every 1s
    led0_blink : process(cnt_clk)
    begin
        if cnt_clk'event and cnt_clk = '1' then
            count <= std_logic_vector(unsigned(count) + 1);
            if (unsigned(count) >= to_unsigned(100000000, count'length)) then
                 led0 <= not led(0);
                 count <= (others=>'0');
            end if;
        end if;
    end process led0_blink;
    
    -- outputs update
    led(0) <= led0;
    led(1) <= led1;
    
end Beh_arch;

the schematics after the synthesis stage is reported below

Now about the warnings we have following ones:

the only warning to solve is about the input and output delay, these ones is basically a entry into the XDC file that I have to put.

About Methodology I've some warning here reported:

I would investigate a little around the TIMING-2 and TIMING-4 could you please share your thinking about?

Thanks!

Best regards

 

[xc6lx45]

I suspect things will make sense if you connect the clock input pin only to the MMCM's input, without other connections to the net.

Most likely, the IO can only drive a single clock-net buffer at the pin site, but you're trying to drive two. For that, the signal needs to go to the fabric => DRC 23-20 (theory!).

Note, if you're using default MMC settings, "clk_div_inst" will include its own clock buffer. This can be disabled on the first page of the clkWiz IP configuration page (bottom right corner).

If I had to measure jitter on the input clock per my own suggestion, the easiest way might be to simply build a 2nd bitstream
 

[BYTEMAN]

I think to have done a small step forward about the warning messages DRC 23-20.

DRC 23-20    Warning    "Rule violation (CKLD-2) Clock Net has IO Driver, not a Clock Buf, and/or non-Clock loads - Clock net sysclk_IBUF is directly driven by an IO rather than a Clock Buffer or may be an IO driving a mix of Clock Buffer and non-Clock loads. This connectivity should be reviewed and corrected as appropriate. Driver(s): sysclk_IBUF_inst/O"

I tried to insert a BUFG after the implicit IBUF that, I think, is inferred automatically by the tool, hence I've modified my VHDL source code as below:

----------------------------------------------------------------------------------
-- VHDL LED example
-- use of the MMCM clock module
----------------------------------------------------------------------------------

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use ieee.numeric_std.all; 

library unisim;
use unisim.vcomponents.all;

entity led is
    Port ( btn : in STD_LOGIC_VECTOR(1 downto 0);
           led : buffer  STD_LOGIC_VECTOR(1 downto 0);
           sysclk : in std_logic    -- system clock 12 MHz
           );
end led;

-- Arch definition
architecture Beh_arch of led is

-- Clock buffer between the IBUF and the MMCM clock input
component BUFG
port( I : in  std_logic;
      O : out std_logic
     );
end component;

-- (IP CLOCKING WIZARD) definition of the MMCM clocking module (100 MHz from 12 MHz)
component clk_wiz_0
port( clk_in1  : in  std_logic;  -- Clock in ports
      clk_out1 : out std_logic   -- Clock out ports
    );
end component;

    -- Internal signal declaratons
    signal cnt_clk : std_logic; -- 100 MHz clock signal
    
    signal btn0s : std_logic;
    signal btn1s : std_logic;
    signal led0 : std_logic := '0';
    signal led1 : std_logic := '0';
    signal count : std_logic_vector(31 downto 0) := X"00000000";
    
    -- For BUFG -> MMCM connection
    signal dclk_BUFG    : std_logic;
      
begin

    -- Buffer between IBUF and the input clock of the MMCM
    BUFG_1: BUFG
    port map(I => sysclk, O => dclk_BUFG);

    -- IP clock instance
    clk_div_inst : clk_wiz_0
        port map
        (
        clk_in1 => dclk_BUFG,  -- Clock in ports (12 MHz)
        clk_out1 => cnt_clk -- Clock out ports (100 MHz)
        ); 
    
    -- synch the button input signal with the 12 MHz clock
    synch_btn : process(sysclk)
    begin
        if sysclk'event and sysclk = '1' then
            btn0s <= btn(0);
            btn1s <= btn(1);
        end if;
    end process synch_btn;
    
    -- 32-bit counter to obtain a led1 blinking every 1s
    led0_blink : process(cnt_clk)
    begin
        if cnt_clk'event and cnt_clk = '1' then
            count <= std_logic_vector(unsigned(count) + 1);
            if (unsigned(count) >= to_unsigned(100000000, count'length)) then
                 led0 <= not led(0);
                 count <= (others=>'0');
            end if;
        end if;
    end process led0_blink;
    
    -- led1 output update on btn1 toggle
    synch_toggle_led1 : process (sysclk)
    begin
        if sysclk'event and sysclk = '1' then
            if btn(1) = '1' then
                led1 <= not led(1);
            end if;
        end if;
    end process synch_toggle_led1;
    
    -- outputs update
    led(0) <= led0;
    led(1) <= led1;
    
end Beh_arch;

From what I understand (correct me if I'm wrong) between the input clock (12 MHz) and the input clock of the MMCM module we have a BUFG_1 component (if I've correctly understand the IBUF, which is the buffer directly connected to the physical input pin of the FPGA, should be inferred automatically by the tool), now the schematic (F4) after the implementation stage looks like this one.

the BUFG_1 is the one forced from the VHDL statements the other one sysclk_IBUF_BUFG_inst was generated automatically by the tool.

Now I kindly ask if my approach is correct or not to solve the DRC 23-20 Warning issue or if I've missed some conceptual point.

Also to perform another check I did the Implementation->Report DRC and this one show nothing:

the DRC setting was the default ones.

Thanks to help me understanding.

Best regards

 

 

 

[xc6lx45]

PS: If this is true, my proposal

>> If you measure jitter anyway, you could route the 12M output to one pin and check that one, too.

would have caused the same issue...

[xc6lx45]

Hi,

I suspect (!) that this is caused because you have other logic on the source clock used for the MMCM block. This causes routing constraints which lead to the message (theory!)

Try to add an additional 12 MHz clock output from the MMCM block (it has up to 6 outputs with independent divider) and use that for the remaining logic, e.g. change this one:

synch_toggle_led1 : process (sysclk)

 

[BYTEMAN]

I've noticed at the end of the synthesis stage I've some warning about the clock:

Here the code:

----------------------------------------------------------------------------------
-- VHDL LED example
-- use of the MMCM clock module
----------------------------------------------------------------------------------

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use ieee.numeric_std.all; 

entity led is
    Port ( btn : in STD_LOGIC_VECTOR(1 downto 0);
           led : buffer  STD_LOGIC_VECTOR(1 downto 0);
           sysclk : in std_logic    -- system clock 12 MHz
           );
end led;

-- Arch definition
architecture Beh_arch of led is

-- (IP CLOCKING WIZARD) definition of the MMCM clocking module (100 MHz from 12 MHz)
component clk_wiz_0
port
    (
    clk_in1  : in  std_logic;  -- Clock in ports
    clk_out1 : out std_logic   -- Clock out ports
    );
end component;

    -- Internal signal declaratons
    signal cnt_clk : std_logic; -- segnale clock 100 MHz
    
    signal btn0s : std_logic;
    signal btn1s : std_logic;
    signal led0 : std_logic := '0';
    signal led1 : std_logic := '0';
    signal count : std_logic_vector(31 downto 0) := X"00000000";
      
begin
    -- IP clock instance
    clk_div_inst : clk_wiz_0
        port map
        (
        clk_in1 => sysclk,  -- Clock in ports (12 MHz)
        clk_out1 => cnt_clk -- Clock out ports (100 MHz)
        ); 
    
    -- synch the button input signal with the 12 MHz clock
    synch_btn : process(sysclk)
    begin
        if sysclk'event and sysclk = '1' then
            btn0s <= btn(0);
            btn1s <= btn(1);
        end if;
    end process synch_btn;
    
    -- 32-bit counter to obtain a led1 blinking every 1s
    led0_blink : process(cnt_clk)
    begin
        if cnt_clk'event and cnt_clk = '1' then
            count <= std_logic_vector(unsigned(count) + 1);
            if (unsigned(count) >= to_unsigned(100000000, count'length)) then
                 led0 <= not led(0);
                 count <= (others=>'0');
            end if;
        end if;
    end process led0_blink;
    
    -- led1 output update on btn1 toggle
    synch_toggle_led1 : process (sysclk)
    begin
        if sysclk'event and sysclk = '1' then
            if btn(1) = '1' then
                led1 <= not led(1);
            end if;
        end if;
    end process synch_toggle_led1;
    
    -- outputs update
    led(0) <= led0;
    led(1) <= led1;
    
end Beh_arch;

"CKLD #1 Clock net sysclk_IBUF is directly driven by an IO rather than a Clock Buffer or may be an IO driving a mix of Clock Buffer and non-Clock loads. This connectivity should be reviewed and corrected as appropriate. Driver(s): sysclk_IBUF_inst/O"

into the XDC I've:

set_property -dict {PACKAGE_PIN L17 IOSTANDARD LVCMOS33} [get_ports sysclk]
create_clock -period 10.000 -name sys_clk_pin -waveform {0.000 5.000} -add [get_ports sysclk]

But sysclk is the 12 MHz clock and I think the system should place automatically a clock buffer on this pin. I'm forgotting something into the XDC or in my HDL source code?

To be correct I've posted similar question also into the XILINX forum because I don't know if this is a topic strictly related to the VIVADO environment or HDL question (directive to use into my code that I've not specified), I don't like to perform multiple posts of same topic over different forums, but really I don't know if this is a generic HDL question or related to the specific tool I'm using, sorry for that, be patient!

Thank!

[xc6lx45]

If you measure jitter anyway, you could route the 12M output to one pin and check that one, too.

Those

set_property IOSTANDARD LVTTL [get_ports {yourOutput[*]}]
set_property DRIVE 24 [get_ports {yourOutput[*]}]
set_property SLEW FAST [get_ports {yourOutput[*]}]

might improve results (because a slow slope turns additive noise into jitter). The PMOD port has series resistors => bad choice.

Another experiment interesting experiment could be to add a 2nd PLL block after the first MMCM stage. Depending of the quality of the 12 MHz clock (which we don't know, but the working assumption is that it's quite good), this may act as a jitter filter and improve the clock quality.

That said, maybe it's not wise to turn it into a science for general-purpose digital logic that tends to be really really robust, if all I'm concerned about is the shortest expected cycle time for timing closure. The real problems are "probably" elsewhere (obviously I can't speak for any possible use case, but for example if I'd proto some high-end audio app it's common sense that I can't just take the converter clock from the USB crystal).

 

[BYTEMAN]

Hi all,
last night I've succesfully implemented my first VHDL design on the Cmod A7-35T board using the IP Clocking Wizard in order to have an internal 100 MHz clock starting from the original 12 MHz clock that is into the evaluation board. It seems working correctly, this monday in my office, I'll check with the scope the signal jitter and others electricals parameters, but from a behavioural point of view, using a sinlge 32 bit counter I was able to divide the 100 MHz clock in order to obtain a time base of 1 s used to perform a simple led blinking.

If could be of some interesting I can post a detailed totorial, a sort of  "HOW TO" with all the steps involved for a beginner point of view?

Thanks for now!

 

.

[jpeyron]

Hi @BYTEMAN,

I believe @xc6lx45 as correct with 

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

thank you,

Jon

[BYTEMAN]

2 hours ago, jpeyron said:

Hi @BYTEMAN,

Could you attach your xdc file? The example shows how to take the system clock(100 mhz) into the clocking wizard and output your desired clk frequency.

cheers,

Jon

Here the file.

Thank

 

Cmod-A7-Master.xdc

[xc6lx45]

those...

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

... look familiar (I'd have to re-read the documentation and schematics, the same way you already did).

I believe there are two ways to set a clock frequency:

- via the constraints file, as in the example constraints file
- via a clocking wizard

Use either-or. If using both, Vivado will do timing analysis between two hypothetical identical but alternative clocks. It doesn't make any sense but slows down P&R. This would be visible in the timing report from the implemented design

Running a design straight from the system clock (no clock IP) is OK, might reduce the carbon footprint by one or two molecules

[jpeyron]

Hi @BYTEMAN,

Could you attach your xdc file? The example shows how to take the system clock(100 mhz) into the clocking wizard and output your desired clk frequency.

cheers,

Jon

[BYTEMAN]

2 hours ago, jpeyron said:

Hi @BYTEMAN,

The easiest way to get the 12 mhz clk would be to use the clocking wizard. Here is a project that uses the clocking wizard with VHDL that you can use as an example for using the clocking wizard.

cheers,

Jon

I've see the link you wrote, thank, then I've to do:

- Step1 Configure the clock by means the Clock IP Wizard (with name clk.wiz_0 in this example)

- Step2 Insert into my code the following VHDL block statements:

 

component clk_wiz_0
port
 (-- Clock in ports
  CLK_IN1           : in     std_logic;
  -- Clock out ports
  CLK_OUT1          : out    std_logic
 );
end component;

[...]

clk_div_inst : clk_wiz_0
  port map
   (-- Clock in ports
    CLK_IN1 => CLK_I,
    -- Clock out ports
CLK_OUT1 => pxl_clk);

- Step3 Insert this code into the xdc file:

## Clock signal

set_property -dict { PACKAGE_PIN E3    IOSTANDARD LVCMOS33 } [get_ports { CLK_I }]; #IO_L12P_T1_MRCC_35 Sch=gclk[100]
create_clock -add -name sys_clk_pin -period 10.00 -waveform {0 5} [get_ports { CLK_I }];

then I can use in my design the pxl_clk signal as clock source for my process, right?

If all is correct my next step is configure the IP clocking Wizard to gain a 100 MHz clock inside the FPGA starting from the 12 MHz clock generator on the evaluation board, I'll post my screenshot to check if the step that I will take are correct...

Thank

Best regards

 

[BYTEMAN]

16 minutes ago, jpeyron said:

Hi @BYTEMAN,

The easiest way to get the 12 mhz clk would be to use the clocking wizard. Here is a project that uses the clocking wizard with VHDL that you can use as an example for using the clocking wizard.

cheers,

Jon

Hi jpeyron

thanks for your time, could you confirm that also my mode (directly through the XCD file) was correct?

Thanks again, I'm still makeing test in order to keep confidence with the system, my last design was with XILINX Foundation over a XC5200 and Spartan model so more time ago...:)

Best regards

 

[jpeyron]

Hi @BYTEMAN,

The easiest way to get the 12 mhz clk would be to use the clocking wizard. Here is a project that uses the clocking wizard with VHDL that you can use as an example for using the clocking wizard.

cheers,

Jon