I've seen issues like this due to delta cycle delays and scheduling problems between blocks when a clock is run through some logic and/or even through hierarchical blocks. I've never sat down and figured out exactly the instances where it fails to work and how they relate to the spec, as I've only run across the problem a couple of times. Once after modifying some code I inherited and once recently when a colleague brought this problem up in IP code where they had modified the clocking scheme.
As you haven't shown the some_signal generation I can only surmise it is on one of the simulated_clock_# domains and is not clocked by the clock_mux_out output. Which is why you would see such a problem the clock mux assignment is causing a scheduling event that moves the clock past the delta cycle that the data scheduling event takes place. If you add an after to the some_signal assignment you'll see it start working (This might be the only way you can fix this, though I'm no VHDL expert).
Your have described a Dff with "clock_mux_out" as clock. Why would you expect a delayed by a clock cycle signal ? It will behave as an output signal from a Dff. If it changes in the falling edge, then it will not notice it.
I assume that some_signal is generated on one of the source clocks? if so you have a delta problem.
Remember that each signal assignment counts as a delta cycle. So clock_mux_out is delayed by 3 deltas WRT simulated_clock_X
so anything that is clocked on simulated_clock_X will have already changed by the time the clock_mux_out rising edge, propogating the signal to make your DFF look like a wire. The best part is - this is a simulation/synthesis missmatch as the hardware will work as expected (apart from the clock muxing issues - not really a good idea in FPGA).
Solution - synchronise some_signal in the clock_mux_out domain by passing it through the same number of signals as the clocks go through:
Code:
a <= ip;
b <= a;
some_signal <= b; -- 3 delta delay
or just dont mess around re-routing clock signals in your testbench. It can be a mess!
Your have described a Dff with "clock_mux_out" as clock. Why would you expect a delayed by a clock cycle signal ? It will behave as an output signal from a Dff. If it changes in the falling edge, then it will not notice it.
mmm, because this is how registered signals behave...
Don't know why you mention the falling edge edge in this context - so I'll just pretend I didn't see it.
ads-ee,
As you haven't shown the some_signal generation I can only surmise it is on one of the simulated_clock_# domains and is not clocked by the clock_mux_out output.
Verilog doesn't have the same delta cycle stuff under the hood like VHDL for behavioral code, though you can run into similar issues with routing clocks around your design like this. I usually only see this in the case of testbench signal generation, which I either use an clocked always block to generate the stimulus into the DUT or I just delay the signals that go to the DUT with #1 before applying the signals (when I'm generating stimulus in a task). I normally don't use the opposite edge of the clock as that requires that I "think" about the relationship between the DUT inputs and the rest of the logic as they are phase shifted by 180 degrees.
// the code in the task will result in a DUT seeing the leading edge of the input_signal.reg clk =0;initialbeginforever#5 clk =~clk;endreg input_signal;task gen_input;begin@(posedge clk);
input_signal =1;endendtask;
dut dut (
.clk (clk),
.input_signal (input_signal));initialbegin#100;
gen_input;#100;$stop
In the case of ASIC verification your clock signal are a bunch of ASIC clock buffer primitives that aren't coded like the behavioral description that exhibits the problem you are seeing, the entire tree is implemented and all the delays are annotated.
the old 'delay by 1' trick solves any issue in verilog. for verification, it can be an issue if you are doing functional verification. for physical and gate level simulation, it is typically fine.