7
\$\begingroup\$

I usually initialize state registers of my FSMs by specifying an initial value in my VHDL code, so that, I do not require a reset pulse after startup of the configured FPGA. The following example demonstrates this by a "ring-counter" which just merges all state registers together:

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

entity counter_init is
  port (
    clock : in  std_logic;
    msb   : out std_logic);
end entity counter_init;

architecture rtl of counter_init is
  -- large counter to detect excessive skew on Global Write Enable (GWE)
  signal counter : unsigned(255 downto 0) :=
    x"55555555_55555555_55555555_55555555_55555555_55555555_55555555_55555555";
begin  -- architecture rtl

  counter <= counter(0) & counter(counter'left downto 1) when rising_edge(clock);

  -- The counter value will be observed by an on-chip logic analyzer.
  -- Output most-significant bit to prevent synthesizing away the above logic.
  msb <= counter(counter'left); 

end architecture rtl;

This technique has worked in my designs for Altera or Xilinx FPGAs so far. I have explicitly checked it using the vendor-specific on-chip logic analyzer and a startup trigger. Here is a screenshot of ChipScope, ok one cycle is missed apparently:

ChipScope screenshot

But, after reading the docs, I wonder how it works: How do all the flip-flops (connected to the same clock signal) start to toggle at the same time?

The startup sequence for a Xilinx FPGA is described in the 7 Series FPGAs Configuration User Guide (UG470) for example. After configuration of the FPGA, a startup sequence is executed which asserts a "Global Write Enable (GWE)" Table 5-12:

When asserted, GWE enables the CLB and the IOB flip-flops as well as other synchronous elements on the FPGA.

and in the footnote:

GWE is asserted synchronously to the configuration clock (CCLK) and has a significant skew across the part. Therefore, sequential elements are not released synchronously to the user's system clock and timing violations can occur during startup. It is recommended to reset the design after startup and/or apply some other synchronization technique.

So, this actually means: If the clock at the flip-flops already toggles, then all the flip-flops may start to toggle at different times / clock edges. Given that the clock oscillator on the FPGA board is already running, and that I'm using a global clock-buffer without an enable input (BUFG): Will the clock input at the flip-flops already toggle before GWE is asserted?

I didn't find any information in UG470 about if and how clock-buffers are enabled. And the Xilinx 7 Series FPGA and Zynq-7000 All Programmable SoC Libraries Guide for HDL Designs (UG768) only states that the clock-enable input of a BUFGCTRL must be asserted synchronously. But, this is actually a user-driven input.

For the Altera Cyclone III FPGA I'm using too, I didn't find any relevant information in the Cyclone III Device Handbook.

To repeat: I didn't observed any failing initialization so far, but this seems not to be specified in the docs.

\$\endgroup\$
  • 2
    \$\begingroup\$ A general rule - do not count on things which you do not control. If your startup state is important, provide an external reset which will release after configuration is complete. \$\endgroup\$ – WhatRoughBeast Apr 12 '16 at 15:39
  • 1
    \$\begingroup\$ Austin Lesea is the guy from Xilinx to answer this I think, I remember reading an app note he either wrote or recommended that explains this -- ah yeah, here is the one: xilinx.com/support/documentation/white_papers/wp272.pdf \$\endgroup\$ – Krunal Desai Apr 12 '16 at 16:51
  • \$\begingroup\$ @KrunalDesai The white-paper actually states that no user-defined reset is required because flip-flops and so on are reseted to ther initial value during configuration. But this contradicts the footnote cited in my question: It is recommended to reset the design after startup and/or apply some other synchronization technique. \$\endgroup\$ – Martin Zabel Apr 12 '16 at 19:02
4
\$\begingroup\$

You should assume the clock input to your flip-flops is toggling unless you can prove otherwise (by a guaranteed power on or post configuration delay). All the flip-flops on a given clock domain are not guaranteed to start on the same clock edge based on GWE or GSR. Both act like an asynchronous reset and cause potential problems for some logic (counters, one-hot state machines, etc).

Specifically a one-hot state-machine that transitions immediately after configuration WILL (eventually) FAIL (transition to an invalid state). The frequency of failure will depending on the clock period compared to the device (and place and route) specific skew for your design.

Another simple experiment to see this behavior initialize a relatively fast count down counter with 10000000 and look at its behavior immediately after configuration. Some bits make the transition to 01111111 and some bits miss that first transition but the subsequent counting sequence will be correct.

The white paper mentioned by Krunal Desai talks about this very problem and is a great reference. Any SRAM based FPGA will most likely have a similar issue.

There is no need to reset the registers to get a known value. If you have logic that is sensitive to all starting on the same clock edge will need to add synchronization logic (this can consist of a synchronously de-asserted reset or other synchronous logic). Xilinx AR44174 talks about the issue a little more. I would add a third method of mitigation which is to guarantee clocked logic is not changing/transitioning during the first several clock cycles after startup.

\$\endgroup\$
  • \$\begingroup\$ I will check your counter example tomorow. The white-paper actually states that no user-defined reset is required because flip-flops and so on are reseted to ther initial value during configuration. But this contradicts the footnote cited in my question: It is recommended to reset the design after startup and/or apply some other synchronization technique. So, is your advice to reset the (relevant parts of the) FPGA design after startup? \$\endgroup\$ – Martin Zabel Apr 12 '16 at 19:02
  • \$\begingroup\$ You are implementing a shift register not a counter, correct? I believe this should show the glitch behavior as well. What clock rate are you running? If the rate is not fast enough you have a low chance of the skew of the GWE bridging over a clock cycle. I would run the clock as fast as you can, if the tool placed the registers (or SLRs) close together it would have the effect of minimizing the GWE skew as well. \$\endgroup\$ – davidd Apr 12 '16 at 21:57
  • \$\begingroup\$ It was an up-counter first, but then I realized that I need a ring counter / shifter, so that all bits toggle at the first clock edge. By the way, the on-chip logic analyzer runs with the same clock and the only observation is that the first clock cycle is skipped deterministically in the trace. I will take a look at the AR from Xilinx. \$\endgroup\$ – Martin Zabel Apr 13 '16 at 6:22
5
\$\begingroup\$

For Xilinx FPGAs, the Answer Record AR# 44174 confirms that:

  • Timing violations can occur with flip-flops and SRLs since GWE is releasing synchronous elements with respect to the configuration clock instead of the user's system clock.

  • Propagation of the GWE signal means SRLs and flip-flops might be released at slightly different times which results in some parts of the design starting up before others.

So we have two options:

  1. Stop the user's system clock until startup is completed.
  2. Automatically apply a reset pulse after GWE or similar is asserted.

If no external reset input is required otherwise in the design, then solution 1 in the Answer Record is useful for Xilinx FPGAs.

  • Initially after startup, the clock should be stopped.
  • Once the EOS signal asserts from the STARTUP primitive, the clock can be restarted synchronously to the user's systemclock.
  • The best way to control this is to use a BUFGCE, BUFR reset, or BUFHCE.

I tried this solution, but Chipscope revealed that not all flip-flops started to toggle at the same time. It seems that the synchronous assertion of the clock enable pin CE of the BUFGCE is not that easy.

I recommend to use the second (following) technique instead. Instead of an external reset (reset_pin below), a '0' zero (no reset) has just to be feed into the reset synchronizer.


If there is an external reset anyway, then the reset synchronizer can be initialized such in a way, that a reset will be asserted after GWE or alike is asserted during the startup sequence. The reset synchronizer will not start the release sequence (i.e. flip-flops toggling towards '0') until GWE is asserted. The duration of the release sequence must be longer than the skew on the GWE. This solution will work on Xilinx and Altera FPGAs.

Declarations:

signal reset_sync : std_logic_vector(1 downto 0) := (others => '1');
signal reset : std_logic;

Architecture Body (register chain):

reset_sync <= reset_sync(reset_sync'high-1 downto 0) & reset_pin when rising_edge(clock);
reset <= reset_sync(reset_sync'high); -- active-high

Of course, the counter logic now requires a reset:

  process(clock)
  begin
    if rising_edge(clock) then
      if reset = '1' then
        counter <= x"55555555_55555555_55555555_55555555_55555555_55555555_55555555_55555555";
      else
        counter <= counter(0) & counter(counter'left downto 1);
      end if;
    end if;
  end process;

The screenshot below shows errors due to the asynchronous assertion of GWE. To provoke these, I omitted the signal initialization, so that, all counter flip-flops were initialized to '0' during configuration. As reset is asserted from the beginning, one would expect that all flip-flops change to the requested reset value with the first rising clock-edge after GWE is asserted. But, at time 0 (T marker), the counter value is not a sequence of x"5". Due to the reset-chain, the expected reset value is restored. The reset is released in cycle 2 (X marker), so that all flip-flops toggle in sub-sequent cycles. The clock frequency here is 200 MHz.

ChipScope screenshot with failed initialization

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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