Traffic light complete!

H

Hammer

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;
 
H

Hammer

Hammer said:
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;
Click to expand...

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)
 
?

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

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)
Click to expand...

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.
 
M

Mark McDougall

Hammer said:
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)
Click to expand...

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,
 
N

Niv

Hammer said:
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;
Click to expand...


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.
 
H

Hammer

Mark said:
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,
Click to expand...
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!
 
K

KJ

Schüle Daniel said:
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.
Click to expand...
*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;
Click to expand...
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
 
H

Hammer

KJ said:
*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.
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
Click to expand...
Thanks for explanation :) . Now it is clear to me why the code inside
process is supposed to be syncronized with clock.
 
J

JULIOSOL

Joined
May 25, 2007
Messages
1
Reaction score
0
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
 
Last edited:

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Similar Threads

Traffic light 10
How to use ufixed when it involves multiplication a number of times?(VHDL question) 0
IC 74374-getting incorrect simulation 0
pls help me ; vhdl; 0
LFSR doesn't generate random values during simulation 1
Problem With Mealy Sequence Detector 1
Implementation a SVM ( SVPWM) in FPGA with VHDL 0
traffic light controller 0

Members online

Total: 83 (members: 2, guests: 81)
Robots: 466

Forum statistics

Threads
473,995
Messages
2,570,230
Members
46,819
Latest member
masterdaster

Latest Threads

Top