cannot be synthesized, bad synchronous description

[Zenock]

Hello:

I'm new to VHDL and am running into some trouble. I know the code
listed below doesn't work. I don't understand exactly why it doesn't
work.

Basically, I can't figure out why I can't trigger off a rising AND a
falling edge only one or the other. So in essence, I want to know, what
is the correct way to do this?

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;

entity light_seqv is
Port(
Pulse_in :in std_logic;
Pulse_out ut std_logic;
Run_stop ut std_logic
);
end light_seqv;

architecture Behavioral of light_seqv is
Constant FALSE : std_logic := '0';
Constant TRUE : std_logic := '1';
Constant zero4 : std_logic_vector(3 downto 0) := "0000";
signal count_up : std_logic_vector(3 downto 0) :=zero4;
signal i_cnt : std_logic := '0';
signal run : std_logic := '0';

begin
process (Pulse_in)
begin
if Rising_edge(Pulse_in) Then
if count_up = 0 or count_up = 2 or count_up = 12 Then
i_cnt <= TRUE;
count_up <= count_up + 1;
elsif count_up = 14 Then
i_cnt <= TRUE;
count_up <= zero4;
run <= TRUE;
else
i_cnt <=FALSE;
count_up <= count_up + 1;
end if;
elsif Falling_edge(Pulse_in) Then
i_cnt <= FALSE;
run <= FALSE;
end if;
end process;

Pulse_out <= i_cnt;
Run_stop <= run;
end Behavioral;

Trying to do this in XILINX Web Pac repeatedly gives me...
Signal i_cnt cannot be synthesized, bad synchronous description

Basically what the module is count the clock pulses, on the very 1st,
3rd, 12th, and 15th pulse it needs to output a pulse. On the 15th
pulse it needs to set the count back to 0 so it can start over again
and send an additional signal to let another module no that the 15th
pulse was reached.

 

[Ralf Hildebrandt]

Zenock wrote:

I'm new to VHDL and am running into some trouble. I know the code
listed below doesn't work. I don't understand exactly why it doesn't
work.

process (Pulse_in)
begin
if Rising_edge(Pulse_in) Then ....
elsif Falling_edge(Pulse_in) Then ....
end process;

Do not use both edges - use only one. Only very few synthesis tools and
libraries are capable of dual-edge flipflops.

Rule for the thumb: Don't use an else / elsif branch after an 'event
(rising_edge() / faling_edge()).


If you really need dual-edge behavior, there are ways to model it, but
in general: Try to avoid it as long as possible!

Ralf

 

[charles.elias]

Below is my version of your code. I don't use IEEE.STD_LOGIC_ARITH
because it is not really an ieee standard. Instead I have used
ieee.numeric_std and used the type unsigned for count_up. Some of the
other changes I made are just a matter of personal style (for example,
I don't like to use true and false--already defined for type
boolean--in place of '1' and '0'). In any case, you don't need the
falling_edge(pulse_in) stuff. As a general rule you can't synthesize
logic that triggers on both clock edges. There is at least one
exception to this, but you really don't need it here. All of that said,
the code below will fix your bad synchronous description error, but it
may not do exactly what you intend. Here is a summary of my simulation
results:

On the first count sequence pulse_out is '1' during count_up counts 1,
3 and 13; run_stop is '0' for counts 0...14. After this, pulse_out is
'1' for counts 0, 1, 3 and 13; run_stop is '1' for count '0'.

Best regards,

Charles



library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
--use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.NUMERIC_STD.ALL;


entity light_seqv is
Port(
Pulse_in :in std_logic;
Pulse_out ut std_logic;
Run_stop ut std_logic
);
end light_seqv;


architecture Behavioral of light_seqv is
-- Constant FALSE : std_logic := '0';
-- Constant TRUE : std_logic := '1';
-- Constant zero4 : std_logic_vector(3 downto 0) := "0000";
signal count_up : unsigned(3 downto 0) := (others => '0');
signal i_cnt : std_logic := '0';
signal run : std_logic := '0';


begin
process (Pulse_in)
begin
if Rising_edge(Pulse_in) Then
if count_up = 0 or count_up = 2 or count_up = 12 Then
i_cnt <= '1';
count_up <= count_up + 1;
Run <= '0';
elsif count_up = 14 Then
i_cnt <= '1';
count_up <= (others => '0');
run <= '1';
else
i_cnt <= '0';
Run <= '0';
count_up <= count_up + 1;
end if;
end if;
end process;


Pulse_out <= i_cnt;
Run_stop <= run;
end Behavioral;

 

[Andy Peters]

Below is my version of your code. I don't use IEEE.STD_LOGIC_ARITH
because it is not really an ieee standard. Instead I have used
ieee.numeric_std and used the type unsigned for count_up.

Ya know, it's funny. I just installed Xilinx' ISE 7.1 and I was
"thumbing" through the XST manual looking to see how certain things are
inferred.

The example code to infer an "Unsigned 8-bit Adder" (page 105) uses the
old Synopsys std_logic_arith and std_logic_unsigned libraries. In
fact, all of the examples use these libraries!

Maybe these libraries would shrivel up and die if the tools vendors
stopped using them in examples. Then again, the examples still use
VHDL'87 syntax (hello! rising_edge(clk), anyone?) in a document
copyrighted 2005.

Sheesh!

-a

 

[Tim Hubberstey]

Ya know, it's funny. I just installed Xilinx' ISE 7.1 and I was
"thumbing" through the XST manual looking to see how certain things are
inferred.

The example code to infer an "Unsigned 8-bit Adder" (page 105) uses the
old Synopsys std_logic_arith and std_logic_unsigned libraries. In
fact, all of the examples use these libraries!

Maybe these libraries would shrivel up and die if the tools vendors
stopped using them in examples.

They won't do anything unless they hear the complaints. After all, the
code *is* correct, just outdated.

You should forward your post to Xilinx; maybe something will happen.

I don't know if we'll ever get rid of std_logic_unsigned and
std_logic_signed. There are too many designers around that prefer the
convenience of not having to deal with type conversions (BTW: I'm not
one of them).

What _might_ speed the demise of these libraries would be a utility to
automatically convert std_logic_arith, std_logic_unsigned, or
std_logic_signed code into numeric_std code. Without having done an in
depth analysis, I think it should be fairly simple. Then all that legacy
code using the old libraries could be (relatively) painlessly recovered.

Then again, the examples still use
VHDL'87 syntax (hello! rising_edge(clk), anyone?) in a document
copyrighted 2005.

This is a different issue. rising_edge(clk) is _not_ the same as
(clk'event and clk=1) for non-synthesized code. Changing over without
careful checking could result in "interesting" behavior in test benches.

 

[Divyang M]

Interesting discussion on which libraries to use.
I've switched over the IEEE compliant libraries and have even taken the
liberty to use the upcoming VHDL-200X libraries (mostly the fixed-point
library), hoping that by the time I am writing up the documentation for
my code (last quarter of 2005), they will become a standard. I can
then claim my design is IEEE Compliant

And Tim, I have a question for you. I noticed P.Eng in your signature,
and am wondering (being in the software/hardware field myself, but I am
still a graduate student), when is this designation required or
preffered in this field. I have always noticed that in electrical,
mechanical, or civil etc..many positions here in Canada require a
P.Eng, but have not come across this in the HW/SW field. I am asking
this because I am also looking into getting a P.Eng and want to find
out more.

Cheers,
Divyang M

 

[prashant.v.joshi]

hi..... please help out...
while synthesising vhdl code iam getting error as
"clk1 singnal cant be synthesised, bad synchronous discription".. here is vhdl code:
if(clk'event and clk='1')then
sig<=clk;
clk1<='1';
elsif(clk1'event and clk1='1')then
clk1<='0' after 10 ns;
end if;

please help me out....

 

[vipinlal]

@prashant: this kind of coding will not working in synthesize.check this link:
vhdlguru.blogspot.com/2010/03/can-you-change-signal-at-both-positive.html