<awygle>
hm, what's the best way to troubleshoot signals not being named in simulator vcd outputs? i have a few signals that are just being named "$signal$#"
<ktemkin>
I assume you just have a few signals that are declared in Complex Enough Ways that they're not being automatically named by nMigen; in which case, it's probably easiest just to look for signals that are likely your missing ones and then set the name argument in their constructors [e.g. Signal(name="hi")]
<adamgreig>
i find it often happens when i'm making signals in a context that they can't infer a name, e.g. in a list comprehension x = [Signal(8) for _ in range(5)] or whatever, I've usually found out by checking the generated RTLIL to work out what it was and then add names manually
<adamgreig>
yes, what ktemkin said
<awygle>
ah, interesting
<awygle>
yes, that seems quite likely
<ktemkin>
and yep, checking the RTLIL or back-generating Verilog seems like the best way to figure out which ones they are, if you don't have good guesses
<adamgreig>
i found i ended up sort of knowing when they wouldn't get named and adding names manually a priori, but that's not a very helpful answer :P
<adamgreig>
the other time this happens is submodules
<adamgreig>
for idx, ctr in enumerate(counters): m.submodules[f"counter{idx}"] = ctr
<adamgreig>
otherwise the submodules are named like U$0 which helps no-one
<awygle>
... i hate python. lol
<awygle>
i added a "name" argument, then used it below a loop that used "name" as the loop variable name
<awygle>
this, predictably, did not work
<awygle>
thanks you two
<awygle>
is the uart on the ecp5 versa ttyUSB0 or ttyUSB1...
<ktemkin>
IIRC, it'll be the second interface, and thus ttyUSB1
<ktemkin>
IIRC, by default, BDBUS[0]/BDBUS[1] are tied to the second UART; so yes, ttyUSB1
<awygle>
cool, thank you
<awygle>
what is "C"? as in "Cat(C(0, 1), self.tx_data, C(1, 1))"?
<awygle>
oh, "Const", ok
_whitelogger has joined #nmigen
<awygle>
argh. there's definitely uart data coming out of the FPGA, i can see it on my scope and my scope correctly decodes it at the intended baud rate, but it doesn't show up in my serial port.
<awygle>
oh ffs the FTDI chip isn't (wasn't) configured for that channel to be a UART.
<awygle>
thanks a million lattice
_whitelogger has joined #nmigen
<awygle>
whitequark: ping
Asu has joined #nmigen
electronic_eel has quit [Ping timeout: 260 seconds]
electronic_eel has joined #nmigen
electronic_eel has quit [Ping timeout: 255 seconds]
electronic_eel has joined #nmigen
proteus-guy has joined #nmigen
<ktemkin>
awygle: is your board one that’s never been configured by Diamond? I suspect the FTDI configuration EEPROM is only burned once Diamond sees the board for the first time
cr1901_modern has quit [Quit: Leaving.]
cr1901_modern has joined #nmigen
XgF has joined #nmigen
XgF has quit [Client Quit]
XgF has joined #nmigen
<awygle>
ktemkin: could be. it does say Lattice Versa Board in the descriptor, but that might be generic somehow, or it gets updated by diamond