Generate random signal
Daku
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.
Jonathan Bromley
> 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
Daku
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:
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.
If I may be permitted to quote myself:
> > Be more precise about your needs
"Fluctuates" is not a very lucid way to describe a probability
distribution!
--
Jonathan Bromley
Daku
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 ...
sumath...@gmail.com
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???
rickman
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
Theo Markettos
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
rickman
> rickman <gnu...@gmail.com> wrote:
>> On 10/26/2016 7:35 AM, sumath...@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
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
>
Rick C
Theo Markettos
> 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.
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