now I read almost 200 pages of the book "The Designers Guide to VHDL",
by Peter Ashenden. The thing is that everyone has been recommending the
book, and I want to improve my skills in VHDL.
I'm actually stunned... the book is CRAP by all means. Before reading
that book, I read the book "Circuit Design with VHDL 2004" by Pedroni.
The problem is that I found that Ashenden's book like lives in the dream
world of simulation. It talks along the whole book about the command
"after" within its examples, which is NEVER synthesisable (and many
other non-synthesisable commands with total verbosity), and in the mean
time speculates about the latency in hardware which is a "serious issue"
as the book says when talking about delta delays, while it's never
realistic nor practical, because most of the commands it uses are not
On the other hand, a book like Circuit Design with VHDL, teaches all the
commands, and mentions beside each command whether a command is
sythesisable, and so, with such a book (which is btw only 315 pages
without appendices), I could learn VHDL in less than 2 months and made
many simple circuits and implemented them on my Spartan 3AN Starter Kit.
And I'm now gonna read the new version of that book "Circuit Design and
Simulation with VHDL 2010", which has more practical examples and which
will make me dive deeper in VHDL with no non-synthesisable wonders.
Now what I don't understand, why does everyone recommend that huge book
that talks about wonders that cannot be synthesised in hardware, and
that forces one to read more than 500 pages before even starting to talk
about the synthesis process.
Did I go with VHDL on the wrong foot? Am I on the wrong path? is
simulation really THAT useful? Is being brief or verbose better
nowadays? what would you guys say against these two books and against my
judgement? could you tell me some of your experiences? please advise!
I'm really getting lost and don't know what book to take anymore. I need
to learn more VHDL.
I'm, btw, not an engineer. I'm a PhD student physicist who needs to use
FPGA's for an experiment.
Thank you for any efforts :-)
> is simulation really THAT useful?
Yes. At first my designs have to run in simulator. At second I can test
it on real hardware. To check what's goning wrong is much easyer to use
the simulator, than a logic analyzer...
> is simulation really THAT useful?
Have a look back to ancient times with "only" ASICs: you didn't have to
possibility to "try out wether its working or not." When you start a
ASIC you want to be and you must be sure that its almost finished (and
hopefully only some minor problems may occur). The design (and all of
its components around) has to be simulated thoroughly.
And then you say: Yes, VHDL is simulation and simulation is VHDL.
> is simulation really THAT useful?
And alos for FPGA Designs the only answer to this is: Yes.
The simulator is for a FPGA designer the same thing like the debugger
for the software programmer. And: do you expect to get a litle bit
complex piece of software running without a debugger?
> is simulation really THAT useful?
First book of Pedroni was "Circuit Design with VHDL"
Now comes "Circuit Design and Simulation with VHDL"
Think about that...
> On the other hand, a book like Circuit Design with VHDL ...> mentions beside each command whether a command is sythesisable
You can NEVER say: this exact VHDL statement isn't synthesizeable!
The synthezizer may not be capable to handle a description today, but
with the next software realease the synthesizer can.
And so you will ALWAYS have to look in the synthesizer handbook/guide-
line to know what statements a synthesizer is able to cope with.
> I need to learn more VHDL.
No. You want to learn more FPGA. If you want to learn VHDL then take
Ashenden. But only 5% of VHDL (at maximum) is synthesizeable on hardware
(ASIC/FPGA). The "wait for" statement is the most simple statement not
synthesizeable (yet). There are thousands of other constructs you can
use very efficient in a simulation. Just take a lok at the attributes
'stable or 'last_event or 'delayed...
> "The Designers Guide to VHDL"> why does everyone recommend that huge book> that talks about wonders that cannot be synthesised in hardware
Keep in mind: the name of the book isn't "Designers Guide to FPGA".
Don't throw it away. You will be happy to own it in 2 years...
Thank you for your replies, guys.
The problem with simulation is that not everything can be simulated. For
example, a few weeks ago I coded an SPI for an ADC (LTC1407) with an
analog amplifier with digital interface (LTC6912). How would I ever
simulate such components? these components need some kind of a special
interface for simulation that's provided by the manufacturing company,
so that when I write a code for it, I would see its response on my
simulator, right? such a thing doesn't exist at all. At least as far as
I've seen (does every component has a simulation interface for testing?
I doubt it!). Which makes simulations only useful if I'm building code
from scratch. If I'm using any external components (which is almost
always the case) like ADCs, DACs, amplifiers, network interfaces, ...
etc. Then simulation is totally useless. Right?
Fair enough, Lothar. Your arguments make a lot sense. So you're saying,
that what I need for the mean time is learn more about FPGAs. This
sounds fair and talks to my complaint that Ashenden's book is very
verbose in simulation, or respectively VHDL. So how do I proceed? now I
know almost all the basic commands in VHDL. So what should I read/do? Is
there a book that you recommend to learn about FPGAs conceptually? or
should I just take the manual of XST and use/read it in some way? please
> If I'm using any external components (which is almost> always the case) like ADCs, DACs, amplifiers, network> interfaces, ... etc. Then simulation is totally> useless. Right?
No! You could write some behavioral modules and connect them within your
testbench to the design.
When creating such functional models you could use not-synthesizable
VHDL statements as described in Ashendens book :o)
Thank you for your answer.
berndl wrote:>> If I'm using any external components (which is almost>> always the case) like ADCs, DACs, amplifiers, network>> interfaces, ... etc. Then simulation is totally>> useless. Right?>> No! You could write some behavioral modules and connect them within your> testbench to the design.> When creating such functional models you could use not-synthesizable> VHDL statements as described in Ashendens book :o)
But this is somewhat a circular problem. If I already know how the
devices operate exactly, why would I want to simulate them in the first
place? It took me almost two weeks to know how to communicate correctly
to that ADC with its pre-amplifier without losing any bits. How would a
simulation help in such a thing?
> It took me almost two weeks to know how to communicate correctly> to that ADC with its pre-amplifier without losing any bits.> How would a simulation help in such a thing?
First, simple testbench:
You can easily compare your timing diagrams with the ones required in
the ADC data sheet. That is manual work with eyes and pencil.
Second, more sophisticated testbench:
Let the testbench check the timings you can read in the data sheet of
Third, final testbench:
Read the input for the ADC from a file or generate it by random. Check
the timing on the interface to the ADC. And finally compare the
converted value with the generated ADC input value.
> So you're saying, that what I need for the mean time is learn more about> FPGAs. This sounds fair and talks to my complaint that Ashenden's book is> very verbose in simulation, or respectively VHDL. So how do I proceed?
Take some easy excercises and play with them. Look at the RTL schematics
generated out of your code. See what happens, when you change a minor
part of your design. Understand why that happend.
> now I know almost all the basic commands in VHDL. So what should I do?
Start with a flashing light
Switch over to a chasing light
And then go over to more complex designs as serial port, vga diaplay.
Imagine that you have a really huge design with lots of interfaces and
FSMs that depend on each other and you need to control some machine with
it. Without simulation models every change will require you to dive deep
into the design and check that all circuits still work as intended.
If you have simulation models that do some abstraction you only need to
run the simulator, see whether the interfaces behave correctly (e.g. a
ramp input to the component that feeds that DAC will lead to a ramp
output) and that's it.
Without simulation you'll just die from the complexity.
On the other hand, thing that work in my simulation typically also work
I also bought that book wishing to learn VHDL, wasted money. I bought
another book but about Verilog instead and I have been making quite a
bit of progress. I decided again to give "The designer's..." a try...
there is something wrong with that book. It is not that simulation is
not important is the approach to the whole that I find not very useful.
I haven't used any delays in my simulations and I'd like to include them
because well hardware has them... the problem is how to do that (And I
do not mean the syntax!) but how to realistically estimate how much time
every component needs. Any tips on how to approach this problem ?
> I haven't used any delays in my simulations and I'd like to include them> because well hardware has them...
What hardware? Your FPGA? The external components?
Its not your task as developer to calcutlate the FPGAs internal
> the problem is how to do that (And I do not mean the syntax!) but how> to realistically estimate how much time every component needs.
For timings you read the data sheet of your (external) components. For
the internal delays inside the FPGA the usual way ist not to calculate
whatsoever delays, but to put constraints on your design. So you tell
the toolchain, what timing you want. Thats the completely other way!
Rather than saying "let me see what the resulting delays are", you say
"i want the tools to reach my specific timing". And this you say with
Its like pin assignment constraints: you tell the toolchain where to
put the IO signals.
Timing constraints are similar for Verilog and VHDL.
Just quickly writing about a book: My absolute favorite is "RTL Hardware
Design USING VHDL" by Pong P.Chu. I simply love it and it is never
trying to teach you what you don't know but always what you should know.
> My absolute favorite is "RTL Hardware Design USING VHDL" by Pong P.Chu.
A book having one complete chapter about clocking and synchronizing and
at least 10 pages about metastabiliy, but using the asynchronous reset
scheme throughout, having only 4 lines about the second most critical
asynchronous external signal and stating a simple and uncritical
behaviour to it, is only halfway finished... :-o
Just to say it simple:
Every asynchronous external signal must be synchronized. The reset is a
asynchronous external signal.
If a part of a design doesn't need a reset, then don't implement it.
(For Xilinx users: read the whitepaper WP272)
Ale wrote:> He (Pong P. Chu) some other books like FPGA prototyping by Verilog/VHDL> examples.
Theres also one book specially for the Spartan 3 and even in this the
Xilinx specific considerations with sync and async reset is completely
I'd still say Chu wrote a great introductory book. I tried to approach
the topic with some others and i got nothing but frustrated. With this
book and also the other one which is in particular written for the
Spartan 3, I was able to understand and work right away.
Might be a question of taste and also super FPGa professionals might
have a completely different view than less experienced guys.
> Might be a question of taste
To this: Yes, of course. I don't like the 3-process-fsm style...
> and also super FPGa professionals might> have a completely different view than less experienced guys.
To this: No. In a book specially for Spartan 3 there MUST be at least
a hint on the specific behaviour of Xilinx flipflops! When you use the
async reset, the FFs will be set in the async mode, and therefore they
cannot be set/reset synchronous afterwards.
Heres a German topic on that:
Beitrag "Re: Hardware mit VHDL "richtig" beschreiben."
Maybe Babelfish or Google translator can get it right... ;-)
> Where you use the unsynthesizable "wait"
Of course wait is synthesizeable.
Keep in mind: a process with a sensitivity list is a special case of a
generic process. These two simple samples are similar:
process (a,b,c) begin
Above you say that "wait for" can't be synthesized and then you say it
can... (I only know Verilog!), are there then two "wait xx" statements ?
I see that a wait on would be equivalent to a sensitivity list, what is
the other one for ?
Dave wrote:>>I'm a PhD student physicist who needs to use>>FPGA's for an experiment.>> Then take a look at 'HDL Chip Design' from Douglas J. Smith.> It´s main focus is more on the things you are looking for, I guess.
Thank you. I'm checking it. Hopefully it's available for download :-).
Ale wrote:> I'd check at the University's library... you may be surprised by the> large amount of books available, well at least here in Germany :).
Thank you for the suggestion. But I found it already online and
downloaded it, and it's on my tablet queued for reading xD.
The situation with our library here is fairly complicated. The library
is at city center, and I work in the Clinic of the university, which is
far from there. I don't like hard books. I like to have my books on my
tablet and read them wherever I'm ;-).