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
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.
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.
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.
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.
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.
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.
