Generate random signal

D

Daku

Guest
Could some Verilog guru please suggest some ideas ?
A standard way to generate a clock pulse would be:
always
begin
#5 clock = 1;
#5 clock = 0;
end

Is there a straightforward way to generate a signal that goes high at
random intervals ?
I have messed around with $random and tried some ideas with LFSRs, but
have not gotten anything useful to work .
Any hints, suggestions would be extremely helpful. Thanks in advance
for your help.
 
On Dec 11, 8:11 am, Daku <dakup...@gmail.com> wrote:

A standard way to generate a clock pulse would be:
always
 begin
  #5 clock = 1;
  #5 clock = 0;
end

Is there a straightforward way to generate a signal that goes high at
random intervals ?
Click to expand...
Of course there is, but you need to be a bit clearer about what
you mean by "random".

You can make a "random" clock signal easily, but let's think a
little about the characteristics you want it to have. Is it to
be a given frequency, with random jitter on the edges? Or
perhaps you want some jitter in the clock phase, or period?
Both those things can be done by computing a random time
error, and using it in a delay. Here's a 100MHz clock
generator with jitter in its edges:

`timescale 1ps/1ps;
...
parameter half_period = 5000; // 100 MHz nominal
parameter max_jitter = 500; // +/- 0.5ns jitter
reg clock;
reg clock_running = 1; // set to 0 to stop the clock
initial begin : jittery_clock_generator
integer seed; // needed for $dist_uniform
integer edge_error;
seed = 42; // change this to get different random values
clock = 0;
while (clock_running) begin
edge_error = $dist_uniform(seed, -max_jitter, +max_jitter);
#(half_period + edge_error) clock = ~clock;
end
end

If you don't like the uniform jitter distribution you could
try dist_gaussian instead, but beware of the (rather rare)
possibility of jitter being larger than a half-period.

Randomization of frequency I'll leave as an exercise :)

Another useful thing to do is to generate a random possibility
of something happening. Suppose you have some synchronous
enable signal, and you want it to be asserted and deasserted
randomly on each clock edge. If you simply use randomization:

always @(posedge clock)
if ($random > 0)
enable <= 1;
else
enable <= 0;

you will get 50% probability of enable being active, but the
behaviour will probably not be very interesting; for example,
the chance of getting enable asserted for 4 successive clocks
is only 1/16. So it may be more interesting to say that
enable has a certain (small) probability of changing:

parameter typical_pulse_duration = 5;
initial begin : random_activity
integer seed;
seed = 42;
enable = 0;
forever @(posedge clock) begin
if ($dist_uniform(seed, 0, typical_pulse_duration) == 0)
enable <= ~enable;
end
end

Don't forget the other $dist_*** distribution functions:
for example, $dist_poisson is particularly useful for generating
things like the number of wait states introduced by a peripheral.

SystemVerilog adds a very sophisticated constraint language,
giving you access to all kinds of other randomization possibilities,
but that's another discussion. Good old Verilog $dist_*** will
get you a long way.

Hope this gives you some ideas. Be more precise about your needs
if you want more specific advice!
--
Jonathan Bromley
 
Thanks for the feedback. What I am really after is random variations
in clock period, so that within a fixed time interval of observation,
say 1 sec, I will have 5000 pulses, and then in the next second, 1250
pulses, so that the number of pulses per
unit time fluctuates.

On Dec 11, 1:35 pm, Jonathan Bromley <s...@oxfordbromley.plus.com>
wrote:
On Dec 11, 8:11 am, Daku <dakup...@gmail.com> wrote:

A standard way to generate a clock pulse would be:
always
begin
#5 clock = 1;
#5 clock = 0;
end

Is there a straightforward way to generate a signal that goes high at
random intervals ?

Of course there is, but you need to be a bit clearer about what
you mean by "random".

You can make a "random" clock signal easily, but let's think a
little about the characteristics you want it to have. Is it to
be a given frequency, with random jitter on the edges? Or
perhaps you want some jitter in the clock phase, or period?
Both those things can be done by computing a random time
error, and using it in a delay. Here's a 100MHz clock
generator with jitter in its edges:

`timescale 1ps/1ps;
...
parameter half_period = 5000; // 100 MHz nominal
parameter max_jitter = 500; // +/- 0.5ns jitter
reg clock;
reg clock_running = 1; // set to 0 to stop the clock
initial begin : jittery_clock_generator
integer seed; // needed for $dist_uniform
integer edge_error;
seed = 42; // change this to get different random values
clock = 0;
while (clock_running) begin
edge_error = $dist_uniform(seed, -max_jitter, +max_jitter);
#(half_period + edge_error) clock = ~clock;
end
end

If you don't like the uniform jitter distribution you could
try dist_gaussian instead, but beware of the (rather rare)
possibility of jitter being larger than a half-period.

Randomization of frequency I'll leave as an exercise :)

Another useful thing to do is to generate a random possibility
of something happening. Suppose you have some synchronous
enable signal, and you want it to be asserted and deasserted
randomly on each clock edge. If you simply use randomization:

always @(posedge clock)
if ($random > 0)
enable <= 1;
else
enable <= 0;

you will get 50% probability of enable being active, but the
behaviour will probably not be very interesting; for example,
the chance of getting enable asserted for 4 successive clocks
is only 1/16. So it may be more interesting to say that
enable has a certain (small) probability of changing:

parameter typical_pulse_duration = 5;
initial begin : random_activity
integer seed;
seed = 42;
enable = 0;
forever @(posedge clock) begin
if ($dist_uniform(seed, 0, typical_pulse_duration) == 0)
enable <= ~enable;
end
end

Don't forget the other $dist_*** distribution functions:
for example, $dist_poisson is particularly useful for generating
things like the number of wait states introduced by a peripheral.

SystemVerilog adds a very sophisticated constraint language,
giving you access to all kinds of other randomization possibilities,
but that's another discussion. Good old Verilog $dist_*** will
get you a long way.

Hope this gives you some ideas. Be more precise about your needs
if you want more specific advice!
--
Jonathan Bromley
Click to expand...
 
On Dec 11, 4:58 pm, Daku <dakup...@gmail.com> wrote:
Thanks for the feedback. What I am really after is random variations
in clock period, so that within a fixed time interval of observation,
say 1 sec, I will have 5000 pulses, and then in the next second, 1250
pulses, so that the number of pulses per
unit time fluctuates.
Click to expand...
If I may be permitted to quote myself:

Be more precise about your needs
Click to expand...
"Fluctuates" is not a very lucid way to describe a probability
distribution!
--
Jonathan Bromley
 
Basically a power law distribution, so that
the time period the clock is high is constant, but the time period the
clock is
low varies as in a power law. As a result,
if I were to look at the clock output with
GTKWave, there will regions where clock low
times are small (varying about a mean) and then there would be regions
where the clock
low times are large.
I have had some success with $dist_exponential, but I think I will
have to write a function myself to achieve this.



On Dec 11, 9:36 pm, Jonathan Bromley <s...@oxfordbromley.plus.com>
wrote:

If I may be permitted to quote myself:
snip ...
"Fluctuates" is not a very lucid way to describe a probability
distribution!
--
Jonathan Bromley
Click to expand...
 
On Friday, December 11, 2009 at 12:41:48 PM UTC+5:30, Daku wrote:
Could some Verilog guru please suggest some ideas ?
A standard way to generate a clock pulse would be:
always
begin
#5 clock = 1;
#5 clock = 0;
end

Is there a straightforward way to generate a signal that goes high at
random intervals ?
I have messed around with $random and tried some ideas with LFSRs, but
have not gotten anything useful to work .
Any hints, suggestions would be extremely helpful. Thanks in advance
for your help.
Click to expand...

Hi,

Have a Nice Day !!!

Have you fixed this issue??? If yes, how did you achieve it??? I wanna generate a random signal (but not pseudo random using LFSR)using HDL to implement in FPGA???
 
On 10/26/2016 7:35 AM, sumathig2806@gmail.com wrote:
On Friday, December 11, 2009 at 12:41:48 PM UTC+5:30, Daku wrote:
Could some Verilog guru please suggest some ideas ?
A standard way to generate a clock pulse would be:
always
begin
#5 clock = 1;
#5 clock = 0;
end

Is there a straightforward way to generate a signal that goes high at
random intervals ?
I have messed around with $random and tried some ideas with LFSRs, but
have not gotten anything useful to work .
Any hints, suggestions would be extremely helpful. Thanks in advance
for your help.

Hi,

Have a Nice Day !!!

Have you fixed this issue??? If yes, how did you achieve it??? I wanna generate a random signal (but not pseudo random using LFSR)using HDL to implement in FPGA???
Click to expand...

When you say "not LFSR", what are you looking for the an LFSR doesn't
provide? You can't get true randomness from calculations. In fact,
there is no true randomness other than quantum mechanical events.

What are you really trying to do?

--

Rick C
 
rickman <gnuarm@gmail.com> wrote:
On 10/26/2016 7:35 AM, sumathig2806@gmail.com wrote:
Have you fixed this issue??? If yes, how did you achieve it??? I wanna
generate a random signal (but not pseudo random using LFSR)using HDL to
implement in FPGA???

When you say "not LFSR", what are you looking for the an LFSR doesn't
provide? You can't get true randomness from calculations. In fact,
there is no true randomness other than quantum mechanical events.
Click to expand...

Look at a PUF (Physical Uncloneable Function). It's a way of deriving a key
from device variability - typically harvested by racing two paths through a
stack of muxes or comparing free-running ring oscillators.

You can use a PUF to seed a pseudo-random number generator (RNG), which gets
you a device-specific RNG. There's various PUF RNG work - I think this is
the first:
http://csg.csail.mit.edu/pubs/memos/Memo-481/Memo-481.pdf

Lots of commercial chips use the non-PUF ring oscillator approach - ie XOR a
number of ring oscillators together to produce a bitstream with some degree
of non-determinism. However it's typically a bit harder on an FPGA because
you have to fight the tools to achieve it. There are ways though:
https://people.csail.mit.edu/devadas/pubs/ches-fpga-random.pdf

It is also worth mentioning that such RNGs should also be evaluated in the
face of an attacker, as I found out:
https://www.cl.cam.ac.uk/~atm26/papers/markettos-ches2009-inject-trng.pdf

Theo
 
On 11/26/2016 3:01 PM, Theo Markettos wrote:
rickman <gnuarm@gmail.com> wrote:
On 10/26/2016 7:35 AM, sumathig2806@gmail.com wrote:
Have you fixed this issue??? If yes, how did you achieve it??? I wanna
generate a random signal (but not pseudo random using LFSR)using HDL to
implement in FPGA???

When you say "not LFSR", what are you looking for the an LFSR doesn't
provide? You can't get true randomness from calculations. In fact,
there is no true randomness other than quantum mechanical events.

Look at a PUF (Physical Uncloneable Function). It's a way of deriving a key
from device variability - typically harvested by racing two paths through a
stack of muxes or comparing free-running ring oscillators.

You can use a PUF to seed a pseudo-random number generator (RNG), which gets
you a device-specific RNG. There's various PUF RNG work - I think this is
the first:
http://csg.csail.mit.edu/pubs/memos/Memo-481/Memo-481.pdf

Lots of commercial chips use the non-PUF ring oscillator approach - ie XOR a
number of ring oscillators together to produce a bitstream with some degree
of non-determinism. However it's typically a bit harder on an FPGA because
you have to fight the tools to achieve it. There are ways though:
https://people.csail.mit.edu/devadas/pubs/ches-fpga-random.pdf
Click to expand...

My understanding is that multiple asynch ring oscillators is hard to do
because they tend to couple. In the end they end up being vaguely
periodic which destroys their utility as RNGs.


It is also worth mentioning that such RNGs should also be evaluated in the
face of an attacker, as I found out:
https://www.cl.cam.ac.uk/~atm26/papers/markettos-ches2009-inject-trng.pdf

Theo
Click to expand...

--

Rick C
 
rickman <gnuarm@gmail.com> wrote:
My understanding is that multiple asynch ring oscillators is hard to do
because they tend to couple. In the end they end up being vaguely
periodic which destroys their utility as RNGs.
Click to expand...

That's true - it doesn't take much to cause them to step into line.

I've been poking around microcontroller TRNGs recently and a few others look
a bit worrying - eg the 'leave the ADC pin floating and sample the "random
noise"' approach, which suggests it'll instead sample whatever the pin
happens to be capacitively coupled to. I think a lot of people are
substantially overestimating how much entropy they collect.

Theo
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top