ChanServ changed the topic of #nmigen to: nMigen hardware description language · code at · logs at
TD-Linux has joined #nmigen
_whitelogger has joined #nmigen
ZirconiumX has quit [Ping timeout: 272 seconds]
ZirconiumX has joined #nmigen
_whitelogger has joined #nmigen
_whitelogger has joined #nmigen
ronyrus has joined #nmigen
_whitelogger has joined #nmigen
_whitelogger has joined #nmigen
proteus-guy has joined #nmigen
ronyrus has quit [Remote host closed the connection]
proteus-dude has joined #nmigen
_whitelogger has joined #nmigen
_whitelogger has joined #nmigen
<ktemkin> hmm -- it might be nice to have a clean idiom for passing around clock attributes (like the frequency of a domain's clock signal); that'd allow for nice, clean declarations like `u = UARTReceiver(baud=115200)`
<ktemkin> though I imagine that'd be tricky to implement without also creating a confusing mechanic, given the way clock domains are created
Asu has joined #nmigen
ronyrus has joined #nmigen
ronyrus has quit [Remote host closed the connection]
Asu has quit [Remote host closed the connection]
Asu has joined #nmigen
<awygle> ugh still can't get diamond backend to work
<awygle> probably shoulda just set up a red hat/fedora VM
<emily> what are you trying to run it on?
<cr1901_modern> This worked for me for Ubuntu. If you are on windoze, you will need to set up a script to add diamond to your path
<cr1901_modern> because lattice conveniently doesn't provide one for you on Windoze
<awygle> ubuntu
<awygle> i got it _installed_
<awygle> but all the paths are wrong
<awygle> for dynamic libraries
<awygle> so i fixed that, and now it's failing to read the "execute" shell script properly
<awygle> ubuntu 18.04 specifically
<cr1901_modern> execute shell script?
<cr1901_modern> I've only ever run nmigen w/ Diamond on Windows
<awygle> /usr/local/diamond/3.11-x64/pnbase/bin/execute or something liket hat
<cr1901_modern> There's no pnbase directory on 3.10 on my machine
<awygle> sorry, "synpbase"
<cr1901_modern> No execute under /usr/local/diamond/3.10_x64/synpbase/bin/ on my machine
<cr1901_modern> awygle: Try this
<awygle> it's probably a change in 3.11 then, maybe i should try 3.10
<cr1901_modern> set bindir env variable to /usr/local/diamond/3.11_x64/bin/lin64
<cr1901_modern> source /usr/local/diamond/3.11_x64/bin/lin64/diamond_env
<cr1901_modern> err export* bindir
<cr1901_modern> This is what I had to do to get pnmainc working
<awygle> yosys is picking up the wrong libc++ now i think
<cr1901_modern> Okay, that's a problem then :/
<cr1901_modern> These are my notes for dealing w/ diamond paths. I was trying to add autodetection to omigen, but eventually they dropped all the autodetection stuff:
<cr1901_modern> diamond_env sets LD_LIBRARY_PATH, and yosys will need to run to convert the RTLIL to Verilog
<cr1901_modern> Prob worth opening an issue for this
<cr1901_modern> awygle: Could you generate the build inputs but not run diamond, and then paste the shell script for me?
<awygle> i can try, gimme a sec
<cr1901_modern> awygle: Actually I found the lines I want
<cr1901_modern> I guess my question is: why is yosys choking due to libc++ on your system, but not necessarily others?
<awygle> i probably fucked everything somehow
<awygle> here are the three errors that i get
<cr1901_modern> awygle: FWIW, I now have the same error after trying it :P
<awygle> Well that's encouraging, sort of
<cr1901_modern> I've never run yosys when diamond_env was active, that's why I never saw this issue
<whitequark> awygle: ugh, so, you shouldn't set bindir while you're running nmigen
<whitequark> one moment
<whitequark> try running nmigen with `export NMIGEN_ENV_Diamond=/usr/local/diamond/3.11_x64/bin/lin64/diamond_env`
<awygle> whitequark: so, that prevents the yosys explosion, but there's still the parse problem with the execute shell script
<whitequark> which parse problem?
<whitequark> can you show the log?
<awygle> which log?
<awygle> this is what ig et on the terminal
<whitequark> hm
<whitequark> okay, let me grab diamind
<whitequark> *diamond
<_whitenotifier-3> [nmigen] rroohhh opened issue #320: Unclear error message on direction mismatch between Instance in submodule and toplevel usage -
<_whitenotifier-3> [nmigen] whitequark commented on issue #320: Unclear error message on direction mismatch between Instance in submodule and toplevel usage -
Asu has quit [Ping timeout: 268 seconds]
<awygle> the o->n conversion of Signal(max=N) should be Signal(range(N)), right?
<whitequark> yes
<whitequark> (it says that in the deprecation warning, no?)
<awygle> i just got an explosion, not a deprecation warning. but i'm messing around in nmigen.compat, so that's probably why
<awygle> (by explosion i mean "unexpected keyword argument" error)
<whitequark> awygle: ok, i have diamond working
<awygle> oh sweet
<whitequark> `fakeroot alien --scripts x.rpm` is just fine
<whitequark> not sure what broke for you
<awygle> on what linux distro?
<whitequark> debian
<awygle> i didn't use fakeroot i just used Actual Root, lemme try with fakeroot and see if that helps...
<whitequark> mostly packages from stable (everything diamond depends on should be from stable, anyway_
<whitequark> the diamond GUI runs
<whitequark> let me check nmigen now
<whitequark> awygle: i can reproduce your crash
<whitequark> awygle: sigh
<whitequark> awygle: for x in /usr/local/diamond/3.11_x64/synpbase/bin/*; do [ -f $x ] && sudo sed 's,#!/bin/sh,#!/bin/bash,' -i $x; done
<emily> hey come on at least do /usr/bin/env bash
<awygle> Jesus. Arright lol
<whitequark> emily: pointless
<whitequark> the rest of it is still full of absolute paths
<whitequark> awygle: applies to 3.10 too iirc
<ktemkin> oh gods; it's 2020 and we're still getting bitten by the "everyone links /bin/sh to bash except debian who links to dash by default" thing?
<ktemkin> life hack: put the blinders back on and `dpkg-reconfigurure dash` your way to `bash` being your `/bin/sh`~