<GitHub69>
[smoltcp] whitequark commented on pull request #72 f96e199: The easiest way to make this parser much simpler would be to make it recursive. Here's an outline:... https://git.io/vFrrB
<GitHub187>
[smoltcp] whitequark pushed 3 new commits to master: https://git.io/vFrrz
<GitHub187>
smoltcp/master 1979072 whitequark: Remove impl Ord/PartialOrd for Cidr....
<GitHub119>
[smoltcp] whitequark commented on pull request #72 f96e199: Do you really need a macro for something that will be used exactly once? Just expand it with copy/paste, it's more clear how it works then. https://git.io/vFrr1
<GitHub80>
[smoltcp] whitequark commented on pull request #65 aaf9ca5: I am sure that you have discovered a real issue, but I do not seem to understand your explanation. Do you think you could expand on it or rephrase it in a different way? https://git.io/vFrrd
<GitHub105>
[smoltcp] dlrobertson commented on commit ffcd3ab: Nice! https://git.io/vFroO
<GitHub45>
[smoltcp] whitequark commented on issue #78: > By the way, why do we break from the loop in socket_egress on Error::Unaddressable? There could be other sockets left with endpoints resolved, and by breaking here we prevent them from sending packets until all the sockets before them have their destinations resolved.... https://git.io/vFro0
<sb0>
_florent_, can you make up for the delays please?
<GitHub0>
[smoltcp] whitequark commented on commit ffcd3ab: Oh I misunderstood the context. Thanks, fixed. https://git.io/vFroV
<GitHub67>
[smoltcp] dlrobertson commented on commit ffcd3ab: Np. https://git.io/vFror
<travis-ci>
m-labs/smoltcp#401 (master - 9b98dfa : whitequark): The build passed.
<GitHub115>
[smoltcp] dlrobertson commented on pull request #72 29ea1e3: Nah, just being lazy. Updated. https://git.io/vFroy
<GitHub142>
[smoltcp] dlrobertson commented on pull request #72 29ea1e3: Can we rely on `(self.pos == self.data.len()) == true` event for a CIDR? I thought for the current implementation I just had to hand processing over as soon as I hit a non-number in the second parsing round or when I filled the addr buffer. Either way, adding that to the above would be pretty easy and this is def more readable. I'll work on this tomorrow after I get some sleep. I ne
<GitHub93>
[smoltcp] dlrobertson commented on pull request #72 29ea1e3: Can we rely on `(self.pos == self.data.len()) == true` event for a CIDR? I thought for the current implementation I just had to hand processing over as soon as I hit a non-number in the second parsing round (if `is_cidr` is true) or when I filled the addr buffer. Either way, adding that to the above would be pretty easy and this is def more readable. I'll work on this tomorrow after I
<GitHub44>
[smoltcp] whitequark commented on pull request #72 29ea1e3: Oh I guess you can look ahead for whether there's a `:` and bail out if there is not, instead of looking for EOF. https://git.io/vFrKI
<GitHub106>
[smoltcp] batonius commented on pull request #78 bca2dbe: As far as I understand, since `ICMPv4` and `ICMPv6` are somewhat different (unlike TCP and UDP), this match guarantees we respond to an `ICMPv4` packet with `ICMPv4`. Specifically, we shouldn't return `Packet::Icmpv4` for IPv6 packets. https://git.io/vFryz
bb-m-labs has quit [Quit: buildmaster reconfigured: bot disconnecting]
<GitHub115>
[smoltcp] pothos commented on issue #65: Hello,... https://git.io/vFrQo
<rjo>
cr1901_modern: that's too complicated. you don't want to test random migen/fhdl functionality. you could do (1) an empty module and make verilog for all the toolchains we have (2) a single asyncresetsynchronizer on all toolchains (3) a single multireg on all platforms
<_florent_>
sb0: yes i'm trying to do my best (i already spent lots of time understanding what is going on with serwb), for some builds it's always working, for others not. It's related to rx on sayma amc. I'm also trying to find a fallback solution (reduced speed?) to allow you to at least use things.
slava_ has joined #m-labs
<sb0>
rjo, why is the Urukul output limited to 200MHz? the DDS are 1GSPS. the SYSU guys want 250MHz
<sb0>
or is it that 200MHz is just what opticlock needs?
<sb0>
(and the actual limit is higher)
<rjo>
where does it say that?
<rjo>
the outputs will go to ~400 MHz
<rjo>
but yes. that was a spec requirement for opticlock.
<sb0>
the wiki is a bit unclear "Highest output frequency (first Nyquist zone): 200 MHz"
<sb0>
the mention of the nyquist zone makes it sound like it's a hardware limitation and not what opticlock needs
<rjo>
ack.
<sb0>
I found out why the ethernet carrier was not detected on our Saymas: Greg's cable was damaged, plus our idiotic media converter only takes into account the SFP EEPROM to determine SFP link status, plus Greg's cable has this EEPROM removed
<rjo>
i am rewriting that wiki page now.
<sb0>
connecting a SFP with nothing on the other end makes it light its link status LED ...
<sb0>
anyway plugging a fs.com SFP copper cable makes this thing detect the link
<sb0>
I will solder a SATA connector on the other end
<sb0>
this trenz-electronic thing is not only expensive, but it also has the problem of host vs. device SATA pinout
rohitksingh_work has quit [Read error: Connection reset by peer]
<sb0>
inside the cable I brought from the US, the SATA cable solders to the SFP PCB were completely ripped out
<sb0>
I don't know how that happened, that cable was working in the US and I did not mistreat it
<rjo>
To me it didn't look like it would survive. Was there any torsional or axial strain relief on that hack?
<sb0>
the SATA cable was glued to the PCB. the glue broke and then the solders followed. the connection between the SATA cable and the PCB were made using some fine flexible wire, and that just broke...
<sb0>
soldering a SFP copper cable cut in half to a male (motherboard/drive) SATA connector sounds solid enough, though
<sb0>
rjo, what is the plan for generating both DDS REFCLK and the FPGA RTIO clock with Kasli/Urukul on opticlock?
<rjo>
dds refclk == fpga rtio clock
<rjo>
and we probably won't have to bother with synchronizing (SYSCLK to RTIO time). i.e. update jitter is not an issue.
<sb0>
er, SYSCLK
<cr1901_modern>
rjo: Ack. Would you be willing to merge my two current PRs if you don't have any issues (in order of "Icestorm Improvements", "TinyFPGA") if you don't have any other changes requested?
<cr1901_modern>
I have a number of branches on my laptop with non-overlapping functionality that I'd like to get rid of
<cr1901_modern>
I'll get right on the "add unit tests" pull and just rebase when you're ready
<rjo>
cr1901_modern: convince sb0
<cr1901_modern>
sb0: So, IceStorm backend has been improved in a number of ways, including changing how commands are constructed for icestorm to run, as well as adding things like >>
<cr1901_modern>
AsyncResetSynchronizer. I also added a new platform TinyFPGA (so I can test something for mithro). TinyFPGA-B PR depends on my icestorm improvements. >>
<GitHub88>
[migen] sbourdeauducq pushed 20 new commits to master: https://git.io/vFoOZ
<GitHub88>
migen/master 6767966 William D. Jones: lattice/icestorm: Add attribute support (keep).
<GitHub88>
migen/master c09edd4 William D. Jones: lattice/icestorm: Convert keep attribute to yosys format.
<GitHub88>
migen/master 2e5bf6f William D. Jones: lattice/icestorm Add new supported targets in arachne-pnr (as of 7e135ed).
<cr1901_modern>
oh nevermind
<GitHub5>
[migen] sbourdeauducq pushed 2 new commits to master: https://git.io/vFoOE
<GitHub5>
migen/master a728e6a William D. Jones: build/platforms: Add tinyfpga_b platform and programmer.
<GitHub5>
migen/master 71a4844 William D. Jones: lattice/programmer: Add boot() method to TinyFpgaBProgrammer.
<cr1901_modern>
sb0: I was under the impression you might want all of the backends to be updated to "pass toolchain commands and binaries to execute" using lists before merging.
<sb0>
cr1901_modern, does it make sense in the other backends?
<sb0>
cr1901_modern, yes. figuring out a cleaner way for all platforms would be nice. you're very welcome to submit another PR with that
<cr1901_modern>
sb0: Will do, but I don't have Vivado installed and it's not practical for me to do so atm (disk space). So I can refactor the code, but can't actually test right now. Will send a pull for ISE though.
rohitksingh has joined #m-labs
<sb0>
why are sfp cages and connectors sold separately?
<GitHub158>
[smoltcp] whitequark closed pull request #78: Don't end ICMP packet processing with ICMP sockets. Ignore `Error::Unaddressable` for ICMP sockets. (master...icmp_socket_passthru) https://git.io/vFr3F
<GitHub98>
[smoltcp] whitequark pushed 2 new commits to master: https://git.io/vFolu
<GitHub98>
smoltcp/master 907f365 Egor Karavaev: Make `Error::Unaddressable` ignored for ICMP sockets as well.
<whitequark>
sb0: fixing a ManagedMap issue right now
<sb0>
what is ManagedMap?
<sb0>
ah, some rust-managed feature
<sb0>
"It also requires the use of a nightly compiler" << so there will be another risky rustc upgrade before the ARP issue is fixed?
<whitequark>
no
<whitequark>
our compiler has always been nightly
<whitequark>
no upgrades needed
<whitequark>
that's for other people who want to use rust-managed (if any)
<whitequark>
sb0: "nightly" rust compiler means "rust compiler that lets you use unstable features"
<whitequark>
and most features needed for bringing up an embedded system are unstable
<whitequark>
like inline assembly
<whitequark>
so artiqwill be stuck on nightly for foreseeable future anyway
<whitequark>
that's fine though, rustc has a far higher bar for "stable" than we need
<rjo>
sb0: for the cages there are lots of options on cooling, mounting, arrangement while the edge connectors are all the same. and splitting surface mount (connector) from through hole (cage) is pretty much a fabrication requirement.
<GitHub17>
[smoltcp] whitequark commented on issue #55: * I've realized that using an EthernetInterface for loopback is, of course, a wrong approach, and we should have a LoopbackInterface for that.... https://git.io/vForZ
<GitHub46>
[smoltcp] whitequark commented on issue #55: * I've realized that using an EthernetInterface for loopback is, of course, a wrong approach, and we should have a LoopbackInterface for that. This precludes your approach since a LoopbackInterface doesn't *need* a `Device`; it only ever needs a single buffer, and every egress packet gets immediately squeezed back in.... https://git.io/vForZ
<sb0>
did someone check that one kasli and 8 eems fit in a 19-inch box?
<rjo>
mechanically?
<sb0>
yes
<rjo>
what do you mean?
<sb0>
is there enough space for all the front panels?
<rjo>
yes.
Hartytp has joined #m-labs
<Hartytp>
19 inch box is about 84U
<Hartytp>
Biggest EEM is 8u
<Hartytp>
Many take more than 1 idc
<Hartytp>
Fyi there is room for 2 x 16ch nu servo in a standard rack
Hartytp has quit [Ping timeout: 260 seconds]
<cr1901_modern>
sb0: Do your spartan 3 RE notes still exist anywhere (out of curiosity)?
<sb0>
spartan 3?
<cr1901_modern>
Yea, I think it was you who did some RE for S3
<cr1901_modern>
Am I misremembering?
<cr1901_modern>
Ahh small wonder I couldn't find it
<cr1901_modern>
A. It was Spartan 6
<cr1901_modern>
B. I was looking for "lekernel", not your current name
<GitHub24>
[smoltcp] whitequark commented on pull request #65 40133c9: I don't understand how wrapping is relevant here. TCP sequence numbers are compared modulo 2³². Specifically, `TcpSeqNumber(i32::MAX - 6) - TcpSeqNumber(i32::MAX - 3)` equals `TcpSeqNumber(-6) - TcpSeqNumber(-3)`.... https://github.com/m-labs/smoltcp/pull/65#discussion_r150620591
stekern has quit [Ping timeout: 268 seconds]
stekern has joined #m-labs
rohitksingh has quit [Read error: Connection reset by peer]
rohitksingh has joined #m-labs
<GitHub35>
[smoltcp] dlrobertson commented on pull request #72 89e2403: Updated to use the recursive method and used `lookahead_char` instead of `is_cidr`. IMO it makes it less confusing and there are less mutable variables you need to keep track of. https://github.com/m-labs/smoltcp/pull/72#discussion_r150669443
<GitHub28>
[smoltcp] dlrobertson commented on pull request #72 7a4fc0d: This particular branch is really only applicable to CIDRs (specifically one with a double colon before the prefix e.g. `fe80::/64`), so maybe I should reintroduce `is_cidr` then https://github.com/m-labs/smoltcp/pull/72#discussion_r150687100