n gate delay

C

colin

Guest
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 =^.^=
 
On Aug 26, 3:00 pm, "colin" <colin.ro...@ntworld.NOSPAM.com> wrote:
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 =^.^=
Click to expand...
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
 
"Shannon" <sgomes@sbcglobal.net> wrote in message
news:1188191896.489103.125870@x40g2000prg.googlegroups.com...
On Aug 26, 3:00 pm, "colin" <colin.ro...@ntworld.NOSPAM.com> wrote:
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.
Click to expand...
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 =^.^=
 
On Mon, 27 Aug 2007 11:10:34 GMT, "colin"
<colin.rowe1@ntworld.NOSPAM.com> wrote:

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.
Click to expand...
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
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.
 
"Jonathan Bromley" <jonathan.bromley@MYCOMPANY.com> wrote in message
news:uoc5d351djl41qngqok92mf6juu5efjbe9@4ax.com...
On Mon, 27 Aug 2007 11:10:34 GMT, "colin"
colin.rowe1@ntworld.NOSPAM.com> wrote:

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.
Click to expand...
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 =^.^=
 
On Mon, 27 Aug 2007 11:36:55 GMT, "colin"
<colin.rowe1@ntworld.NOSPAM.com> wrote:

"Jonathan Bromley" <jonathan.bromley@MYCOMPANY.com> wrote in message
news:uoc5d351djl41qngqok92mf6juu5efjbe9@4ax.com...
On Mon, 27 Aug 2007 11:10:34 GMT, "colin"
colin.rowe1@ntworld.NOSPAM.com> wrote:

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.
Click to expand...
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
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.
 
On Aug 27, 6:54 am, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com>
wrote:
On Mon, 27 Aug 2007 11:36:55 GMT, "colin"





colin.ro...@ntworld.NOSPAM.com> wrote:
"Jonathan Bromley" <jonathan.brom...@MYCOMPANY.com> wrote in message
news:uoc5d351djl41qngqok92mf6juu5efjbe9@4ax.com...
On Mon, 27 Aug 2007 11:10:34 GMT, "colin"
colin.ro...@ntworld.NOSPAM.com> wrote:

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
jonathan.brom...@MYCOMPANY.comhttp://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.
Click to expand...
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
 
Jonathan Bromley wrote:

Just a thought. Others with more FPGA-specific
expertise than I have may suggest clever stuff
with digital clock managers and the like.
Click to expand...
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
 
"Mike Treseler" <mike_treseler@comcast.net> wrote in message
news:5jgdsoF3tia12U1@mid.individual.net...
Jonathan Bromley wrote:

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
Click to expand...
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 =^.^=
 
On 27 Aug., 07:18, Shannon <sgo...@sbcglobal.net> wrote:
On Aug 26, 3:00 pm, "colin" <colin.ro...@ntworld.NOSPAM.com> wrote:



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.
Click to expand...
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,
Click to expand...
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
 
"Thomas Stanka" <usenet_10@stanka-web.de> wrote in message
news:1188452644.014734.239390@d55g2000hsg.googlegroups.com...
On 27 Aug., 07:18, Shannon <sgo...@sbcglobal.net> wrote:
On Aug 26, 3:00 pm, "colin" <colin.ro...@ntworld.NOSPAM.com> wrote:
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.

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.
Click to expand...
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.

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.
Click to expand...
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 =^.^=
 
On Thu, 30 Aug 2007 14:19:01 GMT, "colin"
<colin.rowe1@ntworld.NOSPAM.com> wrote:

"Thomas Stanka" <usenet_10@stanka-web.de> wrote in message
news:1188452644.014734.239390@d55g2000hsg.googlegroups.com...
On 27 Aug., 07:18, Shannon <sgo...@sbcglobal.net> wrote:
On Aug 26, 3:00 pm, "colin" <colin.ro...@ntworld.NOSPAM.com> wrote:
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.
Click to expand...
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...

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.

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.
Click to expand...
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
 
"Brian Drummond" <brian_drummond@btconnect.com> wrote in message
news:943gd39mu88lmtvrsm25g3qj7ndvo8as7e@4ax.com...
On Thu, 30 Aug 2007 14:19:01 GMT, "colin"
colin.rowe1@ntworld.NOSPAM.com> wrote:

"Thomas Stanka" <usenet_10@stanka-web.de> wrote in message
news:1188452644.014734.239390@d55g2000hsg.googlegroups.com...
On 27 Aug., 07:18, Shannon <sgo...@sbcglobal.net> wrote:
On Aug 26, 3:00 pm, "colin" <colin.ro...@ntworld.NOSPAM.com> wrote:
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.

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...

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.

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... ;-)
Click to expand...
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 =^.^=
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top