<GitHub147>
[artiq] gkasprow commented on issue #854: On other AMC boards I use single-chip Ethernet switch that has RGMII on two ports, RMII or MII on one port, 2x RJ45 and 2x 1000BASE-X/SGMII. It does not need any configuration, just pin-straps. It costs 17$.... https://github.com/m-labs/artiq/issues/854#issuecomment-358150990
<GitHub42>
[artiq] gkasprow commented on issue #854: I will attach tiny Arduino board to my SFP media converter that will switch the SFP module to SGMII mode. This should help and let @sbourdeauducq continue his work https://github.com/m-labs/artiq/issues/854#issuecomment-358152514
_whitelogger has joined #m-labs
<whitequark>
sb0: is it normal that on sayma3 hmc830 lock times out?
<whitequark>
hopefully by the time I'm done with that sayma has working ethernet
<GitHub151>
[artiq] sbourdeauducq commented on issue #894: I don't see how this can happen and I cannot reproduce it. Are you sure the command you ran is just ``artiq_flash -t kc705 -m nist_clock``?... https://github.com/m-labs/artiq/issues/894#issuecomment-358168134
<whitequark>
sb0: a couple of questions
<whitequark>
1. how hard it is to get timing closure if I route a reset line from ethmac (or rather, a module inserted into datapath of ethmac) to the mor1kx core?
<whitequark>
it could be heavily registered for all i know
<GitHub166>
[artiq] sbourdeauducq commented on issue #894: I don't see how this can happen and I cannot reproduce it. Are you sure the command you ran is just ``artiq_flash -t kc705 -m nist_clock``?... https://github.com/m-labs/artiq/issues/894#issuecomment-358168134
<whitequark>
2. how bad of an idea would it be to add an NMI to mor1kx? just resetting it loses the contents of registers
<sb0>
whitequark, I don't think those are priorities right now
<sb0>
rather, you could help making ethernet work on sayma.
<sb0>
or the allaki attenuator
<whitequark>
is allaki blocking something important?
<sb0>
yes
<whitequark>
oh, you should have said so right away
<whitequark>
okay then
<sb0>
it gets in the way of getting rf from sayma
<whitequark>
let me do allaki first
<whitequark>
still, I'd like to discuss manageability because the current situation sucks
<whitequark>
I've thought a lot about it meanwhile and basically here's where I arrived:
<sb0>
why not just reload the bitstream?
<sb0>
RTM FPGA loading (and generally all work specific to the new hardware) is also quite important. did you get it to work?
<whitequark>
that's how I arrived at manageability again, actually
<sb0>
why do you need all those extensions to write firmware that pushes a binary over a simple serial interface?
<whitequark>
sigh
<whitequark>
I'm trying to make a coherent system where all maintenance can be done through a single TCP endpoint without having to fuck with openocd bugs
<whitequark>
sure, all of your short-term hacks work
<whitequark>
that doesn't mean they work very well or have a good experience
<sb0>
I didn't notice "openocd" bugs on Florent's sayma yet
<sb0>
and your proposal requires ethernet, which doesn't work at the moment
<whitequark>
you didn't even listen to my proposal
<whitequark>
because I have not actually said what I want.
<sb0>
you did say that it needs ethernet, so it's already moot
<whitequark>
well sure I can help with ethernet on sayma first, if you think I can indeed help there
<sb0>
when are you coming back? that may need some board rework
<GitHub64>
[artiq] TheCakeIsAPi commented on issue #893: Output of ```conda list``` in question. Did I somehow end up with artiq 2.5? I used "git checkout 3.2" on the cloned repository when creating my environment.... https://github.com/m-labs/artiq/issues/893#issuecomment-358171007
<whitequark>
I'm not sure if I can do fine SMD work anymore, tricyclics fucked something about muscle control
<whitequark>
though I'm not on them anymore so it might be back
<whitequark>
in any case I'm still sick enough that I really don't want to fly anywhere for 8+ hours
<GitHub52>
[artiq] sbourdeauducq commented on issue #894: @TheCakeIsAPi What happened is conda installed ``artiq`` in ``C:\Users\monroe\Miniconda3\envs\artiq-dev\lib\site-packages\artiq`` and ``artiq-kc705-nist_clock`` a different directory, in ``C:\Users\monroe\Miniconda3\envs\artiq-dev\Lib\python3.5\site-packages\artiq``.... https://github.com/m-labs/artiq/issues/894#issuecomment-358171482
<GitHub27>
[artiq] sbourdeauducq commented on issue #894: @TheCakeIsAPi What happened is conda installed ``artiq`` in ``...\artiq-dev\lib\site-packages\artiq`` and ``artiq-kc705-nist_clock`` in a different directory, ``...\artiq-dev\Lib\python3.5\site-packages\artiq``.... https://github.com/m-labs/artiq/issues/894#issuecomment-358171482
<GitHub69>
[artiq] whitequark commented on issue #893: Conda installed packages and your git checkout are completely independent of each other. Also, artiq-dev 3+ is not available on Windows because we do not build the Rust components for it.... https://github.com/m-labs/artiq/issues/893#issuecomment-358172159
<GitHub77>
[artiq] TheCakeIsAPi commented on issue #894: Not sure why. I would say the bug is in the artiq-kc705-nist_clock package, because it is the only thing at all in ```Lib\python3.5``` Everything else is in ```Lib\site-packages``` https://github.com/m-labs/artiq/issues/894#issuecomment-358172208
<sb0>
no loss of lock and seems stable (except in the common case when JTAG is broken)
<sb0>
I soldered a 0603 50R resistor in the SMP I'm not using
<hartytp>
do you think that commit is what's wrong with my board? Should I retry with it?
<sb0>
ah also different frequencies on each DAC channels...
<sb0>
which is what the code should be doing. so everything works well.
<sb0>
no DAC failure observed so far...
<hartytp>
great work guys!
<hartytp>
That's really wonderful
<hartytp>
So,... a trash fire with RF? I'll take that ;)
hartytp has quit [Ping timeout: 260 seconds]
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
<sb0>
yeah, meanwhile I cannot test my rgmii ethernet rework because 1.8V systematically fails in the middle of flashing. already at the 15th attempt or so ..
<rjo>
cjbe: the cisco ones (https://www.fs.com/products/11802.html) also work and don't have an eeprom. given that the "FS P/N" is the same (SFP-GE-BX and SFP-GB-GE-T) and given that they are externally the same and have the same markings, i suspect that they are actually the same. i.e. the cisco branded ones from fs.com are the same as their generic ones.
<GitHub63>
[artiq] sbourdeauducq commented on issue #854: Ethernet works with RGMII, your suggested board rework, and forthcoming MiSoC commits (add 1.25ns of delay on data and rxctl via IDELAYE3). https://github.com/m-labs/artiq/issues/854#issuecomment-358270858
<rjo>
_florent_: nice! great work! could you try --with-sawg and check whether the example outputs something useful?
<whitequark>
sb0: oh *excellent*
<rjo>
_florent_: also the honor to post that result to the mailing list and the issues is yours. many people will be delighted.
<bb-m-labs>
build #1950 of artiq is complete: Failure [failed python_coverage] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/1950 blamelist: Florent Kermarrec <florent@enjoy-digital.fr>
<_florent_>
rjo: ok we will give a try to --with-sawg, you can post the result to the mailing list, excepting bringing with my a board that works, i haven't done anything special to unlock that :)
<sb0>
our screenshot is ugly due to poor scope probe connection
<sb0>
no allaki yet...
<_florent_>
rjo: for the sawg target, do we need to do anything special to control it? or just initialize the jesd?
<rjo>
_florent_: it's the same procedure as without --with-sawg. then, in addition, you need to artiq_compile the example and flash it as idle_kernel (or use ethernet and artiq_run if that works now).
<rjo>
_florent_: it only replaces the dumb sawtoooth generators with proper SAWG RTIO channels.
<sb0>
Florent's board is the only one on which that works, and to get ethernet we need to rework the board and touch the RTM connector, the typical result of which is 30min wasted to get JTAG working again
<GitHub48>
artiq/master 3313e99 whitequark: test: fix test_worker to work when deprecation warnings are emitted.
<sb0>
whitequark, what were those deprecation warnings?
<sb0>
and your fix assumes that the deprecation warnings are never in message 0 ...
<whitequark>
oh, crap
<whitequark>
it should be the other way around
<whitequark>
sb0: you can see them in the log.
<whitequark>
/var/lib/buildbot/slaves/debian-stretch-amd64-1/miniconda/envs/buildbot-artiq-1950/lib/python3.5/site-packages/h5py/__init__.py:36: FutureWarning: Conversion of the second argument of issubdtype from `float` to `np.floating` is deprecated. In future, it will be treated as `np.float64 == np.dtype(float).type`.
<GitHub132>
[smoltcp] hjr3 commented on issue #125: @dlrobertson here is my PR for `Pad1` and `PadN`. If you see major problems, ping me and I can hop on IRC. I have two _TODO_ items to figure out, but they should not cause major change to the PR as-is. https://github.com/m-labs/smoltcp/pull/125#issuecomment-358350635
hartytp has joined #m-labs
<hartytp>
anyone there got access to sayma atm and mind doing a quick test for me?
<sb0>
hartytp, do you want a login on the HK server?
<hartytp>
sure! Thanks
<hartytp>
so, Weida got our HMC830 eval board locking with the loop filter on Sayma.
<hartytp>
and thinks he may have found the issue with the ARTIQ code.
<hartytp>
we write 32 bits to all registers
<hartytp>
the registers are variable length, so we pad them out with zeros
<hartytp>
Weida thinks the VCO subsystem (reg 5) only accepts the first 16 bits written (remember it's on an internal SPI bus so behaves differently to the rest)
<hartytp>
so, padding needs to be put at the end of the word rather than at the beginning
<hartytp>
e.g. {8'h05,24'hE11000} instead of {8'h05,24'h00E110}
<hartytp>
other than that, the register set in my PR seems to work perfectly for him
<hartytp>
(the PR I closed a while back)
<hartytp>
I'm out of the lab atm, but would one of you mind having a quick go with that?
<sb0>
hartytp, shouldn't the VCO writes be just 16-bits then?
<sb0>
hartytp, send me your SSH key
<sb0>
also there is no 100MHz source on the saymas right now so it'll have to wait until i go to the lab tomorrow...
<hartytp>
i think the spi core prefers 32 bit writes it just need a different alignment for the VCO subsystem
<hartytp>
okay. I don't think I'll have time to look at this on our boards until mid next week
<hartytp>
anyway, that reg set worked for Weida on his eval board + FPGA, so hopefully it will work for us
<sb0>
"the spi core" -> the one inside the hmc830?
<sb0>
the artiq one can do <32 without problems
<hartytp>
right.
<hartytp>
Since that set of writes worked on Weida's FPGA with the eval board, I'd start with that. If that works, we can think about nicer ways of doing it...
<hartytp>
(24 bits, not 16, as first 8 bits are the address)
<_florent_>
sb0: i was testing prbs on sayma3, but jtag seems to be stuck (not the problem we had this afternoon but the one where openocd is stuck), is there a way to unlock that remotely?
<sb0>
_florent_, try whitequark's usbreset.c
<sb0>
(see irc logs)
<_florent_>
sb0: ok thanks, will try that
<hartytp>
anyway, let me know if that works or not if you try it before I do
hartytp has quit [Quit: Page closed]
<_florent_>
sb0: not sure i can do it since i'm not a sudoer
<_florent_>
sb0: i'll test that tomorrow, i think i know why the prbs test was failing
<GitHub162>
[smoltcp] dlrobertson commented on pull request #125 1954e7e: Create a `should_panic` test for this. Also I can't remember off the top of my head if an out of bounds index panics in release mode. If not, add an `assert!` checking the length. https://github.com/m-labs/smoltcp/pull/125#discussion_r162188835
<GitHub45>
[smoltcp] dlrobertson commented on pull request #125 1954e7e: I think `ident` is redundent. If you're using the `Pad1` `Repr` then `emit` knows that the option type should be that of `Pad1`. https://github.com/m-labs/smoltcp/pull/125#discussion_r162185904
<GitHub190>
[smoltcp] dlrobertson commented on pull request #125 1954e7e: A `check_len` function should be added, and a `new_checked` function should be added. See some of the other implementations in `wire` for details. Make sure to test `check_len` well. It will be a little tricky since the length requirements vary based on the options type. https://github.com/m-labs/smoltcp/pull/125#discussion_r162183405
<GitHub165>
[smoltcp] dlrobertson commented on pull request #125 1954e7e: There should probably be a `OpFailureType` for the four on failure type defined in [RFC 8200 4.2]. Then a `From<OptionType> for OpFailureType`. E.g. something like... https://github.com/m-labs/smoltcp/pull/125#discussion_r162185157
<GitHub137>
[smoltcp] dlrobertson commented on pull request #125 1954e7e: Yeah, you wouldn't change the current option type. I mean to add a new type that would be specifically for the following.... https://github.com/m-labs/smoltcp/pull/125#discussion_r162202752
<GitHub72>
[smoltcp] dlrobertson commented on pull request #125 1954e7e: Yeah, you wouldn't change the current `OptionType`. I mean to add a new `OpFailureType` that would be specifically for the following.... https://github.com/m-labs/smoltcp/pull/125#discussion_r162202752