sb0 changed the topic of #m-labs to: ARTIQ, Migen, MiSoC, Mixxeo & other M-Labs projects :: fka #milkymist :: Logs http://irclog.whitequark.org/m-labs
sb0 has joined #m-labs
kuldeep has quit [Ping timeout: 272 seconds]
kuldeep has joined #m-labs
mumptai has quit [Ping timeout: 264 seconds]
mumptai has joined #m-labs
<GitHub137> [llvm-or1k] whitequark pushed 1 new commit to artiq-3.8: https://github.com/m-labs/llvm-or1k/commit/ed46799ac82a3857d427e583c7378bff8c28b5fa
<GitHub137> llvm-or1k/artiq-3.8 ed46799 whitequark: [SelectionDAG] Fix calling convention in expansion of ?MULO....
rohitksingh_work has joined #m-labs
sandeepkr has joined #m-labs
sandeepkr has quit [Max SendQ exceeded]
sandeepkr has joined #m-labs
sb0 has quit [Quit: Leaving]
<GitHub199> [artiq] whitequark pushed 2 new commits to master: https://git.io/vPOpz
<GitHub199> artiq/master 6bbaff8 whitequark: Rust: implement idle kernels.
<GitHub199> artiq/master 398b709 whitequark: Rust: use try_borrow where applicable.
<whitequark> sb0: can you elaborate on the "startup kernel" feature
<whitequark> since when do we ship software to startups?
sb0 has joined #m-labs
<bb-m-labs> build #91 of artiq-board is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-board/builds/91
<sb0> whitequark, it's very easy. you just run it once when the device boots, and wait until it terminates before proceeding further (idle kernel/network sessions)
<whitequark> ok
<bb-m-labs> build #981 of artiq is complete: Failure [failed python_unittest_1] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/981 blamelist: whitequark <whitequark@whitequark.org>
<GitHub183> [artiq] whitequark pushed 2 new commits to master: https://git.io/vPOja
<GitHub183> artiq/master 2b3bc30 whitequark: Rust: implement startup kernels.
<GitHub183> artiq/master 0cd87af whitequark: Rust: don't crash kernel CPU when no flash kernel is present.
Gurty has quit [Quit: Kooll ~o~ datalove <3³\infty]
<bb-m-labs> build #92 of artiq-board is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-board/builds/92
<bb-m-labs> build #376 of artiq-win64-test is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-win64-test/builds/376
<bb-m-labs> build #982 of artiq is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/982
sb0 has quit [Ping timeout: 248 seconds]
<GitHub15> [artiq] whitequark pushed 1 new commit to master: https://git.io/vP3ed
<GitHub15> artiq/master 0e2cd38 whitequark: Rust: set the SOF_KEEPALIVE flag on session sockets.
FabM has joined #m-labs
<bb-m-labs> build #93 of artiq-board is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-board/builds/93
<bb-m-labs> build #377 of artiq-win64-test is complete: Failure [failed python_unittest] Build details are at http://buildbot.m-labs.hk/builders/artiq-win64-test/builds/377 blamelist: whitequark <whitequark@whitequark.org>
<bb-m-labs> build #983 of artiq is complete: Failure [failed] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/983 blamelist: whitequark <whitequark@whitequark.org>
<GitHub60> [misoc] whitequark pushed 1 new commit to master: https://git.io/vP3I9
<GitHub60> misoc/master 3dc110a whitequark: Rust CSR: generate --cfg flags for extant regions and CONFIG_* consts.
<GitHub181> [artiq] whitequark pushed 1 new commit to master: https://git.io/vP3I7
<GitHub181> artiq/master b590c6c whitequark: Rust: import --cfg flags generated by misoc.
<bb-m-labs> build #138 of misoc is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/misoc/builds/138
EvilSpirit has joined #m-labs
<bb-m-labs> build #94 of artiq-board is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-board/builds/94
<bb-m-labs> build #378 of artiq-win64-test is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-win64-test/builds/378
<bb-m-labs> build #984 of artiq is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/984
<bb-m-labs> build #95 of artiq-board is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-board/builds/95
<bb-m-labs> build #985 of artiq is complete: Failure [failed] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/985
sandeepkr has quit [Remote host closed the connection]
sandeepkr has joined #m-labs
sb0 has joined #m-labs
bentley` has quit [Ping timeout: 264 seconds]
<whitequark> sb0: how do I test moninj?
<larsc> _florent_: how did you check whether the CGS succeeded?
<rjo> _florent_: nice.
sb0 has quit [Ping timeout: 244 seconds]
sb0 has joined #m-labs
<whitequark> ok, dashboard has it...
Gurty has joined #m-labs
<GitHub107> [artiq] whitequark pushed 2 new commits to master: https://git.io/vP3PS
<GitHub107> artiq/master 2fefd0a whitequark: Rust: implement moninj.
<GitHub107> artiq/master 2e4d19a whitequark: Rust: add some conditional compilation back to rtio_crg.
<whitequark> sb0: moninj in rust appears to work as intended, except that OEs don't work
<whitequark> but they also don't work in the current C runtime
<whitequark> is that a known problem?
rohitksingh_work has quit [Read error: Connection reset by peer]
<bb-m-labs> build #96 of artiq-board is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-board/builds/96
<sb0> how do they not work?
<whitequark> or maybe not OEs
<whitequark> basically, OVERRIDE_ENABLE works
<sb0> I told you to use TCP
<whitequark> then I try setting a channel to high and nothing changes in the monitor packets
<whitequark> hm? I'm specifically not changing any protocol details until I have a complete port running
<whitequark> it's about five lines of change on the Rust side anyway, no big deal
<sb0> bah, this UDP stuff is a waste of time (including getting the lwip side to work), and if moninj is broken, it shouldn't be a big deal to fix it, right?
<bb-m-labs> build #986 of artiq is complete: Failure [failed python_unittest_1] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/986 blamelist: whitequark <whitequark@whitequark.org>
<whitequark> I don't really know how it's done...
<sb0> I don't get what does not work
<whitequark> I try to set OE=1 by doing:
<whitequark> csr::rtio_moninj::inj_override_sel_write(MONINJ_TTL_OVERRIDE_OE);
<whitequark> csr::rtio_moninj::inj_value_write(1);
<whitequark> OE does not become 1 as read using the monitor
<sb0> is the C runtime touching OE?
<whitequark> nope
<whitequark> and the override part is working
<sb0> yes. OE is supposed to be set (and generally untouched) by kernels only (and in particular the startup kernel)
<whitequark> i.e.
<whitequark> csr::rtio_moninj::inj_override_sel_write(MONINJ_TTL_OVERRIDE_ENABLE);
<whitequark> csr::rtio_moninj::inj_value_write(1);
<whitequark> results in the override bit being set in monitor response
<whitequark> hm, I don't understand it then, why does moninj write to OE?
<whitequark> shouldn't it only write to O then?
<sb0> so what happens when you write to OE?
<sb0> and did you write to OE on a TTLOut or a TTLInOut?
<whitequark> absolutely nothing happens
<whitequark> well, from the software POV
<whitequark> I didn't look at the outputs themselves
<whitequark> and I tried to write to OE on almost every channel
<sb0> what happens when you read it back?
<sb0> output-only TTL RTIO PHYs don't have OE.
<whitequark> setting value to 1 also didn't seem to produce any effect...
<whitequark> hm, I'm not at the lab anymore and ssh doesn't forward UDP
<whitequark> ok, I'll just add an issue then and fix it once the transition is done
<sb0> yes. I told you to use TCP for a reason...
<whitequark> well I'm not arguing with that
<sb0> actually the current code does set OE
<sb0> and is supposed to set any channel to output when overriden
<whitequark> yes
<whitequark> when OE is read back via the monitor, it's always zero
<sb0> did you do rtio_moninj_mon_value_update_write(1)?
<whitequark> yep
<whitequark> both c and rust code does that
<sb0> and are you sure the TTL PHY you are targeting is not a output-only PHY?
<whitequark> I tried every TTL
<sb0> are you using the correct probe number?
<whitequark> I just translated the C code
<sb0> writing to OE is 2, reading is 1
<whitequark> yeah
<whitequark> ok, I'll poke it again tomorrow morning. I need to go now
<sb0> a output-only TTL PHY gives the "erroneous" behavior you are describing. but the IO ones support OE.
<sb0> on output-only, writing to OE is a nop and reading returns 0
<_florent_> larsc: I check CGS with CODEGRPSYNC register and by looking at the SYNC signal (released to 1 when CGS passed on all lanes)
<larsc> _florent_: thanks, got things to work.
<larsc> with the DAQ2
<larsc> I asked around about the dividers
<larsc> the guy who did the software said that he got the config from the product line and they said to use that setup to get something that works...
jboulder has joined #m-labs
<_florent_> larsc: ok thanks, I think the schematic of the AD9161/AD9162 makes senses for the AD9154, at least it's coherent with the behaviour I have.
<_florent_> larsc: I now have ILAs with correct checksum on all lanes, PRBS test is also working. Now I have to check the transport layer.
<larsc> well done, transport is luckily not that complicated if you are going with a more or less static setup
bentley` has joined #m-labs
<larsc> _florent_: did you read back the ILAS register from the part?
EvilSpirit has quit [Ping timeout: 252 seconds]
<_florent_> larsc: yes it's fine. The computed checksum also match the expected checksums.
<_florent_> larsc: http://pastebin.com/NBSQHDHk
<larsc> hm, the checksum is the only thing that works for me
<larsc> does initializing a ROM with initial rom = .... work with the Xilinx tools?
<larsc> maybe that is my issue
EvilSpirit has joined #m-labs
<_florent_> larsc: maybe your are indeed only sending zeros
<_florent_> larsc: which would give correct checksum...
<larsc> I'm sending zeros everywhere except for the lane ID
<larsc> I'm just wondering why
<larsc> interestingly enough things still work fine as well
EvilSpirit has quit [Ping timeout: 244 seconds]
<larsc> what I do for testing is this http://pastebin.com/dcqpTYzb
<larsc> works fine in simulation
<rjo> _florent_: you have ERR_KUNSUPP: 1, ERR_JESDBAD: 1 and SERPLLLOST: 1. or are those latching?
<larsc> those are sticky
sandeepkr has quit [Read error: Connection reset by peer]
_rht has joined #m-labs
jboulder has quit [Quit: Page closed]
<larsc> I could hav sworn that the inital method works for Xilinx, but it looks like it does not
<larsc> and you have to do the checksum over the individual fields and not the bytestream? that is just terrible
<rjo> larsc: you can do it over the bytes.
<larsc> but that's a special mode of the ad converters it seems
<larsc> the standard says over the fields
<rjo> larsc: i think for viviado $readmemh() works as an initial. at least we use it in migen
<larsc> yes, readmem works, but that's it
<larsc> simple assigments do not
<GitHub179> [artiq] jordens pushed 6 new commits to phaser: https://git.io/vPsSx
<GitHub179> artiq/phaser 206462f Robert Jordens: phaser: kernel support for ad9154 spi
<GitHub179> artiq/phaser 6f86e98 Robert Jordens: phaser: move spi to kernel cpu
<GitHub179> artiq/phaser 19a3733 Robert Jordens: phaser: cleanup pins
acathla has quit [Quit: Coyote finally caught me]
acathla has joined #m-labs
acathla has quit [Changing host]
acathla has joined #m-labs
mumptai has quit [Quit: Verlassend]
_rht has quit [Quit: Connection closed for inactivity]