01:40 <sb0> whitequark: you never finished that netboot feature, right?

01:41 <sb0> cr1901: yes

01:42 <whitequark> sb0: if it's not finished it wouldn't be committed i believe

01:42 <sb0> whitequark: the only code I see is this

01:42 <sb0> https://github.com/m-labs/artiq/blob/master/artiq/firmware/bootloader/main.rs#L153

01:42 <sb0> which doesn't seem to do anything with the socket

01:43 <whitequark> sb0: yeah, there's no server

01:43 <whitequark> it'd be pretty easy to finish though

13:00 <key2> what is the reason we use gray counter in order to make an async fifo ?

13:04 <whitequark> if you do multi bit cdc with a 2FF you can only have one bit change at a tie

13:04 <whitequark> *time

13:04 <mtrbot-ml> [mattermost] <hartytp> hartytp joined the team.

13:05 <cr1901> if more than one bit changes, it's possible one of the 2ff will settle on the previous value, and other 2ffs will settle on the new value. This results in an invalid value seen in the dest clk domain.

13:08 <cr1901> If you limit to one bit change, then well, either the previous value or the new value is seen in the dest clk domain. And if the prev value was propogated, the new value will be seen in the dest clk domain after one clk cycle in src has elapsed

13:08 <cr1901> (or well, after a time interval of "whichever clk is slower" has elapsed)

13:16 <key2> whitequark: suppose I want to write during one time, and then read

13:16 <key2> meaning read/write can not happen at the same time

13:17 <key2> but the read counter and write counter are on 2 different clock domain

13:17 <key2> do I need to implement that with a gray counter ?

13:25 <whitequark> key2: can you explain some other way?

13:28 <key2> I need a mechanism in which I store into a Memory some data that come from a clockdomaine A, once finished and crc validated, I want to read them but from clock domain B. while reading, writing can not occur, while writing, reading can not occur either. so it's either way. in this case, do I need to compare with a gray conter ? or the fact that one operation happens after the other one can prevent me from doing so, if we consider

13:28 <key2> that the write counter got propagated properly

13:40 <whitequark> key2: sounds like you need two PulseSynchronizer

13:41 <key2> where ?

13:41 <key2> and why

13:41 <whitequark> one for request (write->read), one for ack (read->write)

13:41 <whitequark> and well, it's basically the same as BusSynchronizer but with a memory and not a bus

16:07 <key2> whitequark: can you tell me more about it ? what do PulseSynchronizer do that is needed in my case ?

16:12 <whitequark> take a look at BusSynchronizer, it does everything you need