Sonata FAQ
You may also want to consult the Errors
and Warnings lists. Also, you may wish
to go through the tutorial provided with the software (...
Symphony EDA\VHDL Simili 2.1\Examples)
Q: Can I download Sonata?
A: Yes, you can download it straight from the company, Symphony EDA.
They provide a limited free license, but the capabilities under this
free license should be enough for your needs.
Q: How do I test my design using the testbench?
A:
- Create a project and add to it, from the
"Project" menu, the VHDL files of your design and the
testbench file.
- To the directory containing the project, add the input and output
files that the testbench requires.
- Compile the files using one of the
buttons on the toolbar.
- Load up the simulator using the
button on the taskbar and select the testbench (architecture or entity,
it doesn't matter) as the top level. This will load up the
simulator waveform.
- Finally, click the
or 
buttons to run the
simulation. Any error messages or warnings will appear in the
bottom panel, letting you know if there is a problem with your design.
Q:
How do I add signals to the waveform?
A: Once the simulator has been loaded, you can right
click on the signals frame in the bottom left corner of the screen and "Add all signals to waveform".
If you wish to add signals from your modules lower down and not just
from the top level, expand the tree under the testbench in the hierarchy
window. Then click on the component you want (they are named by
their labels in the testbench) and its signals and ports will appear in
the window below.
Q:
Why won't the simulator load my design?
A: There are a
number of problems that could cause the simulator to fail
- Missing input and output files could cause I/O failure.
Ensure that you have put these files in the correct directory
- There may be some syntax error with your design. Be sure to
scroll up to the first compilation error message to address the correct
problem. Double-clicking on the error message will take you to the
troublesome line of code.
- Your component names may not match those in the testbench file
(located before the architecture 'begin' statement.
Q:
How do I know what to fix when an ASSERT: ERROR message comes up?
A: There are a number of ways to do this,
including studying your design carefully. A good way to get
to the problem, however, is to load all the testbench signals into the
waveform and double-click the time on the error message. This will
take you to the time of the message and beside the signal names you will
be able to see the values currently assigned to the signals. From
here, you can determine what is going on with your design.
Q: If I edit my design here, will it work the same in the
Foundation software?
A: For the most part, this will be the case.
There are, however, some things that are allowable in a simulator that
cannot be done when the design needs to the synthesized. For
example, internal signals cannot take initial values (Foundation will
give you a warning about this). Also, this simulator will only
test the logical functionality of your design. If there are still
problems with your design but it works okay in the simulator, chances
are that your constraints file has some problems (e.g. missing or
wrong pin assignments) or there are timing issues with your design.
Q:
Can I create my own input and output files to test my design?
A: Yes, you can, but you should understand what is in the
input file before you make your own. The simulator will read the
input and assign certaing signals the values that it reads. It may
take some time understanding the process that takes the input before you
will be able to create your own.
Q:
Can I save the waveform with the output produced?
A: Yes. By saving the
waveform, you will save the produced signals from the display (that is,
those signals shown in the main window of the waveform). You will
not, however, be able to manipulate the waveform as it is just the saved
values of the output.
Q:
How come my design tests fine in the testbench but will not work in the
board?
A: There are a number of reasons that this would be
the case:
- Your pin assigments may be wrong.
- There may be a timing issue with your design. If there are
portions of your design requiring synchronicity, try increasing the
amount of time that the signals have to stabilize.
- There may be some cases in your if statements that are
undefined. If you do not have an else part of your if, the
functionality of this case is entirely up to the implementation
tools. In some cases, functionality is added that is not desired,
but gets added because there is not restriction there.
- The RAM may have stopped responding. If your design relies
on RAM, it's a good idea to use GXSTEST to test the device before
programming it. If there is a major error, you will know that the
RAM is not responding and must be reset (unplug then replug the device).
Q: Why are some of my signals changing when they aren't supposed to?
A: The way that the simulator works is that whenever a signal in
the sensitivity list of a process is changed, the process will be
re-evaluated. This means that if a process changes a signal that is
in its own sensitivity list, it will be re-evaluated. If your process
is dependent on this signal (i.e. reacts differently when this signal
changes), this will change the behaviour, causing unwanted
behaviour. Note: this behaviour will not show up in hardware, but
will most definitely affect your simulation
Q: Why is my signal being set to unknown ('U') when I am
explicitly setting it to a known value?
A: This is probably happening because you have multiple drivers.
That is, you are assigning to one signal from two different processes.
Whereas Foundation will check this in synthesis to ensure that you are
not specifying this behaviour, Sonata does not check for this
behaviour. Instead, when the simulator gets conflicting assignments
to a signal, it will not chose and set the signal to unknown. If this
is the case, there is likely a value for your signal that can be
explicitly set, and one or more others that cause a problem. The
bottom line is that you shouldn't have a signal being assigned to from
multiple processes.
[Return to CMPUT 329 Lab Home Page]