<cr1901_modern>
xor led_val, stx led_val, then nop sled until incomplete addr decoding goes back to addr 0. Control blink freq by nop sled size?
<whitequark>
cr1901_modern: yeah, that's an obvious solution
<whitequark>
btw i've heard of a router that has the initial led blink implemented like that
<whitequark>
fiveor so iterations
<cr1901_modern>
There's an SBC optimized for embedded Javascript that also used that trick (minus the wraparound) as the hello world
<whitequark>
disgusting
<cr1901_modern>
don't remember the name of the board tho
<whitequark>
espruino?
<cr1901_modern>
That sounds right; might've been an earlier revision. Looks like the blinky now is... relatively less horrible: https://www.espruino.com/Flashing+Lights
<cr1901_modern>
setInterval, which contains an string to eval() that executes after a timer fires
<cr1901_modern>
yep
<cr1901_modern>
or maybe it's more horrible. Idk
<cr1901_modern>
In the example I was thinking of, Javascript NOPs are introduced via whitespace :). The more whitespace you have between led.on() and led.off() the longer the interval!
<whitequark>
yeah, it's awful
cr1901_modern1 has joined #m-labs
cr1901_modern has quit [Ping timeout: 248 seconds]
<cr1901_modern>
whitequark: Btw, there's some sort of problem in nmigen where if I do an NMIGEN_* env var override from an msys2 prompt, and try to actually to a build from said prompt, the env vars won't be propogated to the child cmd.exe. I will file a PR and/or bug when I know more, because right now I cannot sink the time into this
<cr1901_modern>
I'm just gonna eat that some things will be a bit inconvenient for me personally for now
<cr1901_modern>
I've known about this bug for a month, btw. Just, again, things are hectic. I'll do my part :).
<whitequark>
cr1901_modern: I think they aren't supposed to propagate?
<whitequark>
the NMIGEN_ vars only affect the *generation* of the script
<whitequark>
if the script itself depends on NMIGEN_ env vars it's generally a bug
<cr1901_modern>
Oh that's interesting... this came up last month when I was trying to disable the heap placer for nextpnr since (at the time) I didn't have it. I couldn't get NMIGEN_NEXTPR_OPTS to disable the heap placer.
<cr1901_modern>
Anyways, good to know.
<cr1901_modern>
I'll take another look
<whitequark>
cr1901_modern: it might be a different bug
<whitequark>
or whatever the cmd equivalent of it is
<whitequark>
oh I remember, there was a quoting issue... might be that again?
<whitequark>
anyway, Windows is a first-class platform for nmigen so this should be fixed
* cr1901_modern
nods
<cr1901_modern>
Also keep in mind I don't have a typical system even for a Windoze user. I absolutely 100% believe that cmd.exe should be sufficient to get started w/ nmigen/migen/etc. For convenience's sake I still use a bash prompt.
<cr1901_modern>
I'm okay if whatever the bug is ends up being "user's setup is out of scope". B/c it's not possible to cover every possible "Windoze and Unix coexisting on the same system" quirk
<cr1901_modern>
s/user's setup/MY setup/
<whitequark>
does nextpnr even build not on msys? (I think it should, but...)
<daveshah>
It has definitely been tested with Visual Studio in the past
<cr1901_modern>
Requiring msys to build != "can't use on a vanilla system"
<daveshah>
From memory Python was a bit of a pain but everything else is fine
<whitequark>
yeah Python was what I'm worried about
<whitequark>
well, alright
<cr1901_modern>
msys is annoying in the sense that if you want a portable package to "just install" on a user's system, you have to also supply some cygwin guts (like libgcc, unless you use -static-libgcc). But it's nothing that's stopped me before.
<cr1901_modern>
At some point tho it probably becomes more convenient to just eat the cost of installing msys (unless packaging all of yosys/nextpnr/icestorm/trellis deps into a zip file that a user downloads becomes feasible)
<cr1901_modern>
I'm pretty close to submitting yosys/nextpnr/icestorm-git pkgs to MINGW-packages
<cr1901_modern>
whitequark: NMIGEN_VERBOSE is an env var, right?
<whitequark>
NMIGEN_verbose
<whitequark>
it's case sensitive
<whitequark>
> (unless packaging all of yosys/nextpnr/icestorm/trellis deps into a zip file that a user downloads becomes feasible)
<whitequark>
I need that for glasgow anyway
<daveshah>
I think micko is working on that for platformio
<daveshah>
It won't include the GUI though iirc
<cr1901_modern>
I hope there's a "I know what I'm doing" override if he does that
<cr1901_modern>
I want to use my own personal copies of nextpnr, yosys, etc.
<whitequark>
hm, I might want to take a look at platformio some day
<cr1901_modern>
And the GUI works fine from msys minus Optimus bullshit
<daveshah>
I understand there is various work in progress to improve HDL/FPGA stuff in PlatformIO
<daveshah>
It seems like a very nice way to make the tools more accessible
<cr1901_modern>
My main point in favor of requiring msys2 for yosys is while yosys in principle does build on Visual Studio, you lose most of the features. And I've gotten a vast majority of features to work on yosys from msys2 with pretty minimal effort.
<whitequark>
most of the features? like what?
<cr1901_modern>
TCL, ABC, GLOB, PLUGINS, READLINE
<cr1901_modern>
COVER
<daveshah>
I don't think these PlatformIO builds will use Visual Studio in any case
<cr1901_modern>
I could most likely get libyosys and protobuf to work, but I haven't had incentive to try :P
<whitequark>
also, there's "just mingw" as opposed to "msys2" and "vs"
<cr1901_modern>
mingw is a 32-bit only compiler
<whitequark>
mingw64 obviously
<daveshah>
There's also cross mingw64
<whitequark>
(or just building it with clang, same difference)
<whitequark>
what i mean is that if tcl doesn't build on vs (though that sounds weird), you don't need to pull in all the posix junk
<daveshah>
Which I think is how the apio tools are built
<cr1901_modern>
Sure, msys is just convenient :P. I also don't blame micko is he doesn't build the GUI. Qt is moderately well-behaved build, but not something I want to do repeatedly
<whitequark>
it just seems superfluous for platformio purposes
<daveshah>
It's the Qt and OpenGL combo that's a bit of a pain
<daveshah>
Indeed
<whitequark>
i'm actually not sure what is the gui useful for
<whitequark>
not in perspective, but right now
<daveshah>
Mostly debugging tbh
<daveshah>
Looking at placer and router behaviour
<daveshah>
Agree it has little end user value right now
<cr1901_modern>
Also, I can't speak for mingw64. Only msys. But I recently had to build a python with debugging symbols. Knowing a visual studio Python had the same bug I wanted to tackle. I wanted to avoid the large number of patches that msys2 provides to the python tarball
<cr1901_modern>
it turns out, you actually need quite a few of them otherwise your build will surely fail
<cr1901_modern>
There's a lot of *nix/Windoze path-handling stuff that the vanilla python tarball just doesn't handle, and the ./configure step is POSIXy enough that it causes a number of compile-time mismatches
<cr1901_modern>
after applying about 5 patches manually, I said screw it and did it the right way (TM) using pkgbuild.
<cr1901_modern>
Even if you want to create a Python that only deals with Windoze paths, I have no idea if there are problems calling into a visual-studio compiled python/libffi from code compiled w/ gcc or g++ with extern "C".
<cr1901_modern>
They're _supposed_ to be compatible ABIs AIUI, but it's not a time sink I've really had time to get into.
<benreynwar>
whitequark: Can I use records or arrays as ports in nmigen? I'm getting an error when I try to.
<whitequark>
benreynwar: arrays: definitely not
<whitequark>
records: records are lowered to separate constituent signals
<whitequark>
so using a record as a port could, in principle, mean adding each of the signals as a port, but that has weird corner cases...
<whitequark>
like for example you want a name for that port for some external tool. what next?
<whitequark>
so I think it is only appropriate to use signals as ports, and a record can be easily grouped into a signal for that
<benreynwar>
whitequark: I was expecting arrays to produce verilog names like mysignal__0 and mysignal__1, and records to produce verilog names like mysignal__firstkey, mysignal__secondkey. But really, I'm not worried about using arrays and records at the top interface, but I would like to be able to use them as ports for nmigen modules that will be instantiated by other nmigen modules. In nmigen should I be building a hierarchy of
<benreynwar>
modules like I would in verilog or VHDL?
tweakoz has joined #m-labs
<whitequark>
benreynwar: arrays don't do that to avoid unnecessary wires (you have to build a mux each time you index an array, anyway) and records do exactly that
<whitequark>
however, what are you doing so that you have a port-related error when building a hierarchy of modules internally in nmigen?
<benreynwar>
I got the error for a top level port. I guess even for internal modules I'll want to generate verilog for them so that I can run simulations with verilator.
<whitequark>
sure, but nmigen modules don't have explicit ports
<whitequark>
you simply use the signal anywhere in the hierarchy you need it
<cr1901_modern>
whitequark: "nextpnr-ice40 --quiet - - p l a c e r s a --log top.tim --up5k --package sg48 --json top.json --pcf top.pcf --pre-pack top_pre_pack.py --asc top.asc || exit /b"
<cr1901_modern>
this is what I get. lmao
<whitequark>
cr1901_modern: wtf, give me a moment
<cr1901_modern>
From NMIGEN_nextpnr_opts="--placer sa" python3 -m nmigen_boards.icebreaker, modified to not actually do the build but just emit the files
<benreynwar>
whitequark: Thanks for the help.
<whitequark>
benreynwar: unlike in verilog, you can drive a signal from multiple modules, too
<whitequark>
(this flattens the hierarchy)
<whitequark>
(and emits a warning, because this can get pretty confusing, but it's useful in a pinch0
<cr1901_modern>
Also happens with export NMIGEN_nextpnr_opts="--placer sa". Anyways, at least it's a different bug.
<whitequark>
cr1901_modern: ok, i figured it out
<whitequark>
this is a problem with every _opts variable
<whitequark>
you should file a bug about it... the fix is to replace join(" ") with a new primitive
<whitequark>
something like options()
<whitequark>
that would understand that strings, although they are iterable, should not be joined
<whitequark>
or i guess i could just fix it
<cr1901_modern>
Will do now
<benreynwar>
Just to motivate having Array ports with an example. A decoder might take a bunch of soft bits as inputs, where the each soft bit's probability is represented by 5 bits. That's nicely represented by an array of 5 bit vectors. But, you're right that I wouldn't want each of the soft bits to be a separate signal.
<whitequark>
benreynwar: the thing is that Verilog doesn't support array ports
<whitequark>
(SystemVerilog does, but Yosys doesn't really support SV in any meaningful way)
<whitequark>
(nor do most other FOSS tools anyway)
<whitequark>
if Yosys ever adds first class support for array ports (i.e. it happens in RTLIL) then of course nMigen could do it
<benreynwar>
OK. That makes sense.
tweakoz has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<_whitenotifier-3>
[nmigen] cr1901 opened issue #130: `NMIGEN_` `overrides` are incorrectly emitted in output scripts. - https://git.io/fjiLg
<_whitenotifier-3>
[nmigen] whitequark commented on issue #130: `NMIGEN_` `overrides` are incorrectly emitted in output scripts. - https://git.io/fjiL2
<_whitenotifier-3>
[m-labs/nmigen] whitequark pushed 1 commit to master [+0/-0/±5] https://git.io/fjiLV
<cr1901_modern>
>(5:22:50 PM) whitequark: cr1901_modern: I think they aren't supposed to propagate
<cr1901_modern>
This is what I concluded as well. What I think I'll do is just manually create shell scripts to source the vars I care about and then run a subshell if I want to build from nmigen in an bash prompt, but I don't have the tools on my path
<cr1901_modern>
I don't want to pollute my env w/ the xilinx crap by default
<cr1901_modern>
Ahh shit this doesn't work either
<whitequark>
hmm, that seems troublesome
<cr1901_modern>
I have a possible solution
<whitequark>
what about this: we change build.bat (and maybe build.sh?) to extend the PATH with a predefined variable
<whitequark>
for example TOOLCHAIN_PATH
<whitequark>
and *that* one would be manually propagated to subprocesses
<cr1901_modern>
I had a similar idea, but rather have the user point to the source script they want to run
<whitequark>
hm?
<cr1901_modern>
before they build
<whitequark>
ah, I see
<whitequark>
that's actually more flexible
<cr1901_modern>
i.e. Xilinx doesn't just set PATH
<whitequark>
I like it more
<whitequark>
how do you source a file in bash?
<cr1901_modern>
what needs to happen here is that the sourcing needs to happen _after_ we called into cmd.exe
<cr1901_modern>
if you're running a batch script and you invoke "call my_script", you'll get the env vars you need propogated back to your cmd.exe instance
<whitequark>
oh, TIL
<whitequark>
ok
<whitequark>
give me a sec
<whitequark>
how do you check if a variable is not empty in bash?
<whitequark>
like [ -n "$FOO" ]
<whitequark>
er
<whitequark>
in cmd*
<cr1901_modern>
I don't... this came up last month