Raito_Bezarius has quit [Ping timeout: 255 seconds]
Raito_Bezarius has joined #nmigen
emeb_mac has quit [Quit: Leaving.]
electronic_eel has quit [Ping timeout: 252 seconds]
electronic_eel has joined #nmigen
hve has joined #nmigen
<hve>
Hi all
<whitequark>
hi!
<hve>
Hi wq! Just logging in and wondering how to help..
<hve>
Working with the colorlight board, using litex..
<hve>
And i like the versatillity of nmigen, can migen and nmigen mix?
<whitequark>
sort of
<whitequark>
the same way you can mix verilog and nmigen
<hve>
Wondering if I should port the platform to nmigen-boards
<hve>
Currently mixing verilog and migen/litex do not understand how to get gtkwave traces. Probably only in available in python only mode...
<hve>
So you see I am still learning... :)
<whitequark>
iirc there's a colorlight platform already
<hve>
Just wondering would it make sense to write a converter that converts litex_board platforms to nmigen_boards?
<whitequark>
ahh, there's an open PR
<whitequark>
probably not, the conventions are not the same
<agg>
there are a few different colorlite boards out there too, with totally different pinouts sadly
<agg>
though i think there are nmigen platforms around for many of the variants
<hve>
I would imagine a simple script could do the conversion for += 90% just by converting the structures to a nmigen format...
<whitequark>
litex boards do not specify IO directions, for example
<hve>
just a thought...
<whitequark>
I'm specifically against having boards being converted from migen/litex ones because there is a good reason the nmigen board format is designed in a different way
<whitequark>
migen boards are glorified constraint files
<hve>
looking at the PR, hmm if you like I will have a go with the latest comments to get this PR according to standards..
<whitequark>
that would be great!
<whitequark>
thank you
<hve>
Just looking ath the ulx3s.py board.. The directions of the pins could probably be overridden I would assume.
<hve>
Thing is the colorlight board needs some hardware modification (removal of output buffers) in order to have input support.
<agg>
you'd probably specify those pins in the 'connectors' part of the platform
<agg>
while the led, switch, rgmii, and ram would go in the resources
<agg>
in that case i also put the common led header signals (oe, clks, etc) as resources I guess
<agg>
hmm well I also put the LED connectors into resources where they were intended to be outputs, heh
<agg>
but if you want to let users change direction later because they've removed the level shifters, you can also specify each connector's pins in the connectors attribute, so users can put their own resources on them