12:58 <lambda> how does migen convert nested python submodules to flat verilog identifiers? I can't really find a pattern for when it inserts the module name into the signal name and when it doesn't

13:02 <lambda> does it just try to use the signal names as-is, and prepend module names whenever there are collisions?

13:26 <lambda> are there any known issues with this renaming? I'm trying to figure out why there's a logic loop in the generated verilog, and it's quite hard to associate the signal names with their corresponding python code, sometimes it feels like multiple Signals got the same verilog signal name or something

13:46 <lambda> nevermind, looks like it was just a good old logic bug.

15:11 <smosanu> mithro (or anyone else) please feel free to reach out to me with any questions regarding the PiMulator paper/platform

16:52 <jevinskie[m]> The Cologne Chip rep got back to me and mentioned others are already evaluating them for use with LiteX :)

17:00 <trabucayre> jevinskie[m]: yep : me :)

17:01 <trabucayre> https://github.com/trabucayre/litex/tree/colognechip

17:01 <trabucayre> https://github.com/trabucayre/litex-boards/tree/gatemate_evb

17:01 <trabucayre> but it's requires a patch for yosys and without CPU :(

17:01 <trabucayre> I have to search why :)

22:18 <jevinskie[m]> So it looks like, to support existing modules in VPI, I have two options 1) add signal getter/setters (for Verilator: pointer derefs, for VPI: vpi_get_value/vpi_put_value 2) emulate the Vsim object by scanning out signals at the start of the timestep and writing the stub Vsim values out at the end

22:19 <jevinskie[m]> I'll go with 2 for now since it seems to be the simplest but it might have some performance overhead