Conversation

Notices

1. Embed this notice
   Aleksorsist (aleksorsist@fosstodon.org)'s status on Tuesday, 06-May-2025 05:45:57 JST Aleksorsist

   • Andrew Zonenberg

   @urja @azonenberg Yup! It would have edge modules, slope and delay timers. Basically you feed it code (a list of conditions really) and the PC increments every time a condition is met. Here's a napkin sketch:

   • Embed this notice
     Aleksorsist (aleksorsist@fosstodon.org)'s status on Tuesday, 06-May-2025 05:45:50 JST Aleksorsist

     in reply to

     • Andrew Zonenberg

     @azonenberg @urja it will never clock at 1 GHz because we'd be doing this on the output of the 8:1 serdes. Just need a very simple module to track where exactly the sample was and then spit it back out another 8:1 serdes to the trigger output (that way it should be a fixed 8 cycle delay plus hardware delays)

   • Embed this notice
     Andrew Zonenberg (azonenberg@ioc.exchange)'s status on Tuesday, 06-May-2025 05:45:51 JST Andrew Zonenberg

     in reply to

     @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)

   • Embed this notice
     Andrew Zonenberg (azonenberg@ioc.exchange)'s status on Tuesday, 06-May-2025 05:45:51 JST Andrew Zonenberg

     in reply to

     @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.

   • Embed this notice
     Andrew Zonenberg (azonenberg@ioc.exchange)'s status on Tuesday, 06-May-2025 05:45:52 JST Andrew Zonenberg

     in reply to

     @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.

   • Embed this notice
     Andrew Zonenberg (azonenberg@ioc.exchange)'s status on Tuesday, 06-May-2025 05:45:52 JST Andrew Zonenberg

     in reply to

     @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)

   • Embed this notice
     Aleksorsist (aleksorsist@fosstodon.org)'s status on Tuesday, 06-May-2025 05:45:53 JST Aleksorsist

     in reply to

     • Andrew Zonenberg

     @azonenberg @urja ah, you want to clock off the signals, gotya. I was thinking of basing everything off of counting samples so it'll work more generally for say, analog / power sequencing stuff

   • Embed this notice
     Andrew Zonenberg (azonenberg@ioc.exchange)'s status on Tuesday, 06-May-2025 05:45:53 JST Andrew Zonenberg

     in reply to

     @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

   • Embed this notice
     Aleksorsist (aleksorsist@fosstodon.org)'s status on Tuesday, 06-May-2025 05:45:54 JST Aleksorsist

     in reply to

     • Andrew Zonenberg

     @azonenberg @urja that's actually more what I'm thinking. Basically the modules are always looking at the data, it's just new parameters that get clocked in once the previous condition is met. I can't think of a trigger that doesn't need a sequential list of conditions (with commands across channels treated kinda like multi-threading)

   • Embed this notice
     Andrew Zonenberg (azonenberg@ioc.exchange)'s status on Tuesday, 06-May-2025 05:45:54 JST Andrew Zonenberg

     in reply to

     @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

   • Embed this notice
     Andrew Zonenberg (azonenberg@ioc.exchange)'s status on Tuesday, 06-May-2025 05:45:55 JST Andrew Zonenberg

     in reply to

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

   • Embed this notice
     Andrew Zonenberg (azonenberg@ioc.exchange)'s status on Tuesday, 06-May-2025 05:45:55 JST Andrew Zonenberg

     in reply to

     @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

   • Embed this notice
     Aleksorsist (aleksorsist@fosstodon.org)'s status on Tuesday, 06-May-2025 05:45:56 JST Aleksorsist

     in reply to

     • Andrew Zonenberg

     @azonenberg @urja I wouldn't want to hard code any protocols. I'm trying to find the core modules that everything is built on and make those into atomic instructions. Then a compiler can take the current state of the scope (i.e. what is an ADC code in volts, what's a sample in time units) as well as a description of the desired protocol, and spit these instructions out.

   • Embed this notice
     Andrew Zonenberg (azonenberg@ioc.exchange)'s status on Tuesday, 06-May-2025 05:45:57 JST Andrew Zonenberg

     in reply to

     @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.