[libre-riscv-dev] [Bug 316] bperm TODO

[bugzilla-daemon at libre-soc.org]

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

--- Comment #7 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Cole Poirier from comment #6)

> I looked up 'clifford wolf bitmanip' and found this
> https://github.com/riscv/riscv-bitmanip/blob/master/verilog/rvb_bextdep/
> rvb_bextdep.v 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 referring to?

yes.

> > 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.

you're not.  if the code is unused by anyone (which in this case it is),
you cannot cause anyone else "damage" or "inconvenience"... therefore commit
it.  right now.

>  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?

tests directory of the working directory.  in this case, soc/src/logical/test
as "test_bperm.py" or something.


> Here is my attempt at the array code because I believe I can't yet commit it
> to the repo:

the very fact that you've cut/paste at least 3 variations into a *bugtracker*
should tell you everything that you need to know.

and that if your hard drive were to become corrupted, the only way for you to
recover the work would be.... to extract the code... *from these comments*.

that's s***, isn't it? :)

therefore, clearly, you must have misunderstood.

> ```
>  from nmigen import Elaboratable, Signal, Module, Repl, Cat, Const, Array
>  from nmigen.cli import main
>  
>  class Bpermd(Elaboratable):    
>      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))

no need to set perm to 0.  i said already.

>          index = Signal(8)
>          signals = [ Signal(1) for i in range(0,64) ]

just range(64).  no need to specify the default of 0

>          for i,n in enumerate(signals):
>              n.eq(self.rb[i])
>          rb8 = Array(signals)

call it rb64

>          for i in range(0, 7 + 1):

you _can_ do this as "8", which is 7+1 :)

>              index = self.rs[8 * i:8 * i + 7 + 1]

likewise here...

>              with m.If(index < 64):
>                  m.d.comb += self.perm[i].eq(rb8[index])
>              with m.Else():
>                  m.d.comb += self.perm[i].eq(0)

again, no need to set something to zero when, if it is not set, it will
default *to* zero.

this btw only holds true for *combinatorial* logic.  sync logic you *must*
do zero-setting (etc) where needed.

>          m.d.comb += self.ra[0:8].eq(self.perm)

looks good.

>          return m
>  
>  if __name__ == "__main__":
>      bperm = Bpermd(width=64)
>      main(bperm,ports=[bperm.perm, bperm.rs, bperm.ra, bperm.rb])
> ```

run python3 bperm.py generate -t il > bperm.il then use yosys to examine the
graph (read_ilang bperm.il; show top)

it will be fascinating to see.

-- 
You are receiving this mail because:
You are on the CC list for the bug.