<lkcl>
for a reconfigureable ASIC (GPIO pinmux, like many TI OMAP processors, or STM32F or ATSAM3/4) yes absolutely virtually every single GPIO will be tristate i/o/oe, with a pinmux behind it
<whitequark>
i'm talking about FPGAs only here fwiw
<lkcl>
however for "direct" driving (non-muxed) IO... ah yeah absolutely, FPGAs they're similar category to pinmux'd ASICs.
feldim2425 has quit [Ping timeout: 272 seconds]
feldim2425 has joined #nmigen
Degi has quit [Ping timeout: 260 seconds]
Degi has joined #nmigen
electronic_eel has joined #nmigen
electronic_eel has quit [Ping timeout: 260 seconds]
PyroPeter_ has joined #nmigen
PyroPeter has quit [Ping timeout: 240 seconds]
PyroPeter_ is now known as PyroPeter
chipmuenk has joined #nmigen
chipmuenk has quit [Quit: chipmuenk]
_whitelogger has joined #nmigen
hitomi2509 has joined #nmigen
chipmuenk has joined #nmigen
chipmuenk has quit [Quit: chipmuenk]
emeb_mac has quit [Quit: Leaving.]
chipmuenk1 has joined #nmigen
chipmuenk1 is now known as chipmuenk
jeanthom has joined #nmigen
chipmuenk has quit [Quit: chipmuenk]
chipmuenk1 has joined #nmigen
Ceda has joined #nmigen
Ceda has quit [Remote host closed the connection]
jeanthom has quit [Ping timeout: 272 seconds]
cr1901_modern has quit [Ping timeout: 240 seconds]
<key2>
@ktemkin is USB3 full or half duplex ?
<whitequark>
full duplex
<whitequark>
well, the physical layer is
<key2>
yes but can both side communicate at the same time
<key2>
or is it still like the usb2
<key2>
either you send or receive
<key2>
I know it doesnt share the same diff pairs, but that doesnt mean it doesnt communicate full duplex
<lkcl>
ktemkin: that's absolutely fantastic news about the nmigen+FPGAs workshop. very cool.
vup has quit [Quit: No Ping reply in 180 seconds.]
cr1901_modern has quit [Ping timeout: 256 seconds]
jeanthom has quit [Ping timeout: 260 seconds]
<cr1901_modern1>
What does Passive() mean in simulation again?
<cesar[m]>
It means that the simulation can end, even if the passive process has not finished yet.
<cr1901_modern1>
excellent, thanks
<cesar[m]>
For instance, an endless loop in a passive process will not cause the simulation to hang.
<alanvgreen>
I'm considering using nmigen to build IP for a litex soc
<alanvgreen>
The obvious way is to output verilog from nmigen then including that in the soc build
<alanvgreen>
Is there a better way?
<Lofty>
alanvgreen: litex uses migen; you can get migen back-compat through nmigen.compat
<Lofty>
So if you replace all instances of migen imports with nmigen.compat imports, you can use litex as if it was nmigen
<alanvgreen>
I'm not quite sure what that would look like in practice.
<alanvgreen>
It sounds like you're suggesting porting litex to nmigen?
_florent_ has quit [Ping timeout: 272 seconds]
_florent_ has joined #nmigen
<Lofty>
alanvgreen: `sed -i "s/import migen/import nmigen.compat/"` is what it looks like in practice
<Lofty>
(inside litex)
<lkcl>
alanvgreen: i do export to verilog then re-import that verilog back into itex. 1 sec i will find you the links, i got some help from florent of enjoy-digital to do it...
<Lofty>
_florent_ is here btw
<lkcl>
here's how to output to verilog from nmigen, the important line is line 58:
<lkcl>
and this is how you "re-import' that verilog file *back* into litex, and "connect" the "foreign" (verilog) file to signals in a litex CPU class:
<lkcl>
it's done with a dictionary that has the keys be the names of the foreign (verilog-exported numben) interface, and the values are the litex (migen) Signals
<lkcl>
if the key starts with "i_" then that means that the (verilog-exported) nmigen port Signal is an input, and, obviously, "o_" is for output
<lkcl>
here's a simpler-looking one which does the exact same thing, after microwatt VHDL was converted to verilog:
<mithro>
I think I linked some cool text rendering of waveforms in this channel a while back -- but now I can't find them... Anyone know what it was...