cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Observer
Observer
481 Views
Registered: ‎03-20-2012

What seems to be an incorrect answer from FPGA for some arithmetic sums

So I have this function for calculating tcp checksums:

function [15:0] add_hdr_checksum;

input [15:0] value1;
input [15:0] value2;
logic [16:0] sum_st1;
begin
sum_st1 = value1 + value2;
add_hdr_checksum = sum_st1[15:0] + sum_st1[16];
end
endfunction

and am using it here:
st1_1_p0 = network_params::add_hdr_checksum({time_gen_csum[15:8],time_gen_csum[7:0]}, {transact_time_csum[15:8],transact_time_csum[7:0]});

I can see from an ila capture that both time_gen_csum[15:0] and transact_time_csum[15:0] are 16'h6e34, however the answer that is coming back for st1_1_p0 is 16'hcc68 when it should be 0xdc68.  I don't understand why this is consistently happening.  Anyone got any ideas - seems to be off by 0x1000 which is weird.


0 Kudos
6 Replies
Highlighted
Teacher
Teacher
466 Views
Registered: ‎07-09-2009

signed v un signed ?

( try VHDL :-> ))
<== If this was helpful, please feel free to give Kudos, and close if it answers your question ==>
0 Kudos
Highlighted
Observer
Observer
460 Views
Registered: ‎03-20-2012

The answer doesnt make sense even if interpreted as signed values and I’ve checked the same calc in sim too and it gives the right answer.  I think it must be a weird tool bug. 

0 Kudos
Highlighted
Teacher
Teacher
457 Views
Registered: ‎07-09-2009

simulation is very different to ila,
have you fully constrained design, does it meet timing ?
are you crossing clock boundaries,

in simulation, none of this is relevant, as its all single delta timed.

do you want to post full code ?
<== If this was helpful, please feel free to give Kudos, and close if it answers your question ==>
0 Kudos
Highlighted
Observer
Observer
454 Views
Registered: ‎03-20-2012

Yeah, it’s all the same clock domain, meets timing, etc. 


 

0 Kudos
Highlighted
Scholar
Scholar
384 Views
Registered: ‎09-16-2009

I agree with your assessment of the problem - your RTL code is fine, as confirmed by the simulation.  (I'm wondering why you're concatenating the seperate bytes of the wider variable for the function arguments, but I suspect it's probably due to code simplification for this post.  In either case, it's ok code wise, just looks weird...)

Can you double check your ILA connections?  (How did you hook up the the ILA?)  Is bit 12 Stuck at 0 on the bench?  Can you try and capture outputs for different function arguments?

Not that I think it matters, but how is st1_1_p0 declared?

Regards,

Mark

0 Kudos
Highlighted
Observer
Observer
365 Views
Registered: ‎03-20-2012

So the reason I'm concatenating the seperate bytes is cause I am auto-generating the code and its a quirk of the way I'm doing it.  st1_1_p0 is declared as a 16-bit reg.  To be more specific about the ILA, I'm not actually using ILA but my own capture buffer (means I can capture stuff when I don't have a JTAG connection on board) which I tested in sim to check that it captured the data correctly.  I suspect the way I am generating the transact_time_csum is the root of the problem as I changed it from this:

wire [31:0] tt_offset_no = (fix_messages_pkg::header_length+fix_messages_pkg::new_order_transact_time_start);


.time_gen_csum (all_time_gen_csum[order_session_exp]),
.time_gen_fix_csum (all_time_gen_fix_csum[order_session_exp]),
.transact_time_csum (tt_offset_no[0]?all_time_gen_odd_csum[order_session_exp]:all_time_gen_even_csum[order_session_exp]),

to using a generate statement which now gives me the correct answer.  All very strange.

0 Kudos