<GitHub52>
ionpak/master dce70f3 whitequark: Fix signature of panic_fmt.
<sb0>
where was cjbe's report on urukul sync again?
<sb0>
ERROR: [Synth 8-4556] size of variable 'data_mem' is too large to handle; the size of the variable is 1048576, the limit is 1000000 [/home/sb/artiq_drtio/artiq_sayma/standalone/gateware/top.v:75922]
<sb0>
vivado never ceases to amaze by its crappiness
<hartytp>
I have some python SCPI ethernet drivers for things like DMMs SAs Scopes Synths etc that I'd like to clean up and package up
<hartytp>
to work with ARTIQ
<hartytp>
do you know of a repo with that already that I should contribute to?
<hartytp>
or should I start my own? Or, is this something you'd be interested in hosting/managing at m-labs/quartiq?
<sb0>
hartytp, the general policy for ARTIQ drivers is, drivers that are useful without ARTIQ (and where you can expect someone doesn't want to pull in all the ARTIQ dependencies) or drivers that pull in other dependencies (hidapi for lda or libusb/pyusb for newfocus8742) should be separate.
<hartytp>
right
<sb0>
if they don't have dependencies, and are artiq-specific, I suggest merging them into artiq. otherwise I guess create your own repos
<hartytp>
okay, I'll create my own repo
<hartytp>
No explicit artiq dependency
<hartytp>
just writing them with artiq integration in mind
<hartytp>
SCPI is pretty common and some basic instrument drivers seems like a nice thing for people to have access to
<sb0>
yes
<sb0>
so you want to structure your driver with a) a generic python part and b) an artiq controller?
<hartytp>
So, if this is something that there is community interest in then it might be worth hosting it somewhere like M-Labs and maintaining it to a higher standard. Otherwise, I'll just host something on my github
<sb0>
as an intermediate solution: we can also list your repository (and similar ones) in the artiq docs. and we can still look over the code etc.
<hartytp>
well, let's start with that
<sb0>
I have a preference for this kind of more decentralized organization, but if you feel strongly about this I can also create a repos under m-labs
<hartytp>
anyway, basically just a heads up that I'm going to slowly work on getting something into a decent shape
<whitequark>
re: Python SCPI drivers
<whitequark>
shouldn't we just use sigrok?
<whitequark>
it already has Python bindings. sigrok-meter is written in PyQt
<hartytp>
hadn't seen taht
<hartytp>
taht
<hartytp>
that
<rjo>
IME "generic SCPI bindings" tend to be less than helpful.
<whitequark>
rjo: elaborate?
<whitequark>
sigrok has per-instrument implementations of SCPI
<GitHub104>
ionpak/master 941f602 whitequark: Use the crc crate.
<rjo>
whitequark: there are many devices with half compliant, barely compliant or uncompliant SCPI implementations. that makes the greatest common denominator pretty much 1. and even if you were to ignore all the devices that don't comply what are you offering with a SCPI abstraction? is it just "MEAS:VOLT:DC?" -> measure_voltage_dc() ?
<whitequark>
why does it matter whether the device is SCPI compliant or not?
<rjo>
if you are trying to build a layer that allows you to swap a tek and a hp scope underneath and still use a common interface with a non-trivial set of features, good luck.
<rjo>
whitequark: if it's not compliant, it's unusable with generic SCPI bindings
<whitequark>
who said anything about generic SCPI bindings?
<rjo>
you asked me about them.
<whitequark>
yes, that's what I mean
<whitequark>
where did generic SCPI bindings ever come from?
<rjo>
that's what i observe when people write a driver for their instrument and find another that they want to use as well.
<hartytp>
rjo: how long do you expect SPI reads (spi.bus.read) to take?
rohitksingh_wor1 has quit [Read error: Connection reset by peer]
sb0 has quit [Quit: Leaving]
<rjo>
time between what?
<rjo>
you mean the negative slack after SPI.write(); SPI.read()? iirc 2-10 µs.
<hartytp>
yes
<hartytp>
why so long?
<rjo>
it's pretty much symmetric. write() and read() take about the same CPU time because they traverse the same depth of code, CPU, RTIO.
<rjo>
what would you have expected?
<rjo>
iirc it's closer to 2µs. compared to the ~2µs (?) of slack that write() needs.
Gurty has quit [Ping timeout: 265 seconds]
<hartytp>
Looking at sampler, I found I need a 6us delay between calls to sample_mu on 2 channels
<hartytp>
so the total cycle time as abou 8us, even though the SPI is only 2us (and could be faster without SI issues)
<hartytp>
so, that's a bit disappointing
<hartytp>
I also found that passing a list of 30k integers to a kernel takes approximately an eternity
<hartytp>
but, I think that's a known bug
<hartytp>
anyway, I guess this all falls under the general category of ARTIQ being a bit painfully slow
hartytp has quit [Quit: Page closed]
Gurty has joined #m-labs
sb0 has joined #m-labs
<rjo>
hartytp: with novogorny to do faster sampling on bursts, pipelining the transfers got increased the sample rate by roughly a factor of two.
<rjo>
you haven't told me what you expected and how you arrived at that expectation. it would be great if people could convert their complaints about speed into funding and specifications for speed improvements.
hartytp has joined #m-labs
<hartytp>
rjo: IIRC for the Sampler driver, we agreed that burst writes to the SPI bus should come close to saturating the SPI bus, and that the speed of continuous reads should be limited by general RTIO infrastructure
<hartytp>
AFAICT, the driver you've written satisfies that
<hartytp>
(well, there isn't a burst read function, but I don't need that atm and it's that's trivial to add later if one wants it)
<hartytp>
so, no complaints about that
<hartytp>
this is more of a general moan about the speed of various things in ARTIQ in the hope that letting the developers know what's limiting us
<rjo>
hartytp: all ack.
hartytp has quit [Quit: Page closed]
rohitksingh has joined #m-labs
rohitksingh has quit [Quit: Leaving.]
<cjbe__>
sb0: core.reset() now seems to reset the direction of InOut TTLs to input - previously the direction was maintained. Is this an intentional change?
<rjo>
cjbe__: no. core.reset() should not touch phy state. could you file an issue?
<GitHub-m-labs>
[artiq] sotirova opened pull request #972: Sampler rename v_ref to v_span, fix default value in adc_mu_to_volt (master...sampler_vref) https://github.com/m-labs/artiq/pull/972
<GitHub-m-labs>
[artiq] hartytp commented on issue #972: NB `span` here was intended to denote the ADC differential input span, not Sampler's input span. I don't think that's as confusing as all that, but maybe the comments could have been clearer.... https://github.com/m-labs/artiq/pull/972#issuecomment-376627113
<GitHub-m-labs>
[artiq] jordens commented on issue #972: NB: Use `git rebase --interactive` to squash, reword and clean up your changes. `git revert` is probably not what you are looking for. https://github.com/m-labs/artiq/pull/972#issuecomment-376665454
<GitHub-m-labs>
[artiq] gkasprow commented on issue #854: What SFP-RJ45 module did you use?