signal assignment 
Author Message
 signal assignment

Hello!
            I am a bit comfused of how the signals are assigned. Signals
are always scheduled so that means the transaction on the signal is
scheduled for the next clock edge.

I have something like this...
process(CLK,CLR,BWE)
begin
   if ( CLR ='1') then
          BWEQ <= '0';
   elsif rising_edge(CLK) then
                BWEQ <= BWE;
end process;
So BWEQ becomes 1 after a clock cycle delay.

Also I HAVE ...

BURSTWRITE1 <= (BURSTWRITE and (not(LA(21))) and (LA(20)));
outside the process  so in the waveform I notice that
BURSTWRITE1 and BURSTWRITE become 1 immediately at the same clock edge.

Also I have
RD <= RDO when (WRITE_ENABLE ='1') else (others =>'Z'); a tristate
buffer...
I notice the same thing for RD and RDO. RDO instantaneoulsy gets the value
of RD..

This I get even if I put the above statement in a procss...

assign_RD: process(CLK,RDO,WRITE_ENABLE)
begin
if (WRITE_ENABLE ='1') then
RD <= RDO;
else
RD<= (others=>'Z');
end if;
end process;
even though this process is clocked or not RDO instantaneoulsy gets the
value
of RD..

Thanks in advance.
Sreedhar



Tue, 10 Dec 2002 03:00:00 GMT  
 signal assignment
Hi

Sreedhar Sampath a crit :

Quote:

> Hello!
> I am a bit comfused of how the signals are assigned. Signals
> are always scheduled so that means the transaction on the signal is
> scheduled for the next clock edge.

Only if you specify it. A combinational signal assignment won't depend
on any clock.

Quote:
> I have something like this...
> process(CLK,CLR,BWE)
> begin
>    if ( CLR ='1') then
>           BWEQ <= '0';
>    elsif rising_edge(CLK) then
>                 BWEQ <= BWE;
> end process;
> So BWEQ becomes 1 after a clock cycle delay.

Right. Note: you don't need to put BWE in the sensitivity list since it
won't trigger any output change.

Quote:
> Also I HAVE ...
> BURSTWRITE1 <= (BURSTWRITE and (not(LA(21))) and (LA(20)));
> outside the process  so in the waveform I notice that BURSTWRITE1 and
> BURSTWRITE become 1 immediately at the same clock edge.

Right (in real life, there will be a small delay due to the
combinational logic)

Quote:
> Also I have
> RD <= RDO when (WRITE_ENABLE ='1') else (others =>'Z');
> I notice the same thing for RD and RDO. RDO instantaneoulsy gets the
> value of RD..

Same thing as above. There's no clock in the expression, therefore it
won't depend on any clock.

Quote:
> This I get even if I put the above statement in a procss...
> assign_RD: process(CLK,RDO,WRITE_ENABLE)
> begin
> if (WRITE_ENABLE ='1') then
> RD <= RDO;
> else
> RD<= (others=>'Z');
> end if;
> end process;
> even though this process is clocked or not RDO instantaneoulsy gets
> the value of RD..

Right. There's no instruction that says "wait for a clock edge".
Although you put the clock in the sensitivity list, your process is NOT
clocked. It may be if you remove ALL signals but the clock from the
sensitivity list.

--
Nicolas MATRINGE           DotCom S.A.
Conception electronique    16 rue du Moulin des Bruyeres
Tel +33 1 46 67 51 11      92400 COURBEVOIE
Fax +33 1 46 67 51 01      FRANCE



Tue, 10 Dec 2002 03:00:00 GMT  
 signal assignment

Hi Sreedhar and Nicolas.
Most of Nicolas satements seem to be correct, but one ting to
mention...

Quote:
> Sreedhar Sampath a crit :

> > Hello!
> > I am a bit comfused of how the signals are assigned. Signals
> > are always scheduled so that means the transaction on the signal is
> > scheduled for the next clock edge.
> Only if you specify it. A combinational signal assignment won't depend
> on any clock.

So far so good, but...

Quote:
> > I have something like this...
> > process(CLK,CLR,BWE)
> > begin
> >    if ( CLR ='1') then
> >           BWEQ <= '0';
> >    elsif rising_edge(CLK) then
> >                 BWEQ <= BWE;
> > end process;
> > So BWEQ becomes 1 after a clock cycle delay.
> Right. Note: you don't need to put BWE in the sensitivity list since
it
> won't trigger any output change.

I dont think so. The Assignment of BWEQ will be scheduled for the next
?delta cycle (that means in no measurable time) or for synthesis yo
will experience the clock to output delay. Check your simulations for
the following : When does BWE change? Does it also come from a clocked
output?  
In that case each change of BWE would affect BWEQ one clock cycle
later. But that's not due to some ?scheduling for the next clock
period. Its just that BWE changes AFTER a rising clock edge, and
therefore wont be assigned to BWEQ on that same clock edge, but the
one after that.

Quote:
> > Also I HAVE ...
> > BURSTWRITE1 <= (BURSTWRITE and (not(LA(21))) and (LA(20)));
> > outside the process  so in the waveform I notice that BURSTWRITE1 and
> > BURSTWRITE become 1 immediately at the same clock edge.
> Right (in real life, there will be a small delay due to the
> combinational logic)

Correct, its only combinational!

Quote:
> > Also I have
> > RD <= RDO when (WRITE_ENABLE ='1') else (others =>'Z');
> > I notice the same thing for RD and RDO. RDO instantaneoulsy gets the
> > value of RD..
> Same thing as above. There's no clock in the expression, therefore it
> won't depend on any clock.

You say it.

Quote:
> > This I get even if I put the above statement in a procss...
> > assign_RD: process(CLK,RDO,WRITE_ENABLE)
> > begin
> > if (WRITE_ENABLE ='1') then
> > RD <= RDO;
> > else
> > RD<= (others=>'Z');
> > end if;
> > end process;
> > even though this process is clocked or not RDO instantaneoulsy gets
> > the value of RD..
> Right. There's no instruction that says "wait for a clock edge".
> Although you put the clock in the sensitivity list, your process is
NOT
> clocked. It may be if you remove ALL signals but the clock from the
> sensitivity list.

Right, you don't need any clock here, while all input signals are in
the sensitivity list, and the proces uses only combinational
statements.
BUT if there would only be the clock signal in the sensitiviti list,
the process would only be activated on EVERY change of the clock
signal. This would lead to some very funny behavior I think :-)

Have a nice synthesis

     Eilert



Fri, 13 Dec 2002 03:00:00 GMT  
 signal assignment
Sreedhar,

You need to look at the way concurrent statements are executed.If in a process
the values are updated only when the process suspends which in other words
would be when it reaches the end process statement(assuming that you do not
have wait statements)

The delta delay is an inheritent property of  concurrent statements

Hope this helps u again

Sateesh

Quote:

> Hello!
>             I am a bit comfused of how the signals are assigned. Signals
> are always scheduled so that means the transaction on the signal is
> scheduled for the next clock edge.

> I have something like this...
> process(CLK,CLR,BWE)
> begin
>    if ( CLR ='1') then
>           BWEQ <= '0';
>    elsif rising_edge(CLK) then
>                 BWEQ <= BWE;
> end process;
> So BWEQ becomes 1 after a clock cycle delay.

> Also I HAVE ...

> BURSTWRITE1 <= (BURSTWRITE and (not(LA(21))) and (LA(20)));
> outside the process  so in the waveform I notice that
> BURSTWRITE1 and BURSTWRITE become 1 immediately at the same clock edge.

> Also I have
> RD <= RDO when (WRITE_ENABLE ='1') else (others =>'Z'); a tristate
> buffer...
> I notice the same thing for RD and RDO. RDO instantaneoulsy gets the value
> of RD..

> This I get even if I put the above statement in a procss...

> assign_RD: process(CLK,RDO,WRITE_ENABLE)
> begin
> if (WRITE_ENABLE ='1') then
> RD <= RDO;
> else
> RD<= (others=>'Z');
> end if;
> end process;
> even though this process is clocked or not RDO instantaneoulsy gets the
> value
> of RD..

> Thanks in advance.
> Sreedhar



Sun, 15 Dec 2002 03:00:00 GMT  
 signal assignment
Thanks for the answer sateesh.
It did help.
I was also wondering if we have too many process in the design does that
mean the speed of the design would increase.
The design ofcourse could be written in one process....

Sreedhar

Quote:

> Sreedhar,

> You need to look at the way concurrent statements are executed.If in a process
> the values are updated only when the process suspends which in other words
> would be when it reaches the end process statement(assuming that you do not
> have wait statements)

> The delta delay is an inheritent property of  concurrent statements

> Hope this helps u again

> Sateesh


> > Hello!
> >             I am a bit comfused of how the signals are assigned. Signals
> > are always scheduled so that means the transaction on the signal is
> > scheduled for the next clock edge.

> > I have something like this...
> > process(CLK,CLR,BWE)
> > begin
> >    if ( CLR ='1') then
> >           BWEQ <= '0';
> >    elsif rising_edge(CLK) then
> >                 BWEQ <= BWE;
> > end process;
> > So BWEQ becomes 1 after a clock cycle delay.

> > Also I HAVE ...

> > BURSTWRITE1 <= (BURSTWRITE and (not(LA(21))) and (LA(20)));
> > outside the process  so in the waveform I notice that
> > BURSTWRITE1 and BURSTWRITE become 1 immediately at the same clock edge.

> > Also I have
> > RD <= RDO when (WRITE_ENABLE ='1') else (others =>'Z'); a tristate
> > buffer...
> > I notice the same thing for RD and RDO. RDO instantaneoulsy gets the value
> > of RD..

> > This I get even if I put the above statement in a procss...

> > assign_RD: process(CLK,RDO,WRITE_ENABLE)
> > begin
> > if (WRITE_ENABLE ='1') then
> > RD <= RDO;
> > else
> > RD<= (others=>'Z');
> > end if;
> > end process;
> > even though this process is clocked or not RDO instantaneoulsy gets the
> > value
> > of RD..

> > Thanks in advance.
> > Sreedhar



Mon, 16 Dec 2002 03:00:00 GMT  
 
 [ 7 post ] 

 Relevant Pages 

1. conditional signal assignment

2. Signal Assignment conflicts, What can I do?

3. Signal assignment mismatch with Aldec 5.1 problem

4. Help with multiple signal Assignments

5. question about signal assignment in "case"

6. Time Delay in signal assignment

7. Parent Signal Assignment inside Procedure?

8. Use of hex values for selected signal assignment

9. selected signal assignment question

10. VHDL Signal Assignment Rules

11. Conditional Signal Assignments inside Processes?

12. Signal assignments

 

 
Powered by phpBB® Forum Software