Best Synthesis Method

[Bar Nash]

Hi all

In case of a large design which is the best synthesis method ?

1> To synthesise each block of hardware in order to prove its
"synthesability"
and at the end to synthesise the whole design or .

2> To synthesise the whole design after RTL simulation success ?

Thanks
EC

 

[HT-Lab]

"Bar Nash" <wavesoft@netvision.net.il> wrote in message
news:gccnpe$56q$1@news4.netvision.net.il...

Hi all

In case of a large design which is the best synthesis method ?

1> To synthesise each block of hardware in order to prove its
"synthesability"
and at the end to synthesise the whole design or .

2> To synthesise the whole design after RTL simulation success ?

Thanks
EC

It is always a good idea to check that your code can be synthesised. I use

Precision in script mode (compile only) to check my code periodically. The
compile mode is quick and gives me some useful warnings/errors like unused
signals/missing signals in sensitivity list, inferred instances, latches,
index checking etc.

Hans
www.ht-lab.com

 

[KJ]

On Oct 6, 6:05 am, "Bar Nash" <waves...@netvision.net.il> wrote:

Hi all

In case of a large design which is the best synthesis method ?

1> To synthesise each block of hardware in order to prove its
"synthesability"
       and at the end to synthesise the whole design or .

2> To synthesise the whole design after RTL simulation success ?

Thanks
EC

None of the above.

I usually take #3 which is to synthesize the whole design while design
and simulation are still ongoing. As Hans noted this can find things
that can help speed up getting the design completed but mainly it is
to
1. Shows that you've got the entire build process debugged and ready
once you are ready to start building for real.

2. Help to start becoming aware of the slow paths in the design that
will need some redesign in order to meet timing. Gives you more time
to think about ways to rewrite the code so that it will synthesize to
something simpler that will run faster.

KJ

 

[Andy]

#1, with the addition of synthesizing as much of the whole as is
practical as the project progresses. This is especially important when
multiple developers are working on one project.

In general, synthesize "early and often" to find code problems,
potential timing bottlenecks, resource hogs, etc. Likewise with
simulation, but to find behavioral problems.

Andy

 

[Kevin Neilson]

Andy wrote:

In general, synthesize "early and often" to find code problems,
potential timing bottlenecks, resource hogs, etc. Likewise with
simulation, but to find behavioral problems.

Andy
"Early and often" is good advice. I synthesize parts as I am going

along. Some parts I don't worry about; I know they will work fine,
whereas if I'm using some abstract structure or constant function or
something, I'll try that as soon as I write it to make sure the
synthesizer knows how to handle it.

As you gain experience, you will understand ahead of time where the
problems will be and you'll pipeline and design accordingly. You'll
know if you have too many conditions in your FSM branches or if you have
wide adders these may be the weak points. You'll also design in,
up-front, adjustable delay lines, to account for latency changes later.
-Kevin