Soft-Core Processor Design - CiteSeer

the HDL coding style. To ensure that the desired megafunction will be inferred from the HDL,
the coding style guidelines outlined in [16] should be followed.
Aside from the design flow steps described in the section 2.3, the Quartus II design flow
includes two optional steps: timing analysis and simulation. Timing analysis provides information
about critical paths in a design by analyzing the netlist produced by the fitter. Simulation is used
for design verification by comparing the expected output with the output of the design simulation.
The Quartus II simulator supports two modes of simulation; functional and timing. Functional
simulation verifies the functionality of the netlist produced by synthesis. At that level, timing
parameters are unknown, since there is no information on mapping into the physical device.
Therefore, the functional simulation ignores any timing parameters and assumes that the
propagation delays are negligible. The timing simulation extracts the timing information from the
fitting results, and uses it to simulate the design functionality, including timing relations among
signals. The timing simulation gives more precise information about the system behaviour at the
expense of increased simulation time.
Quartus II also supports the use of other Electronic Design Automation (EDA) tools. One such
tool is ModelSim [19], the simulation tool which was particularly useful for the work in this
thesis. In addition to functional and timing simulation, ModelSim also supports behavioural
simulation. The behavioural simulation verifies the functionality of the circuit description,
without any insight into actual implementation details. For instance, if the circuit specification is
given in an HDL, the behavioural simulator would simulate the HDL code line by line; like a
program in a high-level language. Unlike the functional simulator, the behavioural simulator does
not take into account how the circuit specification maps into logic gates, or if it can be mapped at
all. A design that passes the behavioural verification may not function correctly when
implemented in logic, since it is unknown how it maps to the hardware.
To make sure that the behavioural description will compile and produce a circuit with
intended behaviour, designers should follow the design recommendations provided in the Quartus
II documentation [16]. This is especially true when writing HDL code. Both Verilog and VHDL
were designed as simulation languages; only a subset of the language constructs is supported for
synthesis [20,21]. Therefore, not all syntactically correct HDL code will compile into the
functionality corresponding to the results of the behavioural simulation.
In this chapter, an overview of the previous work in the area of reconfigurable computing has
been presented. Design methodology, and hardware and software tools used in this thesis have
also been presented. The next chapter presents the Altera Nios soft-core processor and supporting
tools in more detail.
11