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
Reply to
Al
Loading thread data ...

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

formatting link

Reply to
Koen Van Renterghem

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 Enterpo> Hi to everyone, I'm trying to generate a 5-10 ns pulse width out of an

Reply to
John Adair

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
Reply to
Al

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
Reply to
Al

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

Reply to
Jim Granville

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.

Reply to
Symon

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

Reply to
jonas

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
Reply to
Al

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

Reply to
Jon Elson

Al mentioned he wanted to avoid a PCB respin, but he could certainly look for spare IO pin(s), and make use of the pin path delays. It may even become probe-able ?

-jg

Reply to
Jim Granville

Hi guys, well, as Jim said I wouln't like to respin the pcb, but still the IO delay could be used because there are some close pins which are not used and can be easily shorted, but unfortunately I need to instantiate a lot of these delays. So either I implement a free running counter with this delay to generate an internal clock and then do all the things I need, or I simply try to count on the internal routing delay, which is quite ok on post-layout sim, but still have to try it on the hardware! I will post my results next week, when I will do some tests.

Thanks to all

Al

--
Alessandro Basili
CERN, PH/UGC
Hardware Designer
Reply to
Al

Al schrieb:

buried ring oscillator tends to run at rather high frequencies, so you may use a single unused IO pin as pin-pad-oscillator (just route pad in over inverter back to pad, may have to add always true tristate control to avoid synthesis issues) this will usually oscillate at lower frequencies, and in most cases will have constant routing without special tricks to lock the instances

Antti

Reply to
Antti

Sorry Jim, I didn't understand correctly what do you mean by that.

Don't understand this either

Could you give me some reference about what you said or simply explain this to me in a more detailed way? You can contact me directly if you think this is not the place to go in details.

Thanks a lot

Al

--
Alessandro Basili
CERN, PH/UGC
Hardware Designer
Reply to
Al

Guys, I used an unbonded IOB to get delay once. Drove a signal to its unbonded pad and got the signal back through the IOB delay thing on the same unbonded IOB. Who knows what the delay would be from device to device, but it was good enough to deglitch a 19MHz clock. If you do this, you need to turn of the DRC in the bitgen part of the tool flow. HTH, Syms.

Reply to
Symon

What is the DRC in the bitgen? Thanks

Al

--
Alessandro Basili
CERN, PH/UGC
Hardware Designer
Reply to
Al

Al,

formatting link

HTH, Syms.

Reply to
Symon

It depends on just what you are trying to do - it sounds like you have some sort of centering issue ? The idea above means to create a number of delays, and then use one, but check with another - so you can at least flag a failure. The simplest delay schemes have no error flags

To do this, you need again a tapped delay line, only now you add a CAL phase - again, system dependant, but often you have a pulse/chipselect of known width, and that is used to sample/latch the Chip delay line, and store the result. That number then selects a tap to use in the desired delay.

Rather more complex than a simple IO pin delay, but it self-tracks. Downside is you need a CAL pass before it is valid.

-jg

Reply to
Jim Granville

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.