<GitHub-m-labs>
[artiq] sbourdeauducq commented on issue #919: @whitequark I suspect your problems are due to incompatible or outdated RTM gateware. I just updated everything and it worked. The RTM gateware that you had loaded into the board was quite old.... https://github.com/m-labs/artiq/issues/919#issuecomment-377437843
<GitHub-m-labs>
[artiq] sbourdeauducq commented on issue #919: @whitequark I suspect your problems are due to incompatible or outdated RTM gateware. I just updated everything and it worked. The RTM gateware that you had loaded into the board was quite old.... https://github.com/m-labs/artiq/issues/919#issuecomment-377437843
rohitksingh has joined #m-labs
rohitksingh has quit [Quit: Leaving.]
rohitksingh has joined #m-labs
rohitksingh has quit [Quit: Leaving.]
cr1901_modern has quit [Read error: Connection reset by peer]
rohitksingh has joined #m-labs
<GitHub-m-labs>
[artiq] whitequark commented on issue #919: @sbourdeauducq No, I've built the gateware for the master branch at the time when I was testing after you told me that it was too old. Seems like random breakage. https://github.com/m-labs/artiq/issues/919#issuecomment-377474033
<GitHub-m-labs>
[artiq] whitequark commented on issue #948: > 11 ms is still almost one and a half million cycles – DWARF does take some time to parse, variable-length integers and all, but that still seems like a lot?... https://github.com/m-labs/artiq/issues/948#issuecomment-377475946
<GitHub24>
clang-or1k/artiq-6.0 0e62ce1 Simon Dardis: Revert "Reland "[mips] Teach the driver to accept -m(no-)gpopt.""...
<GitHub24>
clang-or1k/artiq-6.0 680fb28 Simon Dardis: Reland "[mips] Teach the driver to accept -m(no-)gpopt."...
<GitHub24>
clang-or1k/artiq-6.0 0d160eb Hans Wennborg: Revert r308441 "Recommit r308327: Add a warning for missing '#pragma pack (pop)' and suspicious uses of '#pragma pack' in included files"...
<GitHub-m-labs>
[artiq] whitequark commented on issue #636: @sbourdeauducq What do you think about mapping the RTIO registers to OR1K SPRs? I've just thought of a good way to expose those to LLVM; we can add a new address space so that accesses to SPRs are just pointer accesses and most optimizations still apply to them. https://github.com/m-labs/artiq/issues/636#issuecomment-377550993
<GitHub-m-labs>
[artiq] sbourdeauducq commented on issue #636: Why does that help, single-cycle access? What kind of interface would that have? Wouldn't that cause problems with ``now`` pinning? Wouldn't that cause timing issues in the FPGA? Also that contributes to breaking compatibility with other CPUs. Is it really worth it? https://github.com/m-labs/artiq/issues/636#issuecomment-377551573
<GitHub-m-labs>
[artiq] whitequark commented on issue #636: @dhslichter Something you can do to advance this is submit realistic benchmark code that I can profile. There might be inefficiencies that I don't currently expect in different parts of the stack. https://github.com/m-labs/artiq/issues/636#issuecomment-377554830
<GitHub-m-labs>
[artiq] dhslichter commented on issue #636: @sbourdeauducq I assume that the proposals for shaving time off RTIO submissions would also shave time off RTIO retrieval (i.e. from reading timestamps from an input FIFO). Is this accurate? https://github.com/m-labs/artiq/issues/636#issuecomment-377554859
<GitHub-m-labs>
[artiq] dhslichter commented on issue #636: @whitequark ack, I will send along some code for sideband cooling to give a sense of what we're up against, and to give you something to benchmark with. https://github.com/m-labs/artiq/issues/636#issuecomment-377554971
<sb0>
whitequark, I would imagine bus errors to be broken for *writes*, not reads... since there is the write buffer
<GitHub-m-labs>
[artiq] sbourdeauducq commented on issue #636: > I assume that the proposals for shaving time off RTIO submissions would also shave time off RTIO retrieval (i.e. from reading timestamps from an input FIFO). Is this accurate?... https://github.com/m-labs/artiq/issues/636#issuecomment-377556626
<GitHub-m-labs>
[artiq] whitequark commented on issue #636: > Not that much, it's basically a bit of system code, the exception handling/unwinder, and dealing with rustc/LLVM breakage that I cannot imagine will miss the opportunity to manifest itself. A lot of things are portable.... https://github.com/m-labs/artiq/issues/636#issuecomment-377559593
<GitHub-m-labs>
[artiq] whitequark commented on issue #636: > Not that much, it's basically a bit of system code, the exception handling/unwinder, and dealing with rustc/LLVM breakage that I cannot imagine will miss the opportunity to manifest itself. A lot of things are portable.... https://github.com/m-labs/artiq/issues/636#issuecomment-377559593
<GitHub-m-labs>
[artiq] whitequark commented on issue #636: > Not that much, it's basically a bit of system code, the exception handling/unwinder, and dealing with rustc/LLVM breakage that I cannot imagine will miss the opportunity to manifest itself. A lot of things are portable.... https://github.com/m-labs/artiq/issues/636#issuecomment-377559593
<GitHub-m-labs>
[artiq] sbourdeauducq commented on issue #636: For inputs, we can shave 1 programming register access, plus another one and (in the fast code path) some tests by using Wishbone bus wait/error states. https://github.com/m-labs/artiq/issues/636#issuecomment-377560795
<GitHub-m-labs>
[artiq] sbourdeauducq commented on issue #636: For inputs, in addition to ``now`` pinning, we can shave 1 programming register access, plus another one and (in the fast code path) some tests by using Wishbone bus wait/error states. https://github.com/m-labs/artiq/issues/636#issuecomment-377560795
<sb0>
whitequark, stekern, how can it work (and be precise) with the write buffer?
<GitHub21>
[smoltcp] podhrmic opened pull request #185: Initial commit for fragmentation support && Ethernet jumbo frames support (master...fragmentation) https://github.com/m-labs/smoltcp/pull/185
<GitHub7>
[smoltcp] podhrmic commented on pull request #185 2f6734f: This way the fragments are handled similarly to a socket set. Other option would be to have a fragment set attached to an interface, I am not sure which one is better. https://github.com/m-labs/smoltcp/pull/185#discussion_r178408053