run a counter without a clock

Hi to everyone, I'm trying to generate a 5-10 ns pulse width out of an
edge, without the use of any clock, just with internal delays.
Unfortunately I can imagine how much this delay will depend on 
temperature and voltage and how much the width will be affected, but 
still I have some margins (anyway everything will be tested in a thermal 
chamber to verify functionalities).
So far I developed a sort of a "ripple-counter" with an auto-reset for 
each FF (Q(0) will asynchronously reset Q(0)) so that I can start an 
internal oscillation (a clock!).
After that a normal counter can be realized on the basis of this clock, 
allowing to build a pulse. Once the pulse is over a reset is generated 
to stop asynchronously all the FFs.
Does it make sense at all? I think no! :-)

Any ideas?

thanks a lot

Al

-- 
Alessandro Basili
CERN, PH/UGC
Hardware Designer

Al wrote:
> Hi to everyone, I'm trying to generate a 5-10 ns pulse width out of an
> edge, without the use of any clock, just with internal delays.
> Unfortunately I can imagine how much this delay will depend on 
> temperature and voltage and how much the width will be affected, but 
> still I have some margins (anyway everything will be tested in a thermal 
> chamber to verify functionalities).
> So far I developed a sort of a "ripple-counter" with an auto-reset for 
> each FF (Q(0) will asynchronously reset Q(0)) so that I can start an 
> internal oscillation (a clock!).
> After that a normal counter can be realized on the basis of this clock, 
> allowing to build a pulse. Once the pulse is over a reset is generated 
> to stop asynchronously all the FFs.
> Does it make sense at all? I think no! :-)
> 
> Any ideas?
> 
> thanks a lot
> 
> Al
> 
Take a look at the DCM_STANDBY macro Xilinx uses as a workaround for 
Virtex4 DCM problems. They have a circuit in there (ringosc.vhd) that
provides a clock even if no external clock is present.
See 
http://www.xilinx.com/xlnx/xil_ans_display.jsp?BV_UseBVCookie=yes&getPagePath=21127

Alessandro

You have not said what device you are trying to do this in. Generally
temperature, silicon batch, voltage will all affect the result and is
highly unpredictable. You may be better considering either board delays
or discrete delay line devices for better accuracy. Even the good old
RC time constant may be more accurate than using silicon delays
especially if you use a high accuracy voltage comparitor.

John Adair
Enterpoint Ltd.

Al wrote:
> Hi to everyone, I'm trying to generate a 5-10 ns pulse width out of an
> edge, without the use of any clock, just with internal delays.
> Unfortunately I can imagine how much this delay will depend on
> temperature and voltage and how much the width will be affected, but
> still I have some margins (anyway everything will be tested in a thermal
> chamber to verify functionalities).
> So far I developed a sort of a "ripple-counter" with an auto-reset for
> each FF (Q(0) will asynchronously reset Q(0)) so that I can start an
> internal oscillation (a clock!).
> After that a normal counter can be realized on the basis of this clock,
> allowing to build a pulse. Once the pulse is over a reset is generated
> to stop asynchronously all the FFs.
> Does it make sense at all? I think no! :-)
>
> Any ideas?
>
> thanks a lot
> 
> Al
> 
> -- 
> Alessandro Basili
> CERN, PH/UGC
> Hardware Designer

John Adair wrote:
> Alessandro
> 
> You have not said what device you are trying to do this in. Generally
> temperature, silicon batch, voltage will all affect the result and is
> highly unpredictable. You may be better considering either board delays
> or discrete delay line devices for better accuracy. Even the good old
> RC time constant may be more accurate than using silicon delays
> especially if you use a high accuracy voltage comparitor.
> 

It's right, I'm sorry. I am using A54SX08A fpga from Actel and I did 
manage to make the pulse simply using a ripple-counter and getting the 
output on the combination of the value. Last bit in the counter will 
asynchronously reset the whole counter.
With 6 FFs in cascade the back-annotate simulation shows a 5-6 ns pulse, 
  this week I'm going to program the fpga and check.

Unfortunately I cannot change the board layout or add some other 
components, which would have been "cleaner", so I have to do it with the 
logic. What really worries me is the temperature sensitivity, that's why 
we are going to test it in a thermal chamber.
Anyway, based on the datasheet, it looks like that temperature derating 
factor, with 2.5V for VCCA (as it is in our case), will be 0.74 at -40 
�C and 0.97 at +85 �C (our temperature range), that's why I estimated a 
min-max difference of 20%.
If all these calculations are wrong (as they can be)then we will see a 
problem! :-)

Cheers,

Al


-- 
Alessandro Basili
CERN, PH/UGC
Hardware Designer

An errata corrige to my previous post:

Al wrote:
> Anyway, based on the datasheet, it looks like that temperature derating 
> factor, with 2.5V for VCCA (as it is in our case), will be 0.74 at -40 
> �C and 0.97 at +85 �C (our temperature range), that's why I estimated a 
> min-max difference of 20%.
> If all these calculations are wrong (as they can be)then we will see a 
> problem! :-)
> 
The datasheet reports derating for Junction Temperature, which is 
strictly related to the power and is not ambient temperature at all. I 
will estimate power consumption from the external current absorption on 
my board, which has much more than a simple fpga!
The thermochamber will give much more answers!

Cheers

Al


-- 
Alessandro Basili
CERN, PH/UGC
Hardware Designer

Al wrote:

> An errata corrige to my previous post:
> 
> Al wrote:
> 
>> Anyway, based on the datasheet, it looks like that temperature 
>> derating factor, with 2.5V for VCCA (as it is in our case), will be 
>> 0.74 at -40 �C and 0.97 at +85 �C (our temperature range), that's why 
>> I estimated a min-max difference of 20%.
>> If all these calculations are wrong (as they can be)then we will see a 
>> problem! :-)
>>
> The datasheet reports derating for Junction Temperature, which is 
> strictly related to the power and is not ambient temperature at all. I 
> will estimate power consumption from the external current absorption on 
> my board, which has much more than a simple fpga!
> The thermochamber will give much more answers!

Depending on what exactly you are using this for, you could also look
at 'margining' it - generate a tapped delay, and use a faster tap for 
your delay, and check the longer one was still (just) OK, which
means the faster one was OK with margin.

Or, even build a calibrate phase into the tap selection.

On the 'going faster' sense, the FPGAs tend to self-compensate : A
fast process device will give, and tolerate, faster delays, and a
hot device will give, and need, longer delays.
Generally the big problems come when the delays run into the
next clock edge :)

-jg

"Al" <alessandro.basili@cern.ch> wrote in message 
news:ek9t4f$5n2$1@cernne03.cern.ch...
>
> The datasheet reports derating for Junction Temperature, which is strictly 
> related to the power and is not ambient temperature at all.
Hi Al,
So, I guess by the above statement you don't really mean that the junction 
temperature is independent of the ambient temperature, do you?
Cheers, Syms. 

Hi.

I've done some experiments with inverter chain loops on a Virtex 2p.
The frequencies changed about +- 20% from the mean value just depending
on place&route.
If you manage it to get a very fast (but dirty) clock with your
asynchronus logic, with less than 5 ns, I think it should be possible
to measure its frequency onboard with use of a slower stable external
clock. So you could control the pulse length with multiples of the
fundamental frequency of your asynchronus clock.
If you measure a period duration of 3 ns, then you take 2 periods...
Good luck...

Jonas

Symon wrote:
> "Al" <alessandro.basili@cern.ch> wrote in message 
> news:ek9t4f$5n2$1@cernne03.cern.ch...
> 
>>The datasheet reports derating for Junction Temperature, which is strictly 
>>related to the power and is not ambient temperature at all.
> 
> Hi Al,
> So, I guess by the above statement you don't really mean that the junction 
> temperature is independent of the ambient temperature, do you?
> Cheers, Syms. 
> 
> 
No, I didn't mean that (don't know if it sounded like!). The junction 
temperature is so defined:

JT = c*P + Tamb

c = junction to ambient coefficient (related to the package)
P = power
Tamb = ambient temperature

But the P term is not so easy to evaluate.
Cheers

Al

-- 
Alessandro Basili
CERN, PH/UGC
Hardware Designer

Al wrote:

> Hi to everyone, I'm trying to generate a 5-10 ns pulse width out of an
> edge, without the use of any clock, just with internal delays.
> Unfortunately I can imagine how much this delay will depend on 
> temperature and voltage and how much the width will be affected, but 
> still I have some margins (anyway everything will be tested in a 
> thermal chamber to verify functionalities).
> So far I developed a sort of a "ripple-counter" with an auto-reset for 
> each FF (Q(0) will asynchronously reset Q(0)) so that I can start an 
> internal oscillation (a clock!).
> After that a normal counter can be realized on the basis of this 
> clock, allowing to build a pulse. Once the pulse is over a reset is 
> generated to stop asynchronously all the FFs.

I needed a delay to advance an address counter after a bus strobe
ended.  It was for a CPLD on a small plug-in board, and there was
no other need for a clock on the board.  So, I routed the signal out
one pin, through a 1.5 K Ohm resistor, and into another pin.  The
input capacitance of the pin became the C of the RC time constant.
This has worked well in the application.

In your case, taking the signal through a similar external delay, and then
bringing it back in to an AND2B1 for a pulse only on the rising edge,
or an XOR if you want pulses on both edges should do what you want.
Adjust the resistor value to get the desired time delay.

It may also be possible to route to an unbonded IO pad with weak drive
and get a fair amount of delay, easily 5 ns, but probably not 10.

Jon