URL
https://opencores.org/ocsvn/openmsp430/openmsp430/trunk
Subversion Repositories openmsp430
[/] [openmsp430/] [trunk/] [doc/] [html/] [asic_implementation.html] - Rev 224
Go to most recent revision | Compare with Previous | Blame | View Log
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"> <html><head><title>openMSP430 ASIC Implementation</title> <meta http-equiv="content-type" content="text/html; charset=utf-8"> <meta http-equiv="content-type" content="text/html; charset=utf-8"> <meta http-equiv="content-type" content="text/html; charset=utf-8"> <meta http-equiv="content-type" content="text/html; charset=utf-8"> <meta http-equiv="content-type" content="text/html; charset=utf-8"> <meta http-equiv="content-type" content="text/html; charset=utf-8"> <meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body> <h3>Table of content</h3> <ul> <li><a href="#1_Introduction">1. Introduction</a></li> <li><a href="#2_RTL_Configuration"> 2. RTL Configuration</a> <ul> <li><a href="#2_1_1_Low_Frequency_Clock_Domain"> 2.1 Basic Clock Module</a></li> <ul> <li><a href="#2_1_1_Low_Frequency_Clock_Domain"> 2.1.1 Low-frequency clock domain</a></li> </ul> <ul> <li><a href="#2_1_2_Clock_Muxes"> 2.1.2 Clock muxes</a></li> </ul> <ul> <li><a href="#2_1_3_Clock_Dividers"> 2.1.3 Clock dividers</a></li> </ul> <ul> <li><a href="#2_1_4_Low_Power_Modes">2.1.4 Low-Power modes</a></li> <ul> <li><a href="#2_1_4_1_Internal_clocks">2.1.4.1 Internal clocks ( MCLK / SMCLK )</a><br> </li> <li><a href="#2_1_4_2_Clock_oscillators">2.1.4.2 Clock oscillators ( DCO_CLK / LFXT_CLK )</a><br> </li> </ul> </ul> <li><a href="#2_2_Other_configuration_options">2.2 Other configuration options</a><br> </li> <ul> <li><a href="#2_2_1_Fine_Grained_Clock_Gating"> 2.2.1 Fine grained clock gating</a></li> </ul> <ul> <li><a href="#2_2_2_Watchdog_Clock_Mux"> 2.2.2 Watchdog clock mux</a></li> </ul> </ul> </li> <li><a href="#3._DFT_Considerations"> 3. DFT considerations</a></li> <ul> <li><a href="#3_1_Resets">3.1 Resets</a></li> <li><a href="#3_2_Clock_Gates">3.2 Clock Gates</a></li> <li><a href="#3_3_Clock_Muxes">3.3 Clock Muxes</a></li> <li><a href="#3_4_Coverage">3.4 Coverage</a></li> </ul> <li><a href="#4_Sensitive_Modules"> 4. Sensitive modules</a><br> <ul> <li><a href="#4_1_AND_Gate"> 4.1 AND Gate ( <span style="font-style: italic;">omsp_and_gate.v</span> )<br> </a></li> <li><a href="#4_2_Clock_Gate">4.2 Clock Gate ( <span style="font-style: italic;">omsp_clock_gate.v</span> )</a></li> <li><a href="#4_3_Clock_Mux">4.3 Clock Mux ( <span style="font-style: italic;">omsp_clock_mux.v</span> )</a></li> <li><a href="#4_4_Scan_Mux">4.4 Scan Mux ( <span style="font-style: italic;">omsp_scan_mux.v</span> )</a></li> <li><a href="#4_5_Sync_Cell">4.5 Sync Cell ( <span style="font-style: italic;">omsp_sync_cell.v</span> )</a></li> <li><a href="#4_6_Sync_Reset">4.6 Sync Reset ( <span style="font-style: italic;">omsp_sync_reset.v</span> )</a></li> <li><a href="#4_7_Wakeup_Cell">4.7 Wakeup Cell ( <span style="font-style: italic;">omsp_wakeup_cell.v</span> )</a></li> </ul> </li> </ul> <a name="1_Introduction"></a> <h1>1. Introduction</h1> This section covers specific points of the openMSP430 ASIC implementation, in particular:<br> <ul> <ul> <ul> <li>The ASIC specific RTL configuration options.</li> <li>Some DFT considerations.</li> <li>A description of each ASIC sensitive module.<br> </li> </ul> </ul> </ul> Keep in mind that as no exotic design technique were used in the openMSP430, following a standard implementation flow from Synthesis to P&R is the best way to go.<br> <br> <br> <a name="2_RTL_Configuration"></a> <h1>2. RTL Configuration</h1> Whenever the "<span style="font-weight: bold; font-style: italic;">`define ASIC</span>" statement of the <a style="font-style: italic;" href="http://opencores.org/project,openmsp430,core#2.1.3.3%20Expert%20System%20Configuration">Expert System Configuration</a> section is uncommented, all ASIC specific configuration options are enabled.<br> <a name="2_1_Basic_Clock_Module"></a> <h2>2.1 Basic Clock Module</h2> In its ASIC configuration, the Basic clock module of the openMSP430 can support <span class="Apple-style-span" style="color: rgb(0, 0, 0); font-family: 'Times New Roman'; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; font-size: medium;"><span class="Apple-converted-space"> </span>up to all features described in the<span class="Apple-converted-space"> </span><a href="http://www.ti.com/litv/pdf/slau049f">MSP430x1xx Family User's Guide</a><span class="Apple-converted-space"> </span>(Chapter 4).<br> </span><br> In particular, the <span style="font-weight: bold; font-style: italic;">ASIC_CLOCKING</span> option activates all advancd clocking options (note that formal equivalence with the FPGA version is achieved by commenting this option out):<br> <br> <table border="0" cellpadding="0" cellspacing="4"> <tbody> <tr> <td width="35"><br> </td> <td bgcolor="#d0d0d0" width="3"><br> </td> <td width="15"><br> </td> <td> <code>//===============================================================<br> // ASIC CLOCKING<br> //===============================================================<br> <br> //-------------------------------------------------------<br> // When uncommented, this define will enable the ASIC<br> // architectural clock gating as well as the advanced low<br> // power modes support (most common).<br> // Comment this out in order to get FPGA-like clocking.<br> //-------------------------------------------------------<br> `define ASIC_CLOCKING<br> <br> </code></td> </tr> </tbody> </table> <br> <span class="Apple-style-span" style="color: rgb(0, 0, 0); font-family: 'Times New Roman'; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; font-size: medium;">All these advanced clocking options are highlighted in the following diagram and discussed below:<br> <br> </span> <div style="text-align: center;"><img alt="Clock Module ASIC configuration" src="http://opencores.org/usercontent,img,1321995017" width="80%"><br> </div> <a name="2_1_1_Low_Frequency_Clock_Domain"></a> <h3>2.1.1 Low-Frequency Clock Domain</h3> The LFXT clock domain can be enabled thanks to the following configuration option:<br> <span class="Apple-style-span" style="color: rgb(0, 0, 0); font-family: 'Times New Roman'; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; font-size: medium;"><span class="Apple-converted-space"> </span></span><span class="Apple-style-span" style="color: rgb(0, 0, 0); font-family: 'Times New Roman'; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; font-size: medium;"><span class="Apple-converted-space"> </span></span><span class="Apple-style-span" style="color: rgb(0, 0, 0); font-family: 'Times New Roman'; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; font-size: medium;"><span class="Apple-converted-space"> </span></span><br> <table border="0" cellpadding="0" cellspacing="4"> <tbody> <tr> <td width="35"><br> </td> <td bgcolor="#d0d0d0" width="3"><br> </td> <td width="15"><br> </td> <td> <code>//============================================================================<br> // LFXT CLOCK DOMAIN<br> //============================================================================<br> <br> //-------------------------------------------------------<br> // When uncommented, this define will enable the lfxt_clk<br> // clock domain.<br> // When commented out, the whole chip is clocked with dco_clk.<br> //-------------------------------------------------------<br> `define LFXT_DOMAIN<br> <br> </code></td> </tr> </tbody> </table> <br> <span style="font-style: italic; font-weight: bold; text-decoration: underline;">Note 1:</span> When commented-out:<br> <ul> <ul> <ul> <li><span style="font-style: italic;">ACLK</span> is running on <span style="font-style: italic;">DCO_CLK</span></li> <li>MCLK_MUX and SMCLK_MUX options are not supported</li> <li>OSCOFF_EN low power mode is not supported<span style="font-style: italic;"><br> </span></li> </ul> </ul> </ul> <span style="font-weight: bold; font-style: italic; text-decoration: underline;">Note 2:</span> Unlike its name suggest, there is no frequency limitation on <span style="font-style: italic;">LFXT_CLK</span>. The name was simply kept in order to be consistent with the original MSP430 documentation, where <span style="font-style: italic;">LFXT_CLK</span> is typically connected to a 32 kHz crystal oscillator.<br> <br> <a name="2_1_2_Clock_Muxes"></a><br> <h3>2.1.2 Clock Muxes</h3> The <span style="font-style: italic;">MCLK</span> and <span style="font-style: italic;">SMCLK</span> clock muxes can be enabled or disabled with the following options:<br> <br> <table border="0" cellpadding="0" cellspacing="4"> <tbody> <tr> <td width="35"><br> </td> <td bgcolor="#d0d0d0" width="3"><br> </td> <td width="15"><br> </td> <td> <code>//============================================================================<br> // CLOCK MUXES<br> //============================================================================<br> <br> //-------------------------------------------------------<br> // MCLK: Clock Mux<br> //-------------------------------------------------------<br> // When uncommented, this define will enable the<br> // MCLK clock MUX allowing the selection between<br> // DCO_CLK and LFXT_CLK with the BCSCTL2.SELMx register.<br> // When commented, DCO_CLK is selected.<br> //-------------------------------------------------------<br> `define MCLK_MUX<br> <br> //-------------------------------------------------------<br> // SMCLK: Clock Mux<br> //-------------------------------------------------------<br> // When uncommented, this define will enable the<br> // SMCLK clock MUX allowing the selection between<br> // DCO_CLK and LFXT_CLK with the BCSCTL2.SELS register.<br> // When commented, DCO_CLK is selected.<br> //-------------------------------------------------------<br> `define SMCLK_MUX<br> <br> </code></td> </tr> </tbody> </table> <br> <span style="font-style: italic; font-weight: bold; text-decoration: underline;">Note 1:</span> When a MUX is excluded, the concerned clock (<span style="font-style: italic;">MCLK</span> and/or <span style="font-style: italic;">SMCLK) is</span> running with <span style="font-style: italic;">DCO_CLK</span>.<br> <br> <span style="font-weight: bold; font-style: italic; text-decoration: underline;">Note 2:</span> If a MUX is included, the implementation and sign-off tools (in particular CTS and STA) must be aware that a new clock needs to be defined on the MUX output.<br> <br> <br> <a name="2_1_3_Clock_Dividers"></a> <h3>2.1.3 Clock Dividers</h3> The <span style="font-style: italic;">MCLK</span>, <span style="font-style: italic;">SMCLK</span> and ACLK clock dividers can be enabled or disabled with the following options:<br> <br> <table border="0" cellpadding="0" cellspacing="4"> <tbody> <tr> <td width="35"><br> </td> <td bgcolor="#d0d0d0" width="3"><br> </td> <td width="15"><br> </td> <td> <code>//============================================================================<br> // CLOCK DIVIDERS<br> //============================================================================<br> <br> //-------------------------------------------------------<br> // MCLK: Clock divider<br> //-------------------------------------------------------<br> // When uncommented, this define will enable the<br> // MCLK clock divider (/1/2/4/8)<br> //-------------------------------------------------------<br> `define MCLK_DIVIDER<br> <br> //-------------------------------------------------------<br> // SMCLK: Clock divider (/1/2/4/8)<br> //-------------------------------------------------------<br> // When uncommented, this define will enable the<br> // SMCLK clock divider<br> //-------------------------------------------------------<br> `define SMCLK_DIVIDER<br> <br> //-------------------------------------------------------<br> // ACLK: Clock divider (/1/2/4/8)<br> //-------------------------------------------------------<br> // When uncommented, this define will enable the<br> // ACLK clock divider<br> //-------------------------------------------------------<br> `define ACLK_DIVIDER<br> <br> </code></td> </tr> </tbody> </table> <br> The clock dividers instantiate a clock gate on the clock tree and are implemented as following:<br> <br> <div style="text-align: center;"><img alt="Clock Divider" src="http://opencores.org/usercontent,img,1322310000" width="50%"><br> </div> <br> <a name="2_1_4_Low_Power_Modes"></a> <h3>2.1.4 Low-Power Modes</h3> <a name="2_1_4_1_Internal_clocks"><br> </a><span style="font-weight: bold;">2.1.4.1 Internal clocks ( MCLK / SMCLK )</span><br> <br> Two bit fields in the status register (R2) allow to control the system clocks:<br> <ul> <ul> <ul> <li><span style="font-weight: bold;">CPUOFF</span> allows to switch-off <span style="font-style: italic;">MCLK</span></li> <li><span style="font-weight: bold;">SCG1</span> allows to switch-off <span style="font-style: italic;">SMCLK</span><br> </li> </ul> </ul> </ul> These control bits are supported by the openMSP430 and can be included in the design with the following defines:<br> <br> <table border="0" cellpadding="0" cellspacing="4"> <tbody> <tr> <td width="35"><br> </td> <td bgcolor="#d0d0d0" width="3"><br> </td> <td width="15"><br> </td> <td><code>//============================================================================<br> // LOW POWER MODES<br> //============================================================================<br> <br> //-------------------------------------------------------<br> // LOW POWER MODE: CPUOFF<br> //-------------------------------------------------------<br> // When uncommented, this define will include the<br> // clock gate allowing to switch off MCLK in<br> // all low power modes: LPM0, LPM1, LPM2, LPM3, LPM4<br> //-------------------------------------------------------<br> `define CPUOFF_EN<br> <br> //-------------------------------------------------------<br> // LOW POWER MODE: SCG1<br> //-------------------------------------------------------<br> // When uncommented, this define will include the<br> // clock gate allowing to switch off SMCLK in<br> // the following low power modes: LPM2, LPM3, LPM4<br> //-------------------------------------------------------<br> `define SCG1_EN<br> <br> </code></td> </tr> </tbody> </table> <br> In order to keep the clock tree as flat as possible, the CPUOFF and SCG1 low power options share the same clock gate with the clock divider:<br> <br> <div style="text-align: center;"><img alt="Clock Divider and low power" src="http://opencores.org/usercontent,img,1322310023" width="50%"><br> </div> <a name="2_1_4_2_Clock_oscillators"><br> </a><span style="font-weight: bold;">2.1.4.2 Clock oscillators ( DCO_CLK / LFXT_CLK )</span><br> <br> There are two bit fields in the status register (R2) allowing to control the clock oscillators:<br> <ul> <ul> <ul> <li><span style="font-weight: bold;">SCG0</span> allows to switch-off the DCO oscillator<span style="font-style: italic;"></span></li> <li><span style="font-weight: bold;">OSCOFF</span> allows to switch-off the LFXT oscillator<span style="font-style: italic;"></span><br> </li> </ul> </ul> </ul> These control bits are supported by the openMSP430 and can be included in the design with the following defines:<br> <br> <table border="0" cellpadding="0" cellspacing="4"> <tbody> <tr> <td width="35"><br> </td> <td bgcolor="#d0d0d0" width="3"><br> </td> <td width="15"><br> </td> <td><code>//============================================================================<br> // LOW POWER MODES<br> //============================================================================<br> <br> //-------------------------------------------------------<br> // LOW POWER MODE: SCG0<br> //-------------------------------------------------------<br> // When uncommented, this define will enable the<br> // DCO_ENABLE/WKUP port control (always 1 when commented).<br> // This allows to switch off the DCO oscillator in the<br> // following low power modes: LPM1, LPM3, LPM4<br> //-------------------------------------------------------<br> `define SCG0_EN<br> <br> //-------------------------------------------------------<br> // LOW POWER MODE: OSCOFF<br> //-------------------------------------------------------<br> // When uncommented, this define will include the<br> // LFXT_CLK clock gate and enable the LFXT_ENABLE/WKUP<br> // port control (always 1 when commented).<br> // This allows to switch off the low frequency oscillator<br> // in the following low power modes: LPM4<br> //-------------------------------------------------------<br> `define OSCOFF_EN<br> <br> </code></td> </tr> </tbody> </table> <br> The control logic of both DCO and LFXT oscillators is identical.<br> <br> When disabled, the <span style="font-weight: bold;">*_WKUP</span> signal is used to asynchronously wake up the oscillator. Once the oscillator is awake (and therefore a clock is available), the <span style="font-weight: bold;">*_ENABLE</span> signal will take over and synchronously keep the oscillator enabled until the CPU clears the SCG0 or OSCOFF bit again.<br> <br> The following two waveforms illustrate the CPU entering the LPM1 mode, and in particular the DCO oscillator being switched-off:<br> <ul> <li>Entering LPM1 through a <span style="font-weight: bold; font-style: italic; color: rgb(51, 51, 153);">BIS #N, R2</span> instruction:</li> </ul> <img alt="Entering LPM1 with BIS" src="http://opencores.org/usercontent,img,1322600748" width="100%"><br> <ul> <li>Entering LPM1 through a <span style="font-weight: bold; font-style: italic; color: rgb(51, 51, 153);">RETI</span> instruction:<br> </li> </ul> <img alt="Entering LPM1 with RETI" src="http://opencores.org/usercontent,img,1322600763" width="100%"><br> <br> <span style="font-weight: bold; text-decoration: underline;">Note:</span> the DCO oscillator is enabled until the BIS and RETI instruction are fully executed (i.e. until the CPU state machines reach their IDLE state).<br> <br> <br> At last, this waveform shows the CPU going out of LPM1 mode and in particular the DCO oscillator wake-up sequence:<br> <br> <img alt="Wakeup from LPM1" src="http://opencores.org/usercontent,img,1322602185" width="100%"><br> <br> In order to wake-up the CPU from ANY low power mode, the system <span style="font-weight: bold;">MUST ALWAYS</span> go through the following chain of events (as illustrated in the previous waveform):<br> <ul> <ul> <ol> <li style="color: red;"> <span style="color: black;">The peripheral (for example a timer) asserts the </span><span style="font-weight: bold; font-style: italic; color: black;">WKUP</span><span style="color: black;"> input of the openMSP430 in order to asynchronously restore the clocks. At this stage, </span><span style="font-weight: bold; font-style: italic; color: black;">DCO_WKUP</span><span style="color: black;"> is activated and </span><span style="font-weight: bold; font-style: italic; color: black;">DCO_ENABLE</span><span style="color: black;"> is still cleared.</span></li> <li style="color: red;"> <span style="color: black;">Once MCLK is available, the peripheral generates a synchronous IRQ signal in order to re-activate the CPU state machines.</span></li> <li style="color: red;"> <span style="color: black;">The CPU state machines activated, </span><span style="font-weight: bold; font-style: italic; color: black;">DCO_ENABLE</span><span style="color: black;"> is synchronously set.</span><br> </li> <li style="color: red;"> <span style="color: black;">When the global interrupt enable flag (GIE) is cleared, <span style="font-weight: bold; font-style: italic;">DCO_WKUP</span> is released two clock cycles later (i.e. same behavior as a reset synchronizer).<br> <span style="font-weight: bold; text-decoration: underline;">Important note:</span> the peripheral should release the </span><span style="font-weight: bold; font-style: italic; color: black;">WKUP</span><span style="color: black;"> input when its interrupt pending flag is cleared</span><span style="font-weight: bold; font-style: italic; color: black;"></span><span style="color: black;">. Otherwise the <span style="font-weight: bold; font-style: italic;">DCO_WKUP</span> signal will be set again as soon as the GIE flag is restored by the RETI instruction... which is probably not the intended behavior :-P<br> </span></li> <li style="color: red;"><span style="color: black;">The DCO oscillator is now enabled until SCG0 is set again.</span><br> </li> </ol> </ul> </ul> <br> <a name="2_2_Other_configuration_options"></a> <h2>2.2 Other configuration options</h2> <a name="2_2_1_Fine_Grained_Clock_Gating"></a> <h3>2.2.1 Fine Grained Clock Gating</h3> Nowadays, all synthesis tools support automatic (fine grained) clock gating insertion.<br> However, as some design houses still prefer to have the clock gates directly instantiated in the RTL, there is the possibility to include the <span style="font-style: italic;">'manual</span>' fine grained clock gates in the design with the following define:<br> <br> <table border="0" cellpadding="0" cellspacing="4"> <tbody> <tr> <td width="35"><br> </td> <td bgcolor="#d0d0d0" width="3"><br> </td> <td width="15"><br> </td> <td><code>//============================================================================<br> // FINE GRAINED CLOCK GATING<br> //============================================================================<br> <br> //-------------------------------------------------------<br> // When uncommented, this define will enable the fine<br> // grained clock gating of all registers in the core.<br> //-------------------------------------------------------<br> `define CLOCK_GATING<br> <br> </code></td> </tr> </tbody> </table> <br> <br> <a name="2_2_2_Watchdog_Clock_Mux"></a> <h3>2.2.2 Watchdog Clock Mux</h3> <span class="Apple-style-span" style="color: rgb(0, 0, 0); font-family: 'Times New Roman'; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; font-size: medium;">The watchdog clock <span class="Apple-converted-space"><span style="font-style: italic;"></span></span><span style="font-style: italic;"></span><span class="Apple-converted-space"></span><span class="Apple-converted-space"></span><span style="font-style: italic;"></span><span class="Apple-converted-space"></span>mux allows to select between <span style="font-style: italic;">ACLK</span> and <span style="font-style: italic;">SMCLK</span>. It can be enabled or disabled with the <span style="font-weight: bold;">WATCHDOG_MUX</span> define.<br> </span>When excluded, the additional <span style="font-weight: bold;">WATCHDOG_NOMUX_ACLK</span> option allows the user to decide if the watchdog clock should be hard-wired to <span style="font-style: italic;">ACLK</span> (if uncommented) or <span style="font-style: italic;">SMCLK</span> (if commented-out)<br> <br> <table border="0" cellpadding="0" cellspacing="4"> <tbody> <tr> <td width="35"><br> </td> <td bgcolor="#d0d0d0" width="3"><br> </td> <td width="15"><br> </td> <td> <code>//============================================================================<br> // CLOCK MUXES<br> //============================================================================<br> <br> //-------------------------------------------------------<br> // WATCHDOG: Clock Mux<br> //-------------------------------------------------------<br> // When uncommented, this define will enable the<br> // Watchdog clock MUX allowing the selection between<br> // ACLK and SMCLK with the WDTCTL.WDTSSEL register.<br> // When commented out, ACLK is selected if the<br> // WATCHDOG_NOMUX_ACLK define is uncommented, SMCLK is<br> // selected otherwise.<br> //-------------------------------------------------------<br> `define WATCHDOG_MUX<br> //`define WATCHDOG_NOMUX_ACLK<br> <br> </code></td> </tr> </tbody> </table> <br> <a name="3_DFT_Considerations"></a><br> <h1><a name="3._DFT_Considerations"></a>3. DFT Considerations</h1> The openMSP430 is designed to be fully scan friendly. During production, the ATE controls the core through the <span style="font-weight: bold; font-style: italic;">scan_mode</span> and <span style="font-weight: bold; font-style: italic;">scan_enable</span> signals. The <span style="font-weight: bold; font-style: italic;">scan_mode</span> port is always asserted during scan testing and is used to switch between functional and scan mode.<br> <a name="3_1_Resets"></a><br> <h2>3.1 Resets</h2> When in scan mode (i.e. <span style="font-weight: bold; font-style: italic;">scan_mode</span> input port is set), <span style="font-weight: bold;">ALL</span> internal resets of the openMSP430 are connected the <span style="font-style: italic; font-weight: bold;">reset_n</span> input port.<br> Taking the <span style="font-weight: bold; font-style: italic;">POR</span> generation as an example, it is implemented using the <span style="font-weight: bold;">omsp_scan_mux</span> module as following:<br> <br> <div style="text-align: center;"><img alt="DFT Reset" src="http://opencores.org/usercontent,img,1330808995" width="50%"><br> </div> <a name="3_2_Clock_Gates"></a> <h2>3.2 Clock Gates<br> </h2> When in scan mode (i.e. <span style="font-weight: bold; font-style: italic;">scan_mode</span> input port is set), <span style="font-weight: bold;">ALL</span> clock gates instantiated in the design must<span style="font-weight: bold;"> </span>be enabled during scan shifting. This is can be achieved by setting the <span style="font-weight: bold; font-style: italic;">scan_enable</span> input port during the shift phase.<br> On the other hand, during the capture phase, the <span style="font-weight: bold; font-style: italic;">scan_enable</span> port must be cleared in order to restore the functional behavior of the clock gate.<br> <br> This feature is implemented in the <span style="font-weight: bold;">omsp_clock_gate</span> module as following:<br> <br> <div style="text-align: center;"><img alt="DFT Clock Gate" src="http://opencores.org/usercontent,img,1322775594" width="50%"><br> </div> <a name="3_3_Clock_Muxes"></a> <h2>3.3 Clock Muxes</h2> When in scan mode (i.e. <span style="font-weight: bold; font-style: italic;">scan_mode</span> input port is set), the <span style="font-weight: bold; font-style: italic;">MCLK</span> and <span style="font-weight: bold; font-style: italic;">SMCLK</span> clock muxes are both running on <span style="font-weight: bold; font-style: italic;">DCO_CLK</span>. The watchdog mux is running <span style="font-weight: bold; font-style: italic;">SMCLK</span> (i.e. DCO_CLK).<br> <br> This feature is implemented in the <span style="font-weight: bold;">omsp_clock_mux</span> module as following:<br> <br> <div style="text-align: center;"><img alt="DFT Clock MUX" src="http://opencores.org/usercontent,img,1322775611" width="50%"><br> </div> <br> <span style="font-weight: bold; text-decoration: underline;">Note:</span> if the LFXT clock domain is enabled, the <span style="font-weight: bold; font-style: italic;">LFXT_CLK</span> input port should also be connected to the scan clock when in scan mode.<br> <a name="3_4_Coverage"></a> <h2>3.4 Coverage</h2> After synthesizing the openMSP430 in its maximum configuration (in particular with ALL clock domains available and ALL clock muxes included), the core reaches <span style="font-weight: bold;">99.7%</span> stuck-at fault coverage:<br> <br> <div style="text-align: center;"><img alt="Tetramax" src="http://opencores.org/usercontent,img,1331154317" width="50%"><br> </div> <br> <br> <a name="4_Sensitive_Modules"></a><br> <h1>4. Sensitive Modules</h1> ALL modules discussed in this section have a simple and well defined functionality but nonetheless lay on sensitive parts of the design (clock tree, wake-up path, ...).<br> <br> In the industry, it is common place for companies to have policies recommending designers to use textbook structures or specific standard cells when implementing circuits considered as 'sensitive'.<br> This section will hopefully help to quickly identify these 'sensitive' circuits and adapt them to your requirements if necessary.<br> <br> <a name="4_1_AND_Gate"></a> <h2>4.1 AND Gate (<span style="font-style: italic;"> omsp_and_gate.v</span> )<br> </h2> This module implements a simple AND2 gate and is instantiated several times on the wake-up paths in order to ensure a glitch free generation of the wake-up signals. The idea behind this block is to prevent the synthesis tool from optimizing the combinatorial wake-up path and potentially generate a glitchy logic.<br> <br> There are three different ways to handle this block:<br> <ol> <li>Do nothing<br> </li> <li>Modify the RTL by directly instantiating an AND2 cell from the target library and applying a <span style="font-weight: bold; font-style: italic;">don't touch</span> or <span style="font-weight: bold; font-style: italic;">size only</span> attribute on it before proceeding to the synthesis compile step<br> </li> <li>Keep the RTL unchanged and when running synthesis, first compile this module separately before going to the top down compile (don't forget the <span style="font-weight: bold; font-style: italic;">don't touch</span> or <span style="font-weight: bold; font-style: italic;">size only</span> attribute)<br> </li> </ol> Note that the first option is actually acceptable because in low power mode, there are no clocks available, which means no glitch... However, in active mode, the wake-up line could see a lot of glitches, which is functionally not a problem (since the core is awake anyway) but could be considered as not really elegant...<br> <br> <a name="4_2_Clock_Gate"></a> <h2>4.2 Clock Gate (<span style="font-style: italic;"> omsp_clock_gate.v</span> )<br> </h2> Almost every company has a different policy for handling clock gates. Therefore, this module is probably the most likely to be modified. <br> <br> So here are the facts:<br> <ul> <li>There are only rising edge flip-flop in the design<b><sup><font color="#ff0000">1</font></sup></b><br> <span class="Apple-style-span" style="color: rgb(51, 51, 51); font-family: Arial,Verdana,sans-serif; font-size: 13px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: 18px; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; background-color: rgb(255, 255, 255);"><b style="margin: 0px; padding: 0px;">→</b></span> as a consequence clock gates can indifferently park the clock high or low without affecting functionality.<br> <br> </li> <li>The enable signal of ALL clock gates in the openMSP430 are generated with the rising edge of the clock<br> <span class="Apple-style-span" style="color: rgb(51, 51, 51); font-family: Arial,Verdana,sans-serif; font-size: 13px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: 18px; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; background-color: rgb(255, 255, 255);"><b style="margin: 0px; padding: 0px;">→</b></span> this leaves the door open for both LATCH and NAND2 based clock gates.<br> </li> </ul> <small style="font-style: italic;"><b><sup><font color="#ff0000">1</font></sup></b><span style="color: red; font-weight: bold;"></span>: beside for the DCO_ENABLE and LFXT_ENABLE signals and the clock MUXes. However, these can be safely ignored</small><br> <br> As a consequence, you can feel free to use:<br> <ul> <li>A LATCH based clock gate. For example:<br> <div style="text-align: center;"><img alt="Clock Gate Latch" src="http://opencores.org/usercontent,img,1328475744" width="50%"><br> </div> </li> <li>Or a NAND2 based clock gate:<br> </li> </ul> <div style="text-align: center;"><img alt="Clock Gate NAND2" src="http://opencores.org/usercontent,img,1328475770" width="30%"><br> </div> <br> <a name="4_3_Clock_Mux"></a> <h2>4.3 Clock Mux ( <span style="font-style: italic;">omsp_clock_mux.v</span> )<br> </h2> The clock muxes of the openMSP430 are implemented as following:<br> <div style="text-align: center;"><img alt="Clock Mux" src="http://opencores.org/usercontent,img,1330032914" width="70%"><br> </div> <span style="font-weight: bold; text-decoration: underline;"></span>In order to make this implementation 100% bullet proof, the RTL could be modified by manually instantiating the NAND2 and AND2 cells directly from the target library (with the associated <span style="font-weight: bold; font-style: italic;">don't touch</span> or <span style="font-weight: bold; font-style: italic;">size only</span> attributes of course).<br> However, if you decide to compile this module as it is, the synthesis tool should normally be smart enough and not mess it up (but PLEASE PLEASE PLEASE double check manually the resulting gate netlist).<br> <br> <a name="4_4_Scan_Mux"></a> <h2>4.4 Scan Mux ( <span style="font-style: italic;">omsp_scan_mux.v</span> )<br> </h2> As illustrated in the section <a href="asic_implementation.html#3_1_Resets">3.1</a> , the scan mux cell allows <span style="font-weight: bold;">ALL</span> internal resets to be controllable with the <span style="font-style: italic; font-weight: bold;">reset_n</span> input port in scan mode.<br> In addition, the scan mux is also used by the <span style="font-style: italic;">omsp_wakeup_cell</span> (see section <a href="asic_implementation.html#4_7_Wakeup_Cell">4.7<span style="font-style: italic;"></span></a> below).<br> <br> <a name="4_5_Sync_Cell"></a> <h2>4.5 Sync Cell ( <span style="font-style: italic;">omsp_sync_cell.v</span> )<br> </h2> The following synchronization cell is instantiated on all clock domain crossing data paths: <br> <br> <div style="text-align: center;"><img alt="Sync Cell" src="http://opencores.org/usercontent,img,1330809519" width="40%"><br> </div> <a name="4_6_Sync_Reset"></a> <h2>4.6 Sync Reset ( <span style="font-style: italic;">omsp_sync_reset.v</span> )<br> </h2> Internal resets are generated using the following standard reset synchronizer:<br> <div style="text-align: center;"><img alt="Sync Reset" src="http://opencores.org/usercontent,img,1330809533" width="40%"><br> </div> <br> <a name="4_7_Wakeup_Cell"></a> <h2>4.7 Wakeup Cell ( <span style="font-style: italic;">omsp_wakeup_cell.v</span> )<br> </h2> The wakeup cell is the most unconventional module of the openMSP430 design as it contains a flip-flop whose clock and reset are both coming from a data path.<br> In the openMSP430 core, it is instantiated a single time in the watchdog timer but can also be reused in external custom peripherals.<br> <br> The implementation of the block looks as following:<br> <div style="text-align: center;"><img alt="Wakeup cell" src="http://opencores.org/usercontent,img,1331155523" width="60%"><br> </div> <br> The basic idea here is simply to set the WKUP_OUT signal with a rising edge on the WKUP_EVENT port, and clear it when WKUP_CLEAR is active (i.e. level sensitive clear).<br> <br> In order to give a better perspective from a system point of view, the following diagram shows how the wakeup cell has been used in the particular case of the watchdog timer (note that WDTIFG_CLR_REG and WDTQN_EDGE_REG are both output of a flip-flop and therefore glitch-free):<br> <br> <div style="text-align: center;"><img alt="Watchdog wakeup" src="http://opencores.org/usercontent,img,1331155543" width="100%"><br> </div> <h1> </h1> <span style="font-weight: bold; text-decoration: underline;">Note:</span> Wake-up signals can of course be generated in a different way as long as they directly come from a flip-flop (or are certified to be non-glitchy).<br> For example a simple handshake between the WDT_CLK and MCLK clock domains could have been used to clear the WDT_WKUP signal in a fully synchronous manner.<br> However, it is to be noted that this handshake would introduce some synchronization delay, which might not be negligible if MCLK and WDT_CLK frequencies are orders of magnitude apart (i.e. several MHz for MCLK and 32kHz for WDT_CLK).<br> As getting the oscillators back to sleep as fast as possible might prove to be extremely important for low-power designs, this asynchronous solution was selected for the <span style="font-style: italic; font-weight: bold;">omsp_watchdog</span> implementation.<br> <br> <br> </body></html>
Go to most recent revision | Compare with Previous | Blame | View Log