<lkcl>
aw god twitter recursion! it's as bad as the Beatles yellow submarine incident (sucked its own tail up). i was... 8 or 9 when i watched it? :)
<lkcl>
i don't know if the film is even available anywhere, now
<cesar[m]>
whitequark: Just to let you know, that I'm making good progress towards a reduced test case for https://github.com/nmigen/nmigen/issues/439#issuecomment-686492542 (on cxxsim, some traces are seemingly changing on the falling clock edge, as viewed on GTKWave). I'll comment on the bug report when I have something more concrete to show.
<whitequark>
cesar[m]: great! I have a few guesses as to what it can be but I don't see anything obviously wrong in the scheduling code so far
chipmuenk has joined #nmigen
Asu has quit [Quit: Konversation terminated!]
awe00 has joined #nmigen
emeb has joined #nmigen
_whitelogger has joined #nmigen
jeanthom has joined #nmigen
Asu has joined #nmigen
jeanthom has quit [Ping timeout: 240 seconds]
<d1b2>
<marble> If I have a board definition file, that's not upstream, what the proper way to import it into a script in another project? Should I add my for of the board repository as a submodule to the project repository?
<Lofty>
You can, yeah, although if possible just contribute it upstream
<d1b2>
<marble> I made a PR. I guess there are still some things that violate the code convention, so please point anything out that needs cleanup.
cr1901_modern has quit [Ping timeout: 246 seconds]
cr1901_modern1 has quit [Quit: Leaving.]
cr1901_modern has joined #nmigen
electronic_eel has quit [Ping timeout: 240 seconds]
electronic_eel has joined #nmigen
<cr1901_modern>
awygle: Decent chance I won't be able to make the meeting tomorrow, but I'm still interested in what you have in mind for a "board tester" gateware that others can use to bring up their boards.
chipmuenk has quit [Quit: chipmuenk]
ademski has joined #nmigen
jeanthom has quit [Ping timeout: 260 seconds]
chipmuenk has joined #nmigen
Asu has quit [Remote host closed the connection]
ademski has quit [Ping timeout: 260 seconds]
ademski has joined #nmigen
awe001 has joined #nmigen
awe00 has quit [Ping timeout: 240 seconds]
<anuejn>
is it an inherit limitation in async fifos that they have to be power of two in depth?
<anuejn>
or is it rather a limitation of the current implementation in the nmigen lib?
<anuejn>
why is this limitation there, what are the considerations behind it?
chipmuenk has quit [Quit: chipmuenk]
<vup>
well in theory one could chain multiple power of two fifos to get arbitrary depth, especially if latency is of no concern
ademski has quit [Ping timeout: 246 seconds]
<agg>
anuejn: I believe it is because the current implementation uses grey codes to move pointers between clock domains, and the grey codes require power-of-2 number of codes
<agg>
the memory addresses in use are successive grey code values, so you have to be able to access any possible n-bit address
<agg>
it's not fundamental to async fifos; you could just add more logic to decode the grey code into binary sequences for example
<agg>
i think the asyncfifo docs actually link to the paper that describes this style of fifo, which will probably have more of the considerations
ademski has joined #nmigen
<whitequark>
Gray code, not grey code ("Gray" is a first name)
<whitequark>
otherwise, yes
<whitequark>
it's generally not worth it to jump through a lot of hoops to support NPOT sized async FIFOs when they're probably going to be backed by a POT sized BRAM anyway
<agg>
too used to converting the american spelling to british english
<_whitenotifier-f>
[nmigen-boards] whitequark closed pull request #110: made cs pin optional for SDRAMResource - https://git.io/JUGSr
<_whitenotifier-f>
[nmigen/nmigen-boards] whitequark pushed 1 commit to master [+0/-0/±1] https://git.io/JUGpp
<_whitenotifier-f>
[nmigen/nmigen-boards] cyber-murmel 71ddd72 - resources.memory: make cs pin optional for SDRAMResource
<_whitenotifier-f>
[nmigen-boards] whitequark commented on pull request #110: made cs pin optional for SDRAMResource - https://git.io/JUGph