diff --git a/doc/atomic_ops.md b/doc/atomic_ops.md
new file mode 100644
index 0000000..f092a38
--- /dev/null
+++ b/doc/atomic_ops.md
@@ -0,0 +1,94 @@
+# Atomic Operations Support
+
+## Overview
+
+From [OS dev wiki](https://wiki.osdev.org/Atomic_operation):
+
+    An atomic operation is an operation that will always be executed without any other process being
+    able to read or change state that is read or changed during the operation. It is effectively
+    executed as a single step, and is an important quality in a number of algorithms that deal with
+    multiple independent processes, both in synchronization and algorithms that update shared data
+    without requiring synchronization.
+
+For single core system:
+
+    If an operation requires multiple CPU instructions, then it may be interrupted in
+    the middle of executing. If this results in a context switch (or if the interrupt handler refers
+    to data that was being used) then atomicity could be compromised. It is possible to use any
+    standard locking technique (e.g. a spinlock) to prevent this, but may be inefficient. If it is
+    possible, disabling interrupts may be the most efficient method of ensuring atomicity (although
+    note that this may increase the worst-case interrupt latency, which could be problematic if it
+    becomes too long).
+
+For multi core system:
+
+    n multiprocessor systems, ensuring atomicity exists is a little harder. It is still possible to
+    use a lock (e.g. a spinlock) the same as on single processor systems, but merely using a single
+    instruction or disabling interrupts will not guarantee atomic access. You must also ensure that
+    no other processor or core in the system attempts to access the data you are working with.
+
+The aim of this dev (made from v1.6.1) is to support atomic operation instructions. Atomic
+operations will bring synchronization techniques required by kernels. The goal is to be able to boot
+a kernel like FreeRTOS or Linux (without MMU) and makes the core a platform for real worl usecases.
+`AMO` will be implemetned in a dedicated processing unit and in load/store stage (`memfy`). `AMO` unit
+will issue read/write request to `memfy` with a specific and unique ID. dCache will also be updated
+to better support `ACACHE`, slighlty change `AID` and put in place exclusive access.
+
+## AXI Ordering
+
+To be documented
+
+## Master
+
+## Slave
+
+# Interconnect
+
+
+## Design Plan
+
+### Overview
+
+When `AMO` unit receives an atomic operation:
+- it reserves its `rs1`/`rs2`/`rd` registers
+- it issues to `memfy` a read request to a memory register with:
+    - a specific ID (i.e. `0x40`)
+    - an exclusive access
+    - `ACACHE=0x0` as `non-cachable` and `non-bufferable`
+- it executes the atomic operation
+- it issues to `memfy` a request with the same attributes
+    - a write request to update the memory register
+    - a read request to release the memory register
+
+Using a single `ID` will ensure in-order completions
+
+### AMO Unit
+
+`AMO` will be able:
+- to execute only one exclusive access at a time, `device`-like access
+- to support al RISCV atomic operation
+
+### Processing Unit
+
+TBD
+
+### Memfy Unit
+
+Issue a dedicated single ID, so in-order, `non-cachable` and `non-bufferable`
+Can handle exclusive access and normal access for best bandwidth
+Should be able to manage completion reodering (possible enhancement)
+
+### dCache Unit
+
+Needs to support exclusive access
+- OoO stage should manage exclusive access in a dedicated LUT
+- Don't replace ID for exclusive access
+- Exclusive access = `device` like access (no cache)
+
+Out of exclusive access scope, the cache should be able to manage different IDs and don't
+substitute all the time them. Better performance. Reordering should be done only on different IDs.
+
+## Test Plan
+
+- An atomic operation can't be stopped if control unit manages async/sync exceptions
+
diff --git a/doc/project_mgt_hw.md b/doc/project_mgt_hw.md
index d0f7ff4..393fe98 100644
--- a/doc/project_mgt_hw.md
+++ b/doc/project_mgt_hw.md
@@ -5,9 +5,6 @@
     - [X] Support U-mode
     - [X] Support PMP/PMA
     - [X] https://github.com/eembc/coremark
-    - [ ] Advanced Interrupt controller
-        - [ ] AXI ERR handling
-        - [ ] AXI EXOKAY handling
     - [ ] Atomic operations
         - stage to execute the instruction, controlling ldst Stages
         - memfy exposes two interfaces for requests.
@@ -26,6 +23,7 @@ Any new features should be carefully study to ensure a proper exception and inte
 
 ## Memory
 
+- [ ] Bus fault to route on exceptions https://lists.riscv.org/g/tech-privileged/topic/80351141
 - [ ] Better manage ACACHE attribute
     - [ ] Correct value driven from memfy
     - [ ] Use it correctly across the cache
@@ -55,6 +53,7 @@ Any new features should be carefully study to ensure a proper exception and inte
 
 ## Cache Stages
 
+- [ ] Add dedicated RAM for cache, not connected thru AXI interconnect
 - [ ] AXI4 + Wrap mode for read
 - [ ] Support datapath adaptation from memory controller
     - [ ] Narrow transfer support?