Locating BUFG with Vivado and a CMOD A7-35T

[ToddW]

I have an input signal that is not being placed properly with an updated design.  I would like to tell Vivado 2023.2 where to place it.  This pin is in the same bank as the other IO pins that the design is using. The irq port is not a clock it is an input. 

I have tried to look for where the BUFG is located, but I do not see the device or any IO planning in Vivado.

Here are the full errors if it helps:

[Place 30-574] Poor placement for routing between an IO pin and BUFG. If this sub optimal condition is acceptable for this design, you may use the CLOCK_DEDICATED_ROUTE constraint in the .xdc file to demote this message to a WARNING. However, the use of this override is highly discouraged. These examples can be used directly in the .xdc file to override this clock rule. < set_property CLOCK_DEDICATED_ROUTE FALSE [get_nets irq_IBUF] > Clock Rule: rule_gclkio_bufg Status: FAILED Rule Description: An IOB driving a BUFG must use a CCIO in the same half side (top/bottom) of chip as the BUFG irq_IBUF_inst (IBUF.O) is locked to IOB_X1Y12 irq_IBUF_BUFG_inst (BUFG.I) is locked to BUFGCTRL_X0Y1

[Place 30-99] Placer failed with error: 'IO Clock Placer failed' Please review all ERROR, CRITICAL WARNING, and WARNING messages during placement to understand the cause for failure.

Edited Thursday at 10:31 PM by ToddW

[artvvb]

Hi @ToddW

We need more info on your design to be able to tell why Vivado thinks your input is a clock. Are you using it in a posedge expression, feeding it to a clock input of an IP in a block design, adding a create_clock constraint for it, or something else to that effect?

Thanks,

Arthur

[ToddW]

The design had some clock gating without using a BUFGCE.  It has been fixed.  Your comment was helpful in finding this issue.  I appreciate it and sorry that I had some common error.

[ToddW]

Unfortunately, I was wrong about this as the solution.  It was temporarily fixed, but after resolving another issue it returned.

Several options have be tried to fix the issue.

- BUFGCE with the enable signal done both with a wire and an always block setting the value based on a posedge clock.  Here are the two code snippets for the enable:

1. 

assign buffer_clk_en = (math_op == TIMEBASE_MATH_OP && prev_enable_timebase_math == 0) || (math_op == READ_DATA_OP && interrupt_event == 1 && prev_buffer_load == 0);

2.

always @(posedge clk or negedge reset_n) begin
    if (!reset_n) begin
        buffer_clk_en <= 0;
    end else begin
        buffer_clk_en <= (math_op == TIMEBASE_MATH_OP && prev_enable_timebase_math == 0) ||
                         (math_op == READ_DATA_OP && interrupt_event == 1 && prev_buffer_load == 0);
    end
end

- Setting a reg instead of gating a clock based on an always block and accepting the frequency is half of the clock.  This was done with the enable as a wire and always block as above.  Here is the code for the reg:

 always @(negedge clk or negedge reset_n) begin
    if (!reset_n) begin
        buffer_clk <= 0;
    end else begin
        if (buffer_clk_en) begin
            buffer_clk <= ~buffer_clk;
        end else if (!buffer_clk_en) begin
            buffer_clk <= 0;
        end
    end
end

 

The pin placement hasn't changed since the initial design which has been emulated for other functions.

 

Thank you.

Edited Friday at 09:06 PM by ToddW

[artvvb]

Is the location constraint for the clock just the standard Cmod A7 sysclk input (https://github.com/Digilent/digilent-xdc/blob/7583b4e7a6b8178afdb7f9e07f18162c48a89b0d/Cmod-A7-Master.xdc#L7), or something on the DIP header?  If the latter, the input might not be clock capable?

45 minutes ago, ToddW said:

always @(posedge clk or negedge reset_n) begin
    if (!reset_n) begin
        buffer_clk_en <= 0;
    end else begin
        buffer_clk_en <= (math_op == TIMEBASE_MATH_OP && prev_enable_timebase_math == 0) ||
                         (math_op == READ_DATA_OP && interrupt_event == 1 && prev_buffer_load == 0);
    end
end

always @(negedge clk or negedge reset_n) begin
    if (!reset_n) begin
        buffer_clk <= 0;
    end else begin
        if (buffer_clk_en) begin
            buffer_clk <= ~buffer_clk;
        end else if (!buffer_clk_en) begin
            buffer_clk <= 0;
        end
    end
end

Can you use the buffer_clk_en pin in further downstream logic instead of buffer_clk? Using the buffer_clk output by this with posedge in a sensitivity list would likely be considered a gated clock. Alternatively, using an MMCM or PLL to divide by two could work fine - this would mean something like adding a clocking wizard to generate clocks used with the design, maybe with no buffer on the output, so that you can manually instantiate a buffer and add the enable.

[ToddW]

For the clock, it has the standard clock and a clock wizard to boost the internal system clock, clk, to 100MHz.  The interrupt, irq, is an asynchronous input pin.  This was used both as an asynchronous value and synchronized with an always block creating interrupt_event.  What the design is trying to do is generate 2 clock pulses for a memory access to a memory generated by the Block Memory Generator.  Hopefully this is clearer?

[artvvb]

1 minute ago, ToddW said:

This was used both as an asynchronous value and ...

I think the original warning means that Vivado thinks that irq is supposed to be a clock, by virtue of it showing up in HDL as a signal used with posedge or negedge that doesn't look like a reset. It's not on a clock-capable pin, so it can't be used as a clock. Best bet might be to sample and synchronize it with the system clock.

[ToddW]

The design has the detection distributed to a couple of block.  It now has them all synchronized and the bitstream can be built.  Will make a single detection and distribute that.  I appreciate the help.