<sb0>
though I don't understand those tables, where is such a big difference between "minimum" and "maximum" coming from?
<sb0>
anyway, taking the average between the min and max you get 225ns for crossing the GTP transceivers (one TX one RX) alone, and the rest of the DRTIO stack can easily add roughly 30-60ns (off the top of my head) when synching the counters
<sb0>
I found a phase that works for the data, but the packet boundaries may be wron
<sb0>
g
<sb0>
this makes perfect sense, the sayma ethernet system had this opportunity to be awful by having different timing for txctl and txdata, so of course it did
<GitHub49>
[artiq] sbourdeauducq commented on issue #687: > I never said that. I'm not fussed if you want an ARTIQ driver for it. I just don't want Novogorny advertised as a product that people should consider buying.... https://github.com/m-labs/artiq/issues/687#issuecomment-367966245
<sb0>
also that PHY chip truncates preambles, because why not
<sb0>
or is that a liteeth bugß
<sb0>
?
<GitHub197>
[artiq] hartytp commented on issue #687: @sbourdeauducq "rights" not in a legal sense, but more in an etiquette/not being a jerk sense. Like, you don't rename a boat once you buy it. Nothing is stopping you, it's just not productive to go around making trivial changes to other people's work and then changing the name.... https://github.com/m-labs/artiq/issues/687#issuecomment-367968609
<sb0>
hm, the txdata/txctl difference looks small enough. the preamble truncation happens only sometimes, can be normal and due to the way 1000base-x operates.
<GitHub64>
[artiq] hartytp commented on issue #687: I actually sometimes look back nostalgically at the days when my experimental code was written in turbo pascal and labview, but I didn't have to deal with all this BS. https://github.com/m-labs/artiq/issues/687#issuecomment-367971709
<GitHub38>
[artiq] sbourdeauducq commented on issue #854: Note: the KC705 sniffer is completely OK with most kinds of of corrupted packets, including those with broken preambles. This makes it a nice tool for dealing with this sort of bug. https://github.com/m-labs/artiq/issues/854#issuecomment-367973941
<GitHub8>
[artiq] sbourdeauducq commented on issue #854: Note: the KC705 sniffer (with the most direct connection to Sayma, i.e. SFP/RJ45, transceiver, and direct RJ45 cable, no switch) is completely OK with most kinds of of corrupted packets, including those with broken preambles. This makes it a nice tool for dealing with this sort of bug. https://github.com/m-labs/artiq/issues/854#issuecomment-367973941
<sb0>
rjo, microscope over JTAG has three problems: 1) nonportable FPGA JTAG primitives 2) digging into OpenOCD code 3) having IPC between OpenOCD and the microscope client (unless we rewrite it in C)
<hartytp>
_florent_ do you expect vivado warnings like "WARNING: [Vivado 12-3521] Clock specified in more than one group: serwb_pll_pll_serwb_serdes_clk [/home/ion/scratch/tph/artiq/artiq_sayma/standalone/gateware/top.xdc:882] WARNING: [Vivado 12-3521] Clock specified in more than one group: serwb_pll_pll_serwb_serdes_5x_clk [/home/ion/scratch/tph/artiq/artiq_sayma/standalone/gateware/top.xdc:884]
<GitHub155>
artiq/spi2 b0ce2cd Robert Jordens: firmware, sayma: port converter_spi to spi2...
<sb0>
hartytp, marmelada, if you have spare time, feel free to reproduce the sayma->kc705 ethernet. that would be at least one ethernet thing that is reproducible on more than one board...
<sb0>
hartytp, does your board have the ethernet rework?
<rjo>
sb0: i've had great success calling things like those "challenges". ;) (1) sure. (2) and (3) could be all done over openocd telnet in python.
<sb0>
yeah well, pick your battles. it would take more time to do those than what I spent on microscope since the beginning.
<hartytp>
sb0: not yet, will prob do that next week
<rjo>
sb0: i wouldn't be that dismissive all the time. you risk killing discussions and degrading the level of respect. ultimately people will turn away or even start retalliating by claiming that microscope is shitty, badly documented, slow, NIH, idiosyncratic, technically inferior, and what not...
<hartytp>
IIRC, Greg said he got a decent link with Artiq and sayma
<hartytp>
want to try that first
<hartytp>
but will have to wait until next week
<rjo>
sb0: could you have a look at that spi2 branch and tell me what I need to test and how?
<rjo>
hartytp, cjbe: are you also using lab.m-labs to do sayma compilation runs?
<hartytp>
rjo: can you double check that the HMC830 SEN/CS has a rising edge before the first rising edge of SCLK at startup
<hartytp>
both should start LOW, then SEN/CS should have a rising edge
<hartytp>
otherwise the SPI interface breaks
<rjo>
hartytp: yes. so we are certain that we want "HMC Mode"?
<hartytp>
don't really care either way
<hartytp>
HMC mode is simpler to program and is what's already in the code
<sb0>
rjo, compile rtm gateware, amc gateware, load into sayma-3, check that the hmc830 is detected, then disable hmc830 and recompile runtime, check that hmc7043 is detected
<rjo>
but "SPI interface" breaks would mean that "Open Mode" does not work.
<hartytp>
if you want to deterministically make it the other mode and then recode it the I have no objection
<sb0>
alternatively make the runtime continue on hmc830 failure right from the start
<rjo>
sb0: that is sayma standalone?
<hartytp>
yes, that's what I mean. Precisely, I mean "breaks the code currently in ARTIQ"
<sb0>
rjo, yes
<sb0>
rjo, please use sayma-3, I'm doing ethernet tests on sayma-1
<hartytp>
just need to make sure that it does deterministically start in one mode and that we know which one that is, and have written code appropriately
<sb0>
rjo, also use --without-sawg
<hartytp>
"hartytp, cjbe: are you also using lab.m-labs to do sayma compilation runs?" no. building locally
<sb0>
rjo, re. developing microscope-over-jtag, let me give a more detailed answer: it's nontrivial and I don't have a shortage of "spare-time" projects. I'm not opposed to someone else implementing it and would gladly review/merge PRs.
<sb0>
maybe it should be a more general uart-over-jtag, then the cpu console can go there as well
<rjo>
sb0: ack. i totally get and support that.
<rjo>
sb0: exacly. that's also what i thought. and it would be nice to hook the cpu tap to openocd with a gdb stub.
<rjo>
sb0: openocd has a crapload of openrisc debugging code but it's badly fragmented and intertwined with other things and the old openrisc implementation.
<rjo>
sb0: ok. anything else that i can test for spi2?
<sb0>
if you add serwb please put it in a branch, as it tends to increase development cycles
<sb0>
rjo, zotino monitoring?
<sb0>
rjo, actually, hmc830 not locking is expected right now, since we don't have the 100MHz input connected
<rjo>
sb0: well. it claimed to have lock twice.
<rjo>
anyway. if i ignore that it continues happily and identifies and configures the other chips.
<rjo>
sb0: i ported zotino monitoring. reasonably certain that's correct.
<rjo>
i.e. the things that were not yet explicitly tested with hardware with spi2 are zotino, zotino monitoring, nrtspimaster, nrtspimaster-over-drtio.
<GitHub96>
artiq/spi2 972980d Robert Jordens: RELEASE_NOTES: add note about spi2 port
<GitHub96>
artiq/spi2 d5a63ca Robert Jordens: kc705: switch backplane spi to spi2
<GitHub96>
artiq/spi2 17d9884 Robert Jordens: hmc830: spelling
<sb0>
cjbe, ^
<rjo>
cjbe, hartytp: let me know if there is something missing or not working.
<rjo>
sb0: the new spi2 core makes me very certain that the spi gateware is unlikely to be the culprit for the hmc830 not locking.
<rjo>
sb0: well. you should hook up the 100 mhz and see whether it is better now.
mumptai has quit [Remote host closed the connection]
<GitHub164>
[artiq] jonaskeller commented on issue #902: I don't have time at the moment to look into building it myself, so I'd rather wait for your bot for now. Once I have a compiled version, I'll give it a try. https://github.com/m-labs/artiq/issues/902#issuecomment-368063115
<GitHub163>
misoc/master bee272b Robert Jordens: spi2: wrong variable
<GitHub163>
misoc/master c7a97c5 Robert Jordens: spi: deprecate
hartytp has joined #m-labs
<GitHub72>
[artiq] gkasprow commented on issue #854: I will have a look on the signals with fast scope, but I need to have some transmission somehow working. Maybe we need to add some AC termination... https://github.com/m-labs/artiq/issues/854#issuecomment-368064931
<hartytp>
rjo: FWIW, I don't think the old SPI core can have been the problem with the HMC830
<hartytp>
we can read back all the correct default register values before programming
<hartytp>
and all the correct values after programming
<rjo>
hartytp: i agree.
<hartytp>
plus on SB's board it sometimes locks
<hartytp>
on mine it never does
<hartytp>
also, don't think the register values are the issue
<hartytp>
since we can get our eval board to lock fine (same goes for the LF not being the problem)
<hartytp>
FWIW, the input clock also looks fine as do the supply rails
<hartytp>
so, in short, I don't think anything is the problem
<GitHub147>
[artiq] whitequark commented on issue #854: @jordens I already fuzz smoltcp using LLVM's libfuzzer, that's much faster since it's coverage-guided. Might make sense for liteeth, not sure. https://github.com/m-labs/artiq/issues/854#issuecomment-368071731
<GitHub108>
[artiq] hartytp commented on issue #908: Having said that, there are still gaps in the middle of the working region, so it's hard to see any leveling algorithm being able to guarantee to work 100% of the time. ... https://github.com/m-labs/artiq/issues/908#issuecomment-368071805
<GitHub130>
[smoltcp] dlrobertson commented on pull request #167 6cf2c03: So then `NdiscPacket::new` would be something like `NdiscPacket::new(packet: Icmpv6Packet)`? It gets a bit tricky since the type id is in the ICMP header. https://github.com/m-labs/smoltcp/pull/167#discussion_r170352973
attie has quit [Remote host closed the connection]
attie has joined #m-labs
<cjbe>
sb0, rjo: have you got DRTIO working with fiber SFPs? If so, could you send me a link to the tranceivers you used?