sb0 changed the topic of #m-labs to: ARTIQ, Migen, MiSoC, Mixxeo & other M-Labs projects :: fka #milkymist :: Logs http://irclog.whitequark.org/m-labs
_whitelogger has joined #m-labs
<sb0>
whitequark, if we have a CPU with separate memories for data and code, can rust/llvm target it? e.g. reading the program memory would not be allowed
<ohsix>
dont' know much about rust/llvm in particular, but there are other targets where the 'memories' are the same but need special instructions to access and they manage fine, i think that implies very different memories would work
<ohsix>
err, the bit that followed doesn't apply to rust, just llvm
<mithro>
sb0: that might be useful from verifying that my stuff is mostly valid - I'm on a yak shave of adding ac97 decoding to sigrok at the moment
<sb0>
whitequark, where would you buy m6 stainless steel screws (for cf35 vacuum flanges) of various lengths?
<sb0>
silver plated if not expensive, otherwise i can just use the mos2
<sb0>
I could also cut those I have to the desired length but that sounds messy
<mithro>
sb0: Did anyone ever port the m1 soc to somewhat run on the mixxeo (even if just very hackily)?
<sb0>
I want good quality ones that won't break (removing any broken part stuck in my slightly expensive cf35 cube sounds annoying) so not so keen on trying random hardware store stuff
<whitequark>
sb0: not allowed to read code at all? hmmmm let me think about it
<whitequark>
yes, I think that could be reasonably done
<whitequark>
I don't think the OR1K target actually reads any code, it doesn't have "constant islands" or something
<whitequark>
sb0: regarding SS screws, do you mean cutting by sawing off? normal bolt/screw cutters fail if you use them with SS
<whitequark>
anyway, silver plated is probably taobao, these are special stuff, and regular ones you can get at reclamation st in one of the zillion hardware shops
<whitequark>
it's pretty hard to fuck up an SS screw...
<GitHub3>
[smoltcp] whitequark commented on issue #34: Okay, so I think we have some confusion with this PR.... https://git.io/v5cpx
<GitHub164>
[smoltcp] whitequark commented on issue #34: Okay, so I think we have some confusion with this PR.... https://git.io/v5cpx
<GitHub182>
[smoltcp] whitequark pushed 1 new commit to master: https://git.io/v5chZ
<GitHub182>
smoltcp/master 614323b whitequark: README: add some notable omissions.
<travis-ci>
m-labs/smoltcp#185 (master - 614323b : whitequark): The build passed.
<_florent_>
sb0: for the delay-finding, no it's not handling all the cases right now (since you wanted to use phase_detector I haven't spent too much time on it), but if you are now fine with this method, I'll make sure we are covering all the cases and add testbenches for that.
<sb0>
_florent_, ok. is the phase detector issue on the ultrascale or artix side? the ultrascale phase detector would be nice to have for drtio over rtm/amc
<_florent_>
sb0: it's on the ultrascale side
<sb0>
of course
<_florent_>
sb0: I got an answer on xilinx forum but haven't tested it yet
<_florent_>
sb0: the issue is that you want to be able to have the 90° phase shift between the master and slave serdes
<_florent_>
sb0: when you use it in counter mode (ie you specify the number of taps to do 90°phase shift and not the time), it's working fine, init ok, reload ok
<_florent_>
sb0: when you use it in time mode, init is working fine, but when you reload it's set to 0
<sb0>
ah it's a "phase shift" on the input data, via idelay
<sb0>
what is the difference between "init" and "reload"?
<_florent_>
sb0: and the things with ultrascale is that you taps have variables delays
<sb0>
because of no calibration like spartan6? or is it something else?
<_florent_>
sb0: init: after reset, reload, you set the load pin of the serdes
<GitHub32>
artiq/sinara 32ca51f Florent Kermarrec: gateware/targets/sayma_amc_standalone/rtm: use new serwb modules
<GitHub32>
artiq/sinara 41d57d6 Florent Kermarrec: gateware/serwb: SERWBPLL, SERWBPHY, SERWBCore and add checks in delay finding to verify the sampling window
rohitksingh has joined #m-labs
<whitequark>
aha, figured
<GitHub188>
smoltcp/master 280ddde whitequark: Fix Ipv4Packet::payload{,_mut}() returning overly long buffers....
<GitHub188>
[smoltcp] whitequark pushed 1 new commit to master: https://git.io/v5CXy
<GitHub32>
[artiq] dhslichter commented on issue #685: This is nice to have the improvement, thanks @whitequark. However, this is still very slow in the grand scheme of things, especially if we are going to larger Sinara setups. It seems that we should be aiming to go at least an order of magnitude faster (if not more) once we are working with Metlino cards driving multiple uTCA crates etc -- complex experiments, with all the attendant parameterized wavefor
<GitHub139>
[artiq] dhslichter commented on issue #685: Sounds good @whitequark, and I am glad that you have managed to improve the reliability here (I do recall your reporting better numbers before, but with consistency/reliability issues). Definitely seems like tuning the TCP stack to optimize throughput will be a more straightforward task. Anyway, my main message is "good work!" :) https://github.com/m-labs/artiq/issues/685#issuecomment-326028894
<GitHub65>
[smoltcp] whitequark commented on issue #36: Sure. Do you have any particular hardware in mind? Show me the datasheet and I'll think about exposing this capability. https://git.io/v5Wa7
<GitHub81>
[smoltcp] steffengy commented on issue #36: STM32F2xxx/F4xxx (F4 is just a superset with more functionality basically, ethernet is afaik the same):... https://git.io/v5WV8
<GitHub173>
[smoltcp] steffengy commented on issue #36: STM32F2xxx/F4xxx (F4 is just a superset with more functionality basically, ethernet is afaik the same):... https://git.io/v5WV8
<GitHub41>
[smoltcp] steffengy commented on issue #36: STM32F2xxx/F4xxx (F4 is just a superset with more functionality basically, ethernet is afaik the same):... https://git.io/v5WV8
<GitHub146>
[smoltcp] whitequark pushed 1 new commit to master: https://git.io/v5WHB
<GitHub146>
smoltcp/master 3226770 whitequark: Fix the TCP SEQ acceptability check....
<travis-ci>
m-labs/smoltcp#192 (master - 3226770 : whitequark): The build passed.