n gate delay

[colin]

Hi,
I need a programable delay of n gates,
im not bothered about it being exact delay
as long as n+1 is just a little bit longer than n etc.

not too dificult to design with gate delays,
however it seems to optimise out any gates I try and put in
even on the schematic.

I cant find out how to use the dont_touch atribute on the schematic,
when I click on properties it says cant edit the atributes.

im using the xilinx ISE 9.2

thanks
Colin =^.^=

 

[Shannon]

Hi,
I need a programable delay of n gates,
im not bothered about it being exact delay
as long as n+1 is just a little bit longer than n etc.

not too dificult to design with gate delays,
however it seems to optimise out any gates I try and put in
even on the schematic.

I cant find out how to use the dont_touch atribute on the schematic,
when I click on properties it says cant edit the atributes.

im using the xilinx ISE 9.2

thanks
Colin =^.^=

Not sure I'm following what you are trying to do but if you just want
to delay a signal by adding a bunch of "gates" after it, yes they will
get optimized away.

I fear what you are doing is not good practice. It's a fairly
uncontrolled way of adding delay to a signal. If you can, give us
more information on what exactly you are trying to do and I'm sure we
can find a more rigorous method.

Shannon

 

[colin]

Not sure I'm following what you are trying to do but if you just want
to delay a signal by adding a bunch of "gates" after it, yes they will
get optimized away.

I fear what you are doing is not good practice. It's a fairly
uncontrolled way of adding delay to a signal. If you can, give us
more information on what exactly you are trying to do and I'm sure we
can find a more rigorous method.

its basicaly part of a numerically controlled oscillator loop,
as long as the increments are small and not less than zero it will be ok.

im probably not using these fpgas in anyway like you guys think your
supoposed to lol,
but at the end of the day heck they are just gates,
and ive done it with discretes before.

its for vernier time interval measurement.

Colin =^.^=

 

[Jonathan Bromley]

I need a programable delay of n gates,
im not bothered about it being exact delay
as long as n+1 is just a little bit longer than n etc.

I wonder if you could do it with an adder?
Build a regular adder, write 1111...1111
to the register that drives one input. Then
choose which of the other input's bits to
wiggle. The same wiggle should appear on the
adder's carry-out, but if the input you wiggle
is the LSB you'll get a longer carry delay
than if you wiggle the input MSB. Uses the
FPGA's carry chain as your vernier.

Don't hard-code A=B+"1111111", or else the
synth tool will do something clever with
another optimization. Make the "1111111"
something that you write-to dynamically,
even though it will always be all-ones.

Just a thought. Others with more FPGA-specific
expertise than I have may suggest clever stuff
with digital clock managers and the like.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
(e-mail address removed)
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

 

[colin]

I wonder if you could do it with an adder?
Build a regular adder, write 1111...1111
to the register that drives one input. Then
choose which of the other input's bits to
wiggle. The same wiggle should appear on the
adder's carry-out, but if the input you wiggle
is the LSB you'll get a longer carry delay
than if you wiggle the input MSB. Uses the
FPGA's carry chain as your vernier.

Don't hard-code A=B+"1111111", or else the
synth tool will do something clever with
another optimization. Make the "1111111"
something that you write-to dynamically,
even though it will always be all-ones.

Just a thought. Others with more FPGA-specific
expertise than I have may suggest clever stuff
with digital clock managers and the like.

oo that sounds quite clever thanks,
even if it does use more gates than realy necessary it sounds like it
might be quite well controlled if it uses a primitive.


Colin =^.^=

 

[Jonathan Bromley]

I wonder if you could do it with an adder?

[snip]

oo that sounds quite clever thanks,
even if it does use more gates than realy necessary it sounds like it
might be quite well controlled if it uses a primitive.

On second thoughts I'm not at all sure... you need to distribute
the input signal to many different LUTs (all the input bits)
and I fear their routing delays may dominate over the carry
chain delays that you're trying to exploit as a vernier.

Still worth a try, though.

Don't forget the tricks you can play with the SERDES, too.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
(e-mail address removed)
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

 

[Andy]

On Mon, 27 Aug 2007 11:10:34 GMT, "colin"
I need a programable delay of n gates,
im not bothered about it being exact delay
as long as n+1 is just a little bit longer than n etc.
I wonder if you could do it with an adder?

[snip]

oo that sounds quite clever thanks,
even if it does use more gates than realy necessary it sounds like it
might be quite well controlled if it uses a primitive.

On second thoughts I'm not at all sure... you need to distribute
the input signal to many different LUTs (all the input bits)
and I fear their routing delays may dominate over the carry
chain delays that you're trying to exploit as a vernier.

Still worth a try, though.

Don't forget the tricks you can play with the SERDES, too.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
(e-mail address removed)://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

Since we've thrown all caution to the wind...

Building upon what Jonathan suggested, you could use the input to
drive a clock signal (via clock buffer for low skew) that clocks in a
given pattern into a register that is then presented as the addend.
You'd need an async reset to turn it back off. Depending on the
addend, the delay from input to carry out would be quite repeatable,
except over temperature, voltage, die variances, etc. I assume your
control algorithm can deal with that though, so long as it is
monotonic.

Andy

 

[Mike Treseler]

Just a thought. Others with more FPGA-specific
expertise than I have may suggest clever stuff
with digital clock managers and the like.

If Colin requires this delay vernier
to line up a clock with data, this
has already been done quite cleanly in FPGAs
with source synchronous interfaces.
http://www.google.com/search?q=source+synchronous+interface

-- Mike Treseler

 

[colin]

If Colin requires this delay vernier
to line up a clock with data, this
has already been done quite cleanly in FPGAs
with source synchronous interfaces.
http://www.google.com/search?q=source+synchronous+interface

-- Mike Treseler

im not sure if this is any use, unless it has variable delays ?
ive looked at a few but dont seem to be able to see what I want exactly.

theres no data as such,
there are two clocks slightly diferent frequency,
first is started when triger A occurs,
second starts when trigger B occurs,

the vernier reading is the point when the two clocks come in phase.

its not new, its been done with standard ttl etc since erm ..

I just need to know how to tell it to not optimise out my gates !

the delay isnt important as its easy to measure each clock frequency,
but it does need to be variable so they can be made slightly diferent.

Colin =^.^=

 

[Thomas Stanka]

Not sure I'm following what you are trying to do but if you just want
to delay a signal by adding a bunch of "gates" after it, yes they will
get optimized away.

Unless you manage to prevent the synthesis tool to do so.
Im not sure if xst accepts the syn_keep pragma, but I would try using
this in the vhdl code if Xst didn't work with dont_touch.

I fear what you are doing is not good practice. It's a fairly
uncontrolled way of adding delay to a signal. If you can,

There are reasons to consider this as acceptable practice in some
cases, as long as you don't expect the delay having a specific
duration.
If you need to ensure that signal A is definitly after signal B but
before the next rising edge of clock, you might end up, that gate
delays are better to handle than route delays.

bye Thomas

 

[colin]

Unless you manage to prevent the synthesis tool to do so.
Im not sure if xst accepts the syn_keep pragma, but I would try using
this in the vhdl code if Xst didn't work with dont_touch.

The keep pragma works but only so far, by the time it gets to the device its
had no effect.
also the optimize off pragma is acepted but again has no effect on the
generated device.

Ive tried putting it on the schematic and vhdl source,
The schematic gets converted to vhdl anyway.

Its hard to tell how much gets optimised out exept by using the post place
edit tool.

Ive tried the adder aproach and works to some extent but the delay change is
miniscule
compared to the overal delay.

Ive tried various complex routes of logic wich I was sure wldnt get
optimized out,
but this proves to be a headache as one change and wham all the logic is
gone,
or the logic gets changed in such a away that my variable length paths get
optimised to all be as short as eachother.

There are reasons to consider this as acceptable practice in some
cases, as long as you don't expect the delay having a specific
duration.
If you need to ensure that signal A is definitly after signal B but
before the next rising edge of clock, you might end up, that gate
delays are better to handle than route delays.

It would need clocks well in to the many ghz region to do this with clocked
logic the so called proper way.

I realy need to be able to specify a circuit exactly,
its hard going trying to find the information to do it.

Colin =^.^=

 

[Brian Drummond]

Keeping it monotonic at the point of use will be difficult due to
routing delays; using an FPGA column with the point of use in an
adjacent column might work, though you probably also need "directed
routing".

I expect you'll become familiar with floorplanner and FPGA editor...

The keep pragma works but only so far, by the time it gets to the device its
had no effect.
also the optimize off pragma is acepted but again has no effect on the
generated device.

If this hasn't already been suggested, consider a chain of AND gates,
where the second input is fed from a bit in a register. You'll write
(others => '1') to the register, or reset it appropriately (to 0, and
use OR gates), but the synthesiser doesn't know that...

oops, mustn't forget the obligatory "chain of gates is of course a Bad
Idea" warning... ;-)

- Brian

 

[colin]

Keeping it monotonic at the point of use will be difficult due to
routing delays; using an FPGA column with the point of use in an
adjacent column might work, though you probably also need "directed
routing".

I expect you'll become familiar with floorplanner and FPGA editor...


If this hasn't already been suggested, consider a chain of AND gates,
where the second input is fed from a bit in a register. You'll write
(others => '1') to the register, or reset it appropriately (to 0, and
use OR gates), but the synthesiser doesn't know that...

oops, mustn't forget the obligatory "chain of gates is of course a Bad
Idea" warning... ;-)

thanks, I posted in another thread about the wierd problem
that stoped the save and keep atributes from working.

I now have a chain of nor gates, and an and gate ands them all to avoid
glitches,
to make it faster you just set one or more nor inputs high.

now the save net is working they dont all get optimized out lol

im mainly just interested in seeing if this can work,
i thought the main proplem would be crosstalk and jitter
from a bank of internal ring oscillators,
not the software optimizing all my gates out.

Ive droped the need to be monotonic,
as long as two such circuits can
be made close enough to make a vernier

I have used floorplaner but only to find wether my gates were there or not
lol.

ive taken so long messing about with the software ive run out of time
to spend on doing it in hardware for a while, but at least it was a learning
path for vhdl.

Colin =^.^=