- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
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----
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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----
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
![](/skins/images/B7BA37F9CE4B52FF7CAE1FB0388839C8/responsive_peak/images/icon_anonymous_message.png)
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page