Flipflops

[Thomas Heller]

Up to now, I have always used processes to create flipflops:

process(clock)
begin
if rising_edge(clock) then
a <= b;
end if;
end process;

Is the following code exactly equivalent? It is much
less verbose and much more readable:

a <= b when rising_edge(clock);

Thanks,
Thomas

 

[Thomas Heller]

Am 22.06.2012 08:39, schrieb goouse99@googlemail.com:

Am Freitag, 22. Juni 2012 08:00:48 UTC+2 schrieb Thomas Heller:
Up to now, I have always used processes to create flipflops:

process(clock)
begin
if rising_edge(clock) then
a <= b;
end if;
end process;

Is the following code exactly equivalent? It is much
less verbose and much more readable:

a <= b when rising_edge(clock);

Thanks,
Thomas

Hi Thomas.
We live in a time where reliable synthesis tools are available without costs.
Why didn't you just try it?

I did try it, and it worked in practice. However, I wanted to make sure
that my understanding is correct and that the two examples are really
describing exactly the same thing.

But tell us one thing:
Are you really coding each simple FF separately?
What about Resets?
What about ClockEnables?
What about really complex algorithms that could be done within a single synchronous process?

I will probably use it for throw-away debug code, where I need to bring
out internal signals to the outside in cases where I need pipelining
to meet the timing constraints.

Anyway, thanks for the answer and the comments.
Thomas

 

[HT-Lab]

On 22/06/2012 07:00, Thomas Heller wrote:

Up to now, I have always used processes to create flipflops:

process(clock)
begin
if rising_edge(clock) then
a <= b;
end if;
end process;

Is the following code exactly equivalent? It is much
less verbose and much more readable:

a <= b when rising_edge(clock);

Thanks,
Thomas

There is an interesting VHDL20xx proposal which takes this a step further,

http://www.eda.org/twiki/bin/view.cgi/P1076/ClockedShorthand

Hans
www.ht-lab.com

 

Am Freitag, 22. Juni 2012 08:00:48 UTC+2 schrieb Thomas Heller:

Up to now, I have always used processes to create flipflops:

process(clock)
begin
if rising_edge(clock) then
a <= b;
end if;
end process;

Is the following code exactly equivalent? It is much
less verbose and much more readable:

a <= b when rising_edge(clock);

Thanks,
Thomas

Hi Thomas.
We live in a time where reliable synthesis tools are available without costs.
Why didn't you just try it?

To save you the two minutes to test it I tell you the result observed with ISE14 XST:
Yes, it perfectly synthesizes a nice DFF.
No messages like "not a synchronous description" appeared.

But tell us one thing:
Are you really coding each simple FF separately?
What about Resets?
What about ClockEnables?
What about really complex algorithms that could be done within a single synchronous process?

Will the verbosity and readability of the code remain?

I truly appreciate the simpleness of the example and was really surprised that it worked. But I doubt that it has a great practical use, because it really only holds for this simple FF type.

Have a nice synthesis
Eilert

 

[Andy]

On Jun 22, 1:39 am, goous...@googlemail.com wrote:

Am Freitag, 22. Juni 2012 08:00:48 UTC+2 schrieb Thomas Heller:





Up to now, I have always used processes to create flipflops:

process(clock)
begin
   if rising_edge(clock) then
     a <= b;
   end if;
end process;

Is the following code exactly equivalent?  It is much
less verbose and much more readable:

a <= b when rising_edge(clock);

Thanks,
Thomas

Hi Thomas.
We live in a time where reliable synthesis tools are available without costs.
Why didn't you just try it?

To save you the two minutes to test it I tell you the result observed with ISE14 XST:
Yes, it perfectly synthesizes a nice DFF.
No messages like "not a synchronous description" appeared.

But tell us one thing:
Are you really coding each simple FF separately?
What about Resets?
What about ClockEnables?

q <= '0' when reset = '1'
else d when rising_edge(clk) and clk_enable = '1';

What about really complex algorithms that could be done within a single synchronous process?

True, when you have a complex algorithm and especially multiple
registers, a process wins hands-down.

But when all you need is a simple register (especially in an otherwise
structural architecture), this works fine with far less code, without
giving up readability.

One side effect: the resulting process from the concurrent assignment
includes d and clk_enable in the sensitivity list. If you code a lot
of them, it will slow down your simulation (compared to an
architecture consisting solely of synchronous processes).

Andy