<lkcl>
sb0, whitequark: found the issue. when SyncFIFO is used with fwft=False, the data is not properly in sync with the SyncFIFO's readable/re signals. they're one clock apart.
<lkcl>
where it's possible to use comb assignment with SyncFIFO(fwft=True), it's *not* possible to do that when fwft=False.
<whitequark>
lkcl: you should read the documentation for `fwft`.
<lkcl>
i did.
<lkcl>
i recommend that to everyone on my team, so i do that all the time.
<whitequark>
lkcl: the documentation for SyncFIFO clearly describes the behavior you're talking about
<whitequark>
in particular:
<whitequark>
fwft : bool
<whitequark>
First-word fallthrough. If set, when the queue is empty and an entry is written into it,
<whitequark>
that entry becomes available on the output on the same clock cycle. Otherwise, it is
<whitequark>
necessary to assert ``re`` for ``dout`` to become valid.
<whitequark>
and
<whitequark>
For FWFT queues, [dout is] valid if ``readable`` is asserted. For non-FWFT queues, valid on the next
<whitequark>
cycle after ``readable`` and ``re`` have been asserted.
<lkcl>
yes.
<whitequark>
so what is the issue?
<lkcl>
we're developing a pipeline API.
<lkcl>
using SyncFIFO as a fan-in / fan-out buffer mechanism seemed like a good way to save writing extraneous code
<lkcl>
i was expecting it to be possible to combinatorially join two SyncFIFOs together (with some processing in between)
<lkcl>
and use the fwft capabilities to have the data go through if there's no stall, and pause if it's not
<lkcl>
it's odd. don't worry, i'll investigate some more. won't take up your time with this
<sb0>
whitequark: any udea about that rust elf32-big problem?
<sb0>
wtf is elf32-big anyway?
rjo has quit [Ping timeout: 252 seconds]
rjo has joined #m-labs
<whitequark>
sb0: sounds like it's compiled once with properly configured rustc and once with x86 rustc
<whitequark>
or maybe some other target
<whitequark>
but i'm not sure
<sb0>
so x86-rustc would create a "elf32-big" binary?
<whitequark>
it should be -little
<whitequark>
can you give me the files?
<sb0>
which files?
<whitequark>
those .o files
<whitequark>
with elf32-or1k and elf32-big
<sb0>
ok, moment
mauz555 has quit [Remote host closed the connection]
<sb0>
whitequark: oh i think i found the problem
<whitequark>
what was it?
mauz555_ has joined #m-labs
<sb0>
it seems nixos introduced some pass that patches .rlib files in a recent update, and that corrupted the .rlib's for or1k
<sb0>
still need to confirm that though
<whitequark>
ah yes, the worst part of nixos ruins everything...
<whitequark>
i wonder if guix has the same problem
<sb0>
yep that was it, it works now
<sb0>
in general, nixos works quite well IME
<whitequark>
nixos mostly achieves some impressive goals, but the crimes it has to commit for that make it a non-starter for me
<sb0>
to be more specific, the .rlib's were patched when packaged with the default options; that's not worse than what many other package managers are doing
<whitequark>
i mean that you need binary patching in general
<whitequark>
i don't consider it acceptable for a general purpose system
<whitequark>
that said, people resort to shipping docker images around, which is far worse than nixos, so it can be justified that way
<sb0>
does guix have better support for ABIs?
<sb0>
the binary patching isn't a *big* issue ime (and you can build FHS environments within NixOS, which lets you run unpatched binaries, and is very useful for stuff like vivado). but the recompilations/redownloads when some library changes are annoying indeed.
<whitequark>
i'm not sure, i need to look on guix closer
<lkcl>
sb0: debian did this in a reaaasonably sane way, they took binary-diffs on the package archives
<lkcl>
which are still chain-signed down the same web-of-trust
<lkcl>
so if you happen to have the previous archive package lying around, you get to save a hell of a lot of kb in downloads
<whitequark>
that's not the problem here
<whitequark>
the problem is hashes of dependencies being encoded into dependent packages
<whitequark>
so if glibc updates you need to rebuild literally everything
<lkcl>
argh...
<lkcl>
and they probably think it's a good "security" idea... *sigh*
<whitequark>
it has nothing to do with security
<lkcl>
oink? what on earth are they playing at, then??
<whitequark>
if you read anything about nixos before disparagingly commenting on it, you would know that
<whitequark>
but it's easier to talk shit on irc
<lkcl>
:)
<lkcl>
i may need to know a lot more about this, as the NLnet foundation, who have accepted our team for a grant, is funding nixos, i believe
<lkcl>
btw small change of subject (as you do on irc)
<lkcl>
a riscv core written in nmigen. with plans to adapt an auto-generator that creates a PLA-style instruction decoder
<lkcl>
well cool. an earlier version is in verilog (kcp35030), and the author will be using the exact same "spec" file, writing a nmigen-generation option
<whitequark>
i haven't been able to take a close look at it yet
<vup2>
ok no problem
kc5tja has joined #m-labs
<kc5tja>
Greetings everyone. I'm trying to model a combinatorial RS flip flop using nmigen, but running it through the simulator doesn't seem to produce any results. Is there any way to annotate a propegation delay through nmigen's logic? I suspect the simulation is failing because the simulation assumes 0-delay logic elements.