sb0 changed the topic of #m-labs to: https://m-labs.hk :: Mattermost https://chat.m-labs.hk :: Logs http://irclog.whitequark.org/m-labs
mumptai has quit [Quit: Verlassend]
<Astro-_> read from qspi flash on zc706 \o/
airwoodix7 has joined #m-labs
airwoodix has quit [Ping timeout: 240 seconds]
airwoodix7 is now known as airwoodix
harryho has joined #m-labs
<mtrbot-ml> [mattermost] <sb10q> nice!
<cr1901_modern> sb10q: I know ages ago you did a paper (might be on arxiv?) on a time-to-digital converter implementation. You know where I could find that?
<mtrbot-ml> [mattermost] <sb10q> https://arxiv.org/abs/1303.6840
<cr1901_modern> Tyvm
<mtrbot-ml> [mattermost] <sb10q> btw I might want this ported to ECP5 (unless prjxray does the job, in which case artix-7 is also OK) and nMigen for some laser experiments
<cr1901_modern> Ahhh good to know. I was just randomly thinking of it tonight and forgot the paper link
<mtrbot-ml> [mattermost] <sb10q> also increase the clock frequency of the tdc chain from 125MHz to the maximum the FPGA will take
<mtrbot-ml> [mattermost] <sb10q> maybe with multiple phase-aligned domains
<cr1901_modern> I wonder how precise one can get on ice40 (not that it would be fast enough)
<mtrbot-ml> [mattermost] <sb10q> I also want ethernet and a cpu in that FPGA so ice40 won't work
<mtrbot-ml> [mattermost] <sb10q> and some DSP
<cr1901_modern> Ahh yea, that last one alone means ice40 is unacceptable
<mtrbot-ml> [mattermost] <sb10q> can you even do TCP on ice40?
<cr1901_modern> I never tried. But a CPU plus cache def fits comfortably. If you use SPI flash as the program memory for a tcp stack, and a simple PHY interface, then I bet you can do TCP on ice40
<tpw_rules> the ice40 UP parts have MAC units
<tpw_rules> they also have the big SPRAMs, 128KB total which would make great memory for the program (once it's loaded from spi flash)
<cr1901_modern> Correct, but they're slow as hell. So I didn't even think to mention them :P.
<tpw_rules> eh, depends on your definition of hell i guess
Stormwind_mobile has joined #m-labs
m4ssi has joined #m-labs
<mtrbot-ml> [mattermost] <vince_cheng> vince_cheng joined the team.
proteus-guy has quit [Ping timeout: 265 seconds]
siruf has quit [*.net *.split]
forrestv has quit [*.net *.split]
key2 has quit [*.net *.split]
kaalia has quit [*.net *.split]
m4ssi has quit [Remote host closed the connection]
forrestv has joined #m-labs
siruf has joined #m-labs
key2 has joined #m-labs
kaalia has joined #m-labs
Gurty has joined #m-labs
m4ssi has joined #m-labs
Gurty has quit [Remote host closed the connection]
Gurty has joined #m-labs
<rjo> sb0: that revamped TDC would be great!
Stormwind_mobile has quit [Ping timeout: 250 seconds]
Stormwind_mobile has joined #m-labs
Stormwind_mobile has quit [Ping timeout: 240 seconds]
proteus-guy has joined #m-labs
<mtrbot-ml> [mattermost] <hartytp> @astro cool! What's next on the roadmap?
<Astro-_> actual writing, not only through rust but openocd too
airwoodix2 has joined #m-labs
airwoodix has quit [Ping timeout: 265 seconds]
airwoodix2 is now known as airwoodix
<mtrbot-ml> [mattermost] <hartytp> Is ethernet working reliably? Did you look at communication between the CPUs? (Not trying to chase, just excited/curious :) )
<mtrbot-ml> [mattermost] <sb10q> @hartytp I have trouble figuring out exactly what gets measured with DDMTD
<mtrbot-ml> [mattermost] <sb10q> this isn't clear from Weida's diagrams
<mtrbot-ml> [mattermost] <sb10q> so all the DDMTD cores are running from the helper DCXO, right?
<mtrbot-ml> [mattermost] <sb10q> then what are all the clocks that get sampled with the DDMTD FFs that are on the helper DCXO? and which tags are computed between which clocks exactly?
<mtrbot-ml> [mattermost] <hartytp> in the first instance, ask @weidazhang
<mtrbot-ml> [mattermost] <sb10q> then I'll get more confusing replies
<mtrbot-ml> [mattermost] <hartytp> as I'd only ask him and then reply in my own words
<mtrbot-ml> [mattermost] <hartytp> didn't he send you verilog?
<mtrbot-ml> [mattermost] <sb10q> it's super hard to read
<mtrbot-ml> [mattermost] <hartytp> maybe the easiest thing is if the three of us meet on MM at some point today/tomorrow and discuss
<mtrbot-ml> [mattermost] <hartytp> what's your availability?
<mtrbot-ml> [mattermost] <sb10q> well that question should have a straightforward answer...
<mtrbot-ml> [mattermost] <hartytp> sure, I just don't know what it is and haven't thought about WR much at all so I'd only be translating Weida's response.
<mtrbot-ml> [mattermost] <hartytp> anyway, I'll see when he's around and have a chat
Gurty has quit [Ping timeout: 246 seconds]
<mtrbot-ml> [mattermost] <sb10q> well let's try to understand it
<mtrbot-ml> [mattermost] <sb10q> the helper DCXO needs to be phase-locked to the main XO and with a N-1/N frequency ratio, right?
<mtrbot-ml> [mattermost] <hartytp> I thought the helper was locked to the reference
<mtrbot-ml> [mattermost] <sb10q> the reference is? the recovered clock?
<mtrbot-ml> [mattermost] <hartytp> yes
<mtrbot-ml> [mattermost] <hartytp> or an external source in master mode
<mtrbot-ml> [mattermost] <sb10q> why would there be a master mode?
<mtrbot-ml> [mattermost] <sb10q> in master mode this wrpll thing can be disabled and the external clock used directly, no?
<mtrbot-ml> [mattermost] <sb10q> or you want to filter noise on the external clock_
<mtrbot-ml> [mattermost] <sb10q> or you want to filter noise on the external clock?
<mtrbot-ml> [mattermost] <hartytp> yes, if you wanted to filter an external clock
<mtrbot-ml> [mattermost] <hartytp> or if you didn't have the flexibility in your hw design to clock from the external source directly
<mtrbot-ml> [mattermost] <hartytp> e.g. I can't remember on Kasli 2.0 if we can clock the EEMs from the external SMA directly or if we agreed to use the WR PLL even in master mode to generate the EEM clock
<mtrbot-ml> [mattermost] <hartytp> anyway, I really need to discuss this all with @weidazhang to check I've remembered the details correctly as it's been a while since I thought about it. I'll try to get back to you later on today
<mtrbot-ml> [mattermost] <sb10q> okay so let's say the helper clock needs to be locked at N-1/N from the reference
<mtrbot-ml> [mattermost] <sb10q> what should be measured with DDMTD to achieve that?
<mtrbot-ml> [mattermost] <sb10q> DDMTD is normally between two clocks, but are you doing something different?
Gurty has joined #m-labs
Gurty has joined #m-labs
Gurty has quit [Changing host]
<mtrbot-ml> [mattermost] <hartytp> IIRC this is all in the pseudo code doc weida sent you a while back
<mtrbot-ml> [mattermost] <sb10q> is it the same as the original WR?
<mtrbot-ml> [mattermost] <hartytp> yes, but the helper lock is a bit different to the main lock as it uses the DDMTD core tag output
<mtrbot-ml> [mattermost] <sb10q> yeah it's this kind of detail that I want to know about
<mtrbot-ml> [mattermost] <hartytp> yes, IIRC Weida wrote that all up in the docs he circulated a while back. I can re-read and rephrase in my own words if that helps, but I think it's better to just ask him these questions directly on IRC/MM
<mtrbot-ml> [mattermost] <hartytp> need to head off now but back in a few hours
<mtrbot-ml> [mattermost] <sb10q> this I understandthis I understand:
<mtrbot-ml> [mattermost] <sb10q> the weida docs I don't
<mtrbot-ml> [mattermost] <sb10q> (and, generally, the WR docs from which this diagram are extracted I also understand)
<mtrbot-ml> [mattermost] <sb10q> is there a reason for deviating from the WR implementation?
<mtrbot-ml> [mattermost] <sb10q> other than SOS filters instead of PI, and different DCXOs
Stormwind_mobile has joined #m-labs
jfng has quit [Read error: Connection reset by peer]
marble[m] has quit [Remote host closed the connection]
synaption[m] has quit [Remote host closed the connection]
xobs has quit [Read error: Connection reset by peer]
rjo has quit [Read error: Connection reset by peer]
jryans has quit [Read error: Connection reset by peer]
Stormwind_mobile has quit [Ping timeout: 265 seconds]
Stormwind_mobile has joined #m-labs
rohitksingh has quit [Ping timeout: 250 seconds]
rjo has joined #m-labs
synaption[m] has joined #m-labs
marble[m] has joined #m-labs
xobs has joined #m-labs
jfng has joined #m-labs
jryans has joined #m-labs
proteus-guy has quit [Ping timeout: 268 seconds]
<_whitenotifier-e> [nmigen-boards] Stary2001 opened pull request #35: tinyfpga_bx: fix definition of io pin 17 - https://git.io/JeXp2
<_whitenotifier-e> [nmigen-boards] whitequark closed pull request #35: tinyfpga_bx: fix definition of io pin 17 - https://git.io/JeXp2
<_whitenotifier-e> [m-labs/nmigen-boards] whitequark pushed 1 commit to master [+0/-0/±1] https://git.io/JeXpa
<_whitenotifier-e> [m-labs/nmigen-boards] Stary2001 353a21b - tinyfpga_bx: fix definition of io pin 17
<_whitenotifier-e> [nmigen-boards] whitequark commented on pull request #35: tinyfpga_bx: fix definition of io pin 17 - https://git.io/JeXpV
m4ssi has quit [Remote host closed the connection]
Stormwind_mobile has quit [Ping timeout: 268 seconds]
Stormwind_mobile has joined #m-labs
gsuberland has joined #m-labs
Sarayan has joined #m-labs
Stormwind_mobile has quit [Ping timeout: 268 seconds]
Stormwind_mobile has joined #m-labs
<mtrbot-ml> [mattermost] <hartytp> I don't believe that Weida does deviate from that
<mtrbot-ml> [mattermost] <hartytp> That's how the main PLL works, but it's not the whole story as you need the frequency detector for the helper PLL lock which isn't included there
<mtrbot-ml> [mattermost] <hartytp> you can see the wr implementation of that in 4.3.6 here https://white-rabbit.web.cern.ch/documents/Precise_time_and_frequency_transfer_in_a_White_Rabbit_network.pdf
Stormwind_mobile has quit [Ping timeout: 265 seconds]
mumptai has joined #m-labs
<Astro-_> @hartytp we have both cortex-a9 cores running and a working mutex implementation.
<_whitenotifier-e> [nmigen] whitequark commented on issue #213: flow graph analysis and automation - https://git.io/Je1fP
Stormwind_mobile has joined #m-labs
<_whitenotifier-e> [nmigen] daveshah1 commented on issue #213: flow graph analysis and automation - https://git.io/Je1fN
<_whitenotifier-e> [nmigen] whitequark commented on issue #213: flow graph analysis and automation - https://git.io/Je1Je
rohitksingh has joined #m-labs
<_whitenotifier-e> [m-labs/nmigen] whitequark pushed 1 commit to master [+0/-0/±7] https://git.io/Je1U4
<_whitenotifier-e> [m-labs/nmigen] whitequark 7df7005 - back.pysim: redesign the simulator.
<_whitenotifier-e> [nmigen] whitequark closed issue #34: Unexpected Memory behaviour in simulation - https://git.io/fhyHX
<_whitenotifier-e> [nmigen] whitequark closed issue #160: pysim is very slow - https://git.io/fjDdl
<_whitenotifier-e> [nmigen] whitequark closed issue #161: pysim should have a way to reset user/sync signals - https://git.io/fjDd8
<_whitenotifier-e> [nmigen] whitequark closed issue #242: bitarray dependency is unfortunate - https://git.io/JenU9
<_whitenotifier-e> [nmigen] whitequark closed issue #215: pysim treats `x == 1` and `x == -1` for 1-bit signal `x` differently - https://git.io/Je3MN
<_whitenotifier-e> [nmigen] whitequark closed issue #262: pure simulation signals should be supported - https://git.io/JeuLu
<whitequark> sb: rjo: i rewrote pysim2 without changing interface (so far). it is now 6x faster than pysim, and 3x faster than migen.sim.
<whitequark> (on minerva-examples benchmark)
<_whitenotifier-e> [nmigen] mithro commented on issue #213: flow graph analysis and automation - https://git.io/Je1Uy
<_whitenotifier-e> [nmigen] Success. The Travis CI build passed - https://travis-ci.org/m-labs/nmigen/builds/618358545?utm_source=github_status&utm_medium=notification
<_whitenotifier-e> [nmigen] Success. Absolute coverage decreased by -0.29% but relative coverage increased by +9.23% compared to f8428ff - https://codecov.io/gh/m-labs/nmigen/commit/7df70059d1483677b1c4d24eaed3bac323b32a11
<_whitenotifier-e> [nmigen] Success. 91.56% of diff hit (target 82.33%) - https://codecov.io/gh/m-labs/nmigen/commit/7df70059d1483677b1c4d24eaed3bac323b32a11
mumptai has quit [Quit: Verlassend]
rohitksingh has quit [Ping timeout: 250 seconds]
<_whitenotifier-e> [nmigen] whitequark commented on issue #160: pysim is very slow - https://git.io/Je1TR
<_whitenotifier-e> [nmigen] whitequark commented on issue #160: pysim is very slow - https://git.io/Je1T0
<adamgreig> hah, new nmigen pysim fixes the bug that my test was working around, so now the test fails
<adamgreig> though less amusingly my runtime has only gone from 27s to 25s
<adamgreig> i guess most of my time is elaborating rather than running or something, will look in to resetting and sharing
<whitequark> yes
<whitequark> actually i think i can maybe make elaborating a bit faster
<adamgreig> removing the "TODO: remove this when pysim is fixed" fixed my test
<adamgreig> o/
<whitequark> lol nice
rohitksingh has joined #m-labs
<_whitenotifier-e> [nmigen] whitequark commented on issue #242: bitarray dependency is unfortunate - https://git.io/Je1Ty
<_whitenotifier-e> [nmigen] whitequark opened issue #275: Remove everything deprecated in nmigen 0.1 - https://git.io/Je1ks
<ZirconiumX> Is nmigen-soc useful in its current state? It seems to have some useful infrastructure.
<whitequark> sure, everything in master should be well-designed and reasonably stable