Processor-based FPGA Design

Use the following links to browse through the frequently asked questions relevant to this area of soft design. For more in-depth, visual answers to commonly posed questions, use the links to the corresponding training videos, listed on the right.

When allocating processor address space, what is the difference between Device Memory and Application Memory?

Device Memory relates to blocks of memory that are mapped into the processor's memory architecture (i.e. its address space) based on the physical memory defined in the system. From an OpenBus System document, this is handled automatically (and dynamically). From an Embedded Software project, this can be achieved by manually importing directly from the FPGA project, or by automatically importing from the FPGA project upon compilation.

Application Memory relates to defined blocks of memory corresponding to the mapped blocks of device memory. Definable from the Embedded Software project only, these blocks enable you to handcraft exactly how the device memory is used by the embedded code. By default, an application memory block will be the same definition as its 'parent' device memory block. You might decide to define the application memory block to be smaller in size or maybe define multiple sub-blocks within the available application memory block.

How can I export interrupt pins from my OpenBus System?

If an interrupt line is currently assigned to an OpenBus peripheral, it can be made available as an output pin on the top-level design schematic. This enables you, for example, to export an interrupt for debugging purposes, or for connection to a processor that resides on the schematic sheet. From the Interrupts tab of the OpenBus Signal Manager dialog (Tools » OpenBus Signal Manager), simply set the entry in the associated field for the interrupt to Exported (as output pin). The following image illustrates this for a series of processor interrupt pins assigned for use by internal OpenBus peripheral devices.

Exporting processor interrupt lines for use outside of the OpenBus System.

When defining processor interrupt pin INT_I0 in an OpenBus System, there is an additional entry that can be chosen – Internal – what is this?

This allows for the situation where the INT_I0 line of the processor is actually the logical OR of the interrupt generated by a Programmable Interval Timer, internal to the processor, and the interrupt line zero. Provided the interrupt is not assigned to an OpenBus peripheral, the Internal entry will be available.

When this option is used, the interrupt pin will not be exported for use outside the OpenBus System. Note however, that precedence is given to use of the interrupt line by an OpenBus peripheral. If you have set the Internal option for the pin, then subsequently assign INT_I0 for a peripheral's interrupt line, the setting will automatically be changed to Exported (as output pin).

I have enabled profiling for the processor in my design, so why don't I get any runtime results?

Since code instrumentation is performed by the C Compiler, any Assembly code functions in your program will not appear in the profiling data. Also, as profiling data is gathered during program execution, the input of the program directly influences the results. For example, if a function within the program is not activated while the program is being profiled, then no profile data for that function will be generated.

In addition, runtime profiling information is only generated when a program finishes execution – either by reaching the end of main() or by specifically calling the exit() function. Simply stopping the debug session while the program is still running will yield no profiling results.