[libre-riscv-dev] [Bug 316] bperm TODO
bugzilla-daemon at libre-soc.org
bugzilla-daemon at libre-soc.org
Sat May 16 01:24:56 BST 2020
--- Comment #6 from Cole Poirier <colepoirier at gmail.com> ---
(In reply to Luke Kenneth Casson Leighton from comment #4)
> (In reply to Cole Poirier from comment #1)
> good for you! throw it into... mmm... let's see...
Thank you so much Luke, am positively giddy at having written my first bit of
(In reply to Luke Kenneth Casson Leighton from comment #5)
> (In reply to Cole Poirier from comment #3)
> err... err.... ah :) rrrright, you need to use nmigen.Array.
> * create a list of 64 signals, each 1-bit wide, for-loop, append them each
> to the
> * assign 1 bit of rb into each of those 64 (signal_1_bit.eq(rb[i])
> * create the array: rb8 = Array(my_list_of_64_signals)
> *then* you can index them.
> however... be aware that this is an absolutely truly dreadful way to do it :)
> it will at least be functional and we can work on an improved design in a
> second iteration.
> basically it is absolutely awful because we are creating a *SIXTY FOUR* way
> crossbar... actually 8 such 64-way crossbars!
> this is pretty massive.
> however... before completely freaking out, it is worthwhile seeing what
> yosys actually generates (synth command). it *might* actually generate
> an efficient design. we have to see.
> if it really doesn't, then we can look around for alternatives. there might
> be something in clifford wolf's excellent bitmanip code.
I looked up 'clifford wolf bitmanip' and found this
which seems to implement the rvb equivalent of bperm, shfl (and unshfl). Wolf,
who I believe from the copyright on this file now goes by Claire, wrote the
riscv bitmanip extention proposal, which is also available in the linked repo
in pre-built or self-built pdf form. Is this the bitmanip code you are
> but - go through with this as it is, then write a unit test. you will then
> have "something to test an alternative design against", later.
I believe I have implemented the fixes you have suggested, but I'm really
struggling with how to write an appropriate unit test, which prevents me from
committing my code to your suggested location in the soc repo, if I'm recalling
the HDL_Workflow development rules correctly. Can you point me to a resource or
explain the basic principles or rules of writing hardware unit tests? I'm
feeling at a total loss of where to start here. Additionally, pardon my
ignorance, but are the unit tests supposed to be written inline or put in the
tests directory of the working directory? (It wasn't obvious to me after
examining the alu and experiment directories)
Here is my attempt at the array code because I believe I can't yet commit it to
from nmigen import Elaboratable, Signal, Module, Repl, Cat, Const, Array
from nmigen.cli import main
def __init__(self, width):
self.perm = Signal(width)
self.rs = Signal(width)
self.ra = Signal(width)
self.rb = Signal(width)
def elaborate(self, platform):
m = Module()
m.d.comb += self.perm.eq(Const(0,8))
index = Signal(8)
signals = [ Signal(1) for i in range(0,64) ]
for i,n in enumerate(signals):
rb8 = Array(signals)
for i in range(0, 7 + 1):
index = self.rs[8 * i:8 * i + 7 + 1]
with m.If(index < 64):
m.d.comb += self.perm[i].eq(rb8[index])
m.d.comb += self.perm[i].eq(0)
m.d.comb += self.ra[0:8].eq(self.perm)
if __name__ == "__main__":
bperm = Bpermd(width=64)
main(bperm,ports=[bperm.perm, bperm.rs, bperm.ra, bperm.rb])
You are receiving this mail because:
You are on the CC list for the bug.
More information about the libre-riscv-dev