ibex
ibex copied to clipboard
lowRISC
Evaluate the feasibility of parameterising ibex by XLEN
It could be interesting to support RV64I as well as RV32I (imagine small helper cores, with access to the same address space as a larger 64-bit application cores). Before leaping into doing this, someone needs to do the ground work to see how disruptive it might be, so we can evaluate the potential maintenance / readability costs vs the benefits of supporting an RV64I configuration.
Sir , i want to work on this . Do we need to add more intructions corresponding to rv64I or just extend the memory and no of instructions remains the same ??
It would require adding any RV64I instructions that RV32I doesn't have to produce a fully compliant RV64I implementation
Note that this has the potential to be a highly disruptive change and we may not wish to support it. If you are interested in working on this I'd suggest sharing your thoughts as to how it would be done early so we can discuss the best path forward and whether we wish to do it at all.
ohk , so i have not gone through the whole code of ibex , but what i build was normal 5 stage processor with some instructions , so what was there is that we have 32 bit registers , and memory was 32 bit and ISA was according to mips , so to extend that we have to create new ISA and registers and memory to 64 bit . Suppose for example we have opcode of 6 bits in 32 bit processor , now we will having suppose 10 bits . and then no of registers will also increase , so instead of 5 we will be having 6 bits for registers .
I think it will be same in ibex also , but need to go through all the code and how it started and ended .
I don't think that turning Ibex into a 5-stage pipeline is a very good idea: that would be a completely different processor and Ibex probably isn't the right starting point if you want to make that. Maybe you could explain what you're trying to achieve, and then we can discuss whether working on this issue is the right way to get there.
Also, it would probably be better to have that discussion in a slightly different place. That avoids massive expansion of the text in this issue for a question that may be only slightly related. Please either open a separate issue for the question or (possibly a better initial step) start a conversation on our Zulip channel. You can register for an account here, and we welcome anyone who wants to get involved.
