# How to estimate timing contraints for FPGAs?

I try to find out how to specify the timings restrictions in FPGA designs correctly (in .sdc/.xdc files). I know what setup and hold times mean. However: How do I find out, what timing constraints my external circuit has?

What I hopefully understood so far is:

1. I need to specify my external clocks (especially it's speed) fed into the FPGA by using a create_clock statement. This ensures that internal timings (between pins of cells, e.g. between FlipFlops or Memory) are within limits.

2. For all input pins, I can specify setup (-min) and hold timings (-max) for all input pins of the FPGA (which are called ports in this context). These are relative to a clock and specified via set_input_delay -clock {clockname} -min/-max <time> [ get_ports {portname} ]

3. For all output pins, I can specify setup (-min) and hold timings (-max) for all input pins of the FPGA (which are called ports in this context). These are again relative to a clock and specified via set_input_delay -clock {clockname} -min/-max <time> [ get_ports {portname} ]

# Hypothetical Szenario

Let's say the FPGA has a external clock 'CLK' of 50 MHz connected. Specifying this one is easily:

create_clock -name CLK -period 20ns [ get_ports {CLK} ]


Now a microcontroller (ESP8266, datasheet) is connected to it, having its own external 80 MHz clock ("CLK").

The microcontroller sends and receives it's data using a simple clocked bus system:

• "TX" => "RX" (µC => FPGA)
• "RX" <= "TX" (µC <= FPGA)
• "clock" => "clock" (µC => FPGA, rising_edge triggered)

My microcontroller has the following program loop (pseudo code):

BEGIN:
(TX, CLK) <= (write_data, LOW)  [1th cycle]
(TX, CLK) <= (write_data, HIGH) [2th cycle]
JUMP BEGIN                        [4th cycle]


Let's assume the wiring of the tx, rx and clock line are about 20 cm in length and might deviate by 5 cm (shortest vs. longest wire). This means 0.67 ns average time for each path, but each signal might be +/- 0.17 ns faster or slower.

# My approach so far...

Timing at µC relative to rising edge:

(read_data) <= (RX)             -37.5ns <-- last read
JUMP BEGIN                      -25.0ns
(TX, CLK) <= (write_data, LOW)  -12.5ns <-- current data written
(TX, CLK) <= (write_data, HIGH)   0.0ns <-- current low->high
JUMP BEGIN                       25.0ns
(TX, CLK) <= (write_data, LOW)   37.5ns <-- next data written
(TX, CLK) <= (write_data, HIGH)  50.0ns <-- next low->high


Inputs:

When then the rising edge of the "clock" arrives at the FPGA, the data at the FPGAs "RX" pin is already valid for 1 clock cycle of the µC t=-12.5ns reduced by the max. deviation of traveling time t=-12.33 ns. Hence, the setup time of the FPGA may be up to 12.33 ns.

The input data at "RX" will be valid for 3 clock cycles of the µC reduced by the uncertainty of the travel time: 37.5ns - 0.17ns = 37.33 ns.

Outputs:

The data output at the FPGAs "TX" pin must be valid/stable and traveled to the µCs "RX" pin of the µC within 12.5ns - t_setup of the µC. Hence, it must be stable at 12.5 ns - 0.67 ns - 0.17 ns - t_setup = 11,66 ns - t_setup. However, I don't know how to find out t_setup for the µC.

Also, the µC should not output data to earl. The last data finishes reading until t <= -37.5ns + t_hold measured at the µC, which means t <= -38 ns + t_hold at the FPGA. This is the sets the limit for the FPGA's setup time.

Now there are some unknown parameters (the µCs setup_time and hold_time). And I don't know if I calculate everything correct...

Also, when writing the constraint, should I use the negated values for the setup_time in the constraints or the earliest/latest time relative to the clock event?

Here is my intermediate/Incomplete solution:

set_input_delay -clock clock -min -12.330ns [ get_ports {RX} ]
set_input_delay -clock clock -max 37.330ns [ get_ports {RX} ]

set_output_delay -clock clock -min -38.000ns [ get_ports {TX} ]
set_output_delay -clock clock -max 12.330ns [ get_ports {TX} ]


However, I did not include setup and hold time of the "RX" pin at the µC and I somehow need to specify the clock signal received by the µC via the 'clock' line of the bus in the constraints file, as the constraints relate to this clock and not to the FPGAs own external 50 MHz clock. Right?

# Questions

• How to specify the received clock signal sent by the µC correctly?
• How to specify the input/output delays correctly?
• How to find out (or estimate by rule of thumb) the setup/hold time for the µC's GPIO-Pins? (I didn't find it in the datasheet; maybe it's called differently... what keywords should I search for? Which diagrams/section names?)
• How to interpret the diagram of the Altera TimeQuest Timing Analyzer Wizard (screenshot below)?

# Diagram in the "TimeQuest Wizzard" in Quartus II

There is a time diagram in the "TimeQuest Wizzard" in Quartus II. But, I'm not able to read it, because I found it confusing which block (<....>) is my current data bit which and what the <////> block means. I only could identify the clock signal, not knowing for sure if the standard is rising/falling edge. This in turn makes it difficult to conclude, which of the blocks is which and to which time those arrows relate. Maybe, there are conventions - but I don't know them. So please give me some insight here...

# DATASHEET OF µC:

In the example above the µC is an ESP8266 (datasheet).

# EDIT:

Here is some example FPGA source code (VHDL) which hopefully explains how I think about using the two clocks. The speed of the async clock for the data must of course be slow enougth, such that the FPGA has enough clock cycles to recognize, that new async data arrive (RX_flag) and to prepare the output to the TX_reg before the next rising edge on the clock from the µC. Given the above timing, the µC has 50ns to recognize and process input data. Hence, there should be at least 1 full cycle of CLK having a half period of CLK before it (a falling edge that notices if data is already available):

   library ieee;
use ieee.std_logic_1164.all;
use ieee.std_logic_unsigned.all;
use ieee.numeric_std.all;

entity AsyncIO is
port(
-- own clock, reset
CLK : in std_logic;
reset : in std_logic;

-- IO-Pins to uC
clock, RX_pin : in std_logic;
TX_pin        : out std_logic
);
end entity;

architecture RTL of AsyncIO is

signal RX_buffer : std_logic := '0'; -- holds received bit
signal RX_flag   : std_logic := '0'; -- is set when new bit arrive / reset when processed
signal RX_ready  : std_logic := '0'; -- is set when new bit was available at falling_edge / reset when processed
signal TX_reg    : std_logic := '0'; -- output that is currently to be send

signal last_RX : std_logic;
signal counter : std_logic_vector(1 downto 0) := "00";

begin
-- async process
process (clock) is
begin
if rising_edge(clock) then
RX_buffer <= RX_pin;
RX_flag <= '1';
TX_pin <= TX_reg;
end if;
end process;

-- async reset
process (reset) is
begin
if reset = '1' then
counter <= "00";
RX_buffer <= '0';
RX_flag <= '0';
TX_reg <= '0';
end if;
end process;

-- synced process
process (CLK) is

-- processes RX
-- count similar bit in a row
-- TX_reg <= '1' if 5 similar bit in a row
-- else TX_reg <= '0'
procedure processRX is
begin
if (RX_buffer = last_RX) then
-- count similar bits
counter <= counter + 1;
-- no overflow at value '11'
-- instead keep at '11' and set TX_reg to '1'
if counter = "11" then
counter <= "11";
TX_reg <= '1';
end if;
else
-- reset if not similar
counter <= "00";
TX_reg <= '0';
end if;
-- remind last_RX
last_RX <= RX_buffer;
end;

begin
if falling_edge(CLK) then
if RX_flag = '1' then
end if;
end if;

if rising_edge(CLK) then
-- if RX_read is '1' then RX_flag was already '1' at falling_edge
-- hence RX_buffer is safe to read now
processRX; -- call procedure to process bit in RX_buffer
RX_flag <= '0';
end if;
end if;
end process;

end architecture;

• Please provide a link to the datasheet for your microcontroller. – Elliot Alderson Jan 16 '19 at 15:25
• Please explain how RX, TX, and CLOCK are connected to the microcontroller. Are they all part of the same general-purpose I/O register or do TX/RX come from a UART? Also, are you certain that the compiler will not reorder instructions or I/O accesses? – Elliot Alderson Jan 16 '19 at 15:29
• Added the Link to the datasheet. Just imagine it like SPI with a static chip select. All pins at the same µC-port bank. No reordering, just assume I would use assembly instructions. -- IMPORTANT NOTE: This is a hypothetical example to show what my current knowledge level is like and what I need to find out. I want to understand how to calculate timing constraints in general. – SDwarfs Jan 16 '19 at 15:45

As your FPGA and micro-controller run of different clocks, there is NO timing relation between them. To safely transfer data between them you have to use synchronizers or a circuit which has clock domain crossing logic built-in like an asynchronous FIFO with a read and write clock (Every FPGA vendor I known has IP for those).

This also means that you can't (and thus don't have to) set up timing contraints between them.

This holds for both your CLK and TX data from CPU to FPGA, and also for your RX data from FPGA to micro-controller.

This still leaves you with the issue how to set up the FPGA timing for your example interface with a CLK and TX data. Unfortunately there is no simple answer as it greatly depends on how the instructions generate the signals. e.g. are the clock and TX always set in the same clock cycle? You could use the falling edge of the clock to register the data.

Last but not least: Synchronizers and asynchronous FIFOs require more then one clock cycle to transfer the data between clock domains. Thus you must either have a continuous running CLK or you must generate several more cycles after you have send data or before you plan to receive data.

• Good answer, just wanted to emphasize that the OP must have synchronizers to avoid metastability. – Elliot Alderson Jan 16 '19 at 16:25
• Thanks for your response: In my example data is sent one µC clock cycle (12.5 ns) before the rising clock edge. Hence, a FPGAs process being sensitiv to the clock signal should be able to safely store the current bit into a flipflop. The FPGA would use it's internal clock to prepare the output, which is already stored into a flipflop near the output pin. Assuming the FPGA produces a (known clocks from the µC delayed) bit as output for each input bit, this should work. – SDwarfs Jan 16 '19 at 16:29
• What is an "OP"? @EliotAlderson – SDwarfs Jan 16 '19 at 16:31
• OP=Original Poster – CapnJJ Jan 16 '19 at 16:40
• That code is incorrect. I suggest you deal with that in a separate question. – Oldfart Jan 16 '19 at 17:36