cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Observer
Observer
3,634 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
Guide
Guide
6,061 Views
Registered: ‎01-23-2009

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

View solution in original post

0 Kudos
7 Replies
Highlighted
Explorer
Explorer
3,630 Views
Registered: ‎04-12-2017

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
Highlighted
Guide
Guide
3,625 Views
Registered: ‎01-23-2009

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
Highlighted
Observer
Observer
3,613 Views
Registered: ‎06-14-2017

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
Highlighted
Observer
Observer
3,558 Views
Registered: ‎06-14-2017

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
Highlighted
Guide
Guide
3,500 Views
Registered: ‎01-23-2009

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
Highlighted
Observer
Observer
3,490 Views
Registered: ‎06-14-2017

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
Guide
Guide
6,062 Views
Registered: ‎01-23-2009

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

View solution in original post

0 Kudos