ChanServ changed the topic of #nmigen to: nMigen hardware description language · code at · logs at · IRC meetings each 1st & 3rd Monday at 1800 UTC · next meeting July 20th
daknig2 has quit [Ping timeout: 264 seconds]
<_whitenotifier-b> [YoWASP/yosys] github-actions[bot] pushed 1 commit to update-deps [+0/-0/±1]
<_whitenotifier-b> [YoWASP/yosys] github-actions[bot] d46cc4e - Update upstream code
<_whitenotifier-b> [yosys] github-actions[bot] opened pull request #9: Auto-update -
<_whitenotifier-b> [yosys] github-actions[bot] created branch update-deps -
<_whitenotifier-b> [YoWASP/nextpnr] github-actions[bot] pushed 1 commit to update-deps [+0/-0/±2]
<_whitenotifier-b> [YoWASP/nextpnr] github-actions[bot] 0bb6bb6 - Update upstream code
<_whitenotifier-b> [nextpnr] github-actions[bot] created branch update-deps -
<_whitenotifier-b> [nextpnr] github-actions[bot] opened pull request #5: Auto-update -
daknig2 has joined #nmigen
Degi has quit [Ping timeout: 258 seconds]
Degi has joined #nmigen
electronic_eel has quit [Ping timeout: 246 seconds]
electronic_eel has joined #nmigen
* zignig battles a register allocator.
jaseg has quit [Ping timeout: 260 seconds]
jaseg has joined #nmigen
jock-tanner has quit [Remote host closed the connection]
jock-tanner has joined #nmigen
electronic_eel has quit [Ping timeout: 260 seconds]
electronic_eel has joined #nmigen
<d1b2> <TiltMeSenpai> how am I supposed to interface with a Connector? I feel like I'm missing something big here
<d1b2> <TiltMeSenpai> oh wait, there's add_resource
<d1b2> <TiltMeSenpai> hmm... hold, I might be doing bad braindead here
<d1b2> <TiltMeSenpai> ok, I think I figured it out
PyroPeter_ has joined #nmigen
PyroPeter has quit [Ping timeout: 260 seconds]
PyroPeter_ is now known as PyroPeter
jock-tanner has quit [Ping timeout: 256 seconds]
proteus-guy has joined #nmigen
proteus-guy has quit [Remote host closed the connection]
proteus-guy has joined #nmigen
daknig2 has quit [Ping timeout: 256 seconds]
daknig2 has joined #nmigen
<d1b2> <emeb> heh - actually got nmigen blinking the rgb on my orangecrab. took some groveling through all the languishing tutorials and various repos but it's starting to make sense.
<d1b2> <TiltMeSenpai> yay, I almost have cap sense working
<d1b2> <TiltMeSenpai> I just gotta get some time constants right
<d1b2> <emeb> almost is good - if you know how to get the last bit
<d1b2> <TiltMeSenpai> I think the capacitance could be tweaked to get a higher response
<d1b2> <TiltMeSenpai> oh found it
jock-tanner has joined #nmigen
jeanthom has joined #nmigen
Asu has joined #nmigen
Kekskruemel has joined #nmigen
<Kekskruemel> I have a module with two clock domains, one positive and one negative edge triggered. If I use pysim to "yield Tick('sync_neg')" i get a full cylce each time ending on the negative edge, as i would expect. If i then "yield Tick('sync') i get a half cycle as expected, but doing a second "yield Tick('sync')" gives me just a negative half cycle and doesn't take me to the next positive edge. Why?
<Kekskruemel> I thought it was handled differently before the last pysim changes...
<_whitenotifier-b> [nmigen-boards] ktemkin opened pull request #85: add resource helpers for USB (direct+ULPI) -
<_whitenotifier-b> [nmigen-boards] ktemkin closed pull request #85: add resource helpers for USB (direct+ULPI) -
<_whitenotifier-b> [nmigen-boards] ktemkin opened pull request #86: add resource helpers for USB (direct+ULPI) -
<ktemkin> [by the way, expect a bunch of PRs from me to nmigen-boards as I try squish all the LUNA supported boards into there]
daknig2 has quit [Ping timeout: 240 seconds]
daknig2 has joined #nmigen
daknig2 has quit [Ping timeout: 256 seconds]
daknig2 has joined #nmigen
<_whitenotifier-b> [yosys] whitequark closed pull request #9: Auto-update -
<_whitenotifier-b> [YoWASP/yosys] whitequark pushed 1 commit to develop [+0/-0/±1]
<_whitenotifier-b> [YoWASP/yosys] github-actions[bot] 2f7882d - Update upstream code
<_whitenotifier-b> [nextpnr] whitequark closed pull request #5: Auto-update -
<_whitenotifier-b> [YoWASP/nextpnr] whitequark pushed 1 commit to develop [+0/-0/±2]
<_whitenotifier-b> [YoWASP/nextpnr] github-actions[bot] 0b58e41 - Update upstream code
<_whitenotifier-b> [yosys] whitequark deleted branch update-deps -
<_whitenotifier-b> [YoWASP/yosys] whitequark deleted branch update-deps
<_whitenotifier-b> [YoWASP/nextpnr] whitequark deleted branch update-deps
<_whitenotifier-b> [nextpnr] whitequark deleted branch update-deps -
<_whitenotifier-b> [nmigen] DaKnig opened issue #438: wrong type of buffer primitive used in series 7 -
<whitequark> daveshah: any idea what's happening here? AFAICT BUFGCE is a 7S primitive
<DaKnig> why does it need BUFGCE anyways? why not BUFG?
<DaKnig> its a blinking led, surely BUFG would have been enough
alexhw_ has joined #nmigen
XgFgX has joined #nmigen
XgF has quit [Disconnected by services]
alexhw has quit [*.net *.split]
<whitequark> ktemkin: ping
<whitequark> Kekskruemel: that seems like a bug, can you open an issue with an MCVE?
<_whitenotifier-b> [nmigen] DaKnig edited issue #438: wrong type of buffer primitive used in series 7 -
<_whitenotifier-b> [nmigen] whitequark commented on issue #438: wrong type of buffer primitive used in series 7 -
<whitequark> ktemkin: so what i was wondering about is the pin naming for USB
<whitequark> upstream says dp/dm, we say d_p/d_n in one place and dp/dn in another
<whitequark> i feel like we should at *least* reduce the amount of naming conventions by one
<whitequark> originally i used d_p/d_n because that's our standard for differential pins... but... USB 1 isn't actually differential, so that no longer applies
<whitequark> (and there won't be a direct USB resource for USB2, i suspect)
<ktemkin> I mean, lots of things aren't _really_ differential but use the differential naming
<ktemkin> *but use differential naming
<ktemkin> I've seen d_p and d_n in a variety of FPGA designs, and wound up using it for LUNA in order to keep in line with that convention
<ktemkin> (I omitted underscores in the kwargs because underscores in kwargs are semantically overloaded in other places, such as Instance)
daknig2 has quit [Ping timeout: 260 seconds]
<whitequark> fair
<_whitenotifier-b> [nmigen-boards] whitequark reviewed pull request #86 commit -
<ktemkin> I am honestly okay with pretty much any of the options; and there's nothing super wrong with e.g. just using dp/dm or d_p/d_n
<_whitenotifier-b> [nmigen-boards] whitequark reviewed pull request #86 commit -
<whitequark> I don't have a strong opinion, it just seems potentially frustrating to have three conventional names at once
<ktemkin> mm
<ktemkin> my main concern with dp/dm is that D+/D- are named as if the lines were differential on the USB side; and I feel like when guessing how those'd be written in nmigen I/O, folks might assume d_p/d_n
<ktemkin> since generically A+/A- translate to a_p and a_n
<whitequark> mm, right
<ktemkin> all the options suck, so I'm completely ambivalent
<whitequark> I'd probably just use d_p/d_n in the resource arguments, then
<ktemkin> mm, I'm fine with that
<whitequark> it's not very ambiguous with Instance
<ktemkin> mm, yeah -- I just worry the prefixes will seem to have semantic meaning
<ktemkin> I see quite a few omigen designs that use things like i_blah and o_blah
<ktemkin> but again, I don't -really- see an issue with changing it
<ktemkin> just sharing thought process
<whitequark> that's more or less what already happens there, right?
<whitequark> with suffixes instead of prefixes
<ktemkin> mm, fair
<ktemkin> if you want I can update the PR accordingly
<ktemkin> might be a couple of hours until I get around to it, though
<whitequark> sgtm
<_whitenotifier-b> [nmigen-boards] ktemkin synchronize pull request #86: add resource helpers for USB (direct+ULPI) -
<_whitenotifier-b> [nmigen-boards] ktemkin synchronize pull request #86: add resource helpers for USB (direct+ULPI) -
<_whitenotifier-b> [nmigen-boards] whitequark closed pull request #86: add resource helpers for USB (direct+ULPI) -
<_whitenotifier-b> [nmigen/nmigen-boards] whitequark pushed 1 commit to master [+0/-0/±6]
<_whitenotifier-b> [nmigen/nmigen-boards] ktemkin dd0bb11 - Factor out direct USB and ULPI resources.
<_whitenotifier-b> [nmigen-boards] ktemkin reviewed pull request #86 commit -
<lkcl> whitequark: i ran cxxsim a few days ago (and again an hour ago after yosys and nmigen git pull) and on the ALU pipeline test the unit produces results that are wrong - and known to be correct.
<ktemkin> cool beans; with that merged I can start PR'ing all the platform definitions I've been lazily collecting over here >.>
<lkcl> i'm looking to see if i can find a smaller example.
<lkcl> however things are hampered by not being able to find the equivalent option that saves a vcd file.
<_whitenotifier-b> [nmigen-boards] whitequark reviewed pull request #86 commit -
<whitequark> lkcl: VCD writing is supported in the cxxsim branch, I pushed an update that does this recently
<lkcl> ahh great. how recently? in the past hour?
<whitequark> 2020-07-16 07:54:36
<ktemkin> <-- bleh; it's going to be fun to figure out the best way to capture these platform resources on the hackaday badge
<lkcl> that's... odd. the repo checkout i'm working with has gone... odd. master is no longer "master".
<lkcl> let me investigate what the heck is going on
<lkcl> i've managed to check out "commit 5ccc2122" despite it not being listed as "head" on github.
<lkcl> head is listed as commit d06add0
<lkcl> ah. whitequark: are we talking about the cxxsim branch?
<whitequark> yes
<lkcl> ahh nooow i have a write_vcd function. okaay.
<lkcl> 1 sec will re-run the test
Yehowshua has joined #nmigen
<lkcl> okaay. small example doesn't terminate. two sync processes, the unit test "works" but does not end when both processes finish.
<whitequark> hm, odd
<whitequark> please post MCVE
<whitequark> as an issue
<lkcl> whitequark: remember, i do not have a github account, so i can't post issues. or communicate on or interact with github issues.
<whitequark> then register one
<lkcl> i'll see what i can do. the example is quite small and (almost) self-contained
<lkcl> apologies: i don't agree with their terms and conditions, so will not be registering one.
daknig2 has joined #nmigen
<whitequark> okay, that's not my problem though
<Yehowshua> Hey Luke,
<lkcl> Yehowshua: ta. that would work.
<lkcl> or i can upload elsewhere (and/or commit to a repo and post a link)
<lkcl> the example we're working with is quite simple so should not take long to cut down.
<Yehowshua> whitequark, so CXXSim works in my Linux box just fine, but I have to inform it on my Mac to explicitly use GCC. This is because in `cc = sysconfig.get_config_var("CC")`, `sysconfig.get_config_var("CC")` is permanently fixed to `clang` on Mac. To get around this, I explicitly, set `cc = 'gcc'` in Do you think it makes sense supporting a `cc`
<Yehowshua> argument to Simulator(), or perhaps changing sysconfig.get_config_var to os.environ since I have gcc and not clang as my CC variable anyways?
<Yehowshua> lkcl, or just email it to me, I'll make an issue
<lkcl> cando.
<lkcl> am currently putting in some debug prints.
<whitequark> Yehowshua: clang actually runs cxxsim code faster
<whitequark> by something like 15%
<Yehowshua> Yeah - i you mentioned that in February. CXXSim selects `gcc` in my ubuntu box though by default
<Yehowshua> And I can't change it
<Yehowshua> Well technically sysconfig.get_config_var selects it in ``
<whitequark> yeah, so in principle, the reason i'm using sysconfig.get_config_var is because that's guaranteed to be a working compiler python knows how to invoke, since it's what native extensions use
<whitequark> but overides make sense
<Yehowshua> This is tricky. You wouldn't want to do Simulator(cc='clang') because then that requires the user to compensate for different platforms. If you make it fetch CC from the environment, then the user is only responsible to set once in their environment with `export CC` or just do `CC=clang CXX=clang ptyhon3`.
<Yehowshua> Just my two cents
<Yehowshua> Compensate, as in change lots of files that run tests etc.
<lkcl> it's standard practice and a standard convention to allow override of the c compiler in build tools through "CC".
<lkcl> some people define it to run through ccache
<lkcl> and some through ccache *and* distcc
<lkcl> even when using gcc (on the target remote machine)
<lkcl> distcc as you know allows running of gcc (or other compiler) on a remote (often much faster) system.
<whitequark> Yehowshua: yeah I meant from the environment
<whitequark> lkcl: I know it's standard, what I was worried about is e.g. people overriding CC but not CFLAGS
<whitequark> resulting in a broken combination
<lkcl> yyeah that's a tricky one. one of the downsides of creating a (new) build/Make system (which is what nmigen is, effectively)
<lkcl> from experience, typically it's the top-level INSTALL.txt / README that contains the list of supported exported variables and how to use them.
<lkcl> honestly i'd expect that if it's right in the top level and people don't understand that overriding CC and CFLAGS is a standard convention, then.. well... :)
<lkcl> _documented_ and well-established convention...
<whitequark> no, not that
<whitequark> usually the default CFLAGS is empty, but in cxxsim it's not
<lkcl> understood
<whitequark> (aside: cxxsim's build system and are completely unrelated. yes, nmigen now has *two* build systems)
<Yehowshua> Anyways whitequark, well done so far with CXXSim. I mentioned that its as fast as verilator to some people in my lab and saw some serious interest.
<Yehowshua> Pushing for more interest in better HDL tooling in Academia - because those are the people that go to industry. Chisel saw some industry adoption that way
<Yehowshua> Would be great to see the same for nMigen
<lkcl> hmmm the issue with cxxsim is in a handshaking example. ready/valid signalling. synchronisation is being lost (where it works with pysim)
<lkcl> odd
Yehowshua has quit [Remote host closed the connection]
<whitequark> Yehowshua: it's *almost* as fast as *single-threaded* verilator on most designs
<lkcl> cool!
<whitequark> i've only seen it be completely equivalent to verilator's speed on one design, i think
Yehowshua has joined #nmigen
Yehowshua has quit [Remote host closed the connection]
jock-tanner has quit [Ping timeout: 264 seconds]
<lkcl> given that it's running *from python* then a fair comparison would be running against e.g. cocotb.
<lkcl> which is a co-simulation system that compiles code using verilator, and (just like cxxsim) single-steps it from *python*
* lkcl wonders if cxxsim could do verilog code as well? it can, can't it (use Instance)
<daveshah> If Yosys can parse the Verilog, then sure
<lkcl> would that be right? whitequark: can it also compile arbitrary verilog that's included via Instance()?
<lkcl> utterly cool!
<daveshah> I've even done mixed simulation with VHDL too
<daveshah> using the ghdl plugin
<lkcl> well that's fantastic, because it means not needing to compile everything to verilator as the "default sole exclusive option to do mixed RTL simulations"
<lkcl> cool!
<whitequark> lkcl: in principle yes, in practice that's not exposed in nmigenyet
<whitequark> it's not really clear how that would be done
<lkcl> whitequark: ok
<lkcl> oh. minor discrepancy: pysim creates vcd files with the dut being under something named "top"
<whitequark> right, yeah
<lkcl> where cxxsim does not have that "top" object.
<daveshah> Ah, I wasn't using the nMigen integration so I can't comment on that side of things
<whitequark> i should bring them together
<lkcl> ok, you know about it :)
<lkcl> i just re-loaded gtkwave (ctrl-shift-R) and lost all the signals under investigation (doh)
<whitequark> yeah, obnoxious
<whitequark> right now this isn't exposed in the cxxrtl C API, i think
<whitequark> so will take a small amount of time to fix
<lkcl> i got into the habit of saving the state to a gtkw file and have even been known to hand-edit the gtkw files to change signal names (!)
<whitequark> you can rename them in the gtkwave ui i think
<lkcl> fsm_state is only a signal not a string, now i have the two vcd files side-by-side
<whitequark> right, decoders don't work
<lkcl> whitequark: oh! i discovered "aliases" a few days ago
<whitequark> if you want decoders to work, find someone to work on
<lkcl> interesting. count$next is missing, as is fsmstate$next...
<whitequark> yes, pysim doesn't have those, as they are an artifact of translating to RTLIL
<whitequark> i can get rid of them in cxxsim view i think
<lkcl> oh right! yes, they're in the cxxrtl version.
<lkcl> ok. yep. i'm looking side-by-side at the two runs (pysim and cxxsim) and ... err... errr... ah.
<lkcl> fsm_state and fsm_state$next are *different*.
<lkcl> oink
<lkcl> ah Yehowshua's offline
<lkcl> screenshot-of-a-screenshot time... :)
<lkcl> ahhh. a "yield" was missing which allowed the FSM to remain asserted for long enough
<lkcl> at the end of the FSM's ready/valid signalling.
<lkcl> mmm iiinteresting, that pysim didn't pick that up, but cxxsim did
<lkcl> ok let's try some more examples
<lkcl> another handshaking example fails. mmm checking these is going to take a while.
<lkcl> i'm always nervous about two "unknowns". we have no idea if it's cxxsim or if it's the unit test.
<lkcl> damn. well, it's a good thing.
daknig2 has quit [Ping timeout: 258 seconds]
Yehowshua has joined #nmigen
<Yehowshua> lkcl I’m back... sorry got a little distracted trying to build cxxsim for my ipad
<whitequark> comparing performance?
<whitequark> lkcl: so here's the thing, any mismatch between cxxsim and pysim is inherently a bug
<Yehowshua> No... being a Masochist... also trying on MacSE
<whitequark> it's a bug in either pysim or cxxsim
<Yehowshua> Oh that was for lkcl
<DaKnig> what is that line supposed to do? I am trying to pass that bitstream_filename to some other app but when it gets there, the app claims the file doesnt exist
<DaKnig> it points to somewhere in /tmp/
Kekskruemel has quit [Ping timeout: 256 seconds]
<DaKnig> while the ./build/ directory has the .bit file as well
emeb has joined #nmigen
<Yehowshua> DaKnig, so that line pattern matches for the filname
<Yehowshua> whitequark, so I’ll go ahead and create an issue for Luke’s thing once I test it on my machine?
<DaKnig> sorry I dont understand what you're saying
<DaKnig> what pattern?
Yehowshua has quit [Remote host closed the connection]
Yehowshua has joined #nmigen
<Yehowshua> Hold up, what do you mean by passing to another app?
<Yehowshua> the built files should be in the folder ./build
Kekskruemel has joined #nmigen
<whitequark> Yehowshua: so is a bit complex because it's designed to support remote builds
<whitequark> for example, when you have one vivado license and it's on a windows server, but you're on linux
<whitequark> so there's an .extract() method that, with remote builds, would grab stuff from the server
Yehowshua has quit [Remote host closed the connection]
daknig2 has joined #nmigen
daknig2 has quit [Ping timeout: 256 seconds]
<lkcl> whitequark: ok, so i commented the line that needs to be removed/added to get (alternately but mutually-exclusively) pysim or cxxsim to work
<lkcl> doh, Yehowshua's gone offline again :)
<lkcl> whitequark: i realise it's "Yet Another Dependency" - have you looked at pyro?
Yehowshua has joined #nmigen
<DaKnig> Yehowshua: I changed the next line to use vivado to flash the device. it just says that the file at /tmp/ doesnt exist... and I cant see it either
<lkcl> it's pretty frickin awesome: the author invented a network protocol that allows function calls to be done as if they're local, and the results to be sent back transparently. even exceptions translate correctly across the link
<Yehowshua> lkcl, Yehowshua lives in an area that could really benefit from net neutrality and less crummy ISPs...
<lkcl> Yehowshua: compiling for an ipad?? i'm not sure whether to be scared or impressed :)
<Yehowshua> Haha - nMigen without CXX runs just fine in iOS shell and on iMac G3. Can't say the same for my Powerbook Pismo 95 tho
<lkcl> Yehowshua: sigh. there's IRC proxies around. although i know that a huge number of debian developers log in to remote servers using "screen" and leave a ]text-based version of] an irc client permanently running for years.
<Yehowshua> DaKnig, can I see a pastebin?
<whitequark> i actually use irssi in mosh
<lkcl> whitequark: i suggest pyro4 because rather than invent a remote calling system, it Does The Job. as long as python is installed remotely (and ssh) it's possible for it to bootstrap itself by first scp'ing a copy of pyro4 onto the remote machine
<whitequark> in tmux
<whitequark> what? of course i don't want to assume python is installed
<whitequark> just the build tools
<lkcl> whitequark: ahh then pyro4 is not an option.
<lkcl> somewhere online i found a really useful shell-script voodoo incantation which combines mosh and screen. i've found it incredibly useful.
<whitequark> there's nothing super complicated about remote builds
<lkcl> mosh-screen () { mosh "$@" -- screen -dR mosh-session }
<whitequark> transfer a zip archive, unpack it, run a single command inside it, transfer results back
<lkcl> whitequark: true :)
<Yehowshua> lkcl, currently looking at your FTP file, will create issue shortly
<lkcl> Yehowshua: ack, appreciated. it's... odd. i'm reasonably certain it's a close-call timing-related issue in the original code ( which is missing that "yield"
<lkcl> if it wasn't for that bug this issue wouldn't have been spotted
<whitequark> i think i know what you're hitting
<lkcl> but the fact that when running under cxxsim, fsm_state$next is "correct" but fsm_state *does not match it* leads me to believe it's a bug in cxxsim
<whitequark> hm
<whitequark> wait, what
<lkcl> fsm_state$next != fsm_state-delayed-by-one-cycle
<lkcl> which is what alerted me to look more closely at how ready_i was being set/checked
<lkcl> and valid_o
<whitequark> lkcl: wtf, looks like a bug for sure
<lkcl> and it turns out there was no "yield" between when:
<whitequark> wait
<lkcl> * ready_i is set to 1
<lkcl> * valid_o is checked
<lkcl> * ready_i is set to 0
<whitequark> look at it more carefully
<whitequark> fsm_state$next changes to 01 in the middle of the cycle
<whitequark> presumably as a result of something your processes did
<whitequark> oh
<whitequark> ok, yeah, i know what bug you're hitting
<lkcl> tck...tck... ah yes it does. it changes on the falling edge, doesn't it?
<lkcl> wh
<lkcl> i mean, it's a "good thing" in that we've found a crucial bug in one of the unit tests
lkcl is now known as lkcl_away
<DaKnig> when I run my nmigen script thing it synthesyses and all that but when it gets to running this part, it says something about the file /temp/something_here.bit not existing
DaKnig is now known as helloworldpi
helloworldpi is now known as DaKnig
<Yehowshua> DaKnig, you're using RPC?
<Yehowshua> As in calling it remotely - I can only read part of the previous conversation owing to my crummy internet connection
<_whitenotifier-b> [nmigen] BracketMaster opened issue #439: fsm_state changes mid cycle -
<DaKnig> you can look at the logs
<DaKnig> I dont run it via remote or anything
<whitequark> can you strace it?
<DaKnig> the problem is I dont get that that `with` line is doing, I assumed it gives me the bitstream file or w/e, but when I pass it to vivado , it says that the file (which is located in /tmp/ btw) does not exist
<whitequark> that's what it should be doing
<whitequark> grabbing a file and stuffing it into /tmp/ and giving you the filenema
<whitequark> *filename
<DaKnig> why in /tmp tho? this file also exists in the ./build directory, wouldnt it be easier to give me that?
<whitequark> to make remote builds and local builds as close as possible, therefore avoiding latent bugs in the relatively rare remote builds at the cost of somewhat more pain in local builds
<_whitenotifier-b> [nmigen] kruemelkeks opened issue #440: Wrong timestep with mixed clock edge ticks within pysim -
Kekskruemel has quit [Ping timeout: 240 seconds]
<_whitenotifier-b> [nmigen] BracketMaster edited issue #439: fsm_state changes mid cycle -
<DaKnig> whitequark does this `with` statement also delete the file right after it?
<DaKnig> when closing the context
<whitequark> yes
<whitequark> does vivado fork or something?
daknig2 has joined #nmigen
<trabucayre> pff qorc-sdk is freertos dependant :(
Yehowshua has quit [Ping timeout: 245 seconds]
daknig2 has quit [Ping timeout: 264 seconds]
<DaKnig> vivado forks, yes
<DaKnig> I have no idea how to tell it to not take up all the system resources when it starts, even if the task at hand doesnt require those resources
<DaKnig> when it starts it takes like 6 seconds on my pc and at that time it eats up more than half the RAM even if its just to run a tcl script
<daveshah> I suspect a chunk of that is the device data
<daveshah> I am not sure if there is any particular way of improving things, though
<DaKnig> doubt
<DaKnig> it takes said 6 seconds before it starts doing anything
<DaKnig> I mean before the first tcl command runs (which is before it knows what device I wanna use)
<DaKnig> running the tcl script itself doesnt take long at all
<whitequark> DaKnig: can you run impact directly?
<DaKnig> whats impact
<DaKnig> all I am trying to do is use vivado in cli mode to flash the bitstream
<DaKnig> since the solution provided by default doesnt work for me without recompiling half the OS
daknig2 has joined #nmigen
<DaKnig> btw I cant access the log whitequark
<whitequark> iMPACT is Vivado's programming
<whitequark> *programmer
<emeb> It is ancient and crufty and has a horrible UI.
<whitequark> so, like the rest of vivado?
<whitequark> vivado's GUI*
<whitequark> DaKnig: take a look at what Atlys does
<emeb> yes, but worse because it's older. I can remember using Impact 20 yrs ago.
<whitequark> ouch
<emeb> there were many impact/crash jokes about the lab back in the day...
Yehowshua has joined #nmigen
<Yehowshua> Never miss a chance to rag on Vivado...
<emeb> whitequark: lols
lkcl_away has quit [Ping timeout: 258 seconds]
<Yehowshua> whitequark, I tried getting CXXSim running under ubuntu explicitly with clang in docker and am having a .so issue...
* emeb has nightmares about using Xilinx back in the 3000-series days.
<emeb> when we had to optimize timing by hand placing *everything*
<Yehowshua> In fact, I've **only** gotten CXX to work with gcc so far...
<Yehowshua> That's clang10
<Yehowshua> emeb: were you using Xilinx 3000 for work?
<whitequark> Yehowshua: hm, how are you running it exactly?
<Yehowshua> I change cc and cxx in both to 'cc'
<emeb> Yehowshua: yes! We were doing software-defined radio stuff back in the early 90s
<Yehowshua> OH dang!!
<Yehowshua> You were ahead of your time
<whitequark> Yehowshua: yeah well don't do that, "cc" is a C compiler
<whitequark> use "c++"
<emeb> At the risk of sounding like Grandpa Simpson, we used an entire FPGA just to build a digital multiplier. :P
<Yehowshua> It worked!
<Yehowshua> witchcraft
<Yehowshua> emeb, do you have a Github?
<Yehowshua> So from what I gather from talking to other companies and engineers, Xilinx FPGAs are largely used in the broadcast industry
<Yehowshua> Especially in SDI PCIe cards and to do debayering and color correction for high end cameras
<Yehowshua> And then the MS Azure Brainwae and Amazon's virtual FPGA thingy
<Yehowshua> emeb, looks like you have a ulx3s
<emeb> Used pretty much everywhere that lots of logic is needed but the market isn't large enough to justify a full-custom ASIC solution.
<emeb> A lot of earlier cell basestations were FPGA based too.
lkcl has joined #nmigen
<emeb> Yehowshua: yes - Edmund sent me one a few months ago. Haven't done much with it yet, but I suspect I could hook my ADC board to it...
lkcl_ has joined #nmigen
<Yehowshua> How is it? I ordered one but they're not shipping until August
<emeb> Seems perfectly fine. It took me a bit of futzing to get the programming tool to work though.
<emeb> The details escape me ATM, but I had to hunt around for docs and source to get it going.
<Yehowshua> Just came across your RPI ice40 SDR hat, I think I remember a couple years ago, black mesa labs made an RPI hat
<Yehowshua> With an hx8k
<emeb> Yes, he did that one about the same time I did mine.
lkcl has quit [Ping timeout: 258 seconds]
<Yehowshua> Have you used nMigen any?
<emeb> Just got started with it last night on my new Orange Crab.
<Yehowshua> Very cool. Curious to see what you do with it.
<emeb> heh - probably some boring SDR crud. I've got my decimating downconverter modeled in Python so it would seem like a short leap to code it up in nmigen.
Yehowshua has quit [Remote host closed the connection]
jeanthom has quit [Ping timeout: 246 seconds]
SpaceCoaster has quit [Ping timeout: 265 seconds]
SpaceCoaster has joined #nmigen
Yehowshua has joined #nmigen
<Yehowshua> emeb, have you tried using Luna to talk to orange crab from your host?
<emeb> Yehowshua: No - haven't gotten far enough into nmigen to grok that.
<Yehowshua> Well, I imagine you might need to communicate with the orange crab soon for SDR. Didn't see a Luna example for orange crab. Its probably not too hard to do. So I'll take a stab at getting a minimal Luna serial on the orange crab
Yehowshua has quit [Remote host closed the connection]
<ktemkin> (LUNA’s examples are often provided-platform agnostic; so the existing examples work on the orangecrab if you set the LUNA_PLATFORM environment variable correctly)
<emeb> hmm... trying to install luna but getting all kinds of interesting errors.
<emeb> did I install the wrong nmigen?
<whitequark> LUNA requires nmigen from the master branch, I believe
<emeb> yes, saw that. I *thought* that's what I had.
<whitequark> what are the errors?
<emeb> nmigen 0.3.dev141+g5ccc212 has requirement pyvcd~=0.2.2, but you'll have pyvcd 0.1.7 which is incompatible.
<emeb> lambdasoc 0.1.dev25+g7381b47 has requirement nmigen<0.3,>=0.1, but you'll have nmigen 0.3.dev141+g5ccc212 which is incompatible.
<whitequark> how did you install nmigen? did you follow the instructions on
<emeb> I read that page and did this: pip3 install --user --upgrade nmigen
<emeb> and then to get the latest boards did this: pip3 install --user 'git+'
<whitequark> yes, that seems correct
<whitequark> why didn't it pull newer pyvcd
Asu has quit [Remote host closed the connection]
<ktemkin> (you can ignore the lambdasoc soft-error; the on their side is overly strict about version and it’s a soft requirement)
<emeb> is there a way to grab a newer pyvcd and retry?
<whitequark> pip3 install 'pyvcd~=0.2.2'
<ktemkin> those “errors” aren’t indications that the process has failed, as much as python makes it look like it — they’re it letting you know that you have conflicting local requirements post-instal, so things might be broken
<ktemkin> *install
<whitequark> (you're technically right, of course, but i still think that can only be called a "failure"...)
<emeb> ok. newer pyvcd installed and the luna script rerun w/ happy results. thanks!
<ktemkin> whitequark: yeah, but without the strict need to re-run the command that “error”’d / “retry”
<ktemkin> the failure is less on the part of the individual install command and more on python package management as a whole~ =P
jeanthom has joined #nmigen
<whitequark> i'm actually not completely sure about the lack of need to re-run
<whitequark> i think i've seen some cases where i did have to rerun them?
<emeb> ktemkin: tried the post-install test dry run and it's complaining: ModuleNotFoundError: No module named 'prompt_toolkit'
<ktemkin> the docs need to be clarified: that test script is only for LUNA hardware
<ktemkin> run one of the examples to test running on the OrangeCrab (I suggest examples/usb/
<emeb> OK - will do.
<ktemkin> emeb: it’s worth noting that the orangecrab is a full-speed USB platform, so if you want to do something like SDR, LUNA/USB may not have enough throughput for your application
<emeb> ktemkin: Yeah - not looking at wide bandwidth stuff ATM. Full speed should suffice for audio bandwidths.
<ktemkin> also, make sure you set LUNA_PLATFORM in your environment if you want the examples to Just Work:
<emeb> Thanks - just started reading the docs and am making a lot of incorrect assumptions.
Yehowshua has joined #nmigen
<Yehowshua> ktemkin, so I'm guessing the reason you have to set the platform is to enable LUNA to generate the PLL in the `platform.clock_domain_generator()`?
<ktemkin> in the environment? it just sets which platform the examples (and other things that use the built-in main function) try to use
<emeb> \o/ appears to have built, programmed and enumerated.
<Yehowshua> ayyy
<Yehowshua> `lsusb`?
<emeb> just looking at journalctl -f
<ktemkin> Yehowshua: but yes, the platform definition local to LUNA, in addition to the I/O resources and typical platform things, provide a teensy bit of platform abstraction in the form of indicating which module should be used by the examples for e.g. PLL/clock-domain config & which I/O resource provides the USB connections
<Yehowshua> You should see `0x16d0`
<emeb> yep, and lotsa nice mfg data in the descriptors.
<Yehowshua> Yes, I notice how you fill out the PLL params directly in the derived board classes
<Yehowshua> Super clever
<emeb> loopback works too.
<emeb> Very nice - idiot proof. :P
<ktemkin> \o/
<emeb> Now wondering if I can get this working so easily on my home-made ice40 up5k board...
<emeb> I guess I'd have to make a custom platform definition?
<Yehowshua> How many lattice's you got there buddy?
<Yehowshua> You're making Lattice rich...
<Yehowshua> You can derive from ice40
<Yehowshua> Take a look at that for guidance
<emeb> lots - I've been grinding boards out for the last few years.
<ktemkin> (check out the Fomu or iCEBreaker platforms; those are up5k based)
Kekskruemel has joined #nmigen
<emeb> cool
<ktemkin> LUNA_PLATFORM will take a filename for the section before the “:” too; so you can use an out-of-tree platform file as you dev, as well :)
<DaKnig> whitequark whats atlys? you mean the diligent board?
<emeb> Good - that's what I was hoping to do.
<DaKnig> that's all I can see
<ktemkin> [anyways, I’ll be back later if you have more questions :)]
<emeb> thanks for the help!
emeb has quit [Read error: Connection reset by peer]
emeb1 has joined #nmigen
emeb1 has quit [Client Quit]
Kekskruemel has quit [Quit: Leaving]
<Yehowshua> ktemkin, just curious, why not have the requirements in requirements in ``?
<Yehowshua> That way you could do `pip install git +`
<d1b2> <emeb> heh - hooked the orange crab RGB LED to the low 3 bits of the USB payload in the example.
<Yehowshua> I see `-e` in requirements.txt. Guessing that's why...
<whitequark> Yehowshua: little known fact: you can specify those in too
<whitequark> though that might be deprecated
<Yehowshua> Well, distutils deprecated adding git+somerepo into requires for `python install` for python38 I believe
<Yehowshua> I only discovered last week and was walking cPython's git log to find out why
<whitequark> ah ok
<Yehowshua> it will *still* work however for `pip3 install -e .` in the same directory as
jeanthom has quit [Ping timeout: 240 seconds]
XgFgX is now known as XgF_
XgF_ is now known as XgF
<Yehowshua> Got Luna on my TinyFPGA. Any recommendations besides wireshark usb for debugging?
<Yehowshua> I guess I'm asking if Luna comes with such capabililties
<Yehowshua> Running on the host
jock-tanner has joined #nmigen
Yehowshua has quit [Remote host closed the connection]
Stary has quit [Quit: ZNC -]
Stary has joined #nmigen
<DaKnig> I cant find the impact executable
<DaKnig> I searched for files with `impact` in their names in the whole directory that ahs everything xilinx on my computer but the only one that didnt have an extension was a manpage
<whitequark> hm
<whitequark> it might be an optional component that's not installed
<whitequark> let's see if there are other ways to fix this
<whitequark> can you link me to the procedure you want to use with vivado?
<whitequark> does it help if you pass -batch to vivado as an argument?
<whitequark> er
<DaKnig> I posted a link to my paste earlier, lemme find it
<whitequark> vivado -mode batch -source program_fpga.tcl
<DaKnig> yeah that's what Im doing
<DaKnig> but it doesnt work with this
<DaKnig> since vivado says that the file does not exist
<whitequark> you have -mode tcl
<whitequark> and it forks
<whitequark> i'm wondering if with -mode batch it won't fork
<DaKnig> Im assuming it forks
<DaKnig> lemme check if it works with this one
proteus-guy has quit [Ping timeout: 256 seconds]
<DaKnig> btw there's this issue with zynq devices (I remember solving it in some way with some tcl when I was using VHDL): `WARNING: [DRC ZPS7-1] PS7 block required: The PS7 cell must be used in this Zynq design in order to enable correct default configuration.
<DaKnig> `
<DaKnig> yeah whitequark I still get the error `... File /tmp/nmigen_kgb1wheq_top.bit not found ...`
<DaKnig> with batch mode instead of tcl
<_whitenotifier-b> [YoWASP/] whitequark pushed 1 commit to master [+0/-0/±1]
<_whitenotifier-b> [YoWASP/] whitequark ba02b41 - Fix typo
<whitequark> DaKnig: ok that's annoying, i don't have any way to solve this offhand, sorry
<whitequark> i mean you could obviously copy it elsewhere
<DaKnig> but can I get the original file's location somehow?
<DaKnig> the one before it is copied to /tmp/
<whitequark> nope, by design
<whitequark> i didn't realize that a programmer that always forks is something i'd have to deal with
<whitequark> or others would, in this case
<DaKnig> :(
Yehowshua has joined #nmigen
<DaKnig> I guess copying is not that bad
<whitequark> long term (i.e. to be merged in nmigen-boards), we should figure out how to make vivado not do that
<whitequark> and if there's absolutely no way to make vivado not do that, i guess we change the design
<Yehowshua> ktemkin, I programed TinFPGABX with the serial acm example. It shows up under `lsusb` with the vendor id and all, but does not enumerate in the device tree as an acm device. Checking the raw usb packets, I see that it send `bDeviceClass: Device (0x00)` in its descriptor packet. When restting to the default TinyFPGA ACM USB boot loader, that field
<Yehowshua> is `bDeviceClass: Communication and CDC Control (0x02)`
<DaKnig> I think that this design , where it "asserts dominance" as somebody somewhere else described it, on start even tho it doesnt require all those processes and resources or the whole internal machinery is dumb
<DaKnig> but then again Im the one who is stuck on CentOS 7 :)
<whitequark> is it dumb? or is it just solving a problem you don't anticipate having?
<DaKnig> the second, but not anticipating them was dumb on my part, but thats partly due to inexperience with linux... I thought that there would be a big difference that somehow centos7 would make a better platform
<whitequark> what it tries to prevent is the following: (1) you contribute a board with this toolchain_program() upstream, (2) someone tries to use it with remote builds, (3) they get sad
<whitequark> if remote builds work the same as local, it's not possible to write a function that doesn't work in that scenario
<whitequark> i just didn't anticipate that "not possible" is going to mean "vivado actually makes this not possible" rather than "the buggy function gets fixed earlier"
<DaKnig> ... I did not mean that the "dumb design" was on your part, I was just saying that vivado is inefficient
<whitequark> ohh
<DaKnig> sorry :)
<whitequark> oh yeah vivado is doing something weird
Yehowshua has quit [Ping timeout: 245 seconds]
daknig2 has quit [Ping timeout: 265 seconds]
<_whitenotifier-b> [nmigen] DaKnig opened issue #441: PS7 block not initialized on series-7 Zynq targets -