Question about concurrent signal assignments

[mamu]

Hi,

when i simulate the following code I see that clk1 and clk2 are not
the same clk nets and therefore reg2 takes the value of reg1 at what
looks to be the some rising edge. I can understand the result of the
simulation if it is correct that clk2 should be delayed by one delta
cycle. But in my mind clk1 and clk2 are the same net and the
simulation does not match the expected result of the circuit
described.

So, does the simulator interpret the VHDL code correctly and is this
is a case where a functional simulation will always give a mismatch
with hardware?

architecture rtl of test is
signal clk1 : std_logic := '0';
signal clk2 : std_logic := '0';

signal reg1 : std_logic := '0';
signal reg2 : std_logic;

begin

clk1 <= not clk1 after 10 ns;

clk2 <= clk1;

pSync1 : process (clk1) is
begin
if rising_edge(clk1) then
reg1 <= not reg1;
end if;
end process pSync1;

pSync2 : process (clk2) is
begin
if rising_edge(clk2) then
reg2 <= reg1;
end if;
end process pSync2;

end architecture rtl;

 

[Barry]

Hi,

when i simulate the following code I see that clk1 and clk2 are not
the same clk nets and therefore reg2 takes the value of reg1 at what
looks to be the some rising edge. I can understand the result of the
simulation if it is correct that clk2 should be delayed by one delta
cycle. But in my mind clk1 and clk2 are the same net and the
simulation does not match the expected result of the circuit
described.

I believe this (untested) code will eliminate the delta cycle delay
between clk1 and clk2, if that is your goal.

process
variable clk0 : std_logic := '0';
begin
clk1 <= clk0;
clk2 <= clk0;
wait for 10 ns;
clk0 := not clk0;
end process;

Barry

 

[Andy]

I believe this (untested) code will eliminate the delta cycle delay
between clk1 and clk2, if that is your goal.

process
  variable clk0 : std_logic := '0';
begin
  clk1 <= clk0;
  clk2 <= clk0;
  wait for 10 ns;
  clk0 := not clk0;
end process;

Barry

That's usually what I try to do, insert delta delays in a copy of the
original clock to match up with the delayed clock. The beauty of this
is that you only have to do it once. Otherwise, you'd have to put
delays on every signal from the early clock domain to the late clock
domain.

I've even on occasion flipped edges of the clock just to make this
work, especially if I don't have access to the original clock before
it is used in other sections I don't have access to, but need their
outputs lined up with my (delayed) clock.

Andy

 

[mamu]

Thank you for your answers and comments.

I ran into this problem when I was using block diagram based design
tool. The name of the clock input pin was 'IP_CLK' while I prefer
simply 'clk', so I renamed the clock net and saw strange behavior in
the simulation. Now I understand why and I will hopefully not make the
same mistake again.

I was thinking that there should be some way (with VHDL) to simply
connect nets to each other without delay, but that would be
inconsistent with regards to how VHDL handles signal assignments.
Besides, I could simply use an alias and my problem would be solved.
(It is not so easy to do it with the tool I am using though).

I am not sure I like the idea of having clocks that are delayed by
delta cycles. It can cause a lot of confusion (as it did to me). But I
see that there might be cases where it is the only solution. E.g. if
you have to interface with some component (functional model) that
forwards a clock that is already delayed by a delta cycle so that its
outputs updates at the same time as the clock.

Magne

 

[Barry]

Thank you for your answers and comments.

I ran into this problem when I was using block diagram based design
tool. The name of the clock input pin was 'IP_CLK' while I prefer
simply 'clk', so I renamed the clock net and saw strange behavior in
the simulation. Now I understand why and I will hopefully not make the
same mistake again.

I was thinking that there should be some way (with VHDL) to simply
connect nets to each other without delay, but that would be
inconsistent with regards to how VHDL handles signal assignments.
Besides, I could simply use an alias and my problem would be solved.
(It is not so easy to do it with the tool I am using though).

I am not sure I like the idea of having clocks that are delayed by
delta cycles. It can cause a lot of confusion (as it did to me). But I
see that there might be cases where it is the only solution. E.g. if
you have to interface with some component (functional model) that
forwards a clock that is already delayed by a delta cycle so that its
outputs updates at the same time as the clock.

Magne

To simply re-name an input port signal, you can use

alias clk : std_logic is IP_CLK;

in the declarations section of the architecture.

No assignment, and hence no delta delay.

Barry