DFB ALU output in the case of special instructions

[PiWy_2406846]

Could someone clarify the following:

acu(hold, hold) dmux(sa, sa) alu(clearsem, 010) mac(hold)

What will be the ALU output after executing this instruction? The simulator behaves as if it were alu(hold),

but I cannot find any binding specification in the documentation. It says only

"Set the semaphores low using mask, addr[2:0]".

[GeonaP_26 · Accepted solution]

DFB support semaphores to interact with the system software. It also provide an option to tie the semaphores to hardware signals such as DMA Request,interrupt source. clearing semaphore will not have any effect on ALU output, rather there will be change in signal mapped to semaphore 1.

Suppose semaphore 1 is mapped to output 1 source of DFB which in turn connect to DMA request for transfer. We can trigger the DMA transfer using semaphores set in firmware. alu(clearsem, 010) will help to clear the semaphore 1 and make it ready for next transfer. You can get a feel of the same with the Digital Filter Block (DFB) Code Example available along with PSoC Creator.

[PiWy_2406846]

So could you please state it explicitly in the documentation? I see no point in inferring all these simple facts from faint evidence

and simulator experiments. There are more problems like this:

1. Every jump should be of the form jmp(eob, CONDITION...), not jmp(CONDITION).

2. The shifter effectively works on the ALU input, not the output. You don't shift after an operation, you shift before the result consumption.

3. But not in the case of writes, where you can alter the memory result one cycle after its calculation and one cycle before the actual store.

4. If you write to memory, the content to be written is delayed by two cycles, but the address calculation is not delayed.

5. The condition flags calculation rules are, in fact, not specified. The TRM says:

     Dpeq – Datapath Equity – Asserted when the ALU hardware detects an output value of zero

The DFB assembler documentation says:

     Datapath Equity. Asserted when the ALU hardware detects an output value of zero. The ALU

     asserts dpeq only when the program uses ALU threshold detection operands (tsuba, tsubb,

     taddabsa, …)

So which one is correct? Does add assert dpeq? The simulator says it does, contradicting its own documentation. Another example. The TRM:

    Dpsign – A jump based on the MSB of the ALU output. If ALU output goes negative, assert.

The assembler's documentation:

    A jump based on the MSB of the ALU output. Asserted when the ALU output is negative.

So they are in agreement, but lead to silly conclusions on a higher level: the PSOC sets dpeq only in

the case of threshold detecting instructions, but dpsign always.

6. What happens to the condition flags if one uses only the non-arithmetic ALU instructions like the hold? Set/reset/retained/undefined?

     Datapath conditions require a two-cycle delay to meet a jump condition.

Fine, but what happens after that 2 cycles? Can I compute a flag 10 cycles in advance?

7.

     Datapath Threshold. Asserted when the ALU detects a sign change. The ALU asserts dpthresh only

     when the program uses ALU threshold detection operands (tsuba, tsubb, taddabsa, …).

A sign change relatively to what? The previous ALU output? The previous ALU output computed by a threshold detection operand, ignoring all the regular arithmetic operations in between? The sign of the first argument? The second, maybe?

8. Please specify the DFB pipeline exactly, why do we need to guess what result and when will be available? The DFB programming is sufficiently hard already.