UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Visitor nbstrike
Visitor
416 Views
Registered: ‎07-20-2018

pipelining ap_memory interface accesses

Is it possible to initiate multiple, pipe-lined memory accesses to an array using an ap_memory interface type? I don't seem to be able to achieve that outcome with code like this (where I'm hoping to have a throughput of one lookup per cycle):

void ram_access(hls::stream<ap_uint<8> >& addr,
                ap_uint<8> table[256],
                hls::stream<ap_uint<8> >& res)
{
#pragma HLS PIPELINE II=1 enable_flush

#pragma HLS INTERFACE ap_memory port=table latency=3
#pragma HLS RESOURCE variable=table core=RAM_1P

#pragma HLS interface ap_fifo port=addr
#pragma HLS interface ap_fifo port=res

	ap_uint<8> offset;

	if (addr.read_nb(offset)) {
		const auto x = table[offset];
		res.write(x);
	}
}

Perhaps I'm trying to approach this the wrong way? Is there a better way to achieve this?

Also, rather curiously, going by ug902 "Arrays on the Interface" I was under the impression that the 'latency=3' parameter should be on the resource line (not the interface line) but this seemed to expect a result from the array on the next cycle.

Many thanks.

0 Kudos
2 Replies
Xilinx Employee
Xilinx Employee
332 Views
Registered: ‎09-05-2018

Re: pipelining ap_memory interface accesses

@nbstrike

What interval do you get from the Vivado HLS Synthesis Report?

Because you have II=1, I think anything other than an interval of 1 should give you an error in the console. That might offer a clue.

Nicholas Moellers

Xilinx Worldwide Technical Support
0 Kudos
Visitor nbstrike
Visitor
297 Views
Registered: ‎07-20-2018

Re: pipelining ap_memory interface accesses

Hi @nmoeller -- thanks for looking at this, these are the latency & interval figures I get:

+ Latency (clock cycles): 
    * Summary: 
    +-----+-----+-----+-----+----------+
    |  Latency  |  Interval | Pipeline |
    | min | max | min | max |   Type   |
    +-----+-----+-----+-----+----------+
    |    3|    3|    1|    1| function |
    +-----+-----+-----+-----+----------+

I'm realising that I simply have a fundamental mis-understanding of the way that HLS works; especially when a function like this is called from a dataflow region I keep imagining that it will keep running autonomously and continually as often as it can (ie as if it were a regular HDL module) -- this is of course wrong, it is simply a C function and must act as if it was one thus if called once from the top level function it should only execute once, and it is not possible to overlap multiple executions of a single function.

Given that I'm writing packet processing codes in the manner of XAPP 1209 processing an input per cycle from a stream, is there a clean way to handle slow memory accesses like this? or is my best bet to stream requests and responses to an external verilog module to handle? [which would seem to rather spoil the benefits of HLS]

Many thanks,

Nick

0 Kudos