EmbDev.net

Forum: FPGA, VHDL & Verilog Not a homework question, I am 58 1/2!


von Julian M. (Company: Relevant Technologies Ltd) (geoffreym)


Rate this post
useful
not useful
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
von Svenska (Guest)


Rate this post
useful
not useful
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
No account? Register here.