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
fengling has joined #m-labs
<sb0>
rjo, I still dislike the double-buffering controlling CS. if you put that core in a CPU system, having the CPU timing change the semantics of SPI is weird and obscure, it is difficult to debug, and it is difficult to guarantee the correct transaction
<sb0>
using the freescale SPI controller would annoy me for those reasons.
<sb0>
what is wrong with a "total number of bits during which CS should be asserted" register? you can still mix reads and writes with that
<sb0>
rjo, did you test the bridge with e.g. the LED?
<sb0>
rjo, those unittests I can run without a physical TTL loopback are fine.
fengling has quit [Quit: WeeChat 1.4]
fengling has joined #m-labs
cr1901_modern1 has joined #m-labs
sj_mackenzie has joined #m-labs
<GitHub51>
[artiq] sbourdeauducq pushed 2 new commits to master: https://git.io/v21te
<GitHub51>
artiq/master 946bd84 Sebastien Bourdeauducq: protocols/pc_rpc: support retrieving selected target
<GitHub56>
[artiq] sbourdeauducq pushed 1 new commit to master: https://git.io/v21t3
<GitHub56>
artiq/master 763a4d3 Sebastien Bourdeauducq: rpctool: use pprint in interactive mode
mumptai has quit [Ping timeout: 248 seconds]
mumptai has joined #m-labs
cr1901_modern1 has quit [Ping timeout: 248 seconds]
cr1901_modern has joined #m-labs
<sb0>
mithro, ok. i'm only going misoc master (not legacy)
<sb0>
*to modify
<whitequark>
rjo: re pipistrello: underprovisioned RAM?
<whitequark>
rjo: are gateware and runtime up to date?
<sb0>
whitequark, try it on yours...
<whitequark>
is there a way to flash it yet without wasting hours fighting xc3sprog?
<sb0>
connect it to the build server, conda install artiq-pipistrello-nist_qc1, artiq_flash -t pipistrello
<whitequark>
ah great
<sb0>
you should run a conda build for pipistrello before though
<whitequark>
bb-m-labs: force build artiq-pipistrello-nist_qc1
<bb-m-labs>
build forced [ETA 42m39s]
<bb-m-labs>
I'll give a shout when the build finishes
<sb0>
yes.
<sb0>
openocd is in /usr/local/bin
<mithro>
sb0: Do you know if there is any way to dynamically change IO standards that a Spartan 6 pin is using?
<sb0>
mithro, not in a xilinx documented way. but if you reverse engineer the IOB frame a bit, writing it into the ICAP should do the trick.
<sb0>
you can prepare two bitstreams with the different io standards you want and diff them
<sb0>
the slightly tricky part is to figure out the FAR value, location, and size of the IOB frame in the ISE-generated bitfile, but I think Wolfgang sorted that out
<mithro>
sb0: I saw a while back you had some tools for doing something like that?
<mithro>
It would be really awesome to have a GSoC student work on reverse engineering the Spartan 6 bitstream format, but I doubt we'd get a suitable student
<bb-m-labs>
Hey! build artiq-pipistrello-nist_qc1 #154 is complete: Success [build successful]
<whitequark>
okay. Error: unable to open ftdi device with vid 0403, pid 6010, description 'Pipistrello LX45' and serial '*'
<sb0>
yes, this is #290
<sb0>
not a complicated one, but someone needs to test and all to avoid idiotic bugs that never miss an opportunity to manifest themselves in such refactorings
<whitequark>
hm, wtf
<whitequark>
Error: libusb_open() failed with LIBUSB_ERROR_ACCESS
<whitequark>
but I'm a member of dialout
<sb0>
are the permissions set?
<whitequark>
oh, it's using libusb, not ttyUSB
<sb0>
isn't it supposed to be plugdev?
<sb0>
there are also udev rules in the artiq doc iirc. would be a good opportunity to test them.
<whitequark>
sb0: ok. there is some crap on the serial line. how do I use pppd?
<sb0>
that's in the doc, too
<sb0>
"FPGA board ports" section
<whitequark>
ah, found it
<whitequark>
hm, wonder if I can put it on our internal network
<whitequark>
probably not
<whitequark>
well, not without annoying iptables shit
<GitHub133>
[migen] sbourdeauducq pushed 1 new commit to master: https://git.io/v21ND
<GitHub133>
migen/master bc21743 Sebastien Bourdeauducq: build/xilinx: fix error message when Xilinx toolchain directory exists but does not contain a ISE version directory. Closes #39
Gurty has joined #m-labs
<rjo>
sb0: the double buffer is needed in any case. it has little to do with controlling cs.
<rjo>
sb0: for us, having a "total transaction counter controlling cs" does not really help because we have rtio. if somebody wants to change the core accordingly that's fine by me.
<sb0>
why is the double buffer needed? for meeting timing?
<rjo>
sb0: bridge works fine here on pipistrello but the gui sometimes does not react to right clicks.
<rjo>
whitequark: yes. all are up to date. did you check that the memory you are using for the cache also fits on pipistrello?
<sb0>
rjo, what part of the gui, the TTL injection?
<sb0>
did that work before your changes?
key2 has joined #m-labs
<rjo>
sb0: pretty sure it is a gui-only issue. if i undock the ttl dock and re-dock it it reacts for one click again.
<rjo>
sb0: because you have to do two wb transactions per (chained) transfer: one to read the previous data and one to write the next and trigger the (chained) transfer.
<sb0>
by "react" do you mean "opening the menu" or "the menu option does something"?
<rjo>
it does not open a context menu on right click anymore after a while.
<rjo>
works three times. then stops working.
<sb0>
are you clicking the number?
<rjo>
also broken before the spimaster merge.
<rjo>
might be general business of the ppp link.
<rjo>
it persists over gui restarts.
<sb0>
nothing is sent to the core device when you open the meny
<rjo>
LMB on the number does not do anything.
<sb0>
*menu
<sb0>
and RMB?
<rjo>
as i said. works sometimes.
<rjo>
ah it is only sensitive on the number?
<rjo>
not on the button ?!
<rjo>
then it was just the fact that the button is not actually sensitive.
<rjo>
the thing that concerns me currently is that the buildbot does not meet timing anymore with spimaster. but each time i run it myself it does meet timing just fine. both failure and success are reproducible on kc705 and pipistrello.
<GitHub83>
[migen] sbourdeauducq pushed 1 new commit to master: https://git.io/v2Mvi
<GitHub83>
migen/master ba8f576 Sebastien Bourdeauducq: sim: add more signals to VCD (#36)
<sb0>
rjo, yes, only on the number...
<sb0>
this could be changed
<rjo>
if it looks like a button it should behave like a button if possible.
<sb0>
whitequark, probably the buildbot should mark the build as failed, or at least show a warning, when timing is not met
<sb0>
rjo, there is a discussion on github about replacing the menu with buttons that are shown only when the cursor is over the widget
<sb0>
whitequark, have you been able to reproduce the cache unittest failure?
<rjo>
i suspect that it is printing something (crash or log) on the console. but pppd is smart enough to gloss over it.
<whitequark>
strace pppd?
<rjo>
instead i went on to look at other things.
<sb0>
rjo, would you think a CF35 6-way to be a good vacuum chamber for a "simple" ion trap?
<sb0>
this way it's a standard part and there won't be any CAD, machining or welding involved
<rjo>
sb0: yes. we frequently build traps like that.
<rjo>
sb0, _florent_: i suspect the ethernet mac is the underlying timing issue that makes the artiq soc fail timing (on 2015.4 consistently, reproduciblt and for a long time already, on 2014.2 on the buildbot intermittently before and now more reliably due to probably unrelated changes in the gateware).
<rjo>
_florent_: did liteth never have timing issues for you?
<rjo>
iirc the artiq soc never met timing for vivado >= 2014.4 for me.
<felix_>
mithro: why s6 and not a7? a7 is much better and newer. at least i wouldn't spent time reversing s6, but i'm interested in reversing a7. but currently not time for that
<rjo>
the timing problem on pipistrello seems rare enough (both here and on the buildbot) to ignore it.
<felix_>
mithro: oh, and at least for the coreboot gsoc thing it was said that reverse engineering projects can't (or was is shouldn't?) be done in the context of gsoc
<rjo>
whitequark: ARTIQ-Python, if i have the usual pattern of '__init__(self, foo_name=None): if foo_name is None: self.foo=dmgr(foo_name); else: self.foo=None' the compiler complains about not being able to unify None with the object. How do i handle an attribute that is either an object or a "NULL pointer"?
<whitequark>
you cannot.
<rjo>
whitequark: any way to do what i want to achieve?
<whitequark>
not without complex changes to the compiler, I'm afraid.
<whitequark>
I'm not yet sure how complex. I'll need to think about it.
<rjo>
well i can leave it to the user to not call the kernel that would make use of of the object if it is not None.
<whitequark>
what do you mean?
<whitequark>
i.e. not call the kernel that needs an object if the object is not available?
<rjo>
the kernel methods that use the attribute are like "if self.foo is not None: self.foo.do_something()"
<whitequark>
yes, that's the easiest way to solve this
<whitequark>
the problem with optional types (what you want) is that not everything has an indirection.
<whitequark>
well, the first problem, that is. for things that have a pointer, it is relatively easy to handle this, but not for things that are expanded inline
<whitequark>
e.g. tuples
<whitequark>
a "tuple or None" would need to become a proper optional i.e. have an explicit "is present" flag.
<rjo>
ack
<whitequark>
the second problem is that representing union types (like "Foo or NoneType") rather than sum types (like "SomeWrapper (that has methods that may return Foo or raise)") is quite awkward
<whitequark>
in the type system that we have, that is.
<rjo>
and is there really no way to prevent me from sprinkling int() everywhere to keep it from makeing an int64 out of an int32 each time i e.g. add something to it?
<whitequark>
it doesn't really mesh with the ML-style unification and combined with Python's weak typing would become a complete nightmare i.e. require annotations everywhere
<whitequark>
and we don't even have a syntax for annotations on non-arguments
<whitequark>
hm, your int problem is odd.
<whitequark>
are you saying that... x = int32(0); x + 1 returns an int64?
<whitequark>
that should not happen for sure
<rjo>
it hink so. at least that's how i read the complaint.\
<whitequark>
try that. you'll see this is not the case
<rjo>
maybe i read it wrong then. maybe another thing why can't delay_mu(int32) simply cast to int64?
<rjo>
_florent_: i know that you might see misoc/migen to be a bit of a fast moving target (that's why you forked them in litex, i presume). but i think it would be really really beneficial if those parts could be merged/reintregrated again, and misoc/migen be released. maybe mithro's GSoC students can help here.
<_florent_>
yes I'm willing to reintegrate that, just that I was very busy these last months
<_florent_>
I'll have more time for that in the next weeks
<_florent_>
are timings better with the false path constraints?
<rjo>
_florent_: that's fine. i wasn't complaining. might also be a nice task for a migen/misoc beginner like the GSoC students.
<rjo>
the timing paths seem better
<rjo>
i'll do a 2015.4 run now
<rjo>
it is impressive and suspicious that there can be path delays longer than 7 ns on that chip.
<rjo>
also it systematically starts with lots of hold violation. afaict that is indicative of slock skew. but i could not see the how and why for that.
<_florent_>
yes that can be a nice task for a student, maybe I should create MiSoC issues for these things (at least if that's not a student that do it that will be me)
<rjo>
it think issues are fine for that in any case.