08:06 <whitequark> marcan: poke

08:07 <biot> whitequark: glasgow boards for the masses coming up, I see :)

08:08 <whitequark> biot: oh?

08:09 <biot> I mean the crowdsupply pre-page

08:09 <whitequark> oh yeah

08:27 <marcan> whitequark: ack

08:29 <whitequark> marcan: got any time to spend on glasgow?

08:30 <marcan> what's on the todo list again?

08:31 <whitequark> submit the remaining symbols/footprints upstream, revD

08:34 <marcan> revD will probably stay on my back burner for a while; I can put some time into the former though

08:35 <marcan> (sorry, I don't know how I manage to fill up my schedule all the time)

08:35 <whitequark> fine by me :)

08:35 <whitequark> I have quite a bit of work in nmigen

08:38 <marcan> kk

11:47 <thaytan> exciting!

19:09 <biot> whitequark: if you wanted to do a speed test on say cat6 cable, plugging a cable into a glasgow and using all 16 pins, how fast could it send/receive/verify data?

19:09 <biot> not sure what that FPGA can really do

19:09 <whitequark> hmmm

19:09 <whitequark> just bare copper cable?

19:10 <biot> yup, which for cat6 is rated to 10GB...

19:10 <whitequark> Glasgow can do at most 200 MHz. 100 MHz is more realistic, at least without nontrivial effort

19:11 <biot> yeah, I figured as much

19:11 <whitequark> you're not getting anywhere near 10 GbE and even for 1 GbE I think you wouldn't get anything useful because Ethernet is actually analog (so the cards have an analog frontend and so on), and I doubt testing it with digital I/O will get you anything useful

19:12 <biot> yeah, isn't it -5v/+5v or something

19:14 <whitequark> i think 2.5V?

19:14 <whitequark> 5Vpp

19:17 <davidc__> 1000 base-T uses PAM-5; with each pair being used in both directions

19:19 <davidc__> Cable testing isn't just attenuation-at-frequency; its also impedance discontinuities (reflections), and crosstalk. Glasgow would probably make a good controller for test apparatus, but most of the work would be on the analog side

19:20 <biot> davidc__: I figured there had to be a reason why basic pinout ethernet testers are about $4 on $CHINA, but actual performance... not so cheap

19:21 <davidc__> biot: Some ethernet PHYs expose diagnostics and status registers that report on link state

19:21 <davidc__> biot: (including quality)

19:22 <davidc__> You might be able to hack something together for a qualitative tester (and you might be able to use glasgow for that; I haven't checked whether timing would work)

19:22 <biot> still, for actual throughput testing it would have to be something else, an actual 10GB chip

19:24 <davidc__> biot: well... throughput isn't always a great test.. most links either "work" or they don't. In my experience, its a pretty narrow range in which the link throws errors (between "link won't negotiate at speed" and "link seems to be fine")

19:24 <davidc__> And that range is going to be affected by silicon details, like how good that particular PHY is, or die temp of the PHY, etc

19:25 <davidc__> In terms of "does the link come up" - you don't actually need to talk ethernet data rates for that. The PHYs generally negotiate the link without any data traversing it

19:25 <davidc__> so you could just ignore the RX/TX *MII busses and configure the PHY over MDIO

19:25 <davidc__> and see if the link comes up

21:28 <Stormwind_mobile> davidc__: what about driving the wires/differential pairs with digital signals, but at ever increasing frequency, while monitoring error rate?

21:31 <Stormwind_mobile> Okay, granularity is getting rather coarse at the interesting high frequency end. 200MHz would mean 5ns of resolution. Not sure how far this would get you, and resembles probably more to crystal ball r

21:31 <Stormwind_mobile> eading than a waveform you'd get from an actual specialized network analysis tool.

21:32 <Stormwind_mobile> Probably best if someone knowledgeable in signal integrity stuff gives a take on it.

21:56 <davidc__> Stormwind_mobile: "Error rate" isn't a good proxy for a bunch of the measurements you care about