Introduction and excuses
Busy period
last few weeks. Even a retired man sometimes has obligations. And other hobbies
perhaps.
I did some programming
with SpaceClaim, what a wonderful 3D software! The keyboard of my laptop got
some Armagnac, what a waste! Now I use an external keyboard… I spent some weeks
in a caravan with my wife, of course I found some time to fiddle with my
bladeRF! And I had an ebook (well, actually a pdf file) about VHDL.
But I found
some time to study more VHDL, surf the web and think about my bladeRF project.
Because the process is more important than my goal/end result I sometimes take
sideways instead of the main road to success. An email from Brian made me
thinking…
Simulate/debug
For a
simple project you just write some code, try it, find some errors, correct it
and finally it is OK. For a little bit more complicated projects this does not
work anymore. You need tools. You need an editor that helps you with the syntax
of your program, whether it is written in C, python or VHDL. Then you need a
debugger/simulator. I don’t like debuggers. I read the error codes, get my
aha-erlebnis, correct my errors (well, some, not all) and recompile. Sometimes a
lot of cycles in this process.
Many times
I saw Mark, a former colleague, use a debugger. He always finds in a very short
time all the errors in a program. In the time that I need to edit and compile
he runs a debugger/simulator and finds all or most errors.
Brian is
right: you need to use Modelsim to simulate your design. Not only to find
errors but also to better understand your very own program!
Modelsim
So I
decided to learn how to use Modelsim. I read the tutorial and did some
experiments. It seems that the tutorial describes a different version than I
have in my computer. I need a different method of working with Modelsim.
Instead of painfully following a script I will try to describe in global terms
what and why in the hope that this leads to a better way of understanding and doing simulation.
In this
blog I will try to describe what I learnt so far, in the next blog I hope to
show some results.
Modelsim
Alterras
tutorial uses two files:
C:\altera\work\counter.vhd
C:\altera\work\tcounter.vhd
Have a
look at these files.
Counter.vhd
Counter.vhd
is a regular vhdl-implementation of a counter. This file looks a bit
complicated/daunting because it is a
universal counter. Furthermore they use a function increment. But this is a nice
example of a universal VHDL-implementation of a counter.
This
counter, counter.vhd, is simulated.
For that,
you need an input for the signals clk and reset from the port specification and
in the simulation the count will be altered by the clk and reset-signals. In
the simulation you should be able to see all these signals.
This
counter becomes the DUT, Device Under Test.
How would
you test this counter on your lab bench? Well, I would take a button for the
reset-signal and a clock-generator connected at the clk-input of the counter.
Then I
would connect some display device at the count output of the counter.
I would
connect a power supply, start my clock generator and press the reset button.
Then I would have a look at the counter. If all is well, you would see an
increasing count value. I.e. the higher order bits of count should change less
often than the lower bits.
This is
exactly what Modelsim will do. You have to connect the DUT to a test-setup.
What is a test-setup? A vhdl-file that tells the setup/connections at your
workbench and the settings of the signal-generator!
tcounter.vhd
Now have
a look at tcounter.vhd
Actually
it is a simple file. It describes the port-specification of the DUT, which is
our counter counter.vhd. Then incorporates it and feeds it with a clock and a
stimulus.
Clock is
a simple process that generates a clock-signal that is 10 ns high, 10 ns low.
One cycle is 20 ns which makes it into a 50 MHz clock. Simple eh?
Stimulus
is a process that generates the reset
signal and then waits forever.
If you
start Modelsim and feed it with these two VHDL-files you have your simulation.
But how exactly to do that?
To be
honest, I don’t know yet, but I will
find out soon…
Stay
tuned!
Conclusion
The email from Brian as a response to my previous message is a perfect example of help from the Internet. Brian brought me back to the main road by a very concise and very good explanation of my problems. He did not solve all my problems by the way and that is good!
I am gonna play around with Modelsim sometime till I know enough to use this product for all my future VHDL-problems. In the meantime I will try to describe what I did in the hope that others will have less problems than I have/had.
Hope this helps
No comments:
Post a Comment