[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