Now things get really interesting! I have a datapath-based component (you helped me to develop it in the Parallel port thread). Its function is as follows: idle a trigger arrives (51kHz if that matters). Then issue 9 consecutive DMA transfers on the same channel to an 8-bit GPIO port, generating externally visible strobes after each transfer. and sampling the status of an external 1-bit input (through the carry chain), collects the last 8 results and store the final 8 bits into an output FIFO. The datapath FSM manages all that. This, together with a Count7-based fixed duty cycle two channel (with deadbanding) 500kHz PWM generator fits within a single UDB.

The question is about triggering. The trigger signal pulse will have unknown duration (now 50% @ f=1/51kHz, which is long in terms of the 64MHz datapath clock), but synchronized, so a resettable edge detector is required. It can be easily written in Verilog, but it would eat up one PLD macrocell. So I've invented the following: since one FIFO is unused, it could be configured to internal dynamic mode (d1_load=0). Then its write strobe (f1_load) is connected to the trigger signal, the write data source could be anything except of CPU/DMA, according to the manual (now: A1) and f1_bus_stat indicates whether the FIFO is not empty. Then the system starts with f1_bus_stat high (empty FIFO), the trigger causes it to load something into the FIFO (the fetched value has no meaning), f1_bus_stat gets low and datapath starts its job. In the final state D1 is loaded from the FIFO, which makes it empty again. The result is a resettable edge detector based on the FIFO; moreover, it can buffer up to 4 trigger signals should they arrive before the datapath's job completion (cannot happen here, but still a potentially useful feature).

The scope confirms it works like a charm, but since it abuses the FIFO so much beyond its designed purpose, there is a question whether the whole approach is legal in terms of the specification.

It is not illegal ,but I have not FIFO used in this manner as its purpose is different.It is a good idea if you do not want to use PLDs but some may feel it is a convoluted way of achieving a edge detector.

But I'm wondering how you removed the byte from FIFO in the last state ,In the dynamic FIFO control mode, d0_load and d1_load are not available for their normal use in loading the D0/D1 registers from F0/F1.

The byte is removed in the last stage by fetching it to A0 (and then xoring A0 with A0 in the next stage, as the value is unpredictable. See the attached DCT dump. In the meantime I changed the value of 9 iterations to 16, because it allows me to do more in the next stage. Another interesting trick is to use A0_A0 in the comparator section. Then I can use .cl1() directly as one of my strobes (STCP, it is for NPIC6C596) and force it low where necessary (because A0 < A0 always results in 0), without using any PLD resources. The remaining strobe (SHCP) is directly encoded in the highest bit of cs_addr, sparing another macrocell. Very compact, but undebuggable without a scope. :)

I was confused initially as you mentioned "In the final state D1 is loaded from the FIFO" , Its clear now .as I mentioned this is not illegal and its good that you are making use of the unused functionality in Datapaths .This also allows better routing and placement .

Note that the PLD structure has 12 inputs which feed across 8 product terms (PT) in the AND array and output of the PTs are inputs into the OR array giving out 4 outputs . So for example if all inputs are used up to generate single output ,reset of the resources cannot be used .

// BUG: NRQ is asserted after the entire TRANSACTION, not a single burst!!!

// Pretend it worked correctly, to be reworked later. Cypress should really make it configurable.

- This is not a bug, but a "feature" ( PSoC4 does not have it). Since the amount of data to transfer is only 9 samples per DMA cycle, you can chain 9 TD, so that each TD will add nrq pulse after moving a byte. Demo project attached (not tested, but should work).

- This is not a bug, but a "feature". Yes, sometimes it is a feature, but sometimes you need a transfer confirmation after a single burst, not after the entire TD. My use case is "Transfer 9 bytes in a single burst per trigger from consecutive locations of an array of 9*1024 bytes. Let datapath know that all the 9 bytes have been transferred and move the DMA 'cursor' to the next bundle of 9 bytes. Wait for the trigger, repeat. When finished, issue an interrupt". So, I need both NRQ and BRQ (let's call it so, a notification after each burst completion), even configurable behavior of NRQ wouldn't suffice. The 9 TD approach is very interesting, but it doesn't handle the "autoincrement to 1024, then stop" phase safely and this, I dare to say, quite typical use case has no proper hardware support and requires Byzantine constructions like feeding a FIFO from one DMA channel (to handle the "1024" case) and consuming the bytes from the other end by a second DMA channel ("the 9 bytes" case).

If there was a single BRQ flag from the same channel...

BTW, how do you draw these beautiful waveforms? By hand or is there a dedicated utility in Creator?

Piotr, Typically, individual "BRQ" (single element transfer completed) is not required, because one can count trq requests (hoping that each trq will end in DMA completion), instead of BRQ. There are probably several other solutions using chained DMA, indexed DMA, etc. - see Cypress AN Advanced DMA Topics... http://www.cypress.com/documentation/application-notes/an84810-psoc-3-and-psoc-5lp-advanced-dma-topics Take a look on this example, where Datapath directly calculates next array index (not consecutive one) and uses DMA1 to pass this index to working DMA2 (which actually performs data transfer). http://www.cypress.com/blog/psoc-sensei-blog/direct-digital-synthesis-indexed-dma Unfortunately, the above example was written for older PSoC5, and doesn't work on PSoC5LP. My attempt to update DMA code ended in conclusion that there is underlying issue with Datapath operation, which also needs updating. P.S. waveforms are hand-drawn using line tools, pen width 1.5, start/end stroke squared, then grouped together. Dbl-click the line tool to make multiple lines.