I have a rather large if else block.
always #(posedge clk)
begin
r <= 3;
if( cond1 )
a <= 1;
else if( cond2 )
begin
a <= 2;
r <= 3;
end
else
a <= 3;
end
In this case I am trying to specify a default value for r in the blocks. Would the top r<= statement be executed for the first and last if blocks?
It is perfectly legal to specify default values.
In Verilog the last assignment 'wins'.
- For non blocking assignments that means only the last one is executed.
- For blocking assignments they are executed in the order they are encountered.
In fact in complex state machines it is a method I prefer.
You can use it in both combinatorial (blocking) and clocked/registered (non-blocking) code.
However it is good coding practice to flag this so the reader
knows you are setting defaults and that those values can be override further down in the code. Here a is a snippet from a UART transmitter:
// Defaults for TX FSM
nxt_tx_state = tx_state;
nxt_tx_bit_cnt = tx_bit_cnt;
nxt_tx_samp_cnt = tx_samp_cnt;
nxt_shift_out = shift_out;
The same holds when you have a bottom-all-overriding assignment:
....
....
// This overrides all the above
if (emergency_halt)
state <= IDLE_STATE;
How does the synhtesis tool process this default value? Or is not something I dont have to look at
You don't have to worry about it. Most important is that the simulation and the hardware behave in the same way.
But I'll answer anyway. Simplest is to give an example:
always #(*)
begin
// default
A = 1;
if (B==2)
A = 3;
if (B==4)
A = 5;
end
The synthesis tool translates this into:
if (B==4)
A = 5;
else if (B==2)
A = 3;
else
A = 1;
In this case the two 'if' statements are mutually exclusive but even if that is not the case the result will be that the hardware behaves as the blocking assignments: The last one wins.
Related
I am trying to create an Immediate Generator for RISC-V assembly, but I have encountered an error with if statement.
Here is my code in Verilog:
module signextend(in, out, sel);
parameter nin = 32;
parameter nout = 32;
input [nin-1:nin-25] in;
input [2:0] sel;
output [nout-1:0] out;
if (sel == 3'b000)
begin
assign out[19:0] = in[31:12];
assign out[31:20] = {12{in[31]}};
end
else if (sel == 3'b001)
begin
assign out[11:0] = in[31:20];
assign out[31:12] = {20{in[31]}};
end
else if (sel == 3'b010)
begin
assign out[4:0] = in[24:20];
assign out[31:5] = 0;
end
else if (sel == 3'b011)
begin
assign out[3:0] = in[11:8];
assign out[4:9] = in[30:25];
assign out[10] = in[7];
assign out[11] = in[31];
assign out[31:12] = {20{in[31]}};
end
else if (sel == 3'b100)
begin
assign out[4:0] = in[11:7];
assign out[11:5] = in[31:25];
assign out[31:12] = {20{in[31]}};
end
else if (sel == 3'b101)
begin
assign out[9:0] = in[21:30];
assign out[10] = in[20];
assign out[18:11] = in[19:12];
assign out[19] = in[31];
assign out[31:20] = {12{in[31]}};
end
else
assign out = 32'hxxxx;
endmodule
The problem exists in each if statement:
The generate if condition must be a constant expression.
You need to put all your code inside an always block and remove the assigns:
always #(*) begin
if (sel == 3'b000)
begin
out[19:0] = in[31:12];
out[31:20] = {12{in[31]}};
end
else if (sel == 3'b001)
// etc
An always block contains a little bit of software (your if statements) that models a little bit of hardware (the resulting combinational logic).
It is legal to have an if statement outside an always (or initial) block, but then it means something different. Then it means conditional including of hardware, ie if some condition is true, include this hardware. Such a condition has to be static, ie fixed at compile time. It cannot be an input, like your sel. If you think about it, that makes total sense: how could you create some hardware that magically appears and disappears depending on the value of some input? You can't. That is why you are getting your error.
You need to remove the assigns, because while it is legal to have an assign inside an always block, it means something weird. Never do it.
I have been working on a program that basically used brute force to work backward to find a method using a given set of operations to reach the given number. So, for example, if I gave in a set of operations +5,-7,*10,/3, and a given number say 100(*this example probably won't come up with a solution), and also a given max amount of moves to solve (let's say 8), it will attempt to come up with a use of these operations to get to 100. This part works using a single thread which I have tested in an application.
However, I wanted it to be faster and I came to multithreading. I have worked a long time to even get the lambda function to work, and after some serious debugging have realized that the solution "combo" is technically found. However, before it is tested, it is changed. I wasn't sure how this was possible considering the fact that I had thought that each thread was given its own copy of the lambda function and its variables to use.
In summary, the program starts off by parsing the information, then passes the information which is divided by the parser as paramaters into the array of an operation object(somewhat of a functor). It then uses an algorithm which generated combinations which are then executed by the operation objects. The algorithm, in simplicity, takes in the amount of operations, assigns it to a char value(each char value corresponds to an operation), then outputs a char value. It generates all possible combinations.
That is a summary of how my program works. Everything seems to be working fine and in order other than two things. There is another error which I have not added to the title because there is a way to fix it, but I am curious about alternatives. This way is also probably not good for my computer.
So, going back to the problem with the lambda expression inputted with the thread as seen is with what I saw using breakpoints in the debugger. It appeared that both threads were not generating individual combos, but more rather properly switching between the first number, but alternating combos. So, it would go 1111, 2211, rather than generating 1111, 2111.(these are generated as the previous paragraph showed, but they are done a char at a time, combined using a stringstream), but once they got out of the loop that filled the combo up, combos would get lost. It would randomly switch between the two and never test the correct combo because combinations seemed to get scrambled randomly. This I realized must have something to do with race conditions and mutual exclusion. I had thought I had avoided it all by not changing any variables changed from outside the lambda expression, but it appears like both threads are using the same lambda expression.
I want to know why this occurs, and how to make it so that I can say create an array of these expressions and assign each thread its own, or something similar to that which avoids having to deal with mutual exclusion as a whole.
Now, the other problem happens when I at the end delete my array of operation objects. The code which assigns them and the deleting code is shown below.
operation *operations[get<0>(functions)];
for (int i = 0; i < get<0>(functions); i++)
{
//creates a new object for each operation in the array and sets it to the corresponding parameter
operations[i] = new operation(parameterStrings[i]);
}
delete[] operations;
The get<0>(functions) is where the amount of functions is stored in a tuple and is the number of objects to be stored in an array. The paramterStrings is a vector in which the strings used as parameters for the constructor of the class are stored. This code results in an "Exception trace/breakpoint trap." If I use "*operations" instead I get a segmentation fault in the file where the class is defined, the first line where it says "class operation." The alternative is just to comment out the delete part, but I am pretty sure that it would be a bad idea to do so, considering the fact that it is created using the "new" operator and might cause memory leaks.
Below is the code for the lambda expression and where the corresponding code for the creation of threads. I readded code inside the lambda expression so it could be looked into to find possible causes for race conditions.
auto threadLambda = [&](int thread, char *letters, operation **operations, int beginNumber) {
int i, entry[len];
bool successfulComboFound = false;
stringstream output;
int outputNum;
for (i = 0; i < len; i++)
{
entry[i] = 0;
}
do
{
for (i = 0; i < len; i++)
{
if (i == 0)
{
output << beginNumber;
}
char numSelect = *letters + (entry[i]);
output << numSelect;
}
outputNum = stoll(output.str());
if (outputNum == 23513511)
{
cout << "strange";
}
if (outputNum != 0)
{
tuple<int, bool> outputTuple;
int previousValue = initValue;
for (int g = 0; g <= (output.str()).length(); g++)
{
operation *copyOfOperation = (operations[((int)(output.str()[g])) - 49]);
//cout << copyOfOperation->inputtedValue;
outputTuple = (*operations)->doOperation(previousValue);
previousValue = get<0>(outputTuple);
if (get<1>(outputTuple) == false)
{
break;
}
debugCheck[thread - 1] = debugCheck[thread - 1] + 1;
if (previousValue == goalValue)
{
movesToSolve = g + 1;
winCombo = outputNum;
successfulComboFound = true;
break;
}
}
//cout << output.str() << ' ';
}
if (successfulComboFound == true)
{
break;
}
output.str("0");
for (i = 0; i < len && ++entry[i] == nbletters; i++)
entry[i] = 0;
} while (i < len);
if (successfulComboFound == true)
{
comboFoundGlobal = true;
finishedThreads.push_back(true);
}
else
{
finishedThreads.push_back(true);
}
};
Threads created here :
thread *threadArray[numberOfThreads];
for (int f = 0; f < numberOfThreads; f++)
{
threadArray[f] = new thread(threadLambda, f + 1, lettersPointer, operationsPointer, ((int)(workingBeginOperations[f])) - 48);
}
If any more of the code is needed to help solve the problem, please let me know and I will edit the post to add the code. Thanks in advance for all of your help.
Your lambda object captures its arguments by reference [&], so each copy of the lambda used by a thread references the same shared objects, and so various threads race and clobber each other.
This is assuming things like movesToSolve and winCombo come from captures (it is not clear from the code, but it seems like it). winCombo is updated when a successful result is found, but another thread might immediately overwrite it right after.
So every thread is using the same data, data races abound.
You want to ensure that your lambda works only on two three types of data:
Private data
Shared, constant data
Properly synchronized mutable shared data
Generally you want to have almost everything in category 1 and 2, with as little as possible in category 3.
Category 1 is the easiest, since you can use e.g., local variables within the lambda function, or captured-by-value variables if you ensure a different lambda instance is passed to each thread.
For category 2, you can use const to ensure the relevant data isn't modified.
Finally you may need some shared global state, e.g., to indicate that a value is found. One option would be something like a single std::atomic<Result *> where when any thread finds a result, they create a new Result object and atomically compare-and-swap it into the globally visible result pointer. Other threads check this pointer for null in their run loop to see if they should bail out early (I assume that's what you want: for all threads to finish if any thread finds a result).
A more idiomatic way would be to use std::promise.
I'm working on a university assignment wherein I have to re-create the classic Frogger game. Having trouble with tyre movement.
for (int tZ = 0; tZ < kTyreColumnLength; tZ++)
{
for (int tX = 0; tX < kTyreRowLength; tX++)
{
eachTyre = tX + tZ;
tyre[eachTyre] = tyreMesh->CreateModel(0, -2.50, 0);
tyre[eachTyre]->Scale(10);
tyre[eachTyre]->SetX(tyreXs[tX]);
tyre[eachTyre]->SetZ(tyreZs[tZ]);
if (tZ % 2 == 0)
{
tyreMovingLeft[eachTyre];
}
}
}
Basically, the way I'm drawing my tyres is through nested for loops. The inner loop draws3 tyres, and is repeated for each row (outer loop)
I'm then trying to assign each "even" row tyre, a Boolean to track its direction.
tZ % 2 ==0 IS correctly resolving to true/false each time the outer loop iterates, the debugger says the condition IS being met, but it's just never executing.
You never actually performed an assignment, you just indexed your array.
tyreMovingLeft[eachTyre];
You probably meant
tyreMovingLeft[eachTyre] = true;
Thr issue is that the inner block doesn’t have any effect:
tyreMovingLeft[eachTyre];
So it's optimized out by compiler. Didn't yoy mean some assignment or passing the result to some function?
I'm in a for loop in C++ and i want an "if" clause inside of it to disappear in the next iteration (for the sake of performance) after it checks the value as true once. Is that possible in C++ or in any other language?
There is no magic to change to code dynamically. Executing an if clause in a loop is probably not super-expensive if the if condition is cheap to execute.
If the condition is expensive to evaluate, you may want to protect it with an extra boolean variable:
bool mustCheck = true;
size_t const n = ...; // number of iterations
for (size_t i = 0; i < n; ++i) {
if (mustCheck && theExpensiveCheck(...)) {
mustCheck = false; // turn off the check now
....
}
...
}
If the goal is to execute the check on the first iteration only, you could test if the loop index is 0:
for (size_t i = 0; i < n; ++i) {
if (i == 0 && theExpensiveCheck(...)) {
....
}
...
}
Another option that does not have an if inside the loop is to pull out the if completely, and execute it before the loop if the loop has at least one iteration:
size_t const n = ...; // number of iterations
if (n > 0) {
// do check and execute loop body for first item
if (theExpensiveCheck()) {
....
}
}
// start regular loop, starting at index 1
for (size_t i = 1; i < n; ++i) {
// execute loop body for other items
...
}
The modifications above add extra complexity (and thus potential bugs) to your code. I would recommend to not perform any of these modifications if it's unclear whether there actually is a perform problem with the loop or the if condition. Often enough, applying the above modifications will not result in substantial performance gains, but clearly it depends on the if condition.
Compilers nowadays also provide several powerful loop optimization techniques, so you should make sure you're compiling with all these optimizations turned on.
This is not possible in C++. Once it is compiled, that's it. But, you shouldn't worry about checking a value once. The performance impact is insignificant.
I suppose if the value check was pretty involved (ie more than simple checking if it is T or F), you could add some sort of flag to check first and then skip the rest of the check if it is true. This obviously requires its own check/assignment and is most likely not worth doing.
I'm writing some code to do bitmap blending and my function has a lot of options for it. I decided to use switch to handle those options, but then I needed to either put switch inside a loop (I read that it affects performance) or to assign loop for each switch case (makes code way too big). I decided to do this using third way (see below):
/* When I need to use static value */
BYTE *pointerToValue = (BYTE*)&blendData.primaryValue;
BYTE **pointerToReference = &pointerToValue;
*pointerToReference = *pointerToReference - 3;
/* When I need srcLine's 4th value (where srcLine is a pointer to BYTE array) */
BYTE **pointerToReference = &srcLine;
while (destY2 < destY1) {
destLine = destPixelArray + (destBytesPerLine * destY2++) + (destX1 * destInc);
srcLine = srcPixelArray + (srcBytesPerLine * srcY2++) + (srcX1 * srcInc);
for (LONG x = destX1; x < destX2; x++, destLine += destInc, srcLine += srcInc) {
BYTE neededValue = *(*pointerToReference + 3); //not yet implemented
destLine[0] = srcLine[0];
destLine[1] = srcLine[1];
destLine[2] = srcLine[2];
if (diffInc == BOTH_ARE_32_BIT)
destLine[3] = srcLine[3];
}
}
Sometimes I might need to use srcLine[3] or blendData.primaryValue. srcLine[3] can be accessed easily with *(*pointerToReference + 3), however to access blendData.primaryValue I need to reduce pointer by 3 in order to keep the same expression (*(*pointerToReference + 3)).
So here are my questions:
Is it safe to set pointer out of its memory range if later it is
going to brought back?
I'm 100% sure that it won't be used when it's out of range, but can
I be sure that it won't cause any kind of access violation?
Maybe there is some kind of similar alternative to use one variable
to capture a value of srcLine[3] or blendData.primaryValue
without if(), like it's done in my code sample?
Because of #2, no usage, the answer to #1 is yes, it is perfectly safe. Because of #1, then, there is no need for #3. :-)
An access violation could only happen if the pointer were actually used.