irshan
Joined: 01 Jul 2006
Posts: 22
Helped: 1
|
 22 Dec 2008 6:50 case statement getting encoded using one-hot |
|
|
|
|
hi
i have required 128 bit input for testing of a core, i am willing to give input from computer using seril port, to accomplish my task i have designed the sate machine which buffer 8-bit data from serial to buffer, and provide 128 bit to my core on reception of all 128 bit form seial port, the core is given as unders and warning which i have recieved on it's synthesis is followed by the core, ur help required to modify the core so that it function properly ,
module buffer(
input mclk , // Master clock
input arst_n , // Asynchronous reset (active low)
input [0:7] RxD_data ,
input RxD_data_ready ,
output reg [0:127] input_data , // Supplied datato core
output reg input_valid
);
reg [3:0]Byte_count=4'd0;
reg [2:0] currentstate,nextstate;
parameter [2:0]IDLE = 3'b001 ;
parameter [2:0]shift_reg = 3'b010 ;
parameter [2:0]input_data_valid = 3'b100 ;
always@(posedge mclk or negedge arst_n)
begin
if(!arst_n)
currentstate<=IDLE;
else
currentstate<=nextstate;
end
always@*
begin
case(currentstate)
IDLE:
begin
if(!arst_n)
begin
Byte_count<=4'd0;
end
else
nextstate<=shift_reg;
end
shift_reg:
begin
if(RxD_data_ready)
case(Byte_count)
4'b0000:
input_data[0:7]<=RxD_data;
4'b0001:
input_data[8:15 ]<=RxD_data;
4'b0010:
input_data[16:23 ]<=RxD_data;
4'b0011:
input_data[24:31]<=RxD_data;
4'b0100:
input_data[ 32:39]<=RxD_data;
4'b0101:
input_data[40:47]<=RxD_data;
4'b0110:
input_data[48:55]<=RxD_data;
4'b0111:
input_data[56:63]<=RxD_data;
4'b1000:
input_data[64:71]<=RxD_data;
4'b1001:
input_data[72:79]<=RxD_data;
4'b1010:
input_data[80:87 ]<=RxD_data;
4'b1011:
input_data[88:95 ]<=RxD_data;
4'b1100:
input_data[96:103]<=RxD_data;
4'b1101:
input_data[104:111]<=RxD_data;
4'b1110:
input_data[112:119]<=RxD_data;
4'b1111:
input_data[120:127]<=RxD_data;
default:
input_data[0:127]<=128'd z;
endcase
Byte_count <= Byte_count + 1'b1 ;
nextstate<=input_data_valid;
end
input_data_valid:
begin
if(Byte_count==15)
begin
inputdata_valid<=1’b1;
else if(!arst_n)
nextstate<=IDLE;
else
nextstate<=shift_reg;
end
default nextstate<=IDLE;
endcase
end
endmodule
Warnings
Xst:737 - Found 1-bit latch for signal <input_data_1>.
.
.
.
Xst:737 - Found 1-bit latch for signal <input_data_127>.
Xst:2117 - HDL ADVISOR - Mux Selector <currentstate> of Case statement line 48 was re-encoded using one-hot encoding. The case statement will be optimized (default statement optimization), but this optimization may lead to design initialization problems. To ensure the design works safely, you can:
- add an 'INIT' attribute on signal <currentstate> (optimization is then done without any risk)
- use the attribute 'signal_encoding user' to avoid onehot optimization
- use the attribute 'safe_implementation yes' to force XST to perform a safe (but less efficient) optimization
Xst:2734 - Property "use_dsp48" is not applicable for this technology.
Xst:737 - Found 4-bit latch for signal <Byte_count>.
Xst:2371 - HDL ADVISOR - Logic functions respectively driving the data and gate enable inputs of this latch share common terms. This situation will potentially lead to setup/hold violations and, as a result, to simulation problems. This situation may come from an incomplete case statement (all selector values are not covered). You should carefully review if it was in your intentions to describe such a latch.
Xst:737 - Found 3-bit latch for signal <nextstate>.
Xst:2371 - HDL ADVISOR - Logic functions respectively driving the data and gate enable inputs of this latch share common terms. This situation will potentially lead to setup/hold violations and, as a result, to simulation problems. This situation may come from an incomplete case statement (all selector values are not covered). You should carefully review if it was in your intentions to describe such a latch.
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.
|
|
rberek
Joined: 23 May 2007
Posts: 65
Helped: 9
Location: Canada
|
22 Dec 2008 13:10 attribute safe_implementation |
|
|
|
|
Because of the the way you code, you are inferring latches rather than flip flops. In several if-else blocks, you do not completely specify the state of every signal.
For example, in your code snippet:
| Code: |
if(!arst_n)
begin
Byte_count<=4'd0;
end
else
nextstate<=shift_reg;
end
|
You do not mention what Byte_count is when arst_n is one, nor do you mention what nextstate is when arst_n is zero. Therefore you get latches in both signals rather than flipflops. When you have latches instantiated, the pre-synthesis simulation will rarely match the post-synthesis simulation.
r.b.
|
|
