digitaljs
digitaljs copied to clipboard
tilk
Editing a Number should trigger logic
When I enter an input number, the changes do not propagate. I have to toggle a button to propogate the changes.
Here is a particular circuit that exhibits this behavior.
It is a serial comparator. Starting from the most significant bit. The input on the first stage should just be 2'b11, meaning the two values are the same, before any comparison. Instead of a constant, I have two buttons to toggle, to make the updates happen.
Here is the code.
module compare(input [1:0] previous, input a, input b, output reg [1:0] result);
wire [1:0] both; reg [1:0] bitResult; assign both= {a,b};
always @ (previous,bitResult) begin
case (previous)
2'b10 : result = 2'b10; //A is bigger
2'b01 : result = 2'b01; //B is bigger
2'b11 :
case (both)
2'b10: result = 2'b10;
2'b01: result = 2'b01;
2'b11:
case (both)
2'b10: result = 2'b10;
2'b01: result = 2'b01;
2'b11: result = 2'b11;
2'b00: result = 2'b11;
endcase
2'b00: result = 2'b11;
endcase
2'b00 : result = 2'b00;
endcase
end endmodule
module main (input previous1, input previous2, input [3:0]a, input [3:0]b, output [1:0] finalResult); reg [1:0] result0,result1, result2, result3; compare comp1 ({previous1,previous2},a[3],b[3],result3); compare comp2 (result3,a[2],b[2],result2); compare comp3(result2,a[1],b[1],result1); compare comp4(result1,a[0],b[0],finalResult);
endmodule
I'm sorry, I fail to understand your problem. Could you create a minimal testcase exhibiting the wrong behavior?
Okay, here is a much simpler bug demo. It is a serial comparitor. PREVIOUS1 and PREVIOUS2 are from the previous comparison They tell you which previous bit was larger. //was a bigger, b bigger, or the same. // 00 or 11, mean the values were the same.
If I enter data for a and b, the output does not change. If I toggle the buttons to either 00 or 11, the output does change correctly. Thank you for looking at this.
module compare (input previous1,
input previous2,
input [1:0]a,
input [1:0]b,
output reg [1:0] result);
wire [1:0] previous ;
wire [1:0] both;
assign previous = {previous1,previous2};
assign both= {a[0],b[0]};
always @ (previous,both) begin
case (previous)
2'b10 : result = 2'b10; //A is bigger
2'b01 : result = 2'b01; //B is bigger
2'b00: //a and b SAME
case (both)
2'b10: result = 2'b10;
2'b01: result = 2'b01;
2'b11: result = 2'b11;
2'b00: result = 2'b11;
endcase
2'b11 : //a and b SAME
case (both)
2'b10: result = 2'b10;
2'b01: result = 2'b01;
2'b11: result = 2'b11;
2'b00: result = 2'b11;
endcase
endcase
end
endmodule
As far as I can see, the simulation works correctly. Number input doesn't change while typing, so that potentially wrong intermediate values don't show up on the wire. Input is accepted by using ENTER or changing to another input.
You are correct, if I enter ENTER, it works.
Usually on forms I do not have to enter ENTER.
This user expected that on key up, or on clicking elsewhere on the screen, the calculation would update.
Basically it violated my expectations.
I am sure that I am not the only one who has had that problem.
This was a design decision. I didn't want incorrect signals to propagate so easily.
I suggest two ways of mitigating this problem. One, use a color or some symbol (do you have suggestions?) to clearly show that the value is not entered. Second, introduce a timeout, say one second, after which the value will be automatically entered.
Both work. Red is a warning color. Light red would be good. Particularly if it goes away after a second. It gives the user some idea of what is going on.
On further thought, leaving the data entry box should also trigger the simulation. It is a clear signal that the user is done entering that data.