# Inferring D-latch on Zedboard within Vivado Error

I'm trying to implement a simple latch on a ZedBoard via Vivado.

begin
process(D,Enable) begin
if(Enable = '1') then
Q <= D;
Qbar <= not(D);
end if;
end process;


I'm using user I/O on the constraints for the inputs/outputs. I assign the inpus to two SWITCH Pins and the outputs to two LED pins.

The routing (implementation phase) gives me the following error:

[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 Enable_IBUF] >

Enable_IBUF_inst (IBUF.O) is locked to IOB_X1Y125 and Enable_IBUF_BUFG_inst (BUFG.I) is provisionally placed by clockplacer on BUFGCTRL_X0Y31

The two suggested solutions to the problem are here and setting the < set_property CLOCK_DEDICATED_ROUTE FALSE [get_nets Enable_IBUF] > works but I would like to understand solution 1  1) Move the clock input to a clock capable pin. since it seems important.

How can I find a clock capable input that I can press/move like I do on the switch?

What's happening here is that the tools are interpreting your Enable signal as a clock. (You can view your implemented design in the tool to check this.) If you attempt to design some asynchronous logic, the tools generally try very hard to find a clock, because FPGA timing models assume a synchronous system.

So you are getting the CLOCK_DEDICATED_ROUTE warning because the tools think the enable signal is a real clock. If it was a real clock, you would want to use the special clock pins on the FPGA that are directly connected to clock routing resources. (These are labelled MRCC and SRCC, for multi-region and single region, respectively.) But since your signals are coming from physical switches, for the purposes of your experiment the non-ideal routing doesn't really matter.

One thing you could do is use an Earle latch, which is a form of D latch using an AND-OR with three terms. It shouldn't be recognized as sequential (clocked) logic by your synthesis tool. See How can I implement a simple, Q only, D-latch using VHDL?.

Without expressing a second latch for Qbar:

library ieee;
use ieee.std_logic_1164.all;

entity dlatch is
port (
D:      in  std_logic;
Enable: in  std_logic;
Q:      out std_logic;
Qbar:   out std_logic
);
end entity;

architecture fum of dlatch is
signal QQ:   std_logic;
begin
process(D, enable, QQ)
begin
QQ <= (Enable and D) or
(not Enable and QQ) or
(D and QQ);          -- consensus term
Q <= QQ;
Qbar <= not QQ;
end process;
end architecture;


This should be synthesis eligible.

And here is a testbench to determine the three terms are correct:

library ieee;
use ieee.std_logic_1164.all;

entity dlatch_tb is
end entity;

architecture test of dlatch_tb is
signal D:       std_logic := '0';
signal Enable:  std_logic := '0';
signal Q:       std_logic;
signal Qbar:    std_logic;

component dlatch is
port (
D:      in  std_logic;
Enable: in  std_logic;
Q:      out std_logic;
Qbar:   out std_logic
);
end component;

begin
DUT:
dlatch
port map (
D => D,
Enable => Enable,
Q => Q,
Qbar => Qbar
);
STIM:
process
begin
wait for 10 ns;
Enable <= '1';
wait for 10 ns;
Enable <= '0';
wait for 10 ns;
d <= '1';
wait for 10 ns;
Enable <= '1';
wait for 10 ns;
Enable <= '0';
wait for 10 ns;
wait;
end process;
end architecture;
`

On the other hand "- Never mind"

I'm using user I/O on the constraints for the inputs/outputs. I assign the inpu(t)s to two SWITCH Pins and the outputs to two LED pins.

and

How can I find a clock capable input that I can press/move like I do on the switch?

If you're using switches to operate your latch you shouldn't care about sub optimal routing and setting the 'CLOCK_DEDICATED_ROUTE constraint in the .xdc file to demote this message to a WARNING' is perfectly valid.

It's highly unlikely you can manage to toggle both switches so close together you risk getting the 'wrong' state stored with any degree of certainty which order they toggled. We're talking about sub optimal routing on the extremely close order of a nanosecond considering the low capacitive loading.