wire statement = "WIRE", new identifier, transmitter, receiver,
{wire attribute};
transmitter = link spec;
receiver = link spec;
link spec = processor identifier, "[", link type, ":", constant, "]";
link type = identifier;
wire attribute = "NOBOOT";
The WIRE statement declares an explicit connection that you have made between link connectors of two processors. This usually involves an explicit cable, although on certain systems the actual connection may be made by an underlying carrier board, a backplane, or some other mechanism. Unless, exceptionally, you actually do want to provide a cable between the relevant external connectors, the WIRE statement should not be used to connect processors that are attached, either explicitly or implicitly: see ATTACH attribute.
Driver software (and sometimes firmware) needs to be added to processors before links can be used. A reference to a link in a WIRE statement is taken as a request for the configurer to ensure that the relevant driver module is loaded. If you do not reference a link in a WIRE statement (or CONNECT statement), you are unlikely to be able to use that link at all. Drivers are also loaded automatically for connections between attached processors.
Every processor in the network can control one or more types of link. Each link type has a unique name and provides a number of links, identified by integers from 0 upwards. The two ends of the wire are each defined by using a link spec construct made up from a processor identifier, the type of the link and a constant selector.
The position of a link spec, either transmitter or receiver, is used to initialize links implemented on hardware that needs to be set into a particular initial state: (comports and SDBs, for example). With such devices, Diamond may need to create new firmware should the reset direction implied by the link spec not match that assumed by the default firmware: you would need to declare any attached processor explicitly and have appropriate Diamond licences. Other than this, because each WIRE statement usually supports communication in both directions, the two link specs in a WIRE statement may often be interchanged without affecting the statement's meaning.
wire yellow_wire proc_one[somelink:2] proc_two[somelink:3]
The PROCESSOR and WIRE statements must correspond to the real hardware network on which the application is to be run. If this is not so, the application will probably fail to load and will certainly not run properly.
The two ends of the wire must be of compatible types. Refer to the installation section for a list of the available link types.
When you give a link spec, the configurer checks to see if the processor has the link you mention and then uses it. If there is no such link, the configurer checks any processor to which the given processor is attached, and repeats the procedure up the hierarchy until the link is found. You will receive an error message if the end of the chain of attachments is reached before the link is discovered. The configurer may decide to create new bitstreams if a path through an FPGA is needed and one is not available in the standard bitstream. Note that no new paths are created in implicit processors.
The following diagram shows how connectors can be accessed from three processors X, Y, and Z, where X has links of type DEV_C, Y has links of type DEV_B, and Z has links of type DEV_A:
As there can be several ways to reference the same link (for example in the picture above, Y[DEV_B:0] and Z[DEV_B:0]) you should be careful that you do not try to connect a link to itself, as in the following WIRE statement:
WIRE W9 Y[DEV_B:0] Z[DEV_B:0]
This would result in the configurer giving the error message 'link Z[DEV_B:0] has already been used'.
Connections between tasks placed on processors that are attached do not require WIRE statements explicitly joining the processors; such connections are created automatically and invisibly for you.
The following diagram gives the SMT374 as an example. It has two DSPs connected to an FPGA which is providing six comport connectors (the other devices it provides have been omitted for clarity). The actual connections between the DSPs and the FPGA are made using the C6000 EMIF, but this detail can be ignored.
The default firmware provides all the connections shown. DSPA has access to three connectors (CP:3, CP:4, and CP:5) and its other three comports are connected to DSPB. Similarly, DSPB has access to comport connectors CP:0, CP:1, and CP:2, and has three comports connected to DSPA.
A link specification such as DSPA[CP:0] would give DSPA access to the comport connector CP:0 which is usually associated with DSPB. Similarly, FPGA[CP:0] would give components you place in the FPGA access to that comport connector and the internal connection in the FPGA would be replaced. In either case, DSPB would then no longer be able to use CP:0.
This behaviour greatly simplifies using multi-processor modules, as internal wires are never mentioned.
It is, however, a change from earlier implementations of Diamond.
Let us assume we have TASK_A placed on DSPA and TASK_B placed on DSPB. The following configuration file arranges for a channel to connect these tasks. Note that no WIRE statement is needed as the connections can be managed directly by the configurer:
PROCESSOR DSPA SMT374_6713
PROCESSOR DSPB SMT374_6713
TASK TASK_A ...
TASK TASK_B ...
CONNECT ? TASK_A[0] TASK_B[0]
CONNECT ? TASK_B[0] TASK_A[0]
PLACE TASK_A DSPA
PLACE TASK_B DSPB
In order to allow communication between the two processors DSPA and DSPB using older versions of Diamond, you would have had to make declarations similar to the following in your configuration file:
! Old version of configuration file
PROCESSOR DSPA SMT374_300
PROCESSOR DSPB SMT374_300
WIRE W1 DSPA[CP:0] DSPB[CP:3]
WIRE W2 DSPA[CP:1] DSPB[CP:4]
WIRE W3 DSPA[CP:2] DSPB[CP:5]
To get the identical effect with the new version of Diamond, you would simply omit the WIRE statements; appropriate (but possibly different) wires will be created for you automatically by the configurer.
If you were to leave the WIRE statements, the configurer would attempt to build something like the following, where the connections are no longer internal to the FPGA but are assumed to involve actual physical wires joining the module's connectors:
This would fail for two reasons:
| 1. | There is now no comport that can be used to load the processors; and |
| 2. | The new layout requires a new bitstream, but this is not allowed as the FPGA has not been explicitly declared as a processor. |
If you have older configurations you will need to remove WIRE statements that are now unnecessary and whose meanings have changed.
One advantage of the new definition is that it now makes reconfiguring multiprocessor modules almost trivial. For example, if you have an SMT374 and you need DSPB to have access to most of the comport connectors, you can do it easily as in this example (details of other processors have been omitted and channels between the DSPs have been assumed):
PROCESSOR FPGA1 SMT374_6713_FPGA
PROCESSOR DSPA SMT374_6713 ATTACH=FPGA1
PROCESSOR DSPB SMT374_6713 ATTACH=FPGA1
WIRE W1 DSPB[CP:0] ... ! connection to another processor
WIRE W2 DSPB[CP:1] ... ! connection to another processor
WIRE W3 DSPB[CP:2] ... ! connection to another processor
WIRE W4 ... DSPA[CP:3] ! connection to another processor
WIRE W5 ... DSPB[CP:4] ! connection to another processor
WIRE W6 ... DSPB[CP:5] ! connection to another processor
The result would be a new bitstream providing internal connections of this form:
Note that connections between DSPA and DSPB (purple) are added automatically if needed.