In my code, I've to use some registers which are used to store some values for making decision in code. They don't directly take values from input wire.
Now, I'm getting ...
Signal is assigned but never used. This unconnected signal will
be trimmed during the optimization process.
Should I ignore this warning? My simulation works correctly.
The short answer is: no, you shouldn't. The long answer is (as usually) "it depends".
Assigned signals that are detected as not being in use could mean that you forgot to connect a port of your module, or you mispelled a signal name. In these cases, it is likely that your design won't behave as expected.
On the other hand, there is a kind of construction that usually leads to this warning: the case in that a register is defined with N bits, although only some of them are actually used (for example, an 8 bit control register in a device, in which only bit 0 is used). In this case, the warning can be safely ignored. Your simulation will not be affected by this.
So just ask yourself whether that particular signal should be used (read) by any other part in your design or not.
Related
In OpenModelcia, do all variables of a model save in the ring buffer only when the delay operator is used, or is it done automatically whether we use delay or not? and if so, can we access the ring buffer from an external function C?
Since Modelica models can fail at any point in time all variables are saved in some sort of backup, for the C runtime in some buffers in the so-called thread data. And in some cases the OpenModelica compiler is able to revert the last step and try again, but slightly different.
For example an assert is throwing an error, because some variable has become negative but wasn't allowed to, so the compiler tries again with a smaller step size.
This backup is done independent of the presence of the delay operator and always done.
For the delay operator a different data structure is used, which is the RINGBUFFER you are probably referring to. It is only allocated if there are delay operators in the Modelica model.
There are no API functions provided to access (this) internal data of a OpenModelica simulation. So accessing the ring buffer would only be possible if you write such a function yourself, which is of course possible.
Question would be what you are trying to accomplish in the first place.
I have some questions about reg initialization.
Can I put Initial blocks in the design? Is that a good way?
How to initial regs in my bottom design? Do I need to create ports in each level and give initial value from top to bottom? For each simulation, initial values are different.
Point 1:
We recently had a discussion about initial statements on the Electronics forum.
Initial statements in test benches are normal. In fact without initial statements it becomes a lot more difficult to write test code.
Initial statements are not possible in ASICs, CPLDs or hard programmed FPGAs.
You can use initial statements in a most RAM based FPGAs where the state is valid after the FPGA is loaded. However if you would have a 'reset' pin or command that would not restore the initial state. As such, the FPGA condition after such a reset could well be different from your start-up state and thus your design might not work correctly.
There are some cases where an initial state in an actual synthesize-able module is allowed or even mandatory for the module to work. See examples below.
Example 1: You have a divide by two register without reset coded as:
divide_by_two <= ~divide_by_two;
or
divide_by_two <= not(divide_by_two);
In simulation that will always remain 'X' but in reality it will start in a 0 or 1 conditions and then toggle between the two. To work around the 'X' in simulation you have the set an initial condition. Your code should work independent if the initial condition is '1' or '0'.
Example 2: You have a divide by four register without reset coded as:
divide_by_four[1:0] <= {divide_by_four[0],~divide_by_four[1]};
or
divide_by_four[1:0] <= divide_by_four[0] & not(divide_by_four[1]);
The reason why this is allowed is that during operation the two registers go through every of the four possible states: 00, 01, 11, 10. It does not matter in which of the four it starts, the sequence will always be repeated. Again to work around the 'XX' in simulation you have the set an initial condition. Your code should work independent if the initial condition is 00, 01, 10 or 11.
A lot of designers feel that, apart for examples like above, the use of initial statements in synthesized code is dangerous and it is better to avoid them.
Point 2:
Instead of initial statements you can use a 'reset' signal with the appropriate HDL code to set the start condition. It is normal for the reset to go to every module which has registers.
Depends on your target design.
You can usually use initial blocks with FPGAs. You can initialization the registers in the same module that declares it. Hierarchically assignment is not allowed. You can also initialization registers with a synchronous reset if you add a reset input. Most FPGAs have a limited number of flops with asynchronous reset/preset (if any). Hence initial blocks and synchronous resets are the best options FPGA.
ASICs typically do not synthesize initial blocks. Initialization of flops is done with reset condition in synchronous logic. This is commonly an asynchronous reset but not required. In sort, synchronous or asynchronous reset for ASIC.
For both cases, to be synthesizable the initialization value needs to be deterministic and determined by constants. It cannot be derived on an input port or the current state of another register.
It is a good idea to follow these guidelines even if you plan to never synthesize. Otherwise is extra challenging to debug.
I am currently running my UPPAAL simulator. My simulator stops running the code after a certain point. This point varies depending on the declaration i provide. But i would like to know generally when does the clock stop running? Is there something that triggers this?
I'm not sure if I interpret your question correctly, if I could read your model I may give you some precise advice.
Trying to guess what the problem is, I can say there are times when the Uppaal simulator takes infinitely many discrete steps (transitions) without increasing any of the clock variables.
The feeling is that "the clock is stopped", while the rest of the simulation is going on. In this case, the time is not actually stopped: Uppaal, among all possible paths, it is just exploring the one where clock does not evolve. If the simulator (or the model checker) can take infinitely many transitions without increasing the clock variables, that is an example of "Zeno path".
It is a responsibility of the person who writes the model to avoid the possibility of taking zeno paths.
If you are not sure your model is free of Zeno paths, you can use known methods for verifying that a Timed Automaton has no zeno paths (in Uppaal).
Another possibility is that the simulator stop running at all saying that there is a deadlock. In this case the problem is not that the clock stopped running, but that you arrived at a situation where all possible transitions are disabled (maybe because all possible guards are never enabled, or because all the possible target states of your enabled transitions have some time invariants that are false)
I went over a few Verilog tutorials and reviewed the topics a couple times and a few questions have been lingering in my head from since the concepts were first introduced and if anyone could shed them light on them, that would be very helpful.
What's the purpose of strength on a net?
Often times in examples parameters exact names are used to also describe registers. For example:
module x (…,in1,…);
…
input in1;
reg [7:0] in1;
…
endmodule
Does this declare the input port as a type of data or are they separate? If the former is true, what other kinds of quantities can I do this with (integers, scalars, etc.)? If the latter is true which item am I referring to when I say “in1” inside the module?
Initial blocks at the beginning of a simulation all get executed in “parallel” but when you’re inside the block, the instructions are executed serially. Does the simulation tool you’re using determine what order the serially executed instructions are done in? For instance you have 2 initial blocks, do we execute all of one first, or jump back and forth?
4 .Why are initial values in simulation X? If Verilog’s job is to represent real life why doesn’t it have a pseudo random engine and pick the same random order of bits for all the values at the beginning? You run into a lot of issues with unique case statement warnings and it seems like a design flaw or at least an incongruity between system Verilog and Verilog.
Lets you have multiple drivers on a net and determine the value of the resulting signal; see 7.10 in the LRM
They're all the same in1 - very verbose. In V-2001 you can write a single input reg[7:0] in1 in the port list instead. You can do this for anything that you connect through a port.
Note that initial's are not guaranteed to be executed before always, and there is no guaranteed order of execution between any initial/always blocks in your design. In practice, the simulator chooses a block, and executes it until it reaches a suspend point (a timing control), at which point the sim schedules another initial or always, and executes that until it suspends, and so on.
This is essentially philosphy, but why would you want to assign initial random values to anything? This is basically what 'unknown' (X) means (or Z for nets). If everything is X or Z at the beginning of time, then you know that it's uninitialised and will remain so until you do something to it. If the tool gave everything initial random valid values you'd never know that.
In case of a contention strength helps to resolve to a known value. Last time I saw something like this in a design was it 10 years ago. And even then it was considered to be a bad design practice.
As EML says it.
No and No. The statements in any procedural block such as initial block are executed sequentially within the same time-slot. The initial blocks begin execution at time 0. The simulator executes all the statements in the order they appear inside the initial block as per the verilog event queue. The variables are updated as per the schedule dictated by the event queue. All of this is part of the standard (LRM 8.10). If you are not familiar with verilog event queue and the notion of time-slots and simulation time then Cliff Cumming's paper is a great reference. It doesn't matter if the simulator executes the statements from different initial blocks interleaved or any other way. The simulation time doesn't advance and the variables are only updated based on the event queue.
What is not standard is which initial block the simulator should begin with. This becomes important because this creates dependency on the simulator if variables are assigned in one initial block and used in the other procedural block within the same event queue. Cumming's paper referenced above explains this scenario very nicely.
It's not just about the unresolved state of the net. But also about starting the simulation from a predictable state. Therefore, randomly picking the resolved state of the inputs to the design would not provide the predictability in starting the simulator from the same point everytime. In addition to EML's suggestion, you may use the 2-state datatypes provided in SystemVerilog. Ofcourse, these are not synthesizable. Because, to accurately model the hardware you want the output state to be unknown if the inputs are unknown.
While I try to put the animation update function and physics simulation of a game engine into a seperate thread for execution, I realize the potential race condition of some floating point values (say, position of an object) between the writer thread (animation,physics) and the reader thread (renderer) if both threads are going to access the values simultaneously.
My question is, given that even a floating point assignment is not atomic, will such a read-write race condition can result a wired/sudden change of the original smoothly changing values as seen by the reader?
Moreover, in my situation I can tolerance a small amount of error, since such error will not accumulate over the next rendering frame.
For my understanding, you can ignore the race condition as long as you only have on thread writing the veriable at a time and you don't care if your reading thread(s) are not using the latest version.
From my understanding, writing the float should be atomic to your code, though this could be platform-dependent I assume.
Section 12.5 of ECMA-334 (the C# language specifcation) states:
Reads and writes of the following data
types shall be atomic: bool, char,
byte, sbyte, short, ushort, uint, int,
float, and reference types.
To that end, you shouldn't see any corruption due to reads and writes of a float (assuming you don't mean double here, that is not guaranteed to be an atomic write).
However, what should be noted is that while the writing of the values is guaranteed to be atomic, the order of the reads/writes is not guaranteed unless you are using something specific, like a call to Monitor.Enter.
Monitor.Enter is a little heavy for this though, so I would recommend using the volatile keyword when declaring the variable. Assuming the read/write of this variable is the only thing that needs to occur, it will guarantee that the reads/writes are done in order.
Theoretically speaking you could get a massive degree of error if there was a context switch between updating the exponent and updating the mantissa, but I doubt most platforms or architectures in use today allow such a thing to happen.