5. Architecture Overview
Diagram of the ECAP5-DPROC architecture
5.1. Clock domains
| ID | A_CLOCK_DOMAIN_01 |
| Description | All modules of ECAP5-DPROC shall belong to a unique clock domain. |
| Rationale | This is to facilitate the design of version 1.0.0. |
5.2. Functional partitioning
- ECAP5-DPROC is built around a pipelined architecture with the following stages :
The instruction fetch stage loads the next instruction from memory.
The decode stage handles the instruction decoding to provide the next stage with the different instruction input values including reading from internal registers.
The execute stage implements all arithmetic and logic operations.
The load/store stage implements load/store operations.
The write-back stage which handles storing instructions outputs to internal registers.
| ID | A_FUNCTIONAL_PARTITIONING_01 |
| Description | The memory module shall arbitrate memory requests from both the fetch module and the loadstore module. |
| Derived from |
| ID | A_MEMORY_01 |
| Description | The memory module shall give priority access to the external memory bus for the fetch module. |
| ID | A_FUNCTIONAL_PARTITIONING_02 |
| Description | The fetch module shall implement the instruction fetch stage of the pipeline. |
| ID | A_FUNCTIONAL_PARTITIONING_03 |
| Description | The decode module shall implement the decode stage of the pipeline. |
| ID | A_FUNCTIONAL_PARTITIONING_04 |
| Description | The register module shall implement the internal general-purpose registers. |
| ID | A_FUNCTIONAL_PARTITIONING_05 |
| Description | The execute module shall implement the execute stage of the pipeline. |
| ID | A_FUNCTIONAL_PARTITIONING_06 |
| Description | The loadstore module shall implement the load/store stage of the pipeline. |
| ID | A_FUNCTIONAL_PARTITIONING_07 |
| Description | The writeback module shall implement the write-back stage of the pipeline. |
| ID | A_WRITEBACK_01 |
| Description | The writeback module shall perform its operation in a single cycle. |
| ID | A_FUNCTIONAL_PARTITIONING_08 |
| Description | The hazard module shall handle the detection of data and control hazards as well as trigger the associated pipeline stalls and pipeline drops. |
5.3. Hazard management
5.3.1. Pipeline stall
In order to handle pipeline stalls, a handshaking mechanism is implemented between each stages, allowing the execution flow to be stopped. A stall can be either triggered by a stage itself or requested by the hazard module.
Diagram of the pipeline stall behavior
Pipeline stages located at the start and end of the pipeline do not implement the bubble and wait modes respectively.
- The following points describe the behavior of the different modes :
A stage in normal mode shall operate as described by its different functional behaviors.
A stage in stall mode shall deassert its input ready signal and output valid signal while waiting to unstall.
A stage in bubble mode shall operate as normal but taking a nop instruction as input instead of the data provided by the preceding stage.
A stage in wait mode shall deassert its input ready signal and wait until going back to normal mode.
In case of a stall, the stalling stage deasserts its input ready signal leading to preceding stages waiting for completion. The stalling stage deasserts its output valid signal leading to following stages taking a bubble as their input.
The following figure is a timing diagram of the stall behavior of a 5-stage pipeline where the 3 rd stage is stalled on the 4 th cycle. By stalling the 3 rd stage, this example provides a representative visualisation of all the stalling states of the pipeline stages.
Timing diagram of the pipeline stall behavior
| ID | A_PIPELINE_WAIT_01 |
| Description | The following modules shall implement the pipeline wait state : fetch, decode, execute. |
| Rationale | The loadstore module doesn’t need to implement the pipeline wait state as the writeback module performs its operation in a single cycle (refer to A_REGISTER_01). |
| ID | A_PIPELINE_BUBBLE_01 |
| Description | The following modules shall implement the pipeline bubble state : decode, execute, loadstore and writeback. |
5.3.2. Structural hazard
For the scope of this document, are designated as structural hazards all cases when a stage is unable to finish its processing within the required time before the next clock cycle.
| ID | A_PIPELINE_STALL_01 |
| Description | The fetch module shall stall the pipeline while performing the memory request. The pipeline shall be unstalled after completing the request. |
| ID | A_PIPELINE_STALL_02 |
| Description | The loadstore module shall stall the pipeline while performing the memory request. The pipeline shall be unstalled after completing the request. |
Note
It shall be noted that the some of the performance impact of this kind of hazard could be mitigated but this feature is not included in version 1.0.0.
5.3.3. Data hazard
A data hazard occurs when an instruction (A) uses the result of a previous instruction (B) which is still being processed in the pipeline.
A pipeline stall is produced in case of data hazards so that B is able to finish before A uses its result.
| ID | A_HAZARD_01 |
| Description | The hazard module shall issue a stall request to the decode module while a write operation to one of the next registers to be read by decode is to be performed by the following modules : decode (current output), execute, loadstore and writeback. |
| Rationale | Stalling the decode module inserts pipeline bubbles to the subsequent modules. |
| ID | A_PIPELINE_STALL_03 |
| Description | The decode module shall stall the pipeline upon stall request from the hazard module. |
| ID | A_PIPELINE_STALL_04 |
| Description | While stalling the pipeline due to a stall request from the hazard module, the decode module shall clear its register outputs. |
| Rationale | In the case where the data hazard is cause by the current decode output, not clearing the decode module’s outputs will lead to the hazard module stalling the decode module indefinitely. |
Note
It shall be noted that some of the performance impact of this kind of hazard could be mitigated but this feature is not included in version 1.0.0.
5.3.4. Control hazard
A control hazard occurs when a jump or branch instruction is executed, as instructions following the jump/branch are already being processes through the pipeline when the jump/branch happens.
Instructions following the jump/branch are replaced by a nop instruction through the use of the bubble mode of the pipeline stages. This operation is designated as pipeline drop.
| ID | A_HAZARD_02 |
| Description | The hazard module shall issue a pipeline drop request to the execute module on the rising edge of clk_i after the execute module has issued a branch request to the fetch module. The pipeline drop request shall be held asserted for two cycles. |
| Rationale | The pipeline drop is held asserted for two cycles to flush both the fetch and decode outputs. |
| ID | A_PIPELINE_DROP_01 |
| Description | The execute module shall discard the decode module’s output and output a pipeline bubble upon drop request from the hazard module. |
Note
It shall be noted that some of the performance impact of this kind of hazard could be mitigated but this feature is not included in version 1.0.0.
5.4. Module interfaces
Note
The module’s interfaces and functional behaviors are not described further in this document and are left to the designer’s judgement.