0
\$\begingroup\$

I use Vivado 2019 and want to create a bitfile.

I want to use an incoming clock for both my ip-core and my process, but I have some timing errors.

1. What I tried:

1.1 clocking

  • How to use derivation of my 156,25 Mhz for my process and for the 50 MHz input of my IP-Core?
  • Will it work with IBUFDS_GTE2 output?

*xdc:

set_property PACKAGE_PIN F13            [ get_ports a7_mgt216_clk_p_i ]
set_property PACKAGE_PIN E13            [ get_ports a7_mgt216_clk_n_i ]

create_clock -period  6.400  [ get_ports a7_mgt216_clk_p_i ] 

I tried to connect MGTREFCLK directly to a MMCM, but it didn't work.

UG482 shows that I could maybe use the output of the IBUFDS_GTE2 buffer:

ug482 IBUFDS

Connecting it to a MMCM and then to my process with a 156 out and to the ip core dclk with 50 MHz still gives me a timing error.

I looked into the timing summary report:

enter image description here

device browser :bad timing

I looks like my reset path 41 is too slow. Why? I can change it, but how?

device browser: process to xaui

1.2 My initialization process:

  • Make a reset after around 700 ns.
  • Toggle an ip-core entry until it is ready.

enter image description here

1.1.1 reset:

    p_counter : PROCESS (clk156_out)
    
      BEGIN
        IF rising_edge(clk156_out) THEN
          IF finished = '0' THEN
            --counter := counter + 1;
            counter_value <= counter_value + 1;
            reset <= '0';
          END IF;
          IF counter_value = "1111111" THEN
            finished <= '1';
          END IF;
          IF finished = '1' THEN
            reset <= '1';
          END IF;
    
        END IF;
    
      END PROCESS p_counter;

1.1.2 toggling


    IF rising_edge(clk156_out) THEN
      IF dut_ready = '0' AND status_vector_design /= "11111100" THEN
        IF toggle = '0' THEN
          configuration_vector(2) <= '1';
          configuration_vector(3) <= '1';
          toggle <= '1';
        ELSIF toggle = '1' THEN
          configuration_vector <= (OTHERS => '0');
          toggle <= '0';
        END IF;
      ELSE
        dut_ready <= '1';

      END IF;
    END IF;
  END PROCESS p_config_status_vector2;

I am getting the following critical warning:

[Timing 38-282] The design failed to meet the timing requirements. Please see the timing summary report for details on the timing violations.

When I comment it all out this warning went away.

1.3 Question:

  1. Should I change the ifs into another type of command?
  2. Why does it get into timing issues?
  3. There aren't that many ifs.

2. What I try now for debug:

But ok – Puffafish 6 mins ago you say the ifs are not the problem its the amount of stuff inside the process?

Ah I see following also gives me

[Timing 38-282] The design failed to meet the timing requirements. Please see the timing summary report for details on the timing violations.

  p_counter : PROCESS 
   

  BEGIN
wait until rising_edge(clk156_out);
      case finished is
      when '0' =>
        --counter := counter + 1;
        counter_value <= counter_value + 1;
        reset <= '0';
      when others =>
        reset <= '1';
      end case;
  ---
      case counter_value is
      when "1111111" =>
        finished <= '1';
        when others =>
        finished <= '0';
      end case;
      
    ---  
     case finished is
      when '1' =>
        reset <= '1';
        when others => 
        reset <= '0';
      end case;
      
    ---  
  END PROCESS p_counter;

next test shows again the same

   p_counter : PROCESS (clkwiz2_156_25MHzOut)
  BEGIN
    IF rising_edge(clkwiz2_156_25MHzOut) AND (finished = '0') AND (dut_ready = '0') AND (status_vector_design /= "11111100") THEN
        counter_value <= counter_value + 1;
        reset <= '1';
    END IF;
  END PROCESS p_counter;

It must have to do with my clock output.

It comes out of a ip core... I will pass it now into a clock wizard and use its output. I don' t know which buffers would be appropriate.

.. oh ok my first try doesn't work.

I will check out if I can use another clock.... :(

Something I am doing totally wrong. After connecting connect 50 MHz to my process which also goes to xaui

[Route 35-468] The router encountered 9 pins that are both setup-critical and hold-critical and tried to fix hold violations at the expense of setup slack. Such pins are:
    reset_i_1/I1
    reset_i_1/I2
    reset_i_1/I3
    reset_i_1/I4
    reset_i_1/I5
    reset_i_2/I2
    reset_i_2/I0
    reset_i_2/I1
    reset_i_2/I3
\$\endgroup\$
3
  • \$\begingroup\$ You can rewrite this to reduce your use of processes. Why is reset and finish declared in the process? You can easily take them both out of it. The IFs are not the problem, its the amount of stuff you put in the process. \$\endgroup\$
    – Puffafish
    Commented Mar 31, 2022 at 7:34
  • 1
    \$\begingroup\$ "A sequential signal assignment takes effect only when the process suspends. If there is more than one assignment to the same signal before suspension, the last one executed takes effect." Source. \$\endgroup\$
    – Velvet
    Commented Mar 31, 2022 at 7:46
  • \$\begingroup\$ thank you. i am lucky i already know this. But it is really important! \$\endgroup\$
    – pgapga
    Commented Mar 31, 2022 at 8:15

2 Answers 2

1
\$\begingroup\$

There is a simple mistake here: the XAUI block is clocked with a 10 MHz clock from a PLL (that is instantiated by the clock wizard), but the reset signal is generated in the 156 MHz clock domain.

Timing analysis looks at the phase relationship of the two clocks, and since they are of a different frequency, all possible phases must be evaluated.

If you derived a 50 MHz clock from a 100 MHz clock, the relationship would be easy: the 50 MHz clock's rising edge is delayed by a certain amount from a rising edge of the 100 MHz clock, and there are two possible values for that delay. Likewise, if you derived 100 MHz from 50 MHz.

Since your clock setup has higher values in numerator and denominator for the PLL, there are more possible phase offsets between rising edges, and some of these will be worse than others.

Likely, your best bet is to generate the reset signal in the right clock domain in the first place, and use a synchronizer chain for crossing the finished signal between domains.

\$\endgroup\$
1
  • \$\begingroup\$ thank you. I will take care that reset is on the right clock domain. And I will also take a look into synchronizer chains. :D \$\endgroup\$
    – pgapga
    Commented Jun 23, 2022 at 5:20
0
\$\begingroup\$

You set and check the value of counter_value in the same process, so that will probably not be doing what you expect, as metntioned in the comments by @seir.

I'd rewrite this to reduce your use of processes.

For example, the RESET block could be:

 p_counter : PROCESS (clk156_out)
  BEGIN
    IF rising_edge(clk156_out) AND (finished = '0') AND (dut_ready = '0') AND (status_vector_design /= "11111100") THEN
        counter_value <= counter_value + 1;
        reset <= '1';
    END IF;
  END PROCESS p_counter;

The do a when statement for reset = 0 when counter_value = "1111111".

I have no idea what you are doing with the finished signal, looking at what you've given us, it can be removed.

The toggling block depends on what the signals are doing, it doesn't look too bad if the signals need to be sycnconised to the clock edge.

The obvious other question is; what are the timeing requirements? Usually you've put them in place, so they could be anything. Are you sure they are sensible?

It looks to me like you're a software enginer who doesn't understand the full power of VHDL. Not everything needs to happen in a process. Take all logic declarations out of processes and put them in as their own lines.

\$\endgroup\$
8
  • \$\begingroup\$ yeah sure "finished " can maybe reduced :) I will check it. Thank you I will try to find out what my logic declarations are.. someone told me I should rewrite it with "case" .. but it gives me the same cirtical warning. I will now try your advices! \$\endgroup\$
    – pgapga
    Commented Mar 31, 2022 at 7:46
  • \$\begingroup\$ hmm same critical warning comes after copy and paste your example. Today I also checked to timing analyser. Maybe this can it. I should show you. \$\endgroup\$
    – pgapga
    Commented Mar 31, 2022 at 7:51
  • \$\begingroup\$ @pgapga What are the timing requirements? Are they sensible? \$\endgroup\$
    – Puffafish
    Commented Mar 31, 2022 at 7:57
  • \$\begingroup\$ oh sry. the timing requirements are not sensible. there is a ethernet xaui core which is controlled by a 156 Mhz clock. since I have no other clock in my design (as far as I know) I should use this clock somehow. Unfortunatly I cant directly use this 156 clock. But I checked the schematic and the bufer ibufds where the 156 goes into has one output for the xaui and one for my design :) and there is also a transceiver 156 Mhz output. all I want to do is to do a reset in the beginning and toggle a std_logic_vector. \$\endgroup\$
    – pgapga
    Commented Mar 31, 2022 at 8:02
  • \$\begingroup\$ I think you need to have a lot better understanding of VHDL and FPGAs in order for us to help you with this question. @pgapga you can have pretty much any clock inisde the FPGA you want, just need to put the input clock into a PLL. If the requirements are not sensible, then you need to change something. \$\endgroup\$
    – Puffafish
    Commented Mar 31, 2022 at 8:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.