doc: update doc for 1.0.2 release

Signed-off-by: Huaqi Fang <[email protected]>

NMSIS/doc/source/changelog.rst

@@ -3,14 +3,45 @@
 Changelog
 =========
 
+V1.0.2
+------
+
+This is the official release version ``V1.0.2`` release of Nuclei MCU Software Interface Standard(NMSIS).
+
+The following changes has been made since ``V1.0.1``.
+
+* **Documentation**
+
+  - Update NMSIS Core/DSP/NN related documentation
+
+* **Device Templates**
+
+   - DOWNLOAD_MODE_xxx macros are removed from riscv_encoding.h, it is now defined as enum in ``<Device.h>``, and
+     can be customized by soc vendor.
+   - startup code now don't rely on DOWNLOAD_MODE macro, instead it now rely on a new macro called VECTOR_TABLE_REMAPPED,
+     when VECTOR_TABLE_REMAPPED is defined, it means the vector table's lma != vma, such as vector table need to be
+     copied from flash to ilm when boot up
+   - Add more customized csr of Nuclei RISC-V Core
+   - Add **BIT**, **BITS**, **REG**, **ADDR** related macros in ``<Device.h>``
+
+* **NMSIS-Core**
+
+   - Nuclei Cache CCM operation APIs are now introduced in core_feature_cache.h
+   - Update NMSIS-Core header files
+
+* **NMSIS-DSP/NN**
+
+   - Merged the official CMSIS 5.8.0 release, CMSIS-DSP 1.9.0, CMSIS-NN 3.0.0
+   - RISC-V Vector extension and P-extension support for DSP/NN libraries are added
+
 V1.0.2-RC2
 ----------
 
 This is the release candidate version ``V1.0.2-RC2`` release of Nuclei MCU Software Interface Standard(NMSIS).
 
 The following changes has been made since ``V1.0.2-RC1``.
 
-* Documentation
+* **Documentation**
 
   - Update NMSIS Core/DSP/NN related documentation
 
@@ -43,7 +74,7 @@ The following changes has been made since ``V1.0.1``.
 V1.0.1
 ------
 
-This is the offical ``V1.0.1`` release of Nuclei MCU Software Interface Standard(NMSIS).
+This is the official ``V1.0.1`` release of Nuclei MCU Software Interface Standard(NMSIS).
 
 The following changes has been maded since ``V1.0.1-RC1``.
 

NMSIS/doc/source/conf.py

@@ -21,10 +21,10 @@
 author = 'Nuclei'
 
 # The short X.Y version
-version = '1.0.2-RC2'
+version = '1.0.2'
 
 # The full version, including alpha/beta/rc tags
-release = '1.0.2-RC2'
+release = '1.0.2'
 
 
 # -- General configuration ---------------------------------------------------

NMSIS/doc/source/core/core_template_device_header.rst

@@ -6,8 +6,11 @@ Device Header File <device.h>
 The :ref:`core_template_device_header` contains the following sections that are device specific:
   - :ref:`core_interrupt_num_def` provides interrupt numbers (IRQn) for all exceptions and interrupts of the device.
   - :ref:`nmsis_core_configuration` reflect the features of the device.
-  - :ref:`core_device_periph_access` provides definitions for the :ref:`core_api_periph_access` to all device peripherals. It contains all data structures and the address mapping for device-specific peripherals.
-  - **Access Functions for Peripherals (optional)** provide additional helper functions for peripherals that are useful for programming of these peripherals. Access Functions may be provided as inline functions or can be extern references to a device-specific library provided by the silicon vendor.
+  - :ref:`core_device_periph_access` provides definitions for the :ref:`core_api_periph_access` to all device peripherals.
+    It contains all data structures and the address mapping for device-specific peripherals.
+  - **Access Functions for Peripherals (optional)** provide additional helper functions for peripherals that are useful
+    for programming of these peripherals. Access Functions may be provided as inline functions or can be extern references
+    to a device-specific library provided by the silicon vendor.
 
 :ref:`nmsis_core_api` describes the standard features and functions of the :ref:`core_template_device_header` in detail.
 
@@ -48,7 +51,7 @@ The following example shows the extension of the interrupt vector table for the
         Reserved14_IRQn              =  16,     /*!<  Internal reserved                        */
         HardFault_IRQn               =  17,     /*!<  Hard Fault, storage access error         */
         Reserved15_IRQn              =  18,     /*!<  Internal reserved                        */
-    
+
         /******  GD32VF103 Specific Interrupt Numbers ******************************************/
         WWDGT_IRQn                   =  19,     /*!< window watchDog timer interrupt           */
         LVD_IRQn                     =  20,     /*!< LVD through EXTI line detect interrupt    */

NMSIS/doc/source/core/core_template_intexc.rst

@@ -19,17 +19,20 @@ Click `NMI`_ to learn about Nuclei Processor Core NMI in Nuclei ISA Spec.
 NMI is used for urgent external HW error. It can't be masked and disabled.
 
 When NMI happened, bit 9 of CSR ``MMSIC_CTL`` will be checked.
-If this bit value is 1, then NMI entry address will be the same as exception(CSR_MTVEC), and exception code for NMI will be 0xFFF, otherwise NMI entry will be same as reset_vector.
+If this bit value is 1, then NMI entry address will be the same as exception(CSR_MTVEC),
+and exception code for NMI will be 0xFFF, otherwise NMI entry will be same as reset_vector.
 
-In NMSIS-Core, the bit 9 of CSR ``MMISC_CTL`` is set to 1 during core startup, so NMI will be treated as Exception and handled.
+In NMSIS-Core, the bit 9 of CSR ``MMISC_CTL`` is set to 1 during core startup,
+so NMI will be treated as Exception and handled.
 
 
 Exception
 ---------
 
 Click `Exception`_ to learn about Nuclei Processor Core Exception in Nuclei ISA Spec.
 
-For CPU exception, the entry for exception will be ``exc_entry``, in this entry code, it will call default exception handler :cpp:func:`core_exception_handler`.
+For CPU exception, the entry for exception will be ``exc_entry``, in this entry code,
+it will call default exception handler :cpp:func:`core_exception_handler`.
 
 In the common exception routine(``exc_entry``) to get more information like exception code.
 Exception handle flow show as below picture:
@@ -52,11 +55,14 @@ We support three nesting mode as below:
 - Exception nesting NMI
 
 
-For software, we have provided the common entry for NMI and exception. Silicon vendor only need adapt the interface defined in :ref:`core_api_intexc_nmi_handling`.
+For software, we have provided the common entry for NMI and exception. Silicon vendor only need adapt
+the interface defined in :ref:`core_api_intexc_nmi_handling`.
 
 Context save and restore have been handled by ``exc_entry`` interface.
 
-When exception exception return it will run the intruction which trigger the exception again. It will cause software dead loop. So in the exception handler for each exception code, we propose to set CSR ``MEPC`` to be ``MEPC+4``, then it will start from next instruction of MEPC.
+When exception exception return it will run the instruction which trigger the exception again.
+It will cause software dead loop. So in the exception handler for each exception code,
+we propose to set CSR ``MEPC`` to be ``MEPC+4``, then it will start from next instruction of MEPC.
 
 Interrupt
 ---------
@@ -65,7 +71,8 @@ Click `Interrupt`_ to learn about Nuclei Processor Core Interrupt in Nuclei Spec
 
 Interrupt could be configured as **CLINT** mode or **ECILC** mode.
 
-In NMSIS-Core, Interrupt has been configured as **ECLIC** mode during startup in *startup_<Devices>.S*, which is also recommended setting using Nuclei Processors.
+In NMSIS-Core, Interrupt has been configured as **ECLIC** mode during startup in *startup_<Devices>.S*,
+which is also recommended setting using Nuclei Processors.
 
 ECLIC managed interrupt could configured as **vector** and **non-vector** mode.
 
@@ -81,9 +88,10 @@ Detail interrupt handling process as below picture:
     Interrupt Handling Flow
 
 
-To get highest priority interrupt we need compare the interrupt level first.If level is the same then compare the priority. High level interrupt could interrupt low level
-ISR and trigger interrupt nesting. If different priority with same level interrupt pending higher priority will be served first. Interrupt could be configured as vector mode 
-and non-vector mode by vendor. For non-vector mode interrupt handler entry get from MTVT2 and exception/NMI handler entry get from MTVEC. If Vendor need set non vector mode
+To get highest priority interrupt we need compare the interrupt level first.If level is the same then compare the priority.
+High level interrupt could interrupt low level ISR and trigger interrupt nesting. If different priority with same level
+interrupt pending higher priority will be served first. Interrupt could be configured as vector mode and non-vector mode by vendor.
+For non-vector mode interrupt handler entry get from MTVT2 and exception/NMI handler entry get from MTVEC. If Vendor need set non vector mode
 interrupt handler entry from ``MTVVEC`` you need set ``MTVT2.BIT0`` as 0.
 
 
@@ -110,7 +118,9 @@ Non-vector mode software handle flow show as below pciture:
 
 3. Save CSR registers ``MEPC/MCAUSE/MSUBM`` to stack.
 
-4. Run instruction ``csrrw ra, CSR_JALMNXTI, ra``. It will enable interrupt, check interrupt pending. If interrupt is pending then get highest priority interrupt and jump to interrupt handler entry in the vector table, otherwise it will go to step 6.
+4. Run instruction ``csrrw ra, CSR_JALMNXTI, ra``. It will enable interrupt, check interrupt pending.
+If interrupt is pending then get highest priority interrupt and jump to interrupt handler entry in the vector table,
+otherwise it will go to step 6.
 
 5. Execute the interrupt handler routine, when return from isr routine it will jump to step 4.
 
@@ -122,7 +132,7 @@ Non-vector mode software handle flow show as below pciture:
 
 9. Execute ``mret`` to return from handler.
 
-For **non-vector** mode iterrupt it could support **interrupt nesting**. 
+For **non-vector** mode iterrupt it could support **interrupt nesting**.
 
 **Interrupt nesting** handle flow show as below picture:
 

NMSIS/doc/source/core/core_template_system_device.rst

@@ -7,7 +7,9 @@ The **System Configuration Files system_<device>.c and system_<device>.h**
 provides as a minimum the functions described under :ref:`core_api_system_device`.
 
 These functions are device specific and need adaptations. In addition, the file might have
-configuration settings for the device such as XTAL frequency or PLL prescaler settings, necessary system initilization, vendor customized interrupt, exception and nmi handling code, refer to :ref:`core_api_system_device` for more details.
+configuration settings for the device such as XTAL frequency or PLL prescaler settings,
+necessary system initialization, vendor customized interrupt, exception and nmi handling code,
+refer to :ref:`core_api_system_device` for more details.
 
 For devices with external memory BUS the ``system_<device>.c`` also configures the BUS system.