is this synthesizable?

[Xin Xiao]

Some people say that this line is synthesizable; some others say it isn't.

Clk <= not Clk after period / 2;

Is it synthesizable?

 

[KJ]

"Xin Xiao" <x@x.com> wrote in message
news:flb0ur$set$1@nsnmrro2-gest.nuria.telefonica-data.net...

Some people say that this line is synthesizable; some others say it isn't.

Clk <= not Clk after period / 2;

Is it synthesizable?

No commercially available FPGAs or CPLDs currently implement delay lines so
the above is not synthesizable when targetting such devices.

KJ

 

[Jonathan Bromley]

On Mon, 31 Dec 2007 16:13:24 +0100, "Xin Xiao" <x@x.com> wrote:

Some people say that this line is synthesizable; some others say it isn't.

Some people say the earth is flat.

Clk <= not Clk after period / 2;
Is it synthesizable?

You tell me. What hardware should the synthesis tool
build to implement this? Note, it's a single *inertial*
delay of "period/2", which excludes the possibility of
building a ring oscillator - the many stages required
would implement something much closer to transport delay.
Today, synthesis tools don't know how to build RC delay
elements - and even if they did, it would be a little
tricky to implement such a thing on an FPGA.

Synthesis generally cannot build analogue elements.

The direct answer to your question is that almost all
synthesis tools completely ignore "after" delays, so
the synthesized result would be an inverter with its
output and input joined together. This would obviously
be a crazy thing to do, and the tool chain would give
you various warning messages about it in the stages
beyond RTL synthesis. Finally, if you allowed such
a thing to be implemented in the finished hardware,
you would obviously get absurd behaviour.

It is usually possible to build a clock oscillator on
an FPGA by playing silly games with I/O buffers and
external RC networks, but it's rarely a good idea.
--
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.

 

[KJ]

"Jonathan Bromley" <jonathan.bromley@MYCOMPANY.com> wrote in message
news:vc3in31tfjjocl7eet1gh7bdfelvm1n42g@4ax.com...

On Mon, 31 Dec 2007 16:13:24 +0100, "Xin Xiao" <x@x.com> wrote:

Some people say that this line is synthesizable; some others say it isn't.

Some people say the earth is flat.

Some say it's only a few thousand years old

Clk <= not Clk after period / 2;
Is it synthesizable?

You tell me. What hardware should the synthesis tool
build to implement this?
A delay line and an inverter.

Today, synthesis tools don't know how to build RC delay
elements - and even if they did, it would be a little
tricky to implement such a thing on an FPGA.

But those FPGA suppliers are pretty creative, I'll bet they could do it.

But I'm betting that they won't because there is really little market demand
for a stand alone delay line feature.

Synthesis generally cannot build analogue elements.

Maybe someone should tell Altera, Xilinx, et al to remove their PLL/DLLs and

Actel to get rid of the A/D and D/As then...they're all pretty much analog
beasts. What is 'synthesizable' can not be discussed without also
discussing the underlying technology that would/could be used to implement
it.

The direct answer to your question is that almost all
synthesis tools completely ignore "after" delays, so
the synthesized result would be an inverter with its
output and input joined together.
Shame on the tool writers then for not flagging it as an error early on.

This would obviously
be a crazy thing to do, and the tool chain would give
you various warning messages about it in the stages
beyond RTL synthesis. Finally, if you allowed such
a thing to be implemented in the finished hardware,
you would obviously get absurd behaviour.

See? That's why the synthesis tool should've flagged an error. The only

reason for the absurd behaviour is because it tossed out something that the
underlying hardware didn't happen to be able to implement with today's
parts....tomorrows part could be a different story. In any case, by
ignoring something that it couldn't implement it caused it's own problem.

It is usually possible to build a clock oscillator on
an FPGA by playing silly games with I/O buffers and
external RC networks, but it's rarely a good idea.
But it's not a silly game when inverters and other logic gets turned into

memory look up tables?

KJ

 

[Jonathan Bromley]

On Mon, 31 Dec 2007 14:54:58 -0500,
KJ <kkjennings@sbcglobal.net> wrote:

We've disagreed somewhat about this before, but I think
that on this occasion we're largely in agreement and
you're mainly picking holes in my wording...

Clk <= not Clk after period / 2;
Is it synthesizable?

You tell me. What hardware should the synthesis tool
build to implement this?
A delay line and an inverter.

Well, not really; as I pointed out later, the VHDL
calls for inertial rather than transport delay.
Without proper care and feeding, the delay line and
inverter make a strange oscillator....

Synthesis generally cannot build analogue elements.

Maybe someone should tell Altera, Xilinx, et al to remove their PLL/DLLs and
Actel to get rid of the A/D and D/As then...they're all pretty much analog
beasts. What is 'synthesizable' can not be discussed without also
discussing the underlying technology that would/could be used to implement
it.

I have yet to see any synthesis tool infer a PLL or an A/D from
anything other than an instantiation. You may be right in
chastising me for saying that such things are not synthesizable,
since - as you point out - they can be generated as part of the
output from a synthesis tool. But I don't really see black-box
instantiation as "synthesis" in any meaningful way. You and I
both know this well enough, I think. Let's not fall out over
the nitpicky meaning of a word (synthesis) that has, at best,
only a de-facto definition in this context.

synthesis tools completely ignore "after" delays, so
the synthesized result would be an inverter with its
output and input joined together.

Shame on the tool writers then for not flagging it
as an error early on.

Well.... it probably *is* flagged as an error fairly early,
because it represents combinational feedback. AFAIK all current
synthesis tools will (a) make an effort at implementing
such combinational feedback, and (b) complain about it more
or less vociferously at one or more stages in the processing -
often, fairly early. I stand by my statement. Synth tools
properly ignore "after" delays in other situations, such
as
if rising_edge(clk) then
Q <= D after Tco;
end if;
where the general understanding is that the "after" delay is
for simulation only, is a poor approximation to real timing
behaviour, and is at the author's own risk. Of course, good
tools will nevertheless log the fact they've ignored it.

See? That's why the synthesis tool should've flagged an error.

I acknowledge your position that tools should error on
constructs that they can't faithfully build, but I don't agree
that it's wrong to issue a warning instead - not here, anyway.

It is usually possible to build a clock oscillator on
an FPGA by playing silly games with I/O buffers and
external RC networks, but it's rarely a good idea.
But it's not a silly game when inverters and other logic
gets turned into memory look up tables?

I don't follow. The transformations you describe will faithfully
and reliably preserve the intent and behaviour of my code.
A clock oscillator built using external discrete components
in the way I suggested will likely be crap. My "silly games"
were at the level of hardware outside the device, where the
synthesis tool does not play any part.

All manner of internal things in FPGAs and ASICs are analogue
structures at their core - clock buffers, memories, and even
flip-flops. But the synth tools and FPGAs conspire together
to preserve my simple-minded HDL logic descriptions when
implemented using these analogue thingumabobs. Great stuff.
Respect to the tool and device vendors.
--
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.