Unless you indicate otherwise, Diamond makes all external channels virtual, that is, they automatically carry messages between distant processors via intermediate network nodes. Since multiple virtual channels can share the same wire, any number of virtual channels may connect tasks on different processors.
Transmission over virtual channels is guaranteed to be deadlock free: the routing that Diamond inserts cannot cause your program to lock up with one message waiting for the transmission of a second which itself is waiting for the first. That said, Diamond cannot protect you against deadlocks that are the consequence of errors in your coding of the application.
Virtual channels are slower than the underlying physical mechanism. Diamond therefore also provides physical channels, which map directly to the hardware. Their advantage is speed: their disadvantage is that the number of physical links, and the paths they can take, are both restricted by the available hardware.
When a wire is used for virtual channels, both transfer directions are used, even if there is only one channel using it. This means that it is not possible to use a wire for both virtual and physical channels.
When the throughput of particular channels is critical to application performance, you may try making the connection direct and substituting physical channels for virtual ones. Experimenting is easy because the same message-passing functions are used in both cases: no code changes are required. The Diamond configurer automatically assigns virtual channels to physical links. This assignment first selects possible links that provide a deadlock-free routing, and then selects one based on the speed of the link and its current loading with virtual channels. Within these constrains, usage of links for virtual channels will be statically balanced across the available connections.