[libre-riscv-dev] [Bug 351] create a "block" (mass) regfile port (read and write) onto an array-based regfile

[bugzilla-daemon@libre-soc.org]

https://bugs.libre-soc.org/show_bug.cgi?id=351

--- Comment #3 from Cole Poirier <colepoirier@gmail.com> ---
(In reply to Luke Kenneth Casson Leighton from comment #1)

Unfortunately I had quite a lot of difficulty trying to follow your
instructions. I was unable to determine what you were referring to in several
instances, and grepping for some of the terms used turned up no results in the
codebase. I went ahead and pushed my commit as soc/regfile/virtual_port.py, its
my best attempt at interpreting your instructions, but its god ugly and I felt
bad about committing such a weak skeleton, but remembered your earlier guidance
to push so it's easier to get help. Hopefully with some clarifying questions
below I'll be able to better learn to speak the language of the project :)

> ok so first derive from RegFileArray.

As in regfiles.py "class IntRegs(RegFileArray):"?

> use the two parameters as follows:

By 'the two parameters', do you mean inherited from RegFileArray self.width and
self.depth? Otherwise do you mean take the below two parameters as new
parameters in the __init__ of VirtualPort, like "def __init__(self, bitwidth,
n_regs):'? Also do I have to "super().__init__(m, n)" before assigning python
lists to self.w_ports and same for rd?

> * bitwidth: the TOTAL number of bits
> * n_regs: the number of subdivisions of those bits.
> 
> therefore RegfileArray n_regs = nregs

I'm very confused by this, is n_regs internal to RegFileArray while nregs is
derived from n_regs for VirtualPort?

> 
> however RegfileArray regwidth is bitwidth DIVIDED by n_regs.

Where is regwidth used? I assume it's important but I am missing/have missed
something.

> then, in the constructor, add n_regs read ports and n_regs write ports to a
> pair of lists.
> 
> you can see this being done in soc.regfile.regfiles here
> 
> https://git.libre-soc.org/?p=soc.git;a=blob;f=src/soc/regfile/regfiles.py;
> h=d6f3a8dd79930d1286c72a42328363d9b9b8e9f3;hb=HEAD#l42
> 
> except, that should be a for loop
> 
> 
> next, we want an EXTRA read port and an extra write port.

Does this mean that I should keep them as separate variables outside of the
wr_ports and rd_ports lists as I have done in my first commit for this?

> this should, for data, instead of being only bitwidth/nregs wide, should
> instead be the FULL bitwidth wide. 
> 
> however the enable lines should be nregs wide.
> 
> 39         port = RecordObject([("ren", nregs),
>   40                              ("data_o", bitwidth)],
>   41                             name=name)
> 
> like that.
> 
> 
> then, in the elaborate:
> 
> * if any of the "extra" port ren bits are set, the data is sent through the
> corresponding *lower* indexed ports.

I was unable to determine how to route the data through the corresponding lower
indexed ports, I suspect it might have something to do with the below code from
regfile.py, but I was unable to make heads or tails of it either way:
```
144  for (regs, p) in self._rdports:
145     #print (p)
146     m.d.comb += self._get_en_sig(regs, 'ren').eq(p.ren)
147     ror = treereduce(list(regs))
148     m.d.comb += p.data_o.eq(ror)
```

Some explicit guidance here in particular would be really helpful, as I think
this might be the thing I have the least idea of how to go about implementing.
I assume that my function should match each bit to its corresponding 'enabled'
port but I'm only about 10% sure which variable or 'named parameter' I access
this through.

I apologize that I just don't understand a good portion of your instructions,
but I think that's because I'm learning how to understand and communicate in
the esoteric language of hardware, as well as the terminology that is specific
to our project. If it's something else, I'd sure like to know so I can work to
remedy it.

> you see how that works?

Hehe I think, as you can see, I don't, but I hope to through working through
this :)

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev