Verilog corresponding to VHDL process

[BlueDoze]

Hi,

I want to know the always statement that's corresponding to this VHDL
process statement.



process ( reset, async_set, clock )
begin

if ( reset = '1' ) then
output <= input1 ;
elsif ( async_set = '1' ) then
output <= input2 ;
elsif ( clock = '1' and clock'event) then
if sync_set = '1' then
output <= input3 ;
else
output <= input;
end if;
end if;

end process;


I have tried
always @(posedge clock or posedge reset or posedge async_set)

but I had problems with the negative edge of the clock so I added.
always @(posedge clock or negedge clock or posedge reset or posedge
async_set)

but again I found problems with other negative edges.

Appreciate your help.
Bluedoze

 

[DW]

"BlueDoze" <bluedoze@yahoo.com> wrote in message
news:a53ecee3.0406010651.54bacd2d@posting.google.com...

Hi,

I want to know the always statement that's corresponding to this VHDL
process statement.



process ( reset, async_set, clock )
begin

if ( reset = '1' ) then
output <= input1 ;
elsif ( async_set = '1' ) then
output <= input2 ;
elsif ( clock = '1' and clock'event) then
if sync_set = '1' then
output <= input3 ;
else
output <= input;
end if;
end if;

end process;


I have tried
always @(posedge clock or posedge reset or posedge async_set)

but I had problems with the negative edge of the clock so I added.
always @(posedge clock or negedge clock or posedge reset or posedge
async_set)

but again I found problems with other negative edges.

Appreciate your help.
Bluedoze

Not being over-familiar with VHDL, I assume in the following that you are
interested in the negative going edge of the clock
i.e. "elsif ( clock = '1' and clock'event) then"
in this case, you should only have a negedge clock statement in the
procedural code.

You have both combinatorial logic and synchronous logic. i.e. reset and
async_set are purely asynchronous so why not try this:

// register required to hold required state when clock occurs
reg sync_input;

// continuous assignment code
reset ? output = input1 : ( async_set ? output = input2 : sync_input );

// procedural code
always @( negedge clock )
if sync_set
sync_input <= input3;
else
sync_input <= input;

I have not tried to compile this so please accept my apologies if I have got
it wrong.

DW

 

[Allan Herriman]

On 1 Jun 2004 07:51:29 -0700, bluedoze@yahoo.com (BlueDoze) wrote:

Hi,

I want to know the always statement that's corresponding to this VHDL
process statement.



process ( reset, async_set, clock )
begin

if ( reset = '1' ) then
output <= input1 ;
elsif ( async_set = '1' ) then
output <= input2 ;
elsif ( clock = '1' and clock'event) then
if sync_set = '1' then
output <= input3 ;
else
output <= input;
end if;
end if;

end process;

Are you sure this VHDL is what you want?

If input1 or input2 can change they should also be in the sensitivity
list for the behaviour to make sense.

Consider the following:

reset has rising edge => output takes value of input1 (good)
then
input1 changes => nothing happens (bad?)
then
async_set changes => output takes value of input1 (bad?)


What does your synthesis tool say about this code?

Regards,
Allan.

 

[BlueDoze]

Allan Herriman <allan.herriman.hates.spam@ctam.com.au.invalid> wrote in message news:<rehqb01tj0tr6kf3h23h2appv554pircit@4ax.com>...

On 1 Jun 2004 07:51:29 -0700, bluedoze@yahoo.com (BlueDoze) wrote:

Hi,

I want to know the always statement that's corresponding to this VHDL
process statement.



process ( reset, async_set, clock )
begin

if ( reset = '1' ) then
output <= input1 ;
elsif ( async_set = '1' ) then
output <= input2 ;
elsif ( clock = '1' and clock'event) then
if sync_set = '1' then
output <= input3 ;
else
output <= input;
end if;
end if;

end process;

Are you sure this VHDL is what you want?

If input1 or input2 can change they should also be in the sensitivity
list for the behaviour to make sense.

Consider the following:

reset has rising edge => output takes value of input1 (good)
then
input1 changes => nothing happens (bad?)
then
async_set changes => output takes value of input1 (bad?)


What does your synthesis tool say about this code?

Regards,
Allan.

Thanks Allan.

Thanks all for your comments, It was helpfull.


The following verilog code will match the VHDL:

always @(posedge clk)
if (reset)
output0 = input1;
else if (async_set)
output0 = input2;
else
begin
if (sync_set)
output0 = input3;
else
output0 = input0;
end



always @(clk or reset or async_set or input1 or input2)
if (reset)
output0 = input1;
else if (async_set)
output0 = input2;



But the synthesis tool will give some warnings about multiple driving
of the output.

I'd like to understand if the synthesis tool will work correctly with
the above code ??
Also I'd like to know your comments about this way.

Bluedoze

 

[DW]

"BlueDoze" <bluedoze@yahoo.com> wrote in message
news:a53ecee3.0406020354.298a398d@posting.google.com...

Allan Herriman <allan.herriman.hates.spam@ctam.com.au.invalid> wrote in
message news:<rehqb01tj0tr6kf3h23h2appv554pircit@4ax.com>...
On 1 Jun 2004 07:51:29 -0700, bluedoze@yahoo.com (BlueDoze) wrote:

Hi,

I want to know the always statement that's corresponding to this VHDL
process statement.



process ( reset, async_set, clock )
begin

if ( reset = '1' ) then
output <= input1 ;
elsif ( async_set = '1' ) then
output <= input2 ;
elsif ( clock = '1' and clock'event) then
if sync_set = '1' then
output <= input3 ;
else
output <= input;
end if;
end if;

end process;

Are you sure this VHDL is what you want?

If input1 or input2 can change they should also be in the sensitivity
list for the behaviour to make sense.

Consider the following:

reset has rising edge => output takes value of input1 (good)
then
input1 changes => nothing happens (bad?)
then
async_set changes => output takes value of input1 (bad?)


What does your synthesis tool say about this code?

Regards,
Allan.

Thanks Allan.

Thanks all for your comments, It was helpfull.


The following verilog code will match the VHDL:

always @(posedge clk)
if (reset)
output0 = input1;
else if (async_set)
output0 = input2;
else
begin
if (sync_set)
output0 = input3;
else
output0 = input0;
end



always @(clk or reset or async_set or input1 or input2)
if (reset)
output0 = input1;
else if (async_set)
output0 = input2;



But the synthesis tool will give some warnings about multiple driving
of the output.

I'd like to understand if the synthesis tool will work correctly with
the above code ??
Also I'd like to know your comments about this way.

Bluedoze

I do not think this is correct. The output should respond asynchronously to
the reset and async_set inputs and can be satisfied with combinatorial
logic. I refer you to my previous post specifying a continuous assignment.
The whole point is that it is not edge driven. The only input which needs
to be edge sensitive is the clock input and therefore, that is the only
input which should appear in a procedural construct i.e. @( posedge clk )...
DW

 

[Steven Sharp]

bluedoze@yahoo.com (BlueDoze) wrote in message news:<a53ecee3.0406010651.54bacd2d@posting.google.com>...

process ( reset, async_set, clock )
begin

if ( reset = '1' ) then
output <= input1 ;
elsif ( async_set = '1' ) then
output <= input2 ;
elsif ( clock = '1' and clock'event) then
if sync_set = '1' then
output <= input3 ;
else
output <= input;
end if;
end if;

end process;

As others have pointed out, this VHDL code doesn't make
much sense unless input1 and input2 are actually constants.

Verilog doesn't provide the capability of checking after
an event control to see which of multiple possible events
actually woke you up. All you know is that you woke up.

I believe this means that you can't use a single always
block to correctly model a device that has an edge
sensitive input and multiple higher priority level
sensitive inputs (such as an asynchronous preset and clear).
You can do it with multiple always blocks that are
each sensitive to different subsets of the inputs.

However, most synthesis tools are incapable of correctly
synthesizing flip-flops modeled with multiple always
blocks. They do stupid things, like producing a separate
flip-flop for each always block and then wiring their
outputs together.

 

[Steven Sharp]

"DW" <dave_wooff@hotmail.com> wrote in message news:<c9ie8n$78a$1$8302bc10@news.demon.co.uk>...

// continuous assignment code
reset ? output = input1 : ( async_set ? output = input2 : sync_input );

This is invalid Verilog. You can't have assignments embedded inside
an expression. I assume that the intent was:

assign output = reset ? input1 : (async_set ? input2 : sync_input);

This also doesn't match the desired behavior. This Verilog code is
modeling a flip-flop followed by a MUX, rather than a flip-flop with
asynchronous set and reset inputs. With this Verilog code, the reset
line doesn't clear the flip-flop state, it just gates the output to
zero while it is asserted. The moment the reset goes away, the output
will go to the most recently latched flip-flop output (which is in
sync_input). For correct behavior, the reset line has to clear the
latched value. Then when the reset goes away, the output will remain
clear until a new value gets latched.

I agree that this model calls for two processes, one to handle the
edge-triggered part, and another for the level-sensitive parts. But
since both affect the latched state, they both need to be able to
write to that state. That implies a reg that is written to by two
(or more) always blocks. But synthesis tools don't seem to handle
that situation properly.

 

[Steven Sharp]

bluedoze@yahoo.com (BlueDoze) wrote in message news:<a53ecee3.0406020354.298a398d@posting.google.com>...

The following verilog code will match the VHDL:

The code looks like it should work, though it can be simplified.
The clock block doesn't need to set the output for the asynchronous
inputs because the other block will do that. And the other block
doesn't need to be sensitive to the clock signal. Here is a
simplified version:

always @(posedge clk)
if (!reset && !async_set)
begin
if (sync_set)
output0 = input3;
else
output0 = input0;
end



always @(reset or async_set or input1 or input2)
if (reset)
output0 = input1;
else if (async_set)
output0 = input2;

But the synthesis tool will give some warnings about multiple driving
of the output.

The synthesis tool doesn't understand that output0 is a single state
register being written by two always blocks. It should combine the
two separate pieces of logic that write to the state register in
mutually exclusive situations into a single combined piece of logic
that controls writes to the state register in all situations.

Instead, it tries to treat output0 as a wire that is being driven
by two different drivers tied together, and synthesizes a separate
internal state register for each driver. This doesn't match the
specified behavior at all.

I'd like to understand if the synthesis tool will work correctly with
the above code ??

No, I don't believe so.

Also I'd like to know your comments about this way.

I think this is how you have to model this process in behavioral
Verilog. However, the synthesis tools can't handle it. You should
check your synthesis tool documentation to see if they say anything
about how to synthesize a flip-flop with both asynchronous set and
clear. You may be able to just tell it to map to a predefined
library cell that implements this functionality, instead of
trying to synthesize your Verilog code.

Another way to model this would be to define a UDP with the desired
behavior. UDPs are a pain to write correctly, and synthesis tools
presumably can't handle them.

 

[BlueDoze]

sharp@cadence.com (Steven Sharp) wrote in message news:<3a8e124e.0406021525.649c6348@posting.google.com>...

bluedoze@yahoo.com (BlueDoze) wrote in message news:<a53ecee3.0406020354.298a398d@posting.google.com>...

The following verilog code will match the VHDL:

The code looks like it should work, though it can be simplified.
The clock block doesn't need to set the output for the asynchronous
inputs because the other block will do that. And the other block
doesn't need to be sensitive to the clock signal. Here is a
simplified version:

always @(posedge clk)
if (!reset && !async_set)
begin
if (sync_set)
output0 = input3;
else
output0 = input0;
end

I comletely Agree with this.

always @(reset or async_set or input1 or input2)
if (reset)
output0 = input1;
else if (async_set)
output0 = input2;

This block should be sensitive to the clk, to take care of the
negative edge of the clock.

But the synthesis tool will give some warnings about multiple driving
of the output.

The synthesis tool doesn't understand that output0 is a single state
register being written by two always blocks. It should combine the
two separate pieces of logic that write to the state register in
mutually exclusive situations into a single combined piece of logic
that controls writes to the state register in all situations.

Instead, it tries to treat output0 as a wire that is being driven
by two different drivers tied together, and synthesizes a separate
internal state register for each driver. This doesn't match the
specified behavior at all.

I'd like to understand if the synthesis tool will work correctly with
the above code ??

No, I don't believe so.

Also I'd like to know your comments about this way.

I think this is how you have to model this process in behavioral
Verilog. However, the synthesis tools can't handle it. You should
check your synthesis tool documentation to see if they say anything
about how to synthesize a flip-flop with both asynchronous set and
clear. You may be able to just tell it to map to a predefined
library cell that implements this functionality, instead of
trying to synthesize your Verilog code.

Another way to model this would be to define a UDP with the desired
behavior. UDPs are a pain to write correctly, and synthesis tools
presumably can't handle them.

Thanks for your comments.

Bluedoze

 

[Shalom Bresticker]

If you really wanted to allow input1 and input2 to be variables, I think you could write,
assuming that the input and output data are 1 bit long, and not vectors:

assign a_set = (reset & input1) | (!reset & async_set & input2) ;
assign a_reset = (reset & !input1) | (!reset & async_set & !input2) ;

always @(posedge clock or posedge a_set or posedge a_reset)
if (a_reset)
output <= 1'b0 ;
else if (a_set)
output <= 1'b1 ;
else if (sync_set)
output <= input3 ;
else
output <= input ;

--
Shalom Bresticker Shalom.Bresticker @freescale.com
Design & Reuse Methodology Tel: +972 9 9522268
Freescale Semiconductor Israel, Ltd. Fax: +972 9 9522890
POB 2208, Herzlia 46120, ISRAEL Cell: +972 50 5441478

[ ]Freescale Internal Use Only
[ ]Freescale Confidential Proprietary

 

[DW]

"BlueDoze" <bluedoze@yahoo.com> wrote in message
news:a53ecee3.0406010651.54bacd2d@posting.google.com...

Hi,

I want to know the always statement that's corresponding to this VHDL
process statement.



process ( reset, async_set, clock )
begin

if ( reset = '1' ) then
output <= input1 ;
elsif ( async_set = '1' ) then
output <= input2 ;
elsif ( clock = '1' and clock'event) then
if sync_set = '1' then
output <= input3 ;
else
output <= input;
end if;
end if;

end process;


I have tried
always @(posedge clock or posedge reset or posedge async_set)

but I had problems with the negative edge of the clock so I added.
always @(posedge clock or negedge clock or posedge reset or posedge
async_set)

but again I found problems with other negative edges.

Appreciate your help.
Bluedoze

Is the following of any help (using Quasi-continuous assignment)? :

always @(reset or async_set)
if (reset)
assign output = input1;
else if (async_set)
assign output = input2;
else
deassign output;

always @(posedge clock)
if (sync_set)
output = input3
else
output = input;

 

[Steven Sharp]

"DW" <dave_wooff@hotmail.com> wrote in message news:<c9n7ta$s70$1$830fa79d@news.demon.co.uk>...

Is the following of any help (using Quasi-continuous assignment)? :

always @(reset or async_set)
if (reset)
assign output = input1;
else if (async_set)
assign output = input2;
else
deassign output;

always @(posedge clock)
if (sync_set)
output = input3
else
output = input;

This approach should work for simulation, but still has problems
with synthesis. I think the old Cadence Synergy synthesis tool
handled this particular coding style for asynchronous set and
reset. I don't think other tools accept quasi-continuous assigns.

 

[Steven Sharp]

"DW" <dave_wooff@hotmail.com> wrote in message news:<ca18me$b5o$1$8302bc10@news.demon.co.uk>...

"Steven Sharp" <sharp@cadence.com> wrote in message
news:3a8e124e.0406041216.68278aeb@posting.google.com...
"DW" <dave_wooff@hotmail.com> wrote in message
news:<c9n7ta$s70$1$830fa79d@news.demon.co.uk>...

Its probably a stupid question, but why is it that synthesizers/simulators
appear to be so inconsistent with the interpretation of Verilog - and if a
feature is in the language, why isn't it naturally supported? Is it due to
the changes to Verilog over time i.e. some tools haven't caught up with the
latest standard?

Here is my understanding of the history.

Verilog was designed as a simulation language. It is a programming
language with specialized constructs for modeling digital hardware.
If you created a design from existing hardware components, and wrote
accurate models for those components, you could simulate the design.
You could also write more abstract architectural models of a system,
and then do stepwise refinement of the design. When it became detailed
enough that it was expressed in terms of your available low-level
components, you would have a completed design.

At a later time, somebody came up with the idea of synthesizing
Verilog into hardware. A synthesis tool tries to perform the later
lowest-level stages of refinement to actual components for you,
automatically. It tries to produce hardware that closely approximates
the behavior of the model it is given. It can only handle a subset
of the Verilog language, and it doesn't always approximate it as
accurately as would be desired. Some of the errors in approximation
occur because you can write things in Verilog that can't be done in
actual hardware (for example, I can write a model for a nand gate with
a 1fs propagation delay, but that doesn't mean I really have such a
component). Others are because the tool isn't smart enough to
"understand" the model like a human would, and the rules it uses
produce wrong results in some cases.

Synthesis has become so commonly used that many engineers make the
mistake of regarding the output of synthesis as "defining" the
meaning of the input Verilog code. New users hear that they can
compile Verilog into hardware, and assume they can throw in any
Verilog and get hardware that perfectly matches the specified
behavior, like a software compiler. Experienced users have learned
what hardware gets produced for given Verilog input. As they write
Verilog, they keep in mind what hardware they expect to be produced,
and start to regard that as the "meaning" of the Verilog.

In fact, the meaning of the Verilog language itself is defined by
the simulation behavior. The behavior of the synthesis output just
tells you how well (or poorly) the synthesis tool managed to match
that.

Now back to your questions. Verilog simulators should be pretty
consistent with the language definition, since the language standard
defines the correct behavior for them (with some room for variation).
Verilog synthesizers may be inconsistent with simulators and each other.
They aren't capable of exactly matching the language definition, and
may differ in how they approximate it.

Synthesizers don't naturally support all features in the language,
because the language was not designed with their limitations in mind.
They came along later. They could handle more features than they do.
However, there are a lot of designers who are already used to their
limitations, and are more concerned by other issues like timing
closure. Synthesis has also been dominated by one EDA vendor, who
set the standard of what is considered to be synthesizable.

And no, I don't believe that this has anything to do with extensions
to the language. The features we are talking about were in the
language before synthesis existed.

 

[DW]

"Steven Sharp" <sharp@cadence.com> wrote in message
news:3a8e124e.0406071308.69fbd791@posting.google.com...

"DW" <dave_wooff@hotmail.com> wrote in message
news:<ca18me$b5o$1$8302bc10@news.demon.co.uk>...
"Steven Sharp" <sharp@cadence.com> wrote in message
news:3a8e124e.0406041216.68278aeb@posting.google.com...
"DW" <dave_wooff@hotmail.com> wrote in message
news:<c9n7ta$s70$1$830fa79d@news.demon.co.uk>...

Its probably a stupid question, but why is it that
synthesizers/simulators
appear to be so inconsistent with the interpretation of Verilog - and if
a
feature is in the language, why isn't it naturally supported? Is it due
to
the changes to Verilog over time i.e. some tools haven't caught up with
the
latest standard?

Here is my understanding of the history.

Verilog was designed as a simulation language. It is a programming
language with specialized constructs for modeling digital hardware.
If you created a design from existing hardware components, and wrote
accurate models for those components, you could simulate the design.
You could also write more abstract architectural models of a system,
and then do stepwise refinement of the design. When it became detailed
enough that it was expressed in terms of your available low-level
components, you would have a completed design.

At a later time, somebody came up with the idea of synthesizing
Verilog into hardware. A synthesis tool tries to perform the later
lowest-level stages of refinement to actual components for you,
automatically. It tries to produce hardware that closely approximates
the behavior of the model it is given. It can only handle a subset
of the Verilog language, and it doesn't always approximate it as
accurately as would be desired. Some of the errors in approximation
occur because you can write things in Verilog that can't be done in
actual hardware (for example, I can write a model for a nand gate with
a 1fs propagation delay, but that doesn't mean I really have such a
component). Others are because the tool isn't smart enough to
"understand" the model like a human would, and the rules it uses
produce wrong results in some cases.

Synthesis has become so commonly used that many engineers make the
mistake of regarding the output of synthesis as "defining" the
meaning of the input Verilog code. New users hear that they can
compile Verilog into hardware, and assume they can throw in any
Verilog and get hardware that perfectly matches the specified
behavior, like a software compiler. Experienced users have learned
what hardware gets produced for given Verilog input. As they write
Verilog, they keep in mind what hardware they expect to be produced,
and start to regard that as the "meaning" of the Verilog.

In fact, the meaning of the Verilog language itself is defined by
the simulation behavior. The behavior of the synthesis output just
tells you how well (or poorly) the synthesis tool managed to match
that.

Now back to your questions. Verilog simulators should be pretty
consistent with the language definition, since the language standard
defines the correct behavior for them (with some room for variation).
Verilog synthesizers may be inconsistent with simulators and each other.
They aren't capable of exactly matching the language definition, and
may differ in how they approximate it.

Synthesizers don't naturally support all features in the language,
because the language was not designed with their limitations in mind.
They came along later. They could handle more features than they do.
However, there are a lot of designers who are already used to their
limitations, and are more concerned by other issues like timing
closure. Synthesis has also been dominated by one EDA vendor, who
set the standard of what is considered to be synthesizable.

And no, I don't believe that this has anything to do with extensions
to the language. The features we are talking about were in the
language before synthesis existed.

Thanks (Chris and Steven) that's an interesting insight - especially as I
have come in from a software background straight into synthesis.

 

[glen herrmannsfeldt]

Steven Sharp wrote:

(snip)

Here is my understanding of the history.

Verilog was designed as a simulation language. It is a programming
language with specialized constructs for modeling digital hardware.
If you created a design from existing hardware components, and wrote
accurate models for those components, you could simulate the design.
You could also write more abstract architectural models of a system,
and then do stepwise refinement of the design. When it became detailed
enough that it was expressed in terms of your available low-level
components, you would have a completed design.

I believe that even there it is nice to be able to do some
constructs at a higher level. The description of test signals
input to a design might not be easily synthesized, but it doesn't
need to be. $display should not synthesize a logic analyzer.

I can think of things I can write in verilog that I
would be unhappy with the synthesis of.

@(posedge clk) #5 out = in;

A register with a delay independent of other system parameters?

out = #1000 in;

An analog delay line? (Mercury delay lines, where sound waves
were sent down a column of mercury, were used as memories for
early computers.)

wire [63:0] a,b,c;
assign a=b/c;

If I say assign a=b/2; I definitely don't want a 64 bit
combinatorial divider, though that would be consistent with
the verilog. For assign a=b/3; well, I am not so sure.

I am not sure if I would really want a 64 bit combinatorial
divider to be synthesized from that.

At a later time, somebody came up with the idea of synthesizing
Verilog into hardware. A synthesis tool tries to perform the later
lowest-level stages of refinement to actual components for you,
automatically. It tries to produce hardware that closely approximates
the behavior of the model it is given. It can only handle a subset
of the Verilog language, and it doesn't always approximate it as
accurately as would be desired. Some of the errors in approximation
occur because you can write things in Verilog that can't be done in
actual hardware (for example, I can write a model for a nand gate with
a 1fs propagation delay, but that doesn't mean I really have such a
component).

Or even if you did, it might be much more expensive than the
desired for a given design. As far as I know, though, the
unit of time is not specified in the language.

Others are because the tool isn't smart enough to
"understand" the model like a human would, and the rules it uses
produce wrong results in some cases.

Synthesis has become so commonly used that many engineers make the
mistake of regarding the output of synthesis as "defining" the
meaning of the input Verilog code. New users hear that they can
compile Verilog into hardware, and assume they can throw in any
Verilog and get hardware that perfectly matches the specified
behavior, like a software compiler.

I believe that assumption is also unwarranted in the software
compiler case. It does take new users time to learn that.

Experienced users have learned
what hardware gets produced for given Verilog input. As they write
Verilog, they keep in mind what hardware they expect to be produced,
and start to regard that as the "meaning" of the Verilog.

In fact, the meaning of the Verilog language itself is defined by
the simulation behavior. The behavior of the synthesis output just
tells you how well (or poorly) the synthesis tool managed to match
that.

When writing in high-level programming languages one is expected
to have some idea which constructions run fast and which run slow.
For synthesis one should understand which generate simple logic,
and which generate more complex (than needed) logic.

(snip)

Synthesizers don't naturally support all features in the language,
because the language was not designed with their limitations in mind.
They came along later. They could handle more features than they do.
However, there are a lot of designers who are already used to their
limitations, and are more concerned by other issues like timing
closure.

As I understand it, they are doing much more than only a few
years ago. Still, I prefer structural verilog for synthesis.

-- glen

 

[Glen Herrmannsfeldt]

Steven Sharp wrote:
(snip)

Here is my understanding of the history.

Verilog was designed as a simulation language. It is a programming
language with specialized constructs for modeling digital hardware.
If you created a design from existing hardware components, and wrote
accurate models for those components, you could simulate the design.
You could also write more abstract architectural models of a system,
and then do stepwise refinement of the design. When it became detailed
enough that it was expressed in terms of your available low-level
components, you would have a completed design.

Were both structural model and behavioral model in from the
beginning? I usually try to write structural model, as it
seems to map to logic design more directly. The one
exception is that flip-flops and latches don't have a good
structural representation, though I enclose them in a
module and reference it in structural model.

At a later time, somebody came up with the idea of synthesizing
Verilog into hardware. A synthesis tool tries to perform the later
lowest-level stages of refinement to actual components for you,
automatically. It tries to produce hardware that closely approximates
the behavior of the model it is given. It can only handle a subset
of the Verilog language, and it doesn't always approximate it as
accurately as would be desired.

If one considers verilog (or VHDL) as a way to express the
wiring up of logic gates, it isn't hard to guess what should
and should not be synthsizable.

Some of the errors in approximation
occur because you can write things in Verilog that can't be done in
actual hardware (for example, I can write a model for a nand gate with
a 1fs propagation delay, but that doesn't mean I really have such a
component). Others are because the tool isn't smart enough to
"understand" the model like a human would, and the rules it uses
produce wrong results in some cases.

Some are because the people who write the synthesizers don't
believe anyone would want to do some operations. As I understand
it, most won't synthesize divide, and I almost don't disagree.
A real combinatorial divider for a reasonable number of bits
will be very large and very slow. Still, it might be that one
is useful and needed. Logic density is increasing fast, and what
wasn't useful yesterday may be today or tomorrow.

Synthesis has become so commonly used that many engineers make the
mistake of regarding the output of synthesis as "defining" the
meaning of the input Verilog code. New users hear that they can
compile Verilog into hardware, and assume they can throw in any
Verilog and get hardware that perfectly matches the specified
behavior, like a software compiler.

New users of compiled software languages make the same mistakes.
I remember when I was first learning Fortran (in the F66 days)
trying to use a variable for the FORMAT statement number. It would
be possible to compile it, probably not efficient, but the standard
doesn't allow it.

Experienced users have learned
what hardware gets produced for given Verilog input. As they write
Verilog, they keep in mind what hardware they expect to be produced,
and start to regard that as the "meaning" of the Verilog.

I usually consider it the other way, I know the logic I want
and then consider the verilog that should generate it,
preferably without too much writing.

In fact, the meaning of the Verilog language itself is defined by
the simulation behavior. The behavior of the synthesis output just
tells you how well (or poorly) the synthesis tool managed to match
that.

(snip)

-- glen