samsoniuk
commented
2 years ago oh, good point! it is a long history... the RISCV logical specification need handle 3 different registers at the same time: s1, s2 and d, in a way that the general construction for a sum is:
reg[d] = reg[s1]+reg[s2]
which means that the register set must be physically a triple-port memory. however, from the physical point of view, the register set is constructed with LUTRAM, which can handle only two access at the same time and the tool will do a "hidden" expansion in order to infer a triple-port memory, which means use a register set replica that uses 2x more LUTRAMs.
well, one solution to avoid the "hidden" expansion is read each operand in a separate clock:
tmp = reg[s1] reg[d] = tmp+reg[s2]
but it introduces a problem in the pipeline case the s1 and d are the same, the operation needs to be interlocked with the previous operation, which reduces the performance.
another solution is replicate the set:
reg1[d] = reg1[s1]+reg2[s2] reg2[d] = reg1[s1]+reg2[s2]
which ensures that the reg1 and reg2 are the same, but the reg1 and reg2 are both dual-port LUTRAMs with no "hidden" expansions which 1 register set appears physically as 2 registers set.
well, at this point there is not really much problem, since most tools infer this automatically. the problem is that sometimes I found a 3rd hidden replica!
lets say you have the following logic:
reg[d] = op ? reg[s1]+reg[s2] : reg[d]
which means add the s1+s2 registers when op is set, but do nothing when there is no op... but is this a triple-port memory or a quad-port memory? because we have one write in register d and three reads (registers s1, s2 and d). depending how the logic is constructed, the tool may infer a 3rd hidden replica:
reg1[d] = op ? reg1[s1]+reg2[s2] : reg3[d] reg2[d] = op ? reg1[s1]+reg2[s2] : reg3[d] (hidden expansion) reg3[d] = op ? reg1[s1]+reg2[s2] : reg3[d] (hidden expansion)
by changing the code to:
reg1[d] = op ? reg1[s1]+reg2[s2] : reg1[d] reg2[d] = op ? reg1[s1]+reg2[s2] : reg2[d]
the tool avoided the 3rd replica.
well, I think is possible eliminate the register replica in order to make the code smaller and clearer, but it depends of some additional tests with different tools, in order to ensure that there is no extra "hidden" logic and the timing is not affected.
I guess the problem started with the spartan-3 build and, after the register set replica was introduced, I made additional changes in the logic that may help the tool avoid the 3rd hidden replica.
so, I will check how the tool is handling the current code and maybe we can cut some useless lines of code here! :)
vgegok
Why are two general-purpose register groups designed in darkriscv.v,
Not like one of the riscv specifications,
Is it to support multi-core?
I tried to use a general-purpose register set and it still works.