URL
https://opencores.org/ocsvn/openmsp430/openmsp430/trunk
Subversion Repositories openmsp430
Compare Revisions
- This comparison shows the changes necessary to convert path
/openmsp430/trunk/doc
- from Rev 200 to Rev 202
- ↔ Reverse comparison
Rev 200 → Rev 202
/openMSP430.pdf
Cannot display: file marked as a binary type.
svn:mime-type = application/octet-stream
/html/peripherals.html
55,7 → 55,7
<br> |
With these constrains, the Basic Clock Module is implemented as following: |
<br><br> |
<img src="usercontent,img,1319831724" alt="Clock structure diagram" title="Clock structure diagram" width="80%"> |
<img src="http://opencores.org/usercontent,img,1319831724" alt="Clock structure diagram" title="Clock structure diagram" width="80%"> |
<br> |
<b>Note</b>: CPUOFF doesn't switch MCLK off and will instead bring the |
CPU state machines in an IDLE state while MCLK will still be running. |
63,7 → 63,7
|
In order to '<i>clock</i>' a register with ACLK or SMCLK, the following structure needs to be implemented: |
<br><br> |
<img src="usercontent,img,1246434793" alt="Clock implementation example" title="Clock implementation example"> |
<img src="http://opencores.org/usercontent,img,1246434793" alt="Clock implementation example" title="Clock implementation example"> |
<br><br>For example, the following Verilog code would implement a counter clocked with SMCLK: |
<br> |
<table border="0" cellpadding="0" cellspacing="4"> |
86,34 → 86,118
</tr> |
</tbody></table> |
<br><br> |
<b>Register Description</b> |
<b>Register Description (FPGA)</b> |
<br><br> |
<table border="1"> |
<tbody><tr align="center"> |
<td rowspan="2"><b>Register Name</b></td> |
<td rowspan="2"><b>Address</b></td> |
<td colspan="16"><b>Bit Field</b></td> |
</tr> |
<tr align="center"> |
<td>7</td> |
<td>6</td> |
<td>5</td> |
<td>4</td> |
<td>3</td> |
<td>2</td> |
<td>1</td> |
<td>0</td> |
</tr> |
<tr align="center"> |
<td>DCOCTL</td> |
<td>0x0004</td> |
<td colspan="8"><small><i>not implemented</i></small></td> |
</tr> |
<tr align="center"> |
<td>BCSTL1</td> |
<td>0x0006</td> |
<td colspan="2"><small><i>unused</i></small></td> |
<td colspan="2"><b>DIVAx</b></td> |
<td colspan="4"><small><i>unused</i></small></td> |
</tr> |
<tr align="center"> |
<td>BCSTL2</td> |
<td>0x0008</td> |
<td colspan="4"><small><i>unused</i></small></td> |
<td colspan="1"><b>SELS</b></td> |
<td colspan="2"><b>DIVSx</b></td> |
<td colspan="1"><small><i>unused</i></small></td> |
</tr> |
</tbody> |
</table> |
<ul> |
<li>DCOCTL: Not implemented</li> |
<li>BCSCTL1: |
<ul> |
<li>BCSCTL1[7:6]: Unused</li> |
<li>BCSCTL1[5:4]: DIVAx</li> |
<li>BCSCTL1[4:0]: Unused</li> |
</ul> |
</li> |
<li>BCSCTL2: |
<ul> |
<li>BCSCTL2[7:4]: Unused</li> |
<li>BCSCTL2[3] : SELS</li> |
<li>BCSCTL2[2:1]: DIVSx</li> |
<li>BCSCTL2[0] : Unused</li> |
</ul></li> |
<li>BCSCTL1.<b>DIVAx</b> : ACLK_EN divider (1/2/4/8)</li> |
<li>BCSCTL2.<b>SELS</b>  : SMCLK_EN clock selection (0:DCO_CLK / 1:LFXT_CLK)</li> |
<li>BCSCTL2.<b>DIVSx</b> : SMCLK_EN divider (1/2/4/8)</li> |
</ul> |
|
</ul><a name="2.1.2_Basic_Clock_Module_ASIC"></a> |
<a name="2.1.2_Basic_Clock_Module_ASIC"></a> |
<h3>2.1.2 Basic Clock Module: ASIC</h3> |
<br> |
When targeting an ASIC, up to all clock management |
options available in the <a href="http://www.ti.com/litv/pdf/slau049f">MSP430x1xx Family User's Guide</a> (Chapter 4) can be included:<br><br> |
|
<img src="usercontent,img,1319832480" alt="Clock structure diagram" title="Clock structure diagram" width="80%"><br> |
<img src="http://opencores.org/usercontent,img,1319832480" alt="Clock structure diagram" title="Clock structure diagram" width="80%"><br> |
Additional info can be found in the <a href="http://opencores.org/project,openmsp430,asic%20implementation">ASIC implementation</a> |
section.<br> |
<br> |
<b>Register Description (ASIC)</b> |
<br><br> |
<table border="1"> |
<tbody><tr align="center"> |
<td rowspan="2"><b>Register Name</b></td> |
<td rowspan="2"><b>Address</b></td> |
<td colspan="16"><b>Bit Field</b></td> |
</tr> |
<tr align="center"> |
<td>7</td> |
<td>6</td> |
<td>5</td> |
<td>4</td> |
<td>3</td> |
<td>2</td> |
<td>1</td> |
<td>0</td> |
</tr> |
<tr align="center"> |
<td>DCOCTL</td> |
<td>0x0004</td> |
<td colspan="8"><small><i>not implemented</i></small></td> |
</tr> |
<tr align="center"> |
<td>BCSTL1</td> |
<td>0x0006</td> |
<td colspan="2"><small><i>unused</i></small></td> |
<td colspan="2"><b>DIVAx</b></td> |
<td colspan="1"><b><small>DMA_SCG1</small></b></td> |
<td colspan="1"><b><small>DMA_SCG0</small></b></td> |
<td colspan="1"><b><small>DMA_OSCOFF</small></b></td> |
<td colspan="1"><b><small>DMA_CPUOFF</small></b></td> |
</tr> |
<tr align="center"> |
<td>BCSTL2</td> |
<td>0x0008</td> |
<td colspan="1"><b>SELMx</b></td> |
<td colspan="1"><small><i>unused</i></small></td> |
<td colspan="2"><b>DIVMx</b></td> |
<td colspan="1"><b>SELS</b></td> |
<td colspan="2"><b>DIVSx</b></td> |
<td colspan="1"><small><i>unused</i></small></td> |
</tr> |
</tbody> |
</table> |
<ul> |
<li>BCSCTL1.<b>DIVAx</b>     : ACLK clock divider (1/2/4/8)</li> |
<li>BCSCTL1.<b>DMA_SCG1</b>   : Restore SMCLK with DMA wakeup</li> |
<li>BCSCTL1.<b>DMA_SCG0</b>   : Restore DCO oscillator with DMA wakeup</li> |
<li>BCSCTL1.<b>DMA_OSCOFF</b> : Restore LFXT oscillator with DMA wakeup</li> |
<li>BCSCTL1.<b>DMA_CPUOFF</b> : Restore MCLK with DMA wakeup</li> |
<li>BCSCTL2.<b>SELMx</b>     : MCLK clock selection (0:DCO_CLK / 1:LFXT_CLK)</li> |
<li>BCSCTL2.<b>DIVMx</b>     : MCLK clock divider (1/2/4/8)</li> |
<li>BCSCTL2.<b>SELS</b>      : SMCLK clock selection (0:DCO_CLK / 1:LFXT_CLK)</li> |
<li>BCSCTL2.<b>DIVSx</b>     : SMCLK clock divider (1/2/4/8)</li> |
</ul> |
|
<a name="2.1.3_SFR"></a> |
<h3>2.1.3 SFR</h3> |
/html/dma_interface.html
0,0 → 1,312
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"> |
<html><head><title>openMSP430 DMA Interface</title> |
|
<meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body> |
<h3>Table of content</h3> |
|
<ul> |
<li><a href="#1.%20Introduction"> 1. Introduction</a></li> |
<li><a href="#2.%20Signal%20list"> 2. Signal list</a></li> |
<li><a href="#3.%20Protocol"> 3. Protocol</a></li> |
<ul> |
<li><a href="#3.1%20Simple%20transfer"> 3.1 Simple transfer</a></li> |
<li><a href="#3.2%20Transfer%20with%20wait%20states"> 3.2 Transfer with wait states</a></li> |
<li><a href="#3.3%20Multiple%20transfers"> 3.3 Multiple transfers</a></li> |
<li><a href="#3.4%20Transfer%20response"> 3.4 Transfer response</a></li> |
<li><a href="#3.5%20Priority%20control"> 3.5 Priority control</a></li> |
<ul> |
<li><a href="#3.5.1%20Data%20rate%20control"> 3.5.1 Data rate control</a></li> |
<li><a href="#3.5.2%20Bootloader%20case"> 3.5.2 Bootloader case</a></li> |
</ul> |
</ul> |
<li><a href="#4.%20ASIC%20Implementation">4. ASIC Implementation</a></li> |
<ul> |
<li><a href="#4.1%20Clock%20domains"> 4.1 Clock domains</a></li> |
<li><a href="#4.2%20DMA%20wakeup"> 4.2 DMA wakeup</a></li> |
</ul> |
</ul> |
|
<a name="1.%20Introduction"></a> |
<h1>1. Introduction</h1> |
|
The openMSP430 Direct-Memory-Access interface acts as a gateway to the whole logical 64kB memory space and can |
be enabled be uncommenting the DMA_IF_EN macro in the <i>"openMSP430_defines.sv"</i> file:<br><br> |
<code> |
//-------------------------------------------------------<br> |
// Include/Exclude DMA interface support<br> |
//-------------------------------------------------------<br> |
`define DMA_IF_EN<br> |
</code> |
<br> |
It supports the efficient connection of Bootloader, DMA controller, Memory-BIST or any other hardware |
unit requiring direct read/write access to the CPU memory space. |
<br> |
The interface is also designed as to reuse the existing arbitration logic within the memory-backbone |
and thus minimize to timing costs of its physical implementation (i.e. no additional muxing layer on |
an already critical timing path). |
<br><br> |
An simple system using the DMA interface typically consists of a DMA master directly connected to |
openMSP430 core: |
<br><img src="http://opencores.org/usercontent,img,1431381105" alt="DMA simple systems" title="DMA simple systems" width="100%"> |
<br><br> |
However, it is also possible to combine different DMA masters using a custom arbitration logic: |
<br><img src="http://opencores.org/usercontent,img,1431381122" alt="DMA complex system" title="DMA complex system" width="100%"> |
<br><br> |
|
<a name="2.%20Signal%20list"></a> |
<h1>2. Signal list</h1> |
|
<table border="1"> |
<tbody> |
<tr align="center"> |
<td><b>Name</b></td> |
<td><b>Source</b></td> |
<td><b>Type</b></td> |
<td><b>Description</b></td> |
</tr> |
<tr> |
<td><b>MCLK</b><br><small>System clock</small></td> |
<td align="center"> openMSP430 </td> |
<td align="center">System</td> |
<td>This clock times all DMA transfers. All signal timings are related to the rising edge of MCLK.</td> |
</tr> |
<tr> |
<td><b>PUC_RST</b><br><small>System reset</small></td> |
<td align="center"> openMSP430 </td> |
<td align="center">System</td> |
<td>The system reset is active HIGH and is used to reset the sytem, including the DMA master(s).</td> |
</tr> |
<tr> |
<td><b>DMA_WKUP</b><br><small>Wakeup</small></td> |
<td align="center">DMA Master<br><small>(Asynchronous)</small></td> |
<td align="center">System</td> |
<td>When HIGH in a Low-Power-Mode, the wakeup signal restores the clocks necessary for the DMA transfer (see <a href="#4.%20ASIC%20Implementation">ASIC Implementation</a> section).</td> |
</tr> |
<tr> |
<td><b>DMA_ADDR[15:1]</b><br><small>Address bus</small></td> |
<td align="center">DMA Master</td> |
<td align="center">Address</td> |
<td>This is the 15-bit address bus allowing to access the 64kB address space (16b words).</td> |
</tr> |
<tr> |
<td><b>DMA_DIN[15:0]</b><br><small>Write data bus</small></td> |
<td align="center">DMA Master</td> |
<td align="center">Data</td> |
<td>The write data bus is used to transfer data from the DMA master to openMSP430 system during write operations.</td> |
</tr> |
<tr> |
<td><b>DMA_DOUT[15:0]</b><br><small>Read data bus</small></td> |
<td align="center"> openMSP430 </td> |
<td align="center">Data</td> |
<td>The read data bus is used to transfer data from the openMSP430 system to the DMA master during read operations.</td> |
</tr> |
<tr> |
<td><b>DMA_EN</b><br><small>Transfer enable</small></td> |
<td align="center">DMA Master</td> |
<td align="center">Control</td> |
<td>Indicates that the current DMA transfer is active.</td> |
</tr> |
<tr> |
<td><b>DMA_WE[1:0]</b><br><small>Transfer direction</small></td> |
<td align="center">DMA Master</td> |
<td align="center">Control</td> |
<td>When HIGH, this signal indicates a write transfer on the selected byte, and a read transfer when LOW.</td> |
</tr> |
<tr> |
<td><b>DMA_PRIORITY</b><br><small>Transfer priority</small></td> |
<td align="center">DMA Master</td> |
<td align="center">Control</td> |
<td>When HIGH, this signal indicates a high priority DMA transfer (i.e. CPU is stopped). When LOW, low priority DMA transfer have to wait for the CPU to free the accessed ressource.</td> |
</tr> |
<tr> |
<td><b>DMA_READY</b><br><small>Transfer done</small></td> |
<td align="center"> openMSP430 </td> |
<td align="center">Response</td> |
<td>When HIGH the DMA_READY signal indicates that a transfer has finished on the bus. This signal may be driven LOW to add wait states to the transfer.</td> |
</tr> |
<tr> |
<td><b>DMA_RESP</b><br><small>Transfer response</small></td> |
<td align="center"> openMSP430 </td> |
<td align="center">Response</td> |
<td>The transfer response provides additional information on the status of a transfer (OKAY if LOW, ERROR when HIGH).</td> |
</tr> |
</tbody> |
</table> |
|
<br> |
|
<a name="3.%20Protocol"></a> |
<h1>3. Protocol</h1> |
|
<a name="3.1%20Simple%20transfer"></a> |
<h2>3.1 Simple transfer</h2> |
|
The following figure shows the simplest transfer, one with no wait states.<br> |
<br><img src="http://opencores.org/usercontent,img,1431552266" alt="DMA simple transfer" title="DMA simple transfer" width="60%"><br> |
In a simple transfer with no wait states: |
<ul> |
<li>The DMA master drives the address, control signals and write data onto the bus after the rising edge of MCLK.</li> |
<li>The openMSP430 ressource (pmem/dmem/peripheral) then samples the address, control and write data information on the next rising edge of the clock.</li> |
<li>For read access, after the openMSP430 ressource has sampled the address and control it can start to drive the read data |
and this is sampled by the DMA master on the third rising edge of the clock.</li> |
</ul> |
|
<a name="3.2%20Transfer%20with%20wait%20states"></a> |
<h2>3.2 Transfer with wait states</h2> |
The openMSP430 can insert wait states into any transfer, as shown in the following figure, which extends |
the transfer by two clock cycles, thus taking additional time for completion. |
<br><img src="http://opencores.org/usercontent,img,1431552287" alt="DMA transfer with wait states" title="DMA transfer with wait states" width="90%"><br> |
For both read and write operations the DMA master must hold the address, control and write data stable throughout the extended cycles. |
<br><br> |
<b>Note:</b> wait states are inserted by the openMSP430 if the CPU is currently busy reading or writing to the same ressource that the DMA controller also wants to access. |
<br> |
<a name="3.3%20Multiple%20transfers"></a> |
<h2>3.3 Multiple transfers</h2> |
|
The following figure shows three transfers to unrelated addresses, A, B & C. |
|
<br><img src="http://opencores.org/usercontent,img,1431552310" alt="DMA multiple transfer" title="DMA multiple transfer" width="100%"><br> |
We can here observe: |
<ul> |
<li>the transfers to addresses A and C are both zero wait state.</li> |
<li>the transfer to address B is one wait state.</li> |
<li>the read data from A is available during the <b>first</b> clock cycle when the address and control B are applied.</li> |
<li>the read data from B is available during the clock cycle when the address and control C are applied.</li> |
</ul> |
|
<a name="3.4%20Transfer%20response"></a> |
<h2>3.4 Transfer response</h2> |
|
The following figure shows two transfers to unrelated addresses, A & B. |
|
<br><img src="http://opencores.org/usercontent,img,1431552329" alt="DMA error response" title="DMA error response" width="70%"><br> |
We can here observe: |
<ul> |
<li>the transfer to address A returns an ERROR response (note that transfer returning an ERROR response <b>never</b> have wait states).</li> |
<li>the transfer to address B is a regular transfer (i.e. OKAY response) without wait state.</li> |
</ul> |
<b>Note:</b> an ERROR response are generated if the transfer address lays between the program and data memories, where nothing is mapped. |
<br> |
|
<a name="3.5%20Priority%20control"></a> |
<h2>3.5 Priority control</h2> |
|
<a name="3.5.1%20Data%20rate%20control"></a> |
<h3>3.5.1 Data rate control</h3> |
The DMA_PRIORITY control signal is available to the DMA master for controlling the application data rate requirements.<br> |
<ul> |
<li>When CLEARED, DMA transfers have a <b>fixed lower priority</b> than the CPU. This means that depending on the |
exact kind of instructions currently executed by the CPU, the completion time of the DMA transfers cannot be |
predicted (i.e. DMA transfers are completed only when the CPU is not accessing the trageted ressource).</li> |
<li>When SET, DMA transfers have a <b>fixed higher priority</b> over the CPU. This means that the CPU will |
will stop execution and give the full bandwidth to the DMA controller. In that scenario, DMA transfers complete |
in a single clock cycle (i.e. without any wait states), as the targeted ressources are always available |
(i.e. the CPU is not executing).</li> |
<li>If the application requirements need something in between (namely a minimum DMA transfer data-rate with reduced effect |
on the firmware exection), then the DMA master can dynamically change the DMA_PRIORITY as required.</li> |
</ul> |
These scenario are illustrated in the following figure. |
<br><img src="http://opencores.org/usercontent,img,1431638398" alt="DMA error response" title="DMA error response" width="100%"><br> |
We can here observe: |
<ul> |
<li>phase <b>A</b> illustrates LOW-PRIORITY transfers. Less DMA transfer are completed during that time as shown by the number of wait states.</li> |
<li>phase <b>B</b> illustrates HIGH-PRIORITY transfers. DMA transfers are completed with each clock cycle (i.e. no wait state).</li> |
<li>phase <b>C</b> illustrates MIXED-PRIORITY transfers where the DMA controller is dynamically adjusting the priority to achieve its target minimum data-rate.</li> |
</ul> |
|
<a name="3.5.2%20Bootloader%20case"></a> |
<h3>3.5.2 Bootloader case</h3> |
In general, the purpose of a bootloader is to initialize the program memory at startup (i.e after Power-On-Reset).<br> |
DMA transfers driven by the bootloader should therefore be performed in HIGH-PRIORITY mode, as the CPU should not start |
executing instructions on a non-initialized memory.<br> |
Once the memory initialization is completed, a reset pulse should be generated by the bootloader to make sure the CPU |
re-fetches the new RESET vector from the program memory.<br> |
<br> |
A bootloader could be for example be connected as following: |
<br><img src="http://opencores.org/usercontent,img,1431724552" alt="DMA bootloader" title="DMA bootloader" width="50%"><br> |
|
The bootloading sequence is illustrated in the following figure: |
<br><img src="http://opencores.org/usercontent,img,1431724534" alt="DMA bootloader waveform" title="DMA bootloader waveform" width="100%"><br> |
|
<a name="4.%20ASIC%20Implementation"></a> |
<h1>4. ASIC Implementation</h1> |
|
<a name="4.1%20Clock%20domains"></a> |
<h2>4.1 Clock domains</h2> |
If the ASIC low power options are enabled, it is possible to perform DMA accesses when the main CPU is in <b>any</b> Low-Power-Mode (LPMx).<br> |
However, in order to avoid unnecessary power consumption while restoring the clocks for the DMA transfer, the MCLK |
system clock has been split into two clock domains. |
<ul> |
<li>MCLK_CPU : clocks the CPU core itself, namely the frontend and execution logic. |
When the CPU is in LPMx mode, this clock is ALWAYS OFF, even if a DMA transfer is currently on going.</li> |
<li>MCLK_DMA : clocks the rest of the system (excluding the DBG interface) and gives access to the 64kB memory |
adddress range to the DMA master. This clock is restored in LPMx modes by asserting the DMA_WKUP pin.</li> |
</ul> |
This table summarizes the clock operating modes:<br><br> |
<table border="1"> |
<tbody><tr align="center"> |
<td rowspan="2"><b>Clock Name</b></td> |
<td rowspan="2"><b>CPU Active</b></td> |
<td colspan="2"><b>CPU Low-Power-Mode</b></td> |
</tr> |
<tr align="center"> |
<td>DMA_WKUP=0</td> |
<td>DMA_WKUP=1</td> |
</tr> |
<tr align="center"> |
<td>MCLK_CPU</td> |
<td>ON</td> |
<td>OFF</td> |
<td>OFF</td> |
</tr> |
<tr align="center"> |
<td>MCLK_DMA</td> |
<td>ON</td> |
<td>OFF</td> |
<td>ON</td> |
</tr> |
</tbody> |
</table> |
<br> |
Clock domains are illustrated in the following diagram: |
<br><img src="http://opencores.org/usercontent,img,1431726489" alt="DMA clock domains" title="DMA clock domains" width="50%"><br> |
|
<a name="4.2%20DMA%20wakeup"></a> |
<h2>4.2 DMA wakeup</h2> |
As shown in the "Peripherals" chapter, the Basic-Clock-Module has several |
control registers giving some flexibility to the firmware as to which clocks |
are restored when the DMA_WKUP pin is asserted.<br><br> |
|
<table border="1"> |
<tbody><tr align="center"> |
<td rowspan="2"><b>Register Name</b></td> |
<td rowspan="2"><b>Address</b></td> |
<td colspan="16"><b>Bit Field</b></td> |
</tr> |
<tr align="center"> |
<td>7</td><td>6</td><td>5</td><td>4</td> |
<td>3</td><td>2</td><td>1</td><td>0</td> |
</tr> |
<tr align="center"> |
<td>BCSTL1</td> |
<td>0x0006</td> |
<td colspan="2"><small><i>unused</i></small></td> |
<td colspan="2"><b>DIVAx</b></td> |
<td colspan="1"><b><small>DMA_SCG1</small></b></td> |
<td colspan="1"><b><small>DMA_SCG0</small></b></td> |
<td colspan="1"><b><small>DMA_OSCOFF</small></b></td> |
<td colspan="1"><b><small>DMA_CPUOFF</small></b></td> |
</tr> |
</tbody> |
</table> |
<ul> |
<li><b>DMA_SCG1</b>   : Restore SMCLK with DMA wakeup</li> |
<li><b>DMA_SCG0</b>   : Restore DCO oscillator with DMA wakeup</li> |
<li><b>DMA_OSCOFF</b> : Restore LFXT oscillator with DMA wakeup</li> |
<li><b>DMA_CPUOFF</b> : Restore MCLK_DMA with DMA wakeup</li> |
</ul> |
Note that the DMA_WKUP functionality can be disabled by keeping all these bitfields <b>CLEARED</b>. |
<br> |
<br> |
|
</body></html> |
/html/images/wave_dma.odg
Cannot display: file marked as a binary type.
svn:mime-type = application/vnd.oasis.opendocument.graphics
html/images/wave_dma.odg
Property changes :
Added: svn:mime-type
## -0,0 +1 ##
+application/vnd.oasis.opendocument.graphics
\ No newline at end of property
Index: html/images/dma_waveforms.odg
===================================================================
Cannot display: file marked as a binary type.
svn:mime-type = application/vnd.oasis.opendocument.graphics
Index: html/images/dma_waveforms.odg
===================================================================
--- html/images/dma_waveforms.odg (nonexistent)
+++ html/images/dma_waveforms.odg (revision 202)
html/images/dma_waveforms.odg
Property changes :
Added: svn:mime-type
## -0,0 +1 ##
+application/vnd.oasis.opendocument.graphics
\ No newline at end of property
Index: html/images/dma_waveform_simple.png
===================================================================
Cannot display: file marked as a binary type.
svn:mime-type = image/png
Index: html/images/dma_waveform_simple.png
===================================================================
--- html/images/dma_waveform_simple.png (nonexistent)
+++ html/images/dma_waveform_simple.png (revision 202)
html/images/dma_waveform_simple.png
Property changes :
Added: svn:mime-type
## -0,0 +1 ##
+image/png
\ No newline at end of property
Index: html/images/wave_dma.png
===================================================================
Cannot display: file marked as a binary type.
svn:mime-type = image/png
Index: html/images/wave_dma.png
===================================================================
--- html/images/wave_dma.png (nonexistent)
+++ html/images/wave_dma.png (revision 202)
html/images/wave_dma.png
Property changes :
Added: svn:mime-type
## -0,0 +1 ##
+image/png
\ No newline at end of property
Index: html/images/dma_waveform_priority.png
===================================================================
Cannot display: file marked as a binary type.
svn:mime-type = image/png
Index: html/images/dma_waveform_priority.png
===================================================================
--- html/images/dma_waveform_priority.png (nonexistent)
+++ html/images/dma_waveform_priority.png (revision 202)
html/images/dma_waveform_priority.png
Property changes :
Added: svn:mime-type
## -0,0 +1 ##
+image/png
\ No newline at end of property
Index: html/images/dma_bootloader.png
===================================================================
Cannot display: file marked as a binary type.
svn:mime-type = image/png
Index: html/images/dma_bootloader.png
===================================================================
--- html/images/dma_bootloader.png (nonexistent)
+++ html/images/dma_bootloader.png (revision 202)
html/images/dma_bootloader.png
Property changes :
Added: svn:mime-type
## -0,0 +1 ##
+image/png
\ No newline at end of property
Index: html/images/cpu_structure.odg
===================================================================
Cannot display: file marked as a binary type.
svn:mime-type = application/octet-stream
Index: html/images/cpu_structure.png
===================================================================
Cannot display: file marked as a binary type.
svn:mime-type = application/octet-stream
Index: html/images/dma_waveform_error_resp.png
===================================================================
Cannot display: file marked as a binary type.
svn:mime-type = image/png
Index: html/images/dma_waveform_error_resp.png
===================================================================
--- html/images/dma_waveform_error_resp.png (nonexistent)
+++ html/images/dma_waveform_error_resp.png (revision 202)
html/images/dma_waveform_error_resp.png
Property changes :
Added: svn:mime-type
## -0,0 +1 ##
+image/png
\ No newline at end of property
Index: html/images/dma_waveform_wait_states.png
===================================================================
Cannot display: file marked as a binary type.
svn:mime-type = image/png
Index: html/images/dma_waveform_wait_states.png
===================================================================
--- html/images/dma_waveform_wait_states.png (nonexistent)
+++ html/images/dma_waveform_wait_states.png (revision 202)
html/images/dma_waveform_wait_states.png
Property changes :
Added: svn:mime-type
## -0,0 +1 ##
+image/png
\ No newline at end of property
Index: html/images/core_integration.odg
===================================================================
Cannot display: file marked as a binary type.
svn:mime-type = application/octet-stream
Index: html/images/dma_waveform_bootloader.png
===================================================================
Cannot display: file marked as a binary type.
svn:mime-type = image/png
Index: html/images/dma_waveform_bootloader.png
===================================================================
--- html/images/dma_waveform_bootloader.png (nonexistent)
+++ html/images/dma_waveform_bootloader.png (revision 202)
html/images/dma_waveform_bootloader.png
Property changes :
Added: svn:mime-type
## -0,0 +1 ##
+image/png
\ No newline at end of property
Index: html/images/dma_clock_domains.png
===================================================================
Cannot display: file marked as a binary type.
svn:mime-type = image/png
Index: html/images/dma_clock_domains.png
===================================================================
--- html/images/dma_clock_domains.png (nonexistent)
+++ html/images/dma_clock_domains.png (revision 202)
html/images/dma_clock_domains.png
Property changes :
Added: svn:mime-type
## -0,0 +1 ##
+image/png
\ No newline at end of property
Index: html/images/dma_interface_simple_sys.png
===================================================================
Cannot display: file marked as a binary type.
svn:mime-type = image/png
Index: html/images/dma_interface_simple_sys.png
===================================================================
--- html/images/dma_interface_simple_sys.png (nonexistent)
+++ html/images/dma_interface_simple_sys.png (revision 202)
html/images/dma_interface_simple_sys.png
Property changes :
Added: svn:mime-type
## -0,0 +1 ##
+image/png
\ No newline at end of property
Index: html/images/core_integration.png
===================================================================
Cannot display: file marked as a binary type.
svn:mime-type = application/octet-stream
Index: html/images/dma_interface.odg
===================================================================
Cannot display: file marked as a binary type.
svn:mime-type = application/vnd.oasis.opendocument.graphics
Index: html/images/dma_interface.odg
===================================================================
--- html/images/dma_interface.odg (nonexistent)
+++ html/images/dma_interface.odg (revision 202)
html/images/dma_interface.odg
Property changes :
Added: svn:mime-type
## -0,0 +1 ##
+application/vnd.oasis.opendocument.graphics
\ No newline at end of property
Index: html/images/dma_interface_complex_sys.png
===================================================================
Cannot display: file marked as a binary type.
svn:mime-type = image/png
Index: html/images/dma_interface_complex_sys.png
===================================================================
--- html/images/dma_interface_complex_sys.png (nonexistent)
+++ html/images/dma_interface_complex_sys.png (revision 202)
html/images/dma_interface_complex_sys.png
Property changes :
Added: svn:mime-type
## -0,0 +1 ##
+image/png
\ No newline at end of property
Index: html/images/dma_waveform_multiple.png
===================================================================
Cannot display: file marked as a binary type.
svn:mime-type = image/png
Index: html/images/dma_waveform_multiple.png
===================================================================
--- html/images/dma_waveform_multiple.png (nonexistent)
+++ html/images/dma_waveform_multiple.png (revision 202)
html/images/dma_waveform_multiple.png
Property changes :
Added: svn:mime-type
## -0,0 +1 ##
+image/png
\ No newline at end of property
Index: html/integration.html
===================================================================
--- html/integration.html (revision 200)
+++ html/integration.html (revision 202)
@@ -9,11 +9,12 @@
4. Program Memory
5. Data Memory
6. Peripherals
- 7. Interrupts
- 8. Serial Debug Interface
+ 7. Direct Memory Access Interface
+ 8. Interrupts
+ 9. Serial Debug Interface
@@ -24,7 +25,7 @@
or FPGA.
The following diagram shows an overview of the openMSP430 core connectivity in an FPGA system (i.e. all ASIC specific pins are left unused):
-
+
The full pinout of the core is summarized in the following table.
@@ -280,10 +281,83 @@mclk
Peripheral write byte enable (high active)
+ Direct Memory Access interface
+
+ dma_addr
+ Input
+ 15
+ mclk
+
+ Direct Memory Access address
+
+
+ dma_din
+ Input
+ 16
+ mclk
+
+ Direct Memory Access data input
+
+
+ dma_dout
+ Output
+ 16
+ mclk
+
+ Direct Memory Access data output
+
+
+ dma_en
+ Input
+ 1
+ mclk
+
+ Direct Memory Access enable (high active)
+
+
+ dma_priority
+ Input
+ 1
+ mclk
+
+ Direct Memory Access priority (0:low / 1:high)
+
+
+ dma_ready
+ Output
+ 1
+ mclk
+
+ Direct Memory Access is complete
+
+
+ dma_resp
+ Output
+ 1
+ mclk
+
+ Direct Memory Access response (0:Okay / 1:Error)
+
+
+ dma_we
+ Input
+ 2
+ mclk
+
+ Direct Memory Access write byte enable (high active)
+
+
+ dma_wkup
+ Input
+ 1
+ <async>
+
+ ASIC ONLY: DMA Wake-up (asynchronous and non-glitchy)
+
Interrupts
- irq
+ irq
Input
`IRQ_NR-21
mclk
@@ -290,7 +364,7 @@
Maskable interrupts (one-hot signal)
- nmi
+ nmi
Input
1
<async>
@@ -299,7 +373,7 @@ Non-maskable interrupt (asynchronous)
- irq_acc
+ irq_acc
Output
`IRQ_NR-21
mclk
@@ -308,7 +382,7 @@
Serial Debug interface
- dbg_en
+ dbg_en
Input
1
<async>
@@ -317,7 +391,7 @@ Debug interface enable (asynchronous) 3
- dbg_freeze
+ dbg_freeze
Output
1
mclk
@@ -324,7 +398,7 @@
Freeze peripherals
- dbg_uart_txd
+ dbg_uart_txd
Output
1
mclk
@@ -331,7 +405,7 @@
Debug interface: UART TXD
- dbg_uart_rxd
+ dbg_uart_rxd
Input
1
<async>
@@ -338,7 +412,7 @@
Debug interface: UART RXD (asynchronous)
- dbg_i2c_addr
+ dbg_i2c_addr
Input
1
mclk
@@ -346,7 +420,7 @@ Debug interface: I2C Address
- dbg_i2c_broadcast
+ dbg_i2c_broadcast
Input
1
mclk
@@ -354,7 +428,7 @@ Debug interface: I2C Broadcast Address (for multicore only)
- dbg_i2c_scl
+ dbg_i2c_scl
Input
1
<async>
@@ -361,7 +435,7 @@
Debug interface: I2C SCL
- dbg_i2c_sda_in
+ dbg_i2c_sda_in
Input
1
<async>
@@ -368,7 +442,7 @@
Debug interface: I2C SDA input
- dbg_i2c_sda_out
+ dbg_i2c_sda_out
Output
1
mclk
@@ -632,10 +706,78 @@
+ + +
+
+The protocol between the DMA interface master (DMA controller, bootloader, ...) and the openMSP430 core is similar +to the one followed between the openMSP430 and its data memory. +
However, it comes with a few additional features to support wait states, error response, priority and wakeup (for LPMx modes).
+
+The signal description goes as following: +
+
+
+ - + -
If two interrupts are pending simultaneously, the higher priority interrupt will be serviced first.
@@ -757,9 +899,9 @@
- + -
@@ -779,8 +921,8 @@
- -
The following diagram shows an overview of the openMSP430 core connectivity in an FPGA system (i.e. all ASIC specific pins are left unused):
-
The full pinout of the core is summarized in the following table.
@@ -280,10 +281,83 @@
+
+
+
+
+
+
+
+
+
@@ -299,7 +373,7 @@
@@ -317,7 +391,7 @@
@@ -338,7 +412,7 @@
@@ -346,7 +420,7 @@
@@ -354,7 +428,7 @@
@@ -632,10 +706,78 @@
+ + +
7. Direct Memory Access Interface
+ +Before moving on, please note that further details about the DMA interface can +be found in its dedicated section.+
+The protocol between the DMA interface master (DMA controller, bootloader, ...) and the openMSP430 core is similar +to the one followed between the openMSP430 and its data memory. +
However, it comes with a few additional features to support wait states, error response, priority and wakeup (for LPMx modes).
+
+The signal description goes as following: +
-
+
- DMA_EN:
+this signal enables a DMA transfer and can be released once the transfer is completed, as signaled by DMA_READY.
+
+
+ -
+ DMA_ADDR:
+Logical address of the 16bit word currently accessed by the interface. The address must stay valid until the transfer is completed, as signaled by DMA_READY.
+
Note: the integrated oMSP memory backbone module decode the specified logical DMA address and maps it accordingly to the physical address of the Program, Data or Peripheral memory. +
+
+ -
+ DMA_DOUT:
+When performing a read acces, the DMA data output is valid during the MCLK cycle immediately following the end of the transfer, as signaled by DMA_READY.
+
+
+ -
+ DMA_WE:
+This signal, asserted together with DMA_EN, allows to selects which byte should be written during the transfer.
+DMA_WE[0] activates a write on the lower byte, DMA_WE[1] a write on the upper byte.
+
+ -
+ DMA_DIN:
+When performing a write access, the DMA data input must stay valid until the transfer is completed, as signaled by DMA ready.
+
+
+ -
+ DMA_PRIORITY:
+When SET, the oMSP memory backbone gives highest priority to the DMA transfer and stops CPU execution.
+
When CLEARED, the oMSP memory backbone gives highest priority to CPU execution and the DMA transfer is completed only when the CPU doesn't access the targeted ressource (pmem, dmem or peripheral). +
Note: a DMA controller can control the DMA data rate without stalling the CPU by dynamically asserting/deasserting the DMA_PRIORITY port between transfers. +
+
+ -
+ DMA_READY:
+This port signals that the current DMA transfer is completed.
+
Note: DMA_READY is typically hold low when the CPU owns the interface of the target ressource. +
+
+ -
+ DMA_RESP:
+This port signals if the current transfer was successful (0) or if an error occured (1) and is valid together with DMA_READY.
+
Note: an error is typically signaled when an access is performed outside of any memory mapped area (for example between Program and Data memory). +
+
+ -
+ DMA_WKUP:
+For ASIC implementations supporting the Low-Power-Modes, this port is used to asynchronously restore the clocks before performing a DMA transfer.
+
Note: it is possible to control which clocks are restored during a DMA wakeup using the BCSTL1 register of the Basic Clock Module. +
+
+
+
+ - + -
7. Interrupts
As with the original MSP430, the interrupt +8. Interrupts
As with the original MSP430, the interrupt priorities of the openMSP430 are fixed in hardware accordingly to the connectivity of the NMI and IRQ ports.If two interrupts are pending simultaneously, the higher priority interrupt will be serviced first.
@@ -757,9 +899,9 @@
- + -
8. Serial Debug Interface
+9. Serial Debug Interface
The serial debug interface module provides a two-wires communication bus (UART or I2C) for remote debugging and an additional freeze signal which might be useful for some peripherals (typically timers).@@ -779,8 +921,8 @@
- -
8.1 UART Configuration
+ +9.1 UART Configuration
-
DBG_UART_TXD / DBG_UART_RXD: these signals are typically connected to an RS-232 transceiver and will allow a PC to communicate with the openMSP430 core.
@@ -790,8 +932,8 @@
The following waveform shows some communication traffic on the UART serial bus :
- -8.2 I2C Configuration
+ +9.2 I2C Configuration
-
DBG_I2C_ADDR: I2C Device address of the oMSP core (between 8 and 119). In a multi-core configuration each core has its own address.
/html/serial_debug_interface.html1080,7 → 1080,7
However, here is quick recap about 8N1 (1 Start bit, 8 Data bits, NoParity, 1 Stop bit):<br><br><img src="usercontent,img,1247419201" alt="8N1 Serial Protocol" title="8N1 Serial Protocol"><img src="http://opencores.org/usercontent,img,1247419201" alt="8N1 Serial Protocol" title="8N1 Serial Protocol"><br>As you can see in the above diagram, data transmission starts with aStart bit, followed by the data bits (LSB sent first and MSB sent1091,7 → 1091,7order to determine the communication speed (i.e. the baud rate).<br>The synchronization frame looks as following:<br><img src="usercontent,img,1247420610" alt="Debug Synchronization Frame" title="Debug Synchronization Frame"><img src="http://opencores.org/usercontent,img,1247420610" alt="Debug Synchronization Frame" title="Debug Synchronization Frame"><br>As you can see, the host simply sends the 0x80 value. The openMSP430will then measure the time between the falling and rising edge, divide1111,7 → 1111,7<h3>3.3.1 Command Frame</h3>The command frame looks as following:<br><img src="usercontent,img,1247427400" alt="Debug Command Frame" title="Debug Command Frame"><img src="http://opencores.org/usercontent,img,1247427400" alt="Debug Command Frame" title="Debug Command Frame"><br><table border="0"><tbody><tr>1132,13 → 1132,13<h3>3.3.2 Write access</h3>A write access transaction looks like this:<br><img src="usercontent,img,1247428987" alt="Debug Write Transaction" title="Debug Write Transaction"><img src="http://opencores.org/usercontent,img,1247428987" alt="Debug Write Transaction" title="Debug Write Transaction"><a name="3.3.3 Read access"></a><h3>3.3.3 Read access</h3>A read access transaction looks like this:<br><img src="usercontent,img,1247429086" alt="Debug Read Transaction" title="Debug Read Transaction"><img src="http://opencores.org/usercontent,img,1247429086" alt="Debug Read Transaction" title="Debug Read Transaction"><a name="3.4 Read/Write burst implementation for the CPU Memory access"></a><h2>3.4 Read/Write burst implementation for the CPU Memory access</h2>In1150,13 → 1150,13<h3>3.4.1 Write Burst access</h3>A write burst transaction looks like this:<br><img src="usercontent,img,1247430408" alt="Debug Write Burst Transaction" title="Debug Write Burst Transaction"><img src="http://opencores.org/usercontent,img,1247430408" alt="Debug Write Burst Transaction" title="Debug Write Burst Transaction"><a name="3.4.2 Read Burst access"></a><h3>3.4.2 Read Burst access</h3>A read burst transaction looks like this:<br><img src="usercontent,img,1247430449" alt="Debug Read Burst Transaction" title="Debug Read Burst Transaction"><img src="http://opencores.org/usercontent,img,1247430449" alt="Debug Read Burst Transaction" title="Debug Read Burst Transaction"><a name="4. Debug Communication Interface: I2C"></a><div style="text-align: right;"><a href="#TOC">Top</a></div>1172,7 → 1172,7There are plenty tutorials on Internet regarding the I2C protocol (see the official <a href="http://www.nxp.com/documents/user_manual/UM10204.pdf">I2C specification</a> for more info).<br>A simple byte read or write frame looks as following:<br><br><img src="usercontent,img,1352582784" alt="I2C Protocol" title="I2C Protocol" width="80%"><img src="http://opencores.org/usercontent,img,1352582784" alt="I2C Protocol" title="I2C Protocol" width="80%"><br><a name="4.2 Synchronization frame"></a><h2>4.2 Synchronization frame</h2>Unlike the UART interface, the I2C is a synchronous communication protocol.<br>1188,7 → 1188,7<h3>4.3.1 Command Frame</h3>The command frame looks as following:<br><img src="usercontent,img,1352584261" alt="Debug command frame" title="Debug command frame" width="100%"><img src="http://opencores.org/usercontent,img,1352584261" alt="Debug command frame" title="Debug command frame" width="100%"><br><table border="0"><tbody><tr>1209,13 → 1209,13<h3>4.3.2 Write access</h3>A write access transaction looks like this:<br><img src="usercontent,img,1352586896" alt="I2C Debug Write Transaction" title="I2C Debug Write Transaction" width="100%"><img src="http://opencores.org/usercontent,img,1352586896" alt="I2C Debug Write Transaction" title="I2C Debug Write Transaction" width="100%"><a name="4.3.3 Read access"></a><h3>4.3.3 Read access</h3>A read access transaction looks like this:<br><img src="usercontent,img,1352586064" alt="I2C Debug Read Transaction" title="I2C Debug Read Transaction" width="100%"><img src="http://opencores.org/usercontent,img,1352586064" alt="I2C Debug Read Transaction" title="I2C Debug Read Transaction" width="100%"><a name="4.4 Read/Write burst implementation for the CPU Memory access"></a><h2>4.4 Read/Write burst implementation for the CPU Memory access</h2>In1227,13 → 1227,13<h3>4.4.1 Write Burst access</h3>A write burst transaction looks like this:<br><img src="usercontent,img,1352673100" alt="I2C Debug Write Burst Transaction" title="I2C Debug Write Burst Transaction" width="100%"><img src="http://opencores.org/usercontent,img,1352673100" alt="I2C Debug Write Burst Transaction" title="I2C Debug Write Burst Transaction" width="100%"><a name="4.4.2 Read Burst access"></a><h3>4.4.2 Read Burst access</h3>A read burst transaction looks like this:<br><img src="usercontent,img,1352672466" alt="I2C Debug Read Burst Transaction" title="I2C Debug Read Burst Transaction" width="100%"><img src="http://opencores.org/usercontent,img,1352672466" alt="I2C Debug Read Burst Transaction" title="I2C Debug Read Burst Transaction" width="100%"><div style="text-align: right;"><a href="#TOC">Top</a></div>/html/overview.html11,7 → 11,7family</a></b> and can execute the code generated by any MSP430 toolchain in a near cycle accurate way.<br><br>The core comes with some peripherals (<b>16x16 Hardware Multiplier, </b>Watchdog,GPIO, TimerA, generic templates) and most notably with a two-wire <b>SerialGPIO, TimerA, generic templates), with a DMA interface, and most notably with a two-wire <b>SerialDebug Interface</b> supporting the<b> <a href="http://sourceforge.net/apps/mediawiki/mspgcc/index.php?title=MSPGCC_Wiki" target="_blank">MSPGCC</a> GNU Debugger</b> (GDB) for in-systemsoftware debugging. <br><br>84,6 → 84,7<li>Low Power Modes (LPMx).</li><li>Configurable memory size for both program and data.</li><li>Scalable peripheral address space.</li><li>DMA interface.</li><li>Two-wire Serial Debug Interface (I<sup>2</sup>C or UART based) with GDB support (Nexus class 3, w/o trace).</li><li>FPGA friendly (option for single clock domain, no clock gate).</li><li>ASIC friendly (options for full power & clock management support).<br>/html/core.html70,7 → 70,7The following diagram shows the openMSP430 design structure:<br><br><img src="http://opencores.org/usercontent,img,1354053264" alt="CPU Structure" title="CPU Structure" width="80%"><img src="http://opencores.org/usercontent,img,1430426442" alt="CPU Structure" title="CPU Structure" width="80%"><br><ul><li><b>Frontend</b>: This module performs the instruction Fetch and Decode tasks. It also contains the execution state machine.</li>82,8 → 82,8(without trace). Communication with the host is performed with a standardtwo-wire interface following either the UART 8N1 or I<sup>2</sup>C serial protocol.</li><li><b>Memory backbone</b>: This blockperforms a simple arbitration between the frontend and execution-unitfor program, data and peripheral memory access.</li>performs a simple arbitration between frontend, execution-unit, DMA and Serial-Debug interfacesfor program, data and peripheral memory accesses.</li><li><b>Basic Clock Module</b>: Generates MCLK, ACLK, SMCLK and manage the low power modes.</li><li><b>SFRs</b>: The <b>S</b>pecial <b>F</b>unction <b>R</b>egister<b>s</b> block contain diverse configuration registers (NMI, Watchdog, ...).</li><li><b>Watchdog</b>:239,7 → 239,13`define WATCHDOG<br><br><br>///-------------------------------------------------------<br>//-------------------------------------------------------<br>// Include/Exclude DMA interface support<br>//-------------------------------------------------------<br>//`define DMA_IF_EN<br><br><br>//-------------------------------------------------------<br>// Include/Exclude Non-Maskable-Interrupt support<br>//--------------------------------------------------------<br>`define NMI<br>476,7 → 482,7</tbody></table><br>The values of these parameters are then directly accessible through the CPU_NR register of the SFR peripheral.<br>The values of these parameters are then directly accessible by software through the CPU_NR register of the SFR peripheral.<br>For example, if both cores share the same program memory, the software can take advantage of this information as following:<br><br><table border="0" cellpadding="0" cellspacing="4">520,7 → 526,7toolchain will have to be modified accordingly.<br>The following schematic should hopefully illustrate this:<br><br><br><img src="usercontent,img,1306066277" alt="Memory mapping" title="Memory mapping" width="80%"><img src="http://opencores.org/usercontent,img,1306066277" alt="Memory mapping" title="Memory mapping" width="80%"><br><br><br>710,6 → 716,33<td> Reset Pin (active low, asynchronous and non-glitchy) </td></tr><tr> <td colspan="5" align="center"> <b><i>Interrupts</i></b> </td></tr><tr><td> irq </td><td> Input </td><td> `IRQ_NR-2<b><sup><font color="#ff0000">1</font></sup></b> </td><td style="vertical-align: top; text-align: center;">mclk<br></td><td> Maskable interrupts (one-hot signal) </td></tr><tr><td> nmi </td><td> Input </td><td> 1 </td><td style="vertical-align: top; text-align: center;"><async><br>or mclk<b><sup><font color="#ff0000">4</font></sup></b></td><td> Non-maskable interrupt (asynchronous and non-glitchy)<br>Set to 0 if unused.<br></td></tr><tr><td> irq_acc </td><td> Output </td><td> `IRQ_NR-2<b><sup><font color="#ff0000">1</font></sup></b> </td><td style="vertical-align: top; text-align: center;">mclk<br></td><td> Interrupt request accepted (one-hot signal) </td></tr><tr> <td colspan="5" align="center"> <b><i>Program Memory interface</i></b> </td></tr><tr>836,34 → 869,79</td><td> Peripheral write enable (high active) </td></tr><tr> <td colspan="5" align="center"> <b><i>Interrupts</i></b> </td></tr><tr> <td colspan="5" align="center"> <b><i>Direct Memory Access interface</i></b> </td></tr><tr><td> irq </td><td> Input </td><td> `IRQ_NR-2<b><sup><font color="#ff0000">1</font></sup></b> </td><td style="vertical-align: top; text-align: center;">mclk<br><td> dma_addr </td><td> Input </td><td> 15 </td><td style="vertical-align: top; text-align: center;">mclk<br></td><td> Maskable interrupts (one-hot signal) </td><td> Direct Memory Access address </td></tr><tr><td> dma_din </td><td> Input </td><td> 16 </td><td style="vertical-align: top; text-align: center;">mclk<br></td><td> Direct Memory Access data input </td></tr><tr><td> nmi </td><tr><td> dma_dout </td><td> Output </td><td> 16 </td><td style="vertical-align: top; text-align: center;">mclk<br></td><td> Direct Memory Access data output </td></tr><tr><td> dma_en </td><td> Input </td><td> 1 </td><td style="vertical-align: top; text-align: center;"><async><br>or mclk<b><sup><font color="#ff0000">4</font></sup></b></td><td> Non-maskable interrupt (asynchronous and non-glitchy)<br>Set to 0 if unused.<br></td><td style="vertical-align: top; text-align: center;">mclk<br></td><td> Direct Memory Access enable (high active) </td></tr><tr><td> irq_acc </td><td> dma_priority </td><td> Input </td><td> 1 </td><td style="vertical-align: top; text-align: center;">mclk<br></td><td> Direct Memory Access priority (0:low / 1:high) </td></tr><tr><td> dma_ready </td><td> Output </td><td> `IRQ_NR-2<b><sup><font color="#ff0000">1</font></sup></b> </td><td> 1 </td><td style="vertical-align: top; text-align: center;">mclk<br></td><td> Interrupt request accepted (one-hot signal) </td><td> Direct Memory Access is complete </td></tr><tr><td> dma_resp </td><td> Output </td><td> 1 </td><td style="vertical-align: top; text-align: center;">mclk<br></td><td> Direct Memory Access response (0:Okay / 1:Error) </td></tr><tr><td> dma_we </td><td> Input </td><td> 2 </td><td style="vertical-align: top; text-align: center;">mclk<br></td><td> Direct Memory Access write byte enable (high active) </td></tr><tr><td> dma_wkup </td><td> Input </td><td> 1 </td><td style="vertical-align: top; text-align: center;"><async><br></td><td> ASIC ONLY: DMA Wake-up (asynchronous and non-glitchy) </td></tr><tr> <td colspan="5" align="center"> <b><i>Serial Debug interface</i></b> </td></tr><tr>/openMSP430.odt Cannot display: file marked as a binary type. svn:mime-type = application/octet-stream© copyright 1999-2024 OpenCores.org, equivalent to Oliscience, all rights reserved. OpenCores®, registered trademark.
-
DBG_I2C_ADDR: I2C Device address of the oMSP core (between 8 and 119). In a multi-core configuration each core has its own address.