<whitequark>
if I add another self.ttl1.off() then the analyzer doesn't show me *any* messages
<sb0>
can you make it not underflow for now?
<sb0>
and take some bug sources out of the equation
kmehall_ has quit [Read error: Connection reset by peer]
<whitequark>
sure
<whitequark>
I wasn't doing that on purpose
kmehall has joined #m-labs
<whitequark>
so... three messages: still works
<whitequark>
four messages: core hangs
<whitequark>
five messages: no output
<whitequark>
ok that wasn't related to underflows
<whitequark>
it's just broken with long sequences period
<sb0>
okay, can you put the exact sdram words from a broken long sequence into the test bench?
<whitequark>
well, I need to write a non-broken pack for that...
<sb0>
broken pack?
<whitequark>
the pack function in the testbench.
<sb0>
no, you bypass it entirely
<sb0>
the output of that pack function is sdram words
<whitequark>
I don't have any SDRAM words.
<whitequark>
I have a sequence of bytes.
<whitequark>
also it doesn't matter, I found the bug already
<whitequark>
it's in the software hack I use
rohitksingh_work has joined #m-labs
<whitequark>
sb0: after fixing hax I can confirm that long sequences work
<whitequark>
this one I tested spans five SDRAM words
<whitequark>
sb0: ok, so once the first engine run finishes (presumably successfully because it returns) trying to run it the second time results in a hang
<sb0>
whitequark, can you modify the testbench so it runs the dma core twice?
<whitequark>
sb0: it already does that though
<whitequark>
oh, hm, it doesn't
<whitequark>
I wonder why test writes are duplicated then
<whitequark>
oh, no, I misread, it does after all
<sb0>
whitequark, ah, yes. it does. from the same base address though
<sb0>
does the gateware work when you run the dma core twice without touching any other register than enable?
rohitksingh_wor1 has joined #m-labs
rohitksingh_work has quit [Ping timeout: 260 seconds]
<whitequark>
let's see
<whitequark>
sb0: yes, it does, or rather it results in a sequence error
<whitequark>
sb0: and if I fudge the timestamp between runs, it just works
<whitequark>
timestamp offset*
<sb0>
well, of course you have to fudge the timestamp between runs
<sb0>
okay, this narrows down the bug quite a bit. can you reproduce the broken behavior in the testbench?
<whitequark>
um, not really
<whitequark>
seems like the brokenness is in the "arbiter"
<whitequark>
(which isn't properly tested anyway)
<sb0>
ok, if you don't touch the arbiter (keep it on DMA for the whole lifetime of the runtime), does it work?
<whitequark>
interestingly, no
<whitequark>
it still hangs somewhere
<sb0>
also I don't think arbiter failure could block DMA, it would just write into nothing
<whitequark>
sb0: correction
<whitequark>
it works most of the time.
<whitequark>
and sometimes it hangs.
<whitequark>
seems to hang on `while csr::rtio_dma::enable_read() != 0 {}`
<sb0>
has it put something in the analyzer?
<sb0>
maybe you can add a timeout on that (which will have to be removed in the final version, since there are legitimate reasons for this to take a long time)
<whitequark>
no, nothing
<whitequark>
and what's the point of a timeout?
<whitequark>
the core is unusable afterwards anyway
<sb0>
ah right, you can still get an analyzer dump from the comms cpu
<sb0>
add CSRs into the DMA core to show the state of the FSMs, see where it blocks
<whitequark>
ok
<sb0>
my guess is that the "eop" marker is not properly transferred across the different stages under certain conditions
<sb0>
whitequark, do you understand now why I was opposed to gateware DMA buffer writing? =]
<whitequark>
sb0: well, you have a point here
<sb0>
with people talking about "PI controller kernels" it sounds like we should support multiple kernel (on their own CPUs, I guess) at some point...
<sb0>
allocating/arbitrating rtio channels will be a bit tricky
<sb0>
ffs 9-week lead time on flyback ferrite cores. those things are definitely not easier to work with than regular analog parts (resistors, caps, etc.) but unlike the latter you don't have sample kits readily available
<whitequark>
well, you could avoid flyback...
<sb0>
there are no decent 450V DC-DC converter modules
<whitequark>
no, I mean, the topology
<whitequark>
there are *lots* of isolating topologies
<sb0>
are other transformer cores any better?
<whitequark>
yes, non-gapped cores are plentiful in stock
<whitequark>
try a half-bridge topology
<sb0>
the one that is not stocked is the smaller one. I can also use an oversized core there, those lousy lead times are a good argument for doing that
<whitequark>
or a push-pull, depending on what's more convenient
<sb0>
they also stock the small one with a different airgap size
<sb0>
bah I'll just order the ungapped ones as well, so I can assemble something that works in any case
<whitequark>
get two
<whitequark>
vendors are notoriously opaque on whether they sell you a set or a half
<whitequark>
I was burned a few times on that, since then I only order an even number.
<sb0>
datasheet says "The AL value in the table applies to a core set comprising one ungapped core (dimension g = 0) and one gapped core (dimension g > 0)"
<sb0>
so it sounds like I need to order two different P/N
<whitequark>
they sell RM cores in pairs but E cores in halves
<whitequark>
sb0: btw do you have any contact at TI?
<whitequark>
if yes, can you harass them about releasing SVD files for TM4C129?
<sb0>
what is that? xml description of registers?
<whitequark>
yes
<whitequark>
they did it for older series, and there are a few requests for 129 on E2E, but no release
<sb0>
I don't know anyone at TI
<sb0>
parse the C header files?
<whitequark>
they're very restrictively licensed, for one
<whitequark>
it's probably easier to parse the *PDF* files
<sb0>
do we need that many registers?
<whitequark>
well, I wrote such definitions by hand in the past and I am very unhappy about that sort of workflow
<whitequark>
it's error-prone, and it makes it hard to experiment with various modes of peripherals or such
<whitequark>
I'm actually not joking about the PDF files
<whitequark>
the table structure is fairly regular, it ought to be possible to automate extraction somehow
<sb0>
oh fuck, digikey don't have the *yokes*
<sb0>
sigh
<whitequark>
farnell?
<whitequark>
also what's a yoke?
<whitequark>
do you mean clips?
<sb0>
well I suppose I can pay 125 HKD shipping from mouser for 10 HKD of yokes
<sb0>
yes, the clips
<sb0>
ah, yes element14 has them
<sb0>
and no delivery charge
<sb0>
element14 don't seem to have any of the cores
<whitequark>
that is very odd.
<whitequark>
I really doubt they have clips but not cores
<sb0>
and digikey has everything but the clips
<sb0>
ah, they have a few cores. but not the ones I want
<sb0>
oh wonderful, registering on digikey cleared my entire shopping cart
<sb0>
it's like they're having a competition with RS for the most shitty online shopping website
hartytp has joined #m-labs
<hartytp>
sb0, I have a few follow-up questions about the quote you sent me. Would you prefer to talk here or via email?
<sb0>
for technical stuff, ask here
<hartytp>
okay
<hartytp>
so, firstly, your point about moninj
<hartytp>
that's fine by me
<hartytp>
...
<sb0>
hartytp, ok
<hartytp>
I mainly included it because of rjo's post on #153
<hartytp>
"do [PI loops] with moninj from the host, completely without kernels."
<hartytp>
but, I guess this doesn't work anyway, since moninj isn't supported for the DDS/DAC
<sb0>
hartytp, yes. injection could be solved for the DAC using the same "continuous sampling" trick, though
rohitksingh_wor1 has quit [Ping timeout: 268 seconds]
rohitksingh_work has joined #m-labs
<hartytp>
(more accurately, AFAICT, moninj is currently only supported for monitoring of DDS/DAC, not for override, so a kernel is needed somewhere at the moment)
<hartytp>
okay
<hartytp>
sorry, I'm not up to speed on this, what do you mean by injection by "continuous sampling"?
<rjo>
hartytp: there would be a backing buffer for ADC and DAC and a continuous transfer mechanism between the buffer and the DAC/ADC. I.e. all channels get the same share of the bandwidth. Then you can do mininj on the buffer.
<rjo>
but that negates all flexibility in choosing sampling rates on a per channel basis. and doing bursts.
<rjo>
or fine timed/triggered acquisition/setting.
<hartytp>
okay
<hartytp>
that also seems a bit messy to interleave with RTIO
<hartytp>
so presumably one would have to choose between RTIO and continuous sampling modes, right?
<sb0>
no, RTIO would write to the buffer
<sb0>
there is no problem except that the timing gets coarser
<hartytp>
ack
<rjo>
yes. this will lead to fluctuating delay between the RTIO event and the actual output changing (and analogous for sampling). also you'd have to choose that mode on a per-SPI bus basis.
<hartytp>
thanks for clarifying that all.
<hartytp>
next
<rjo>
np.
<hartytp>
the quote doesn't mention anything about timings
<hartytp>
that's fine by me
<hartytp>
but, to check, the expectation is that we'll end up with something that is close to limited by the DAC's SPI bandwidth
<sb0>
for the DAC with DMA yes
<hartytp>
taking into account limitations due to RTIO frequencies etc.
<sb0>
without DMA, it's unclear
<sb0>
and for the ADC, probably not
<hartytp>
because of the ~us DRTIO overhead?
<sb0>
various overheads: DRTIO stack, cpu/gateware communication, sample processing
<sb0>
writing the right spi registers over drtio
<hartytp>
fine, but as discussed previously, the expectation for the ADC would be that we can access a sample from a kernel within a few us
<hartytp>
?
<rjo>
hartytp: from what i can see now yes.
<rjo>
would you like a proper breakdown of the contributions and an estimate in the quote?
<hartytp>
good ("best effort" on this is fine, so long as that's the aim)
<hartytp>
No, I don't need this on the quote, I just want to check we have the same expectations and that there aren't any obvious major issues that I'm not aware of
<hartytp>
Re the ADC itself: the quote mentions "similar to the ADA3022", reflecting our initial discussions
<hartytp>
but, there are a few things I don't particularly like about that chip
<rjo>
ok. i'd think that the biggest contribs are (1) SPI comms, (2) kernel/rtio reading. for your application also the ADC sampling time and the sample math starting from an integer would matter.
<hartytp>
(the gain ranges aren't ideal for some of our applications, the inputs aren't properly differential, etc.)
<hartytp>
rjo: that's what I expected. So long as the sum of all of that is of order a few us, I'm happy
<rjo>
from out perspective they are all quite similar. it would be different if there were external PGIAs to be handled as well.
<hartytp>
rjo: well, that's what I was wondering.
<hartytp>
Ideally, I was considering using the same front end as Alaki
<rjo>
hartytp: then you'd want some SPI addressable register to drive the PGIA settings. otherwise there won't be I/O
<hartytp>
well, it doesn't need to be real time, so I2C would also be fine
<hartytp>
but yes, something would be needed...
<hartytp>
I figured that we can use the same I2C as the 3U_BNC, so most of the code can be reused?
<rjo>
hartytp: re timing: yep. our goal could be roughly 1µs SPI, 2µs kernel-RTIO, 1µs ADC sampling, ~2µs sample math.
<hartytp>
re timing: good! That's what I'm after
<rjo>
hartytp: is the 3U_BNC doing I2C controlled direction switches?
<rjo>
but there are a few things that we might be missing. on the timing. e.g. having to trigger the sampling with another SPI write etc. all depends on the operation mode and the chip.
<rjo>
3U_BNC directions are readout only.
<hartytp>
sorry, yes, I'd misread the schematic
<hartytp>
rjo: "but there are a few things that we might be missing. on the timing. e.g. having to trigger the sampling with another SPI write etc. all depends on the operation mode and the chip."
<hartytp>
IMO, it's fine if the ADC reads junk for a sample or two after a gain switch -- this isn't something that the user is expected to do often
<rjo>
hartytp: ack. that was a comment about the "timing goal" for the discussion above. not about gain switching.
<hartytp>
If I2C/SPI control of PGIAs is a major pain for you, we can probably live with jumpers/dip switches
<rjo>
hartytp: no. i think having jumpers there is a bad idea for usability. i'd go for programmable pgias if the all-in-one ADC is no good. let's figure out the way to best implement it.
<hartytp>
re timings: aah, sorry. Understood. That's all fine.
<hartytp>
re PGIAs: okay. Do you think you'd be happy implementing that given the price you quoted?
<rjo>
one big thing is that I2C bus. we don't have a full picture yet what we want and need to use that for. right now there are a bunch of temperature sensors, all kinds of si5324-like clocking things, expanders, eeproms on there. so far that looks fine. we'd probably do handle the on startup once....
<rjo>
for your pgias: depends on the details.
<rjo>
SPI or I2C? are there hard special µCs to do the programming?
<hartytp>
I haven't given that much thought yet and, to be honest, I don't really know the market for this kind of thing
<hartytp>
So, for that kind of detail, I'd like to take advice from you or Greg
<hartytp>
I'd be happy to add an extra IC onto the DAC SPI bus to do this if that's easiest
<rjo>
yeah. i think we need to figure out whether we want to do this on the I2C bus or on the SPI bus (shared with the ADC/DACs).
<rjo>
sb0: ?
<rjo>
will we expose an I2C tree on some remote satellite through DRTIO/AUX to the kernel? what if that same bus drives the satellite's si5324 and e.g. Novogorny/Zotino GPIO expanders for PGIA gains.
<hartytp>
Anything like that is fine as far as I'm concerned.
<sb0>
rjo, there is no funding for that, but there is no technical issue about that
<sb0>
same for the remote SPI for the DACs
<hartytp>
Also, I haven't had a thorough look at the market for all-in-one DAQ ICs, so it's possible that there is something like the ADA3022 that would meet our needs without the need for separate PGIAs. That's something that I'll get WUT to look into once work starts on this.
<hartytp>
I just want to flag up that external PGIAs is something that we are considering as a backup plan if we don't find a more convenient alternative
<hartytp>
But, obviously, I see that it puts you in a tough spot being asked to quote support for vapourware
<rjo>
sb0: you mean remote SPI for the JESD DACs? right. same problem.
<rjo>
hartytp: ok.
<rjo>
i am undecided what would be better: diving into that x-level-deep I2C tree that Greg and Joe have been growing and trying to get stuff done there or implementing proper mechanisms to configure that stuff over SPI.
<rjo>
at least there are IO expanders that look similar from both SPI and I2C, e.g. PCA9502
<hartytp>
for the ADC PGIAs: assuming we pick a sensible way of doing this, taking advice from you and avoiding feature-creep, will you be happy supporting it as part work you quoted for?
<rjo>
hartytp: i'd be inclined to say yes. let's assume that from the programming side there are two spi devices on the bus, the ADC and e.g. a MAX7301 28 channel IO expander to drive pgias, termination resistors, ac/dc coupling.
<rjo>
sb0: concur?
nurelin has quit [Read error: Connection reset by peer]
<hartytp>
well, that covers my questions.
<hartytp>
Let me know if you want to make any changes to the quote as a result of this conversation, otherwise I'll place the order
<hartytp>
oh, one other thing: sb0, you mentioned scalable moninj support
<hartytp>
roughly, what would the cost be for that?
<hartytp>
Unfortunately, I suspect it's not something we're going to be able to support at the moment. But, if it's cheap enough, we could consider it
hartytp has quit [Quit: Page closed]
rohitksingh_work has quit [Read error: Connection reset by peer]
ysionnea1 is now known as ysionneau
<sb0>
rjo, yes, SPI for the JESD DACs
<sb0>
rjo, if we're never going to do continuous sampling, then two devices on the SPI bus is fine
<sb0>
otherwise I2C, or another SPI, is preferrable
<sb0>
we can always interrupt continuous sampling to make other transactions, but it makes the gateware messy
<sb0>
so this should be avoided if possible
rohitksingh has joined #m-labs
<rjo>
sb0: there would need to be a way to stop continuous sampling anyway. already to configure the adc. so that same mode/pause feature would be used to jiggle the gpios.
<sb0>
also that continuous sampling should be syncd to the RTIO TSC
<sb0>
so that we can say, e.g. a sample happens every time the TSC is divisible by 8
<sb0>
so that kernels can sample without jitter by tweaking their start time
<sb0>
anyway. do we need continuous sampling at all?
AndChat326081 has quit [Ping timeout: 240 seconds]
AndChat326081 has joined #m-labs
hartytp has joined #m-labs
<hartytp>
sb0: I don't see any use for it currently
<hartytp>
we tend to have two use cases:
<hartytp>
1. Sampling laser powers etc. Here, we are generally only sampling a small number (often 1) of ADC channels, and the acquisition needs to be synchronised with other RTIO evens (e.g. turning lasers on).
<hartytp>
2. Background logging/monitoring of multiple channels at <~1SPS
<hartytp>
This could be done with continuous sampling, but it might be easier to implement with a kernel in an idle experiment...
<hartytp>
For the second case, I am also tempted to make a Beaglebone cape with a few extension module headers on.
hartytp has quit [Quit: Page closed]
<rjo>
sb0: the use cases for continuous sampling would be SAWG-like automatic sample generation, acquisition, and moninj.
rohitksingh has quit [Read error: Connection reset by peer]
nurelin has joined #m-labs
kyak has quit []
kyak has joined #m-labs
kyak has joined #m-labs
mumptai has joined #m-labs
mumptai has quit [Quit: Verlassend]
AndChat|326081 has joined #m-labs
AndChat326081 has quit [Ping timeout: 258 seconds]