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: 
Observer rakesh_bansal
Observer
2,965 Views
Registered: ‎06-14-2017

Delaying an internal signal in virtex ultrascale+

Jump to solution

Hi,

 

I'm using an RTL where a certain signal is delayed by 2ps using following module:

 

module delay(

input in,

output out

);

 

assign out = in #2ps;

 

endmodule

 

Pardon my syntax errors, if there are any. Using this module in RTL any signal can be delayed by 2ps.

 

Now above signal delay cannot be synthesized and hence i need workaround to realize the same delay on fpga.

One approach is to feed the signal to FF, which is running off fastest clock of RTL, but that will give delay of one clock cycle (~20ns), which is what i'm not looking for.

 

I was wondering if virtex ultrascale+ family has some BUF through which i can achieve it? I looked into utrascale library too. But there are only IBUF (used for input pad) or OBUF(used for output pad). Also, i'm not looking to use BUFG for it(only last resort).

 

Is there any other way or some other library cell which i missed? Help!

 

Thanks,

Rakesh

0 Kudos
1 Solution

Accepted Solutions
Highlighted
Historian
Historian
5,392 Views
Registered: ‎01-23-2009

Re: Delaying an internal signal in virtex ultrascale+

Jump to solution

But It is actually first getting sync to the clk before it's getting used to FF.

 

I don't know what this can mean. How do you synchronize a sub-clock period pulse to a clock? Clearly it can't be done "conventionally" by putting the pulse into the D input of two back to back flip-flops (the pulse is too short).

 

Some "short pulse" extender circuits use the pulse as a CLK or asynchronous preset/clear input to the flip-flop - both of which are asynchronous design practices that are seriously discouraged in FPGAs (or modern ASICs for that matter).

 

Logic equation of above mentioned circuit was = sig & (~sig_dly)

 

This is not an AND gate, it is an AND gate with one input inverted. This is the proper syntax for a pulse detector. The LUT will end up implementing this.

 

But even if the tool does not optimize this out (the synplify option is probably a DONT_TOUCH or KEEP), this will generate potentially tiny pulse - less than 1ns. There are asynchronous techniques to work with this but DO NOT USE THEM.

 

Again - throw this code away. It is BAD BAD BAD code. Do not spend time trying to make it work - find a way to do what needs to be done using proper synchronous design techniques.

 

Avrum

0 Kudos
7 Replies
Explorer
Explorer
2,961 Views
Registered: ‎04-12-2017

Re: Delaying an internal signal in virtex ultrascale+

Jump to solution

I don't think you can achieve nothing near to 2ps. However, you can try to create two out-of-phase clocks using an internal MMCM. The minimum phase difference you achieve with the MMCM will be the delay you can achieve.

Avi Chami MSc
FPGA Site
0 Kudos
Historian
Historian
2,956 Views
Registered: ‎01-23-2009

Re: Delaying an internal signal in virtex ultrascale+

Jump to solution

Rakesh,

 

You cannot do what you are asking for. Furthermore, the whole question is somewhat meaningless...

 

In an FPGA, signals are delayed at every point - both in the LUTs and in the interconnects. These delays are

  - much longer than 2ps

  - variable over a wide range (substantially larger than 2ps)

  - are irrelevant to the functionality of an FPGA as long as the delays on a path satisfy the setup/hold requirement on the path

 

So the idea of adding 2ps of delay to an internal signal is meaningless...

 

Why do you think you need something like this?

 

Avrum

0 Kudos
Observer rakesh_bansal
Observer
2,944 Views
Registered: ‎06-14-2017

Re: Delaying an internal signal in virtex ultrascale+

Jump to solution

Hi Avrum,

 

Looks like i missed the very trivial info about PnR.

You are right in your comments.

Let me just have a look at RTL and see for what they really needed for.

 

Thanks,

Rakesh

 

0 Kudos
Observer rakesh_bansal
Observer
2,889 Views
Registered: ‎06-14-2017

Re: Delaying an internal signal in virtex ultrascale+

Jump to solution

Hi Avrum,

 

I just checked RTL and found one example where it's getting used as 'async_clr' signal as a pulse to design (FF) as following :

 

aync_clr <= ((sig xor sig_dly) and sig);

 

At other places the delay signal may have different combinational circuit to realize other functionality, that's why 'sig' and 'sig_dly' are put in a module to use it different places in design.

 

Regards,

Rakesh

0 Kudos
Historian
Historian
2,831 Views
Registered: ‎01-23-2009

Re: Delaying an internal signal in virtex ultrascale+

Jump to solution

I can't stress enough how much you do NOT want to do things like this.

 

This is the epitome of bad asynchronous design practices - a combinatorially pulsed locally generated asynchronous preset/clear.

 

First, it is impossible to generate the delay with a delayed assignment (like you currently have) - the # is completely ignored by synthesis, so your module will reduce to a wire from it's input to its output (which actually has no delay - or at least no more than it would have had for a net going from the driver of the input to the receiver of the output).

 

In very old asynchronous ASIC and board design practices, a delay like this could be done by putting a buffer or a pair of inverters  on a signal to create combinatorial delay, but that only worked when you had more or less direct control over the routing of signals, and the cell delays were significantly larger than the routing delays. Neither of these are true in an FPGA (routing delays outweigh cell delays, and you have very little to no control over routing).

 

Next, the synthesis tool will remove any logic it determines to be Boolean redundant. So anything of the form A & !A (even if !A is "delayed") will be removed. Putting it in it's own module with flatten_hierarchy set to none may be able to preserve the redundant logic (as will a KEEP attribute), but this is very error prone.

 

Finally, the use of any locally generated asynchronous reset (forget about a combinatorially derived pulse) is highly discouraged in the FPGA. No combinatorial FPGA logic is guaranteed to be glitch free, so there is no way to ensure that the reset won't glitch active when it shouldn't. This is aside from the fact that this creates horrible timing paths for the tool to optimize (and you to debug).

 

All in all remove this code from your design. Find a way to do what needs to be done with pure synchronous design practices!

 

Avrum

0 Kudos
Observer rakesh_bansal
Observer
2,821 Views
Registered: ‎06-14-2017

Re: Delaying an internal signal in virtex ultrascale+

Jump to solution

Hi Avrumw,

 

I couldn't agree more to the explanation you gave and as i already mentioned that #delays cannot be synthesized, that's why i wanted to modify that module.

 

But probably in my last post it's like i went with the name of signal and assumed things (that this signal is really asynchronously clr to FF).

But It is actually first getting sync to the clk before it's getting used to FF.

 

Logic equation of above mentioned circuit was = sig & (~sig_dly)

 

I tried realizing above delay by instantiating LUT1 as inverter (using INIT property) and output of LUT1 connected to another inverter. Synthesis output of synplify optimized the circuit such that output of inverter (on 'sig' path) got ANDed with orig 'sig' (even after enabling optimizing circuit option).  something like following:

 

sig->inv->sig_dly

 

And sig_dly got ANDed with orig sig.

 

Could confirm that in tech view of netlist. Sorry, but i couldn't find (to disable or enable) flatten_hierarchy option in synplify_premier.

 

When i imported (.edf from synplify) it to Vivado tool for PnR, there also schematic showed LUT1 (inverter).

Next when i did implementation, it optimized the inverter and changed the simple AND gate (O= in1 & in2) to O' = in1 & !in2 :(

 

And i'm assuming that this kind of AND gate (O') is not good for pulse.

 

One final thing, knowing that pulse will get synced before it is used to FF, is there a reliable way to generate that small pulse (~1ns)? (Yes in original post i mentioned 2ps, but i will be able to live with even with 1-2ns pulse).

 

Best Regards,

Rakesh

 

0 Kudos
Highlighted
Historian
Historian
5,393 Views
Registered: ‎01-23-2009

Re: Delaying an internal signal in virtex ultrascale+

Jump to solution

But It is actually first getting sync to the clk before it's getting used to FF.

 

I don't know what this can mean. How do you synchronize a sub-clock period pulse to a clock? Clearly it can't be done "conventionally" by putting the pulse into the D input of two back to back flip-flops (the pulse is too short).

 

Some "short pulse" extender circuits use the pulse as a CLK or asynchronous preset/clear input to the flip-flop - both of which are asynchronous design practices that are seriously discouraged in FPGAs (or modern ASICs for that matter).

 

Logic equation of above mentioned circuit was = sig & (~sig_dly)

 

This is not an AND gate, it is an AND gate with one input inverted. This is the proper syntax for a pulse detector. The LUT will end up implementing this.

 

But even if the tool does not optimize this out (the synplify option is probably a DONT_TOUCH or KEEP), this will generate potentially tiny pulse - less than 1ns. There are asynchronous techniques to work with this but DO NOT USE THEM.

 

Again - throw this code away. It is BAD BAD BAD code. Do not spend time trying to make it work - find a way to do what needs to be done using proper synchronous design techniques.

 

Avrum

0 Kudos