title: Odd VHDL question: rising_edge(CLK) not firing
body: <p>I have a large simulation testbench which is exercising the interface between two Kintex Ultrascale FPGAs. I'm having the oddest problem: I can't get a rising_edge(CLK) statement to fire.</p>
  
  <p>There are multiple instances of this in the design: I'll trace down a logic path, and end up discovering a rising_edge(whatever) that isn't firing. </p>
  
  <p>Here is the kicker: Replacing rising_edge with CLK'EVENT and CLK='1' causes the logic to fire correctly, but I can't go through a thousand source files to replace them all and then push it to the team repo - that'd be absurd (plus the code is valid, and has been used multiple times, so making a change like that would be a huge waste of time).</p>
  
  <p>A rising_edge is also equivalent to CLK'LAST='0' and CLK'EVENT and CLK='1' - this statement also doesn't fire. So it must be that CLK'LAST='0' isn't satisfied, right? (If CLK'EVENT and CLK='1' fires, and the addition of CLK'LAST='0' does not fire, then it must be that last item causing the problem).</p>
  
  <p>However, I look at the delta-view, and I can see no intermediate values between 0 and 1 - no intermediate high-Z states, no undefined signal, nothing. It looks perfect. </p>
  
  <p>I have tested this with several different Modelsim versions with the same result (just to make sure it wasn't a tool regression). </p>
  
  <p>What, in the world, could be causing this? </p>
  
  <p>The only thing I can think of that's non-standard is that I'm using external names to drive the clock/data a few layers up the hierarchy, but they're updating the expected value to the waveform window.</p>
  
  <p>Could the use of the external names to force values somehow cause the edge to be missed, even though the signals look right (even down to the deltas?) or would it cause some kind of waveform window disparity? What is causing the CLK'LAST to be effectively lost?</p>
  
  <p>Thanks all!</p>