Ordering (NOC, CMD_BUF, VC)

NoC requests/responses are usually asynchronous, but they can have an implicit ordering, or you could enforce an explicit ordering. In this section, we will go over command buffers (CMD_BUF), virtual channels (VC), and allocation of virtual channels.

There are two NoCs (NoC-0 and NoC-1) that are completely phyiscally replicated and separated. The only communication between these NoCs is through software or L1 memory. For each NoC, we have 4 command buffers: RD_CMD_BUF, WR_CMD_BUF, WR_REG_CMD_BUF, AT_CMD_BUF. We usually use the WR_CMD_BUF for all writes, except for the atomic ones where we use AT_CMD_BUF, e.g. noc_semaphore_inc uses AT_CMD_BUF.

For each NoC, we have 6 VC (numbered 0-5). Each VC is usually used for a different purpose. For example, all unicast writes go on NOC_UNICAST_WRITE_VC, which is VC 1, and all multicast writes go on NOC_MULTICAST_WRITE_VC, which is VC 4.

We can allocate VC either statically or dynamically. We can allocate VC statically using NOC_CMD_STATIC_VC, which is usually the case for noc writes. For noc reads, the read requests can use a statically allocated VC, as for read responses, we always use dynamically allocated VC. So there’s really no way to control ordering for data reads.

As for ordering of the NoC writes:

• If writes are on different NoCs, there is no ordering guarantees.

• If writes are on the same NoC but different VCs, there’s also no ordering guarantees. You might as well use different CMD_BUFs to avoid serialization.

• If writes are on the same NoC and same VC, they will be ordered based on program order, regardless whether you use the same CMD_BUF or different ones.