[libre-riscv-dev] [Bug 313] Create Branch Pipeline for POWER9

bugzilla-daemon at libre-soc.org bugzilla-daemon at libre-soc.org
Fri May 22 14:10:31 BST 2020


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

--- Comment #33 from Michael Nolan <mtnolan2640 at gmail.com> ---
(In reply to Luke Kenneth Casson Leighton from comment #32)
> (In reply to Luke Kenneth Casson Leighton from comment #31)
> 
> > the idea is to use 3 bits of BI to look up CR00 to 7
> 
> (3 MSBs)
> 
> > then in OP_BC look up the remaining 2 bits of BI to select which bit of CRn
> > is to be used, right?
> 
> (2 LSBs)

Yep, that's the idea!

> 
> except, small issue: endian-ness looks like it will be an issue.
> 
> in main_stage.py the bit-order is reversed using [31-BI]
> 
>         # The bit of CR selected by BI
>         cr_bit = Signal(reset_less=True)
>         comb += cr_bit.eq((self.i.cr & (1<<(31-BI))) != 0)
> 
> if we are to reduce self.i.cr (BranchInputData.cr) to 4 bits,
> should that not be
>         comb += cr_bit.eq((self.i.cr & (1<<(3-BI))) != 0)
> 
> but also, back in power_decoder2.py, for DecodeCRIn, what about here?
> 
>             with m.Case(CRInSel.BI):
>                 comb += self.cr_bitfield.data.eq(self.dec.BI[2:5])
>                 comb += self.cr_bitfield.ok.eq(1)

I think the register file should be designed to address the 8 crs in the
correct bit order. If I ask for cr0, I should get cr0, whether cr0 comes from
the 4 lsbs of the full register, or the 4 msbs.

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


More information about the libre-riscv-dev mailing list