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.

Register Log in

sequential logic breaks down, possibly glitches?

Status
Not open for further replies.
B

bravoegg

Member level 2
Joined
Mar 28, 2016
Messages
51
Helped
1
Reputation
2
Reaction score
1
Trophy points
8
Activity points
501
Code: 
always@(posedge clk)begin
    data1512_vld_r1 <= data1512_vld;
    tps_vld_r1 = tps_vld;
end

//cmlk_r, ram1512's data aligned to wr_1705
always@(posedge clk)begin
    wr_1705 <= pilot_vld_r2 | data1512_vld_r1 | tps_vld_r1;
end

when either pilot_vld_r2 or data1512_vld_r1 or tps_vld_r1 is '1', wr_1705 turns to '1' the next clock cycle. But the simulation turns out wrong.
1.png

How could it be wrong...it's clearly that tps_vld_r1 is '1', then wr_1705 MUST be '1' next clock cycle...



to furthur test the code, I add the following code:
Code: 
always@(posedge clk)begin
    if(tps_vld_r1)
        luck <= 1;
    else
        luck <= 0;
end

assign   more = tps_vld_r1 || pilot_vld_r2 || data1512_vld_r1;

33.png

it's extremely puzzling that, at the red arrows in the above pictures, signal "luck" behaves completely differently than I thought.

Please help...
 
Last edited:

You are having a scheduling problem, would have to see the structure of your code (where each signal is generated if there is hierarchy involved) and how each signal is generated.

Clock used to generate luck (or tps_vld_r1) is likely being reassigned in another place in the code and transitions from that reassigned clock are not in the same scheduling cycle as the clock for luck. Hence you see the leading edge of the signal getting captured by the clock.
 

I sovled the problem by changing "=" to "<=" in the following code:
Code: 
always@(posedge clk)begin
    data1512_vld_r1 <= data1512_vld;
    [COLOR="#FF0000"]tps_vld_r1 = tps_vld;[/COLOR]
end

it's still puzzling. tps_vld_r1 is a blocking assignment, and in the simulation wave it's delayed by 1 clock.
In the pictures in the 1st post, the signal "luck" seems not recognizing it...is there actually a hardware structure corresponding to blocking assignment?

Can't believe I missed typing "<="...it costed me a whole day!

Found this post very helpful:
https://stackoverflow.com/questions...ocking-vs-non-blocking-assignments-in-verilog

Yet still not understanding why signal "luck" doesn't go up when tps_vld_r1 is '1'...
 
Last edited:

Do not get in the habit of using blocking assignments in edge triggered always blocks they can result in synthesis simulation mismatches, if there are any dependancies on the output of the blocking assignment.

The reason I gave is the source of the problem, but sure go ahead and mask the real problem. Besides I don't know Verilog very well, I've only been using it for every design since 2002, so I'm a total novice.
 

The code in post #1 is a good example how blocking assignments can generate simulation mismatch issues that you won't expect at first sight. You know well how the hardware behaves and don't understand that scheduling rules can cause a different simulation result.

In this case, the result depends on the unknown scheduling order of always blocks. A non blocking assignment guarantees that tps_vld_r1 is assigned after all clk dependent always blocks have been processed.
 

thank you. I'll pay more attention to it...
 

Status
Not open for further replies.

Similar threads

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top