<rjo>
greni: or an active low asynchronous reset synchronizer?
<greni>
rjo: an active low asynchronous reset
<rjo>
AsynchronousResetSynchronizer(your_cd, ~your_rst_n) should do what you want.
<rjo>
*AsyncResetSynchronizer
<greni>
rjo: thanks I will check it
sandeepkr has quit [Ping timeout: 264 seconds]
sandeepkr has joined #m-labs
<rjo>
wow. a Pentium M 1.6 GHz "industrial PC" for DIN-rail with "Linux 2.6 CoDeSys-Visu-Profibus-Master is only ~250 k€...
<sb0>
that's why some companies love µTCA, VME, etc.
sandeepkr has quit [Ping timeout: 256 seconds]
sandeepkr has joined #m-labs
hartytp has joined #m-labs
<hartytp>
rjo: "The code is lacking a lot of clock domain crossings."
<hartytp>
where in particular?
<hartytp>
there are a few I've chosen not to bother with, but AFAICT, none should hurt given the way I'm using the code...
<hartytp>
The important one is the CDC for the looped back data. But, my thinking was that a CDC isn't needed here as I can use the IDELAY to ensure it meets setup/hold w.r.t. the rtio clock
<hartytp>
the CSRs I'm not bothering with CDCs on, but I'm only reading them out when they're static, so no issues there
<hartytp>
and, how is this ignoring intersymbol interference?
<hartytp>
you mean because it's a counter rather than a PRBN?
<hartytp>
or because there is only data in one direction?
<GitHub-m-labs>
[artiq] sbourdeauducq commented on issue #854: Since you have Kasli, you can use microscope to look at e.g. raw transceiver signals (the 8b10b encoded data), FSM states inside the soft Ethernet PHY, etc. to determine what the Sayma PHY is doing wrong. https://github.com/m-labs/artiq/issues/854#issuecomment-382049242
<whitequark>
um, is someone messing with sayma-3 without taking the lock?
<_florent_>
whitequark: i finished with sayma3, you can use it. If you use serwb and see initialization errors, can you log the errors in #967? thanks.
<whitequark>
I already went back home, it's too late...
<whitequark>
_florent_: regarding debug prints
<whitequark>
it's not rust itself, you need to set log level
<whitequark>
add log_level=DEBUG and uart_log_level=DEBUG to the filesystem image
<whitequark>
or use artiq_corelog set_level DEBUG ; artiq_corelog set_uart_level DEBUG if you have ethernet
<GitHub172>
[smoltcp] podhrmic commented on issue #190: > Huh? core::mem::replace exists. But I strongly dislike this solution. The code in EthernetInterface is already awful, let's not make it worse.... https://github.com/m-labs/smoltcp/pull/190#issuecomment-382082273
<GitHub154>
[smoltcp] podhrmic commented on issue #190: Another thing - I am not sure how to handle the CI build fails. In short, fragmentation currently works only for ipv4, but Ethernet Interface needs FragmentsSet even when it is not used. Hence the build fails when not using ipv4...:-/ https://github.com/m-labs/smoltcp/pull/190#issuecomment-382103079
<GitHub-m-labs>
[artiq] whitequark commented on issue #919: @jbqubit Today I've determined that on master, even if AD9154 is initialized (and it gets initialized with @sbourdeauducq's patch that correctly sets up the mux), there is no sawtooth output. I was going to rebuild the commit I initially tested this with and check if that works, but Sayma 3 was busy and I left the lab before it got too late. Will continue tomorrow.
<GitHub-m-labs>
[artiq] jbqubit commented on issue #967: I built from master with --without-sawg. Using AMC+RTM. @enjoy-digital Looks like this was a step backward. memtest fails 10 of 10 times I tried on this board pair (AMC s/n -8). ... https://github.com/m-labs/artiq/issues/967#issuecomment-382124607
<whitequark>
sb0: i learned why vivado is so slow
<whitequark>
"every function call in the synthesis lib uses SSE instructions to create a massive ROP chain and then returns into it"
<whitequark>
of course that murders branch and return address prediction