Not a bug. nMigen's internal simulator, by design, cannot simulate platforms, since it does not know how to handle primitives like I/O buffers.

I can rewrite the front end to use the simulation clock. rather than one bound to a platform clock.

That said it would be cool to be able to simulate a "platform" board system without modification.

Thanks

That said it would be cool to be able to simulate a "platform" board system without modification.

It's not possible. nMigen's built-in simulator doesn't support tristates or dual-edge flip-flops, so you could at best support only the absolute basic designs with no bidirectional or DDR I/O.

DDR flip-flops shouldn't be that hard to add, just trigger on both edges instead of one (assuming falling edge flip-flops are supported). tri-state would be harder

They're quite deliberately not supported. Among other things the Python simulator is already very slow.

I have played around and managed to get simulations and gateware running, however there is a weird duplication.

Would to be possible to change this.

        m = Module()
        m.domains.sync = ClockDomain()
        m.d.comb += ClockSignal().eq(clk16.i)

into a bound clock so the simulator will run it?

I don't want nor need the tristates or DDR interfaces running . I would like a waveform in gtkwave.

I would rather not have it possible to simulate platform code at all than be able to simulate only the most basic case. So no. If you don't want nor need tristates and such, then simulate without any platform code at all.

Pretty much everyone learning nMigen wants to use platform code with the simulator, so there needs to be some solution. I don't know how it should look like though.

A long while ago, @sbourdeauducq and @enjoy-digital proposed a solution for misoc that uses ffi hooks to simulate basic hardware like, say, UART using IPC (using pttys on *nix, but this won't work on Windoze).

Of course, a basic-to-comprehensive SPI flash is quite simulate-able using nmigen alone for said emulation layer. Just needs to be written :D. Alternatively, it could still be written partially calling to an FFI to avoid needing to simulate accessing memory array.

Those two alone will get you a decent chunk of use cases I imagine.

That's kinda different, and I've already discussed it (privately); the problem here is specifically simulating an existing platform, not providing simulated devices to a special, separate platform.

If it was meant to be a special, separate platform, I've since forgotten.

The way I started coding my (failed!) PoC was that the platform needed to register w/ the ffi what peripherals it supported to the omigen simulator. Then the simulator would intercept accesses (using a queue for async inputs from the user) that relied on input/output on supported peripheral pins and redirect to the ffi.

This way, the simulated peripherals and platforms remained decoupled.

For "full platform simulation" something like Verilator is a good solution. By "full platform" I mean simulating things like the UART, Video Display, SPI flash -- all the stuff not actually inside the FPGA itself. People have already written good emulation of these parts and we should just reuse them. Trying to simulate theses in nmigen's simulator gets way too slow very quickly.... Verilator does introduce complexity around needed a C++ compiler and similar issues, so I would not say this is for "simple" solutions were you just want some VCD or one or two LED type things.

For "partial platform simulation" -- IE just emulating one of the LEDs, switches, UART or SPI flash for debugging your nmigen core is a different situation and probably makes sense to try and keep it all internal.

The problem that I hit was that the platform clock would not run inside the simulator. By wrapping or replacing this clock with a sim clock would satisfy my requirements for platform simulation.

I just want a .vcd so I can see what's going on inside.

cxxrtl fixes this