Traffic light complete!

Well
I managed to make the traffic light only with 3 warnings ARE THEY
DANGEROUS(Tomorrow I will go to university to test the code)


WARNING:Xst:1426 - The value init of the FF/Latch y hinder the constant
cleaning in the block count1.
You should achieve better results by setting this init to 1.

WARNING:Xst:1988 - Unit <count1>: instances <Mcompar__n0018>,
<Mcompar__n0025> of unit <LPM_COMPARE_2> and unit <LPM_COMPARE_7> are
dual, second instance is removed

WARNING:Xst:1988 - Unit <count1>: instances <Mcompar__n0023>,
<Mcompar__n0026> of unit <LPM_COMPARE_5> and unit <LPM_COMPARE_8> are
dual, second instance is removed
Loading device for application Rf_Device from file '3s200.nph' in
environment C:\Xilinx.

THE REST I OK, here's the code:

entity count1 is
Port ( clock : in STD_LOGIC;
key : in STD_LOGIC;
yellow : out STD_LOGIC :='0';
green : out STD_LOGIC :='1';
red : out STD_LOGIC :='0';
pred : out STD_LOGIC :='1';
pgreen : out STD_LOGIC :='0');
end count1;

architecture Behavioral of count1 is
signal sec : integer range 0 to 50 :=0;
signal nsec : integer range 1 to 50000000 :=1;
signal x : std_logic :='0';
signal y : std_logic :='0';
begin
process (clock,key,x,y)
begin
if rising_edge(key) then
y<='1';
end if;
if ((key='0' and x='1') or y='0') then
nsec<=1;
sec<=0;
else
if rising_edge(clock) then
if nsec = 5 then
nsec <= 1;
sec <= sec+1;
else
nsec <= nsec + 1;
end if;
if sec>=38 then
x<='1';
end if;
if sec<38 then
x<='0';
end if;
if ((sec<=2) or (sec>=34 and sec<=36)) then
yellow<='1';
else
yellow<='0';
end if;

if (sec>2 and sec<=36) then
red<='1';
else
red<='0';
end if;

if (sec>2 and sec<=36) then
red<='1';
else
red<='0';
end if;

if (sec>36) then
green<='1';
else
green<='0';
end if;
if (sec>5 and sec<=30) then
pgreen<='1';
pred<='0';
else
pgreen<='0';
pred<='1';
end if;
end if;
end if;
end process;
end Behavioral;

Hammer

Hammer wrote:
> Well
> I managed to make the traffic light only with 3 warnings ARE THEY
> DANGEROUS(Tomorrow I will go to university to test the code)
>
>
> WARNING:Xst:1426 - The value init of the FF/Latch y hinder the constant
> cleaning in the block count1.
> You should achieve better results by setting this init to 1.
>
> WARNING:Xst:1988 - Unit <count1>: instances <Mcompar__n0018>,
> <Mcompar__n0025> of unit <LPM_COMPARE_2> and unit <LPM_COMPARE_7> are
> dual, second instance is removed
>
> WARNING:Xst:1988 - Unit <count1>: instances <Mcompar__n0023>,
> <Mcompar__n0026> of unit <LPM_COMPARE_5> and unit <LPM_COMPARE_8> are
> dual, second instance is removed
> Loading device for application Rf_Device from file '3s200.nph' in
> environment C:\Xilinx.
>
> THE REST I OK, here's the code:
>
> entity count1 is
> Port ( clock : in STD_LOGIC;
> key : in STD_LOGIC;
> yellow : out STD_LOGIC :='0';
> green : out STD_LOGIC :='1';
> red : out STD_LOGIC :='0';
> pred : out STD_LOGIC :='1';
> pgreen : out STD_LOGIC :='0');
> end count1;
>
> architecture Behavioral of count1 is
> signal sec : integer range 0 to 50 :=0;
> signal nsec : integer range 1 to 50000000 :=1;
> signal x : std_logic :='0';
> signal y : std_logic :='0';
> begin
> process (clock,key,x,y)
> begin
> if rising_edge(key) then
> y<='1';
> end if;
> if ((key='0' and x='1') or y='0') then
> nsec<=1;
> sec<=0;
> else
> if rising_edge(clock) then
> if nsec = 5 then
> nsec <= 1;
> sec <= sec+1;
> else
> nsec <= nsec + 1;
> end if;
> if sec>=38 then
> x<='1';
> end if;
> if sec<38 then
> x<='0';
> end if;
> if ((sec<=2) or (sec>=34 and sec<=36)) then
> yellow<='1';
> else
> yellow<='0';
> end if;
>
> if (sec>2 and sec<=36) then
> red<='1';
> else
> red<='0';
> end if;
>
> if (sec>2 and sec<=36) then
> red<='1';
> else
> red<='0';
> end if;
>
> if (sec>36) then
> green<='1';
> else
> green<='0';
> end if;
> if (sec>5 and sec<=30) then
> pgreen<='1';
> pred<='0';
> else
> pgreen<='0';
> pred<='1';
> end if;
> end if;
> end if;
> end process;
> end Behavioral;

One more question I had a warning that x and y are missing in process
sensitivity list so I put them there. My question is why are they
missing (they are only bits)

Hammer

Hi,

> One more question I had a warning that x and y are missing in process
> sensitivity list so I put them there. My question is why are they
> missing (they are only bits)

I can't tell you what hardware solution synthese eventually will yield
(actually I am vhdl newbie myself)
I know that everything inside architecture, between begin and end
are processes. Even simple

x <= (a and b) or c;

is process sensitive to all signals on its right.
To be more verbose one can write

process(a,b,c)
begin
x <= (a and b) or c;
end process;

Such processes are said to be combinatorical(all signals are listed),
they are run when at least one event is generated on a, b or c.
Of course multiple events may occure at the same time.

As I said I am beginner myself, I would like to leave it to
experts to explain how synthese interprets processes
that don't have explicitely all signals listed in their
sensitivity list.

To write it down .. is there a difference between

process(a,b)
begin
x <= (a and b) or c;
end process;

and

process(a,b,c)
begin
x <= (a and b) or c;
end process;


Regards, Daniel

ps: I don't want to hijack the thread, I think this is what your
question was about.

=?ISO-8859-1?Q?Sch=FCle_Daniel?=

Hammer wrote:

> One more question I had a warning that x and y are missing in process
> sensitivity list so I put them there. My question is why are they
> missing (they are only bits)

Any signal that is *read* within a process must be in the sensitivity
list for simulation so that the simulator knows to generate an event
(and re-evaluate expressions that read the signal) when that signal changes.

For synthesis, it's good practice but not required.

BTW what do you mean by "they are only bits"??? When it comes down to
that, you can say that about *any* signal!?!

Also, a quick perusal of your code on style...

You can assign 'default' values to signals at the top of the process so
that you only need to actually assign them within your logic for
non-default values.

If you look closely at your logic, a lot of it is mutually exclusive and
some re-arrangement (hint: use 'elsif') can reduce both the number of
lines of code and the number of expressions required. You might even fix
the bug where yellow and red are both on for a few secs!

I suspect your 1988 warnings are because you have duplicate code for the
red traffic light signal?

FWIW 'X' and 'Y' are *terrible* signal names in this instance! You
should be able to do *without* X and I can't tell you what Y does
because it would appear to do nothing at all once a key is pressed.
Also, I think sec is going to continue counting past 38, past 50, back
to 0 and the sequence will play over again.

Regards,

--
Mark McDougall, Engineer
Virtual Logic Pty Ltd, <http://www.vl.com.au>
21-25 King St, Rockdale, 2216
Ph: +612-9599-3255 Fax: +612-9599-3266

Mark McDougall

Hammer wrote:
> Well
> I managed to make the traffic light only with 3 warnings ARE THEY
> DANGEROUS(Tomorrow I will go to university to test the code)
>
>
> WARNING:Xst:1426 - The value init of the FF/Latch y hinder the constant
> cleaning in the block count1.
> You should achieve better results by setting this init to 1.
>
> WARNING:Xst:1988 - Unit <count1>: instances <Mcompar__n0018>,
> <Mcompar__n0025> of unit <LPM_COMPARE_2> and unit <LPM_COMPARE_7> are
> dual, second instance is removed
>
> WARNING:Xst:1988 - Unit <count1>: instances <Mcompar__n0023>,
> <Mcompar__n0026> of unit <LPM_COMPARE_5> and unit <LPM_COMPARE_8> are
> dual, second instance is removed
> Loading device for application Rf_Device from file '3s200.nph' in
> environment C:\Xilinx.
>
> THE REST I OK, here's the code:
>
> entity count1 is
> Port ( clock : in STD_LOGIC;
> key : in STD_LOGIC;
> yellow : out STD_LOGIC :='0';
> green : out STD_LOGIC :='1';
> red : out STD_LOGIC :='0';
> pred : out STD_LOGIC :='1';
> pgreen : out STD_LOGIC :='0');
> end count1;
>
> architecture Behavioral of count1 is
> signal sec : integer range 0 to 50 :=0;
> signal nsec : integer range 1 to 50000000 :=1;
> signal x : std_logic :='0';
> signal y : std_logic :='0';
> begin
> process (clock,key,x,y)
> begin
> if rising_edge(key) then
> y<='1';
> end if;
> if ((key='0' and x='1') or y='0') then
> nsec<=1;
> sec<=0;
> else
> if rising_edge(clock) then
> if nsec = 5 then
> nsec <= 1;
> sec <= sec+1;
> else
> nsec <= nsec + 1;
> end if;
> if sec>=38 then
> x<='1';
> end if;
> if sec<38 then
> x<='0';
> end if;
> if ((sec<=2) or (sec>=34 and sec<=36)) then
> yellow<='1';
> else
> yellow<='0';
> end if;
>
> if (sec>2 and sec<=36) then
> red<='1';
> else
> red<='0';
> end if;
>
> if (sec>2 and sec<=36) then
> red<='1';
> else
> red<='0';
> end if;
>
> if (sec>36) then
> green<='1';
> else
> green<='0';
> end if;
> if (sec>5 and sec<=30) then
> pgreen<='1';
> pred<='0';
> else
> pgreen<='0';
> pred<='1';
> end if;
> end if;
> end if;
> end process;
> end Behavioral;


You should not have two "rising_edge" statements in one process.
A clocked process has only one clock, which is all that should be in
the sensitivity list (possibly along with an async reset signal)...>
e.g.

------------------------------------------------------------------------
myproc : PROCESS (clk, reset_n)
BEGIN
IF reset_n = '0' THEN
signal_logic <= '0'; -- assign a signal to reset value of
'0'
signal_bus <= (OTHERS => '0'); -- assign a bus signal to
reset value of all '0's
ELSIF rising_edge(clk) THEN
signal_bus <= (some bus value);
signal_logic <= (some logic level);
etc etc
END IF;
END PROCESS myproc;
------------------------------------------------------------------------

Note the use of names for the process(es). This is much better to find
things.
Also, only tab in 2 spaces (& I mean spaces, so all editors see the
same, else tab setup across different editors becomes confusing) for
indents, else it can get unwieldy for lots of indents.

Niv

Mark McDougall wrote:
> Hammer wrote:
>
>> One more question I had a warning that x and y are missing in process
>> sensitivity list so I put them there. My question is why are they
>> missing (they are only bits)
>
> Any signal that is *read* within a process must be in the sensitivity
> list for simulation so that the simulator knows to generate an event
> (and re-evaluate expressions that read the signal) when that signal
> changes.
>
> For synthesis, it's good practice but not required.
>
> BTW what do you mean by "they are only bits"??? When it comes down to
> that, you can say that about *any* signal!?!
>
> Also, a quick perusal of your code on style...
>
> You can assign 'default' values to signals at the top of the process so
> that you only need to actually assign them within your logic for
> non-default values.
>
> If you look closely at your logic, a lot of it is mutually exclusive and
> some re-arrangement (hint: use 'elsif') can reduce both the number of
> lines of code and the number of expressions required. You might even fix
> the bug where yellow and red are both on for a few secs!
>
> I suspect your 1988 warnings are because you have duplicate code for the
> red traffic light signal?
>
> FWIW 'X' and 'Y' are *terrible* signal names in this instance! You
> should be able to do *without* X and I can't tell you what Y does
> because it would appear to do nothing at all once a key is pressed.
> Also, I think sec is going to continue counting past 38, past 50, back
> to 0 and the sequence will play over again.
>
> Regards,
>
Y has to be there because if you simulate the code you will notice if Y
is removed the counter will start counting before key is pressed (for
the first time, upon turning on the traffic light).

YES RED IS DUPLICATE THANKS- DIDN'T NOTICE MUST HAVE COPY PASTED AND
FORGOT ABOUT IT

THANK YOU!

Hammer

"Schüle Daniel" <> wrote in message
news:e6sn9q$2vs$...
>
> As I said I am beginner myself, I would like to leave it to
> experts to explain how synthese interprets processes
> that don't have explicitely all signals listed in their
> sensitivity list.
*Usually* synthesis tools will only use the sensitivity list to kick out a
warning about an incomplete list (i.e. using signal 'c' in an equation but
not having it in the list). The reason that they do this is
1. *Usually* the behaviour in the equations is what is intended, the
sensitivity list is simply a bookkeeping chore.
2. Technically what they have implemented is not what your VHDL code says to
do per the VHDL language definition. Since they are taking somewhat of a
guess about what you really intended but violating the language
specification they implement it the way they think you 'really' want it and
kick out a warning to let you know that the actual implementation will
operate differently than your simulation shows.
>
> To write it down .. is there a difference between
>
> A1: process(a,b)
> begin
> x <= (a and b) or c;
> end process;
>
> and
>
> A2: process(a,b,c)
> begin
> x <= (a and b) or c;
> end process;
>
Process A1 is an example of an incomplete sensitivity list. The process
only wakes up and starts executing if signals 'a' or 'b' change for some
reason. If signal 'c' happens to change than nothing happens. So, if 'a',
'b' and 'c' are all '0' signal 'x' will be '0' in both process A1 and A2.
Now if all you do is flip signal 'c' to '1', then process A2 will wake up
because 'c' is in its sensitivity list and it then goes on to recompute 'x'
and figures out that it should be '1' as well. Process A1 however will not
do start up because neither signal 'a' nor 'b' have changed so the 'x' out
of that process will not be recomputed and will stay at '0'.

Maintenance of sensitivity lists is a pointless chore, the compiler should
have the smarts to figure out what signals it is sensitive to but that is
not the way the language specification is defined. The synthesis tool
vendors have caught on to this and issue a warning, simulator do not. To
avoid this pointless headache, what I do is stay away from using
combinatorial processes (i.e. like A1 and A2) and write them as concurrent
statements. Use processes only to generate flip flops (where the only
signal in the sensitivity list then is 'clock' and no sensitivity list
maintenance is required) or if I reeeeeally would like to use 'case' or
'if/endif' over the concurrent method using 'with select' and 'when'.

KJ

KJ

KJ wrote:
> "Schüle Daniel" <> wrote in message
> news:e6sn9q$2vs$...
>> As I said I am beginner myself, I would like to leave it to
>> experts to explain how synthese interprets processes
>> that don't have explicitely all signals listed in their
>> sensitivity list.
> *Usually* synthesis tools will only use the sensitivity list to kick out a
> warning about an incomplete list (i.e. using signal 'c' in an equation but
> not having it in the list). The reason that they do this is
> 1. *Usually* the behaviour in the equations is what is intended, the
> sensitivity list is simply a bookkeeping chore.
> 2. Technically what they have implemented is not what your VHDL code says to
> do per the VHDL language definition. Since they are taking somewhat of a
> guess about what you really intended but violating the language
> specification they implement it the way they think you 'really' want it and
> kick out a warning to let you know that the actual implementation will
> operate differently than your simulation shows.
>> To write it down .. is there a difference between
>>
>> A1: process(a,b)
>> begin
>> x <= (a and b) or c;
>> end process;
>>
>> and
>>
>> A2: process(a,b,c)
>> begin
>> x <= (a and b) or c;
>> end process;
>>
> Process A1 is an example of an incomplete sensitivity list. The process
> only wakes up and starts executing if signals 'a' or 'b' change for some
> reason. If signal 'c' happens to change than nothing happens. So, if 'a',
> 'b' and 'c' are all '0' signal 'x' will be '0' in both process A1 and A2.
> Now if all you do is flip signal 'c' to '1', then process A2 will wake up
> because 'c' is in its sensitivity list and it then goes on to recompute 'x'
> and figures out that it should be '1' as well. Process A1 however will not
> do start up because neither signal 'a' nor 'b' have changed so the 'x' out
> of that process will not be recomputed and will stay at '0'.
>
> Maintenance of sensitivity lists is a pointless chore, the compiler should
> have the smarts to figure out what signals it is sensitive to but that is
> not the way the language specification is defined. The synthesis tool
> vendors have caught on to this and issue a warning, simulator do not. To
> avoid this pointless headache, what I do is stay away from using
> combinatorial processes (i.e. like A1 and A2) and write them as concurrent
> statements. Use processes only to generate flip flops (where the only
> signal in the sensitivity list then is 'clock' and no sensitivity list
> maintenance is required) or if I reeeeeally would like to use 'case' or
> 'if/endif' over the concurrent method using 'with select' and 'when'.
>
> KJ
>
>
Thanks for explanation . Now it is clear to me why the code inside
process is supposed to be syncronized with clock.

Hammer

[JULIOSOL]

Hi everybody

i'm a beginer in FPGAs, and i've been writing some codes, the last was state machine for a lock system. I'm trying to sinthezise it, but I have the next messages,




> WARNING:Xst:1988 - Unit <count1>: instances <Mcompar__n0018>,
> <Mcompar__n0025> of unit <LPM_COMPARE_2> and unit <LPM_COMPARE_7> are
> dual, second instance is removed
>
> WARNING:Xst:1988 - Unit <count1>: instances <Mcompar__n0023>,
> <Mcompar__n0026> of unit <LPM_COMPARE_5> and unit <LPM_COMPARE_8> are
> dual, second instance is removed


Please somebody can tell me
How could i solve this?
Perhapz somebody had the same problem
my e-m is ZOLVEZ@hotm

JULIOSOL

[adnash]

Hi there

I am very new VHDL and want to design the traffic light system and than transfer to spartan 3 board. Is it possible any one could e-mail me any guide (report, tutorial ,file etc) . . Please let me know and Thanks in advanced

Regards
Adnash

adnash