[libre-riscv-dev] Rust over C/C++

[Luke Kenneth Casson Leighton]

On Sunday, January 5, 2020, Jacob Lifshay <programmerjake at gmail.com> wrote:

> Somehow duplicate emails got sent.
>
> On Sun, Jan 5, 2020 at 6:18 AM Immanuel, Yehowshua U
> <yimmanuel3 at gatech.edu> wrote:
> >
> > I’m am quite happy to hear that you guys use nMigen. This is quite
> excellent!
> > Just a few question about how you guys write nMIgen test benches(because
> I am writing the verilator backend which is about 75% finished).
> >
> > The following is from a convo with whitequark:
> >
> > > The statement:
> >
> > >  yield dut.c.eq(dut.a * dut.b)
> >
> > > is evaluated as-if you made a module with just those three values,
> like this:
> >
> > > m = Module()
> > > m.d.comb += dut.c.eq(dut.a * dut.b)
> >
> > > assuming dut.c isn't driven elsewhere.
> >
> > Do you guys ever use Signal expressions inside test bench assignments?
> > If not, then I’m thinking about leaving that unsupported with the
> verilator backend because adding support
> > opens up a whole other can of worms.
>
> I have not seen anything more complex than assigning python integers
> to signals in our code (I wasn't even aware nmigen supported that).
>
> I think leaving it unsupported is perfectly fine.
>
> Will be happy to use a much faster backend than nmigen's built-in
> simulator (though the simulator has slightly different semantics than
> verilog and may help catch errors in the nmigen source), even though
> whitequark has been putting a lot of effort into making nmigen go
> faster.


we will need to integrate with cocotb at some point.

there is peripheral code written in verilog that we aren't going to
duplicate and the only way to test it in conjunction with the core would be
compiling to verilog.

btw Yehowshua do check cocotb it has provided python cosimulation via
verilator compilation for several years.

l.



-- 
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68