[libre-riscv-dev] buffered pipeline

[Jacob Lifshay]

I got the simple pipeline stage to work correctly. Here's the unit test:
https://salsa.debian.org/Kazan-team/simple-barrel-processor/blob/master/test/test_pipeline.py

On Thu, Mar 14, 2019 at 2:29 AM Luke Kenneth Casson Leighton <lkcl at lkcl.net>
wrote:

> On Thu, Mar 14, 2019 at 8:40 AM Jacob Lifshay <programmerjake at gmail.com>
> wrote:
>
> > I'm using the nmigen.back.pysim.Simulator class, which is apparently the
> > recommended solution for simulation. It supports executing multiple
> > generators simultaneously, you just have to watch out for checking values
> > immediately after a clock edge, it needs a slight delay before it
> > calculates the combinatorial values.
> >
> > It's used like:
> >
> > m = MyModule()
> > with Simulator(test_stage, vcd_file=open("test.vcd", "w"),
> > gtkw_file=open("test.gtkw", "w"), traces=[m.sig1, m.sig2]) as sim:
> >     clock_period = 1e-6
> >     sim.add_clock(clock_period)
> >     def process() -> Generator[Any, Any, None]:
> >         yield m.sig1.eq(1) # set m.sig1
> >         yield #wait for clock edge
> >         yield Delay(1e-7) # delay 100ns
> >         sig2_value = yield m.sig2 # read sig2 as an int
> >         print(sig2_value)
> >         yield # clock some more
> >     sim.add_sync_process(process)
> >     sim.run()
> >
> >
> ah interesting, you're using the Simulation class directly rather than the
> run_simulation function which is the usual way.
>
> actually... looking at compat/sim/__init__.py, it *is* basically exactly
> the code above!  sim.add_clock is called, sim.add_sync_process is called,
> sim.run is called:
> https://github.com/m-labs/nmigen/blob/master/nmigen/compat/sim/__init__.py
>
> run_simulation however takes an array (or dictionary) of functions
> [generators], and adds all of them.
>
> mostly, people leave the clock and so on alone, trusting that the defaults
> will be sufficient.
>
> yes, you can't grab even combinatorial logic created-and-outputted on the
> exact same clock cycle as its inputs change, there has to be some
> propagation delay.  the usual design/behaviour is to store the
> combinatorial block in a sync (clocked) signal.
>
> it would be *extremely* bad to write HDL/code that relies on anything other
> than that pattern.  to rely on specific gate propagation delays would be a
> nightmare to synthesise (even if it was possible) or even put into an FPGA.
>
> l.
> _______________________________________________
> libre-riscv-dev mailing list
> libre-riscv-dev at lists.libre-riscv.org
> http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev
>