This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
I was thinking about using the EMIFA on a C6748 to configure an Altera Cyclone III FPGA in their "fast passive parallel" (FPP) mode. It seems like this should be possible by using a few GPIO lines to control the Altera config pins. The EMIFA could then read the configuration data file from an ansychronous flash device onto the bus and use either the EMA_CLK or another GPIO to clock the data into the Altera.
w.r.t the EMA_CLK I know that the EMA_CLK is not truly relevant in asynchronous mode, but since the clock is still externally available on the device and seems synchronous to the EMA_OE in either mode, I wonder if it is possible.
Additionally by setting the configuration Data pins as I/O, the FPGA could be used as a device on the EMIFA after configuration.
Has anyone tried this or something similar?
Ryan Bishop said:w.r.t the EMA_CLK I know that the EMA_CLK is not truly relevant in asynchronous mode, but since the clock is still externally available on the device and seems synchronous to the EMA_OE in either mode, I wonder if it is possible.
Depending on what you are using the EMA_CLK for, this could be marginally okay, or it could be a big problem about to hit. You have to consider that the prop delay from EMA_CLK to EMA_OE can vary by a full clock cycle depending on the particular chip and the environmental conditions of temperature and voltage. If your design can handle this massive uncertainty, then you will be okay. But if you observe the timing once or twice and assume it will always be like that, you may have big trouble.
Based off the timing diagrams on FPP mode, it looks like the EMA_WE would be a better signal to use to clock in the data, rather than the EMA_CLK.
Jeff
I've been in projects doing similar things with Xilinx devices, both bit-wide and byte-wide configuration. In both cases an GPIO was used for the configuration clock since there is no data valid bit on these configuration interfaces, i.e, a valid data bit/byte is needed for every rising clock. This is tricky if you have a free-running clock..
Thanks everyone for your great responses. Based on what you all said, I think that attempting this maybe more trouble than its worth to save some config time. It seems that it would probably be safer to stick with a serial config scheme. If I do decide (or am forced) to attempt the parallel method, I'll be sure to post my results.
Thanks
Ryan