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
Jeremy_ has joined #m-labs
Jeremy_ is now known as Guest88543
Guest88543 has quit [Client Quit]
_whitelogger has quit [Excess Flood]
_whitelogger has joined #m-labs
_whitelogger has quit [Excess Flood]
_whitelogger has joined #m-labs
_whitelogger has quit [Excess Flood]
_whitelogger has joined #m-labs
<whitequark>
rjo: (constant) yes. just like in regular python.
<whitequark>
(latent polymorphism) you have found a particularly degenerate case
FabM has joined #m-labs
<whitequark>
hm. I can suggest prohibiting narrowing via int() unless a width= is specified explicitly.
<whitequark>
(argument types of kernels) I'm not sure what do you imply by "tend"
<whitequark>
we do not currently have annotations for anything except RPCs and syscalls.
<whitequark>
I can add annotations for kernels, of course.
bb-m-labs has quit [Ping timeout: 260 seconds]
<whitequark>
sb0: which TTLs are input-only?
<sb0>
none
<whitequark>
oh.
<sb0>
you have output-only TTLs, and input/output TTLs
<whitequark>
ok, so I got pulse trains on two TTLs out of four.
<sb0>
they are described in the docs
<sb0>
okay, good
<whitequark>
the TTL0 pin is toggled if you use ttl2 channel
<sb0>
which ones?
<whitequark>
the TTL7 pin is toggled if you use ttl6 channel
<whitequark>
the TTL3 pin is ought to be toggled if you use the ttl3 channel, but it doesn't
<sb0>
did you call output() on it?
<whitequark>
yes.
<sb0>
we need: two inout TTLs, one output or inout TTL, and the clock generator TTL
<sb0>
unfortunately, none of ttl2 and ttl6 are inout
<whitequark>
just to verify that I'm not chasing mavericks: is it at all possible that a ttl is dead inside kc705?
<sb0>
yes, but unlikely. i'd rather suspect the reflow of the fmc connector on the nist backplane
<whitequark>
would that happen if someone shorted it?
<sb0>
unlikely
<whitequark>
do they have protection?
<sb0>
not really, but FPGA IOs aren't that fragile
<sb0>
short circuiting one for a short time is unlikely to do damage
<whitequark>
oh, a short time. then i killed ttl3.
<whitequark>
I've looked at the probe connection and I've swapped the probe ground and tip when connecting to that ttl pinhead socket
<sb0>
i've used that card for more than a year without killing it
<sb0>
...
<sb0>
did you add a delay after output()?
<whitequark>
yes, that was my second mistake
<sb0>
so, for now we have one useful pin
<sb0>
have you looked at la32/clockgen at all?
<whitequark>
yes. I did .set(1*ms)
<whitequark>
that didn't do anything.
<whitequark>
the backplane layout appears to be correct, so I'm at a loss as to why,.
<sb0>
ms?
<sb0>
it's a frequency
<whitequark>
*facepalm*
<whitequark>
no. set(500) still doesn't do anything
<sb0>
is the correct runtime function executed?
<sb0>
that used to work with my compiler and runtime
<sb0>
hasn't been tested since, so of course it's broken
<whitequark>
let me instrument it.
_whitelogger has quit [Excess Flood]
_whitelogger has joined #m-labs
<whitequark>
hm AttributeError: 'Platform' object has no attribute 'add_false_path_constraints'
<whitequark>
old igen
<sb0>
brb
sb0 has quit [Quit: Leaving]
bb-m-labs has joined #m-labs
sb0 has joined #m-labs
<sb0>
cool. the kernel folks fixed that touchscreen driver regression
J has joined #m-labs
J is now known as Guest40939
<Guest40939>
Hello guys, just to say: it was awesome to meet you yesterday and discover your projects. Cheers (Jeremy)
<whitequark>
sb0: sigh. I've just realized that the jtag bug you mentioned yesterday is preventing me from resetting the board.
<sb0>
whitequark, yes. you can power off the board, unplug, power on, flash, power off, replug, power on
<whitequark>
very convenient.
<sb0>
yes, totally...
<whitequark>
anyhow, I found the problem. rtio_output is called, but channel/addr=-600161824 1070187793
<sb0>
or short circuit the jtag switch. but please be careful and don't break anything.
<sb0>
especially as this is the only kc705 we have in HK
<whitequark>
well, I don't need this so far.
<whitequark>
oh wait
<whitequark>
that's not right. that's just the core_log call is lying.
<whitequark>
OR1K has different ABIs for vararg and non-vararg functions, so if you don't have a declaration for core_log, it will output garbage data.
<whitequark>
ok. hm.
<whitequark>
sb0: now rtio_output is called with channel=21 addr=0 data=0
<whitequark>
I take it data should've been the FTW?
<whitequark>
yes.
<sb0>
yes. and ftw=0 will drive a steady 0 at the output.
<sb0>
you can actually store kintex-7 fpgas at 150C according to the datasheet. so they are semi-compatible with UHV bakeout...
<whitequark>
sb0: ok, I got clock.
<whitequark>
the problem was a missing int64 conversion.
<whitequark>
but the frequency doesn't make any sense. I asked for 500hz, it's outputting 600.
<whitequark>
er
<whitequark>
60.
<whitequark>
59.5 exactly actually.
<sb0>
ah, hm
<sb0>
yes, I see what that bug is
<sb0>
did you mean 62.5Hz?
<sb0>
wait
<whitequark>
is there a way to reset the board without JTAG?
<sb0>
yes, press the FPGA_RESET (I think) button
<whitequark>
ah yes this is great
<sb0>
yes, 59.6 is what I expect from this bug
<whitequark>
I zoomed in and yes, it's 59.6
<sb0>
whitequark, I will fix it, can you commit the int64 fix and find out the other TTLs?
<whitequark>
sb0: where do I look up the list of inout TTLs?
<sb0>
whitequark, ARTIQ docs, "FPGA board ports"
<GitHub72>
[artiq] whitequark pushed 1 new commit to master: https://git.io/v25U2
<whitequark>
sb0: preferably in the FPGA pin domain, not ARTIQ channel number domain
<whitequark>
since this would just double my work
<sb0>
whitequark, then you have to look at migen/platforms/kc705 (or kc705 schematics), and cross it with artiq/gateware/nist_clock
<sb0>
artiq/gateware/nist_clock gives you standard FMC pin names already, I don't think you need the BGA ball numbers?
<whitequark>
oh yes, I meant FMC pin names
<whitequark>
sb0: so, is there a list of FMC pins with input capability? are these the ones with _CC_?
<sb0>
whitequark, all FMC pins are bidirectional
<whitequark>
oh, it's the RTIO quirk
<sb0>
it's only in ARTIQ that input mode is not supported for certain pins (to save FPGA resources and avoid the output() call) and driving all the time
<sb0>
the hardware which gets connected eventually is unidirectional for those anyway
<sb0>
(the circuit that plugs into the TTL connector on the backplane)
<whitequark>
ok yes I see, ttl3, ttl7, ttl11, ... are IO
<rjo>
whitequark: (constants) but does a module level constant incure attribute load and writeback? i thought that's why we don't put the constants into class attributes.
<rjo>
(kernel arg types).giving default values forces a certain type because of unification. not having a default arg can lead to hidden problems because it may unify differently.
<whitequark>
rjo: (constant) so a module level variable is just a local variable caught in a closure. I do not treat them differently
<whitequark>
and we do not write back those.
<rjo>
so they all get attribute writeback after a kernel?
<rjo>
ah
<whitequark>
I *think* it's not possible to modify a closure in Python
<whitequark>
the caught values are stored in a tuple
<rjo>
so module level constants are advantageous because they cause less traffic, right?
<whitequark>
yes.
<rjo>
attributes of mofule level objects? do they get written back?
<rjo>
*module
<whitequark>
it doesn't matter where the object is, as what triggers writeback is the fact that something is represented by an object.
<whitequark>
sorry, earlier I was not quite correct, in python module level constants are *not* captured in a closure
<whitequark>
they're acquired from __globals__
<whitequark>
however, I do treat them as-if they were captured in a closure.
<whitequark>
rjo: (kernel arg types) yes. I know. this is the same behavior as if you added e.g. "if False: x = 1" instead of having "def f(x=1)"
<whitequark>
both lead to unification.
<rjo>
so accessing an attribute of a module level object would be written back?
<whitequark>
yes, just like with any other object.
<whitequark>
since objects can be referenced from many places, it doesn't make sense to speak of a "module level object" anyway
<rjo>
just verifying that the conclusions i came to are correct.
<rjo>
annotating instead of default args would be nicer IMHO but low prio for now.
<whitequark>
writeback works by enumerating all objects that were codegen'd, going through reflection info about their attributes, and RPCing setattr.
<whitequark>
please make an issue for annotations then
<whitequark>
most of the code is already there...
_whitelogger has quit [Excess Flood]
_whitelogger has joined #m-labs
<sb0>
whitequark, do you confirm TBool -> int?
<GitHub13>
[artiq] sbourdeauducq pushed 2 new commits to master: https://git.io/v25Ig
<GitHub13>
artiq/master c2fcefc Sebastien Bourdeauducq: runtime/rtio: cleanup include
<GitHub13>
artiq/master 354a62f Sebastien Bourdeauducq: Merge branch 'master' of github.com:m-labs/artiq
<GitHub101>
[artiq] sbourdeauducq pushed 2 new commits to master: https://git.io/v25Lc
<sb0>
rjo, shouldn't your SPI driver make use of core.coarse_ref_period/core.ref_multiplier?
<whitequark>
sb0: I can't seem to get any signal out of TTL11 and TTL15 (by ARTIQ mapping)
<whitequark>
and I notice they weren't in the device_db
<sb0>
the example device_db is very incomplete
<sb0>
11/15 should be working afaik
<whitequark>
ok, so there isn't any inherent reason they shouldn't wor
<rjo>
sb0: ah. yes. i didn't see those.
<whitequark>
sb0: hm.
<sb0>
I don'
<sb0>
t find specs for maximum IO currents/voltages/powers. possibly the k7 can indefinitely survive shorted IOs.
<sb0>
s/voltages//
<whitequark>
sb0: well
<whitequark>
I traced ttl11 and ttl15 and they should arrive where I think they should on the backplane
<whitequark>
however, I still see no signal. and they're for sure not dead either.
<sb0>
as long as you don't short enough of them that the maximum junction temperature is exceeded, I guess. but a single IO cannot drive so much current that it will become a problem.
<whitequark>
so maybe they have the same problem as ttl3.
<whitequark>
I can try... hm... toggling all 15 TTLs and seeing if this gives me any ideas
<sb0>
if you suspect TTLInOut, you can try replacing it with a TTLOut in the bitstream
<whitequark>
all 16.
<sb0>
whitequark, wait, did you use the TTLInOut driver, not the TTLOut one?
<whitequark>
TTLInOut.
<whitequark>
what would happen if I used TTLOut?
<sb0>
the output would not get driven
<sb0>
the output() call will go nowhere
<whitequark>
actually, I just had the greatest idea. I should've skipped all the tracing.
<whitequark>
ttl0 outputs a 1ms pulse, ttl1 outputs a 2ms pulse, ...
<sb0>
whitequark, the clock generator should work now btw (after those two commits)
<whitequark>
sb0: yep the pins which don't work are exactly TTLInOut ones
<sb0>
whitequark, did you reboot the router? the IP changed. it's in another range now, so it could be that they gave us static IP.
<whitequark>
sb0: yes, I did. I bought and installed a larger power strip so that scope could be plugged into it too.
<whitequark>
if you haven't updated the IP let me reboot it again to verify that they did give us static IP
<sb0>
ok. haven't updated ...
<whitequark>
nope, they did not.
<whitequark>
the new one is 101.78.169.145.
bb-m-labs_ has joined #m-labs
<whitequark>
oh, you can just /whois bb-m-labs
<sb0>
bb-m-labs, force build artiq-kc705-nist_qc2
<sb0>
bb-m-labs_, force build artiq-kc705-nist_qc2
<bb-m-labs_>
build #156 forced
<bb-m-labs_>
I'll give a shout when the build finishes
<sb0>
bb-m-labs_, force build artiq-kc705-nist_clock
<bb-m-labs_>
build #95 forced
<bb-m-labs_>
I'll give a shout when the build finishes
<sb0>
whitequark, okay, can you have a look at the TTLInOut problem?
<whitequark>
well I am taking a look.
<sb0>
whitequark, there's another TTLInOut on user_sma_gpio_n, which as I demonstrated to you is working
<sb0>
can you try using it to confirm that you are doing it correctly?
<whitequark>
I do get a signal from user_sma_gpio_n
<sb0>
whitequark, can you replace "if i % 4 == 3:" with "if True:" in gateware/targets/kc705 and see if it breaks the currently working TTLOut channels?
<sb0>
you can compile the gateware on the buildserver with python3 -m artiq.gateware.targets.kc705, and load to FPGA SRAM with openocd
<whitequark>
I restarted them and put them in a cronjob @restart
<whitequark>
@reboot
<rjo>
sb0, whitequark do you guys have a scope hooked up to the kc705 in the lab? could i use that setup to verify that the spi waveforms are correct?
<whitequark>
yes, I do
<whitequark>
and I'll capture waveforms for you if you say which FMC pins I should probe
<rjo>
ok. i'll prepare and then when you guys are done with the testing, i'll let you know. thanks.
<rjo>
is that scope/logic analyzer on the network?
<whitequark>
it's a rigol scope. i can plug it into the lab.m-labs.hk.
<rjo>
usb? model?
<whitequark>
it's not supported by sigrok though so you'll have to find your own way of extracting images from it. it supports USB TMC and the documentation is available.
<whitequark>
let me try bringing it up myself first
<whitequark>
sb0: do we have a cable with USB-B end?
<rjo>
doesn't that also have ethernet?
<whitequark>
huh it does.
<whitequark>
but we're out of ethernet cords either.
<whitequark>
sigh. well, let me go for lunch, there's a shop nearby that sells them.
<sb0>
whitequark, yes, probably either on my desk or on the dirty vacuum table
<sb0>
rjo, there is also my chinese scope, which might be supported by sigrok. whitequark what is the model again?
<whitequark>
sb0: that one is 3.0
<whitequark>
it won't fit into my scope
<whitequark>
ga1202cal, and it's not
<whitequark>
two channels anyway
<sb0>
there should be a spare ethernet cord nearby, too
fengling_ has quit [Quit: WeeChat 1.4]
<rjo>
sb0, whitequark, ok if i touch the kc705?
<sb0>
ok for me, whitequark ?
<rjo>
i guess he is out for lunch
<whitequark>
sb0: yes, there was an ethernet cord, but it was a tad too short.
<whitequark>
wouldn't want to kick the router off its place easily, it'll bring down everythin
<whitequark>
anyway I got a cord.
<whitequark>
rjo: you can use kc705 meanwhile.
<whitequark>
the scope is at rigol-ds1074z.lab.m-labs.hk
<whitequark>
unfortunately, it identifies itself as ds1104z, and sigrok doesn't know that *IDN rsponse.
<whitequark>
I'll patch it in a moment.
<whitequark>
rjo: is your system an amd64 debian?
<rjo>
whitequark: excellent. did you install sigrok?
<rjo>
my laptop? or my other machines here?
<whitequark>
whatever you're going to run sigrok on
<whitequark>
I was planning to build a patched libsigrok deb
<whitequark>
hm weird
<whitequark>
it
<whitequark>
it's already there...
<rjo>
i have little experience with sigrok (it seemed to conglomerated to me). but if it has cli tools and can output vcds, i'll use it that way on the lab.m-labs.hk
<whitequark>
conglomerated?
<rjo>
google it. i feared it wasn't a word in english but it apparently is.
<rjo>
to big and messy
<whitequark>
i know what the word means.
<rjo>
but maybe sigrok is fine.
<whitequark>
hm. dunno. good enough for my taste, at least as long as you insist on doing it in C
<whitequark>
(well, not you, whoever is writing it)
<whitequark>
libsigrokdecode and pulseview are a bit too special-casey
<whitequark>
I tried to make an OOK decoder but it was a huge pain to feed back the data to another decoder.
<whitequark>
oh. debian has libsigrok 0.3. ds1104z is supported since 0.4.
<whitequark>
classic
<rjo>
whitequark: what do you have hooked up the scope already (so that you don't have to do too much rejiggering)?
<whitequark>
nothing.
<whitequark>
are you going to use the TTL* outputs on the backplane or SPI*?
<sb0>
rjo, i don't like batching drivers. with the new crates/drtio, we should have enough FPGA IOs that they become unnecessary.
<whitequark>
hm, no debs anywhere. guess i could build them myself...
<whitequark>
sb0: ha. sigrok supports using our pipistrello as a logic analyzer
Guest40939 has quit [Quit: Page closed]
<rjo>
whitequark: the spi wires. but they are on the backplane next to the ttls, right?
<rjo>
sb0: you need batching behavior already for a 40 channel dac. it has only one bus.
<rjo>
ad5370
<whitequark>
rjo: the problem is that the backplane is seriously fucked up so I'll have to trace those wires and figure out where they *actually* go
<whitequark>
please give me the FMC pins you want to be probed and I will set it up accordingly
<rjo>
whitequark: alternatively i can use the xadc header.
<whitequark>
is that less fucked up?
<whitequark>
or is it not on the backplane?
_whitelogger has quit [Excess Flood]
_whitelogger has joined #m-labs
<rjo>
it's a different 0.1 inch header near the usb connectors
<whitequark>
ok. which pins should I probe?
<rjo>
do you prefer the xadc then?
<whitequark>
oh. it's a header. not a socket.
<whitequark>
I don't have anything to reliably hook up to that, so let's go with the backplane.
<whitequark>
which FMC pins do you need?
<rjo>
on xadc (J46) it would be 17, 18, 19, 20, trigger on 19 falling
<rjo>
fmc. let me look them up.
<rjo>
la13_n, la14_n, la17_cc_p, la17_cc_n, and one ttl, let's take ttl0, la00_cc_n, trigger on la14_n falling
<rjo>
drop la17_cc_n from that list. it's not needed
<rjo>
and you only have four channels, right?
<whitequark>
yes.
<whitequark>
rjo: ok. it does not seem to work properly using tcp.
<rjo>
whitequark: i am looking into github.com/pklaus/ds1054z
<whitequark>
btw please don't touch the scope just now because it is updating
<rjo>
i won't
<whitequark>
(the firmware)
<rjo>
whitequark: ok to install those sigrok debs on lab.m-labs?
<whitequark>
~whitequark/sigrok? yes.
<whitequark>
aha! I updated the firmware and now it captures properly from TCP.
<rjo>
whitequark: should i play with it or do you set it up?
<whitequark>
not quite
<whitequark>
rjo: yes. you can play with it now.
<rjo>
whitequark: all hooked up? channels mapped how?
<whitequark>
no, I mean, try getting any data out of it at all.
<rjo>
screenshots work fine.
<whitequark>
hm.
<rjo>
will try sigrok now
<rjo>
sr: rigol-ds: Received invalid data block header 'co'
<whitequark>
yes, exactly.
<whitequark>
it's the start of "command error"
<whitequark>
oh, I have an idea.
<rjo>
i can try that python script. that seemed fine.
acathla has quit [Quit: Coyote finally caught me]
<rjo>
whitequark: what are you doing?
<whitequark>
I was going to downgrade the firmware to what I thought the sigrok devs were using.
<whitequark>
but it refuses to downgrade for whatever reason
<rjo>
ah
acathla has joined #m-labs
<rjo>
whitequark: can i try that python thing?
<whitequark>
oh
<whitequark>
sigrok suddenly started working properly.
acathla has quit [Changing host]
acathla has joined #m-labs
<whitequark>
ah no, it didn't, I misread.
<whitequark>
rjo: so, interestingly, it *does* work with pulseview.
<whitequark>
so you can do an SSH passthrough thing and use pulseview from your laptop. then you can easily configure trigger/channels/etc
<whitequark>
oh, yes, I understand what happens
<whitequark>
instead of doing something nice when it submits the end of the frame, it just barfs with an error
<whitequark>
oh wait, pulseview only works with local USB devices; it doesn't have a tcp backend
<whitequark>
welp
<rjo>
i'll just use the python tools.
<rjo>
once you release it.
<whitequark>
oh, and the trigger setup doesn't work
<whitequark>
released.
<whitequark>
ok. let me set up the probes.
<whitequark>
12:05 < rjo> la13_n, la14_n, la17_cc_p, la17_cc_n, and one ttl, let's take ttl0, la00_cc_n, trigger on la14_n falling
<_florent_>
can I add some prints to help debugging?
sb0 has quit [Ping timeout: 240 seconds]
<whitequark>
do it locally?
sb0 has joined #m-labs
sb0 has quit [Quit: Leaving]
sb0 has joined #m-labs
bentley` has joined #m-labs
<sb0>
whitequark, rjo can I mess with the kc705?
<rjo>
sb0: yes. spi looks good so far.
_whitelogger has quit [Excess Flood]
_whitelogger has joined #m-labs
<sb0>
_florent_, if you replace 1024 with 1, does it still block?
<sb0>
I'm unsure if asyncio will do a partial read
<_florent_>
with 1 it still blocks
<sb0>
since there is approximately zero thought that went into the architecture of asyncio, you have to hack into internal/undocumented functions called by the hacky ad-hoc crap that passes as API in order to get anything done
<_florent_>
hmmm ok, I don't know anything about asyncio, but that seems strange that it's blocking here where we are only defining the event loops...
<sb0>
_florent_, so asyncio.ensure_future() is never returning?
<sb0>
or self.port.read() isn't
<_florent_>
ah sorry yes it's AsyncSerial.read(self, n) that is not returning