What's the difference for VHDL code between simulation and synthesis?

Hi,
The following is from Xilinx "Synthesis and Simulation Design Guide".
Could you give me an example to show their differences? And explain a
little to me? Thank you very much.



You may need to modify your code to successfully synthesize your
design because certain
design constructs that are effective for simulation may not be as
effective for synthesis. The synthesis syntax and code set may differ
slightly from the simulator syntax and code set.

On Nov 27, 3:43 pm, fl <rxjw...@gmail.com> wrote:
> Hi,
> The following is from Xilinx "Synthesis and Simulation Design Guide".
> Could you give me an example to show their differences? And explain a
> little to me? Thank you very much.
>
> You may need to modify your code to successfully synthesize your
> design because certain
> design constructs that are effective for simulation may not be as
> effective for synthesis. The synthesis syntax and code set may differ
> slightly from the simulator syntax and code set.

'Differ slightly' is being way too generous.  Usually it means more
along the lines of 'not supported at all' for synthesis even though it
is perfectly legitimate code.  Some examples and how you would write
the code for simulation are shown below.

1. A delay line (commercially available part from many sources....but
not inside an FPGA typically).
    x <= y after 3 ns; -- VHDL representation

2. Division is hard for 2nd graders...not to mention FPGA vendors.
It's not that it can't be synthesized(it can), but it will chew up a
lot of resources and be pretty slow so I guess they figure nobody
would want to do division.
   x <= y / z; -- VHDL representation

3. Wait for this event, then that event, then some other thing to
happen
    process  -- VHDL representation
        wait for (This = '1');
        wait for rising_edge(That);
        wait for (Some_Other_Thing = Happen);
        .....
   end process;

4. Time?  What is that?  Without a delay line resource available, a
delay must be synthesized by using counters and clocks to count clock
cycles that roughly mimic the intended delay.
   wait for 50.3 ns;  -- VHDL representation

There are many others, this is just one tip of the iceberg.  In order
to create a design (i.e. to synthesize) something that does each of
the above mentioned things one would make various tradeoffs and would
need to be skilled in basic digital design practices and then could
whip something up that is functionally nearly equivalent to all of the
above.

KJ

On Nov 27, 9:43 pm, fl <rxjw...@gmail.com> wrote:
> Hi,
> The following is from Xilinx "Synthesis and Simulation Design Guide".
> Could you give me an example to show their differences? And explain a
> little to me? Thank you very much.
>
> You may need to modify your code to successfully synthesize your
> design because certain
> design constructs that are effective for simulation may not be as
> effective for synthesis. The synthesis syntax and code set may differ
> slightly from the simulator syntax and code set.

There are several possible cases (non exhaustive) :

 - Code that's just _not_ syntesizable :

process
begin
 wait until reset='0';
 wait for 3 ns;
 sig <= '1';
end process;

 - Code that may / may not be (i.e. if the synthesizer was smart, he
could do it ... but it might not be )

a <= b / c;

 - Code that is syntesizable but will most likely result in huge
code ...

e.g. a complete behavioral description of some big stuff but only
using 'simple' behaviors (no unsynthesizable constructs) ...

VHDL is a hardware description language. Meaning that you should _not_
use it to describe what you want the hardware to do. But you should
use it to describe the hardware you want built. It's up to you to find
what hardware to build to do what you want it to do ...


Sylvain

Sylvain Munaut <SomeOne@SomeDomain.com> wrote:

> VHDL is a hardware description language. Meaning that you should _not_
> use it to describe what you want the hardware to do. But you should
> use it to describe the hardware you want built. It's up to you to find
> what hardware to build to do what you want it to do ...

Describing wires explicitly is a very popular style
and works well for synthesis. But it is possible for
me to describe procedurally, how a set of registers
are to be updated, like this:
  http://home.comcast.net/~mike_treseler/stack.vhd
And leave it to synthesis to work out the wires, like this:
  http://home.comcast.net/~mike_treseler/stack.pdf

         -- Mike Treseler

"Sylvain Munaut <SomeOne@SomeDomain.com>" <246tnt@gmail.com> wrote in 
message 
news:78b49268-a7ec-409c-b5c0-c61003164231@n20g2000hsh.googlegroups.com...
> On Nov 27, 9:43 pm, fl <rxjw...@gmail.com> wrote:
> - Code that's just _not_ syntesizable :
>
> process
> begin
> wait until reset='0';
> wait for 3 ns;
> sig <= '1';
> end process;
>
The only reason the above code could be considered 'just _not_ syntesizable' 
is because the behaviour of 'sig' prior to getting to where it is assigned 
has not been defined and is a design error that one would fix while still in 
simulation.

But given that code, if the synthesizer wants to assume that 'sig' defaults 
to 1 then it would synthesize to 'sig' always being '1'.  If instead it 
assumed that 'sig' defaults to '0' then it is again synthesizable with an 
inverter and a 3 ns delay line.  If market pressure causes the FPGA 
suppliers to start adding delay lines to their parts then the above code can 
be targeted to one of those devices, if not it can still be implemented with 
commercially availabe parts so it is not 'just _not_ syntesizable' it's just 
not supported by FPGA software at this time....but there are a whole slew of 
things that are not supported, and those are typically 
bugs/limitations/whatever with the software that result in web cases to the 
support lines when I run across them.  The end result of that is they 
improve their tool.  Things like delay lines would be added as functional 
blocks when (if) there is sufficient market demand for that function.

> - Code that may / may not be (i.e. if the synthesizer was smart, he
> could do it ... but it might not be )
>
> a <= b / c;
>
Again, an example not of unsynthesizable code but of perfectly valid and 
synthesizable code that a particular supplier may not support for their own 
various reasons.

> VHDL is a hardware description language. Meaning that you should _not_
> use it to describe what you want the hardware to do. But you should
> use it to describe the hardware you want built.
I want the tools to figure out the proper bitstream that needs to be loaded 
into a part so that a vast array of RAM look up tables, transistors and flip 
flops inside that device will implement what I want it to do.  In order to 
do that I describe functionally what I want the hardware to do, I definitely 
do not describe the hardware that I want built (i.e. the look up table 
contents, transistor on/off states, etc....and I doubt I'm alone in that 
regard).

KJ 

On Nov 27, 3:43 pm, fl <rxjw...@gmail.com> wrote:
> Hi,
> The following is from Xilinx "Synthesis and Simulation Design Guide".
> Could you give me an example to show their differences? And explain a
> little to me? Thank you very much.
>
> You may need to modify your code to successfully synthesize your
> design because certain
> design constructs that are effective for simulation may not be as
> effective for synthesis. The synthesis syntax and code set may differ
> slightly from the simulator syntax and code set.

I think one thing that others have not pointed out is the fact that an
HDL is just that... a Hardware Description Language.  You can use an
HDL to write programs and they will run in a simulator.  This is often
done in developing a test bench to drive signals to your device and to
monitor the outputs in simulation.  But if you want to write code that
can be synthesized by the compiler, you have to be describing
hardware.

"Describing hardware" means you can only use constructs that the
compiler understands.  See the difference?  Simulation operates on the
full language.  Synthesis only works with a subset that actually
describes hardware.

The examples are far too numerous to list, but here is one.  If you
want to use a register, you show it as a process which is scheduled to
run when the clock transitions or the async reset transitions.

  Example1: process (SysClk, Reset) begin
    if (Reset = '1') then
	  DataOutReg <= (others => '0');
    elsif (rising_edge(SysClk)) then
	  if (SCFG_CMD = '1') THEN
	    DataOutReg <= TT & SD & PCMT0 & PCMT1 & WP_SDO0 & WP_SDO1 & DTR &
RTS;
	  end if;
	end if;
  end process Example1;

This code "describes" an 8 bit register with SysClk as the clock, and
async reset - Reset and SCFG_CMD as an enable.

To make this unsynthesizable in a way that is sometimes attempted by
newbies...

  Example2: process (SysClk, Reset) begin
    if (Reset = '1') then
	  DataOutReg <= (others => '0');
    elsif (rising_edge(SysClk) or falling_edge(SysClk)) then
	  if (SCFG_CMD = '1') THEN
	    DataOutReg <= TT & SD & PCMT0 & PCMT1 & WP_SDO0 & WP_SDO1 & DTR &
RTS;
	  end if;
	end if;
  end process Example2;

You can imagine a register that clocks on both the rising and falling
edge, but you can't build it in an FPGA.  It may be useful in
simulation as part of a testbench.  For example, you might want to
generated data on both edges of the clock as data returning from a DDR
memory.

Every synthesis tool I have ever used will give you many examples of
valid hardware description code for you to examine.  I am not so
familiar with the Altera tools, but I know the Xilinx tools have
provided good examples.  Just download one of these free packages and
take it for a test ride.  The last time I used the Altera package, the
built in editor was so good, I often forgot whether I was using the
built in editor or my favorite editor. So you shouldn't have too much
trouble learning to use the IDE.

Try the tools and if you have problems, come back and ask about the
problems.

"rickman" <gnuarm@gmail.com> wrote in message 
news:2c8d9068-fbe9-497d-8d34-5627976b7332@e23g2000prf.googlegroups.com...
> On Nov 27, 3:43 pm, fl <rxjw...@gmail.com> wrote:
> "Describing hardware" means you can only use constructs that the
> compiler understands.  See the difference?
As I pointed out in my first post, what many people refer to as 'not 
synthesizable' really means that they can't find a tool that supports the 
code as it is written.  Something that is 'not synthesizable' can never be 
built.  Living with the limitations of a particular tool(s) is not the same 
thing at all.

> Simulation operates on the
> full language.  Synthesis only works with a subset that actually
> describes hardware.
>
Agreed.

> The examples are far too numerous to list, but here is one.
<snip>
> To make this unsynthesizable in a way that is sometimes attempted by
> newbies...
>
>  Example2: process (SysClk, Reset) begin
>    if (Reset = '1') then
>   DataOutReg <= (others => '0');
>    elsif (rising_edge(SysClk) or falling_edge(SysClk)) then
>   if (SCFG_CMD = '1') THEN
>     DataOutReg <= TT & SD & PCMT0 & PCMT1 & WP_SDO0 & WP_SDO1 & DTR &
> RTS;
>   end if;
> end if;
>  end process Example2;
>
> You can imagine a register that clocks on both the rising and falling
> edge, but you can't build it in an FPGA.
But that does not imply that it couldn't be synthesized using two sets of 
flip flops whose results get combined.  You might not find a synthesis tool 
in 2007 that accepts the above code, but that doesn't mean that there won't 
be one in 2008 that will.  Whether there is such a tool or not depends on 
how many users scream to brand A and X that they really need this.  It can 
be synthesized, just not how you are focusing on how you think it must be 
synthesized.

>
> Every synthesis tool I have ever used will give you many examples of
> valid hardware description code for you to examine.  I am not so
> familiar with the Altera tools, but I know the Xilinx tools have
> provided good examples.  Just download one of these free packages and
> take it for a test ride.
Agreed.  Since one needs to get today's job done with tools you have today 
you need to understand the limitation of the tools as they are today.  I've 
submitted dozens of web cases in areas that should be supported but errored 
out or produced incorrect results.  The tools were updated and improved, 
thus changing what was not synthesizable into something that is.  Each of 
those things were areas where the synthesis tool did not support a language 
construct and it should.  Bottom line right now for the code I right, I'm 
finding Altera way ahead of Xilinx and Synplify so I'm working with X and S 
to get their tools improved so that they too can have less stuff that some 
would consider to be 'not synthesizable'.

KJ 

"KJ" <kkjennings@sbcglobal.net> writes:

> Bottom line right now for the code I right, I'm finding Altera way
> ahead of Xilinx and Synplify so I'm working with X and S to get
> their tools improved so that they too can have less stuff that some
> would consider to be 'not synthesizable'.

Could you give us an example of something Altera can do that Synplify
can't?  (I've always "felt" Synplify to be ahead of the vendor-specific
tools, but it sounds like that may have changed :-)

Thanks!
Martin

-- 
martin.j.thompson@trw.com 
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.conekt.net/electronics.html

On Nov 30, 5:15 pm, "KJ" <kkjenni...@sbcglobal.net> wrote:
> "rickman" <gnu...@gmail.com> wrote in message
>
> > The examples are far too numerous to list, but here is one.
> <snip>
> > To make this unsynthesizable in a way that is sometimes attempted by
> > newbies...
>
> >  Example2: process (SysClk, Reset) begin
> >    if (Reset = '1') then
> >   DataOutReg <= (others => '0');
> >    elsif (rising_edge(SysClk) or falling_edge(SysClk)) then
> >   if (SCFG_CMD = '1') THEN
> >     DataOutReg <= TT & SD & PCMT0 & PCMT1 & WP_SDO0 & WP_SDO1 & DTR &
> > RTS;
> >   end if;
> > end if;
> >  end process Example2;
>
> > You can imagine a register that clocks on both the rising and falling
> > edge, but you can't build it in an FPGA.
>
> But that does not imply that it couldn't be synthesized using two sets of
> flip flops whose results get combined.  You might not find a synthesis tool
> in 2007 that accepts the above code, but that doesn't mean that there won't
> be one in 2008 that will.  Whether there is such a tool or not depends on
> how many users scream to brand A and X that they really need this.  It can
> be synthesized, just not how you are focusing on how you think it must be
> synthesized.

If you can build the second description, I would like to see that.  Do
you know this is possible or are you just speculating?  I have never
seen a good example of a register clocked on both edges done in an
FPGA.

KJ wrote:
> Bottom line right now for the code I right, I'm 
> finding Altera way ahead of Xilinx and Synplify so I'm working with X and S 
> to get their tools improved so that they too can have less stuff that some 
> would consider to be 'not synthesizable'.

Synplify used to have it over quartus on viewers,
but quartus has caught up. As far as synthesis,
it varies with the design, but I would call
A and S comparable for an altera target.
X needs some focus on advanced synthesis.
For example, I wish they would take this one seriously:

 http://home.comcast.net/~mike_treseler/proc_demo.vhd
 http://home.comcast.net/~mike_treseler/proc_demo_ise_bug.pdf
 http://home.comcast.net/~mike_treseler/proc_demo_ise_fix.pdf

It has been hanging fire since ISE 6.1i,
It wouldn't be so bad if I got an error message.
I get synthesis that does not match simulation.

The suggested "solution"
 http://www.xilinx.com/support/answers/18452.htm
is to avoid the legal code that causes the problem.
Note that brand A and S and Modelsim get it right.

       -- Mike Treseler