<cr1901_modern1>
Would rather see HDMI2USB converted to nmigen, but I acknowledge that's not a trivial project
<cr1901_modern1>
nmigen syntax*
<whitequark>
it's definitely possible to make tooling assisting that
<whitequark>
it might not handle every case but most would be doable
<cr1901_modern1>
I have some thoughts on how to convert the platform abstraction layer in HDMI2USB, which duplicates code from MiSoC, into something ergonomic in nmigen, but I haven't worked through an example fully yet.
<cr1901_modern1>
If done correctly, you could _really_ get good platform abstraction with pretty minimal code duplication
<cr1901_modern1>
Yes these are redefinitions of omigen platforms
<cr1901_modern1>
The idea was that eventually most of this code would be removed and platform files in this folder would inherit from the omigen/litex platform files
<cr1901_modern1>
and annotate with the relevant class vars (spiflash_model, spiflash_read_dummy_bits, etc)
<cr1901_modern1>
depending on the platform's capabilities
<cr1901_modern1>
Because nmigen embeds the platform into elaborate(), there needs to be a way to tell an elaboratable what type of clock tree to create (maybe a mixin)?
<cr1901_modern1>
And that's how far I got into thinking about it
<cr1901_modern1>
The basic idea is "the constructor for your SoC has either a bunch of user-populated vars or mixins which describe how elaborate() should instantiate the platform I/O"
<whitequark>
hm yeah, i see some things i could do
<cr1901_modern1>
Idk what the current plans are w/ the SoC part of HDMI2USB... HeavyX seems to be very nix heavy. Is there a way to get HeavyX to output json or something so a separate build system can parse how to build it?
<cr1901_modern1>
(Assuming HeavyX is the MiSoC replacement)
<whitequark>
i think nix is a nonstarter as the sole $MISOC_REPLACEMENT build system because it still doesn't work properly on windows
<cr1901_modern1>
cc: mithro: If hypothetically HDMI2USB was rewritten to use solely nmigen, what would your plans be for a build system?
<sb0>
whitequark: i think there will be some codebase that will stay in migen, yes. people have limited resources especially considering the risk of some horrid heisenbug popping up in a nmigen rewrite
<whitequark>
sb0: i suspect the codebases that risk-averse will stay in migen completely
<whitequark>
since even with nmigen.compat you are mostly using nmigen past a tiny surface layer
<sb0>
yes, but then the any issue will only affect the nmigen project and not the original one
<whitequark>
sure, the 1st step is to always use nmigen.compat
<whitequark>
then once that works well, change the syntax
<sb0>
one way i'd like to use this compat mode is import existing migen cores (with many other migen projects depending on it) with minimal changes
<sb0>
rewriting all of those projects sounds like something that won't happen
<sb0>
for this use case (which I suspect will be a common one) the warnings are not useful
<whitequark>
disabling them is 1 line
<whitequark>
i think pushing people towards rewriting is useful
<whitequark>
but if i'm wrong we can always change that
cr1901_modern has joined #m-labs
cr1901_modern1 has quit [Ping timeout: 246 seconds]
futarisIRCcloud has joined #m-labs
proteusguy has joined #m-labs
sb0 has quit [Quit: Leaving]
<_whitenotifier-3>
[m-labs/nmigen] whitequark pushed 3 commits to master [+0/-0/±3] https://git.io/fj2qV
<_whitenotifier-3>
[m-labs/nmigen] whitequark f117465 - hdl.ast: tighten assertion in Switch().
<_whitenotifier-3>
[m-labs/nmigen] whitequark f689b77 - compat.fhdl.structure: always order default case as the very last.