#19 core dump for systemverilog

Hi ,

First thanks!!

Second, I experienced "core dump" when the sv code has bug. like "begin;" VCS did not catch this problem. :)

Matt

[Anonymous]

I did not put detail enough. Here is more detail.

My "problem" sv code
516 if (this.tcam_cfg.key_hash.exists(key_str)) begin
517 idx = this.tcam_cfg.key_hash[key_str];
518 // Only abort if in the current side of the TCAM
519 if (idx[8] == dest_core[0]) begin;
520 `uvm_info(flow.get_name(), $psprintf("%s: collision, duplicate key_hash[%s] = 0x%0x, using existing index",this.get_name(),key_str,idx), UVM_NONE );
521 abort = 1;
522 end
523 end

the second if has a extra ";" after begin

The log file showed it pop the if tag. It should not pop the if tags. it should wait until see the keyword end not ";".

findTag: Finding tag for keyword if (kind = control) at line 519
findTag: Candidate-Scope = [if,else,while,for,foreach,repeat,forever:end] under Parent-Scope = [if,else,while,for,foreach,repeat,forever:end] (Path = user_check_t
cam_duplicate_keys:if_516)
findTag: Found begin-scope identifier: if,else,while,for,foreach,repeat,forever
Pushing if(start=if,else,while,for,foreach,repeat,forever) onto scope-stack of size 2
processBlockAssocTag: Extracting current scope = if_519
Read Identifier =
processBlockAssocTag: Saw parentheses
Read Identifier = begin
Associating sequential block with current scope
Read Identifier =
processBlockAssocTag: Saw semicolon
processBlockAssocTag: Restored char ; into character-stream
Updating TagPropertySet for control with if_519
TPS_DUMP :: ID : 130 UPDATES : 0 KIND : control SCOPE : 0
TPS_DUMP :: NAME : if_519

[Vikram Khosa]

hi Matt, thanks for providing the example. Please refer to the main tracker thread -- I believe this is the same issue that Johannes ran into -- I'm pasting my reply to him below :

Johannes, I debugged your segfault -- the problem is that I was exiting
the loop (early) on encountering a semicolon within a block scope. I think
commenting out line 1112 : "loop = FALSE" inside the ";" case of
processBlockAssocTag(...) in systemverilog.c should work as a simple fix
for now (although the "clk" identifier will still not be tagged with the
implicit "reg" or "logic" type). I will need to test this a bit more
thoroughly and include it in a consolidated patch later.