Is there some naming convention to the signals in DarkRiscV?

[MrJake222]

Some examples:

• *2 like HLT2 -- clocked version of HLT?
• X* like XRES -- also clocked version of a signal?
• *X like IDATAX -- gated version of IDATA or IDATA2?
• XI* like XIDATA -- IDATAX clocked again or halted?

Are these prefixes and suffixes meaningful. Or are they just a beautiful one-nighter spaghetti code results?

[samsoniuk]

well, the initial plan was use names based on traditional processor names, like 68000 and 8086... in some cases, DATA and ADDR instead of D and A, in order to be more friendly but names like HLT, CLK, RD, WR were very traditional and automatically makes sense for everyone.

of course, across the time the plan started to show the problems: the inout DATA from traditional processors must be split on input only and output only, so DATA/DATO pair appeared... and later, when the bus was split on instruction/data, IDATA/IADDR would makes sense but DDATA/DDATO/DADDR were not so good... RD/WR would change to DRD/DWR and later I switched again from the intel-like signals to motorola like signals (DLEN, DRW), just to realize that makes sense keep both.

in some parts, HLT2 and IDATA2 are just like HLT and IDATA delayed by 1 clock, so XIDATA and lots of X* were a planned delay of IDATA and related signals, but IDATA2 was added later and does not match any pattern (although matches the pattern of 1 clock delayed signals everywhere).

the darkbridge added even more complexity: lots of similar buses! and at this moment it would make sense start use some kind of prefix, like AXI_* but I just used X*, Y* and XX*...

so, basically there is no name convention because there is no plan, we just open the code and cry! :)

[samsoniuk]

of course, suggestions are welcome!

[MrJake222]

Hi, thank you for an somewhat helpful reply. At least now I don't try to understand.

However (sorry for nagging you) I'd some clarification for this commented out code:

NXPC <= /*XRES ? `__RESETPC__ :*/ HLT ? NXPC : NXPC2;
PC   <= /*XRES ? `__RESETPC__ :*/ HLT ? PC : NXPC;

Why reset signal is not used here? Is it because of a bug or just unnecesary as NXPC/NXPC2 already handle that? If so, why not remove it?

Second case:
Here, why OPCODE is not used anymore? There was a bug or...? Not wanting to duplicate the decoder from above? Handling both 2/3-stage versions?

[samsoniuk]

no problem about it, all questions are welcome! :)

about some commented resets: I was trying improve the timing by removing unused logic, so in the case of PC, when you build it with 3 stages, the real PC will be the NXPC2 (very bad name, it is in fact the PC generated at the instruction fetch), so the NXPC2 will propagate to NXPC (in fact the PC generated at the instruction decode) and them propagated to PC (that is the PC that the execute unity see and that people typically like to see at debug time). so, as far HLT is not asserted, the will just propagate the NXPC2 to NXPC and NXPC to PC. of course, on original version, with 2 stages, we had only NXPC and PC, which is supposed to work the same way.

in the case of OPCODE, it was used back in the 2 stage era, so the instruction fetch and decode were compressed in a single cycle. with the introduction of the 3 stage pipeline, we have a more elaborated decode for 2 and 3 stage versions, so OPCODE was not used anymore... although I keep it for debug purposes. since I cannot keep working on it full time, there will be lots and lots of dead code left across the time... and it is really very interesting that, after some few years, even such small code already have some strata forming and even some fossils! :)