#698 $urandom with seed parameter treats seed as inout

[Trevor Williams]

SystemVerilog treats the seed parameter to the $urandom built-in system call as an input, taking its value and assigning it to the seed associated with the current thread (each thread stores and uses its own seed value). It is expected that the first call to the $urandom system call within the thread sets the seed value and after that, the version of $urandom without a seed parameter.

However, Icarus Verilog does not store the seed value to the thread and, instead, treats the seed parameter in the same way that the $random built-in system call does -- that is, the seed parameter is treated as an inout. This will lead to incorrect simulation results with different simulators.

[Cary R.]

I have started looking at what is needed to make this work correctly. We obviously do not support the full random features of SV. I think I have the basics worked out, but there are some finer details that I need to work through before I start coding. I may have a few examples that need to be tested.

[Cary R.]

Hi Trevor,

I think I'm getting close to having a plan for this in procedural code, but how is this handled in a continuous assign? The other random functions work, but you should really not pass a seed since you don't know the evaluation order and for $urandom where is the seed information stored? Is there a global place for CA statements or is this even allowed?

[Nobody/Anonymous]

Cary,

I'm not exactly sure why anyone would make a call to a random function in a continuous assignment. I cannot find any examples of this in the System Verilog documentation that I have, so I would say that this is a non-issue. If a user passes a seed to a $urandom call in a continuous assignment, they run the risk of indeterminable behavior the simulator. Perhaps if this parsed, a warning or such could be generated.

One interesting thing that I read about when scanning for examples was a statement that suggests the following:

"Initial values in SystemVerilog are not constrained to simple constants; they can include run-time expressions, including dynamic memory allocation. For example, a static class handle or a mailbox can be created and initialized by calling its new method, or static variables can be initialized to random values by calling the $urandom system task. This requires a special pre-initial pass at run-time."

I'm not suggesting that adding the ability to $urandom in parameter assignments or the like is required for this bug report -- but perhaps something to keep in the back of your mind.

Later,
Trevor

[Cary R.]

For the normal random functions we allow this, though using a seed is considered bad form since you don't have a deterministic order. The random functions do not create events, but do create new values each time the expression is evaluated. I can't remember if this is once per time step or once per evaluation.

If you make an example and run it under a SV simulator what happens?

Yes I had seen the initial pass part of SV and no it will not be part of this report. For that matter all the various ways to initialize a random value will not be part of this report. For this report I would just like to have the random value stored in thread space and inherited correctly. What to do for CAs is part of the mix since we allow the other random functions in this context and I don't know where to store the seed information. I'm guessing that we need to use a global place that is independent of thread space.

[Cary R.]

This is still on my list of things to look at, but it is now a more long term project. I really need to get the space in path working before we release V0.9.2 and work is very busy so this unfortunately has been and will continue to languish.

[Cary R.]

Hi Trevor,

I want to let you know that I have not forgotten about this. As you may have been able to surmise from other sources of information I'm very busy at work. Once we tape out and I have some time to recover I'll look at fixing this. Unfortunately being the only one with software experience in the company I'll need to write the control software/GUI before the part comes back, so the break will not be as long/leisurely as I'd like it to be.

[Cary R.]

I'm going to drop this from my list since I really need to focus on the expression rework. Once I'm done with that and assuming no one else has fixed this I'll come back and look at this again.

[Stephen Williams]

Getting this right requires an understanding of SystemVerilog processes (threads). The $urandom and $urandom_range system functions implicitly use thread storage to stash the current state of the RNG, and also implicitly seeds the RNG in sub-threads (fork-join). This will be a bit of a business to get right:-( And if we are going to do it, we should do it right. (The SystemVerilog rules for $urandom make excellent sense to me, so I think we should get it right.)

SystemVerilog adds VPI support for threads. That is probably the right place to hang per-thread data needed to implement things like this.