So I'm trying to design Seven Segment Decoder. When Button is pressed at 110, then the LED Display should display 1 digit hex number: 0,1,2,3,4,5,6,7,8,9,A,B,C,D,E,F. But, when Button is pressed at 101, then the LED Display should display 1 digit decimal number: 0,1,2,3,4,5,6,7,8,9.
This is my Warnings:
Xst:737 - Found 1-bit latch for signal <out<4>>. Latches may be generated from incomplete case or if statements. We do not recommend the use of latches in FPGA/CPLD designs, as they may lead to timing problems.
Xst:737 - Found 1-bit latch for signal <out<5>>. Latches may be generated from incomplete case or if statements. We do not recommend the use of latches in FPGA/CPLD designs, as they may lead to timing problems.
Xst:737 - Found 1-bit latch for signal <out<3>>. Latches may be generated from incomplete case or if statements. We do not recommend the use of latches in FPGA/CPLD designs, as they may lead to timing problems.
Xst:737 - Found 1-bit latch for signal <out<2>>. Latches may be generated from incomplete case or if statements. We do not recommend the use of latches in FPGA/CPLD designs, as they may lead to timing problems.
Xst:737 - Found 1-bit latch for signal <out<1>>. Latches may be generated from incomplete case or if statements. We do not recommend the use of latches in FPGA/CPLD designs, as they may lead to timing problems.
Xst:737 - Found 1-bit latch for signal <out<0>>. Latches may be generated from incomplete case or if statements. We do not recommend the use of latches in FPGA/CPLD designs, as they may lead to timing problems.
Xst:737 - Found 1-bit latch for signal <out<6>>. Latches may be generated from incomplete case or if statements. We do not recommend the use of latches in FPGA/CPLD designs, as they may lead to timing problems.
Xst:2169 - HDL ADVISOR - Some clock signals were not automatically buffered by XST with BUFG/BUFR resources. Please use the buffer_type constraint in order to insert these buffers to the clock signals to help prevent skew problems.
This is my code using Xilinx design tools:
module hex_sch(out, in, button);
output reg [6:0] out;
input [3:0] in;
input [2:0] button;
// Low active signal should activate the LEDs
always #(button or in)
begin
if (button == 3'b110) begin
case (in)
//Output format gfedcba
4'h0: out <= 7'b1000000;
4'h1: out <= 7'b1111001;
4'h2: out <= 7'b0100100;
4'h3: out <= 7'b0110000;
4'h4: out <= 7'b0011001;
4'h5: out <= 7'b0010010;
4'h6: out <= 7'b0000010;
4'h7: out <= 7'b1111000;
4'h8: out <= 7'b0000000;
4'h9: out <= 7'b0011000;
4'hA: out <= 7'b0001000;
4'hB: out <= 7'b0000011;
4'hC: out <= 7'b1000110;
4'hD: out <= 7'b0100001;
4'hE: out <= 7'b0000110;
4'hF: out <= 7'b0001110;
default: out <= 7'bx;
endcase
end
else if (button == 3'b101) begin
case (in)
//Output format abcdefg
4'd0: out <= 7'b1000000;
4'd1: out <= 7'b1111001;
4'd2: out <= 7'b0100100;
4'd3: out <= 7'b0110000;
4'd4: out <= 7'b0011001;
4'd5: out <= 7'b0010010;
4'd6: out <= 7'b0000010;
4'd7: out <= 7'b1111000;
4'd8: out <= 7'b0000000;
4'd9: out <= 7'b0011000;
default out <= 7'bx;
endcase
end
end
endmodule
In order to remove those warnings you must set a value for out in every possible in and button.
otherwise you will get a latch.
In your code you do not cover all posibilities for button input - you only cover 110 and 101.
An easy way to cover all posibilities in your code may be:
... // your module definition as is
// Low active signal should activate the LEDs
always #(button or in)
begin
if (button == 3'b110) begin
case (in)
//Output format gfedcba
... // your case statement as is
endcase
end
else if (button == 3'b101) begin
case (in)
... // your case statement as is
endcase
end
else begin
out <= 7'b1;
end
end endmodule
This way, when button is different then 110 or 101, it will show blank.
Related
Case statement in verilog. I don't understand how this code works
if(cpld_cs & cpld_we)
begin
case(ifc_a27_31)
`RSTCON1: begin
sw_rst_r <= ifc_ad0_7[0];
ddr_rst_r <= ifc_ad0_7[1];
ec1_rst_r <= ifc_ad0_7[2];
ec2_rst_r <= ifc_ad0_7[3];
xgt1_rst_r <= ifc_ad0_7[6];
xgt2_rst_r <= ifc_ad0_7[7];
Just look up documentation. I am no verilog expert but checking documentation you can get that
case(ifc_a27_31)
`RSTCON1: begin
is just simple case where if value of ifc_a27_31 is RSTCON1 then commands
sw_rst_r <= ifc_ad0_7[0];
ddr_rst_r <= ifc_ad0_7[1];
ec1_rst_r <= ifc_ad0_7[2];
ec2_rst_r <= ifc_ad0_7[3];
xgt1_rst_r <= ifc_ad0_7[6];
xgt2_rst_r <= ifc_ad0_7[7];
are getting executed.
And of course
sw_rst_r <= ifc_ad0_7[0];
is just non-blocking assignment.
Information I took from Case Statement and What is the difference between = and <= in verilog?
verilog case syntax consists of a case expression or selector expression (ifc_a37_31) and case items with label expression (macro RSTCON1 in your case) and action items. When afr_a37_31 matches the value of the macro, the statements in the begin .. end block will be executed sequentially.
The case statement might have multiple case items, the first one which matches the selector will be active and its block will be executed.
There is also a default clause which will get executed if no matches are found.
Now in your case it looks like this is a part of a latch or a flop definition, since 'non-blocking' assignments are used there. It is ok to miss some conditions and/or the default statement in such a case.
you might see other variants of the case statement, like casex or casez. Syntax for all of them is similar, the difference is in the ways the selector is compared to the label.
in system verilog there are more, like unique of priority cases or case inside.
So, you need to go through a tutorial to get more information about all this.
For example for:
type PERSONCV is
record
name: String ( 1..4 );
age: Integer;
cvtext: String ( 1..2000 );
end record;
N: constant := 40000;
persons : array ( 1..N ) of PERSONCV;
function jobcandidate return Boolean is
iscandidate: Boolean := False;
begin
for p of persons loop -- what code is generated for this?
if p.age >= 18 then
iscandidate := true;
exit;
end if;
end loop;
return iscandidate;
end;
In C/C++ the loop part would typically be:
PERSONCV * p; // address pointer
int k = 0;
while ( k < N )
{
p = &persons [ k ]; // pointer to k'th record
if ( p->age >= 18 )...
...
k++ ;
}
I have read that Ada uses Value semantics for records.
Does the Ada loop above copy the k'th record to loop variable p?
e.g. like this is in C/C++ :
PERSONCV p; // object/variable
int k = 0;
while ( k < N )
{
memcpy ( &p, &persons [ k ], sizeof ( PERSONCV ) ); // copies k'th elem
if ( p.age >= 18 )...
...
k++ ;
}
Assuming you are using GNAT, there are two avenues of investigation.
The switch -gnatG will regenerate an Ada-like representation of what the front end of the compiler is going to pass to the back end (before any optimisations). In this case, I see
function resander__jobcandidate return boolean is
iscandidate : boolean := false;
L_1 : label
begin
L_1 : for C8b in 1 .. 40000 loop
p : resander__personcv renames resander__persons (C8b);
if p.age >= 18 then
iscandidate := true;
exit;
end if;
end loop L_1;
return iscandidate;
end resander__jobcandidate;
so the question is, how does renames get translated? Given that the record size is 2008 bytes, the chances of the compiler generating a copy is pretty much zero.
The second investigatory approach is to keep the assembly code that the compiler normally emits to the assembler and then deletes, using the switch -S. This confirms that the code generated is like your first C++ version (for macOS).
As an interesting sidelight, Ada 2012 allows an alternate implementation of jobcandidate:
function jobcandidate2 return Boolean is
(for some p of persons => p.age >= 18);
which generates identical code.
I suspect that what you have read about Ada is wrong, and probably worse, is encouraging you to think about Ada in the wrong way.
Ada's intent is to encourage thinking in the problem domain, i.e. to specify what should happen, rather than thinking in the solution domain, i.e. to implement the fine details of exactly how.
So here the intent is to loop over all Persons, exit returning True on meeting the first over 18, otherwise return False.
And that's it.
By and large Ada mandates nothing about the details of how it's done, provided those semantics are satisfied.
Then, the intent is, you just expect the compiler to do the right thing.
Now an individual compiler may choose one implementation over another - or may switch between implementations according to optimisation heuristics, taking into account which CPU it's compiling for, as well as the size of the objects (will they fit into a register?) etc.
You could imagine a CPU with many registers, where a single cache line read makes the copy implementation faster than operating in place (especially if there are no modifications to write back to P's contents), or other target CPUs where the reverse was true. Why would you want to stop the compiler picking the better implementation?
A good example of this is Ada's approach to parameter passing to subprograms - name, value or reference semantics really don't apply - instead, you specify the parameter passing mode - in, out, or in out describing the information flow to (or from) the subprogram. Intuitive, provides semantics that can be more rigorously checked, and leaves the compiler free to pick the best (fastest, smallest, depending on your goal) implementation that correctly obeys those semantics.
Now it would be possible for a specific Ada compiler to make poor choices, and 30 years ago when computers were barely big enough to run an Ada compiler at all, you might well have found performance compromised for simplicity in early releases of a compiler.
But we have thirty more years of compiler development now, running on more powerful computers. So, today, I'd expect the compiler to normally make the best choice. And if you find a specific compiler missing out on performance optimisations, file an enhancement request. Ada compilers aren't perfect, just like any other compiler.
In this specific example, I'd normally expect P to be a cursor into the array, and operations to happen in-place, i.e. reference semantics. Or possibly a hybrid between forms, where one memory fetch into a register serves several operations, like a partial form of value semantics.
If your interest is academic, you can easily look at the assembly output from whatever compiler you're using and find out. Or write all three versions above and benchmark them.
Using a current compiler (GCC 7.0.0), I have copied your source to both an Ada program and a C++ program, using std:array<char, 4> etc. corresponding to String( 1..4 ) etc. Switches were simply -O2 for C++, and -O2 -gnatp for Ada, so as to use comparable settings regarding checked access to array elements, etc.
These are the results for jobcandidate:
C++:
movl $_ZN15Loop_Over_Array7personsE+4, %eax
movl $_ZN15Loop_Over_Array7personsE+80320004, %edx
jmp .L3
.L8:
addq $2008, %rax
cmpq %rdx, %rax
je .L7
.L3:
cmpl $17, (%rax)
jle .L8
movl $1, %eax
ret
.L7:
xorl %eax, %eax
ret
Ada:
movl $1, %eax
jmp .L5
.L10:
addq $1, %rax
cmpq $40001, %rax
je .L9
.L5:
imulq $2008, %rax, %rdx
cmpl $17, loop_over_array__persons-2004(%rdx)
jle .L10
movl $1, %eax
ret
.L9:
xorl %eax, %eax
ret
One difference I see is in how either implementation uses %edx and %eax; for going form one element of the array to the next, and testing whether the end has been reached. Ada seems to imulq the element size to set the cursor, C++ seems to addq it to the pointer.
I haven't measured performance.
Following is a sample code that uses case statement and always #(*) block. I don't get how the always block is triggered and why it works even when x is declared as wire.
wire [2:0] x = 0;
always #(*)
begin
case (1'b1)
x[0]: $display("Bit 0 : %0d",x[0]);
x[1]: $display("Bit 1 : %0d",x[1]);
x[2]: $display("Bit 2 : %0d",x[2]);
default: $display("In default case");
endcase
end
Any help is appreciated.
Thanks.
As we know, reg can be driven by a wire, we can definitely use a wire as the right hand side of the assignment in any procedural block.
Here, your code checks which bit of x is 1'b1 (of course giving priority to zeroth bit). Lets say x changes to 3'b010. Then, Bit 1 shall be displayed and so on. Now, if x=3'b011 then Bit 0 is displayed since zeroth bit is checked first.
As you can see, there is no assignment to x, the procedural block only reads its value. Moreover, the system task $display also reads the value of x.
There is no change of signal value from this block. Hence, this code works fine. If, by chance, we had something like x[0] = ~x[0] instead of $display, then this code shall provide compilation issues.
More information can be found at this and this links.
Here, this always block does not assign a value to a x, but it just checks a value of x. So it's a legal use of wire.
So, the explanation to the part of your question about how always #(*) is triggered is as follows :
"Nets and variables that appear on the right-hand side of assignments, in subroutine calls, in case and conditional expressions, as an index variable on the left-hand side of assignments, or as variables in case item expressions shall all be included in always #(*)."
Ref: IEEE Std 1800-2012 Sec 9.4.2.2
As an extension of #sharvil111's answer, if your code was something like this
always #(*)
begin
case (sel)
x[0]: $display("Bit 0 : %0d",x[0]);
x[1]: $display("Bit 1 : %0d",x[1]);
x[2]: $display("Bit 2 : %0d",x[2]);
default: $display("In default case");
endcase
end
The procedural block would be triggered whenever there is a change in sel signal or x i.e. it would be equivalent to always #(sel or x).
zero <= result_i(31) OR result_i(30) OR result_i(29) OR result_i(28)
OR result_i(27) OR result_i(26) OR result_i(25) OR result_i(24)
OR result_i(23) OR result_i(22) OR result_i(21) OR result_i(20)
OR result_i(19) OR result_i(18) OR result_i(17) OR result_i(16)
OR result_i(15) OR result_i(14) OR result_i(13) OR result_i(12)
OR result_i(11) OR result_i(10) OR result_i(9) OR result_i(8)
OR result_i(7) OR result_i(6) OR result_i(5) OR result_i(4)
OR result_i(3) OR result_i(2) OR result_i(1) OR result_i(0);
How can I make this shorter?
I am assuming you are using std_logic/std_logic_vector types.
Then you can use or_reduce from ieee.std_logic_misc.
library ieee;
use ieee.std_logic_misc.or_reduce;
...
zero <= or_reduce(result_i);
Or write your own function:
function or_reduce(vector : std_logic_vector) return std_logic is
variable result : std_logic := '0';
begin
for i in vector'range loop
result := result or vector(i);
end loop
return result;
end function;
A general tip if you are just starting out with VHDL is to not forget about functions and procedures. Unlike Verilog (Without SystemVerilog) VHDL has good support for writing clean and high level code, even for synthesis, using functions and procedures. If you are doing something repetitive it is a sure sign that it should be wrapped in a function/procedure. In this case there already was a standard function ready to be used though.
You might also want to consider pipelining the or-reduction and inserting flip-flops between the stages. Maybe the 32-bit reduction that you use in your example should still run a reasonably high frequency in an FPGA device but if you are going to use more bits or target a really high frequency you might want to use an or-tree where no more than 6-8 bits are or:ed in each pipeline stage. You can still re-use the or_reduce function for the intermediate operations though.
You can achieve it with vhdl revision 2008
VHDL-2008 defines unary operators, like these:
outp <= and "11011";
outp <= xor "11011";
So in your case it would be:
zero <= or result_i;
I have a piece of code in Julia in which a solver iterates many, many times as it seeks a solution to a very complex problem. At present, I have to provide a number of iterations for the code to do, set low enough that I don't have to wait hours for the code to halt in order to save the current state, but high enough that I don't have to keep activating the code every 5 minutes.
Is there a way, with the current state of Julia (0.2), to detect a keystroke instructing the code to either end without saving (in case of problems) or end with saving? I require a method such that the code will continue unimpeded unless such a keystroke event has happened, and that will interrupt on any iteration.
Essentially, I'm looking for a command that will read in a keystroke if a keystroke has occurred (while the terminal that Julia is running in has focus), and run certain code if the keystroke was a specific key. Is this possible?
Note: I'm running julia via xfce4-terminal on Xubuntu, in case that affects the required command.
You can you an asynchronous task to read from STDIN, blocking until something is available to read. In your main computation task, when you are ready to check for input, you can call yield() to lend a few cycles to the read task, and check a global to see if anything was read. For example:
input = ""
#async while true
global input = readavailable(STDIN)
end
for i = 1:10^6 # some long-running computation
if isempty(input)
yield()
else
println("GOT INPUT: ", input)
global input = ""
end
# do some other work here
end
Note that, since this is cooperative multithreading, there are no race conditions.
You may be able to achieve this by sending an interrupt (Ctrl+C). This should work from the REPL without any changes to your code – if you want to implement saving you'll have to handle the resulting InterruptException and prompt the user.
I had some trouble with the answer from steven-g-johnson, and ended up using a Channel to communicate between tasks:
function kbtest()
# allow 'q' pressed on the keyboard to break the loop
quitChannel = Channel(10)
#async while true
kb_input = readline(stdin)
if contains(lowercase(kb_input), "q")
put!(quitChannel, 1)
break
end
end
start_time = time()
while (time() - start_time) < 10
if isready(quitChannel)
break
end
println("in loop # $(time() - start_time)")
sleep(1)
end
println("out of loop # $(time() - start_time)")
end
This requires pressing and then , which works well for my needs.