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
<GitHub193>
[artiq] sbourdeauducq commented on issue #854: You did not send me a media converter - I'm using the 1000base-x converter I was using before, connected to the sata/sfp with a copper sfp cable. https://github.com/m-labs/artiq/issues/854#issuecomment-364308613
<sb0>
that capacitor seems to work on that board too
<GitHub103>
[smoltcp] canndrew commented on issue #156: > Why would you want that? If you want to use scatter-gather capabilities, just use separate buffers for EthernetFrame, Ipv4Packet, UdpPacket, etc. You can do that right now. Splitting the 14-byte Ethernet header over multiple buffers does not appear useful to me.... https://github.com/m-labs/smoltcp/issues/156#issuecomment-364363471
attie has quit [Ping timeout: 276 seconds]
attie has joined #m-labs
rohitksingh has joined #m-labs
mumptai has quit [Remote host closed the connection]
<TKU8VTbummer>
s i r u f j a e c k e l g r i c U l t r a s a u c e _ w h i t e l o g g e r b a l r o g c e d r i c h j r 3 w h i t e q u a r k s t e k e r n k u l d e e p o h s i x X - S c a l e a w y g l e b b - m - l a b s f o r r e s t v G u r t y R e x O r C i n e
sb0 has joined #m-labs
<sb0>
rjo, is 49MHz better?
<GitHub7>
[smoltcp] whitequark commented on issue #156: > If I can't just store an entire frame in an EthernetFrame<_> the I need to make my own wrapper type that I can keep a queue of - something like:... https://github.com/m-labs/smoltcp/issues/156#issuecomment-364401083
<larsc>
because somebody else already went through 10 iterations of problems with the adi fmc card before it was shipped ;)
<sb0>
yeah we should have just copied the kc705+adi schematics, most of the time spent on sayma is spent yak-shaving; delays, constant stream of bugs, and it's incredibly annoying
<sb0>
also those ultrascale fpgas are slow to compile for and buggy
<GitHub58>
[artiq] gkasprow commented on issue #919: @sbourdeauducq I didn't look where the problem happened. I tested binaries only. Could be either migen or Vivado. That's true, my statement was not precise :) In vivado you can have mixture of settings that treat differently such statements so it may not be a bug.... https://github.com/m-labs/artiq/issues/919#issuecomment-364459790
<GitHub13>
[artiq] gkasprow commented on issue #919: @sbourdeauducq I didn't look where the problem happened. I tested binaries only. Could be either migen or Vivado. That's true, my statement was not precise :) In vivado you can have mixture of settings that treat differently such statements so it may not be a bug.... https://github.com/m-labs/artiq/issues/919#issuecomment-364459790
<GitHub66>
[smoltcp] whitequark commented on pull request #140 c3f6a2b: Also, I suggest calling this something like `enqueue`, moving the non-padding packet enqueueing code in, adding the `enqueue_many` call at the end, and making it return a `Result<&mut [u8]>` with the payload slice, this will reduce duplication below. https://github.com/m-labs/smoltcp/pull/140#discussion_r167279521
<GitHub73>
[smoltcp] whitequark commented on pull request #140 c3f6a2b: I don't think this function has the correct implementation. Shouldn't it be a logical AND? A buffer with a single zero-sized packet is not empty. https://github.com/m-labs/smoltcp/pull/140#discussion_r167277258
<GitHub182>
[smoltcp] whitequark commented on pull request #140 c3f6a2b: The control flow here is confusing. I think you can inline one `check_capacity` invocation, remove the second, and rewrite the condition to something like...... https://github.com/m-labs/smoltcp/pull/140#discussion_r167278625
mumptai has quit [Remote host closed the connection]
rohitksingh has quit [Read error: Connection reset by peer]
rohitksingh has joined #m-labs
attie has quit [Ping timeout: 240 seconds]
attie has joined #m-labs
<GitHub195>
[artiq] gkasprow commented on issue #919: I didn't play with them, my colleague (@wzab) told me that one had similar case in the past. And it was some option to change behaviour. But anyway, there is certainly an issue with this Artix chip, at least with one of the pins. To check it, route the pins that you want to bind to vcc/gnd to the register and write the value you want to have. This solved an issue in my case
<GitHub86>
[artiq] gkasprow commented on issue #919: I didn't play with them, my colleague (@wzab) told me that one had similar case in the past. And it was some option to change behaviour. But anyway, there is certainly an issue with this Artix chip, at least with one of the pins. To check it, route the pins that you want to bind to vcc/gnd to the register and write the value you want to have. This solved the issue in my case.
<GitHub87>
[artiq] gkasprow commented on issue #919: I didn't play with them, my colleague (@wzab) told me that once had similar case in the past. And it was some option to change behaviour. But anyway, there is certainly an issue with this Artix chip, at least with one of the pins. To check it, route the pins that you want to bind to vcc/gnd to the register and write the value you want to have. This solved the issue in my case
<GitHub180>
[artiq] gkasprow commented on issue #919: I didn't play with them, my colleague (@wzab) told me that once had similar case in the past. And it was some option to change the compiler behaviour. But anyway, there is certainly an issue with this Artix chip, at least with one of the pins. To check it, route the pins that you want to bind to vcc/gnd to the register and write the value you want to have. This solved the i
<GitHub41>
[artiq] whitequark commented on issue #902: I've looked at your packet capture. This is very weird; I was not able to crash smoltcp locally. I will add an option to ARTIQ to print a packet trace. https://github.com/m-labs/artiq/issues/902#issuecomment-364502832
<GitHub7>
[smoltcp] dlrobertson commented on issue #75: Due to the addition of `proto-ipv6` since DHCP is IPv4 only the module and `pub use` should probably be `#[cfg(feature = "proto-ipv4")]`. Speaking of that, should the module be dhcpv4? https://github.com/m-labs/smoltcp/pull/75#issuecomment-364503410
<GitHub52>
[smoltcp] dlrobertson commented on pull request #141 8f6fe3f: It makes use of [SystemTime::duration_since] which returns a result type. Now that I'm looking at it, would it make more sense if `Instant::from_system_time` used [SystemTIme::elapsed] instead of [SystemTime::duration_since] the [UNIX_EPOCH]? Or would it make sense to have a `Instant::elapsed()`?... https://github.com/m-labs/smoltcp/pull/141#discuss
<GitHub138>
[smoltcp] whitequark commented on pull request #141 8f6fe3f: It should just use `duration_since(UNIX_EPOCH).unwrap()`. I am not interested in handling cases where the time is less than UNIX epoch. The only such case is badly misconfigured (i.e. non-UTC timezone) systems without an RTC battery or ntpd. https://github.com/m-labs/smoltcp/pull/141#discussion_r167301615
<GitHub147>
artiq/master 180c285 Florent Kermarrec: drtio/gateware/transceiver/gtp_7series: add power down state before reset on rx (seems to make restart reliable)
<bb-m-labs>
build #2035 of artiq is complete: Failure [failed python_coverage_1] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/2035 blamelist: Florent Kermarrec <florent@enjoy-digital.fr>
Rex0r has joined #m-labs
RexOrCine has quit [Ping timeout: 256 seconds]
Rex0r has quit [Quit: Leaving]
RexOrCine has joined #m-labs
cr1901_modern has joined #m-labs
cr1901_modern1 has quit [Ping timeout: 240 seconds]