<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
<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) - https://git.io/JJce3
<_whitenotifier-b>
[nmigen-boards] ktemkin closed pull request #85: add resource helpers for USB (direct+ULPI) - https://git.io/JJce3
<_whitenotifier-b>
[nmigen-boards] ktemkin opened pull request #86: add resource helpers for USB (direct+ULPI) - https://git.io/JJcer
<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]
<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 - https://git.io/JJcU4
<_whitenotifier-b>
[nmigen] whitequark commented on issue #438: wrong type of buffer primitive used in series 7 - https://git.io/JJckw
<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)
<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) - https://git.io/JJcer
<_whitenotifier-b>
[nmigen-boards] ktemkin synchronize pull request #86: add resource helpers for USB (direct+ULPI) - https://git.io/JJcer
<_whitenotifier-b>
[nmigen-boards] whitequark closed pull request #86: add resource helpers for USB (direct+ULPI) - https://git.io/JJcer
<_whitenotifier-b>
[nmigen/nmigen-boards] whitequark pushed 1 commit to master [+0/-0/±6] https://git.io/JJcIM
<_whitenotifier-b>
[nmigen/nmigen-boards] ktemkin dd0bb11 - Factor out direct USB and ULPI resources.
<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.
<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 cxx.py. 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
<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 `cxx.py`
<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 dut.py`.
<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 nmigen.build 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
<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 nmigen.build 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 https://ftp.libre-soc.org/cxxsim.py
<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
<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 (alu_fsm.py) 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
<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
<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 - https://git.io/JJcZT
<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.
<ktemkin>
(you can ignore the lambdasoc soft-error; the setup.py 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 setup.py 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/simple_device.py)
<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.
<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/ simple_device.py 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>
acm_serial.py 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?
<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
<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/yowasp.github.io] whitequark pushed 1 commit to master [+0/-0/±1] https://git.io/JJcut
<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 - https://git.io/JJcgn