<GitHub89>
[artiq] sbourdeauducq commented on issue #854: There are also RGMII FMC cards. The chipscope trace with Greg's bitstream is only marginally useful, it merely checks that the hardware is working. Better look at the signals at different points in our PHY. https://github.com/m-labs/artiq/issues/854#issuecomment-351879414
<GitHub150>
[artiq] gkasprow commented on issue #854: @sbourdeauducq cannot you attach a chipscope to your design? You have the verilog as the design entry for synthesizer, so should be relatively easy to add chipscope to look at the signals in your core. https://github.com/m-labs/artiq/issues/854#issuecomment-351943434
<sb0>
si also has the good taste of leaving power-down modes disabled at reset, so that the chip works by default and then only power-conscious users have to deal with that and in due time (not while debugging at the beginning)...
<sb0>
unfortunately this design decision is pretty much the exception with silicon vendors
<sb0>
put that on some FPGA, replace the GT garbage with the saner IOSERDES...
<sb0>
you even get a locking indicator, which xilinx still can't get to work
<GitHub93>
[artiq] jordens commented on issue #872: Our workflow will continue this way. This is neither a democracy nor a therapeutic session. You need to figure out how to cope with duplicate, out-of-place issues being closed. Ask yourself whether your behavior makes ARTIQ or Sinara better. https://github.com/m-labs/artiq/issues/872#issuecomment-351951443
<GitHub63>
[artiq] sbourdeauducq commented on issue #854: This mess even contains at least 2 copies of the RGMII pin definitions, which is something I wanted to double check. Which one did you use? https://github.com/m-labs/artiq/issues/854#issuecomment-351961842
<GitHub146>
[artiq] sbourdeauducq commented on issue #854: Again, Chipscope is of limited usefulness and like all Xilinx software is a pain to set up, so I'm not going to use it for now. I want to compare your design with mine. https://github.com/m-labs/artiq/issues/854#issuecomment-351976797
<GitHub193>
[artiq] sbourdeauducq commented on issue #854: @gkasprow Is it acceptable to use the RX clock as the TX clock? Back in August your reference code did that, but you changed that in this version. Why? https://github.com/m-labs/artiq/issues/854#issuecomment-351979275
<GitHub167>
[artiq] gkasprow commented on issue #854: It should work, I changed it because had problems with ipbus core and tried many things to fix it. I found the problem which was not caused by the clock connection. https://github.com/m-labs/artiq/issues/854#issuecomment-351980091
<GitHub115>
[artiq] sbourdeauducq commented on issue #854: Hmm, it's not clear to me what is the reference clock in that case. It's like putting two transceivers with loop timing back-to-back. Or does the PHY chip include appropriate clock correction? https://github.com/m-labs/artiq/issues/854#issuecomment-351980404
<GitHub110>
[artiq] sbourdeauducq commented on issue #854: Why did you clock all the ``IDDRE2`` with the inverted clock ``gmii_rx_clk_b``? The registers that follow it are clocked by the non-inverted clock ``gmii_rx_clk``. This is an unusual thing to do and it results in unnecessarily short timing paths inside the FPGA. Does it work when clocking ``IDDRE2`` with the non-inverted clock and swapping ``q1`` and ``q2`.` https:/
<GitHub164>
[artiq] sbourdeauducq commented on issue #854: Why did you clock all the ``IDDRE2`` with the inverted clock ``gmii_rx_clk_b``? The registers that follow it are clocked by the non-inverted clock ``gmii_rx_clk``. This is an unusual thing to do and it results in unnecessarily short timing paths inside the FPGA. Does it work when clocking ``IDDRE2`` with the non-inverted clock and swapping ``q1`` and ``q2``? https:/
<GitHub178>
[artiq] sbourdeauducq commented on issue #854: Why did you clock all the ``IDDRE1`` with the inverted clock ``gmii_rx_clk_b``? The registers that follow it are clocked by the non-inverted clock ``gmii_rx_clk``. This is an unusual thing to do and it results in unnecessarily short timing paths inside the FPGA. Does it work when clocking ``IDDRE1`` with the non-inverted clock and swapping ``q1`` and ``q2``?... http
<GitHub133>
[artiq] jbqubit commented on issue #873: Sure, I can see in this case that this is more likely a hardware related Issue. I appreciate that you'd prefer to not have it cluttering ARTIQ. However, closing miss-filed Issue without first confirming that they've been properly transferred to a different Issue system risks loosing track of bugs. Please don't do this. https://github.com/m-labs/artiq/issues/873#issuecomm
<GitHub11>
[artiq] sbourdeauducq commented on issue #872: We filed the issue, Greg was informed and sounds very capable of fixing it, and until he does it we set up a rapid workaround to reduce its impact on our productivity. I don't see what the problem is here. https://github.com/m-labs/artiq/issues/872#issuecomment-352032432
<sb0>
whitequark, reads of registers > 8-bit on CSR are not atomic
<whitequark>
sb0: voting to switch to 32-bit CSR bus, I would really rather not think about this, and it makes code generation much more efficient too for CSRs
<cr1901_modern>
Isn't the CSR bus width configurable anyway?
<sb0>
whitequark, ok, do you want to do that after you've fixed the networking bugs?
<cr1901_modern>
(Or are you getting rid of the user-configurability?)
<sb0>
enough for today, if someone wants to continue the ethernet bug hunting, the media converter is connected on sayma2
<whitequark>
sb0: I'll think about it
<whitequark>
sb0: do you think these ethernet bugs could impact our usual nist_clock configuration?
<whitequark>
I was getting some dropped and truncated packets where I don't think I should have
<whitequark>
been refactoring smoltcp to better indicate those errors today
<GitHub153>
[artiq] jbqubit commented on issue #872: @sbourdeauducq M-Labs is responsible for tracking the overall project and ensuring that dependent parties are giving due attention to Issues. In this case it's gone unattended since August. Please work with WUT to address it. https://github.com/m-labs/artiq/issues/872#issuecomment-352049152
<sb0>
rjo, remind me - is the si5324 used for drtio mastering with sayma? if not, we can send the ethernet rx clock through it so that vivado stops complaining (and potentially fuck things up like ISE randomly did for spartan6 in this case) about not using a clock-capable pin
<sb0>
whitequark, can you generate a si5324 config for 125MHz in, 125MHz out, and maximum loop bandwidth?
<sb0>
there are so many things on sayma... is there anything else that can act as a buffer for connecting to a clock-capable pin?
<whitequark>
sb0: tomorrow, that VM is a pain in the ass to boot, I only have it in the backups I think
rohitksingh has quit [Quit: Leaving.]
Gurty has quit [Remote host closed the connection]
Gurty has joined #m-labs
Gurty has quit [Changing host]
Gurty has joined #m-labs
<GitHub63>
[artiq] klickverbot opened pull request #875: dashboard: Restore minimized experiments when trying to open them again (master...restore-minimized) https://github.com/m-labs/artiq/pull/875
<GitHub0>
artiq/master c3c13da David Nadlinger: dashboard: Restore minimized experiments when trying to open them again...
<GitHub176>
[artiq] klickverbot closed pull request #875: dashboard: Restore minimized experiments when trying to open them again (master...restore-minimized) https://github.com/m-labs/artiq/pull/875
blinky has quit [Quit: Page closed]
<GitHub113>
[artiq] dhslichter commented on issue #867: It would also be useful to have documentation covering the architecture, both in overview and medium level detail, of how all the various processes are spawned, communicate, etc within ARTIQ -- workers, master, applets, compiler, etc. This is not something most users should touch or care about, but there are instances when I definitely wish I knew a bit more of what was g
<GitHub162>
[smoltcp] jonaskeller commented on issue #93: Just an update: Last time it got triggered, it stopped after ~10 requests (without ever getting a reply). I'll keep monitoring it, but given the low rate of trigger events, it might take a long time before I get a chance to observe it again. If you have any hints on how to provoke it, I'm happy to try things out. https://github.com/m-labs/smoltcp/issues/93#issuecomme