Re: Why doesn't this situation generate a latch?

Discussion in 'VHDL' started by fpgabuilder, Mar 17, 2010.

  1. fpgabuilder

    fpgabuilder Guest

    On Mar 10, 12:24 pm, Ed McGettigan <> wrote:
    > On Mar 10, 10:06 am, Andy <> wrote:
    >
    > > On Mar 9, 12:15 pm, Ed McGettigan <> wrote:

    >
    > > > I would strongly encourage you to change the RESET function from
    > > > asynchronous to synchronous.

    >
    > > On what basis do you make this recommendation, and what does this have
    > > to do with latches?

    >
    > > Andy

    >
    > Synchronous versus asynchronous resets have been discussed at length
    > in other threads.
    >
    > Asynchronous resets have their place in a designer's toolbox, however
    > they should be used sparingly.  Some reasons to use these are for
    > handshakes crossing clock domains, anticipated loss of clock and
    > asynchronous inputs to the synchronous domain.
    >
    > In a synchronous domain, such as the original state machine example,
    > the asynchronous functionality offers no additional benefit in FPGAs
    > as the area cost is identical for both.
    >
    > Asynchronously asserting and de-asserting a reset across multiple
    > registers may/will result in the registers being released before and
    > after a clock edge due to large net delay and skew on the reset net.
    > This will result in different parts of a design coming out of reset
    > across clock boundaries and being out of sync with each other.

    I know Altera's Quartus Timing Analyzer has recovery/removal analysis.
    >
    > Synchronous resets simplify timing analysis and timing closure without
    > having to worry about the consequences of the asynchronous functions
    > and how to correctly constrain them.

    I have not used Xilinx devices with Synchronous resets. I am curious
    is it ever possible that the clock may stop before the reset event and
    then subsequently the clock appears after the reset event passes
    thereby not initializing the logic?
    >
    > I often see problems with FPGA designs that are built with
    > asynchronous resets, but I have yet to see a problem with a FPGA
    > design that was traced to a synchronous reset.
    >
    > In an FPGA there is no downside to a synchronous reset, but there are
    > many pitfalls with an asynchronous reset.
    >
    > None of this has anything to do with a latch, which you also want to
    > avoid using in an FPGA.
    >
    > Ed McGettigan
    > --
    > Xilinx Inc.
    fpgabuilder, Mar 17, 2010
    #1
    1. Advertising

  2. On Fri, 19 Mar 2010 06:32:38 -0700 (PDT), rickman wrote:

    [Weng]
    >> there are 6 types of
    >> reset signals, a situation much more complexer than we think.


    >Ok, go ahead and tease us! Or are you going to share with us what the
    >six types are?


    1. Reset that is asserted at the right time,
    but has the wrong polarity, thus holding the design
    in reset throughout your test.
    2. Reset with the right polarity that is not asserted
    reliably at power-up, because you were too cheap
    to spend $0.70 on a power monitor/watchdog chip.
    3. Reset that is triggered at random times during
    operation because it is laid out on the PCB too
    close to a data bus. Capacitive coupling causes
    reset to be momentarily asserted when more than
    80% of the data lines transition simultaneously.
    4. Reset that is asserted correctly, but is released
    too close to a clock edge and causes the design
    to go into an illegal state because some flops
    respond to the clock and others don't.
    5. Reset of a counter, used by a designer who thought
    it would be a cool way to make the counter go back
    to zero when it overflows some programmed limit.
    6. Reset that is triggered by the operation of a
    system-level watchdog. It causes the CPU to stop
    operating roughly a millisecond before emitting
    the debug message that would have allowed you
    to diagnose the problem.

    Just in case you thought I was fooling, I should point
    out that I have had to debug and correct each of these
    at some point in my career. One or two of them were
    someone else's fault :)
    --
    Jonathan Bromley
    Jonathan Bromley, Mar 19, 2010
    #2
    1. Advertising

  3. On Mar 19, 2:31 pm, Jonathan Bromley <>
    wrote:
    > On Fri, 19 Mar 2010 06:32:38 -0700 (PDT), rickman wrote:
    >
    > [Weng]
    >
    > >> there are 6 types of
    > >> reset signals, a situation much more complexer than we think.

    > >Ok, go ahead and tease us!  Or are you going to share with us what the
    > >six types are?

    >
    > 1. Reset that is asserted at the right time,
    >    but has the wrong polarity, thus holding the design
    >    in reset throughout your test.
    > 2. Reset with the right polarity that is not asserted
    >    reliably at power-up, because you were too cheap
    >    to spend $0.70 on a power monitor/watchdog chip.
    > 3. Reset that is triggered at random times during
    >    operation because it is laid out on the PCB too
    >    close to a data bus.  Capacitive coupling causes
    >    reset to be momentarily asserted when more than
    >    80% of the data lines transition simultaneously.
    > 4. Reset that is asserted correctly, but is released
    >    too close to a clock edge and causes the design
    >    to go into an illegal state because some flops
    >    respond to the clock and others don't.
    > 5. Reset of a counter, used by a designer who thought
    >    it would be a cool way to make the counter go back
    >    to zero when it overflows some programmed limit.
    > 6. Reset that is triggered by the operation of a
    >    system-level watchdog.  It causes the CPU to stop
    >    operating roughly a millisecond before emitting
    >    the debug message that would have allowed you
    >    to diagnose the problem.
    >
    > Just in case you thought I was fooling, I should point
    > out that I have had to debug and correct each of these
    > at some point in my career.  One or two of them were
    > someone else's fault :)
    > --
    > Jonathan Bromley


    Hi,
    Here is where you can find the contents:
    http://www.opensparc.net/opensparc-t2/download.html

    1. /doc/OpenSPARCT2_SoC_Micro_Arch_Vol1.pdf
    2. /doc/OpenSPARCT2_SoC_Micro_Arch_Vol2.pdf

    3. There are too many reset descriptions. I just copy the most
    important context here.

    2.2.2 Reset Sequence for L2 cache
    In L2 cache, parity bits in the tag array, valid bits in VUAD array
    and the directories
    should be initialized before L2 cache is enabled to guarantee
    coherency and correct
    functionality.
    The directory valid bits are cleared with flash reset during POR_. The
    reset block
    drives the flash reset. When the valid bits are cleared (not valid)
    then the entries are
    don’t care. Hence, the parity bits are not initialized to good parity.
    Clearing valid
    bits in the directory informs the L2 cache that there are no valid
    lines in L1.
    BISI or ASIs are used to initialize the VUAD arrays by clearing all
    the valid bits. This
    informs L2 cache that there are no valid lines in L2.
    BISI or ASIs are used to initialize the tag array with good parity.
    This eliminates the
    possibility of any error cases from happening.

    4.16.6 ASIC Reset
    The ASIC blocks in OpenSPARC T2 DMU are treated differently from other
    clusters
    during the reset sequence and warm or debug resets.
    During POR1 the DMU has its clocks stopped until the RST unit tells
    TCU to release
    them with rst_tcu_asicflush_stop_req; this signal comes earlier than
    rst_tcu_flush_stop_req. When the asicflush_stop_req is received, TCU
    releases itself
    from its own flush reset and turns off the clock stops to the ASICs
    and deasserts
    tcu_asic_scan_en. The tcu_asic_aclk is not asserted at all during
    POR1, preventing a
    flush state to the ASICs. During subsequent resets (WMR1, WMR2) the
    ASIC clock
    stops are allowed to activate in the normal clock stop sequence but
    the ASICs are not
    4-90 OpenSPARC T2 SoC Microarchitecture Specification Part 1 of 2 •
    May 2008
    flushed. During debug resets (DBR) the signal rst_tcu_dbr_gen is
    active and TCU
    does not activate the clock stops to the ASICs to allow them to
    continue running.
    During JTAG clock stop operations, these blocks behave as other SOC
    blocks. During
    POR2 the ASIC clock stops will be held deasserted.

    5.3.2 Reset Scheme
    The CCU relies on the RST block for explicit reset signals, and does
    not operate via
    flush reset. Also, it needs to be released from reset before all other
    blocks on the
    chip. One reset is solely for the PLL, and the other for the remaining
    CCU logic,
    loosely speaking. The CCU itself needs to generate one or two
    staggered resets.
    These resets work in a domino like fashion to ultimately provide a
    signal to the RST
    unit that indicates the CCU is done with initialization, and that the
    RST block may
    release the rest of the chip from reset. This signal is
    ccu_rst_sync_stable. When the
    signal goes high, all clocks from the CCU are valid, at the correct
    frequency, and all
    sync pulses are operating in their proper positions.
    Depending on whether clocks may be stable or not, the CCU needs to use
    either
    asynchronous or synchronous reset. However, all resets within the CCU
    are released
    synchronously. Emphasis has been placed on determinism and
    repeatability, so even
    where brute-force synchronization is used, additional signals ensure
    determinism.
    There is only one CSR register in the CCU that is warm reset
    protected. All clock
    generating and pll programmation bits are warm reset protected. The
    rest are not.
    5.3.3 Initialization Sequence
    The Power-On-Reset scheme in the CCU is highlighted by the waveforms
    in
    FIGURE 5-9. For functional operation, the CCU is activated in a very
    simple manner.
    There are two resets to the CCU, ccu_rst_pll_ and ccu_rst_ that need
    to be applied
    in a sequence. Testmode, and divider_bypass pins need to be held low.
    Chapter 5 Clock Control Unit (CCU) 5-17
    An explanation of the various numbered parameters is given in TABLE
    5-5.
    TABLE 5-5 Key Parameters in Initialization Sequence
    Parm # Description Duration
    1 Time taken for first rising edge of refclk to appear from release of
    rst_ccu_pll_ <1 sys_clk cycle
    2 Deassertion of rst_ccu_pll_ to rising edge of stable CMP PLL clock
    output LOCK TIME
    3 Clock distribution delay of global clock tree from PLL output to
    gclk input of
    cluster header
    ~0.5 – ~1.3 CMP
    cycle
    4 Deassertion of rst_ccu_ to gclk_rst_n (requires use of brute force
    synchronizer) 1 to 2 CMP cycles
    5 Rising edge of refclk to assertion of aligned_shift pulse. 3 CMP
    cycles
    6 Shift of aligned_shift pulse to create VCO aligned 4 to 17 CMP
    cycles depending
    on pll_div2[5:0]
    7 Transfer of aligned signal from CMP PLL domain to CMP_GCLK domain.
    Tracks parameter
    #3
    8 From first aligned pulse to aligned_rst_n signal for internal CCU
    blocks for
    coherent reset release.
    1 CMP cycle
    9 Deassertion of aligned_rst_n to first rising edge of ccu_io2x_out 2
    CMP cycles
    10 Deassertion of aligned_rst_n to first rising edge of ccu_io_out 4
    CMP cycles
    11 Time when aligned == 1 to deassertion of divider for generating DR
    clock
    within PLL
    2-3 CMP cycles
    depending on
    pll_div4[6:0]
    12 Deassertion of dft_a_rst_l to first rising edge of dr_clk 5-6 CMP
    cycles
    depending on
    pll_div4[6:0]
    5-18 OpenSPARC T2 SoC Microarchitecture Specification Part 1 of 2 •
    May 2008
    FIGURE 5-7 CCU Clock Domains and Function
    Chapter 5 Clock Control Unit (CCU) 5-19
    FIGURE 5-8 Align Detection Circuitry
    FIGURE 5-9 Initialization Sequence for CCU Clocks
    5-20 OpenSPARC T2 SoC Microarchitecture Specification Part 1 of 2 •
    May 2008
    5.4 Sync Pulses
    The main application of generating synchronization pulses in OpenSPARC
    T2 is to
    allow low latency, deterministic data transfer between ratioed
    synchronous clock
    domains. The key requirements for this scheme to work are:
    A single reference clock source.
    PLLs that have similar behavior, in particular a known input-output
    phase
    relationship.
    The clock frequencies need to be rational multiples of each other, or
    ratioed
    synchronous
    Jitter, skew, and other PVT mismatches are taken into account to
    ensure setup and
    hold requirements are met during domain crossing.
    Clock domains that are of primary concern are the CMP and DR domains.
    Synchronization between cmp and IO, or IO2X domains is a simpler
    problem, but
    handled similarly.
    5.4.1 Proposed Scheme
    The following circuit shows the proposed scheme for clock domain
    transfers.
    FIGURE 5-10 CMP to DR Synchronization
    Chapter 5 Clock Control Unit (CCU) 5-21
    FIGURE 5-11 DR to CMP Synchronization
    It has been borrowed from past designs and modified. All it does is
    allow data to
    cross one domain to another during a safe interval, avoiding setup and
    hold
    problems. The mechanism for operation for fast clock (e.g., cmp) to
    slow clock (e.g.,
    dr) domain is as follows:
    Mux enable to launch flip-flop is generated on cmp_clk.
    Next cmp rising edge, data is launched.
    Data is captured on dr_clk.
    For slow clock to fast clock transfers, the procedure is:
    Data is launched on rising edge of dr_clk.
    Mux enable to capture flip-flop is generated on cmp_clk.
    Next cmp rising edge, data is captured.
    In both cases, the rate of communication is limited by the slower
    clock frequency, so
    the enable is generated once every slow clock cycle. The main
    challenge is to
    determine the ideal intervals between pulse generation for robust
    operation. For a
    discussion on determining the positions, refer to Appendix A.1 – Sync
    Pulse Design
    Procedure.
    5-22 OpenSPARC T2 SoC Microarchitecture Specification Part 1 of 2 •
    May 2008
    5.4.2 Sync Pulse Distribution
    FIGURE 5-12 Logical Representation of Sync Pulse Global Distribution
    Sync pulses will be generated in the CCU on the cmp_gclk domain, and
    be
    distributed (along with other control signals) in five stages of
    pipeline in
    mini-clusters to each cluster header. In the cluster headers, there
    will be one more
    stage of latching the data on the gclk domain. From there, each
    cluster will flop the
    enables on the l2clk domains before local distribution. In effect,
    there will be seven
    stages of cmp_cycle before sync pulses are output from cluster
    headers, and then
    flopped one last time within clusters.
    Chapter 5 Clock Control Unit (CCU) 5-23
    5.4.3 CMP to IO/IO2X Waveforms
    Domain crossing between CMP and IO/IO2X domains is a special, and
    simpler case
    of CMP to DR communication because cmp_clk is an integer multiple of
    io_clk and
    io2x_clk, and both io_clk and io2x_clk are directly derived from
    cmp_clk
    FIGURE 5-13 shows the actual usage, i.e., the final sync_en output
    (refer to FIGURE 5-9).
    FIGURE 5-13 Actual Usage of Sync Pulses at Enable Pin of Transfer
    Flops
    Note – Since cmp_io2x_sync_en and io2x_cmp_sync_en are shown at the
    point of
    usage; however, they would both be driven by a single source – cluster
    header->io2x_sync_en ->flop output.
    5-24 OpenSPARC T2 SoC Microarchitecture Specification Part 1 of 2 •
    May 2008
    For clarity, the outputs of cluster headers are also shown. These are,
    as expected
    from FIGURE 5-9, one l2clk cycle early.
    FIGURE 5-14 Sync Enable Positions at the Outputs of Cluster Headers
    prior to being latched.
    5.4.4 CMP/DR Pulses
    CMP to DR pulse positions are determined by the amount of uncertainty
    that can
    exist between cmp_clk and dr_clks. A discussion on the procedure of
    determining
    the positions appears in the AAppendix A.1 – Sync Pulse Design
    Procedure. There
    Chapter 5 Clock Control Unit (CCU) 5-25
    are several documents detailing the sync pulse schemes and timing
    budgets that
    have been created to ensure robustness. An example of the positions of
    the dr sync
    pulses is shown in FIGURE 5-15.
    FIGURE 5-15 Sync Pulse Example for fCMP:fDR = 11:4
    The convention is to describe the sync pulse position in terms of cmp
    clk phases,
    with phase 0 being set to the nominal alignment of cmp and dr clocks.
    The sync
    pulse positions at the point of domain crossing are given in TABLE
    5-6.
    TABLE 5-6 DR<->CMP Sync Pulse Positions
    CMP<->DR Transfer Edge Transfer phase
    (normalized for four dr=2pi)
    K - > clk cycles K - > clk cycles
    N M Meff N/M 0 1 2 3 0 1 2 3
    8 4 1 2.00 1 1 1 1 1 3 5 7
    9 4 4 2.25 1 3 6 8 1 3 6 8
    10 4 2 2.50 1 4 1 4 1 4 6 9
    11 4 4 2.75 1 4 7 10 1 4 7 10
    12 4 1 3.00 1 1 1 1 1 4 7 10
    13 4 4 3.25 2 5 8 11 2 5 8 11
    14 4 2 3.50 2 5 2 5 2 5 9 12
    15 4 4 3.75 2 6 9 13 2 6 9 13
    16 4 1 4.00 2 2 2 2 2 6 10 14
    17 4 4 4.25 2 6 11 15 2 6 11 15
    18 4 2 4.50 2 7 2 7 2 7 11 16
    5-26 OpenSPARC T2 SoC Microarchitecture Specification Part 1 of 2 •
    May 2008
    5.4.5 CMP/SYS Pulses
    There are a pair of sync pulses between CMP and SYS_CLK strictly for
    the RST unit.
    These pulses are not staged on the global clock tree, and not taken in
    through cluster
    headers. However, to account for fanout, the signals are flopped twice
    inside the
    RST cluster. The scheme relies on the RST block being placed close to
    the CCU; there
    is tolerance built in for skew between the CMP and SYS_CLK up to a
    couple of CMP
    cycles.
    The active position of the sync pulse (“1” on rising edge of cmp_clk)
    will be on
    phase two of l2clk. This will provide ample margin, > 1 fast cmp cycle
    for setup or
    hold. Illustrations of data transfers in both directions are shown in
    FIGURE 5-16. For
    quantification of the amount of margin available, refer to Appendix A.
    1 – Sync Pulse
    Design Procedure.
    19 4 4 4.75 2 7 12 17 2 7 12 17
    20 4 1 5.00 2 2 2 2 2 7 12 17
    21 4 4 5.25 3 8 13 18 3 8 13 18
    TABLE 5-6 DR<->CMP Sync Pulse Positions (Continued)
    CMP<->DR Transfer Edge Transfer phase
    (normalized for four dr=2pi)
    K - > clk cycles K - > clk cycles
    Chapter 5 Clock Control Unit (CCU) 5-27
    FIGURE 5-16 Domain Crossing using Sync Pulses in RST

    Reset signals are distributed across all logic digital designs.

    Weng
    Weng Tianxiang, Mar 20, 2010
    #3
  4. fpgabuilder

    rickman Guest

    On Mar 19, 5:31 pm, Jonathan Bromley <>
    wrote:
    > On Fri, 19 Mar 2010 06:32:38 -0700 (PDT), rickman wrote:
    >
    > [Weng]
    >
    > >> there are 6 types of
    > >> reset signals, a situation much more complexer than we think.

    > >Ok, go ahead and tease us!  Or are you going to share with us what the
    > >six types are?

    >
    > 1. Reset that is asserted at the right time,
    >    but has the wrong polarity, thus holding the design
    >    in reset throughout your test.
    > 2. Reset with the right polarity that is not asserted
    >    reliably at power-up, because you were too cheap
    >    to spend $0.70 on a power monitor/watchdog chip.
    > 3. Reset that is triggered at random times during
    >    operation because it is laid out on the PCB too
    >    close to a data bus.  Capacitive coupling causes
    >    reset to be momentarily asserted when more than
    >    80% of the data lines transition simultaneously.
    > 4. Reset that is asserted correctly, but is released
    >    too close to a clock edge and causes the design
    >    to go into an illegal state because some flops
    >    respond to the clock and others don't.
    > 5. Reset of a counter, used by a designer who thought
    >    it would be a cool way to make the counter go back
    >    to zero when it overflows some programmed limit.
    > 6. Reset that is triggered by the operation of a
    >    system-level watchdog.  It causes the CPU to stop
    >    operating roughly a millisecond before emitting
    >    the debug message that would have allowed you
    >    to diagnose the problem.
    >
    > Just in case you thought I was fooling, I should point
    > out that I have had to debug and correct each of these
    > at some point in my career.  One or two of them were
    > someone else's fault :)
    > --
    > Jonathan Bromley


    Then aren't there at least 7 types of reset? You need to include one
    that actually works as expected... or have you never found that one in
    practice ;^)

    Rick
    rickman, Mar 20, 2010
    #4
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Mr. SweatyFinger
    Replies:
    2
    Views:
    1,804
    Smokey Grindel
    Dec 2, 2006
  2. Weng Tianxiang
    Replies:
    14
    Views:
    1,083
    Martin Thompson
    Mar 11, 2010
  3. Ed McGettigan
    Replies:
    0
    Views:
    473
    Ed McGettigan
    Mar 10, 2010
  4. Andy
    Replies:
    19
    Views:
    876
    Andy Peters
    Mar 22, 2010
  5. Andy
    Replies:
    3
    Views:
    492
    fpgabuilder
    Mar 19, 2010
Loading...

Share This Page