From 2bcaac06613a967d21c926e86235a0b9116f9b43 Mon Sep 17 00:00:00 2001 From: lkcl Date: Wed, 9 Aug 2023 22:35:20 +0100 Subject: [PATCH] --- 3d_gpu/architecture/inorder_model.mdwn | 28 +++++++++++++++++--------- 1 file changed, 18 insertions(+), 10 deletions(-) diff --git a/3d_gpu/architecture/inorder_model.mdwn b/3d_gpu/architecture/inorder_model.mdwn index c17b49e63..617a5ea22 100644 --- a/3d_gpu/architecture/inorder_model.mdwn +++ b/3d_gpu/architecture/inorder_model.mdwn @@ -30,34 +30,42 @@ Diagram that Luke drew comparing pipelines and fsms which allows for a transitio The model for the Single-Issue In-Order core needs to be added to the in-house Python simulator (`ISACaller`, called by `pypowersim`), which will allow basic -*performance estimates*. +*performance estimates*. INCORRECT - pypowersim *outputs an execution trace log* +which **after the fact** may be passed to **any** model of which the in-order +model is **just the very first**. For now, this model resides outside the simulator, and -is *completely standalone*. +is *completely standalone* **and will ALWAYS remain standalone** + +A subtask to be carried out **as incremental development** +is that avatools source code will need to be studied to extract +power consumption estimation and add that into the inorder model -Eventually, Cavatools code will be studied to extract and re-implement in -Python power consumption estimation. ## Task given * [Bug comment #1](https://bugs.libre-soc.org/show_bug.cgi?id=1039#c1) * [IRC log](https://libre-soc.org/irclog/%23libre-soc.2023-05-02.log.html#t2023-05-02T10:51:45) -An offline instruction ordering analyser need to be written that models a +The offline instruction ordering analyser need to be **COMPLETED** +(it is currently 98% complete) that models a (simple, initially V3.0-only) **in-order core** and gives an estimate of instructions per clock (IPC). -Hazard Protection should be straightforward, simple bit vector: +Hazard Protection **WHICH IS ALREADY COMPLETED** is a straightforward, simple bit vector +(WRONG it is a "length of pipeline countdown until result is ready" which models the +clock cycles needed in the ACTUAL pipeline(s)? the "bit" you refer to is +"is there an entry in the python set() for this register yes-or-no") -- Take the write result register number: set bit -- For all read registers, check corresponding bit. If bit is set, STALL (fake/ +- Take the write result register number: set bit WRONG "add num-cycles-until-ready to the set()" +- For all read registers, check corresponding bit WRONG call the function that checks if there is an entry in the "python set() of expected outstanding results to be written" . If bit is set, STALL (fake/ model-stall) A stall is defined as a delay in execution of an instruction in order to resolve a hazard (i.e. trying to read a register while it is being written to). See the [wikipedia article on Pipeline Stall](https://en.wikipedia.org/wiki/Pipeline_stall) -Input should be: +Input **IS** (98% completed, remember?): - Instruction with its operands (as assembler listing) - plus an optional memory-address and whether it is read or written. @@ -65,7 +73,7 @@ Input should be: The input will come as a trace output from the ISACaller simulator, [see bug comments #7-#16](https://bugs.libre-soc.org/show_bug.cgi?id=1039#c7) -Some classes needed which "model" pipeline stages: fetch, decode, issue, +Some classes needed (WRONG: ALREADY WRITTEN) which "model" pipeline stages: fetch, decode, issue, execute. One global "STALL" flag will cause all buses to stop: -- 2.30.2