Non-synthesizable Elements
Inder Singh
I'm new to VHDL.
What use is there for
non-synthesizable VHDL
elements such as files,
floating point numbers, etc?
It seems as if anyone new
to VHDL starts modeling
with all these constructs
until they begin synthesis.
At which point, they must
re-code everything to adhere
to the synthesis policy...
Bert Molenkamp
You look to VHDL from a synthesis point of view. But
VHDL can be used also for:
- stimuli generation.
In many companies the test data are in a file, and this
file is read by a "VHDL program".
- models
Some companies generate VHDL models for components (e.g. Logic
Modeling). These models have nice timing charateristics so that
you can simulate with expected delays.
But 'delays' are not synthesisable.
- specification
Before you write in VHDL "HOW" you are going to implement something, you
may also write first in VHDL "WHAT" you want. This WHAT (specification) need not
to be synthesizable; it should be a clear description
- access types (pointers)
Suppose you have designed a CPU with a 32 bits data bus. And now you want
to simulate it in the environment, e.g. a memory is connected to it. How large
should that memory be? 2**32 adresses? But you could also use a dynamic
structure (access types) to reduce the memory usage (and increase simulation
speed, if simulation was possible at all? "OUT OF MEMORY?"
- ..... and more
Egbert Molenkamp
Dept. of Computer Science
University of Twente
PO Box 217
7500 AE Enschede
the Netherlands
email: mole...@cs.utwente.nl
Andrew Rushton
On Mon, 10 Jun 1996, Inder Singh wrote:
> What use is there for
> non-synthesizable VHDL
> elements such as files,
> floating point numbers, etc?
VHDL is not a synthesis language. It is a general-purpose HDL which supports all
levels of design from system-level downto (or upto depending on your viewpoint)
netlist-level. Synthesis is somewhere in the middle of this and so does not
use all the features.
> It seems as if anyone new
> to VHDL starts modeling
> with all these constructs
> until they begin synthesis.
> At which point, they must
> re-code everything to adhere
> to the synthesis policy...
The lesson is - learn VHDL for synthesis and write only within that domain. In
other words, write for synthesis, not for simulation. You could even use a text
book based on this approach! For example:
<PLUG warning="vested interest">
Title: VHDL for Logic Synthesis
Author: Andrew Rushton
Publisher: McGraw-Hill c1995
ISBN: 0-07-709092-6 (Hardback)
Price: 40 UK Pounds
LC CALL NUMBER: TK7885.7 .R87 1995
</PLUG>
Later on, when you are clear what is and is not synthesisable, you will pick up
the rest of the language and maybe use it for trying out design ideas at a
higher level before committing yourself to design.
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
-- Andy Rushton #8-) email a...@transeda.com --
-- TransEDA Limited tel. +44-1703-255118 --
-- UK fax. +44-1703-270278 --
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
use std.disclaimers.all;
Dan Prysby
>non-synthesizable VHDL
>elements such as files,
>floating point numbers, etc?
>
>to VHDL starts modeling
>with all these constructs
>until they begin synthesis.
>At which point, they must
>re-code everything to adhere
>to the synthesis policy...
A good beginner question.
VHDL for synthesis requires a restricted use of the language.
Synthesis algorithms currently require inference of registers,
latches, and combinatorial logic.
But not all use of VHDL is to create a real circuit via synthesis.
Consider 4 typical uses:
1. A VHDL model of a component (like a FF), circuit, or system.
Here you're modeling behavior such that it accurately represents
the physical part. You can use all VHDL constructs.
2. VHDL code to design a circuit from library cells.
Here you're specifying behavior in a restricted form such that
a synthesis tool can create a circuit that meets timing at
minimal cost of area and power.
3. VHDL code written to try out a concept like a complex algorithm.
Here, you may use constructs too complicated to synthesize
but faster to code and try out.
Once the algorithm is proven via regression testing, re-coding,
then synthesis, then regression testing on the synthesized circuit
follows. The original high-level code is often used as a golden
model in the testbench to compare circuit operation against.
4. VHDL code as a testbench to drive signals and values, check/compare
expected signals and values. Here, files are useful as the "data"
that is input to or used as expected values to compare against.
My personal example: I designed an interface to an RC network.
My code for the interface was synthesizable.
My testbench modeled the RC network, freely using VHDL constructs.
It was accurate enough - the actual circuit worked.
So it's better to have more capability than less and it is useful too.
Dan Prysby
John Cooley
>The lesson is - learn VHDL for synthesis and write only within that domain. In
>other words, write for synthesis, not for simulation.
[ Andy promoting his own book deleted. ]
>Later on, when you are clear what is and is not synthesisable, you will pick
>up the rest of the language and maybe use it for trying out design ideas at a
>higher level before committing yourself to design.
Here! Here!
Andy, you're RIGHT ON that hardware designers should *first* learn the
synthesizable subset *first* and then later play with the non-synth
constructs. (This advice holds true for both VHDL and Verilog based
designers!)
- John Cooley
Part Time EDA Consumer Advocate
Full Time ASIC, FPGA & EDA Design Consultant
===========================================================================
Trapped trying to figure out a Synopsys bug? Want to hear how 4258 other
users dealt with it ? Then join the E-Mail Synopsys Users Group (ESNUG)!
!!! "It's not a BUG, jco...@world.std.com
/o o\ / it's a FEATURE!" (508) 429-4357
( > )
\ - / - John Cooley, EDA & ASIC Design Consultant in Synopsys,
_] [_ Verilog, VHDL and numerous Design Methodologies.
Holliston Poor Farm, P.O. Box 6222, Holliston, MA 01746-6222
Legal Disclaimer: "As always, anything said here is only opinion."
Michael T. Horne
>Andrew Rushton <a...@transeda.com> wrote:
>>The lesson is - learn VHDL for synthesis and write only within that domain.
>>In other words, write for synthesis, not for simulation.
>>
>>up the rest of the language and maybe use it for trying out design ideas at
>>a higher level before committing yourself to design.
>
>Here! Here!
>
>Andy, you're RIGHT ON that hardware designers should *first* learn the
>synthesizable subset *first* and then later play with the non-synth
>constructs. (This advice holds true for both VHDL and Verilog based
>designers!)
> - John Cooley
Guys, I beg to differ. By learning the full language from the start,
the designer has a much broader range of "tools" to use -- that is,
the behavioral aspects of an HDL. With designs becoming so complex,
it's wise to model the behavior of your design before you commit to
how you're going to implement it (coding for synthesis is coding for
implementation, not for behavior). It's a lot easier to do early "what if"
design work at the behavioral level than at the implementation (RTL) level.
Learning the synthesizable subset is trivial, *especially* if you
already have experience with the language as a whole. What is not
trivial is learning the "tricks" of RTL design, since they are in
many ways dependent upon how synthesis tools work (knowing the tricks
can keep an Engineer gainfully employed for a very long time:).
We have seen many, many designers who spent their time learning the
full HDL first (that is, the constructs that provide high design leverage),
then picked up the synthesizable subset with ease. As we show in
our HDL classes, learning the subset is trivial; learning how to use
it effectively for implementation is not.
Perhaps a good analogy would be a shop full of tools, where each tool is
some construct of an HDL. You have a full range of tools available to
you, each useful for a variety of design work, but not for *all* design
work. Some tools are best for behavioral design, but other are better
for RTL work. Assuming you are new to the shop, your first job is to
design something using the tools. Not finding out about the entire set
of tools at your disposal before you tackle a design job is at least
wasteful, and probably irresponsible.
Now, I must be clear that I am not suggesting that *all* designers should
use all of the constructs in an HDL in their everyday work. Indeed, architects
will likely spend most of their time coding for behavior ("what if?"), while
implementors will code for synthesis ("that's what I want"). However, all
Engineers should learn both the behavioral and RTL parts of the language
to gain the knowledge necessary to design efficiently and effectively. The
notion that it's easier or better to learn the subset first is bogus -- our
High Level Design course students have proven otherwise hundreds of times.
And to quote John, this advice holds true for both VHDL and Verilog based
designers. ;)
Michael
--
-----------------------------------------------------------------------------
Michael Horne, President Phone: +1-503-531-9790
Qualis Design Corporation FAX: +1-503-629-5525
Beaverton, Oregon E-mail: mi...@qualis.com
Celia Clause
Michael T. Horne <mi...@qualis.qualis.com> wrote:
>In a recent article jco...@world.std.com (John Cooley) writes:
>>Andrew Rushton <a...@transeda.com> wrote:
>>>The lesson is - learn VHDL for synthesis and write only within that domain.
>>>In other words, write for synthesis, not for simulation.
>>>
>>>Later on, when you are clear what is and is not synthesisable, you will pick
>>>up the rest of the language and maybe use it for trying out design ideas at
>>>a higher level before committing yourself to design.
>>
>>Here! Here!
>>
>>Andy, you're RIGHT ON that hardware designers should *first* learn the
>
>Learning the synthesizable subset is trivial, *especially* if you
>already have experience with the language as a whole. What is not
>trivial is learning the "tricks" of RTL design, since they are in
>many ways dependent upon how synthesis tools work (knowing the tricks
>can keep an Engineer gainfully employed for a very long time:).
Sorry, I have to agree with John and Andy on this one. To use your
shop analogy (which I deleted to save space.), you don't start in
wood shop by learning every single type of tool available. The
teacher starts you off with a few basic tools so that you can get
the hang of things.
To many people don't take the time to learn how Dependants your
final design is on the type of code you write. Even concentrating
on the synthesis constructs, there is a big learning curve to
high level design. Engineers should understanding of what can
and can't be synthesized before worrying about the myriad of
behavioral constructs.
-----------------------------------------------------------------------------
--Celia Clause Celia's Verilog/EDA web page:
cel...@teleport.com http://www.teleport.com/~celiac/ver_eda.html
--
-----------------------------------------------------------------------------
--Celia Clause Celia's Verilog/EDA web page:
cel...@teleport.com http://www.teleport.com/~celiac/ver_eda.html
Steven Bird
<jco...@world.std.com> writes
>Andrew Rushton <a...@transeda.com> wrote:
>>The lesson is - learn VHDL for synthesis and write only within that domain. In
>>other words, write for synthesis, not for simulation.
>
>
>>up the rest of the language and maybe use it for trying out design ideas at a
>>higher level before committing yourself to design.
>
>
>Here! Here!
>
>Andy, you're RIGHT ON that hardware designers should *first* learn the
>constructs. (This advice holds true for both VHDL and Verilog based
>designers!)
What about testbenches? Would you only use RTL constructs? Noting that
there are typically (many) more lines of TB code than functional, not
knowing the more abstract constructs would be very inefficient use of
precious time. I feel that knowing the full breadth and depth of an HDL
first gives you far greater flexibilty.
------------------------------------------------
Steven Bird
VIZEF Limited
Tel: 44 (0)1628 481571
Fax: 44 (0)1628 483902
------------------------------------------------
Mike McNamara
The cast:
Celia > is cel...@teleport.com (Celia Clause)
Michael > is Michael T. Horne <mi...@qualis.qualis.com>
Andy > is Andrew Rushton <a...@transeda.com>
John > is jco...@world.std.com (John Cooley)
Andy > The lesson is - learn VHDL for synthesis and write only
Andy > within that domain. In other words, write for synthesis, not
Andy > for simulation.
Andy >
Andy > Later on, when you are clear what is and is not
Andy > synthesisable, you will pick up the rest of the language and
Andy > maybe use it for trying out design ideas at a higher level
Andy > before committing yourself to design.
John >
John > Here! Here!
John >
John > Andy, you're RIGHT ON that hardware designers should *first*
John > learn the synthsizable subset of what ever HDL they use...
Michael > Guys, I beg to differ. By learning the full language
Michael > from the start, the designer has a much broader range of
Michael > "tools" to use. Learning the synthesizable subset is
Michael > trivial, *especially* if you already have experience with
Michael > the language as a whole. What is not trivial is learning
Michael > the "tricks" of RTL design, since they are in many ways
Michael > dependent upon how synthesis tools work (knowing the
Michael > tricks can keep an Engineer gainfully employed for a very
Michael > long time:).
Celia > Sorry, I have to agree with John and Andy on this one. To
Celia > use your shop analogy (which I deleted to save space.), you
Celia > don't start in wood shop by learning every single type of
Celia > tool available. The teacher starts you off with a few basic
Celia > tools so that you can get the hang of things.
Celia > Too many people don't take the time to learn how dependant
Celia > your final design is on the type of code you write. Even
Celia > concentrating on the synthesis constructs, there is a big
Celia > learning curve to high level design. Engineers should have
Celia > an understanding of what can and can't be synthesized
Celia > before worrying about the myriad of behavioral constructs.
Here here! Lets get some goal oriented focus here: The goal, in case
we've forgotten, is to deliver a netlist to the fab, which meets
timing, implements desired functionality, and gets there on time.
Non-goals are using an ESDA tool, using a synthesis tool, using a
simulator; using an HDL, and using every syntax of the HDL. True,
many of these will help you reach your goal; but they themselves are
NOT the goal.
Everything that is not critical to the path to the goal should be
examined with a jaundiced eye: including the synthesis tool. (Yes,
John, sometimes (too often on my last project) a designer can get
better timing, less area, et cetera by instantiating desired gates.)
Meeting timing is a two value variable: yes or no. If you don't meet
timing, it doesn't work. Getting the wrong answer is pretty horrible,
as well; however _sometimes_ you can redefine the right answer in
terms of what your hardware actually does... (That's why we have our
own OS group, silly)
Face it: We have little time. There are a lot of other people building
very similar projects to that you are working on. The first one to
market with a decent solution wins (modulus good/bad marketing, sales,
luck, having Internet or Java in your name...)
Sure, learn all the constructs of the language. I became a Unix guru
in the early eighties by the little known, and rarely practised
strategy of READING ALL THE MANUALS.
Real wizardry comes not from cluttering your head with inventories of
what spells and potions are available; but rather from using the right
spell at the right time. One can perform wizardry by luck; most is
done by experienced, goal orientated professionals who have learned
what works and what doesn't.
-mac
--
Michael McNamara Silicon Sorcery <http://www.silicon-sorcery.com>
Get my emacs mode (subscribe for free updates!) at
<http://www.silicon-sorcery.com/verilog-mode.html>
Michael T. Horne
>Here here! Lets get some goal oriented focus here: The goal, in case
>we've forgotten, is to deliver a netlist to the fab, which meets
>timing, implements desired functionality, and gets there on time.
Ok, we've danced around this long enough. ;) Let's *really* talk
about The Goal:
The goal is to provide a high-quality product to a
viable market while minimizing time to profit.
Note that this goal does not state *how* you get there, only
that you 1) need to create a product for a market that exists
or can be created, 2) it must be of high quality, and
3) you have to make a profit in the shortest time possible.
I trust that these are self-evident.
With that goal in mind, you formulate a product development
strategy for getting there. With a strategy in hand, you
then define tactics, each of which should get you closer to
your goal while (hopefully) reducing your risks. Anything
that increases risk should be (as Mac states) examined
with a jaundiced eye. Formulating tactics and assessing risk
is not an easy task, *especially if you are unaware of other
viable alternatives available to you*.
Now, with that "New Product Development 101" review complete ;) ,
we get to the root of our disagreement. What I've been hearing
in this thread is that engineers should just learn the basics of
an HDL to get the job done, then learn the higher-level constructs
in their infinite spare time. Once could reasonably assume that
these ideas are based on the following assumptions:
1. All engineers should learn the synthesizable subset
first because all engineers design ASICs.
2. Architectural design and "what if" analysis is best
done using the subset.
3. Engineers write few tests, and what tests they do
write can exclusively use the language subset or (*gak*)
test vectors.
All of these assumptions are problematic:
1. Many, many, MANY engineers are desiging board-level
products, and the synthesizable subset is of limited
use to them. You *can* design a board using behavioral
HDL for individual blocks, not even touching a schematic
until you are *ready* for implementation (much as you
shouldn't start coding RTL until you really know *what*
you're implementing). Additionally, many engineers are
solely responsible for testing and modeling -- the
higher-level constructs of HDLs will give them much
more leverage (and therefore reduce risk and time to
profit) than the RTL subset.
Steven Bird's reply put it best:
> What about testbenches? Would you only use RTL
> constructs? Noting that there are typically (many)
> more lines of TB code than functional, not knowing
> the more abstract constructs would be very
> inefficient use of precious time. I feel that knowing
> the full breadth and depth of an HDL first gives
> you far greater flexibility.
2. Architectural design is best done at the behavioral
level where you have the most flexibility and the easiest
ability to make changes. Structural design and implementation
are best done at the RTL level.
3. You must perform tests to confirm that what you designed
is what you *think* you designed. It's CRITICAL, guys!
Are you going to go the old route of writing "testbenches"
that use test vectors? The successful clients we work
with spend at least 50% of their total design time working
on verification, and they sure as hell don't use test
vectors or RTL code to verify huge ASICs/FPGAs/boards!
To make the verification process fly, you've got to use
the highest leverage elements of the language to
1) reduce the amount of testbench coding and 2) to get
simulations to run in a realistic amount of time.
Given the reality of design (including architectural work,
"what if" analysis, test strategy development and implementation,
and RTL coding/implementation), you are doing yourself a great
disservice (and unnecessarily binding your hands) by focusing
solely on the synthesizable subset. Learning the higher level
constructs is not rocket science, guys, it's relatively
straightforward and incredibly beneficial in everyday design
work. Further, developing a design methodology (strategy)
so that you can design *smarter*, not harder, requires you to
know what tools are at your disposal -- including the full
language and its appropriate application.
Mac continues:
>Non-goals are using an ESDA tool, using a synthesis tool, using a
>simulator; using an HDL, and using every syntax of the HDL. True,
>many of these will help you reach your goal; but they themselves are
>NOT the goal.
Correct -- they are tactics, each of which must be individually
assessed. Choose only those tactics that get you closer to the goal
while balancing risk. But how do you assess those tactics if you
don't know what they can do for you?
>Face it: We have little time. There are a lot of other people building
>very similar projects to that you are working on. The first one to
>market with a decent solution wins (modulus good/bad marketing, sales,
>luck, having Internet or Java in your name...)
>
>...
>
>Real wizardry comes not from cluttering your head with inventories of
>what spells and potions are available; but rather from using the right
>spell at the right time. One can perform wizardry by luck; most is
>done by experienced, goal orientated professionals who have learned
>what works and what doesn't.
BINGO! Absolutely! Learning for the sake of learning may be fun,
but that's not what we're espousing here. We have found again and
again that the most successful projects/engineers are those that
review the widest set of tactical options available to them when
desiging new products. You can't accomplish that without knowing
what's available and how it can be used. And you can't do that if
you greatly reduce your scope of vision (for example, to the
synthesizable subset of the language).
Celia Clause
In article <4ra398$8...@news0.rain.rg.net>,
Michael T. Horne <mi...@corvette.qualis.com> wrote:
>
> 3. You must perform tests to confirm that what you designed
> is what you *think* you designed. It's CRITICAL, guys!
> Are you going to go the old route of writing "testbenches"
> that use test vectors? The successful clients we work
> with spend at least 50% of their total design time working
> on verification, and they sure as hell don't use test
> vectors or RTL code to verify huge ASICs/FPGAs/boards!
> To make the verification process fly, you've got to use
> the highest leverage elements of the language to
> 1) reduce the amount of testbench coding and 2) to get
> simulations to run in a realistic amount of time.
>
First of all, I resent the implication that all of the people who
responded to your posts don't verify designs, have not learned the higher
level constructs of the language, and are generally clueless about the
uses that verilog is being put to in the industry. All of the people
who have responded to your posts (both those who agree with you and
those who don't) have many years of HDL design behind them.
Second, no one is saying that you shouldn't learn the behavioral constructs
of the language. We are saying that you should learn synthesizable
construct FIRST. (This is not the same as saying don't learn anything
but synthesis constructs!) The reason I advocate this is, many ASIC
designers (and board designers who use synthesis) spend a bunch of
time in a Verilog class learning primarily behavior constructs. Then
when it comes time to synthesize the design they struggle to understand
why they aren't getting the correct logic, why there code isn't
sythesizable and why they will never be able to meet their timing
constraints with the type of code they have constructed. The behavioral
part of the language is easy to pick up afterwards. And I don't mean
years afterwards, I mean after spending several weeks writing
sythesizable code and understanding how the whole synthesis process
works.
Designers I have taught verilog in this manner have been pleased with
how quickly they were able to understand the design process. I have
had many people complain that generic verilog courses don't spend
enough time explaining the subtle issues with synthesis. It is
far better to learn these things up front instead of discovering them
by making mistakes on your first design project.
>BINGO! Absolutely! Learning for the sake of learning may be fun,
>but that's not what we're espousing here. We have found again and
>again that the most successful projects/engineers are those that
>review the widest set of tactical options available to them when
>desiring new products. You can't accomplish that without knowing
>what's available and how it can be used. And you can't do that if
>you greatly reduce your scope of vision (for example, to the
>synthesizable subset of the language).
Once again, I wasn't saying that you shouldn't learn the rest of the
language. (Although, some of the PLI stuff could wait for quite a
while.) I was saying learn sythesis constructs FIRST. Get to understand
what your code is implying. And THEN learn the behavioral constructs
that are less complicated. (Behavioral verilog looks a lot like C, so
most people pick up on the behavioral part quickly.)
If you never need to synthesize your HDL code, obviously, it really won't
matter what you learn first. I think everyone understands this, so I
really don't see why you keep bringing up the issue of board designers
who don't use synthesis.
Steven Bird
>
>>
>>Real wizardry comes not from cluttering your head with inventories of
>>what spells and potions are available; but rather from using the right
>>spell at the right time. One can perform wizardry by luck; most is
>>done by experienced, goal orientated professionals who have learned
>>what works and what doesn't.
>
>but that's not what we're espousing here. We have found again and
>again that the most successful projects/engineers are those that
>review the widest set of tactical options available to them when
>what's available and how it can be used. And you can't do that if
>you greatly reduce your scope of vision (for example, to the
>synthesizable subset of the language).
>
>
This is the basis of education, you go to school not to fill your head
with every lesson taught, but to learn what's possible. Then later (in
my case *much* later) you may not remember exactly how to do a specific
task, but (hopefully) you'll know its possible and can then target your
reseach of the solution with focus... Ignorance of the possibilities is
no defense for failure.
Michael T. Horne
Steven Bird wrote:
> Ignorance of the possibilities is no defense for failure.
That's wonderful, Steven! Very succinct! A great summary, and exactly to
the point I've been trying to make.
Michael
-----------------------------------------------------------------------------
Michael Horne, President Phone: +1-503-644-9700
Qualis Design Corporation FAX: +1-503-643-1583
Beaverton, Oregon E-mail: mi...@qualis.com
Michael T. Horne
Let me start by saying I greatly value this stimulating discussion.
Celia Clause wrote:
>
> In article <4ra398$8...@news0.rain.rg.net>,
> Michael T. Horne <mi...@corvette.qualis.com> wrote:
> >
> > The successful clients we work
> > with spend at least 50% of their total design time working
> > on verification, and they sure as hell don't use test
> > vectors or RTL code to verify huge ASICs/FPGAs/boards!
> > To make the verification process fly, you've got to use
> > the highest leverage elements of the language to
> > 1) reduce the amount of testbench coding and 2) to get
> > simulations to run in a realistic amount of time.
> >
>
> First of all, I resent the implication that all of the people who
> responded to your posts don't verify designs, have not learned the higher
> level constructs of the language, and are generally clueless about the
> uses that verilog is being put to in the industry.
I'm sorry you feel offended, Celia, but I never said that. Indeed, this
forum has some of the smartest minds in the industry (send me e-mail for a
list). I simply stated that testing/verifying your design is critical to
your success, and that I know many, many Engineers who spend 50% of their
effort on verification. As a natural implication, if you're going to spend
50% of your time on test, you'll want to use a sound test methodology and the
highest-level constructs to write your test code. You will have a tough time
doing that if you aren't familiar with the high level constructs. In short,
knowledge is power to choose what is appropriate for the task at hand.
> Second, no one is saying that you shouldn't learn the behavioral constructs
> of the language. We are saying that you should learn synthesizable
> construct FIRST.
And here is where we differ. I believe the whole language should be taught
from the get-go. I'll restate my core belief based on real data -- learning
the full language from the start provides real, usable leverage and allows
the designer to make informed design decisions. After focusing on how to do
design using the high-level constructs, virtually all of our students have
very little difficulty learning the synthesizable subset -- indeed, knowing
the high-level constructs provides *more* insight into why the subset is a
restricted set of the language. With the foundation of the whole language to
go on, it becomes easy for Engineers to understand the garbage-in/garbage-out
nature of synthesis tools, and perhaps more importantly, *why* they generate
the logic that they do. Please understand that this is not theory; this is
based on our actual experience training hundreds of engineers in HDLs and
High Level Design.
> The reason I advocate this is, many ASIC
> designers (and board designers who use synthesis) spend a bunch of
> time in a Verilog class learning primarily behavior constructs. Then
> when it comes time to synthesize the design they struggle to understand
> why they aren't getting the correct logic, why there code isn't
> sythesizable and why they will never be able to meet their timing
> constraints with the type of code they have constructed. The behavioral
> part of the language is easy to pick up afterwards. And I don't mean
> years afterwards, I mean after spending several weeks writing
> sythesizable code and understanding how the whole synthesis process
> works.
While I know of very, very few Vendors who provide true Behavioral HDL
training classes, I agree that the flow and content of the classes available
is VERY poor. With poor instruction comes confusion, and what you cite is
not an unusual outcome of the Vendor training generally available. That's
why our intro class to High Level Design using HDLs is completely different.
We paint the big picture, then help the students fill in the details. Since
design is so much more than coding for synthesis, we teach the language as if
it is a tool, a leverage point for accomplishing design. And as I stated
before, new product design includes (among other things):
- Architectural design and "what if" analysis
- Test strategy development and implementation
- Design implementation through RTL coding and/or schematic entry
Celia, it seems to me that we don't disagree on "what" to learn or "why" to
learn it, only "how" to learn it.
> I have had many people complain that generic verilog courses don't spend
> enough time explaining the subtle issues with synthesis. It is
> far better to learn these things up front instead of discovering them
> by making mistakes on your first design project.
I agree whole-heartedly. You're talking about the "hints and kinks" of
coding for synthesis, and it is critical that it be covered in any real
synthesis class. However, as an intro to HDLs or desiging products using
HDLs, it's not enough. The student is still too close to the canvas; he
needs to step back to see the big picture.
> Once again, I wasn't saying that you shouldn't learn the rest of the
> language. (Although, some of the PLI stuff could wait for quite a
> while.)
You won't get any argument from me (especially about the PLI ;).
> If you never need to synthesize your HDL code, obviously, it really won't
> matter what you learn first. I think everyone understands this, so I
> really don't see why you keep bringing up the issue of board designers
> who don't use synthesis.
Ah, but gross generalizations were made from the start about "if you're going
to learn [Verilog][VHDL], start with the synthesizable subset first." Most
designers, however, aren't designing ASICs, a fact that has been soundly
ignored. Frankly, the "next-wave" of HDL users will be board-level and
FPGA/Macro-PLD designers (by definition). It is my considered opinion that
those designers will achieve maximum leverage (and the most success) from
HDLs by learning the behavioral constructs first, followed by the
synthesizable subset, *within the context of a sound design methodology*.
And by the way, at the risk of starting another HDL religious war, you can
get where you need to go with either language ;).
Michael
-----------------------------------------------------------------------------
Vijay A Nebhrajani
In article <4rbk9v$s...@nadine.teleport.com>, cel...@teleport.com (Celia Clause) writes:
:->Second, no one is saying that you shouldn't learn the behavioral constructs
:->of the language. We are saying that you should learn synthesizable
:->construct FIRST. (This is not the same as saying don't learn anything
:->but synthesis constructs!)
As far as this goes, I have to agree. As a pedagogical point, it is true
that *synthesis* should be taught earlier. The simple reason: simulation
is the abstract equivalent of testing, and you gotta design first! And
since the non-synthesizable constructs have little to do with getting the
(synthesizable) design right...
As a matter of practice, I always write a behavioral model first, and
hand it over to my client as soon as possible, asking him to simulate and
verify that the model meets his specs. While doing this modeling, I tend
to use a large subset of VHDL. The design actually uses a far smaller subset
of the language.
As such, I feel that it is important that the entire language be known...
BUT
the synthesizable subset should come first,
IF
you are teaching or learning.
Are we done yet? To each, his (or her) own style!
-- Vijay
Andrew Rushton
This thread has grown unexpectedly but interestingly!
The issue that comes to mind for me that seems to have been missed in this
discussion, is the issue of time - time to learn that is. Very few people have
the luxury of the time required to learn the whole of a language (any language,
let alone a big, cumbersome, designed-by-committee one like VHDL) in a
context-free way and then go away and apply it in whatever their context is.
More likely, and this is typical of the engineers that have been on my course
(whoops, another plug, they just slip out), they will learn what they need *now*
and learn more as they need it. In my experience, many engineers start to use
HDLs because they are starting to use synthesis, so the *now* requirement is to
learn the synthesis subset first. Then they expand their use into other levels
of design. I have never yet come across anyone who started by using HDLs for
system modelling and then moved into other areas (although such people may exist
of course, I just haven't met one). In other words, HDL use tends to be
bottom-up, not top-down, with the bottom level of HDL usefulness being RTL
synthesis.
Another correspondent raised the issue of test benches (sorry, my emailer
doesn't do those fancy multiple quotes). This is a good point - of course anyone
learning VHDL for synthesis will also need to learn VHDL for test benches.
This doesn't change the basis of my original point, it just expands it a bit.
Often test benches can be handled in a formulaic way anyway, so it is not a big
issue once you've learnt a workable formula.
--
\0/ \0/ \ \ / / \0/ \0/
| / /) | (\ \ |
__/ \___/\___/0\___/0\___/0\___/\___/ \__
Andy Rushton - TransEDA Limited UK
a...@transeda.com
Celia Clause
In article <Pine.SUN.3.90.96070...@transeda.com>,
Andrew Rushton <a...@transeda.com> wrote:
>
>The issue that comes to mind for me that seems to have been missed in this
>discussion, is the issue of time - time to learn that is. Very few people have
>the luxury of the time required to learn the whole of a language (any language,
>let alone a big, cumbersome, designed-by-committee one like VHDL) in a
>context-free way and then go away and apply it in whatever their context is.
This is exactly the point I was trying to make. Although verilog is
much simple, you still have quite a few constructs of the language that
are not used very often. These constructs can be taught as time allows.
One poster mentioned that if you already know C, the language itself is
not very difficult. I have found that this is true for most of the
people that I have worked who have learned C. Unfortunately, many
hardware engineers haven't learned C or have not used a programming
language lately. For these people, it can take quite a bit of time
to understand how to use an HDL.
Michael T. Horne
Andrew Rushton wrote:
>
> This thread has grown unexpectedly but interestingly!
Agreed!
> The issue that comes to mind for me that seems to have been missed in this
> discussion, is the issue of time - time to learn that is. Very few people have
> the luxury of the time required to learn the whole of a language (any language,
> let alone a big, cumbersome, designed-by-committee one like VHDL) in a
> context-free way and then go away and apply it in whatever their context is.
I agree -- perhaps 1% of the hundreds of people we've trained learn the language
with such a relaxed pace. The other 99% need it for specific design
responsibilities, usually NOW (or yesterday!). However, as one other poster
mentioned, learning the full language is not like earning your Bachelor's degree
-- we're talking about a difference of a few days. Sure, becoming greatly skilled
in the use of the language takes time, but that's true for RTL as well as
behavioral coding.
> I have never yet come across anyone who started by using HDLs for
> system modelling and then moved into other areas (although such people may exist
> of course, I just haven't met one).
Fascinating. At least 40% of our course attendees start by using HDLs for system
modeling and test development. Most of the companies we consult with use HDLs for
system design/modeling from the start, with RTL coding coming much later. One
large client of ours needs to implement 1.5 to 2 million gates of high speed logic
across 6 ASICs -- can you imagine what it would be like trying to define the
system architecture and test out ideas with RTL code? Any Engineer who started
writing RTL code before behavioral models and testbenches were written would be
shot! Clearly, we talk to different people. ;)
> In other words, HDL use tends to be bottom-up, not top-down, with the bottom
> level of HDL usefulness being RTL synthesis.
Let me start by saying that I am an Engineer with extensive ASIC experience,
primarily in the area of DSP and audio/vido processing. At the risk of making a
gross generalization, I have found that most Engineers take a bottom-up approach
because that's what they're used to. Most Engineers are detail oriented, a skill
that lends itself well to bottom-up design. However, a basic tenet of large
system design is that you don't spend your time on the details of implementation
until you know what it is your designing (that is, until you've formed a
strategy). In the strategy development stage, RTL-level coding is (at best)
inefficient, and probably inappropriate. Yes, you can use RTL-level coding for
architectural design and what-if analysis, but that doesn't mean you should. Time
is of the essence -- use the appropriate tool for the task at hand (and regularly
review the available tools so you know what's available).
Michael
--