Intel® Quartus® Prime Software
Intel® Quartus® Prime Design Software, Design Entry, Synthesis, Simulation, Verification, Timing Analysis, System Design (Platform Designer, formerly Qsys)
16912 Discussions

Postive edge detector design

NilsLiang_WNC
Beginner
943 Views

I've met a unexpected behaviour with my design and I just can't figure it out why.

First, I did some logic to detect the postive edge of input signal. Then I use the pulse to drive output signal to 'high'.

However, I've found the when reset being toggled, the output signal will also being toggled (one pulse) when input signal remains 'low'. 

 

Do you have any idea if there is any casue could lead this situation?

 

The figure below is the waveform generated by SignalTap.

NilsLiang_WNC_0-1671429450034.jpeg

I've also attached my source code if you need it. 

 

----- Source code----

 

// signal in positive edge detect

always @ (posedge clock) begin

    if(!reset)

    signal_in_r     <= 1'b0;

    else  

    signal_in_r     <= signal_in;

end

 

wire signal_in_pulse;

assign signal_in_pulse = signal_in & ~signal_in_r;

 

 

// signal out logic

reg signal_out;

 

always @ (posedge clock) begin

    if(!reset) begin 

        signal_out      <= 1'b0;

 

    end else if (signal_in_pulse) begin 

        signal_out      <= 1'b1;

    end     

end

 

----- Source code----

 

0 Kudos
7 Replies
FvM
Honored Contributor I
928 Views

Hard to decide without seeing the full test design. E.g. what is source of signal_in, what is SignalTap aquisition clock? 

Generally, edge detection can only reliably work, if signal_in is driven (in case of doubt already registered) in same clock domain. Is it so?
External/foreign clock domain signals should be double registered before entering the edge detector.

0 Kudos
NilsLiang_WNC
Beginner
902 Views

Thanks for your reply. 

SingalTap aquisition clock is the same as the clock registered singal_in and signal_out. 

The source of singnal_in is in another clock domain, hence I add two flops synchronizer before it enter this clock domain. 

 

I've already tried two method to fix this bug but I still haven't got a clue why this bug happen.

The first one is latch the signal_in_pulse by register instead of combinational logic.

 

----- Source code----

// signal in positive edge detect

always @ (posedge clock) begin

    if(!reset)

    signal_in_r     <= 1'b0;

   signal_in_pulse <= 1'b0;

    else  

    signal_in_r     <= signal_in;

    signal_in_pulse  <= signal_in & ~signal_in_r

end

----- Source code----

 

 

The second one is set the reset as asychronous reset for these flipflops.

----- Source code----

// signal in positive edge detect

always @ (posedge clock or negedge reset) begin

    if(!reset)

    signal_in_r     <= 1'b0;

   signal_in_pulse <= 1'b0;

    else  

    signal_in_r     <= signal_in;

    signal_in_pulse  <= signal_in & ~signal_in_r

end

----- Source code----

0 Kudos
RichardTanSY_Intel
916 Views

Have you try to simulate the design to check the design functionality?

Does the clock toggle correctly in the signal tap?

Sharing the full design may help to further understand the problem.


Best Regards,

Richard Tan


p/s: If any answer from the community or Intel Support are helpful, please feel free to give best answer or rate 4/5 survey.


0 Kudos
FvM
Honored Contributor I
895 Views

Hello,

we would save many follow-up questions if you had revealed the test design from the start.

After Signal Tap sample clock is specified and we know that you registered signal_in, how about the source of reset? Are we sure that Signal Tap clock is continuously running before, during and after reset?

Do you get any compiler warnings about ignored register reset levels?

Regards

Frank

0 Kudos
RichardTanSY_Intel
869 Views

Please help to share the .qar design file (you can do this by Project menu -> Archive Project ) so we can further investigate.


Best Regards,

Richard Tan


0 Kudos
RichardTanSY_Intel
844 Views

Any update on this?

Best Regards,

Richard Tan

p/s: Please be informed that there will be delay in response in the following week due to holiday season.


0 Kudos
RichardTanSY_Intel
774 Views

Wishing you a Happy New Year 2023!

As we do not receive any response from you on the previous question/reply/answer that we have provided. I now transition this thread to community support. Please login to ‘https://supporttickets.intel.com’, view details of the desire request, and post a feed/response within the next 15 days to allow me to continue to support you. After 15 days, this thread will be transitioned to community support. The community users will be able to help you on your follow-up questions.


Thank you.


Best Regards,

Richard Tan


p/s: If any answer from the community or Intel Support are helpful, please feel free to give best answer or rate 4/5 survey.



0 Kudos
Reply