Why doesn't this situation generate a latch?
in [FPGA]
|
Prev: Some Active-HDL questions
Next: Call for Papers Reminder (extended): The World Congress on Engineering WCE 2010
From: Weng Tianxiang on 19 Mar 2010 22:28 On Mar 19, 2:31 pm, Jonathan Bromley <jonathan.brom...(a)MYCOMPANY.com> 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 dont 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
From: rickman on 20 Mar 2010 17:34 On Mar 19, 5:31 pm, Jonathan Bromley <jonathan.brom...(a)MYCOMPANY.com> 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
From: Andy Peters on 22 Mar 2010 14:13
On Mar 19, 6:32 am, rickman <gnu...(a)gmail.com> wrote: > Yes, it was a typo... in other words, a mistake... Why do they call > it a "typo". It was a mistake regardless of how you categorize it. "typographical error," in other words, a mistake made by the typesetter, back in the days when such jobs existed. -a |