Some processing modules are made up from an FPGA and one or more processors attached to it. The links between such processors are often similar to the links between completely separate processors but may need to be managed in very different ways. For example, C6000 processors usually communicate with an FPGA using the external memory interface, EMIF. Rather than invent peculiar types of link to support these systems, Diamond handles the communications between attached processors itself. You still need to describe the physical connections (wires) between processors that are not attached.
You would usually declare all the processors involved and make the attachments explicitly.
PROCESSOR A MODULE_FPGA
PROCESSOR B MODULE ATTACH=A
PROCESSOR C MODULE ATTACH=A
Processor B and processor C are attached to processor A which must have a type that defines it can accept two (or more) attached processors of type MODULE.Sundance systems use the convention that the processor type name used to declare the FPGA is derived from the type name used to declare each attached DSP by adding the suffix '_FPGA'. Such definitions are usually provided as part of the standard set of processor types in your edition of Diamond.
If a processor needs to be attached to another processor but you do not make that attachment explicit, Diamond attempts to make the attachment for you. The configurer can silently create 'implicit processors' for you. These are just like the processors you declare but they are completely invisible. When the configurer makes an attachment for you it searches through any implicit processors and uses the most recently-declared one it finds of the appropriate type that has not had its full quota of processors attached. If no such processor can be found, the configurer silently declares a new implicit one for you. The example above could be rewritten in the following way:
PROCESSOR B MY_DSP ! attachment to a new implicit processor
PROCESSOR C MY_DSP ! attachment to the previous implicit processor
The configurer's verbose option shows you when implied processors are created and how automatic attachments have been made.
There can be a hardware significance on certain modules to the order in which processors are attached to an FPGA. For example, the first attached processor may be the only one that is capable of loading its parent FPGA. The Sundance multi-DSP modules have this property. As an example on the SMT362, only DSPA has the ability to program the FPGA and so must be loaded before any of the other processors on that module. Diamond can do this only if there is a path of wires from the root processor that reaches DSPA without needing to go through any of the other processors on that module. The order in which you declare attached processors in the configuration file corresponds to the manufacturer-defined ordering of processors on the module.
When you have a structure of attached processors, the configurer automatically invents implicit wires for you to connect the component processors as necessary; you never need to declare wires connecting attached processors.
There is a difference between the way explicit (user-declared) processors and implicit (configurer-declared) processors are treated. The definitions of FPGA processor types include a description of the standard link connections that correspond to the default bitstreams; other connections can be made, but new bitstreams will be needed to achieve them. The configurer creates these new bitstreams if you have declared the FPGA explicitly, but it never attempts to change the bitstream for an implicit processor. Implicit processors are therefore restricted to using standard connections. This can sometimes mean that there may not be enough wires to carry all the channels that your application requests, and the configurer will report that it is unable to route the channel. If this happens, you can either declare the FPGA explicitly and let the configurer invent the extra connections, or you will have to simplify the channel structure of your application. This is discussed further under the WIRE statement.
Note that you need an appropriate Diamond FPGA licence to be able to create new bitstreams.