Andrew Zonenberg
FPGA/ASIC people: when you have a complex state machine fetching data from a memory with unpredictable latency (e.g. AXI bus that may have contention, or external DRAM) how do you figure out what to do when the data comes in?
For my application there's no reordering possible within a single stream of requests so I'm thinking of having a FIFO of context objects that will "jog my memory" so that once data comes back, I know why it was read and how to handle it.
✧✦Catherine✦✧
@azonenberg yep that's what I am generally using
✧✦Catherine✦✧
@azonenberg that's exactly how i designed the glasgow (in future, amaranth-stdio, probably) I/O core. you give it the data to put in the output IOB registers plus metadata, and some cycles later (depending on the platform and configuration), it gives you back metadata and input values
this makes it very easy to write things like high performance JTAG probes without worrying much about the implementation
all stream-based, like AXI4-Stream but in Amaranth
Andrew Zonenberg
@whitequark This almost feels like it's going to turn into a task-flow architecture.
Where instead of reading data then processing the response, you issue a read request attached to a context object and then wherever it shows up gets the data along with instructions on what to do with said data
✧✦Catherine✦✧
@azonenberg yeah that's exactly why I picked this design, SiliconBlue devices have 1 cycle of latency for DDR I/O and Lattice devices have 3 (also i think Xilinx does?). i don't want to be tied by design to one specific platform
Andrew Zonenberg
@whitequark As of now I have a native sram interface to the memory (xilinx UltraRAM) but the latency is variable due to both the potential for me to add arbitration in front of it, and because I will likely be adding and removing pipeline stages for timing closure as the design evolves.
So i don't want my read-side logic to make any assumptions about latency
Tube❄️Time
@azonenberg @whitequark i used this approach for a JTAG/I2C adapter. for efficiency, i packed a number of transfers into a single USB packet and needed a way to disburse all the received data and response codes. the API recorded the pointers, then you'd call a "flush" function that would generate the actual transfer and handle the results, after which the data at those pointers became valid.
✧✦Catherine✦✧
@tubetime @azonenberg this is exactly how my ARM7TDMI debugger works! it's a very effective approach
GNU social JP is a social network, courtesy of GNU social JP管理人. It runs on GNU social, version 2.0.2-dev, available under the GNU Affero General Public License.
All GNU social JP content and data are available under the Creative Commons Attribution 3.0 license.