«

Hi,
I have simple code in VHDL:

"

LIBRARY ieee;
Library unisim;
USE ieee.std_logic_1164.ALL;
use UNISIM.Vcomponents.all;
use ieee.std_logic_arith.ALL;


ENTITY prosty IS
PORT(
P_I_CLK : IN std_logic;
Rst : IN std_logic;
Porty : out std_logic;
wynik : OUT std_logic_vector(3 downto 0);
STAN : OUT std_logic_vector(3 downto 0)


);
end prosty;


Architecture test OF prosty IS

type state is (Idle, Pierwszy, Drugi,Trzeci);

signal S_THIS: state :=Idle;

begin

check_clock: process(Rst,P_I_CLK)


begin

if (Rst='1') then S_THIS <= Idle ;
elsif (P_I_CLK'event and P_I_CLK='1') then
case S_THIS is

when Idle =>
S_THIS<= Pierwszy;


when Pierwszy=>
S_THIS<= Drugi;

when Drugi=>
S_THIS<= Trzeci;

when Trzeci=>
S_THIS<= Idle;


end case;
end if;

end process check_clock;





states: process (S_THIS)
variable zmienna : integer:=0;

begin

Porty <= '0';
STAN <= "0000";
if (zmienna=2) then wynik<="1111";
else
wynik<="0010";
end if;
case S_THIS is

when Idle =>

zmienna := zmienna+1;
--wynik <= zmienna;


when Pierwszy =>
Porty <= '1';
STAN <= "0001";

when Drugi =>
Porty <= '1';
STAN <= "0010";

when Trzeci =>
Porty <= '1';
STAN <= "0011";

end case;


end process states;

end;

"

In post-route simulation it looks like horrible. Port Wynik is very
unsatisfied.
I use Xilinx ISE and Virtex2P XC2VP30.
Clock 40 MHz

I understand post-route simulation seems real hardware..

What should I do?

Regards,
zlotawy

>
> In post-route simulation it looks like horrible. Port Wynik is very
> unsatisfied.
What the heck does that mean? An unsatisfied port??

> I use Xilinx ISE and Virtex2P XC2VP30.
> Clock 40 MHz
>
> I understand post-route simulation seems real hardware..
>
> What should I do?
Use a simulator to debug your code

KJ

U¿ytkownik "KJ" <> napisa³ w wiadomo¶ci
news:Vk_9h.6398$ t...
>
> What the heck does that mean? An unsatisfied port??

In ideal simulation all is OK. In post-route simulation there are
divergences and clutters... If I run it on hardware and will be the same...
Frequency is not high so I do not understand why it does not work
perfectly.


zlotawy

zlotawy wrote:
> U¿ytkownik "KJ" <> napisa³ w wiadomo¶ci
> news:Vk_9h.6398$ t...
>
>>What the heck does that mean? An unsatisfied port??
>
>
> In ideal simulation all is OK. In post-route simulation there are
> divergences and clutters... If I run it on hardware and will be the same...
> Frequency is not high so I do not understand why it does not work
> perfectly.
>
>
> zlotawy
>
>
Hi zlotawy,
first I suggest you to use more meaningful names (english is preferrable
to let other people understand the code) for your states and signals,
secondly I just noticed that your wynick signal is not registered and
this can be the cause of your "clutters". Moreover your zmienna looks
like a counter, but there is no clock on the process, is this that you want?
To let other people help you I think you should give more information
about what is your problem.

Hope that hint helps
Cheers

Al

--
Alessandro Basili
CERN, PH/UGC
Hardware Designer

"zlotawy" <> wrote in message
news:...
>
> U¿ytkownik "KJ" <> napisa³ w wiadomo¶ci
> news:Vk_9h.6398$ t...
>>
>> What the heck does that mean? An unsatisfied port??
>
> In ideal simulation all is OK. In post-route simulation there are
> divergences and clutters..
Answering the question 'what do you mean my unsatisfied port?' with
'divergences and clutters' is equally unhelpful. You don't need colorful
descriptions to get help, you need to describe just what is wrong. What do
you actually see that is not right?

> If I run it on hardware and will be the same...
That's a good thing

> Frequency is not high so I do not understand why it does not work
> perfectly.
Probably won't work because you haven't completed all of the following
tasks:
1. Simulation (of the pre-route design) demonstrates that the code does
what you want it to do.
2. Completed static timing analysis.
3. Gotten rid of all synthesis warnings

I get the rough impression that you may have completed #1 and have not done
anything about #2 or #3. If that's the case your design will likely not
work in real hardware and the first indication that you're getting about
this is that when you run the post-route simulation that you're seeing
'clutters' and 'unsatisfied ports' (whatever that is supposed to mean....but
I'm guessing it's not good).

Perusing your combinatorial process 'states: process (S_THIS) I see the
following things problems:
- The process lists only S_THIS in the sensitivity list but should also
include 'zmienna' since it is used on the right hand side. This should've
produced a warning about an 'incomplete sensitivity list' when you compiled
it, look for it.
- The equation for signal 'zmienna' is questionable. Combinatorial
processes where you have a signal on both sides are a problem (i.e. zmienna
<= zmienna + 1). This should've produced a warning about a combinatorial
loop....look for it.
- The signal zmienna does not get assigned in every path through that
combinatorial process. This will produce a latch which is generally a
problem. Once again, the synthesis tool should've produced a warning about
this, look for it.

As a general rule, try not to use combinatorial processes (i.e. a process
that is sensitive to anything other than the rising edge of a clock). The
reason is that it is far too easy to make the types of mistakes that you've
made in your example.

Once you've got the synthesis warnings taken care of, then you need to
perform static timing analysis so that you know that your design will work
at the clock frequency you intend to run it at.

After you've done all that you should find that there are absolutely no
functional differences between simulation on the pre-route versus the
post-route design....clock for clock the outputs should match.

KJ

Uzytkownik "Al" <> napisal w wiadomosci
news:eka3cl$7s7$...
>
> Hi zlotawy,
> first I suggest you to use more meaningful names (english is preferrable
> to let other people understand the code) for your states and signals,
> secondly I just noticed that your wynick signal is not registered and this
> can be the cause of your "clutters".


should I not send value direct to port?

By signal, and from signal to port is the same problem.


Moreover your zmienna looks
> like a counter, but there is no clock on the process, is this that you
> want?

hmm.....

If i make counter with clock, wynik is beautifull.

"
process (P_I_CLK,Rst)
begin
if (Rst='1') then zmienna <= 0 ;
elsif (P_I_CLK'event and P_I_CLK='1') then

zmienna<= zmienna+1;

end if;

end process;

process(zmienna)
begin
if (zmienna=3) then wynik<="1111";
else
wynik<="0000";
end if;
"

But I wanted count how many times, state was Idle...not how many were rising
clock.
Then in the same time there are sending to wynik "1111" and "0010";

In result on timing I can see "XX1X;


"if (variable=2) then wynik<="1111";
else
wynik<="0010";
end if;"

I think it should send onlz 1111 where variable is 2.


I could signalize that state machine is in one of states. Light leds or
something.

How can I check that some state was active for example second times?


zlotawy

U¿ytkownik "KJ" <> napisa³ w wiadomo¶ci
news:yT1ah.9905$ m...
>
> "zlotawy" <> wrote in message
> news:...
>>
>> U¿ytkownik "KJ" <> napisa³ w wiadomo¶ci
>> news:Vk_9h.6398$ t...
>>>
>>> What the heck does that mean? An unsatisfied port??
>>
>> In ideal simulation all is OK. In post-route simulation there are
>> divergences and clutters..
> Answering the question 'what do you mean my unsatisfied port?' with
> 'divergences and clutters' is equally unhelpful. You don't need colorful
> descriptions to get help, you need to describe just what is wrong. What
> do you actually see that is not right?

I see on output XXXX...


> - The equation for signal 'zmienna' is questionable. Combinatorial
> processes where you have a signal on both sides are a problem (i.e.
> zmienna <= zmienna + 1). This should've produced a warning about a
> combinatorial loop....look for it.

so how can I increment value?



> - The signal zmienna does not get assigned in every path through that
> combinatorial process. This will produce a latch which is generally a
> problem. Once again, the synthesis tool should've produced a warning
> about this, look for it

ok, but i wanted increment variable only in one state...


> As a general rule, try not to use combinatorial processes (i.e. a process
> that is sensitive to anything other than the rising edge of a clock). The
> reason is that it is far too easy to make the types of mistakes that
> you've made in your example.


and what do zou think about it

process (P_I_CLK,Rst)
begin
if (Rst='1') then zmienna <= 0 ;
elsif (P_I_CLK'event and P_I_CLK='1') then

zmienna<= zmienna+1;

end if;

end process;

process(zmienna)
begin
if (zmienna=3) then wynik<="1111";
else
wynik<="0000";
end if;



Second process sensitived on signal changed in other process.


zlotawy

"zlotawy" <> wrote in message
news:...
>
> U¿ytkownik "KJ" <> napisa³ w wiadomo¶ci
> news:yT1ah.9905$ m...
>>
>> "zlotawy" <> wrote in message
>> news:...
>>>
>>> U¿ytkownik "KJ" <> napisa³ w wiadomo¶ci
>>> news:Vk_9h.6398$ t...
>>>>
>>>> What the heck does that mean? An unsatisfied port??
>>>
>>> In ideal simulation all is OK. In post-route simulation there are
>>> divergences and clutters..
>> Answering the question 'what do you mean my unsatisfied port?' with
>> 'divergences and clutters' is equally unhelpful. You don't need colorful
>> descriptions to get help, you need to describe just what is wrong. What
>> do you actually see that is not right?
>
> I see on output XXXX...
And that's because of the combinatorial loops that you created....

>
>
>> - The equation for signal 'zmienna' is questionable. Combinatorial
>> processes where you have a signal on both sides are a problem (i.e.
>> zmienna <= zmienna + 1). This should've produced a warning about a
>> combinatorial loop....look for it.
>
> so how can I increment value?
See below....you already did it.
>
>
>
>> - The signal zmienna does not get assigned in every path through that
>> combinatorial process. This will produce a latch which is generally a
>> problem. Once again, the synthesis tool should've produced a warning
>> about this, look for it
>
> ok, but i wanted increment variable only in one state...
See below for my markup of your process
>
>
>> As a general rule, try not to use combinatorial processes (i.e. a process
>> that is sensitive to anything other than the rising edge of a clock).
>> The reason is that it is far too easy to make the types of mistakes that
>> you've made in your example.
>
>
> and what do zou think about it
>
KJ modified to...
process (P_I_CLK)
begin
if rising_edge(P_I_CLK) then
if (Rst='1') then zmienna <= 0 ;
elsif S_THIS = Idle then
zmienna<= zmienna+1;
end if;
end if;
end process;
>
> process(zmienna)
> begin
> if (zmienna=3) then wynik<="1111";
> else
> wynik<="0000";
> end if;
>
>
>
> Second process sensitived on signal changed in other process.
>
>
> zlotawy
>

zlotawy wrote:
> Uzytkownik "Al" <> napisal w wiadomosci
> news:eka3cl$7s7$...
>
>>Hi zlotawy,
>>first I suggest you to use more meaningful names (english is preferrable
>>to let other people understand the code) for your states and signals,
>>secondly I just noticed that your wynick signal is not registered and this
>>can be the cause of your "clutters".
>
>
>
> should I not send value direct to port?
>
> By signal, and from signal to port is the same problem.
>
>
> Moreover your zmienna looks
>
>>like a counter, but there is no clock on the process, is this that you
>>want?
>
>
> hmm.....
>
> If i make counter with clock, wynik is beautifull.
>
> "
> process (P_I_CLK,Rst)
> begin
> if (Rst='1') then zmienna <= 0 ;
> elsif (P_I_CLK'event and P_I_CLK='1') then
>
> zmienna<= zmienna+1;
>
> end if;
>
> end process;
>
> process(zmienna)
> begin
> if (zmienna=3) then wynik<="1111";
> else
> wynik<="0000";
> end if;
> "

I wouldn't have done this the same. If your output is not registered it
will have glitches in most of the cases.
KJ's solution for zmienna is exactly what I meant, but it is not enough
to me to have a "clean" wynik.
Try this:

process(P_I_CLK, Rst)
begin
if Rst = '1' then
wynik <= "0000";
elsif (P_I_CLK'event and P_I_CLK='1') then
if zmienna = "11" then
wynik <= "1111";
..... -- al your cases here.
else
wynik <= "0000";
end if;
end if;
end process;

In this case your wynick is registered and it will not show glitches.
>
> But I wanted count how many times, state was Idle...not how many were rising
> clock.

Follow KJ's suggestion to count only when idle.
Cheers

Al

--
Alessandro Basili
CERN, PH/UGC
Hardware Designer