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
<GitHub93>
[artiq] jordens pushed 5 new commits to spimaster: https://git.io/v2Kcv
<GitHub93>
artiq/spimaster 7ef21f0 Robert Jordens: nist_clock: add SPIMasters to spi buses
<GitHub93>
artiq/spimaster 12252ab Robert Jordens: nist_clock: rename spi*.ce to spi*.cs_n
<GitHub93>
artiq/spimaster da22ec7 Robert Jordens: gateware.spi: rework wb bus sequence
fengling has joined #m-labs
fengling has quit [Ping timeout: 240 seconds]
fengling has joined #m-labs
<GitHub66>
[artiq] jordens pushed 1 new commit to spimaster: https://git.io/v2KRX
<GitHub66>
artiq/spimaster f2ec869 Robert Jordens: nist_clock: disable spi1/2
fengling has quit [Ping timeout: 240 seconds]
fengling has joined #m-labs
fengling has quit [Ping timeout: 240 seconds]
fengling has joined #m-labs
fengling has quit [Ping timeout: 240 seconds]
fengling has joined #m-labs
<whitequark>
sb0: no idea what MMCX connectors are
<whitequark>
sb0: do you still want me to do things to the backplane?
<whitequark>
rjo: yes. the inlined functions are not removed. this is related to the unnecessary presence of virtual calls i have mentioned a bit earlier.
<whitequark>
well, it's the exact same basic issue.
<sb0>
whitequark, no. i'll handle the backplane/hardware stuff
<sb0>
whitequark, there are #232 and #302 for you. do you want to also look into the unittests on windows?
<whitequark>
ah right #232
<whitequark>
hm windows unittests, what was wrong with them?
<sb0>
don't know. there is no more ssh, and I couldn't stop windows from locking the screen when pressing the L key
<sb0>
maybe they work. either way they should be run.
<whitequark>
can't you make the ssh work like you did before?
<whitequark>
as for L key, that's simple, it means you have the Win key stuck
<whitequark>
press it once, it'll get unstuck
<sb0>
no. cygwin completely crapped out after the VM rebooted and ssh won't start again
<whitequark>
quality software.
<sb0>
I've pressed the win key in combination with various others ~100 times already
<whitequark>
ok, I will give you ssh at least
<whitequark>
maybe the wrong win key? in any case you can do sudo xl reboot win7-experimental
<whitequark>
(there are two win keys...)
<sb0>
there's only one on my keyboard
<sb0>
this kind of vnc issue is really irritating
bentley` has quit [Ping timeout: 260 seconds]
<whitequark>
sb0: oh, I figured out the vnc key problem.
<whitequark>
the "hardware" win key got stuck.
<whitequark>
i.e. the one on qemu vnc, not in-VM vnc
<sb0>
whitequark, ok. anyway, do you want to deal with the windows unittests?
<whitequark>
sure I can take a look
bentley` has joined #m-labs
<GitHub51>
[artiq] whitequark pushed 1 new commit to master: https://git.io/v2KbS
<GitHub51>
artiq/master dc70029 whitequark: transforms.asttyped_rewriter: set loc for ForT (fixes #302).
<sb0>
whitequark, is it easy to remove those virtual calls?
<whitequark>
reasonably easy. and it will also kill some of the gnarliest hacks in the compiler.
<sb0>
ok. make it so, then.
<sb0>
speaking of gnarly hacks, have you sorted out the RPC argument handling yet?
<whitequark>
no
<whitequark>
wasn't in the 1.0 milestone
mumptai has joined #m-labs
<GitHub115>
[artiq] sbourdeauducq pushed 2 new commits to master: https://git.io/v26fi
<GitHub115>
artiq/master b0526c3 Sebastien Bourdeauducq: protocols/pipe_ipc: fix resource leak on Windows
<GitHub115>
artiq/master 18efca0 Sebastien Bourdeauducq: Merge branch 'master' of github.com:m-labs/artiq
<sb0>
bah, windows unittests look pretty fine.
<sb0>
without setting any environment variables, all pass
Gurty has quit [Ping timeout: 252 seconds]
Gurty has joined #m-labs
sb0 has quit [Quit: Leaving]
mumptai has quit [Remote host closed the connection]
stekern has quit [Ping timeout: 276 seconds]
stekern has joined #m-labs
sb0 has joined #m-labs
fengling has quit [Quit: WeeChat 1.4]
key2 has joined #m-labs
<sb0>
rjo, are the ttl outputs working for you?
<sb0>
i cannot get any signal
<rjo>
sb0: i suspect the numbering is all wrong.
<rjo>
sb0: in nist_clock, the ttls are not numberd the way i would expect from the schematic and the fmc pinout.
<rjo>
i notices that yesterday when looking at the spi stuff
<rjo>
but i assumed it was ok because it must have been checked already many times.
<rjo>
e.g. ttl7 collides with spi2.clk
<sb0>
mh
<sb0>
bah, yes it is. LA00_CC_N is ttl0 in gateware and ttl2 on the schematic
<sb0>
why make it simple ...
<sb0>
now Daniel also wants to send I2C through this other I2C-contrller switch on the KC705, because why not
<sb0>
*controlled
<rjo>
sb0: if you complain about many branches and merge commits, you should you should try to use rebase more often if you work in your local master instead of "Merge branch 'master' of github.com:m-labs/artiq".
<GitHub126>
[artiq] sbourdeauducq pushed 1 new commit to master: https://git.io/v26Ke
<GitHub126>
artiq/master c7d48a1 Sebastien Bourdeauducq: coredevice/TTLOut: add dummy output function
<rjo>
ack about the ttls but that must have been noticed before.
<sb0>
I still cannot get anything on ttl2.
sb0 has quit [Read error: Connection reset by peer]
sb0 has joined #m-labs
<sb0>
I can control the LED, but anything FMC looks broken
<rjo>
power?
<sb0>
I'm measuring at the connector directly, it should be connected directly to the FPGA
<sb0>
possible theory: there are multiple variants of the clock backplane...
<GitHub13>
[artiq] jordens pushed 2 new commits to spimaster: https://git.io/v2iUp
<GitHub13>
artiq/spimaster c2fe9a0 Robert Jordens: gateware.spi: delay only writes to data register, update doc
<GitHub13>
artiq/spimaster 324660a Robert Jordens: rt2wb, exceptions: remove RTIOTimeout...
ylamarre has quit [Client Quit]
<sb0>
rjo, what do you call "chained transactions"?
<sb0>
oh, without deasserting cs
<sb0>
rjo, so if you want to send a long series of bits, you want to send them fast enough so that the buffer is full and cs is never deasserted, but not too fast that it would cause a collision/bus error?!
<rjo>
sb0: yes. but this is all predictable. and you have to behave like this and predict it anyway to have a read working.
<sb0>
uhm
<sb0>
this makes the spi core pretty difficult to use in a non-realtime system
<rjo>
anyway, transactions longer than ~4 xfers are ectremely unlikely to become relevant. it is usually fine to have cs deassert in the middle.
<rjo>
sb0: this is how freescale did it. otherwise you handle cs somewhere else.
<rjo>
same here.
<sb0>
which somewhat defeats the purpose of this wishbone adapter
<rjo>
what?
<sb0>
bah, what if a freescale CPU gets an IRQ in the middle of a long SPI write that should not have CS deasserted?
<rjo>
as i said. it is usually benign to have cs deassert.
<sb0>
there are some devices that use CS for framing
<rjo>
and if it is not benign, and and you can't disable interrupts or you are worried about caching delays, you handle cs externally.
<sb0>
and big semiconductor companies do not always do the right thing. you may read the ACPI specification if you are not convinced.
<sb0>
what about a total transaction bit count register?
<rjo>
i am not saying this is is without wrinkles. but it also gets rid of a few problems.
<rjo>
then you can only switch from write to read once during a transaction. i don't know whether that is relevant though.
<rjo>
i had thought about this and there were a few other things.
<rjo>
anyway. maybe this can be done and it could help a non-rtio system. but for us you it doesn't really help because if you can't keep up, you get a problem anyway.
<sb0>
then we don't need wishbone
<rjo>
rt2wb is so thin i don't see how getting rid of wb would be an advantage. it certainly is a disadvantage for testing and precludes reusability.
<rjo>
if someone wants to improve the spi master accordingly it would still work fine for us.
<rjo>
that reminds me. the spimaster should go into misoc.
<sb0>
ok
<rjo>
ok to merge otherwise?
<sb0>
is LTO doing a good job at inlining rtio_output?
<sb0>
otherwise I'd define it "static inline" in a .h (which is what I did for rtio_write_and_process_status already iirc)
<whitequark>
sb0: we don't build the runtime with LTO
<whitequark>
since LTO needs gold and we are using ld.bfd
<whitequark>
I can look into building the runtime with LTO
<sb0>
.h + static inline should solve it faster.
<whitequark>
true
<sb0>
I don't see other areas that would really benefit from LTO
<rjo>
are we certain that inlining rtio_output outweighs the cache cost of having more, duplicate and larger code
<sb0>
are the experiments hopping between TTL-in/oe/o, DDS and SPI all the time?
<rjo>
yes. dds/ttl is common
<whitequark>
the OR1K code is pretty rare
<whitequark>
(as in opposite of dense)
<sb0>
or do they issue the same type of transaction to the same type of device in "bursts"
<sb0>
rjo, so you didn't touch the wishbone adapter in the end?
<rjo>
for dds-ttl it is frequent switches maybe in a 1:3 pattern. maybe 2:4 in batches.
<rjo>
no.
<rjo>
i ignored err. it is also optional in wb spec.
<sb0>
the spi core doesn't generate err either, does it?
<rjo>
no
<sb0>
certainly for ttl_set_o, inlining would be welcome
<sb0>
or have the compiler call rtio_output directly
<rjo>
well i can make it static in the header and then the compiler can decide at object compile time
<whitequark>
rjo: that still duplicates code
<rjo>
yes.
<rjo>
ok. let's have the pulse rate test for pipistrello decide this. if it helps there noticable, then i'll make it inline.
<whitequark>
-ffunction-sections
<rjo>
isn't that all we need for lto?
<rjo>
with the binutils ld?
<rjo>
i remember having lots of fun and bugs with that for some uC a while back
<whitequark>
no, -ffunction-sections has nothing to do with LTO
<whitequark>
LTO in practice means link-time code generation. needs a codegen plugin for ld to invoke LLVM
<whitequark>
-ffunction-sections is just dead-code elimination at linker level and hopefully function merging
<sb0>
rjo, i think we can get rid of ttl.c and have the compiler call rtio_output directly
<sb0>
ttl_get can be renamed rtio_input and go to rtio.c
<sb0>
rtio_input_timestamp even
<whitequark>
I doubt you have seen any LTO bugs for some uC because it (with the GNU toolchain) barely works on desktops IME
<rjo>
"with it". not trying function-sections and lto did help.
<rjo>
sb0: ack. will do.
<rjo>
sb0: this refactoring is nice. i think the bridge could previously artiq_raise_from_c which is a problem afaict.
<rjo>
well it can still do that now unless i refactor more.
<rjo>
how do i convert a bool to an int in ARTIQ-Python? whitequark, sb0?
<whitequark>
int() ?
<rjo>
it complains.
sj_mackenzie has quit [Remote host closed the connection]
<whitequark>
oh. it doesn't consider booleans numeric.
<whitequark>
1 if x else 0 ? :)
<sb0>
rjo, OK to merge otherwise. has anyone tested the DDS recently?
kristian1aul has joined #m-labs
<sb0>
whitequark, would it be hard to support int()?
kristian1aul has quit [Client Quit]
<whitequark>
no. I just think it's a stupid idea.
<whitequark>
Python's True coerces to 1 for historical reasons, and mixing up booleans and numerics is a frequent source of bugs.
<whitequark>
(if you ask me, a programming language doesn't need booleans at all, they're a poor fit to pretty much any domain that is not mathematical logic)
rohitksingh has joined #m-labs
<rjo>
sb0: not that know i know. i think the last testers were you with joe.
rohitksingh has quit [Client Quit]
<sb0>
I think Dave Leibrandt tested the 9914 system while I was there, and of course, found bugs...
rohitksingh has joined #m-labs
<sb0>
I did test the 9858 with Joe as well. surprisingly, it worked without any problem.
<sb0>
those 9914 bugs are fixed now, but I wonder if it broke again
<sb0>
rjo, oh, btw, the last problem I found is the 9914 is sending 3.3V back to the FPGA when reading registers, which goes through the FPGA clamp diodes that are at 2.5V
<sb0>
the solution is to reprogram those complicated power modules on the KC705 to bring the FMC voltage to 3.3V
<sb0>
Daniel is looking into how to do that exactly. seems there is some TI system that can permanently program them.
<larsc>
it's a 80 Euro USB-GPIO bitbang device...
<sb0>
it would be nice to get a better DDS power solution than a bunch of lab PSUs. they take too much space, and destroying something is too easy.
<sb0>
and after those two things are sorted out, we should probably install the DDS cards into the lab KC705, and have automatic unittests run on them regularly
<sb0>
maybe connect some sort of USB ADC/oscilloscope to them and check their output
<GitHub75>
[artiq] jordens pushed 3 new commits to spimaster: https://git.io/v2izA
<GitHub75>
artiq/spimaster 29776fa Robert Jordens: coredevice.spi: unused import
<GitHub75>
artiq/spimaster aa10791 Robert Jordens: rtio: rm rtio_write_and_process_status
<GitHub75>
artiq/spimaster 8adef12 Robert Jordens: runtime: refactor ttl*()...
<rjo>
sb0: yes. the power handling is horrible. same for that box daniel built.
<rjo>
sb0: yay hardware-in-the-loop unittests. i was mumbling that two years ago already.
kristianpaul has quit [Ping timeout: 244 seconds]
balrog has quit [Ping timeout: 244 seconds]
<sb0>
rjo, what PSU does he use in that box?
kristianpaul has joined #m-labs
kristianpaul has joined #m-labs
balrog has joined #m-labs
<sb0>
whitequark, did you figure out how to get the the TTL-clock, one TTL-out, and two TTL-inouts from that backplane?
<whitequark>
no, not yet. as I said I'll do that tomorrow
<rjo>
sb0: the psu (~15 U high) is actually outside the box (which is ~15 U high itself). it is a fat psu from acopian
<rjo>
maybe more like 9+9U in total.
<sb0>
huh, why?
<rjo>
the size?
<sb0>
yes
<rjo>
a low noise linear power supply for ~6 A of 3.3 V is pretty big. there are +- 15, 5, v as well and then many A at 1.8 V ...
<rjo>
i remember seeing about 5 fat very good acopian psus.
<rjo>
sb0, whitequark:does test_put_get() succeed for you?
<sb0>
rjo, works here
<sb0>
gateware 0.1+1004.g18efca0
<rjo>
does not complete on pipistrello.
<sb0>
is anyone using GPIOInOut from misoc? I'm going to add tristate capability to it, and break CSR interface compat
<sb0>
_florent_ larsc ^
<sb0>
mithro
key2 has quit [Ping timeout: 252 seconds]
<rjo>
redpid does not use GPIOInOut
<rjo>
the cache seems to generally crash pipistrello. whitequark any obvious thing i should look for?
<rjo>
sb0, whitequark: do the unittests work with your kc705 currently? if i merge spimaster now, could you run the tests with your device_db.pyon?
<GitHub142>
[artiq] jordens pushed 3 new commits to spimaster: https://git.io/v2PUr
<GitHub142>
artiq/spimaster 3aebbbd Robert Jordens: coredevice.ttl: fix sensitivity
<GitHub142>
artiq/spimaster 135643e Robert Jordens: runtime: define constants for ttl addresses
<GitHub142>
artiq/spimaster 6f9656d Robert Jordens: bridge: fix ttl o/oe addresses
<rjo>
pulse rate on pipistrello is about 2% slower with the refactored ttl.
rohitksingh has quit [Ping timeout: 248 seconds]
<GitHub56>
[artiq] jordens pushed 1 new commit to spimaster: https://git.io/v2PqS
<GitHub56>
artiq/spimaster 81b35be Robert Jordens: bridge: really fix O/OE
<GitHub56>
[artiq] jordens pushed 1 new commit to spimaster: https://git.io/v2Ps6
<GitHub56>
artiq/spimaster baf7b0d Robert Jordens: examples/tdr: adapt to compiler changes
FabM has quit [Ping timeout: 268 seconds]
FabM has joined #m-labs
stekern has quit [*.net *.split]
sb0 has quit [*.net *.split]
bentley` has quit [*.net *.split]
tmbinc__ has quit [*.net *.split]
FabM has quit [*.net *.split]
Gurty has quit [*.net *.split]
bb-m-labs has quit [*.net *.split]
felix_ has quit [*.net *.split]
zoobab has quit [*.net *.split]
attie has quit [*.net *.split]
ChanServ has quit [*.net *.split]
ysionneau has quit [*.net *.split]
mwalle has quit [*.net *.split]
siruf has quit [*.net *.split]
cr1901_modern has quit [*.net *.split]
kaalia has quit [*.net *.split]
rjo has quit [*.net *.split]
larsc has quit [*.net *.split]
mindrunner has quit [*.net *.split]
folkert has quit [*.net *.split]
balrog has quit [*.net *.split]
kristianpaul has quit [*.net *.split]
gric has quit [*.net *.split]
_florent_ has quit [*.net *.split]
acathla has quit [*.net *.split]
hozer has quit [*.net *.split]
[florian] has quit [*.net *.split]
jaeckel has quit [*.net *.split]
kyak has quit [*.net *.split]
whitequark has quit [*.net *.split]
mazzoo__ has quit [*.net *.split]
cyrozap has quit [*.net *.split]
hozer has joined #m-labs
early has joined #m-labs
jaeckel has joined #m-labs
<GitHub105>
[artiq] jordens pushed 3 new commits to spimaster: https://git.io/v2PSI
<GitHub105>
artiq/spimaster f30dc4b Robert Jordens: runtime: rt2wb_input -> rtio_input_data
<GitHub105>
artiq/spimaster 0456169 Robert Jordens: coredevice.spi, doc/manual: add spi
<GitHub105>
artiq/spimaster 2cc1dfa Robert Jordens: kc705: move ttl channels together again, update doc
<GitHub104>
[artiq] jordens pushed 1 new commit to spimaster: https://git.io/v2P7q
<GitHub104>
artiq/spimaster 5ba7534 Robert Jordens: runtime/rtio: rtio_process_exceptional_status() has only one user