Meeting timing constraints

Questions and discussions about the Xillybus IP core and drivers

Meeting timing constraints

Postby Guest » Tue Jul 05, 2016 7:43 pm

Hi,

I have an issue that's been causing me some grief for a few days. I'm hoping someone might have some helpful advice.

I cannot generate a correct bitstream in my project because I have not found a way to handle the timing issues.

Basically, I am sending data to an inferred RAM using the xillybus mem interface. I do not allow one particular register to be written:

Code: Select all
if (user_w_mem_8_wren && user_mem_8_addr != 19) begin
     array[user_mem_8_addr] <= user_w_mem_8_data;   
   end


Instead this register is updated at each clock cycle (that Read_Enable is not asserted) with the output of a combinational circuit.

Code: Select all
if(!user_r_mem_8_rden) begin
              array[19] <= result;
          end


Both the above snippets are contained within an always @(posedge bus_clk)

The combinational circuit accepts the other 19 registers as inputs. I want to read the result stored in the 20th array entry back to host. I do not care that the wrong answer will be clocked many times. I will ensure an appropriate delay in the host app.

So my problem is that this does not meet the timing requirements. Do you know what I must do in order to make this idea valid?

Thank you.
Guest
 

Re: Meeting timing constraints

Postby support » Tue Jul 05, 2016 8:02 pm

Hello,

It looks a bit like you're trying to adopt C programming techniques in Verilog. The synthesizer probably ended up with something less than optimal. You need to feed it with a spoon, otherwise it messes up.

An array in Verilog is considered a hint to produce a memory. What you actually wanted was many registers. Maybe the synthesizer produced those registers, given that all element in the array are accessed by combinatoric logic simultaneously. So maybe this turned out OK, after all.

But if you produced some logic function, based upon 18 pieces of data, and made the "result" signal out of that, and all this using combinatoric dependencies only (no registers in the middle), no wonder you failed timing. You need to pipeline a bit. This issue is beyond the scope of this forum, and I suggest getting help possibly in Xilinx'. But to make a long story short: You need to get some intermediate registers in the middle.

As for your use of Xillybus, it would have been more logic-style to have the FPGA accept 18 elements through a regular (non-address) stream, and then emit the result to another stream in the other direction, once the result is ready. But that's a matter of style and needs.

Regards,
Eli
support
 
Posts: 590
Joined: Tue Apr 24, 2012 3:46 pm

Re: Meeting timing constraints

Postby Guest » Tue Jul 05, 2016 8:44 pm

Hi Eli,

Thanks for the timely response.

So I chose the memory interface just because it felt more intuitive to me than the FIFO approach, but I can see form these timing issues that may have been a mistake.

Anyway, when I examine the schematic I feel as though the vivado synthesizer creates pretty much what I intended.

I apologize if this is not a Xillybus specific question. I thought that it was because I was under the impression that the core was somehow aware of the propagation delay through the combinational part and didn't want to read a register that might hold the "wrong answer."

I will try clocking the output of the combinational part into a reg of it's own before clocking into the 20th array_reg.

I was also looking into using the _empty signal discussed in the FPGA design guide. Do you think it may be possible that if _empty is asserted while the combinational part is propagating changes then it might accept the timing? I'm sorry I'm just confused as to why the Xillybus core cares from where and when the register is filled as long as it isn't read and written on the same cycle.

Thank you very much.
Guest
 

Re: Meeting timing constraints

Postby Guest » Tue Jul 05, 2016 10:46 pm

Hi again,

You're reply pointed me towards the realization of what is really going on here. Many of my assumptions were off. The elaborated design is what I intended but the synthesized design is very messy and very difficult to read. It appears as though what I believed to be a memory-like collection of 20 registers is really a bunch of registers with a bit more complexity than I thought, and clearly some errors too. I see that it really isn't a Xillybus thing that the timing is not working out. I am betting you're advice to utilize the FIFO approach to receive output is an efficient path towards overcoming this issue.

Thanks
Guest
 

Re: Meeting timing constraints

Postby support » Wed Jul 06, 2016 6:59 am

Hello,

The synthesized design is always messy, so don't let that put you off. But working with an FPGA requires having the underlying logic in mind all the time: How is this or that going to be implemented, more or less, and what impact will it have on the propagation between registers? After all, the Verilog will end up to be lookup tables, flip-flops and other quite simple logic elements.

If you like to google a bit on this topic, "timing closure" and "pipelining" are probably good to start with.

Regards,
Eli
support
 
Posts: 590
Joined: Tue Apr 24, 2012 3:46 pm


Return to Xillybus

cron