<_whitenotifier-3>
[nmigen-boards] whitequark edited a comment on issue #58: Add release - https://git.io/JvHhe
<Vinalon>
If I get a YosysError saying, "Parser error in line N", where does it get the line number 'N' from?
<Vinalon>
I tried printing the 'script' value from back/verilog.py, but the line number in that file looks pretty innocuous, and very similar to surrounding lines
<Vinalon>
and what might cause an 'invalid slice' error? The only reference I could find to it was in the YoSys 'ilang_parser.y' file where it gets printed
<Vinalon>
It must be related to these 'extra' bits assigned based on 'b_signed' in the shift operations, right? If I set that to '0', the error disappears:
<_whitenotifier-3>
[nmigen] whitequark edited issue #341: nMigen should avoid emitting very large wires that cause issues in Yosys - https://git.io/JvHje
<_whitenotifier-3>
[nmigen] whitequark reopened issue #341: nMigen should avoid emitting very large wires that cause issues in Yosys - https://git.io/JvHje
<_whitenotifier-3>
[nmigen] whitequark commented on issue #341: nMigen should avoid emitting very large wires that cause issues in Yosys - https://git.io/JvQnl
_franck_ has joined #nmigen
kc5tja has joined #nmigen
proteus-dude has joined #nmigen
proteus-guy has quit [Ping timeout: 260 seconds]
<_whitenotifier-3>
[nmigen] WRansohoff commented on issue #341: nMigen should avoid emitting very large wires that cause issues in Yosys - https://git.io/JvQCq
<_whitenotifier-3>
[nmigen] WRansohoff edited a comment on issue #341: nMigen should avoid emitting very large wires that cause issues in Yosys - https://git.io/JvQCq
<_whitenotifier-3>
[nmigen] whitequark commented on issue #341: nMigen should avoid emitting very large wires that cause issues in Yosys - https://git.io/JvQC4
<_whitenotifier-3>
[nmigen] ZirconiumX commented on issue #341: nMigen should avoid emitting very large wires that cause issues in Yosys - https://git.io/JvQC2
<_whitenotifier-3>
[nmigen] whitequark commented on issue #341: nMigen should avoid emitting very large wires that cause issues in Yosys - https://git.io/JvQCX
<_whitenotifier-3>
[nmigen] ZirconiumX commented on issue #341: nMigen should avoid emitting very large wires that cause issues in Yosys - https://git.io/JvQWU
<_whitenotifier-3>
[nmigen] WRansohoff commented on issue #341: nMigen should avoid emitting very large wires that cause issues in Yosys - https://git.io/JvQ8f
<_whitenotifier-3>
[nmigen] whitequark commented on issue #341: nMigen should avoid emitting very large wires that cause issues in Yosys - https://git.io/JvQ81
<kc5tja>
whitequark: Regarding the PLL code you linked to me yesterday, I see Glasgow is Apache licensed. My project is MPL V2 licensed. Considering the licensing differences, may I have permission to use the relevant PLL code verbatim in my project, with attribution?
<whitequark>
kc5tja: you have my permission to use the PLL code for any purpose forever
<whitequark>
with or without attribution
<whitequark>
also, Glasgow is dual licensed under 0BSD and Apache2
<whitequark>
0BSD is the most boneless license there is, it's pretty much CC0 but works in Germany
<whitequark>
Apache2 is there just for the patent grant
<Sarayan>
wq: FYI, I've reimplemented the wd1772 pll in nmigen. Not tested enough to be sure it works, but it's there
<Sarayan>
I don't pretednt to understand it yet :-)
<Sarayan>
pretend
<kc5tja>
Awesome, thank you!
<kc5tja>
I think the last piece of the puzzle for me is how to instantiate a submodule inside of another clock domain.
<kc5tja>
Anyone have ideas on how to accomplish this task?
<Sarayan>
I suspect the first answer is "are you *sure* you need another clock domain?"
<whitequark>
kc5tja: DomainsRenamer does what you want
<kc5tja>
Took a bit of massaging to get things to work, but it all builds without errors or warnings now. I'm chomping at the bit to test this in real hardware now.
<kc5tja>
Thanks again! Going to head out for lunch, then get back to the workbench and start some soldering.
<whitequark>
good luck!
rohitksingh has joined #nmigen
kc5tja has quit [Ping timeout: 256 seconds]
kc5tja has joined #nmigen
<kc5tja>
No luck. :(
<kc5tja>
I am seeing some pretty wild shit on the data bus when the FPGA is in-circuit.
<kc5tja>
I'm wondering if my level shifters are up to the task. :(
<kc5tja>
I know this is completely off-topic, but does anyone here have experience using TXS0108E level shifters in a circuit? What problems have you run into using them?
<ZirconiumX>
WQ and possibly marcan are probably good people to talk to about level shifters due to Glasgow
<kc5tja>
Hopefully they'll see my query.
<ZirconiumX>
Maybe ask in #glasgow (which is bigger anyway) and perhaps marcan would see it.
<ZirconiumX>
Full disclosure: I don't know where the "correct" place to ask would be
<ZirconiumX>
But #glasgow would be a start
<daveshah>
The most common with those auto level shifters is when one side has a pull up or down
<daveshah>
*most common problem
<daveshah>
Although I may be thinking of the TXB here which is what I have had problems with before, I don't know if the TXS is more robust
Asuu has joined #nmigen
Asu has quit [Ping timeout: 264 seconds]
Vinalon has quit [Remote host closed the connection]
Vinalon has joined #nmigen
<kc5tja>
Not sure. I think I'm going to place an order for 74LVC8T245 transceivers/converters and see how those work. Uugh, I was hoping to not have to need an explicit direction pin. :(