Ring Oscillator on an fpga

[steamedhams]

How can I create a ring oscillator on fpga hardware?

I have tried it but it just isn't synthesizing the way I want.

[vstrakh]

If it just gets optimized away - use the synthesis 'keep' option on wires between inverters.

[dolbeau]

Depending on what you do, you might try to reuse an existing open-source design (e.g. the betrusted project has a TRNG TRNG characterization and Migen source code as they are Litex-based)

[steamedhams]

I am attempting to measure the delay of routes using the RO method.
I'll try and use keep and mess around with the options to get it to output what i want

[BrianHG]

For Quartus, we use the ' (*preserve*) ' keyword when defining the logic cells used in the inverters.

[SiliconWizard]

I've considered implementing this for a TRNG on FPGA. Not done it yet.

[Someone]

You probably shouldn't be synthesising such designs, since you need control over the specific routing and placement this needs to be done by hand/script.

[Bassman59]

I am attempting to measure the delay of routes using the RO method.
I'll try and use keep and mess around with the options to get it to output what i want

Why not just trust what the static timing analyzer tells you?

Or are you trying to do asynchronous design in your FPGA? If so, verily unto you I say, “good luck with that.”

[mark03]

Or are you trying to do asynchronous design in your FPGA? If so, verily unto you I say, “good luck with that.”

This is an unfortunate attitude which seems to bubble up every time someone asks a question on asynchronous design in, e.g., the Xilinx forums.  Just because "proper RTL design" was drilled into everybody's skull in school, and for good reasons, does not mean there aren't legitimate reasons to deviate from it.  TDCs and HRPWM come to mind.

Anyway, it wouldn't be so bad if the tools did not make manual placement and routing artificially difficult.  As seen here, many of the questions boil down to "how can I defeat the tools?"  Nanny [corporate] state anyone?

[steamedhams]

i got it working today. I had to use "keep" to get it going and it worked like a treat. It is a perfect 80 MHz sinewave.. close enough. I just need to find a way to reduce to distance of the LUTS, then it will be more like a square wave.. maybe

[asmi]

This is an unfortunate attitude which seems to bubble up every time someone asks a question on asynchronous design in, e.g., the Xilinx forums.  Just because "proper RTL design" was drilled into everybody's skull in school, and for good reasons, does not mean there aren't legitimate reasons to deviate from it.  TDCs and HRPWM come to mind.

You can use a microscope to drive down nails too, but it doesn't mean that's a good idea, or that many people will sympathize with your complaints about how inconvenient microscopes are for driving nails. FPGA is a tool designed for synchronous applications. You pick a tool for the job, and not the other way around.

[mark03]

This is an unfortunate attitude which seems to bubble up every time someone asks a question on asynchronous design in, e.g., the Xilinx forums.  Just because "proper RTL design" was drilled into everybody's skull in school, and for good reasons, does not mean there aren't legitimate reasons to deviate from it.  TDCs and HRPWM come to mind.

You can use a microscope to drive down nails too, but it doesn't mean that's a good idea, or that many people will sympathize with your complaints about how inconvenient microscopes are for driving nails. FPGA is a tool designed for synchronous applications. You pick a tool for the job, and not the other way around.

And yet numerous published papers on, e.g., FPGA TDCs exist, and they are used in production (CERN and elsewhere).  You may dismiss these as niche applications but it seems to me unnecessarily harsh to offer blanket discouragement of this sort of thing.  Wouldn't you agree the tools should have an "I know what I'm doing" mode, which is not too obscure or difficult to find?  I am not objecting to reasonable guardrails, but it should be possible to circumvent them easily, and inquiries along these lines should not be seen as somehow wrong-headed, unless you know what the person is attempting to achieve.

To the OP:  If you wouldn't mind posting your HDL / synthesis directives, I think others would find this useful.

[BrianHG]

i got it working today. I had to use "keep" to get it going and it worked like a treat. It is a perfect 80 MHz sinewave.. close enough. I just need to find a way to reduce to distance of the LUTS, then it will be more like a square wave.. maybe

If you do not want to use features like defining where on the fabric your logic ends up, here is another synthesis keyword for Quartus:

(* useioff = 1 *)

However, your output also needs to be set to an IO pin.  This trick will force the compiler to always use that defined logic cell as the one on the IO pin FF.  (Obviously you would build your oscillator code around the IO flip-flop register cell which is also the output.)

Some other dirty trickery will allow you to use the IO pins input and output FF for separate logic or functions combined with the the (*preserve*) directive.

Note that there is the proper way to set and logic-lock regions of your code, however, this requires the full registered version of Quartus and such settings locks you down to a single FPGA size.  The (* useioff = 1 *) trick will still work as you change FPGA sizes and give you consistent timing across builds unless you move the chosen IO pin.

[FenTiger]

You pick a tool for the job, and not the other way around.

I think the OP is trying to implement something like the oscillator he posted in his last thread, as a way of measuring the propagation delay of routes within an FPGA.

If so, he doesn't have the luxury of choosing a different "tool", because that wouldn't serve his purpose.

[Bassman59]

This is an unfortunate attitude which seems to bubble up every time someone asks a question on asynchronous design in, e.g., the Xilinx forums.  Just because "proper RTL design" was drilled into everybody's skull in school, and for good reasons, does not mean there aren't legitimate reasons to deviate from it.  TDCs and HRPWM come to mind.

You can use a microscope to drive down nails too, but it doesn't mean that's a good idea, or that many people will sympathize with your complaints about how inconvenient microscopes are for driving nails. FPGA is a tool designed for synchronous applications. You pick a tool for the job, and not the other way around.

And yet numerous published papers on, e.g., FPGA TDCs exist, and they are used in production (CERN and elsewhere).  You may dismiss these as niche applications but it seems to me unnecessarily harsh to offer blanket discouragement of this sort of thing.  Wouldn't you agree the tools should have an "I know what I'm doing" mode, which is not too obscure or difficult to find?  I am not objecting to reasonable guardrails, but it should be possible to circumvent them easily, and inquiries along these lines should not be seen as somehow wrong-headed, unless you know what the person is attempting to achieve.

Saying "CERN uses this in production" is like the small software vendor saying "IBM uses our application!" Sure, maybe one person at IBM thought the software was useful for a particular task (and there's no reason to doubt this), but that doesn't mean that the whole of IBM uses it or even knows it exists.

As for "unfortunate attitude which seems to bubble up every time someone asks a question on asynchronous design in, e.g., the Xilinx forums," be honest -- most of people asking on the Xilinx forum about async design are newbies who need those guardrails.

And here's the thing: most professional FPGA engineers deviate from fully-synchronous designs all the time. We do it every time we need to cross a clock domain, or handle an asynchronous bus from an external device.

I looked and found a CERN paper on TDCs and it is interesting. The Vernier delay line (figure 6) is a clever way of abusing the fabric. I wonder if you could even do this is in a new FPGA where only global nets route to the flops' clock inputs. But, let's be honest here, this is a 64-tap delay line to achieve a specific goal, and not a general-purpose design technique!

[Bassman59]

i got it working today. I had to use "keep" to get it going and it worked like a treat. It is a perfect 80 MHz sinewave.. close enough. I just need to find a way to reduce to distance of the LUTS, then it will be more like a square wave.. maybe

I assume that you bring the oscillator output to an FPGA pin and you monitor that pin with an oscilloscope. What is your 'scope's analog bandwidth? 80 MHz with a 200 MHz bandwidth will look pretty sine-y.

Seems to me reducing the distance (that is, reducing the routing delay) between the LUTs will increase the oscillator frequency.

[BrianHG]

i got it working today. I had to use "keep" to get it going and it worked like a treat. It is a perfect 80 MHz sinewave.. close enough. I just need to find a way to reduce to distance of the LUTS, then it will be more like a square wave.. maybe

I assume that you bring the oscillator output to an FPGA pin and you monitor that pin with an oscilloscope. What is your 'scope's analog bandwidth? 80 MHz with a 200 MHz bandwidth will look pretty sine-y.

Seems to me reducing the distance (that is, reducing the routing delay) between the LUTs will increase the oscillator frequency.

More than just that, like where is the GND pin connected, what it the drive current on the output pin, how much capacitive load is there on the IO pin, if he using a low capacitance JFET amplified probe to help deal with this?

[mark03]

This is an unfortunate attitude which seems to bubble up every time someone asks a question on asynchronous design in, e.g., the Xilinx forums.  Just because "proper RTL design" was drilled into everybody's skull in school, and for good reasons, does not mean there aren't legitimate reasons to deviate from it.  TDCs and HRPWM come to mind.

You can use a microscope to drive down nails too, but it doesn't mean that's a good idea, or that many people will sympathize with your complaints about how inconvenient microscopes are for driving nails. FPGA is a tool designed for synchronous applications. You pick a tool for the job, and not the other way around.

And yet numerous published papers on, e.g., FPGA TDCs exist, and they are used in production (CERN and elsewhere).  You may dismiss these as niche applications but it seems to me unnecessarily harsh to offer blanket discouragement of this sort of thing.  Wouldn't you agree the tools should have an "I know what I'm doing" mode, which is not too obscure or difficult to find?  I am not objecting to reasonable guardrails, but it should be possible to circumvent them easily, and inquiries along these lines should not be seen as somehow wrong-headed, unless you know what the person is attempting to achieve.

Saying "CERN uses this in production" is like the small software vendor saying "IBM uses our application!" Sure, maybe one person at IBM thought the software was useful for a particular task (and there's no reason to doubt this), but that doesn't mean that the whole of IBM uses it or even knows it exists.

As for "unfortunate attitude which seems to bubble up every time someone asks a question on asynchronous design in, e.g., the Xilinx forums," be honest -- most of people asking on the Xilinx forum about async design are newbies who need those guardrails.

And here's the thing: most professional FPGA engineers deviate from fully-synchronous designs all the time. We do it every time we need to cross a clock domain, or handle an asynchronous bus from an external device.

I looked and found a CERN paper on TDCs and it is interesting. The Vernier delay line (figure 6) is a clever way of abusing the fabric. I wonder if you could even do this is in a new FPGA where only global nets route to the flops' clock inputs. But, let's be honest here, this is a 64-tap delay line to achieve a specific goal, and not a general-purpose design technique!

My understanding is that FPGA TDCs are widely used in the high-energy physics community.  You can get a feel for how widely by searching google scholar for "FPGA TDC."  Popular research topic.  The other direction (digital to time, e.g. high-res PWM) is quite useful too, in things like polar transmit architectures for SDR.

I was one of those people asking on the Xilinx forums, which is why this ticks me off.  The degree of "that's not the correct use of the device" and "you shouldn't want to do that" was really remarkable.  Even after carefully explaining the intended application several times very patiently, I still had a certain user with "dr" in his name trying to tell me why I shouldn't be doing what I was trying to do.

Anyway, I think we can agree that this is not a "general-purpose design technique" (!) as you say.  I just wish Xilinx et al. didn't make it so difficult to circumvent the tools, or get a straight answer as to the best way to do so.