Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

Help required in removing errors in 128 bit buffer

Status
Not open for further replies.

irshan

Junior Member level 2
Junior Member level 2
Joined
Jul 1, 2006
Messages
20
Helped
1
Reputation
2
Reaction score
0
Trophy points
1,281
Activity points
1,454
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.
 

xilinx xst 2371

In FPGA you should use flip-flops instead of latches, i.e. use posedge or negedge in every synchronous process. Using latches in FPGA design can be considered bad design practice.
 

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.
 

    irshan

    Points: 2
    Helpful Answer Positive Rating
Status
Not open for further replies.

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top