Conversation
i dont know how you managed to not publish those files without them having to be delete manually every time.
weird inconsistent failure gets thrown when reversing the processor, with yet unknown reason: Multiple changes for port 5-Stage static dual-issue VLIW RISC-V Processor->ifid_reg->pc8_reg->out during a single cycle or similar.
+ removed handful of preliminary return statements in rv_decode to be consistent with the other switch cases. + added explicit decoding of the nop instruction. This allows for more delicate generation of control signals especially for processors where some ways do not support the addi instruction but need a way of correctly detecting a nop. + adjusted currently implemented processors to be consistent with previous implementation.
+ added StageInfo::State::Invalid to indicate that the decoded instruction is invalid for a given lane and therefore will fallthrough w/o being executed + added red crossed out visualization for the Invalid state for the instruction labels + added signals to all pipeline stages of the vliw proc to propagate validity of stage instruction
…egister write order
+ added interface in RV_ISAInfoBase to allow for Implementation Details to adapt instructions for custom implementations + added VLIW Pseudo instructions to the rv i extension
Some processor stage names like "ID 1" or "IF 2" the last part (here "1" or "2") sometimes gets cut off when printed on the line next to the instruction. Using horizontal advance will now correctly calculate the text width so that no characters get cut off and be more accurately horizontally aligned.
+ adapted existing QAssembler & ISA_Assembler to allow for generic inheritance + added VLIW Assembler to constructAssembelrDynamic + new multi issue assembler emits errors on invalid way instruction for visual feedback to the editor
was initially confused and forgot to build in a separate build folder :O
|
Awesome addition! I'm going to be annoying here and ask that you split this PR out into a few separate, atomic PRs, mainly to separate adding the model from all of the non-model specific changes (assembler, isa, ...). That'll also make it easier for me to review :) Although you've probably done a lot of verification already, to my eyes it seems like the model is only being tested on the tests in the RISCV_VLIW_TEST_DIR directory. The model should also pass all of the "regular" tests in the RISCV32_TEST_DIR/RISCV64_TEST_DIR directories and the And likewise, there is nothing preventing the other models from passing the VLIW tests, correct? So if you can do something here to better organize the tests such that all existing models gets these new VLIW tests, and the VLIW model gets all of the existing tests, that'd be great. The easy solution is obviously jsut to add this new test directory for all of the processors in |
|
Hey, thanks for the feedback. I agree that this PR is quite large, so I am working on splitting it into smaller, more manageable parts. Regarding the last two points: Due to the statically dual-issued nature of this VLIW processor, the suggested changes unfortunately are not feasible. As the name Very Long Instruction Word implies, each VLIW instruction consists of two regular RISC-V instructions issued in parallel. All instruction-way control must therefore be resolved offline during assembly, not dynamically at runtime. This design imposes strict pairing rules on VLIW programs: Because both instructions in a pair execute simultaneously, valid VLIW programs can be invalid for other processors. For example: bne a0, a1, loop # inst1: ALU
lw a0, 0(a2) # inst2: loadHere, a branch and a load occur in the same cycle, which is not legal on a non-VLIW core. While VLIW programs can sometimes be written to remain compatible with non-VLIW processors, this is not generally possible. I explored the idea of co-simulation, but return address differences (and other control-flow effects) immediately cause divergence, making meaningful co-simulation impractical. For similar reasons, running the standard RISCV32_TEST_DIR / RISCV64_TEST_DIR suites is not possible. Those tests assume standard single-issue instruction semantics and cannot be executed as-is on a dual-issue VLIW architecture. Converting the entire suite into VLIW-valid programs would require substantial manual effort. Given these constraints, I focused on designing comprehensive custom tests that target all VLIW-specific behavior. Since these tests pass and many components are shared with the existing 5-stage and 6-stage processors, I am confident in the correctness of the implementation. Let me know if you’d like additional clarification or if there’s a specific aspect you want deeper coverage on. |
|
@NLS-04 That makes sense, I think i missed the fact that this model is then effectively statically scheduled. Please educate me here - while i get that it's a valid design point, is this "legal" in terms of official ISA specs? I've been under the (probably) fairly naive assumption that the RISC-V ISA is a dynamically scheduled ISA, and binary compatibility is only based off of ISA width and supported ISA extensions... I guess what i'm trying to understand is if whether this is you that's hacked up a VLIW model + assembler based off of the base RISC-V ISA (which i don't think is necessarily a bad idea), or whether this is a condoned part of the ISA spec. |
|
@mortbopet Well legal is a tricky keyword in this case. All implementations of the I, C, M Extensions and instructions etc. are canonical to the RISC-V specs. However the statically scheduled nature of this VLIW processor is definitely not part of the standard and can be thought of as a specialization of it. So to answer your question. Yes that is a custom hacked specialization of the standard with a custom assembler to verify instruction packing integrity. PS: sorry for the late response and absence. Since last weeks/months i am working on an other exiting addition to Ripes, expect to hear from that soon. PSS: FYI, I am still looking forward to split up this pr into smaller junks (just as you requested), but have not found the time yet to do so. |
2 participants
VLIW Processor Implementation
This pull request introduces the Very Long Instruction Word (VLIW) dual-issue processor as outlined in discussion #414.
Summary of Changes
VLIW Processor Model
Assembler and Pseudo-instructions
MultiIssueAssemblerbase class for multi-issue processor assemblers.Code and Conceptual Refinements
Optionconcept insrc/isa/rvisainfo_common.hwithImplementationDetailfor clearer and more concise behavior specialization across ISAs.Testing and Examples
Bug Fixes
(see commit
c1686c1a31fce29d0bd5b648490821eea6467677).Notes
All modifications align with the existing code style and structure.
All tests pass successfully.