I would like to get clarified some ambiguities in the GPIF 2 Designer Guide, regarding "special function" signals OE, WE, DLE, DACK and DRQ.
Their primary documentation, is in User Guide, on page 16, and there's also discussion on page 51, and also in AN87216 p13.
1. Combining info on all those pages, so far as I can tell, OE and WE do the same thing. If this is not true, then what do they do different?
2a. For signal DLE, UG-p16 says that DLE is used to latch the data into the input stage. If that's the case, and since it's on the same pin as WE, perhaps that's supposed to be the difference between WE and OE? GPIO 18 (WE/DLE) performs input data capture and output driver enable/disable, while GPIO_19 performs only driver disable?
2b. But that supposition is contradicted by UG-p51 and AN87216 p13 where we learn that DLE is not for capturing the input data per se, but rather just to extend the input data hold time. So which is it? Data capture, or extending input data hold time?
2c. And what is the relationship of WE and/or DLE to the IN_DATA action, which seems able to capture input data based on some other input signals altogether?
3. DRQ and DACK: Docs describe DRQ as DMA Request (from FX3 to external device), which seems fine. But then docs describe DACK (DMA Acknowledge) as "an input that is used to control the behavior of the DRQ signal". This explanation seems nonsensical to me.
The purpose of DACK is surely not to control DRQ per se. DRQ and DACK surely work together to operate an FX3-side state machine, and interact with the external-device-side's DMA facility, in order for the FX3 to fetch data from, or send data to, the external device.
3a. It's not clear whether the DRQ/DACK signals relate directly to FX3 internal DMA apparatus, or are a separate mechanism, perhaps intended to work with the DMA facility of the external device?
3b. It's not clear how DRQ/DACK do or don't relate to DMAn_Ready and ...Watermark signals.
3c. It's not clear whether DRQ/DACK operate separately from the GPIF state machine. If they require the GPIF state machine, then what is the significance of these signals being on specific pins, since presumably the GPIF state machine could implement these functions on any GPIOs?
There are some other ambiguities and gaps, but let's start with these please. -- Graham
The OE is used along with the Read enable. OE should be asserted a couple of clock cycles before the read enable signal so that the Data bus is ready with data when the fpga starts reading.
(refer timing diagrams in An65974 application note)
operationred1991_1569406, would you mind pointing to which specific timing diagram shows "OE should be asserted a couple of clock cycles before the read enable signal", because that conflicts with my understanding of OE, including from the AN in question.
For this AN, to clarify, I assume we're talking about the signal named SLOE#, and assertion means LO.
Please find the answers for the above questions.
1. OE and WE both provides direct control of output drivers on the data bus. But it is clear from UG page 51 that, WE assertion helps in setting up ingress path(in to the FX3 device) where as OE is the signal helps in setting up data bus direction for egress path(out of FX3). So WE is to be used when FX3 reads data from master, where as OE is to be used when FX3 writes data to the master device. But Cypress do not have a reference example currently which shows the improvement in design using OE/WE signals.
2a. DLE function latches the data for few nano-seconds more at the de-assertion of WE. Thus WE/DLE will be used with read operation, but the capture is always performed with the IN_DATA operation. DLE is increasing the data latch time at the time of de-assertion of WE and not doing data capture. Here DLE latches the data to input stage doesn't mean that it will capture the data.
2b. DLE is for extending the input hold time.
2c. IN_DATA is the GPIF operation that can capture the data on data bus. The state machine provided with example discussed in UG page 51 shows how to use the signals. WE/DLE is helping to hold the signal to get valid data on sampling.
3. The purpose of DRQ and DACK is as explained in the question. Documentation wanted to convey that both the signals can be used together. The options are provided with DR_DRQ operations.
3a. DACK/DRQ signals are intended to work with DMA facility of external device. The DR_DRQ operation give possible ways of using this either based on DMA_ready(status of active socket), from GPIF state machine or DACK signals.
3b. The DMA_Ready option to assert DRQ is available. But watermark flag based operations are not supported.
3c. The DR_DRQ assertion can be based on DMA_Ready flag or GPIF state machine, these has to on the specific pin mentioned in the user guide.