Hi Everyone I am using the ARM AXI4 stream data interface to create blocks as part of a telemetry data tranceiver. Being a complete newbie (software background), I am making a total meal of this. I need to know if there is a generic solution to receiving data, processing it with arbritrary latency (BRAM access, pipelined calculations, that sort of thing), and transmitting the result of the processing. The whole thing must be stallable at both ends, obviously. My best approach to date has been to separate the input and output processes, using a ping-pong buffer in BRAM. I get the feeling this is the trademark of a kindergarten amateur (it has a latency of one block, for instance) and would like to know a better way. The stream interface is as simple as can be, Tx valid and Rx ready signifying a transfer has been executed, Tx valid being obliged by the protocol to remain asserted until Rx Ready acknowledges. In general, an output needs a number of input words for its construction, and its calculation may additionally need to be pipelined. There must be some pretty obvious way of stalling the input bus when the output bus is unavailable, but nothing comes to mind which enables me to separate the processing of input data from the generation of output data. I want to be able to get on with receiving and crunching as much input data as is needed to generate the next output while waiting for the output bus to accept the last requested transfer. Rx ready is allowed to be a random value, with no protocol constraints save that if it asserted simultaneously with Tx Ready the acceptance of data is implied. This must be a basic technique, and would seem to lend itself to reuseable code. Anybody know of a good book? Best regards Geoff Saluti, Best regards Geoff
:
Edited by User
Your approach doesn't sound like a stupid idea. What about using a dual-ported BRAM as a FIFO, with dedicated input and output ports? Your input process constantly writes into the BRAM (until the buffer is full, at which point it stalls), and your output process constantly reads from the BRAM (until the buffer is empty, at which point it stalls).
Please log in before posting. Registration is free and takes only a minute.
Existing account
Do you have a Google/GoogleMail account? No registration required!
Log in with Google account
Log in with Google account
No account? Register here.