Newbie question on combining if rising_edge(clk).

Hi,

I am learning vhdl and found when writing a simple clock divider I did a
if rising_edge(clk) and div=someval. ISE throws an error saying "The description style you are using to describe a synchronous element (register, memory, etc.) is not supported in the current software release."

I rearranged it to do
if(rising_edge(clk) then
if (div = someval)
....
and it works fine. I don't seem to understand what seems to be wrong?

Thanks,
Gautam.

 

[alb]

On 11/07/2013 08:16, mindentropy@gmail.com wrote:

Hi,

I am learning vhdl and found when writing a simple clock divider I
did a if rising_edge(clk) and div=someval. ISE throws an error
saying "The description style you are using to describe a
synchronous element (register, memory, etc.) is not supported in the
current software release."

I think it would be useful to know other details like which version of
ISE and which technology you are targeting.
Moreover the complete error reported by ISE is:

ERROR:Xst:827 - Signal *** cannot be synthesized, bad synchronous
description. The description style you are using to describe a
synchronous element (register, memory, etc.) is not supported in the
current software release.

<nitpick mode ON>
With such a long error message some people decide to post only the first
sentence, some others only the second, some other again just a part of
the two sentences. IMO either the full message should be reported or
only the unique part which is essentially the error code.
<nitpick mode OFF>

Searching with Google I nevertheless got this as *first* hit:

http://forums.xilinx.com/t5/Archived-ISE-issues/Xst-827-Problem-please-help-me-thx/td-p/20673

which points to the solution:

http://www.xilinx.com/support/answers/14047.htm

I rearranged it to do if(rising_edge(clk) then if (div = someval)
.... and it works fine. I don't seem to understand what seems to be
wrong?

I would add a little context to the 'if' statement since it is possible
that the error is hiding somewhere near it but nobody will ever know
without the code. I always struggle a lot when I have to post code since
sometimes simplified examples might be not representative of your actual
case (therefore ending being just an academic discussion) while other
times your actual case might need too much context to be understood and
investigated.

HTH.

 

[rickman]

On 7/11/2013 2:16 AM, mindentropy@gmail.com wrote:

Hi,

I am learning vhdl and found when writing a simple clock divider I did a
if rising_edge(clk) and div=someval. ISE throws an error saying "The description style you are using to describe a synchronous element (register, memory, etc.) is not supported in the current software release."

I rearranged it to do
if(rising_edge(clk) then
if (div = someval)
....
and it works fine. I don't seem to understand what seems to be wrong?

Thanks,
Gautam.

To write it out more clearly...

if (A and B) then
stuff;
end if;

compared to...

if (A) then
if (B) then
stuff;
end if;
end if;

Where A is rising_edge().

The second form is easier for tools to see what you intend. Synthesis
does not necessarily result from function. It results from form. This
is just a feature of the synthesis tool it is not really a language
issue. But it does make the code easier for others to read as well.

--

Rick

 

[alb]

On 11/07/2013 13:07, rickman wrote:
[]

To write it out more clearly...

if (A and B) then
stuff;
end if;

compared to...

if (A) then
if (B) then
stuff;
end if;
end if;

Where A is rising_edge().

The second form is easier for tools to see what you intend. Synthesis
does not necessarily result from function. It results from form. This
is just a feature of the synthesis tool it is not really a language
issue. But it does make the code easier for others to read as well.

shouldn't the first form correspond to a gated clock, where the second
to just a clock enable? If this is the case the difference between the
two is *a lot*.

If we are not talking about clocked processes than AFAIK the two forms
should be completely equivalent.

 

[Sean Durkin]

rickman wrote:

To write it out more clearly...

if (A and B) then
stuff;
end if;

compared to...

if (A) then
if (B) then
stuff;
end if;
end if;

Where A is rising_edge().

The second form is easier for tools to see what you intend. Synthesis
does not necessarily result from function. It results from form. This
is just a feature of the synthesis tool it is not really a language
issue. But it does make the code easier for others to read as well.

This is not just an issue of form. The two descriptions actually
describe different things, since priorities are different.

The second description first checks for A, and only if that is met is B
even evaluated. So if A is rising_edge(), this forces the tool to
synthesize an entity that reacts to EVERY rising_edge, and then does
"stuff" if B is true. So this is basically a simple flip-flop or other
synchronous element with a synchronous reset, set or a synchronous clock
enable (depending on what "stuff" actually is); no problem there, since
that is exactly what Xilinx' flipflops are.

The first description on the other hand checks for A and B
simultaneously. So if A is rising_edge(), that would mean you want to
synthesize some entity that only reacts to clock edges under specific
circumstances, resulting in something like an asynchronous clock enable,
or a register with built-in clock gating or something.
And that is something that does not exist per se in the Xilinx
architecture and/or is highly recommended against (in the case of clock
gating), so there's no way for XST to correctly automatically synthesize
something that behaves in a way that matches what is described. Hence
the error message, and since this is a common mistake, they warrant a
guess as to what you really wanted to describe.

Xilinx White Paper WP275
(http://www.xilinx.com/support/documentation/white_papers/wp275.pdf) is
quite interesting, the topic is similar.

Greetings,
Sean

 

[rickman]

On 7/11/2013 7:55 AM, alb wrote:

On 11/07/2013 13:07, rickman wrote:
[]
To write it out more clearly...

if (A and B) then
stuff;
end if;

compared to...

if (A) then
if (B) then
stuff;
end if;
end if;

Where A is rising_edge().

The second form is easier for tools to see what you intend. Synthesis
does not necessarily result from function. It results from form. This
is just a feature of the synthesis tool it is not really a language
issue. But it does make the code easier for others to read as well.

shouldn't the first form correspond to a gated clock, where the second
to just a clock enable? If this is the case the difference between the
two is *a lot*.

If we are not talking about clocked processes than AFAIK the two forms
should be completely equivalent.

Even if you are talking about gated processes (A is rising_edge(x)),
there is nothing functionally different about the two. They will
simulate exactly the same.

My point is that while simulation will show an equivalence between the
two, the synthesis tools can make distinctions based on "form" meaning
exactly how you write the code.

Logically speaking, why would the first be a gated clock but not the
second? There is nothing in the VHDL standard that mentions gated vs.
enabled clocks. I think there is a standard for synthesis but I don't
know if it covers gated clocks. Anyone know?

--

Rick

 

[rickman]

On 7/11/2013 1:23 PM, Jim Lewis wrote:

Dear Xilinx,
While, 1076.6-1999 (VHDL RTL Synthesis Standard) only requires that the following is supported:

process(clk)
begin
if rising_edge(Clk) then
if (div = someval) then
...

IEC 62050-2005 (was IEEE 1076.6-2004) requires that the following is supported as a flip-flop with load enable (gating on data path):

process(clk)
begin
if rising_edge(Clk) and (div = someval) then
...

I disagree with @Sean's analysis. The "A and B" does not check them both simultaneously if the results are boolean. Instead, "and" is a short circuit operator, and when it determines the rising edge is false it has determined the result is false, does not analyze B. Hence, from a VHDL perspective the code runs the same. You could make arguments about reversing the order of the clock, however, IEC 62050-2005 still treats it as a flip-flop with load enble.

Historically ASIC vendors have use an attribute with the 1076.6-1999 style to transform it from a data path enable to a clock gate.


What is happening here is called market driven support of standards. From a vendors perspective, why spend money and support features unless their users are asking for them. From a user's perspective, when a vendor takes this position, they stifle progress within the industry.

_If you are a Xilinx customer_, please submit a bug report on this and cite IEC 62050-2005 (was IEEE 1076.6-2004) as a reference. Make sure to reference the IEC standard as I think the IEEE version was deprecated.


If you want to know more about some of the IEC 62050-2005 /1076.6-2004 coding styles, check out my 2002 HDLCon paper, "Extensions to the VHDL RTL Synthesis Standard" on the page:
http://www.synthworks.com/papers/

It really is shameful that 9 years have gone by since the standard was finalized and 11 since my paper and Xilinx still does not support these.

Going further, there is so much more we should be able to do that has not been covered in the RTL synthesis standard yet. If anyone is interested in this effort, I can advise you on working through the IEEE standards process. You will need to get the synthesis vendors on board to insure it gets supported.

Best Regards,
Jim Lewis
IEEE 1076 Working Group Chair
Former IEEE 1076.6 Vice Chair
VHDL Training Expert, SynthWorks

Looks like you answered my questions from the post I just made. I
should have finished reading the thread before I replied.

Thanks for the info, this is just what I couldn't remember.

--

Rick

 

[rickman]

On 7/11/2013 1:50 PM, rickman wrote:

On 7/11/2013 7:55 AM, alb wrote:
On 11/07/2013 13:07, rickman wrote:
[]
To write it out more clearly...

if (A and B) then
stuff;
end if;

compared to...

if (A) then
if (B) then
stuff;
end if;
end if;

Where A is rising_edge().

The second form is easier for tools to see what you intend. Synthesis
does not necessarily result from function. It results from form. This
is just a feature of the synthesis tool it is not really a language
issue. But it does make the code easier for others to read as well.

shouldn't the first form correspond to a gated clock, where the second
to just a clock enable? If this is the case the difference between the
two is *a lot*.

If we are not talking about clocked processes than AFAIK the two forms
should be completely equivalent.

Even if you are talking about gated processes (A is rising_edge(x)),
Correction......................^^^^^ should be "clocked"...

there is nothing functionally different about the two. They will
simulate exactly the same.

My point is that while simulation will show an equivalence between the
two, the synthesis tools can make distinctions based on "form" meaning
exactly how you write the code.

Logically speaking, why would the first be a gated clock but not the
second? There is nothing in the VHDL standard that mentions gated vs.
enabled clocks. I think there is a standard for synthesis but I don't
know if it covers gated clocks. Anyone know?

--

Rick

 

[Jim Lewis]

Dear Xilinx,
While, 1076.6-1999 (VHDL RTL Synthesis Standard) only requires that the following is supported:

process(clk)
begin
if rising_edge(Clk) then
if (div = someval) then
...

IEC 62050-2005 (was IEEE 1076.6-2004) requires that the following is supported as a flip-flop with load enable (gating on data path):

process(clk)
begin
if rising_edge(Clk) and (div = someval) then
...

I disagree with @Sean's analysis. The "A and B" does not check them both simultaneously if the results are boolean. Instead, "and" is a short circuit operator, and when it determines the rising edge is false it has determined the result is false, does not analyze B. Hence, from a VHDL perspective the code runs the same. You could make arguments about reversing the order of the clock, however, IEC 62050-2005 still treats it as a flip-flop with load enble.

Historically ASIC vendors have use an attribute with the 1076.6-1999 style to transform it from a data path enable to a clock gate.


What is happening here is called market driven support of standards. From a vendors perspective, why spend money and support features unless their users are asking for them. From a user's perspective, when a vendor takes this position, they stifle progress within the industry.

_If you are a Xilinx customer_, please submit a bug report on this and cite IEC 62050-2005 (was IEEE 1076.6-2004) as a reference. Make sure to reference the IEC standard as I think the IEEE version was deprecated.


If you want to know more about some of the IEC 62050-2005 /1076.6-2004 coding styles, check out my 2002 HDLCon paper, "Extensions to the VHDL RTL Synthesis Standard" on the page:
http://www.synthworks.com/papers/

It really is shameful that 9 years have gone by since the standard was finalized and 11 since my paper and Xilinx still does not support these.

Going further, there is so much more we should be able to do that has not been covered in the RTL synthesis standard yet. If anyone is interested in this effort, I can advise you on working through the IEEE standards process.. You will need to get the synthesis vendors on board to insure it gets supported.

Best Regards,
Jim Lewis
IEEE 1076 Working Group Chair
Former IEEE 1076.6 Vice Chair
VHDL Training Expert, SynthWorks

 

On Thursday, July 11, 2013 10:53:32 PM UTC+5:30, Jim Lewis wrote:

Dear Xilinx,

While, 1076.6-1999 (VHDL RTL Synthesis Standard) only requires that the following is supported:



process(clk)

begin

if rising_edge(Clk) then

if (div = someval) then

...



IEC 62050-2005 (was IEEE 1076.6-2004) requires that the following is supported as a flip-flop with load enable (gating on data path):



process(clk)

begin

if rising_edge(Clk) and (div = someval) then

...



I disagree with @Sean's analysis. The "A and B" does not check them both simultaneously if the results are boolean. Instead, "and" is a short circuit operator, and when it determines the rising edge is false it has determined the result is false, does not analyze B. Hence, from a VHDL perspective the code runs the same. You could make arguments about reversing the order of the clock, however, IEC 62050-2005 still treats it as a flip-flop with load enble.



Historically ASIC vendors have use an attribute with the 1076.6-1999 style to transform it from a data path enable to a clock gate.





What is happening here is called market driven support of standards. From a vendors perspective, why spend money and support features unless their users are asking for them. From a user's perspective, when a vendor takes this position, they stifle progress within the industry.



_If you are a Xilinx customer_, please submit a bug report on this and cite IEC 62050-2005 (was IEEE 1076.6-2004) as a reference. Make sure to reference the IEC standard as I think the IEEE version was deprecated.





If you want to know more about some of the IEC 62050-2005 /1076.6-2004 coding styles, check out my 2002 HDLCon paper, "Extensions to the VHDL RTL Synthesis Standard" on the page:

http://www.synthworks.com/papers/



It really is shameful that 9 years have gone by since the standard was finalized and 11 since my paper and Xilinx still does not support these.



Going further, there is so much more we should be able to do that has not been covered in the RTL synthesis standard yet. If anyone is interested in this effort, I can advise you on working through the IEEE standards process. You will need to get the synthesis vendors on board to insure it gets supported.



Best Regards,

Jim Lewis

IEEE 1076 Working Group Chair

Former IEEE 1076.6 Vice Chair

VHDL Training Expert, SynthWorks

Thanks Jim for clarifying.

 

[valtih1978]

wait until clk = '1';

requires less typing than

if clk = '1' then
end if;

and, furthremore, causes less confusion than the conditional. I wonder
why people keep reproducing this awkward IF pattern instead of wait
until. Single wait until synthesizes well, even in xilinx tools now.
I've checked that may times.

 

[rickman]

On 7/16/2013 8:47 AM, valtih1978 wrote:

wait until clk = '1';

requires less typing than

if clk = '1' then
end if;

and, furthremore, causes less confusion than the conditional. I wonder
why people keep reproducing this awkward IF pattern instead of wait
until. Single wait until synthesizes well, even in xilinx tools now.
I've checked that may times.

What is the related code for an async resettable FF?

--

Rick

 

Am Dienstag, 16. Juli 2013 14:47:49 UTC+2 schrieb valtih1978:

wait until clk = '1';



requires less typing than



if clk = '1' then

end if;



and, furthremore, causes less confusion than the conditional. I wonder

why people keep reproducing this awkward IF pattern instead of wait

until. Single wait until synthesizes well, even in xilinx tools now.

I've checked that may times.

Hi,
wait until clk = '1';

actually creates latches, which most of us are trying to avoid.

What you probably mean is:

wait until rising_edge(clk);

And to answer rickmans question too:
Yes this coding style makes it hard, if not impossible to implement a (async) reset.
However, there are many applications that neither need this.
There's also this famous paper from Xilinx suggestiong to avoid async resets when possible.
But of course, if one needs it, the well known
if reset then
elsif rising_edge(clk)
does the job pretty well, and for thos who whant to save time typing code:
Use EMACS with VHDL mode.
Then 90% of the code is writing itself.
Just make sure you have a reliable TAB button on your keyboard.

Have a nice synthesis
Eilert

 

[valtih1978]

What is the problem? Can you be more specific?

Should I care using the async pattern because async reset is depricated
and I never use it? Why should I care about the related code?

Is it the only argument you have?

 

[valtih1978]

Rising_edge(clk) is basically equivalent to

process
wait on clk; -- implied by sensetivity list
if clk'event and clk = '1' then
<body>
end if;

end process;

whereas wait until clk='1' is equivalent to (see VHDL spec)

process
loop
wait on Clk;
exit when Clk = '1';
end loop;
<body>
end process

Tell me the difference. I see waiting for the edge in both cases. Does
latch mean the edge-sensitive storage? So, might be it is your
rising_edge that produces the latch? Why double standards?

Do you say that bad style is popular because people mistakenly think
that good style produces the latches?

 

[rickman]

On 7/17/2013 5:58 AM, valtih1978 wrote:

What is the problem? Can you be more specific?

Should I care using the async pattern because async reset is depricated
and I never use it? Why should I care about the related code?

Is it the only argument you have?

I'm asking how you would use this form to generate an async reset on the
FF. Who exactly has "deprecated" the async reset? If you never use it,
that's fine, but I design FPGAs which use an async reset. If you don't
specify a reset the register value is defaults to zero in most cases. I
prefer to define a reset value because it can be useful and it makes the
synthesis match the simulation.

I see no advantage to this form. It may be fewer keystrokes, but my
design process is not limited by the number keys I press. I type very
fast. If I waw worried about the number of keys I press, I wouldn't be
using VHDL at all.

--

Rick

 

[valtih1978]

It is not just a number of keystrokes. You have extra IF-then nest to
handle, which complicates the structure of your code whereas wait until
just makes the wait for clk edge explicit. But, thanks for the argument.

 

[Rob Gaddi]

On Tue, 16 Jul 2013 22:45:20 -0700 (PDT)
goouse99@gmail.com wrote:

Am Dienstag, 16. Juli 2013 14:47:49 UTC+2 schrieb valtih1978:
wait until clk = '1';



requires less typing than



if clk = '1' then

end if;



and, furthremore, causes less confusion than the conditional. I wonder

why people keep reproducing this awkward IF pattern instead of wait

until. Single wait until synthesizes well, even in xilinx tools now.

I've checked that may times.

Hi,
wait until clk = '1';

actually creates latches, which most of us are trying to avoid.

What you probably mean is:

wait until rising_edge(clk);

And to answer rickmans question too:
Yes this coding style makes it hard, if not impossible to implement a (async) reset.
However, there are many applications that neither need this.
There's also this famous paper from Xilinx suggestiong to avoid async resets when possible.
But of course, if one needs it, the well known
if reset then
elsif rising_edge(clk)
does the job pretty well, and for thos who whant to save time typing code:
Use EMACS with VHDL mode.
Then 90% of the code is writing itself.
Just make sure you have a reliable TAB button on your keyboard.

Have a nice synthesis
Eilert

I think this is one of the rare instances where you're wrong.
wait until clk = '1';
is equivalent to
wait on clk until clk = '1';
which is the same as
wait until rising_edge(clk)
if clk can only be '0' or '1'.

Likewise the OP's
if clk = '1' then
in a process where clk was the only thing in the sensitivity list
should have the same behavior as any of that, or of the more traditional
if rising_edge(clk) then

I've used the "wait until" form in synthesizable code a couple times.
It seems to work, at least on modern synthesizers, and it's nice to save
one level of indentation, but it's not a huge deal one way or another.
It does make an async reset pretty impossible, for what that's worth in
whichever circumstances.

I think my biggest problem with it stylistically is that it's simply
not canonical. The synthesizer can take in all manner of things that,
handed off to someone who didn't write them, would cause
consternation. The goal of writing code is to produce something that
not only performs correctly, but is intuitively and obviously correct
to anyone who sits down to read it. Part of that is doing commonly
done things in the way they're commonly done.

--
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order. See above to fix.

 

[rickman]

On 7/17/2013 11:04 AM, valtih1978 wrote:

It is not just a number of keystrokes. You have extra IF-then nest to
handle, which complicates the structure of your code whereas wait until
just makes the wait for clk edge explicit. But, thanks for the argument.

Yeah, I understand what you are saying. I just don't consider any of
these advantages to be addressing problems I have when writing VHDL.

process (clk, reset inputs)
begin
IF (reset condition) then
reset assignments...
ELSIF (rising_edge(clk)) then
register assignments...
ENDIF;
end process;

This is just a form that is so common and recognizable that I have never
given any thought to the need to save a line or two or an indentation
level.

I have seen the form below used for simple FFs.

data_out <= data_in when rising_edge(clk);

This is the simplest form I am familiar with, one line, no indents! The
problem with the concurrent FF statement is that it is harder to add
much logic. The FF input signal would need to be defined by other
statements if the logic is very complex at all.

Of the three forms, I prefer to just use the clocked process and keep
the form constant. No one is confused and the registers are always
easily recognized.

BTW, I have not read the synthesis standard. Does that mention all
three of these forms? Does the standard say anything about
initialization in the signal declaration? That might make a big
difference in which forms are acceptable or preferred.

--

Rick

 

[Andy]

On Wednesday, July 17, 2013 10:04:36 AM UTC-5, valtih1978 wrote:

It is not just a number of keystrokes. You have extra IF-then nest to handle, which complicates the structure of your code whereas wait until just makes the wait for clk edge explicit. But, thanks for the argument.

It would be "safer" to use "wait until rising_edge(clk)", since "wait until clk = '1';" will trigger if clk changes from 'H' to '1' (not a rising edge), and will not trigger when clk changes from '0' to 'H' (a rising edge). For the synthesis tool it won't matter, but the RTL simulation will matter, potentially causing a simulation mismatch between RTL and gate level simulations.

If you need asynchronous reset (not a matter of choice for some design domains), then you'd have to wait for either/both of two events, and then you'd have to use an if-statement to figure out which condition triggered the wait statement.

BTW, an exit statement with a condition is equivalent to an if statement containing an unconditional exit statement. There are no free lunches.

Also, the implicit wait statement in a process with a sensitivity list is at the BOTTOM of the process, not at the top. No real difference for synthesis, but there are differences in simulation: all processes run at startup, regardless of the sensitivity list. Wait statements will not trigger at startup.

Andy