2 Replies Latest reply on Sep 13, 2017 2:39 PM by piotr.wyderski_2406846

    DFB ALU output in the case of special instructions

    piotr.wyderski_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]".
        • 1. Re: DFB ALU output in the case of special instructions
          geon

          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.

          1 of 1 people found this helpful
          • 2. Re: DFB ALU output in the case of special instructions
            piotr.wyderski_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.