| cesar[m]1 | lkcl: Just letting you know that I'm working on it, based on the changes to the FSMs that you did so far. | 09:48 |
|---|---|---|
| cesar[m]1 | Reading of SVSTATE needs to move from issue to the execute FSM, so it can see the srcstep it just updated. | 10:44 |
| cesar[m]1 | ... MSR as well, I guess. That way, the execute FSM may keep working the loop without ever activating the fetch FSM. | 11:06 |
| cesar[m]1 | I think the INSN_FETCH state of the execute FSM may be a good place to place those. | 11:14 |
| cesar[m]1 | The core_stop signal should be handled there as well, to allow stopping the core in the middle of a VL loop. | 11:14 |
| lkcl | yes, fetch issue execute should all be separate | 13:28 |
| lkcl | ahh yes, definitely the stop should not issue a new sub-instruction | 13:29 |
| lkcl | MSR can stay where it is because it never gets read/written to under "loop" conditions | 13:30 |
| lkcl | (there are no SVP64 MSR instructions) | 13:30 |
| lkcl | but... ahh... there are interrupts / exceptions | 13:30 |
| lkcl | but... no, hang on | 13:31 |
| lkcl | anything in SVSTATE needs to be sent "read-only" to execute | 13:31 |
| lkcl | but execute may *change* MSR (and PC) if there is a branch or an exception. | 13:32 |
| lkcl | tck,,, tck... | 13:32 |
| * lkcl thinks | 13:32 | |
| lkcl | MSR can stay where it is for now. | 13:33 |
| lkcl | exceptions will stop the loop because SVSTATE, PC, and MSR will all be swapped into SRR0, SRR1 and SVSRR0 respectively | 13:33 |
| lkcl | and written into StateRegs *by* the Trap Pipeline | 13:34 |
| lkcl | Branch and MTMSR, these are *not* SVP64-Vectorised instructions so that's safe... | 13:35 |
| lkcl | yes, MSR and PC can stay in the INSN-FETCH FSM | 13:35 |
| lkcl | SVSTATE on the other hand cannot. | 13:35 |
| lkcl | SVSTATE has to be read in the ISSUE FSM and *written* in the ISSUE FSM | 13:36 |
| lkcl | setvl is the only instruction permitted to modify SVSTATE directly, and this is *not* Vectoriseable, so that's ok too | 13:36 |
| lkcl | ah: a detection of write to SVPSTATE is going to be needed (just like with PC) | 13:40 |
| lkcl | i will add that | 13:40 |
| lkcl | done | 13:43 |
| lkcl | when an exception happens, Trap pipeline handles it and makes the request to write a new PC, new MSR, and now also new SVSTATE. | 13:49 |
| lkcl | those *must* be noticed so that the issue FSM can stop running and move to fetch, also not to overwrite the SVSTATE! | 13:50 |
| lkcl | just like with pc_changed. | 13:50 |
| lkcl | pc_changed is there because if the Branch or Trap pipelines set a new PC, the NIA (PC+4/8) must not overwrite that! | 13:50 |
| lkcl | exact same thing for SVSTATE | 13:50 |
| lkcl | srcstep | 13:51 |
| lkcl | oh, the other reason why MSR and SVSTATE has to stay in fetch: they're used as part of decode. MSR affects LE/BE for example. | 16:33 |
| lkcl | cesar[m]1, https://bugs.libre-soc.org/show_bug.cgi?id=583 | 19:07 |
| lkcl | i *think* it's that simple. maybe 30 lines of code? and changing the handshake ready/valid. i will note that | 19:08 |
| lkcl | meeting 10min | 21:49 |
| lkcl | programmerjake[m, ^ | 21:49 |
| lkcl | cesar[m]1, ^ | 21:49 |
| lkcl | lxo, ^ | 21:49 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!