with clk'event, must we use clk='1' or clk='0' ?

[sunshinekisses@gmail.com]

Hi,

Consider this part of a hypothetical counter:

process (CLK)
if CLK'event then
if ClrN = '1' then Qint <= "00";
else Qint <= Qint + 1;
end if;
endif;
end process;

Is this legit as it is or MUST I have something like:

if CLK'event and Clk='1' then...

as the idea is to have a counter that changes with EVERY clock event,
not just the leading edge.

ty, -e

 

[Jonathan Bromley]

On Sat, 28 Jul 2007 21:52:47 -0000,
<sunshinekisses@gmail.com> wrote:

Consider this part of a hypothetical counter:

Hypothetical it certainly is.

process (CLK)
if CLK'event then
if ClrN = '1' then Qint <= "00";
else Qint <= Qint + 1;
end if;
endif;
end process;

Is this legit as it is or MUST I have something like:

if CLK'event and Clk='1' then...

as the idea is to have a counter that changes with EVERY clock event,
not just the leading edge.

How do you think this would be implemented in hardware?
Flip-flops that trigger on both edges of a clock are
as rare as rocking-horse shit. Synthesis tools rightly
complain if you try to imply such logic. The code that
you present is valid VHDL, but would not go through any
synthesis tool I know about.

However, it *is* possible to mimic double-data-rate (DDR)
behaviour such as this using standard single-edge FFs.
The big idea is to maintain two completely separate
sets of registers, one clocked on rising edges and
the other on falling edges. You then use the clock
itself to multiplex the appropriate registers' contents
on to your DDR output.

However, your specific problem of a double-edge binary
counter that's free-running would be rather simple if
you could forgo the reset. Consider making the counter
one bit shorter, and using the clock itself as the
least significant output bit - use the falling clock
edge to trigger the upper counter bit(s).

Here's the clock-muxing DDR counter: note the three
separate VHDL processes, and rather a lot of signals.

--- Rising-edge counter
process (clk)
begin
if rising_edge(clk) then
if clear = '1' then
QR <= (others => '0');
else
QR <= QN + 1;
end if;
end if;
end process;

--- Falling-edge counter
process (clk)
begin
if falling_edge(clk) then
if clear = '1' then
QN <= (others => '0');
else
QN <= QR + 1;
end if;
end if;
end process;

--- Output multiplexer controlled by clock
QDDR <= QR when clk = '1' else QN;

Don't ask me to pretend I like it.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

 

[Brian Drummond]

On Sat, 28 Jul 2007 21:52:47 -0000, "sunshinekisses@gmail.com"
<sunshinekisses@gmail.com> wrote:

Hi,

Consider this part of a hypothetical counter:

process (CLK)
if CLK'event then
if ClrN = '1' then Qint <= "00";
else Qint <= Qint + 1;
end if;
endif;
end process;

Is this legit as it is or MUST I have something like:

if CLK'event and Clk='1' then...

as the idea is to have a counter that changes with EVERY clock event,
not just the leading edge.

For simulation it should be fine.

However if you want to generate hardware this way, see Jonathan's
answer.

- Brian

 

[Andy]

On Jul 28, 5:56 pm, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com>
wrote:

On Sat, 28 Jul 2007 21:52:47 -0000,

sunshinekis...@gmail.com> wrote:
Consider this part of a hypothetical counter:

Hypothetical it certainly is.

process (CLK)
if CLK'event then
if ClrN = '1' then Qint <= "00";
else Qint <= Qint + 1;
end if;
endif;
end process;

Is this legit as it is or MUST I have something like:

if CLK'event and Clk='1' then...

as the idea is to have a counter that changes with EVERY clock event,
not just the leading edge.

How do you think this would be implemented in hardware?
Flip-flops that trigger on both edges of a clock are
as rare as rocking-horse shit. Synthesis tools rightly
complain if you try to imply such logic. The code that
you present is valid VHDL, but would not go through any
synthesis tool I know about.

However, it *is* possible to mimic double-data-rate (DDR)
behaviour such as this using standard single-edge FFs.
The big idea is to maintain two completely separate
sets of registers, one clocked on rising edges and
the other on falling edges. You then use the clock
itself to multiplex the appropriate registers' contents
on to your DDR output.

However, your specific problem of a double-edge binary
counter that's free-running would be rather simple if
you could forgo the reset. Consider making the counter
one bit shorter, and using the clock itself as the
least significant output bit - use the falling clock
edge to trigger the upper counter bit(s).

Here's the clock-muxing DDR counter: note the three
separate VHDL processes, and rather a lot of signals.

--- Rising-edge counter
process (clk)
begin
if rising_edge(clk) then
if clear = '1' then
QR <= (others => '0');
else
QR <= QN + 1;
end if;
end if;
end process;

--- Falling-edge counter
process (clk)
begin
if falling_edge(clk) then
if clear = '1' then
QN <= (others => '0');
else
QN <= QR + 1;
end if;
end if;
end process;

--- Output multiplexer controlled by clock
QDDR <= QR when clk = '1' else QN;

Don't ask me to pretend I like it.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.brom...@MYCOMPANY.comhttp://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

Another, non-glitchy way to implement a DDR register with single-edge
flops is to encode the data between two flops, one on each of the
clock edges, and decode the result combinatorially. What we need is a
function such that any input can change the output, no matter what the
other input is. The parity (XOR) function works very well for this,
but so would equality (XNOR). Because of the nature of these two
functions, this could also be expanded to an arbitraty number of
clocks/edges, so long as all clocks/edges are synchronously related,
and timing constraints between them are met.

Note that in the examples below, "dr" could be the same as "df", and
just use "d", and instead of rising and falling edges of the same
clock, two related (synchronously) clocks could be used. This
technique cannot be used for two asynchronous clocks. Naturally, this
could be done with SLV instead of SL as well.

re: process (clk, rst) is
begin
if rst = '1' then
qr <= '0';
elsif rising_edge(clk) then
qr <= dr xor qf;
end if;
end process re;

fe: process (clk, rst) it
begin
if rst = '1' then
qf <= '0';
elsif falling_edge(clk) then
qf <= df xor qr;
end if;
end process fe;

q <= qr xor qf;

Alternatively, some synthesis tools (synplify and others) support
multiple edges in the same process, so long as the same variable/
signal is not assigned on both edges. Also, some of them accept a
combinatorial assignment to a signal from an expression of variables,
after the clock clause:

be: process (clk, rst) is
variable qr, qf : std_logic;
begin
if rst = '1' then
qr := '0';
qf := '0';
elsif rising_edge(clk) then
qr := dr xor qf; -- encode
elsif falling_edge(clk) then
qf := df xor qr; -- encode
end if;
q <= qr xor qf; -- combo decode
end process;

Andy

 

[ast]

"Jonathan Bromley" <jonathan.bromley@MYCOMPANY.com> a écrit dans le message de news: nghna3hoh2sfg7t75sjt7snvdjstpf25hq@4ax.com...

On Sat, 28 Jul 2007 21:52:47 -0000,
sunshinekisses@gmail.com> wrote:

Consider this part of a hypothetical counter:

Hypothetical it certainly is.

process (CLK)
if CLK'event then
if ClrN = '1' then Qint <= "00";
else Qint <= Qint + 1;
end if;
endif;
end process;

Is this legit as it is or MUST I have something like:

if CLK'event and Clk='1' then...

as the idea is to have a counter that changes with EVERY clock event,
not just the leading edge.

How do you think this would be implemented in hardware?
Flip-flops that trigger on both edges of a clock are
as rare as rocking-horse shit. Synthesis tools rightly
complain if you try to imply such logic. The code that
you present is valid VHDL, but would not go through any
synthesis tool I know about.

However, it *is* possible to mimic double-data-rate (DDR)
behaviour such as this using standard single-edge FFs.
The big idea is to maintain two completely separate
sets of registers, one clocked on rising edges and
the other on falling edges. You then use the clock
itself to multiplex the appropriate registers' contents
on to your DDR output.

However, your specific problem of a double-edge binary
counter that's free-running would be rather simple if
you could forgo the reset. Consider making the counter
one bit shorter, and using the clock itself as the
least significant output bit - use the falling clock
edge to trigger the upper counter bit(s).

Here's the clock-muxing DDR counter: note the three
separate VHDL processes, and rather a lot of signals.

--- Rising-edge counter
process (clk)
begin
if rising_edge(clk) then
if clear = '1' then
QR <= (others => '0');
else
QR <= QN + 1;
end if;
end if;
end process;

--- Falling-edge counter
process (clk)
begin
if falling_edge(clk) then
if clear = '1' then
QN <= (others => '0');
else
QN <= QR + 1;
end if;
end if;
end process;

--- Output multiplexer controlled by clock
QDDR <= QR when clk = '1' else QN;

Don't ask me to pretend I like it.
--

This doesnt behave as a DDR counter
or i missed something

 

[Jonathan Bromley]

On Mon, 30 Jul 2007 16:13:18 +0200, "ast" <ast@ast.com> wrote:

"Jonathan Bromley" <jonathan.bromley@MYCOMPANY.com> a écrit
[...]

This doesnt behave as a DDR counter

Well, my brain and my simulator both agree that it does...

or i missed something

I wonder if you missed the fact that each half of the
counter increments the OTHER counter's count?
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

 

[ast]

"Jonathan Bromley" <jonathan.bromley@MYCOMPANY.com> a écrit dans le message de news: cf0sa3te0kocpb45o2m3b3rn2nf7e2nqk4@4ax.com...

On Mon, 30 Jul 2007 16:13:18 +0200, "ast" <ast@ast.com> wrote:


"Jonathan Bromley" <jonathan.bromley@MYCOMPANY.com> a écrit
[...]

This doesnt behave as a DDR counter

Well, my brain and my simulator both agree that it does...

or i missed something

I wonder if you missed the fact that each half of the
counter increments the OTHER counter's count?
--

oh yes, i understand now. nice trick.

 

[Dave Higton]

In message <nghna3hoh2sfg7t75sjt7snvdjstpf25hq@4ax.com>
Jonathan Bromley <jonathan.bromley@MYCOMPANY.com> wrote:

On Sat, 28 Jul 2007 21:52:47 -0000,
sunshinekisses@gmail.com> wrote:

Consider this part of a hypothetical counter:

Hypothetical it certainly is.

process (CLK)
if CLK'event then
if ClrN = '1' then Qint <= "00";
else Qint <= Qint + 1;
end if;
endif;
end process;

Is this legit as it is or MUST I have something like:

if CLK'event and Clk='1' then...

as the idea is to have a counter that changes with EVERY clock event,
not just the leading edge.

How do you think this would be implemented in hardware?
Flip-flops that trigger on both edges of a clock are
as rare as rocking-horse shit. Synthesis tools rightly
complain if you try to imply such logic. The code that
you present is valid VHDL, but would not go through any
synthesis tool I know about.

And since there have been at least two implementations
suggested in this newsgroup, I think it's high time the
synthesis vendors got off their bottoms and implemented
something.

After all, when someone writes VHDL for a counter in a
CPLD, the vendors don't bleat "Woe is me, this CPLD has
no counter primitive, I can't do this" - they synthesise
a counter from the primitives they have available to them.
Same for state machines.

Dave

 

[mk]

On Tue, 31 Jul 2007 20:51:56 +0100, Dave Higton
<davehigton@dsl.pipex.com> wrote:

After all, when someone writes VHDL for a counter in a
CPLD, the vendors don't bleat "Woe is me, this CPLD has
no counter primitive, I can't do this" - they synthesise
a counter from the primitives they have available to them.
Same for state machines.

That's because the synthesis tool has the ingredients necessary to
"synthesize" the desired functionality ie DFFs which triger on one
edge of the clock, a clock tree which distributes said clock and
combinational logic. In order to do DDR synthesis, they also need DFFs
which can triger at either edge of the clock, suitable clock trees for
this purpose and muxes which can control inputs from different phases
of the clock domains without excessive delay. These new components
don't exist on most programmable devices.

 

[Andy]

On Aug 2, 11:05 pm, mk <kal*@dspia.*comdelete> wrote:

On Tue, 31 Jul 2007 20:51:56 +0100, Dave Higton

davehig...@dsl.pipex.com> wrote:
After all, when someone writes VHDL for a counter in a
CPLD, the vendors don't bleat "Woe is me, this CPLD has
no counter primitive, I can't do this" - they synthesise
a counter from the primitives they have available to them.
Same for state machines.

That's because the synthesis tool has the ingredients necessary to
"synthesize" the desired functionality ie DFFs which triger on one
edge of the clock, a clock tree which distributes said clock and
combinational logic. In order to do DDR synthesis, they also need DFFs
which can triger at either edge of the clock, suitable clock trees for
this purpose and muxes which can control inputs from different phases
of the clock domains without excessive delay. These new components
don't exist on most programmable devices.

If you read my post, you'd realize that it is a simple implementation
for a DDR register using 3 XOR gates, two DFFs, and no clock/input/
output muxing. Output is glitch free and 100% STA compatible. It can
use separate clocks (synchronously related, with adequate time between
edges) or both edges of the same clock, with separate inputs or
combined.

I have tried to persuade Synplicity to implement this, but to no
avail. If a lot more users convince any one of the vendors to do it,
then the rest will follow. Maybe Xilinx or Altera will jump on it as a
way to sell more chips ("our chip now does DDR internally!"). Maybe it
will be a new logo: "DDR Inside (TM)"!

After all, if synthesis vendors can do TMR (triple mode redundancy)
automatically, surely they can handle this.

Andy

 

[Dave Higton]

In message <33a5b3hmjhklr4j3btuamk52bbf2qn9m27@4ax.com>
mk <kal*@dspia.*comdelete> wrote:

On Tue, 31 Jul 2007 20:51:56 +0100, Dave Higton
davehigton@dsl.pipex.com> wrote:

After all, when someone writes VHDL for a counter in a
CPLD, the vendors don't bleat "Woe is me, this CPLD has
no counter primitive, I can't do this" - they synthesise
a counter from the primitives they have available to them.
Same for state machines.

That's because the synthesis tool has the ingredients necessary to
"synthesize" the desired functionality ie DFFs which triger on one
edge of the clock, a clock tree which distributes said clock and
combinational logic. In order to do DDR synthesis, they also need DFFs
which can triger at either edge of the clock, suitable clock trees for
this purpose and muxes which can control inputs from different phases
of the clock domains without excessive delay. These new components
don't exist on most programmable devices.

My point is that these "new" components can be synthesised from
primitives that are in most/all programmable logic devices. So
the synthesis tool /does/ have the necessary ingredients.

Dave

 

[Colin Paul Gloster]

In news:1186166132.597196.95080@x35g2000prf.googlegroups.com
timestamped Fri, 03 Aug 2007 11:35:32 -0700,
Andy <jonesandy@comcast.net> posted:
|------------------------------------------------------------------------|
|"[..] |
| |
|I have tried to persuade Synplicity to implement this, but to no |
|avail. If a lot more users convince any one of the vendors to do it, |
|then the rest will follow. Maybe Xilinx or Altera will jump on it as a |
|way to sell more chips ("our chip now does DDR internally!"). Maybe it |
|will be a new logo: "DDR Inside (TM)"!" |
|------------------------------------------------------------------------|

What excuse was used to avoid providing this? Maybe if some vendor
implements it, other vendors will also do so, but it took years for
simple things such as rising_edge and multidimensional arrays to be
widely supported, so do not be too optimistic.

|------------------------------------------------------------------------|
|"After all, if synthesis vendors can do TMR (triple mode redundancy) |
|automatically, surely they can handle this. |
| |
|Andy" |
|------------------------------------------------------------------------|

I am aware of one vendor which has claimed to automatically implement
triple modular redundancy for FPGAs, but I received no satisfactory
reponse to a point I made that this vendor's implementation did not
seem to provide any improvement to not using triple modular redundancy
at all. Triple modular redundancy can be better than not using TMR:
are you aware of a vendor which automatically provides TMR in a useful
manner?

Regards,
Colin Paul Gloster

 

[Colin Paul Gloster]

In news:00c82e0b4f.davehigton@dsl.pipex.com timestamped Tue, 31 Jul
2007 20:51:56 +0100, Dave Higton <davehigton@dsl.pipex.com> posted:
|------------------------------------------------------------------------|
|"In message <nghna3hoh2sfg7t75sjt7snvdjstpf25hq@4ax.com> |
| Jonathan Bromley <jonathan.bromley@MYCOMPANY.com> wrote: |
| |
|> On Sat, 28 Jul 2007 21:52:47 -0000, |
|> <sunshinekisses@gmail.com> wrote: |
|> |
|[..] |
|> > |
|> >as the idea is to have a counter that changes with EVERY clock event,|
|> >not just the leading edge. |
|> |
|> How do you think this would be implemented in hardware? |
|> Flip-flops that trigger on both edges of a clock are |
|> as rare as rocking-horse shit." |
|------------------------------------------------------------------------|

Jonathan, I do not mean to be disrespectful, but it is irrelevant
whether or not flip-flops which can be triggerred on both edges of a
clock are available.

|------------------------------------------------------------------------|
|" Synthesis tools rightly |
|> complain if you try to imply such logic." |
|------------------------------------------------------------------------|

They have no right to complain.

|------------------------------------------------------------------------|
|" The code that |
|> you present is valid VHDL, but would not go through any |
|> synthesis tool I know about. |
| |
|And since there have been at least two implementations |
|suggested in this newsgroup, I think it's high time the |
|synthesis vendors got off their bottoms and implemented |
|something." |
|------------------------------------------------------------------------|

In theory this is true, but synthesis vendors seem to have an ability
to not bother providing an implementation for something until a long
time has passed. I do not know whether this is because they are busy
working on other things or because they are lazy. One person I met
attributed something similar to being a case of vendors knowing that
for a few years a missing feature would be tolerable but that
eventually customers would demand it as virtually essential in which
case it would be eventually provided.

|------------------------------------------------------------------------|
|"After all, when someone writes VHDL for a counter in a |
|CPLD, the vendors don't bleat "Woe is me, this CPLD has |
|no counter primitive, I can't do this" - they synthesise |
|a counter from the primitives they have available to them. |
|Same for state machines. |
| |
|Dave" |
|------------------------------------------------------------------------|

I do not know whether Dave's examples are true, but they seem to be
excellent examples of why a lack of straight forward mappings to
efficient primitives is not a sufficient excuse for not providing
synthesis support for some kinds of code. A synthesis tool should be
more like a compiler instead of merely an assembler.

Regards,
C. P. G.

 

[Andy]

On Aug 6, 10:15 am, Colin Paul Gloster <Colin_Paul_Glos...@ACM.org>
wrote:

Innews:1186166132.597196.95080@x35g2000prf.googlegroups.com
timestamped Fri, 03 Aug 2007 11:35:32 -0700,
Andy <jonesa...@comcast.net> posted:
|------------------------------------------------------------------------|
|"[..] |
| |
|I have tried to persuade Synplicity to implement this, but to no |
|avail. If a lot more users convince any one of the vendors to do it, |
|then the rest will follow. Maybe Xilinx or Altera will jump on it as a |
|way to sell more chips ("our chip now does DDR internally!"). Maybe it |
|will be a new logo: "DDR Inside (TM)"!" |
|------------------------------------------------------------------------|

What excuse was used to avoid providing this? Maybe if some vendor
implements it, other vendors will also do so, but it took years for
simple things such as rising_edge and multidimensional arrays to be
widely supported, so do not be too optimistic.

|------------------------------------------------------------------------|
|"After all, if synthesis vendors can do TMR (triple mode redundancy) |
|automatically, surely they can handle this. |
| |
|Andy" |
|------------------------------------------------------------------------|

I am aware of one vendor which has claimed to automatically implement
triple modular redundancy for FPGAs, but I received no satisfactory
reponse to a point I made that this vendor's implementation did not
seem to provide any improvement to not using triple modular redundancy
at all. Triple modular redundancy can be better than not using TMR:
are you aware of a vendor which automatically provides TMR in a useful
manner?

Regards,
Colin Paul Gloster

IINM, Synplicity does, for non-volatile, rad hard FPGA (i.e. Actel)
targets, provide the option of TMR on all registers. Whether that is
"useful" I don't know, but it irrelevant to my point: They already
take a single inference for register storage, and implement multiple
flops and gates to realize the function desired. Their response was
that they did not see a real need for it. And I suppose, for targets
that have PLL/DLL clock generation facilities, that it is just as easy
(and more efficient?) to double the clock, and use a single edge flop
implementation.

Andy

 

[Colin Paul Gloster]

On 2007-08-06, Andy <jonesandy@comcast.net> wrote:

|----------------------------------------------------------------------------|
|"[..] |
| |
|IINM, Synplicity does, for non-volatile, rad hard FPGA (i.e. Actel) |
|targets, provide the option of TMR on all registers. Whether that is |
|"useful" I don't know," |
|----------------------------------------------------------------------------|

It is not useful as what Synplicity described is basically equivalent to
Vote_Result <= most_common_value(Voter1, Voter2, Voter3);
which can be fine if just Voter1 is corrupted or just Voter2 or just
Voter3 but which is not fine if Vote_Result is corrupted.

|----------------------------------------------------------------------------|
|" but it irrelevant to my point: [..]" |
|----------------------------------------------------------------------------|

True.

Regards,
Colin Paul Gloster

 

[Andy]

On Aug 7, 3:54 am, Colin Paul Gloster <Colin_Paul_Glos...@ACM.org>
wrote:

On 2007-08-06, Andy <jonesa...@comcast.net> wrote:

|----------------------------------------------------------------------------|
|"[..] |
| |
|IINM, Synplicity does, for non-volatile, rad hard FPGA (i.e. Actel) |
|targets, provide the option of TMR on all registers. Whether that is |
|"useful" I don't know," |
|----------------------------------------------------------------------------|

It is not useful as what Synplicity described is basically equivalent to
Vote_Result <= most_common_value(Voter1, Voter2, Voter3);
which can be fine if just Voter1 is corrupted or just Voter2 or just
Voter3 but which is not fine if Vote_Result is corrupted.

|----------------------------------------------------------------------------|
|" but it irrelevant to my point: [..]" |
|----------------------------------------------------------------------------|

True.

Regards,
Colin Paul Gloster

Hmmm, I thought there were three copies of the vote_result logic, one
for each voter. Not sure how or where I got that from though; perhaps
it was just an assumption on my part.

Andy

 

[Evan Lavelle]

On Fri, 03 Aug 2007 22:54:19 +0100, Dave Higton
<davehigton@dsl.pipex.com> wrote:

In message <33a5b3hmjhklr4j3btuamk52bbf2qn9m27@4ax.com
mk <kal*@dspia.*comdelete> wrote:

On Tue, 31 Jul 2007 20:51:56 +0100, Dave Higton
davehigton@dsl.pipex.com> wrote:

After all, when someone writes VHDL for a counter in a
CPLD, the vendors don't bleat "Woe is me, this CPLD has
no counter primitive, I can't do this" - they synthesise
a counter from the primitives they have available to them.
Same for state machines.

That's because the synthesis tool has the ingredients necessary to
"synthesize" the desired functionality ie DFFs which triger on one
edge of the clock, a clock tree which distributes said clock and
combinational logic. In order to do DDR synthesis, they also need DFFs
which can triger at either edge of the clock, suitable clock trees for
this purpose and muxes which can control inputs from different phases
of the clock domains without excessive delay. These new components
don't exist on most programmable devices.

My point is that these "new" components can be synthesised from
primitives that are in most/all programmable logic devices. So
the synthesis tool /does/ have the necessary ingredients.

In principle, yes, a synthesis tool can do anything from the available
primitives, just as you could draw up the circuit yourself using gates
and wires. The problem is that all the interesting circuits (flops and
latches) are asynchronous, and asynchronous design is best left to the
library vendor. They know exactly what will and wont work, and they
supply the results as primitives to the synthesiser. You can't expect
a synthesiser to build an asynchronous circuit from scratch,
especially when you've got something as coarse-grained as an FPGA to
work with.

Evan

 

[Dave Higton]

In message <qkrmb3dkomn1vcf9arj45foegnmunche94@4ax.com>
Evan Lavelle <nospam@nospam.com> wrote:

On Fri, 03 Aug 2007 22:54:19 +0100, Dave Higton
davehigton@dsl.pipex.com> wrote:

In message <33a5b3hmjhklr4j3btuamk52bbf2qn9m27@4ax.com
mk <kal*@dspia.*comdelete> wrote:

On Tue, 31 Jul 2007 20:51:56 +0100, Dave Higton
davehigton@dsl.pipex.com> wrote:

After all, when someone writes VHDL for a counter in a
CPLD, the vendors don't bleat "Woe is me, this CPLD has
no counter primitive, I can't do this" - they synthesise
a counter from the primitives they have available to them.
Same for state machines.

That's because the synthesis tool has the ingredients necessary to
"synthesize" the desired functionality ie DFFs which triger on one
edge of the clock, a clock tree which distributes said clock and
combinational logic. In order to do DDR synthesis, they also need DFFs
which can triger at either edge of the clock, suitable clock trees for
this purpose and muxes which can control inputs from different phases
of the clock domains without excessive delay. These new components
don't exist on most programmable devices.

My point is that these "new" components can be synthesised from
primitives that are in most/all programmable logic devices. So
the synthesis tool /does/ have the necessary ingredients.

In principle, yes, a synthesis tool can do anything from the available
primitives, just as you could draw up the circuit yourself using gates
and wires. The problem is that all the interesting circuits (flops and
latches) are asynchronous, and asynchronous design is best left to the
library vendor. They know exactly what will and wont work, and they
supply the results as primitives to the synthesiser. You can't expect
a synthesiser to build an asynchronous circuit from scratch,
especially when you've got something as coarse-grained as an FPGA to
work with.

I'm sorry, I don't understand your point. We aren't talking about
building an asynchronous circuit; we're talking about building a
flip-flop that triggers on both edges of the clock. It's just as
synchronous as a D type FF (synchronous from the clock, sync or
async - user's choice - from S and R). Whichever of the double
edge triggered circuit alternatives they choose to synthesise,
they would do it from DFFs and gates.

Dave

 

[Andy]

On Aug 9, 2:44 pm, Evan Lavelle <nos...@nospam.com> wrote:

On Fri, 03 Aug 2007 22:54:19 +0100, Dave Higton



davehig...@dsl.pipex.com> wrote:
In message <33a5b3hmjhklr4j3btuamk52bbf2qn9...@4ax.com
mk <kal*@dspia.*comdelete> wrote:

On Tue, 31 Jul 2007 20:51:56 +0100, Dave Higton
davehig...@dsl.pipex.com> wrote:

After all, when someone writes VHDL for a counter in a
CPLD, the vendors don't bleat "Woe is me, this CPLD has
no counter primitive, I can't do this" - they synthesise
a counter from the primitives they have available to them.
Same for state machines.

That's because the synthesis tool has the ingredients necessary to
"synthesize" the desired functionality ie DFFs which triger on one
edge of the clock, a clock tree which distributes said clock and
combinational logic. In order to do DDR synthesis, they also need DFFs
which can triger at either edge of the clock, suitable clock trees for
this purpose and muxes which can control inputs from different phases
of the clock domains without excessive delay. These new components
don't exist on most programmable devices.

My point is that these "new" components can be synthesised from
primitives that are in most/all programmable logic devices. So
the synthesis tool /does/ have the necessary ingredients.

In principle, yes, a synthesis tool can do anything from the available
primitives, just as you could draw up the circuit yourself using gates
and wires. The problem is that all the interesting circuits (flops and
latches) are asynchronous, and asynchronous design is best left to the
library vendor. They know exactly what will and wont work, and they
supply the results as primitives to the synthesiser. You can't expect
a synthesiser to build an asynchronous circuit from scratch,
especially when you've got something as coarse-grained as an FPGA to
work with.

Evan

There is nothing asynchronous about the 2-flop, 3-xor circuit I
described, unless you count the async reset, which just uses the async
resets on the flops directly (and synthesizers don't have a problem
with those). That's the beauty of it: No clock gating, no muxing/
demuxing with the clock, just plain synchronous gates and flops,
connected in a synchronous circuit.

Andy