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 gilg1
Visitor
2,441 Views
Registered: ‎12-18-2016

Memory latency issue

Hi,

I'm trying to synthesize c-code with Vivado HLS 2016.3 

I have memory I/F for read data from external RAM.

Due to timing issues, I need to sample both ce/address going to the RAM and data read from the RAM.

I'm using the following pragma:

#pragma HLS resource variable=array core=RAM_1P latency=3

 

However, from looking in simulation it seems that HLS allows sampling only the read data and not ce/address.

The memory testbench generated by HLS is:

 

always @(posedge clk)

 if (ce==1) 

  begin

   dout_delay1 <= mem[address];

   dout_delay2 <= dout_delay1;

   dout <= dout_delay2;

  end

 

Is there a way to tell HLS that the ce/address are also sampled and not only read data?

Thanks,

 

  Gil

 

 

 

0 Kudos
1 Reply
Scholar jprice
Scholar
2,418 Views
Registered: ‎01-28-2014

Re: Memory latency issue

I can tell you from experience that the address lines can be registered (I forget under what conditions but you should see it in the finalized design starting at 3 or 4 cycles of latency). I've seen both the address and write data/write enable lines use registers. This is only obvious after synthesis/place/route if I recall since the tools can infer equivalent behavior from the type of code you've shown below (I'm fuzzy on this since it's been over a year since I had to deal with it). However the 'CE' lines will never be pipelined and this is a systematic issue with HLS. Xilinx has confirmed there is currently no solution for it and was the bane of one of my designs. 2016.2 supposedly reduced the levels of logic on those nets but I never verified that myself (I was using 2015.4 at the time). I ended up slowing the clock a little and over optimizing other parts of the FPGA to get those lines to close timing. I would also run phys_opt_design with the aggressive explore directive 3 times. 

0 Kudos