Constraining an Asynchronous FIFO

Where the interviewer goes next. Open a node to practise that follow-up.

WhyWhat IfProve ItCompareScale It

1. Constraining an Asynchronous FIFO
2. WhyWhy Unrelated Clocks Need an ExceptionL2 Mid-Level

   Why does a FIFO between a 10 ns and a 7 ns clock fail setup by 0.16 ns if you declare no exception at all?

   Reveal the Model Answer

   Without an exception, STA treats the clocks as related. It finds the tightest launch-capture pair over their 70 ns common period. That is launch at 20 ns and capture at 21 ns, only 1 ns apart. The memory-to-read path cannot meet 1 ns, so it fails. Real asynchronous clocks have no fixed phase, so the check is meaningless and must be replaced by the right exceptions.

   1. Cycle 7

      Launch at 0 ns, capture at 7 ns: 7 ns for the path.

   2. Cycle 14

      Launch at 10 ns, capture at 14 ns: 4 ns for the path.

   3. Cycle 21

      Launch at 20 ns, capture at 21 ns: 1 ns for the path.

   The tool times a wclk-to-rclk path against the smallest of these gaps.

   mem5 → rdatasetup check, latest arrival3 cells

   • Clock latency
   • Cell delay
   • Setup time

   1. Launch at 20 ns

      The tool picked the third wclk edge, at 20 ns.

   2. Capture at 21 ns

      The next rclk edge after it is at 21 ns. That pair is the closest the two clocks ever come.

   3. Violated

      Clock-to-Q and two mux levels take 1.0606 ns, so the slack is -0.1605 ns.

   Read the path as a table

   Launch: wclk rise edge at 20.0000 ns, clock latency 0.0000 ns (ideal). Capture: rclk rise edge at 21.0000 ns, latency 0.0000 ns, library setup time −0.0999 ns.

   Arrival 21.0606 ns, required 20.9001 ns, slack −0.1605 ns (violated).

   Cell	Arc	Through	Edge	Delay (ns)	Time (ns)	Slew (ns)
   1	mem5/CLK → mem5/Q	dfxtp_1	fall	0.3040	20.3040	0.0213
   	mem5/Q → rmux_hi/A1	wire m5	fall	0.0000	20.3040	0.0213
   2	rmux_hi/A1 → rmux_hi/X	mux4_1	fall	0.4680	20.7720	0.0797
   	rmux_hi/X → rmux/A1	wire hi	fall	0.0000	20.7720	0.0797
   3	rmux/A1 → rmux/X	mux2_1	fall	0.2886	21.0606	0.0500
   	rmux/X → rdata/D	wire rd	fall	0.0000	21.0606	0.0500

   The report

   Startpoint: mem5 (rising edge-triggered flip-flop clocked by wclk)
   Endpoint: rdata (rising edge-triggered flip-flop clocked by rclk)
   Path Group: rclk
   Path Type: max
   
   Fanout       Cap      Slew     Delay      Time   Description
   -------------------------------------------------------------------------------------
                       0.1000   20.0000   20.0000   clock wclk (rise edge)
                                 0.0000   20.0000   clock network delay (ideal)
                       0.1000    0.0000   20.0000 ^ mem5/CLK (sky130_fd_sc_hd__dfxtp_1)
        1    0.0014    0.0213    0.3040   20.3040 v mem5/Q (sky130_fd_sc_hd__dfxtp_1)
                                                    m5 (net)
                       0.0213    0.0000   20.3040 v rmux_hi/A1 (sky130_fd_sc_hd__mux4_1)
        1    0.0018    0.0797    0.4680   20.7720 v rmux_hi/X (sky130_fd_sc_hd__mux4_1)
                                                    hi (net)
                       0.0797    0.0000   20.7720 v rmux/A1 (sky130_fd_sc_hd__mux2_1)
        1    0.0017    0.0500    0.2886   21.0606 v rmux/X (sky130_fd_sc_hd__mux2_1)
                                                    rd (net)
                       0.0500    0.0000   21.0606 v rdata/D (sky130_fd_sc_hd__dfxtp_1)
                                          21.0606   data arrival time
   
                       0.1000   21.0000   21.0000   clock rclk (rise edge)
                                 0.0000   21.0000   clock network delay (ideal)
                                 0.0000   21.0000   clock reconvergence pessimism
                                          21.0000 ^ rdata/CLK (sky130_fd_sc_hd__dfxtp_1)
                                -0.0999   20.9001   library setup time
                                          20.9001   data required time
   -------------------------------------------------------------------------------------
                                          20.9001   data required time
                                         -21.0606   data arrival time
   -------------------------------------------------------------------------------------
                                          -0.1605   slack (VIOLATED)

   The memory read with no exception: timed against the 1 ns gap, it fails by 0.1605 ns.

   Self-Check

   Tick each key point you covered in your answer.

   Key point 1 Without an exception, STA treats the clocks as related. Key point 2 It finds the tightest launch-capture pair over their 70 ns common period. Key point 3 That is launch at 20 ns and capture at 21 ns, only 1 ns apart. Key point 4 The memory-to-read path cannot meet 1 ns, so it fails. Key point 5 Real asynchronous clocks have no fixed phase, so the check is meaningless and must be replaced by the right exceptions.

   • Lesson L2.6Clocks in SDC
   • Lesson L8.1Capstone: Constrain the Asynchronous FIFO
   • Problem L8.1.1Keep the FIFO Crossings Visible
3. Prove ItSolve L8.1.1: Keep the FIFO Crossings VisibleSimulator-graded

   Show it, don't just say it: this Silicon Lab problem is graded by the simulator.

   Open Problem L8.1.1

4. CompareFalse Path vs Multicycle PathL1 JuniorL2 Mid-Level

   Compare a false path with a multicycle path. When is each the right exception?

   Reveal the Model Answer

   A false path removes paths from timing entirely. It is for signals that can never propagate in one cycle in practice, such as static configuration written before use. A multicycle path keeps the check but gives it N cycles, for data that is guaranteed stable for N cycles. A false path is the riskier promise, because a wrong one hides a real path forever; never false-path a reset release.

   Self-Check

   Tick each key point you covered in your answer.

   Key point 1 A false path removes paths from timing entirely. Key point 2 It is for signals that can never propagate in one cycle in practice, such as static configuration written before use. Key point 3 A multicycle path keeps the check but gives it N cycles, for data that is guaranteed stable for N cycles. Key point 4 A false path is the riskier promise, because a wrong one hides a real path forever; never false-path a reset release.

   • Lesson L2.8False Paths and Multicycle Paths
5. What IfA Configuration Register Written While RunningL2 Mid-Level

   What if software writes the false-pathed configuration register while the block is running?

   Reveal the Model Answer

   Then the false path is no longer true. The new value can reach a capture flop in any cycle, untimed. Some bits may then be caught a cycle late or go metastable. Either forbid writes while the block runs, and check that rule with an assertion. Or time the path for real.

   Self-Check

   Tick each key point you covered in your answer.

   Key point 1 Then the false path is no longer true. Key point 2 The new value can reach a capture flop in any cycle, untimed. Key point 3 Some bits may then be caught a cycle late or go metastable. Key point 4 Either forbid writes while the block runs, and check that rule with an assertion. Key point 5 Or time the path for real.

   Half-Truth

   "It is a configuration register, so it is always a false path."

   The exception holds only if software writes it before use. A write in mission mode makes the path real.

   Source Lesson L2.8 key points

   • Lesson L2.8False Paths and Multicycle Paths
   • Problem L2.8.1Restore the Same-Edge Hold Check
6. Scale ItAuditing Constraints on a Large ChipL3 Senior

   You inherit SDC for a chip with forty clocks. How do you audit it before trusting any timing result?

   Reveal the Model Answer

   Check coverage first: every register clocked, every port with a delay, zero unexplained unconstrained endpoints. Then review every exception against a written reason, since a false path or clock group trusted by STA removes checks for good. Compare the clock relationships with the design spec and the CDC report. Re-run the audit whenever the SDC or the netlist changes.

   Self-Check

   Tick each key point you covered in your answer.

   Key point 1 Check coverage first: every register clocked, every port with a delay, zero unexplained unconstrained endpoints. Key point 2 Then review every exception against a written reason, since a false path or clock group trusted by STA removes checks for good. Key point 3 Compare the clock relationships with the design spec and the CDC report. Key point 4 Re-run the audit whenever the SDC or the netlist changes.

   • Lesson L7.1Sign-Off Timing: Every Corner, Every Check
   • Lesson L2.8False Paths and Multicycle Paths
   • Lesson L8.1Capstone: Constrain the Asynchronous FIFO
7. What IfA False Path That Swallowed Real PathsL1 JuniorL2 Mid-Level

   Asked if they propose a false path between the clocks

   To silence one slow configuration input, someone writes the line below. What else disappears from timing?

   set_false_path -from [all_inputs]

   Reveal the Model Answer

   Every path from every input, including the clock-domain data inputs that really do need timing. In lesson L2.8 that line turned two flop data pins into unconstrained endpoints. A report through the data input then found no paths at all. Writing the exception on the one port, -from [get_ports cfg], left the other path timed with 0.5837 ns of slack.

   d0 → a0_regsetup check, latest arrival0 cells

   • Clock latency
   • Cell delay
   • Input delay
   • Setup time

   Read the path as a table

   Launch: clk rise edge at 0.0000 ns, clock latency 0.0000 ns (ideal). Capture: clk rise edge at 1.0000 ns, latency 0.0000 ns, library setup time −0.2163 ns.

   Arrival 0.2000 ns, required 0.7837 ns, slack 0.5837 ns (met).

   Cell	Arc	Through	Edge	Delay (ns)	Time (ns)	Slew (ns)
   	d0 → a0_reg/D	wire d0	fall	0.0000	0.2000	0.0000

   The report

   Startpoint: d0 (input port clocked by clk)
   Endpoint: a0_reg (rising edge-triggered flip-flop clocked by clk)
   Path Group: clk
   Path Type: max
   
   Fanout       Cap      Slew     Delay      Time   Description
   -------------------------------------------------------------------------------------
                       0.1000    0.0000    0.0000   clock clk (rise edge)
                                 0.0000    0.0000   clock network delay (ideal)
                                 0.2000    0.2000 v input external delay
        1    0.0017    0.0000    0.0000    0.2000 v d0 (in)
                                                    d0 (net)
                       0.0000    0.0000    0.2000 v a0_reg/D (sky130_fd_sc_hd__edfxtp_1)
                                           0.2000   data arrival time
   
                       0.1000    1.0000    1.0000   clock clk (rise edge)
                                 0.0000    1.0000   clock network delay (ideal)
                                 0.0000    1.0000   clock reconvergence pessimism
                                           1.0000 ^ a0_reg/CLK (sky130_fd_sc_hd__edfxtp_1)
                                -0.2163    0.7837   library setup time
                                           0.7837   data required time
   -------------------------------------------------------------------------------------
                                           0.7837   data required time
                                          -0.2000   data arrival time
   -------------------------------------------------------------------------------------
                                           0.5837   slack (MET)

   With the exception written only on cfg, the path from d0 is timed again: slack 0.5837 ns.

   Self-Check

   Tick each key point you covered in your answer.

   Key point 1 Every path from every input, including the clock-domain data inputs that really do need timing. Key point 2 In lesson L2.8 that line turned two flop data pins into unconstrained endpoints. Key point 3 A report through the data input then found no paths at all. Key point 4 Writing the exception on the one port, -from [get_ports cfg], left the other path timed with 0.5837 ns of slack.

   • Lesson L2.8False Paths and Multicycle Paths
8. What IfA False Path That Covers the ResetL1 JuniorL2 Mid-Level

   What if the same broad false path also covers the reset input?

   Reveal the Model Answer

   Then the reset release has no recovery or removal check. A release near the clock edge can leave some flops in reset for one cycle longer than others. The design then starts in a mixed state. Time the release through its synchroniser, and keep recovery and removal checked.

   Self-Check

   Tick each key point you covered in your answer.

   Key point 1 Then the reset release has no recovery or removal check. Key point 2 A release near the clock edge can leave some flops in reset for one cycle longer than others. Key point 3 The design then starts in a mixed state. Key point 4 Time the release through its synchroniser, and keep recovery and removal checked.

   Misconception

   "Reset is asynchronous, so it needs no timing."

   Asserting it is asynchronous, but releasing it is checked against the clock by recovery and removal arcs.

   Source Lesson L2.1 key points

   • Lesson L2.8False Paths and Multicycle Paths
   • Lesson L2.1Timing Arcs: What a Cell Promises