2
\$\begingroup\$

I was doing one bit flipping in the always @ (*) block. As per many experts, it is subjected to undefined behaviour. Does undefined behaviour mean that it's random so that after a specific period of time we can't predict the status of the bit?

Example code:

// tempBit initialized to 0

always @ (*) begin
  tempBit <= ~tempBit;
end
\$\endgroup\$
3
  • 16
    \$\begingroup\$ "undefined behaviour" does not mean "random". \$\endgroup\$ – Hearth Jun 10 at 1:44
  • \$\begingroup\$ Do yo want a True Random Number Generator? For this specific designs with the appropriate test exists. \$\endgroup\$ – Christian B. Jun 10 at 7:23
  • \$\begingroup\$ I've suggested an edit to try to make the question you're asking a bit clearer, feel free to change it if I got the meaning wrong \$\endgroup\$ – llama Jun 10 at 15:37
10
\$\begingroup\$

This code is effectively creating an inverter with its input connected to its output. If the propagation delay through the inverter is long enough you will get a "ring oscillator". The frequency of oscillation is determined by the delay through the inverter.

So, if you have a free-running oscillator what will be the value of its output at any given instant in time? Can you answer that question predictably?

The take-away learning from this is that you have created a combinational loop, with the output of a combinational logic block fed back as an input. There is always the risk of oscillation or the possibility of unintentionally creating a latch. So don't do it...don't use the output of combinational logic as an input to the same logic.

\$\endgroup\$
2
  • 2
    \$\begingroup\$ So, if you have a free-running oscillator what will be the value of its output at any given instant in time? Can you answer that question predictably? <--- This! I think it deserves stressing that this is not necessarily random at all! \$\endgroup\$ – Marcus Müller Jun 10 at 4:40
  • 1
    \$\begingroup\$ Exactly. The core issue is the fact that a square wave is NOT RANDOM but WHEN you decide to sample the voltage of the square wave is unpredictable (I can't know what you plan to do) but importantly is STILL NOT RANDOM. \$\endgroup\$ – slebetman Jun 10 at 13:10
8
\$\begingroup\$

As others mentioned/explained, undefined behavior is not the same as 'randomness'. And I believe you misunderstood the meaning of always @(*) construct in your example code.

Simulator perspective

First of all, it doesn't mean that randomly flip the value of tempBit. It means that: 'Simulator may trigger this always block for any changes in the values (i.e., events) of signals which are used as input within this always block. This is a short-hand to avoid writing and missing out on a long sensitivity list.

The signal tempBit is used as input, so any changes in tempBit will trigger the always block. But again, since the change in tempBit will cause a change to itself due to the feedback, and always block keeps on triggering, and never stabilizes to a value which simulator can resolve for that simulation-time interval. So this is undefined behavior for an RTL simulator to simulate.

Synthesiser perspective

Secondly, * has nothing to do with Synthesiser, because Synthesisers ignore the sensitivity list ahead of implementation on an FPGA/ASIC. What is taken into account by Synthesiser is the piece of description inside the always @(*).

tempBit <= ~tempBit ;

You are in summary asking Synthesiser to feedback the output of an inverter to its input (Like a Ring Oscillator). This is a classic example of a combinational loop, which has to be avoided in RTL designs.

A Solution

If you really want to generate psuedo-random (Why not true-random?!) values on FPGA on-board, you might want to take a look at LFSRs on FPGA.

For e.g,: generate a pseudo-random N-bit number, \$ X \$, and assign one of its bits as output to tempBit, or you may even generate another pseudo-random number \$Y\$ and then assign\$X [Y]\$ to tempBit.

\$\endgroup\$
2
  • 1
    \$\begingroup\$ Nice answer, +1, Just a side note: there's better pseudo-random number generators for FPGAs than LFSRs! Tausworthe is a classic, but a student of mine was able to port XOROSHIRO128+ to a modern Xilinx FPGA; it's running at extremely high clock rates, without the periodicity problems / linear dependency problems that LFSR-based PRNGs have. \$\endgroup\$ – Marcus Müller Jun 10 at 12:10
  • \$\begingroup\$ @MarcusMüller Not very familiar with that. Will checkout... :-) \$\endgroup\$ – Mitu Raj Jun 10 at 12:47
6
\$\begingroup\$

Can always @ (*) introduce randomness in FPGA?

It's undefined behaviour. That can be random, but it's more likely to be a constant value, that might even be chosen during synthesis to optimize this structure away.

"Undefined behaviour" means your synthesize can do with this what it wants, since it literally can't make things any worse. Setting the value to, say, constant zero, or constant one, or whatever optimizes the thing that uses tempBit away to a constant value, would be sensible behaviour.

Even if it really implements a ring oscillator, that might just be stable enough to not actually give a random output – after all, you say you're using an FPGA, so clocked logic, and thus, relationships between clocks can make this totally predictable.

I'll take a shortcut here, hoping to save you more questions: digital HDLs are designed to design deterministic circuits. Everything non-deterministic is undefined behaviour, and suffers the same. If you want a true random number generators, you will have to bypass your synthesizer.

Because you don't seem to in for pseudorandom number generation (which works just fine), but seem to need real randomness, I'd strongly recommend figuring out whether the FPGAs you're targetting have a hardware source of randomness.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.