SV Blog SystemVerilog Blog
Related Articles
Hopefully you’be gotten most of the clock crossing questions. If you missed them all or if you weren’t able to at least work through them with some help, then it’s very doubtful I’ll be giving a thumbs up. As I have mentioned in replies to comments, they are so essential that they must be present, at least in theory.
So at this point in the interview, I want to get a feel for design analysis skills. The following question is something that happened at #9. There was an engineer tasked with applying bug fixes from a vendor at gate level. We had their RTL, which was synthesized to gates and then we had changed RTL. The engineer was to figure out the changes and apply them at gate level as an ECO.
One of the changes that came in was very simple. It was setting a FF on an asynchronous signal, rather than resetting it. i.e.
always_ff @(posedge clk, negedge rstn) if (~rstn) dout <= '0; else dout <= din;
becomes:
always_ff @(posedge clk, negedge rstn)
if (~rstn) dout <= ‘1;
else dout <= din;
So the question becomes, How can you add digital logic around:
to make it equivalent to:
This question gives me an opportunity to see a candidate attack the problem. I answer questions as need be. What I have found is that somewhere around 25% of the candidates just get it immediately. These tend to be the ones who breeze through the whole interview. Here is what I’m looking for:
- does the proposed solution touch the reset line directly? Often people will try to use the reset to control a mux. This cannot work and it also introduces a problem and I try to see if they understand the problem. If the reset is touched, since it is asynchronous, you are now applying an asynchronous signal into a synchronous design. Although the release of the reset is synchronized (typically if done correctly), it can cause problems for other paths which might not be reset.
- does it touch the clock? Creating a derived clock is not a good thing and messes up static timing. It’s also not the cleanest solution.
