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
<GitHub86>
[smoltcp] podhrmic opened pull request #53: IGMP support (master...igmp) https://git.io/vdrfz
sb0_ has quit [Ping timeout: 240 seconds]
sb0_ has joined #m-labs
llopez has quit [Ping timeout: 260 seconds]
sb0_ has quit [Read error: Connection reset by peer]
rohitksingh_work has joined #m-labs
sb0_ has joined #m-labs
rohitksingh_work has quit [Ping timeout: 255 seconds]
rohitksingh_work has joined #m-labs
rohitksingh_wor1 has joined #m-labs
rohitksingh_work has quit [Ping timeout: 260 seconds]
rohitksingh_work has joined #m-labs
rohitksingh_wor1 has quit [Ping timeout: 240 seconds]
rohitksingh_wor1 has joined #m-labs
rohitksingh_work has quit [Ping timeout: 240 seconds]
rohitksingh_wor1 has quit [Quit: Leaving.]
rohitksingh_work has joined #m-labs
ohsix has quit [Ping timeout: 240 seconds]
ohsix has joined #m-labs
rohitksingh_work has quit [Read error: Connection reset by peer]
rohitksingh_work has joined #m-labs
cr1901_modern has quit [Read error: Connection reset by peer]
_rht has joined #m-labs
<rjo>
sb0_: about kasli gtp clocking: we currently have just the si5324 clock going into the quad. if we want to run ethernet on one sfp and drtio master on the other two, will that work or do we need another clock?
<rjo>
sb0_: from what i can see there are two plls in that quad and we should be ok. or are there problems with any of the RX paths again needing a PLL?
<sb0_>
rjo, the RX path does not need a PLL. for DRTIO mastering, we need the master clock going into the transceiver on a dedicated transceiver clock pin, and Si5324 is not necessary
<sb0_>
I think for ethernet what is usually done is adding a 125MHz crystal connected to a transceiver clock pin, next to the quad that has the ethernet pins
<sb0_>
we can probably use the si5324 to generate that clock, but I would not bother. the crystal is very cheap and simpler.
<sb0_>
what I mean with "does not need a PLL": the PLL can be shared between TX and RX in the same transceiver if they are operating at the same frequency
<sb0_>
(perhaps even across transceivers, with various arcane rules that xilinx made up)
<rjo>
sb0_: *the* crystal?
<sb0_>
well those integrated crystal oscillators
<rjo>
sb0_: did you check the schematics?
<sb0_>
why?
<rjo>
whether everything we need for all that to work is on there?
<rjo>
drtio and ethernet?
<rjo>
sb0_: could you do a review of the kasli schematics in the areas where i am not experienced, i.e. the transcievers and the dram? otherwise nobody does a proper review there.
<sb0_>
ok
<sb0_>
so this 7a100t has only one quad?
<rjo>
that package has. but that can't be news.
<sb0_>
the second transceiver clock definitely could use a crystal on it
<rjo>
that's what i thought. afaict it even needs that to do ethernet at all with anything other than a 125 MHz f_RTIO. the gtp pll can only do N/{1,2} ratio.
<rjo>
i'll write an issue.
<sb0_>
are DDR3 discrete termination resistors necessary?
<rjo>
see the discussion in the issues.
<sb0_>
another "nice to have" is a crystal connected directly to the FPGA. in theory we could use the 125MHz clock and route it through the transceiver, but it requires instantiating the transceiver and configuring many complicated parameters. doesn't make the board very user-friendly.
<rjo>
there is a 50M xtal.
<sb0_>
ok the ddr3 looks fine
<rjo>
sb0_: could you also look at that ODT/VREF stuff. i know very little about the relative constrants between a xilinx memory controller and ours.
<sb0_>
ours has no constraints other than supporting the io standard
<sb0_>
so yes, connect vref in the bank
<rjo>
no need to connect ODT to a VREF pin (like on arty)?
<sb0_>
the odt control digital signal?
<rjo>
and not having CS_N (but RESET_N instead) connected is ok as well?
<sb0_>
not having cs_n is ok, having reset_n is not necessary but won't hurt
<rjo>
sb0_: i know little about ODT. if it is digital, i guess that's just fine. just doing a delta between the arty schematics and Kasli.
<sb0_>
so in arty they have ODT hardwired to Vref?
<sb0_>
in misoc we just drive odt high all the time
<rjo>
sb0_: on arty it's wired to a fpga "vref" pin.
<sb0_>
ok, that's equivalent
<sb0_>
we don't need a LED on si5324 LOL
<sb0_>
if we do status leds, connect them to the FPGA. then we can wire them to LOL and what not.
<sb0_>
LOL is also accessible by I2C so no extra signal is necessary
<rjo>
there is pin shortage on the fpga. that's why he didn't connect that to the fpga and that's why there are only 4 leds. but yes. it's not necessary.
<sb0_>
the second external clock input (J19) doesn't look very useful if the FPGA cannot see it
<rjo>
to save BOM and board space, can we just take the other clkout from the si5324 and use that for the MGT clock input? i.e. instead of adding an xtal and a 125 mhz clock gen, just feed the adclk948 from the adclk944 pin and use the si5324 ckout2 to drive mgtrefclk1
<sb0_>
hmm this mixes ethernet constraints into the drtio si5324 driver
<rjo>
j19 is ok. that would be to drive a 1ghz clock (or a sufficiently low noise clock) to the eems.
<sb0_>
ok and any phase relationships with the other clock that the fpga can see is the responsibility of the user?
<rjo>
ack. makes sense. let's keep it separable.
<rjo>
yes. phase issues with that other clock are elsewhere.
<sb0_>
also the two clock outputs from the si5324 are divided versions of one clock
<rjo>
ok.
<sb0_>
the divider can be very large (it's not a real divider I think) but idk if we can always meet the ethernet ppm specs
<sb0_>
probably not worth the complication to save a small xtal ...
<sb0_>
if you really want to save a xtal, it's easier to route the system clock through the transceiver, from the ethernet xtal
<sb0_>
though I have to check that this clock is stable before and while the transceiver is being initialized
<sb0_>
oh yes, it is fine, and not even overly complicated. IBUFDS_GTE2 output is routable to BUFG and BUFH
<rjo>
na. let's just add the 125 mhz xtal and be done with it. i gave him some options to save space.
<sb0_>
so feel free to remove the 50M
<rjo>
ok. i'll add that as an option.
_rht has quit [Quit: Connection closed for inactivity]
early has quit [Quit: Leaving]
early has joined #m-labs
<GitHub22>
[smoltcp] whitequark commented on issue #49: @phil-opp Do you think you can take the abovementioned outline and implement this yourself? I'm fairly busy right now. https://git.io/vdri5
<GitHub61>
[smoltcp] whitequark commented on pull request #53 f0b6dcb: ... and when the file is called `igmpv2` you can remove the obnoxious prefixes. See how the other protocols do it. https://git.io/vdrMW
<GitHub167>
[smoltcp] whitequark commented on pull request #53 f0b6dcb: I think the file should be called `igmpv2`. https://git.io/vdrM8
<GitHub171>
[smoltcp] whitequark commented on pull request #53 f0b6dcb: The header length is fixed, so there's nothing to invalidate. https://git.io/vdrMR
<GitHub30>
[smoltcp] whitequark commented on pull request #53 f0b6dcb: This is not necessary also. https://git.io/vdrMB
<GitHub172>
[smoltcp] whitequark commented on pull request #53 f0b6dcb: Please, fix indentation. We use spaces. https://git.io/vdrMc
<GitHub37>
[smoltcp] whitequark commented on pull request #53 f0b6dcb: I don't think there's any NIC that does IGMP checksum offload. Even ICMP was a surprise to me. https://git.io/vdrM4
<GitHub140>
[smoltcp] whitequark commented on pull request #53 f0b6dcb: No data in IGMP packets. https://git.io/vdrM0
<GitHub179>
[smoltcp] whitequark commented on pull request #53 f0b6dcb: Without `get_`. https://git.io/vdrME
rohitksingh_work has quit [Ping timeout: 260 seconds]
rohitksingh_work has joined #m-labs
sb0_ has quit [Ping timeout: 240 seconds]
sb0_ has joined #m-labs
rohitksingh_work has quit [Read error: Connection reset by peer]
rohitksingh has joined #m-labs
cr1901_modern has joined #m-labs
<sb0_>
whitequark, any update on the dma bug?
kristianpaul has quit [Quit: Lost terminal]
<GitHub6>
[smoltcp] little-dude opened issue #54: Would a dedicated crate for packet decoding make sense? https://git.io/vdoKK
<GitHub123>
[smoltcp] whitequark commented on issue #54: > The wire module provides abstractions for packet decoding, which could also be useful outside of smoltcp.... https://git.io/vdoKh
<GitHub167>
[smoltcp] little-dude commented on issue #54: I can totally do that. But don't you mind the wire module having code for protocols that are not really used in `smoltcp` ? For instance, would you accept a PR that add support for decoding OpenFlow headers? https://git.io/vdo5n