<GitHub118>
[artiq] sbourdeauducq commented on issue #854: Delaying the tx clock helps. I can ping the board now, though unreliably, but that may be the 1.8V bug that has become really bad (~20 second board life) on the board I reworked, for maximum frustration. https://github.com/m-labs/artiq/issues/854#issuecomment-358842622
<sb0>
whitequark, any update on the allaki programming?
<whitequark>
sb0: implementing software side of RTM bitstream upload now
<whitequark>
oh, does sayma3 have all the correct resistors placed?
<sb0>
I don't know ...
<whitequark>
ok
<sb0>
there is sayma1 as well right now
<whitequark>
does that one?
<sb0>
you have 20 second to run your code until the power supply becomes fucked
<sb0>
yes
<whitequark>
that sounds like a bad Hollywood movie.
<whitequark>
does it expxlode after thoe 20 seconds?
<whitequark>
sb0: what is the way to fix the 1V8 bug?
<sb0>
whitequark, shipping a board to Greg today for investigation
<whitequark>
wow, this things has SEVEN power rails
<whitequark>
sb0: is there ethernet on sayma3?
<whitequark>
oh, no
<whitequark>
I remember there isn't
<sb0>
there is ethernet on sayma1
<sb0>
since yesterday.
<sb0>
though may not be reliable, unless that's just the 1.8V bug
<whitequark>
well but if it dies within 20s that's useless to me
<whitequark>
since I want ethernet for hotswapping
<sb0>
I tried reworking sayma3 as well but damaged the trace, now I have to solder a small wire on the TQFN pad directly...
<_florent_>
sb0: maybe you should consider using an external 1.8v for now on sayma1
<sb0>
I don't know if the power circuit will be happy with power coming from the other way. that needs careful review or may damage thing.
<sb0>
there are also power sequencing issues
<sb0>
whitequark, depending on ethernet isn't a good idea imo. even on kasli with no hardware issues (but xilinx transceiver BS) it took a while to develop.
<sb0>
whitequark, what about cranking up uart speeds? iirc _florent_ was able to run at 2Mbps on Sayma
<_florent_>
sb0: yes 2Mbps works fine
<whitequark>
sb0: so, we're back to SLIP/etc?
<_florent_>
sb0: i just got my drtio code working your drp sequence at 1.25Gbps
<sb0>
I don't know why you want IP, which would interfere with debug messages, but if you really want it, fine
<_florent_>
sb0: we'll be able to test that with sayma at the lab
<sb0>
_florent_, great!
<whitequark>
I already explained many times why I want a non-crippled debug interface
<sb0>
that's a tall order. embedded systems are broken by default.
<sb0>
so only simple things like UART can be relied on
<whitequark>
it's not my fault that you have stockholm syndrome from this vivado shit
<whitequark>
i refuse to sit idle and let it all be broken
<sb0>
how would you print a debug message?
<whitequark>
since we have IP, over IP?
<sb0>
what if the system has only, say, 32KB total memory, e.g. the RTM FPGA?
<sb0>
or if flash is not working and you are also similarly limited in memory on a board with a larger FPGA.
<whitequark>
RTM FPGA has more flash than that, no?
<sb0>
for the first months with sayma we had no flash, and it wasn't vivado's fault
<sb0>
the RTM FPGA has no memory at all, except on-chip
<whitequark>
oh, right, we don't do XIP
<whitequark>
but RTM FPGA also doesn't have a CPU
<whitequark>
so the question is moot, isn't it?
<sb0>
it will
<sb0>
for si5324 housekeeping etc.
<whitequark>
ok, sure, then here's my suggestion
<whitequark>
actually, will RTM FPGA even use the bootloader?
<sb0>
no, it won't. but it will use some of the current infrastructure (libboard etc.)
<whitequark>
then I don't understand your objection, I'm not proposing any changes to libboard
<sb0>
and it needs to output debug messages
<whitequark>
libboard doesn't even deal with debug messages at all, other than the optional uart_console feature
<sb0>
I had to add debug messages to libboard yesterday again, to investigate sayma ethernet.
<whitequark>
okay?
<whitequark>
I don't see any problem with that?
<sb0>
well as long as we can trivially fallback to a serial console, such as when flash is broken or when there is too little memory for IP for any other reason, then it's fine
<whitequark>
you're wholly misunderstanding what I want
<sb0>
it's not having an IP layer on the UART?
<whitequark>
it is, but not in libboard, of course, but in the bootloader (or whatever boots from it)
<sb0>
and that can be disabled when there is no flash?
<whitequark>
why would you have the bootloader when there is no flash?
<sb0>
(with the bootloader in block RAM)
<sb0>
to run anything on the system, e.g. loading firmware via the serial port
<sb0>
or ethernet, if it works
<whitequark>
what
<whitequark>
you're contradicting yourself
<whitequark>
if the bootloader with the IP layer cannot fit into block RAM, then you cannot load firmware via Ethernet
<sb0>
I said: "if it works"
<whitequark>
but sure, there's no reason it can't be disabled
<sb0>
i.e. the FPGA has plenty of available block RAM (the ku040 might), the IP stack is small enough, the ethernet core is functional
<sb0>
and means to load firmware if those conditions are not met is still desirable
<whitequark>
hm, ok, then what I'd do is to run the same protocol over serial or the IP endpoint of the bootloader, if any
<sb0>
ok
<sb0>
also. people will look at those debug messages from windows machines.
<sb0>
and you have to emit debug messages early, when DDR3 is not working yet...
<whitequark>
okay, the bootloader doesn't use anything except builtin RAM.
<sb0>
ok. but say a windows user has a DDR3 problem. how will they look at the messages if they are encapsulated in IP?
<whitequark>
hm, good point
<whitequark>
okay, how about this solution: debug messages go to the UART unmolested until a TCP connection is established
<sb0>
ok
<whitequark>
after that, they go through that connection. if it drops, back to UART.
<whitequark>
SLIP appears resistant to having alphanumeric characters in the stream, they should just be ignored
<whitequark>
(outside frames that is)
<sb0>
no unicode in debug messages?
[X-Scale] has joined #m-labs
<whitequark>
oh, even that can be made to work
[X-Scale] has left #m-labs [#m-labs]
<whitequark>
all I have to do is to make sure 0xc0 is not emitted other than at the start of a frame
<whitequark>
anyway, let me finish allaki first
<whitequark>
sb0: where/how should I initialize allaki?
<GitHub73>
[artiq] sbourdeauducq commented on issue #898: > I follow these instructions verbatim to create a new conda environment for every pull from master. Proxy bitstreams conda package is missing.... https://github.com/m-labs/artiq/issues/898#issuecomment-358866584
<GitHub105>
[artiq] sbourdeauducq commented on issue #898: As for ``bscan-spi-bitstreams``, it is debatable whether it should be included in ``artiq-dev``, the board-specific packages, or ``openocd``. I'll let @jordens make that decision. https://github.com/m-labs/artiq/issues/898#issuecomment-358867579
<GitHub12>
[artiq] sbourdeauducq commented on issue #898: As for ``bscan-spi-bitstreams``, it is debatable whether it should be included in ``artiq``, ``artiq-dev``, the board-specific packages, or ``openocd``. I'll let @jordens make that decision. https://github.com/m-labs/artiq/issues/898#issuecomment-358867579
<_florent_>
sb0: drtio also seems to work at 3gbps on artix7
<sb0>
nice!
<sb0>
does that board have a si5324?
<_florent_>
no
<GitHub156>
[smoltcp] hjr3 commented on pull request #125 7b913cc: Added `check_len` and `new_checked`. I am not sure that I handled `Pad1 correctly. As is, calling `option_data_length` or `data` methods will panic if the type is `Pad1`. https://github.com/m-labs/smoltcp/pull/125#discussion_r162541189
<whitequark>
sb0: rjo: i've implemented network transparency for artiq_flash. you can now tell it --host lab.m-labs.hk and it will transfer all the necessary files (except openocd binary) from the local machine.
<sb0>
whitequark, allaki programming is working. rf goes through. thanks!
<whitequark>
sb0: wow, that worked on the first try.
<sb0>
compiling sawg now ...
<sb0>
whitequark, your rigol scope doesn't have 50ohm terminations, does it?
<GitHub94>
artiq/master 3c0b164 whitequark: artiq_devtool: update for new board file convention....
<rjo>
sb0: SAWG worked fine at 150 MHz. could it be SED?
<sb0>
maybe, but I had compiled it on kc705 and it was working...
<sb0>
(at 150M)
<sb0>
well. most of the delay (6ns!) is routing from the RTIO core to the SAWG PHY
<rjo>
the path jesd_rst to ad9154_0_jesd204bcoretx_elasticbuffer7_reset is a false path. that should be marked.
<sb0>
so yes, it is sed (kind of) since the core is in one place instead of having FIFOs spread out, and also ultraslow routing. probably solvable by inserting a register on that path
<rjo>
i noticed that vivado seemed to no find a few of the multireg FF paths that are to be marked false. that might exacerbate the issues.
<rjo>
there is a message early on when applying the xdc first. i tried to debug it a while ago but didn't find it.
<sb0>
rjo, can you add that false path=
<sb0>
?
<rjo>
i do think having the rtio core in one place and the phys all over is fine and correct. we just have to find way to deal with the long routing.
<sb0>
for the reset
<rjo>
sb0: i'll look at it today. there are all the tcl commands in place that should do that (and they work for the other false paths).
<sb0>
well, with the previous core you had the FIFO write interface in one place and then the FIFOs all over
<sb0>
the routing to spread the data out has to be done anyway
<sb0>
it is actually easier with SED (insert pipeline registers) than with the other (you need feedback from the FIFO to know when it is full)
<rjo>
ack.
<sb0>
oh amazing, sayma1 works really well with that new capacitor, except for serwb
<rjo>
sb0: too much typing imho. i'd like that part of the name to be implicit in the variant. there will be only one of those operating modes per variant. since the variant is non-generic it doesn't make sense to have "drtio_satellite" in there as well which would indicate some genericism.
<GitHub57>
[smoltcp] dlrobertson commented on pull request #125 a44d05c: I don't think it is a variable number of IPv6 Extension Header Options. Each packet is only one Extension Header Option. E.g. if `bytes` contains the following... https://github.com/m-labs/smoltcp/pull/125#discussion_r162620949
<GitHub22>
[smoltcp] dlrobertson commented on pull request #125 a44d05c: nit: for other modules in `wire` if the module is `icmpv4` the exported names are `Icmpv4<something>. Perhaps `ipv6ops` or `ipv6option` would be more in-line with other implementations in `wire`. https://github.com/m-labs/smoltcp/pull/125#discussion_r162623699
<GitHub164>
[smoltcp] hjr3 commented on pull request #125 0e5f6fa: I chose `ipv6option`. I originally was going to put all of the extension headers in the `ipv6ext` module, but have a module for options seems fine to me. https://github.com/m-labs/smoltcp/pull/125#discussion_r162659104
bb-m-labs has quit [Quit: buildmaster reconfigured: bot disconnecting]
<GitHub-m-labs>
[buildbot-config] whitequark pushed 1 new commit to master: https://git.io/vNuar
<GitHub-m-labs>
buildbot-config/master 91a6c94 whitequark: Don't bloat the waterfall so much.
bb-m-labs has joined #m-labs
<whitequark>
sb0: ok, bizarro-bug-land you say...
<sb0>
whitequark, are you using the sayma1 now?
<_florent_>
sb0: i'm using sayma3
<sb0>
sayma1 is still working fine afaict, no 1.8V problem
<_florent_>
sb0 or anyone: how to i update the jesd204b version in artiq/conda?
<_florent_>
sb0: i tested what i implemented for subclass1 and it seems to work
<sb0>
_florent_, build the jesd204b conda package, make a jesd204b release if relevant, then edit conda/artiq-dev/meta.yaml
<sb0>
_florent_, how do you know that sysref meets dac clock s/h?
<sb0>
did you do as I suggested by looking at the two jitter zones?
<_florent_>
sb0: i don't know for now, that's the next step
<whitequark>
sb0: not yet. don't you use the lockfiles?
<_florent_>
sb0: for now i just know that we see the sysref on the fpga side and start on a rising edge
<GitHub141>
[smoltcp] dlrobertson commented on issue #125: IMO there are some doc strings that don't need a period. E.g. `IPv6 Extension Header Option Type`, but doc strings like `A read/write wrapper around a variable number of IPv6 Extension Header Options` probably should. https://github.com/m-labs/smoltcp/pull/125#issuecomment-359008414
<sb0>
lockfiles on sayma were a bit useless while the 1.8V bug trashed the boards within minutes and there was only one global power switch. but yes, we should use it now.
<GitHub28>
[smoltcp] dlrobertson commented on issue #125: IMO there are some doc strings that don't need a period. E.g. `IPv6 Extension Header Option Type`, but doc strings like `A read/write wrapper around an of IPv6 Extension Header Option` probably should. https://github.com/m-labs/smoltcp/pull/125#issuecomment-359008414
<GitHub63>
[smoltcp] dlrobertson commented on issue #125: IMO there are some doc strings that don't need a period. E.g. `IPv6 Extension Header Option Type`, but doc strings like `A read/write wrapper around an IPv6 Extension Header Option` probably should. https://github.com/m-labs/smoltcp/pull/125#issuecomment-359008414
<whitequark>
where's sayma2?
<sb0>
in the crate and powered down
<sb0>
well, no, sayma2 is actually on its way to greg. we have sayma1, sayma3 (which is not connected right now) and florent's
<sb0>
after the crate bug is sorted out, i will fix/workaround 1.8v on sayma3 and then we should have 3 rather solid boards
<whitequark>
okay
<whitequark>
I'm going to work on RTM firmware upload
<whitequark>
or rather that's mostly done as gateware is written and I'm going to sort out the hardcoded firmware partitions
<GitHub16>
artiq/master 9eb13ab Florent Kermarrec: liboard_artiq/hmc830_7043: allow sysref digital/analog delay configuration (will need to be adjusted for jesd subclass1)
<GitHub59>
[smoltcp] hjr3 commented on pull request #125 6a89a57: I decided to use `check_len` to ensure that it is working correctly independently of `new_checked`. I test `new_checked` in `test_option_deconstruct` too. https://github.com/m-labs/smoltcp/pull/125#discussion_r162670117
<sb0>
rjo, what do you recommend for flashing the urukul cpld?
<whitequark>
CoolRunnerII?!
<whitequark>
azonenberg has a FOSS toolchain for that in the works :D
<rjo>
sb0: xc3sprog works if you fxload2 the platform cable each time.
<sb0>
ah, so xilinx platform cable...
<whitequark>
rjo: why is jtagspi for sayma inlined into artiq_flash?
<whitequark>
because it cannot be upstreamed into openocd?
<rjo>
sb0: pretty sure that any other cable that works with xc3sprog will also work fine
<rjo>
sb0: i.e. your favorite ftdi or cypress adapter.
<rjo>
whitequark: jtgspi (the tcl code) doesn't handle more than one flash chip. that would need to be upstreamed.
<sb0>
yeah, I'll shop around for cheap chinese things. the xilinx platform cable is easy to beat...
<whitequark>
rjo: oh and the ftdi junk is sayma-specific.
<whitequark>
ok...
<rjo>
whitequark: but that can go upstream (and iirc i already pushed that for review).
<rjo>
whitequark: it'll need changing again when jtagspi-tcl changes w.r.t. multiple flashes.
<rjo>
i also fear the global variable gymnastics that openocd seems to love.
<whitequark>
rjo: i feel like we can just issue raw flash commands in artiq_flash, without any of this jtagspi magic.
<whitequark>
use case: I want to read flash
<whitequark>
jtagspi lacks that.
<rjo>
the tcl part? yes. that's become a pretty useless shim layer.
<rjo>
the gateware and c part of jtagspi supports flash read just fine.
<rjo>
e.g. see the inlined commands.
<whitequark>
ok to rip it out of artiq_flash.Programmer and unify sayma/kasli/kc705 programmers?
<whitequark>
jtagspi tcl invocations that is
<whitequark>
just parameterize it over pld/bank number.
<rjo>
have artiq_flash generate the "flash read/erase", "target add ..." commands directly. sure.
<whitequark>
excellent
<rjo>
there is a lot of chance for clean up that way.
<whitequark>
yes.
<rjo>
whitequark, sb0: once the sayma storm has settled to about 2/3 of the current level, the next bigger item for opticlock is the driver for the emccd camera: https://www.princetoninstruments.com/products/ProEM-EMCCD just a python ARTIQ device controller/driver. it's ethernet but will need encapsulation of a binary-only library. any takers?
<whitequark>
linux or windows?
<whitequark>
hang on
<whitequark>
it's *ethernet* but talks via a *proprietary library* ?
<whitequark>
can we just reverse-engineer that?
<rjo>
linux.
<whitequark>
unless it does some sort of heavy image processing.
<whitequark>
then it's futile
<rjo>
whitequark: maybe. there shouldn't be much image processing. but i am reluctant to do that. this thing can be bricked and killed.
<whitequark>
rjo: just don't touch the firmware update endpoint?
mumptai has joined #m-labs
<sb0>
whitequark, probably it has bugs like buffer overflows that write to flash etc. :)
<whitequark>
sb0: well I'm not going to *fuzz* it
<whitequark>
I'm sure it does...
<sb0>
oh this makes me think, we should fuzz the artiq core device
<whitequark>
pfff
<whitequark>
what do you expect to happen, besides out of memory errors?
<whitequark>
oh and we actually do fuzz it
<whitequark>
I fuzz smoltcp
<whitequark>
that's why I'm so certain that it is not the part that panics, when a panic occurs
<whitequark>
sb0: this reminds me, all this backtrace machinery is going unused
<whitequark>
kind of a pity
<sb0>
well. no wonder I'm getting such a high rate of packet losses. the Ethernet PHY is ignoring my TX clock
<whitequark>
how are you getting anything at all out of it?!
<rjo>
the camera has high voltages and peltiers that can kill itself.
<sb0>
it just correctly transmits the packet when the clock I'm sending happens to match its clock
<sb0>
if I send it no clock at all, I still get the same packet loss rate
<whitequark>
rjo: oh, I see.
<sb0>
also those packets are short (arp and icmp replies)
<whitequark>
rjo: and you think all of the logic is inside the blob?
marmelada has joined #m-labs
<whitequark>
that seems like absurdly bad design, but I can see that happening
<whitequark>
let's disassemble the blob and see if it's just a dumb protocol serdes or if something more complex is going on, then.
<sb0>
I suppose it worked in Greg's test, because he used the RX clock to derive the TX clock, and the PHY only really has one clock...
<rjo>
whitequark: parameter verification and monitoring and some safeties. yes.
<whitequark>
rjo: why do you use `flash write_image` in jtagspi_program, but `flash erase_sector ...; flash write_bank ...` in sayma programmer?
<rjo>
whitequark: write_image does not take a bank argument. go figure (and file an issue with openocd ;)
<whitequark>
oh...
<whitequark>
wtf
<rjo>
whitequark: i would have loved to use that.
<whitequark>
and... write_bank doesn't know about sector sizes?
<rjo>
yes.
<rjo>
maybe there is a way to teach write_image what the "current bank" is. but i didn't look deeply into that.
<rjo>
ergo i went ahead and inlined write_image as well.
<whitequark>
rjo: it's implicit.
<whitequark>
write_image looks up the flash bank based on the address you're writing.
<whitequark>
so, if you set the 3rd argument of `flash bank` then you can use write_image.
<whitequark>
okay, will fix that too.
<rjo>
whitequark: ok. that'll work. i still think its a bug.
<hartytp>
whitequark: would you mind having a quick skim at this and giving comments (new to rust so just checking there isn't a better way of doing this + looking for general style comments before submitting PR)
<whitequark>
this is set up so that it won't interfere with anyone else, because e.g. if you make a lot of commits, then you can get a higher build number than our "dev" channel
<whitequark>
and if you use the "artiq" builder and people upgrade to your packages, they can have broken setups.
<whitequark>
hrm, sayma needs two packages built
<whitequark>
moment
<hartytp>
thanks!
<whitequark>
wait, it's still not fully functional
<whitequark>
won't build bitstreams
<whitequark>
let me fix that
<whitequark>
don't run anything yet, I'll restart buildmaster a few times
<cjbe>
(OSX does not support embedding in the way Artiq uses it, but the applets work fine standalone)
bb-m-labs has quit [Quit: buildmaster reconfigured: bot disconnecting]
<GitHub-m-labs>
[buildbot-config] whitequark pushed 1 new commit to master: https://git.io/vNzZY
<GitHub-m-labs>
buildbot-config/master 1cc1e88 whitequark: Fix another typo.
bb-m-labs has joined #m-labs
<hartytp>
cab: thanks
<hartytp>
*cjb*
<whitequark>
hartytp: btw if you want to repeat the same build but update the branch, open the build page, select "Same sourcestamps" in "Rebuild using:" and click "Rebuild". saves you filling out the form again.