Active-HDL simulation clock crossing

Question

I have 2 modules using the same clock but in different files, when I sample signal that come from module A in module B , in the Waveform simulation it doesn't get samples after one clock cycle like it should , it shows that is samples in the same rising edge(behavior that fit to asynchronous instasiation) .

I have been told it happens because Active-HDL consider it to 2 differnet clock because of the different component and thats why it sample in the same rising edge(because of the delta time that the signal goes from A to B).

how can i define that Active-HDL will understand they both use the same clock in same area ?

I think you've been told BS. Active HDL, like all VHDL simulators does not trace signals, it traces events. If there is an event in any deltatime then the system changes state dependent on that event. It sounds more like a mistake in your code. — Jay M, Nov 16 '12 at 14:33
Look at your clock assignments. If you are assigning via port maps only, this is stramge. If you have an intermediate signal for your clock, this will add a delty cycle in your simulation and produce the effects you described. — BennyBarns, Dec 04 '12 at 13:08

score 2 · Answer 1 · answered Oct 07 '13 at 07:41

This has nothing to do with your simulator. I assume that you're doing something like this:

        +----------+           +----------+
        |          |-- clk --->|          |
clk --->| Module A |           | Module B |
        |          |-- data -->|          |
        +----------+           +----------+

where you should be doing something like that:

        +----------+           +----------+
        |          |           |          |
clk -+->| Module A |-- data -->| Module B |
     |  |          |           |          |
     |  +----------+           |          | 
     |                         |          |
     +-----------------------> |          |
                               +----------+

The problem with the first configuration is that your clock signal gets delayed by one or more delta cycles when it goes through module A. It may thus toggle in the same, or in a later delta cycle than the data signal. This is something that you will not see in the simulator's waveform view (unless it has an option to expand delta cycles) but you can have a look at the list view to see exactly what happens in delta-time.

score 2 · Answer 2 · answered Oct 08 '13 at 00:59

The handling of clock within your chip and within your simulation environment requires the same type of care you take in doing a board design. In particular clock skew must always be smaller than the smallest propagation delay.

In an RTL simulation environment, all of the delays on signals are measured in terms of delta cycles (the default delay for any signal assignment when you are not using after). Going through a port does not incur any delta cycles. However, every assignment to a signal causes a delta cycle delay.

One method to insure successful data transfer is to make sure all clocks in the design are delta cycle aligned when they are used. The simplest way to make sure this happens is to make sure that none of the blocks do an assignment to the clock they use. Hence, do not do any of the following:

LocalClk <= PortClk ;    -- each assignment causes a delta cycle of clock skew 
GatedClk <= Clk and Enable ;   -- clock gates are bad.  See alternative below

Generally we rarely use clock gates - and then we only do it when it is an approved part of our methodology (usually not for FPGAs). In place of using gated clocks in your design, use data path enables:

process (Clk) 
begin
  if rising_edge(Clk) then
    if Enable = '1' then 
      Q <= D ; 
    end if ; 
  end if ; 
end process ;

There are other methodologies to sort this out.

Active-HDL simulation clock crossing

2 Answers2