Notices by Andrew Zonenberg (azonenberg@ioc.exchange)

@whitequark Better than the debug hell I went through in my thesis work.

I was using a gdbserver I wrote to debug firmware I wrote, compiled against a libc I wrote, running on a CPU I wrote, hooked up to an interconnect I wrote, on a board I designed, using a FTDI-based debug dongle I designed.

And something was going wrong somewhere in the stack and the firmware was locking up (not a full deadlock, instructions were still executing, but it was stuck in a polling loop or something and not making any forward progress). I trusted nothing and had no idea where in the stack things were going wrong.

And it was on a very full xc6slx25 that had enough spare gates to fit *either* JTAG debug support on the CPU *or* a homebrew ILA to sniff a few internal signals. But not both.

@whitequark @aleksorsist @urja Exactly what I was getting at. It's solvable, but not trivial.

You'll probably need multiple replicated copies of the logic and some speculation or replication to handle multiple cases in parallel then figure out what happened the next cycle or something.

@aleksorsist @whitequark @urja Lol.

A VLIW processor may actually end up being the logical implementation of this. Who knows.

But the more I think about it, the more I lean towards a two-part system with a bunch of parallel function blocks that output one or more bits every cycle (each block having a bunch of config registers to specify muxing and thresholds and such), then a serial state machine operating on their output.

@aleksorsist @whitequark @urja What I don't know is what the cleanest programming model for an end user developing triggers for this is going to look like.

@aleksorsist @urja No, you're missing the point.

Because you're running on the output of the 8:1 serdes, your trigger logic is at 125 MHz. But the *input* can still toggle faster than that (remember the frontend BW is what. 300+ MHz?)

So you need to consider what happens if you have >1 toggle in that 8-bit stream of samples. You may need to advance more than one state in a single clock cycle.

@aleksorsist @urja My vision a while back was a series of series of edge detectors feeding into serial/parallel pattern matching blocks, then a state machine acting on the output.

So you could have it look for "falling edge on CH1" then "0x41 serially on CH2 data clocked by CH3 rising edge" then "0x20 serially on same pins", with a rising edge on CH1 or a mismatch of either byte clearing the state machine back to the start.

This would give you a SPI pattern match. I'm sure you can see the potential to implement I2C etc. on the same logic block.

@aleksorsist @urja but my vision is less of a CPU and more of a coarse grained dataflow architecture where you have different modules analyzing the data in parallel, then outputs that feed into some kind of decision block

@aleksorsist @urja Well that's the idea. you build the blocks then the microcode wires them together into a specific protocol.

@aleksorsist @urja Yeah. So what you want IMO is a series of always-enabled data processing blocks, then microcode/state machine that acts on their output.

So for example

HARDWARE BLOCK CONFIG
A) edge detect CH1
B) edge detect CH2
C) edge detect CH3
D) 8-bit shift register, clk=CH2 rising, data=CH3, reset=CH1 falling

STATES
1) on falling edge A: go to 2
2) on data available D: go to 3 if 0x41, else go to 1. On rising edge A, go to 1
3) on data available D: trigger if 0x42, else go to 1. On rising edge A, go to 1

@aleksorsist @urja When I say "clock" I mean in the digital domain.

You're doing everything in the ADC sample domain anyway, but you can emulate clocked logic by looking for a 0-1 transition on the clock input and gating the enable to the block on that

@aleksorsist @urja So maybe instead you have

state 3) wait 1ms, if A still low trigger, else go to 1

(to catch a SPI transaction that gets stuck and never terminates)

@aleksorsist @urja You can add support for fixed time delays as well as edge detection based timing. Different protocols (e.g. SPI vs UART) would work more naturally for one or the other.

They're all just event sources feeding into the state machine.

@aleksorsist @urja The other challenge will be how to handle higher speed serial-ish protocols that might change states quickly.

With 4-channel mode it's easy because you can run trigger logic at 250 MHz and have one set of updates per cycle.

But with 1-channel mode you can't clock the trigger logic at 1 GHz, so you have to consider what happens if you have more than one transition in the signal in a single clock cycle of the trigger state machine. This will only get worse as you transition to faster ADCs in the future and the number of ADC samples per FPGA clock grows.

I don't have all the answers, just pointing out design considerations.

@aleksorsist @urja Running completely based on sample counting won't work for any kind of firmware based DUT that has jitter in timing (e.g. bitbanged SPI bus that might have unpredictable frequency based on interrupts)

@whitequark I found ADIv5 easier to work with than EJTAG 3 but that may have been because it was several years down the road and I was more experienced with embedded bus architectures etc by that point

@whitequark @r I've only worked with EJTAG 3.10 on M4K cores.

Didn't fully implement everything but my recollection is I got to the point of being able to execute single instructions clocked in over JTAG and it worked

@r @whitequark have you looked at the PIC debug interface

@r @whitequark hell, even MIPS EJTAG is at least somewhat cursed

@whitequark debug random number generator

@whitequark Nice.

Have we ever talked about the horrible perversion of JTAG I implemented for debugging my thesis system? This kinda reminds me of it