cjbe__ has quit [Read error: Connection reset by peer]
<bb-m-labs>
build #291 of migen is complete: Exception [exception conda_build_output] Build details are at http://buildbot.m-labs.hk/builders/migen/builds/291 blamelist: Sebastien Bourdeauducq <sb@m-labs.hk>
<GitHub-m-labs>
[artiq] sbourdeauducq commented on issue #1080: @gkasprow @enjoy-digital any idea why that happens? The GTH quad imbalance is the same in both cases, and the number of crossed quads is within spec. https://github.com/m-labs/artiq/issues/1080#issuecomment-399949386
<GitHub-m-labs>
[artiq] sbourdeauducq commented on issue #1080: " a single external reference clock with multiple transceivers connected to multiple Quads. The user design connects the IBUDFS_GTE3 output (O) to the ***GTREFCLK0*** ports of the GTHE3/4_COMMON and GTHE3/4_CHANNEL primitives for the GTH transceiver. ... https://github.com/m-labs/artiq/issues/1080#issuecomment-399996208
<GitHub-m-labs>
[artiq] sbourdeauducq commented on issue #1080: No, that's unlikely to help. The other clock is either unrouted or routed to the other quad for DRTIO. And GTREFCLK0 is the correct setting as per the transceiver user guide I quoted above. https://github.com/m-labs/artiq/issues/1080#issuecomment-399997623
<sb0_>
bb-m-labs: force build --props=package=artiq-board,artiq_target=sayma_amc,artiq_variant=master artiq-board
<bb-m-labs>
build forced [ETA 39m11s]
<bb-m-labs>
I'll give a shout when the build finishes
<GitHub-m-labs>
[artiq] hartytp commented on issue #1065: @sbourdeauducq Holding the HMC7043 in reset breaks all kinds of things, and I don't want to spend time digging through and commenting them all out unless it's really important.... https://github.com/m-labs/artiq/issues/1065#issuecomment-400003199
hartytp has quit [Quit: Page closed]
<GitHub-m-labs>
[artiq] sbourdeauducq commented on issue #1065: > @sbourdeauducq Holding the HMC7043 in reset breaks all kinds of things, and I don't want to spend time digging through and commenting them all out unless it's really important.... https://github.com/m-labs/artiq/issues/1065#issuecomment-400004627
<GitHub-m-labs>
[artiq] sbourdeauducq commented on issue #1065: > @sbourdeauducq Holding the HMC7043 in reset breaks all kinds of things, and I don't want to spend time digging through and commenting them all out unless it's really important.... https://github.com/m-labs/artiq/issues/1065#issuecomment-400004627
<GitHub166>
[smoltcp] podhrmic commented on pull request #236 200ec19: I am not familiar with Ipv6 so I cannot comment on how similar to IPv4 it is. But it can be refactored in the future, if someone with more knowledge about Ipv6 can pitch in. I would keep it separate for now, better some fragmentation support than none:-) https://github.com/m-labs/smoltcp/pull/236#discussion_r197857557
<GitHub194>
[smoltcp] podhrmic commented on pull request #236 200ec19: There is a thread in the old PR where I tried to explain why `ManagedMap` doesn't work. In short, to insert a new packet to `ManagedMap` you need to allocate memory for it somewhere. And either you create a new `Vec<u8>` which is easy but requires `alloc`. Or you have a static buffers somewhere, and that effectively makes it a `ManagedSlice`.... http
<GitHub8>
[smoltcp] podhrmic commented on pull request #236 dcbc010: Edit: I realized even the `loopback.rs` example you have to run with at least `alloc` because of the `From` trait implementation. This definitely limits smoltcp's usage on bare metal systems:-( https://github.com/m-labs/smoltcp/pull/236#discussion_r197863000
<GitHub76>
[smoltcp] dlrobertson commented on pull request #236 dcbc010: > And either you create a new Vec<u8> which is easy but requires alloc. Or you have a static buffers somewhere, and that effectively makes it a ManagedSlice.... https://github.com/m-labs/smoltcp/pull/236#discussion_r197878819
<danman>
hi guys, I'm trying to add new target to misoc. Can you please tell me what CRG mean in class _CRG(Module) ?
danman has quit [Ping timeout: 260 seconds]
<GitHub-m-labs>
[artiq] philipkent commented on issue #888: @dhslichter We will be moving to ARTIQ 3 soon and we're planning on having to setup a development environment to compile gatewares with the expanded FIFO depths. Would it make sense to update the FIFO depth's in the pre-compiled gatewares in the nist_qc2 conda package for ARTIQ 3 to be at least 1024 sense that seems to be what everyone is using? https://github.
<GitHub-m-labs>
[artiq] dhslichter commented on issue #888: Yes, I think that sounds sensible. There are separate input and output FIFOs, and I would suggest that we would make better use of the resources available if we make the input FIFOs relatively small (say 128 or 256) except on a few special channels, when we make them much deeper (16k or so). Then we can hopefully fit 1024 on each output, which would be nice. @r-sri