It is the easy part. Four weeks is plenty of time.
That's why it's so bizarre that the RISC-V design is so awful.
The hard part is the software support side (though, as comments elsewhere in the thread point out, AI is pretty helpful there) and then those lovely pieces like specifying the precise behavior of interrupts.
If it had a snowball's chance in hell of going in to any kind of production anywhere, I'd have no problem spending the next month laying out an ISA. But, again, as this thread makes very, very clear: ISA really just doesn't matter.
It looks an awful lot like something that was designed by a sizeable committee made up mostly of academics, most of whom won't have written ten lines of code in as many years. I don't actually know in this case, but I've had to sit and watch standards created in this manner, and Dmitry's description of the RISC-V mess matches their output fairly closely, a chaotic mess that includes every idea everyone on the standards committee has ever had, all made optional so no-one will vote against it when it comes to balloting.
> That's why it's so bizarre that the RISC-V design is so awful.
Not bizarre.
The design is a direct result of the biases of its initial designers, and its original intended use-case. And TBH, if you assess it by its original design criteria, it's actually pretty good.
It's just by the time RISC-V had escaped containment and was starting to become a general purpose open ISA, it was a little too late to start from the beginning and consider what the correct design criteria should even be.