<GitHub64>
[smoltcp] dlrobertson commented on pull request #207 177a04f: This works for now, but we really need to add support for NDISC Router Advertisements and Solicitations. In IPv6 this should actually be `default_routes` or something like that, where some could have been statically assigned and some could have been dynamically acquired via a Router Advertisement. https://github.com/m-labs/smoltcp/pull/207#discussio
<sb0>
_florent_, and it makes sense to buffer so many writes that using BRAM is appropriate? or is vivado just mapping a small RAM in BRAM for some reason?
<sb0>
_florent_, and this is on the RTM side. not sure if buffering more than, say, 1 write there makes sense; the wishbone bus is typically faster than the serial link.
<sb0>
_florent_, can you write test benches that verify serwb where one would expect bugs to hide (write buffer getting full, reading while there are transactions in the write buffer, etc.)
<sb0>
_florent_, i suggest scrapping the buffers on the rtm side, imo the complexity/benefit ratio is too high
rohitksingh_work has joined #m-labs
<sb0>
whitequark, no, SyncFIFOBuffered can do reads on every cycle
<sb0>
it's pipelined
<GitHub-m-labs>
[artiq] enjoy-digital commented on issue #997: This timing error appeared with new version of Vivado. I haven't done any specifc optimization on the RTM side before since Vivado < 2018.1 was not complaining. I'm looking at that. https://github.com/m-labs/artiq/issues/997#issuecomment-388270479
<hartytp>
sb0, _florent_: is this an issue on Sayma rtm:
<hartytp>
WARNING: [DRC REQP-1577] Clock output buffering: MMCME2_ADV connectivity violation. The signal pll_clk200 on the MMCME2_BASE/CLKOUT1 pin of MMCME2_BASE does not drive the same kind of BUFFER load as the other CLKOUT pins. Routing from the different buffer types will not be phase aligned.
<_florent_>
hartytp: no, pll_clk200 does not need to be phase aligned with the others clocks (sys/sys4x)
<hartytp>
out of curiosity, do you understand what this one is? Pretty sure it's benign vivado noise, but just curious
<hartytp>
WARNING: [Synth 8-115] binding instance 'i_254' in module 'partition' to reference 'logic__875' which has no pins
<_florent_>
hartytp: can't say for this one...
<_florent_>
hartytp: are you starting doing some tests with sayma?
<hartytp>
waiting for the amc gateware to build
<hartytp>
then yes
<hartytp>
while I was waiting, I hacked up some code to scrape vivado outputs and filter out all the obviously benign warnings
<hartytp>
only that one is left
<GitHub-m-labs>
[artiq] marmeladapk commented on issue #999: It may be connected with what I saw - on some variants of Kasli I had rolling restarts of Artiq (but not misoc) once I got `Si5324 is locked`. Next week I'll investigate it more. https://github.com/m-labs/artiq/issues/999#issuecomment-388315503
<_florent_>
hartytp: since amc compilation takes some time, you can still test your last amc bistream on hw
<_florent_>
hartytp: and rebuild amc with buffered=False while testing on hardware
<hartytp>
on it
rohitksingh has quit [Quit: Leaving.]
rohitksingh has joined #m-labs
marmelada has quit [Quit: Page closed]
sb0 has joined #m-labs
sb0_ has joined #m-labs
sb0_ has quit [Client Quit]
<sb0>
_florent_, "buffered" doesn't make it use block RAM. vivado will still use the LUT-ram if the memory is small enough. all "buffered" does is give the option to vivado to use BRAM.
<sb0>
I think the buffered FIFO has strictly better timing than the non-buffered one
<hartytp>
sb0: can you send me the rtm openocd script again
<hartytp>
?
<sb0>
hartytp, you can use artiq_flash load
<sb0>
hartytp, does it still use BRAM with depth=16?
<hartytp>
not sure
<hartytp>
how do I test that?
<hartytp>
I did see a timing error with depth=16
<hartytp>
(posted timing report above)
<sb0>
_florent_, I wonder if the timing issues are due to BUFR. that might have higher skew than BUFG, especially when using BRAM...
<sb0>
hartytp, your timing report shows a RAMB36E1 cell. that is BRAM. the synthesis report (in vivado.log) contains a section about memories, how deep they are, and how they are mapped
<GitHub116>
[smoltcp] dlrobertson commented on pull request #207 32f379e: I really like the idea of working on routing, but anything having to do with routes should probably be a separate PR. https://github.com/m-labs/smoltcp/pull/207#discussion_r187669601
rohitksingh has quit [Quit: Leaving.]
<GitHub66>
[smoltcp] ProgVal commented on issue #207: I could remove the commits with routes, and put them in a new PR after
hartytp has quit [Quit: Page closed]
rohitksingh has joined #m-labs
sb0 has quit [Quit: Leaving]
rohitksingh has quit [Quit: Leaving.]
rohitksingh has joined #m-labs
<cr1901_modern1>
Just curious: Artiq is LGPL, right? I just learned that PyQt5 is GPL. Is there a way that artiq gets around having to license as GPL?
<rjo>
cr1901_modern1: we should use PySide
<rjo>
cr1901_modern1: it's drop in so likely easy
<cr1901_modern1>
Ahh, wasn't aware pyside was still developed
<bb-m-labs>
build #2322 of artiq is complete: Failure [failed python_unittest] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/2322 blamelist: Florent Kermarrec <florent@enjoy-digital.fr>