Vinalon has quit [Remote host closed the connection]
Vinalon has joined #nmigen
<awygle>
whitequark: for the "did you mean" message on https://github.com/nmigen/nmigen/issues/362 , is there a way to get the name they passed in so it can be a correct message?
<whitequark>
awygle: name? not really, no
<whitequark>
you can sorta guess it from the signal's name, but that can be misleading
<whitequark>
so i would use a placeholder
<awygle>
ok
<awygle>
that was basically what i assumed but figured i'd check since python has weird reflection capabilities
<awygle>
how is "(did you mean `ports=(<signal>,)`?)"
<whitequark>
yup
<_whitenotifier-9>
[nmigen] awygle opened pull request #366: Check type of `ports` argument to `convert` functions. - https://git.io/JfLvc
<_whitenotifier-9>
[nmigen] codecov[bot] commented on pull request #366: Check type of `ports` argument to `convert` functions. - https://git.io/JfLvl
<_whitenotifier-9>
[nmigen] codecov[bot] edited a comment on pull request #366: Check type of `ports` argument to `convert` functions. - https://git.io/JfLvl
<whitequark>
awygle: a list or a *string*?
<awygle>
..... motherfucker.
<_whitenotifier-9>
[nmigen] awygle synchronize pull request #366: Check type of `ports` argument to `convert` functions. - https://git.io/JfLvc
<_whitenotifier-9>
[nmigen] codecov[bot] edited a comment on pull request #366: Check type of `ports` argument to `convert` functions. - https://git.io/JfLvl
<awygle>
sorry. i'm not having a good day. thanks for catching that.
<_whitenotifier-9>
[nmigen] awygle synchronize pull request #366: Check type of `ports` argument to `convert` functions. - https://git.io/JfLvc
<_whitenotifier-9>
[nmigen] codecov[bot] edited a comment on pull request #366: Check type of `ports` argument to `convert` functions. - https://git.io/JfLvl
<_whitenotifier-9>
[nmigen] codecov[bot] edited a comment on pull request #366: Check type of `ports` argument to `convert` functions. - https://git.io/JfLvl
<_whitenotifier-9>
[nmigen] codecov[bot] edited a comment on pull request #366: Check type of `ports` argument to `convert` functions. - https://git.io/JfLvl
<_whitenotifier-9>
[nmigen] codecov[bot] edited a comment on pull request #366: Check type of `ports` argument to `convert` functions. - https://git.io/JfLvl
<_whitenotifier-9>
[nmigen] codecov[bot] edited a comment on pull request #366: Check type of `ports` argument to `convert` functions. - https://git.io/JfLvl
<_whitenotifier-9>
[nmigen] codecov[bot] edited a comment on pull request #366: Check type of `ports` argument to `convert` functions. - https://git.io/JfLvl
<awygle>
take a chill pill, codecov
<awygle>
ok, fixed.
<cr1901_modern>
I think this is specific to how wq has notifications set up (does codecov even provide an IRC bot)?
<awygle>
it's nbd it just amused me
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
grant72 has joined #nmigen
Degi has quit [Ping timeout: 240 seconds]
<awygle>
grant72: hello!
<grant72>
howdy!
Degi has joined #nmigen
grant72 has quit [Read error: Connection reset by peer]
grant72 has joined #nmigen
grant72 has quit [Ping timeout: 250 seconds]
grant72 has joined #nmigen
grant72 has quit [Quit: Lost terminal]
<whitequark>
wtf, i thought i turned that off
<cr1901_modern>
I mean the results of running codecov I think are useful messages. Maybe not the edit ones.
FFY00 has quit [Remote host closed the connection]
FFY00 has joined #nmigen
FFY00 has quit [Remote host closed the connection]
<awygle>
Ah, fair points all. Although the "not at the top" was only so I could be under the "ports isn't none" if statement that already existed. Fixed tomorrow.
thinknok has joined #nmigen
thinknok has quit [Ping timeout: 272 seconds]
____ has joined #nmigen
thinknok has joined #nmigen
kernelmethod has joined #nmigen
kernelmethod has quit [Client Quit]
_whitelogger has joined #nmigen
thinknok has quit [Remote host closed the connection]
thinknok has joined #nmigen
chipmuenk has joined #nmigen
Asu has joined #nmigen
Vinalon has quit [Ping timeout: 256 seconds]
cyberclown has quit [Remote host closed the connection]
cyberclown has joined #nmigen
thinknok has quit [Ping timeout: 272 seconds]
thinknok has joined #nmigen
thinknok has quit [Ping timeout: 272 seconds]
thinknok has joined #nmigen
chipmuenk1 has joined #nmigen
chipmuenk has quit [Ping timeout: 256 seconds]
chipmuenk1 is now known as chipmuenk
Vinalon has joined #nmigen
cyberclown has quit [Remote host closed the connection]
<_whitenotifier-9>
[nmigen-boards] WRansohoff opened pull request #60: Board file for Lattice's `ICE40UP5K-B-EVN` breakout board - https://git.io/JfLPl
<grant72>
I'm working on MacOS, and i'm thinking it may be a Linux build.
<awygle>
i think (correct me if i'm wrong, wq) that symbiyosys is an optional dependency, or maybe even not a dependency at all (only yosys being needed, and then only for some backends)
<whitequark>
symbiyosys is not a hard dependency unless you want to run the complete testsuite
<whitequark>
if you only want to use nmigen (or even contribute to most parts of it), you just need yosys
<awygle>
i also don't know that symbiyosys even needs suprove if you're not going to use the suprove backend
<whitequark>
i don't think it does
<whitequark>
i sure don't have it, nor does our CI
<awygle>
you only need one of the SMT solves
<awygle>
(Z3, yices, boolector, suprove, avy)
<awygle>
Z3 is the most commonly used but the nmigen test suite defaults to yices
<awygle>
so that's what i'd recommend
<awygle>
"Yosys, SymbiYosys, and Z3 are non-optional. The other packages are only required for some engine configurations."
<grant72>
Ok! I think that may be some good information to have in the tutorial
<awygle>
grant72: why don't you file an issue on the tutorial repo, perhaps with some suggested verbage?
<awygle>
i don't think robert baruch hangs out in here so he's more likely to see it there
<whitequark>
(there isn't an "official" tutorial... yet)
<awygle>
whitequark: FYI i recruited grant72 as a contributor from an HDL discord, they were looking for a project to contribute to and I suggested nmigen
<whitequark>
ah cool! what kind of contribution?
<grant72>
I was looking to do documenation right now. I was thinking as I learn the project, I might as well write it down :P
<whitequark>
ah, that's also something I'm working on right now
<whitequark>
I should be able to push something you can use soon
<grant72>
I'd rather not step on any toes, so just let me know. Otherwise, I'll just keep working through the unofficial tutorial and adding comments on it for now.
<whitequark>
I'm working on infrastructure for the docs right now, plus a few running notes on the internals of the simulator (which are really something I'm not sure if anyone except me fully understands at the moment)
<whitequark>
there *is* a way you could help, though
<whitequark>
and you're pretty much doing it already, but, just to be more explicit: I am *very* interested in the view a new-to-nmigen programmer has of the language
<whitequark>
since this should inform the way documentation will be written, and to a lesser extent language design
<grant72>
So after learning a bit of the language, you'd like to know how I think about using it?
<_whitenotifier-9>
[nmigen] awygle synchronize pull request #366: Check type of `ports` argument to `convert` functions. - https://git.io/JfLvc
<_whitenotifier-9>
[nmigen] codecov[bot] edited a comment on pull request #366: Check type of `ports` argument to `convert` functions. - https://git.io/JfLvl
<whitequark>
yes, absolutely
<whitequark>
as someone who wrote more or less the entirety of the current compiler, I have long lost the perspective of a beginner
<whitequark>
yet, it is this perspective which the documentation should be geared towards
<whitequark>
plus, if you discover a new footgun (hopefully not!), I get an opportunity to fix it for everyone else
<grant72>
Makes sense to me. Have most other members of nmigen been working on the project for a while?
<_whitenotifier-9>
[nmigen] awygle synchronize pull request #366: Check type of `ports` argument to `convert` functions. - https://git.io/JfLvc
<_whitenotifier-9>
[nmigen] codecov[bot] edited a comment on pull request #366: Check type of `ports` argument to `convert` functions. - https://git.io/JfLvl
<grant72>
Ok. I'll probably spend some time getting familiar with the tool and let you know.
<grant72>
I also noticed that the tutorial is Linux focused - it may be nice to have the relative directions for Mac and Windows
<grant72>
Well, the install portion of it
<whitequark>
macOS is relatively easy, just needs to be done by someone familiar with the OS
<whitequark>
Windows is unfortunately not quite as good as I wish it was
<whitequark>
installing Yosys is still a problem
<whitequark>
I *will* solve this on the nMigen side, but it will take time
<awygle>
what's the issue with installing yosys on windows?
<whitequark>
currently nmigen requires yosys master.
<awygle>
... actually i guess i've never tried outside cygwin which is _definitely_ not supported lol
<whitequark>
so you have to build it. that is... not trivial
<whitequark>
cygwin is definitely not supported
<awygle>
yup, so nvm me
<whitequark>
I'm going to ship a Yosys binary wheel on PyPI either as WASM or as native binaries
<whitequark>
at some point
<whitequark>
it's just a huge pain
<awygle>
brb, gonna rewrite yosys entirely in rust so the cross-platform story is easier
<whitequark>
I did compile it targeting WASI
<whitequark>
no abc, but nmigen doesn't need that
<awygle>
didn't rqou build it against emscripten?
<whitequark>
WASI is a *lot* better
<awygle>
WASI seems very cool
<whitequark>
there are existing libraries that just run WASI stuff on Python
<awygle>
Someday (TM) i'll have both time and a reason to play with it
<whitequark>
even on Windows
<whitequark>
and with JIT compilation too
<awygle>
sweet
chipmuenk has quit [Quit: chipmuenk]
<grant72>
Well with the tutorial, it does say to only install the following: yosys, Symbiyosys, yices2, boolector - but Z3 was mentioned?
<_whitenotifier-9>
[nmigen] codecov[bot] edited a comment on pull request #366: Check type of `ports` argument to `convert` functions. - https://git.io/JfLvl
<_whitenotifier-9>
[nmigen] codecov[bot] edited a comment on pull request #366: Check type of `ports` argument to `convert` functions. - https://git.io/JfLvl
<awygle>
i think Z3 used to be required for symbiyosys but may not be anymore
<whitequark>
that part of the tutorial is a bit misleading
<whitequark>
I'd really love to get to a point where all you need for nMigen is pip
<whitequark>
(as a baseline; it'll be a bit slower)
<awygle>
whitequark: re: https://github.com/nmigen/nmigen/issues/181, should the "i have been reset" signal (proposed name: r_rst) be delayed by a cycle for AsyncFIFOBuffered?
<_whitenotifier-9>
[nmigen] codecov[bot] edited a comment on pull request #366: Check type of `ports` argument to `convert` functions. - https://git.io/JfLvl
<_whitenotifier-9>
[nmigen] codecov[bot] edited a comment on pull request #366: Check type of `ports` argument to `convert` functions. - https://git.io/JfLvl
<whitequark>
awygle: ack on r_rst. good question re delay.
<awygle>
r_rdy is delayed, so it seems like r_rst should be
<whitequark>
it should arrive in sync with the other signals
<whitequark>
yeah
<awygle>
yeah ok
<_whitenotifier-9>
[nmigen] awygle opened pull request #367: Implement r_rst output signal for AsyncFIFO - https://git.io/JfLyG
<grant72>
Would it be a good idea to just have the install instructions for the dependencies (yosys, Symbiyosys, yices2, boolector) located within the README itself?
<whitequark>
grant72: the nmigen README currently does link to the Yosys README; it would be unfortunate to copy the instructions because they might well change in the future, and because they're bulky
<awygle>
links to them would make sense, but i don't think duplicating the information is a good idea since they'd get out of sync
<whitequark>
hm, it actually doesn't
<awygle>
the Yosys link isn't to the README, and it's a bit buried
<awygle>
could use a bit of expansion there
<awygle>
... okay i'm gonna start delaying typing by 30 seconds so i stop repeating whitequark immediately afterwards >_>
<grant72>
Links to each dependency's github may be good along with the symbiyosys instructions
<whitequark>
annoyingly I don't remember if we still support yosys 0.9 or if master is required
<whitequark>
I think 0.9 has some severe bug?
<awygle>
if we specifically require master the 12F ECP5s will Just Work... :p
<whitequark>
uhm, no
<awygle>
(this is a bad reason)
<whitequark>
nmigen only depends on yosys directly for verilog conversion
peeps[zen] has joined #nmigen
<awygle>
yeah that's not a yosys thing
<awygle>
it's a nextpnr thing
<whitequark>
the WASI yosys would be a super cut down thing that only really has like 5 passes
<whitequark>
well, cxxrtl too, later
peepsalot has quit [Ping timeout: 265 seconds]
<_whitenotifier-9>
[nmigen/nmigen] whitequark pushed 1 commit to master [+0/-0/±1] https://git.io/JfLy0
<_whitenotifier-9>
[nmigen/nmigen] whitequark fd7f69f - README: link directly to Yosys build instructions.
<awygle>
is the architecture of yosys "hdl->rtlil frontend", "passes on rtlil", "techmap pass", done?
<awygle>
that's my essential understanding
<whitequark>
awygle: "hdl/il backend"
<whitequark>
but yeah
<whitequark>
it's a pretty conventional batch compiler
<mwk>
WASI?
<whitequark>
POSIX-ish API for WASM
<whitequark>
not as awful as POSIX though, it uses capabilities and stuff
<whitequark>
basically gives you stdio
<_whitenotifier-9>
[nmigen] codecov[bot] edited a comment on pull request #366: Check type of `ports` argument to `convert` functions. - https://git.io/JfLvl
<mwk>
awygle: techmap is not a single pass, it's run multiple times in a iven synth flow
<mwk>
the architecture of yosys is it has a lot of passes
<awygle>
"iven"?
<awygle>
oh given
<whitequark>
*slaps roof of yosys* this bad boy can fit so many passes in it
<mwk>
.. yes
<whitequark>
*slaps roof of yosysjs* not quite so many here
<mwk>
run a frontend, run some preparation passes, then run "coarse" optimization passes (not tech-dependent), techmap a bit, run some more opt on what's left, techmap a bit more, ...
<awygle>
whitequark: how long are lines allowed to be in nmigen? seems to be longer than 79 characters
<whitequark>
mwk: yup, awesome
<mwk>
I imagine you'd want to emit whatever cells we end up with directly instead of relying on whatever inference rules we think of for verilog
<whitequark>
awygle: 100 columns
<awygle>
mk
<whitequark>
I'd put it in .editorconfig but it can't do that
<whitequark>
mwk: I already do emit $memrd
<whitequark>
hm
<mwk>
(though that's scheduled for when I'm done with FF stuff, and *that's* scheduled for when I'm done with uni stuff...)
<whitequark>
like, nmigen doesn't need memory_rmdff
<mwk>
whitequark: the model may change though
<whitequark>
memory_nordff?
<whitequark>
mwk: that sucks somewhat (since nmigen relies on RTLIL) but not too much (since it can adapt to changes)
<mwk>
I mean, we don't currently have eg. read+write port, right?
<whitequark>
see, times like this are when I wish I could use FIRRTL...
<whitequark>
hmm
<whitequark>
neither does nmigen, at the moment
<mwk>
right
<whitequark>
but I agree it would be ideal to have that for SPRAM inference
<whitequark>
what *somewhat* worries me is the potential combinatorial explosion here
<whitequark>
are we going to get a TDP primitive?
<mwk>
I'd go for a "port" primtiive really, like we currently have
<mwk>
except we'd like to have a read+write one as well
<whitequark>
that sounds quite good to me
<whitequark>
lemme see the FIRRTL spec
<daveshah>
So removing $mem and just working with ports?
<daveshah>
that sounds like it might clean things up a bit
<sorear>
even a single port has quite a few combinations
<whitequark>
agreed. IIRC I asked Claire why she added $mem at all
<whitequark>
an the answer was something like "today I would have connected $memrd, $memwr and $meminit with a fake wire"
<whitequark>
which is... not satisfying
<whitequark>
ah wait, might have been something ele
<whitequark>
that was about \MEMID perhaps?
<whitequark>
and $mem exists because it encodes things such as port priorities explicitly?
<whitequark>
I really don't like having two representations though
<mwk>
*shrug*
<mwk>
tbh I don't quite now what the design will look like
<mwk>
there's things I still don't know about the current state of things and I'd rather learn how the whole thing works before blowing things up and making the same mistakes
<whitequark>
want to look at #217 while you're looking at FIFOs? :)
<awygle>
looking at it now
<awygle>
but i don't have an immediate solution, so it's gonna take some work
<whitequark>
it's... quite theoretical, I admit
<whitequark>
but Xilinx does seem to have put in the effort to fix it
<whitequark>
meaning it's not totally out there
<whitequark>
AsyncFIFO is always FWFT, so if you have some safety critical logic tacked onto r_data, you might find it behave incorrectly, in principle.
<whitequark>
the MTBF on that gotta be huge.
<awygle>
i think the Xilinx solution of "all AsyncFIFO are buffered, deal with it" is not unreasonable
<whitequark>
mhm
<whitequark>
it feels unsatisfying, somehow
<whitequark>
plus we have Migen compat
<_whitenotifier-9>
[nmigen] awygle commented on issue #355: [RFC] Redesign UserValue to avoid breaking code that inherits from it - https://git.io/JfLHS
<_whitenotifier-9>
[nmigen] whitequark commented on issue #355: [RFC] Redesign UserValue to avoid breaking code that inherits from it - https://git.io/JfLHx
<awygle>
hm. how is AsyncFIFOBuffered different from a (hypothetical) AsyncFIFO with fwft=False?
<whitequark>
fwft stuff is something we kinda inherited
<whitequark>
originally, there was Migen SyncFIFO, and fwft changed the type of Xilinx memory port macro it would use
<whitequark>
so in one case you got LUTRAM (I think?) and in the other BRAM
<whitequark>
and it was just kinda convenient so everyone went with it *even though the type of FIFOInterface is totally different depening on fwft!!*
<whitequark>
I mean, same signals, same sizes, but different semantics. infuriating.
<whitequark>
I tried to fix this in the docs, to some extent.
<awygle>
whitequark: actually, i am kind of convincing myself that the Clifford Cummings FIFO #2, as implemented in his SNUG2002 paper, does not actually have the problem described by #217
<whitequark>
ooh?
<awygle>
see section 5.3.4
<awygle>
specifically the final paragraph
<awygle>
the r_empty signal is synchronized into the rclk domain. this means that any settling that needs to happen from the BRAM output will be finished by the time the rclk domain believes valid data exists
<whitequark>
yes, that's not the issue
<whitequark>
there is no logical issue in the sense of rdomain using bad data
<whitequark>
there *is*, IMO, a physical issue in which r_data would sometimes end up in metastable state
<whitequark>
which means that downstream logic connected to it, *even if it is disabled*, could still glitch
<whitequark>
(e.g. because r_data is gated with LUTs or something like that)
<whitequark>
the way i see this is that CDCs have an invariant where neither-0-nor-1 values have to go through 2FFs to become safe again (or more if you're paranoid)
<whitequark>
and in case of AsyncFIFO such values only go through 1FF
<whitequark>
(the r_data register)
<whitequark>
meaning that connecting arbitrary logic to r_data is, fundamentally speaking, unsafe. you can only really connect a register to it
<whitequark>
(if you want the CDC to be properly synchronized)
<awygle>
i do understand what you're saying. i guess the point i was making is that any use of the glitched values would be in violation of the FIFO contract. i suppose i could imagine such glitched values causing issues in two cases - 1) ASICs, 2) when they're connected directly to ports
<whitequark>
the problem is that the FIFO contract is purely synchronous
<whitequark>
the FIFO contract, like the contract of any other nMigen synchronous logic, states that the output of a module is always a stable 0 or 1 value
<whitequark>
implicitly, because everything in nMigen that isn't an Instance or a stdlib primitive has that contract
<whitequark>
from this point of view, it is the FIFO that is violating the FIFO contract
<awygle>
i see your point but i don't believe it could ever cause problems (absent the two scenarios above). but ok, let's think about how to fix it
<awygle>
could we put the buffer flop on the r_data output and interlock around it in the case that r_empty is not true?
<awygle>
it won't add any delay to the empty case, because r_empty already has a 2FF synchronizer on it
<whitequark>
awygle: i think we can just disable r_en on empty FIFO
<whitequark>
re "could ever cause problems": one of my dreams is having tsan for FPGAs
<awygle>
don't we already do that?
<whitequark>
it's possible that cxxrtl could some day do this
<whitequark>
i already know how i want to do clock trees and how can i find nasty race conditions in benches automatically
<whitequark>
awygle:
<whitequark>
r_port.en.eq(1),
<awygle>
ah no we don't
<awygle>
because it's always fwft
<whitequark>
yea
<awygle>
ok, that's easy enough to do.
<awygle>
and it's comb so it doesn't add delay
<awygle>
whether it _works_ depends on the semantics of $memrd at a fairly deep level
<awygle>
but i think it will...
<whitequark>
you mean, whether disabling the E input of a DFFE implied in $memrd is enough to mitigate the CDC hazar?
<awygle>
yeah
<whitequark>
I agree that this is also a concern
<whitequark>
I would think that every sane cell library provides that, but ready to be proven wrong
<awygle>
true, but at some point we can only cater to so much insanity
<awygle>
i am pleased with this solution
<whitequark>
in general, what I'd like to have is some sort of slightly formal semantics for CDC that actually takes into account the physical effects instead of just telling people to "linter this" and "add delta cycles that"
<whitequark>
for example, cxxrtl has races around clock gating circuits, like you'd expect in VHDL. i will not be either guaranteeing specific delta cycle counts (the VHDL solution) nor adding blocking assignments / pending tasks (the Verilog solution)
<awygle>
that's gonna be challenging as i think it would have to know the implementations. it severely limits the amount of abstraction which can be provided in a non-leaky way.
<whitequark>
can you be more specific? not sure which part you refer to
<whitequark>
well
<whitequark>
I think I oversold you on "physical effects"
<awygle>
probably :p
<awygle>
i agree with not cargo-culting advice, and actually providing rationales
<whitequark>
I really mean I want a type system that can answer the question "are these two clocks in phase" based on some attributes of your design
<awygle>
ahhhh
<whitequark>
and can then use *that* to tell you whether other parts of your design are safe or not
<awygle>
yeah that would be nice (and seems way more in your wheelhouse than mine)
<whitequark>
it doesn't actually seem hard
<whitequark>
I've thought about doing this for cxxrtl because cxxrtl needs that to be faster
<awygle>
not especially, no, but i'm not very informed in the area so i may be underestimating
<whitequark>
the main problem is instances
<whitequark>
you're gonna have to annotate every port.
<awygle>
every time you say that i imagine the architect from the matrix
<whitequark>
it's the typescript problem all over again
<whitequark>
heh
<awygle>
well, the legendary frog version
<awygle>
"the problem is choice!"
<whitequark>
so you'll be basically writing "type declarations" for "untyped verilog interfaces" if we end up with that kinda type system
<awygle>
it seems like you could assume the instance is synchronous to the clock input you pass it, unless otherwise specified, but that may beeeeeeeeeeeeeeeeeeeeeee too implicit
<awygle>
... thanks bluetooth keyboard
<whitequark>
you know, it's kind of ridiculous there is no actual machine readable way to say "this clock input and this async reset input form a clock domain", isn't it
<awygle>
yes
<whitequark>
so cxxrtl already infers that knowledge from your use of primitives, to a degree
<whitequark>
seeing how similar its innards are to cxxrtl, i bet verilator does, also
<awygle>
anyway. you want i should do the `r_port.en.eq(~r_empty)` thing?
<whitequark>
yep please
<awygle>
kk
<whitequark>
you'll discover why i asked you to do it
<awygle>
... eh?
<whitequark>
try running the formal tests
<_whitenotifier-9>
[nmigen] awygle opened pull request #369: AsyncFIFO: disable read from dual-port Memory when FIFO empty - https://git.io/JfL76
<awygle>
oh
<awygle>
i... should have done that
<awygle>
duh
<_whitenotifier-9>
[nmigen] codecov[bot] commented on pull request #369: AsyncFIFO: disable read from dual-port Memory when FIFO empty - https://git.io/JfL7A
<_whitenotifier-9>
[nmigen] codecov[bot] edited a comment on pull request #369: AsyncFIFO: disable read from dual-port Memory when FIFO empty - https://git.io/JfL7A
<_whitenotifier-9>
[nmigen] codecov[bot] edited a comment on pull request #369: AsyncFIFO: disable read from dual-port Memory when FIFO empty - https://git.io/JfL7A
<_whitenotifier-9>
[nmigen] codecov[bot] edited a comment on pull request #369: AsyncFIFO: disable read from dual-port Memory when FIFO empty - https://git.io/JfL7A
Asu has quit [Remote host closed the connection]
<_whitenotifier-9>
[nmigen] awygle edited pull request #369: [WIP] AsyncFIFO: disable read from dual-port Memory when FIFO empty - https://git.io/JfL76
<awygle>
okay, i think i know what needs to be done here but i'm out of juice for today.
<whitequark>
thanks for the effort!
<awygle>
no problem
<awygle>
thanks for giving me something controllable to focus on :p