[libre-riscv-dev] daily kan-ban update 17jul2020

[libre-riscv-dev] daily kan-ban update 17jul2020

[Jacob Lifshay]

today:
started adding fsm div
got a test where a whole bunch of the core fsm transition functions
are strung together combinatorially to work
(soc.fu.div.test.test_fsm.TestDivState.test_div_state_comb), so that
means that the soc.fu.div.fsm.DivState* classes all work.

However, when I try to wire them up in a simple synchronous fsm
(soc.fu.div.test.test_fsm.TestDivState.test_div_state_fsm), it doesn't
seem to work: I think the simulation process I made that checks
outputs is somehow getting desynchronized from the process that
toggles inputs -- I added some extra wires that the check process
toggles. it appears to me as though the check process is somehow
delayed an entire divide operation (8 or 9 cycles, since I'm testing
an 8-bit divider to make it easier).

Will try to fix that after tomorrow

Jacob

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] daily kan-ban update 17jul2020

[Luke Kenneth Casson Leighton]

On Saturday, July 18, 2020, Jacob Lifshay <programmerjake@gmail.com> wrote:

> today:
> started adding fsm div
> got a test where a whole bunch of the core fsm transition functions
> are strung together combinatorially to work
> (soc.fu.div.test.test_fsm.TestDivState.test_div_state_comb), so that
> means that the soc.fu.div.fsm.DivState* classes all work.


nice.


>
> However, when I try to wire them up in a simple synchronous fsm
> (soc.fu.div.test.test_fsm.TestDivState.test_div_state_fsm), it doesn't
> seem to work: I think the simulation process I made that checks
> outputs is somehow getting desynchronized from the process that
> toggles inputs -- I added some extra wires that the check process
> toggles.


ah.  we learned that even for synchronous signals it can be necessary to
use Settle().

this usually when a combinatorial block is generated *from* a synchronous
signal.


> it appears to me as though the check process is somehow
> delayed an entire divide operation (8 or 9 cycles, since I'm testing
> an 8-bit divider to make it easier).


ah that's a heck of a lot more :)


>
> Will try to fix that after tomorrow
>
> Jacob
>
> _______________________________________________
> libre-riscv-dev mailing list
> libre-riscv-dev@lists.libre-riscv.org
> http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev
>


-- 
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] daily kan-ban update 17jul2020

[Jacob Lifshay]

On Fri, Jul 17, 2020, 20:37 Luke Kenneth Casson Leighton <lkcl@lkcl.net>
wrote:

> On Saturday, July 18, 2020, Jacob Lifshay <programmerjake@gmail.com>
> wrote:
>
> > today:
> > started adding fsm div
> > got a test where a whole bunch of the core fsm transition functions
> > are strung together combinatorially to work
> > (soc.fu.div.test.test_fsm.TestDivState.test_div_state_comb), so that
> > means that the soc.fu.div.fsm.DivState* classes all work.
>
>
> nice.
>
>
> >
> > However, when I try to wire them up in a simple synchronous fsm
> > (soc.fu.div.test.test_fsm.TestDivState.test_div_state_fsm), it doesn't
> > seem to work: I think the simulation process I made that checks
> > outputs is somehow getting desynchronized from the process that
> > toggles inputs -- I added some extra wires that the check process
> > toggles.
>
>
> ah.  we learned that even for synchronous signals it can be necessary to
> use Settle().
>
> this usually when a combinatorial block is generated *from* a synchronous
> signal.
>

I'm specifically using Delay to delay a fraction of a clock cycle after
each Tick before measuring values, so Settle shouldn't be necessary.

Jacob
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] daily kan-ban update 17jul2020

[Luke Kenneth Casson Leighton]

On Sun, Jul 19, 2020 at 8:04 AM Jacob Lifshay <programmerjake@gmail.com> wrote:

> > > However, when I try to wire them up in a simple synchronous fsm
> > > (soc.fu.div.test.test_fsm.TestDivState.test_div_state_fsm), it doesn't
> > > seem to work: I think the simulation process I made that checks
> > > outputs is somehow getting desynchronized from the process that
> > > toggles inputs -- I added some extra wires that the check process
> > > toggles.

> I'm specifically using Delay to delay a fraction of a clock cycle after
> each Tick before measuring values, so Settle shouldn't be necessary.

hmm don't know what to suggest, then, other than saying "nuts to the
lot of it" and cookie-cutting microwatt divider.vhdl - into a new
subdirectory :)

l.

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev