Some types of link, in particular comports and SDBs, need to be set into a particular direction before they can be used for the first time. This direction is established for comports by firmware when the hardware is reset; SDBs are set into their initial direction by software in the Diamond device driver.
Previous versions of Diamond used a combination for factors to determine whether a comport should be initialized as a transmitter or as a receiver, including the order of specifiers in WIRE and CONNECT statements and pre-defined properties of comports (CP:0, CP:1, and CP:2 usually initialize as transmitters; CP:3, CP:4, CP:5 usually initialize as receivers). This has never been completely satisfactory and was done only to attempt to maintain backwards compatibility with existing applications developed before FPGA support existed.
Diamond has now simplified the rules governing the reset direction of links: the reset direction of a link is determined by the order of link specifiers in the WIRE statement or the first CONNECT statement that mentions it.
This is a change from previous behaviour where the order of comport link specifiers was overridden by consideration of the usual reset state of the links involved. You may have to reverse the order of comport link specifiers in WIRE statements in existing applications.
One consequence of this is that when you create WIRE statements, you should ensure that you connect a comport that usually resets as a transmitter to a comport that usually resets as a receiver. Making the connection the other way round will result in a new bitstreams being created for the relevant processors, and will fail if you have not declared the attached FPGA explicitly or if you do not have the appropriate Diamond licence.
For example, the following WIRE statement will not require custom firmware as CP:1 normally resets as a transmitter and CP:4 normally resets as a receiver:
WIRE W1 root[CP:1] node[CP:4]
On the other hand, the following statement will require new bitstreams to be built as it reverses the reset direction of both comports:
WIRE W2 root[CP:4] node[CP:1]
You will also get an error message similar to the following if you have not explicitly attached either root or node to a declared FPGA:
ERROR: implicit processor SMT361_FPGA#1 requires a new bitstream.
Perhaps a WIRE statement changes the natural reset direction of a link?
Although not really an exception to this rule, any comport used to load a processor for which Diamond will create a new bitstream will always silently be reset as a receiver. This is because the processor will have been reading from the boot link just before its FPGA is loaded with a new bitstream, leaving the boot link as a receiver and the corresponding link on the booting processor as a transmitter.