ChanServ changed the topic of #nmigen to: nMigen hardware description language · code at · logs at
<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
Asu has quit [Quit: Konversation terminated!]