SelectMAP Configuration and Readback

Dear all,

I have a requirement to configure one Spartan 3 using another over SelectMAP8. I am struggling to get anything working at all, so I have attempted to construct a simple readback test. I am basing my test on the command sequence given in Table 17 in XAPP452. Unfortuantely, even this test doesn't work, and I find the application note a little ambiguous.

I will attempt to describe what I am doing. I have one FPGA (configured with my driving logic) attached to an unconfigured FPGA. Both are Spartan 3 1000s. I am running a continuous 20MHz configuration clock. On the falling edge of the configuration clock I set up the data ready for the unconfigured FPGA to clock the data in on the rising edge. On the first falling edge of interest I assert CS_B and RDWR_B low and I present the most significant byte of the first data word (0xFF) to the SelectMAP interface. The byte is bit-reversed as specified by the Spartan 3 datasheet. I then continue to present bytes with CS_B and RDWR_B asserted. Each word is presented most significant byte first, with the bits reversed within each byte. After sending 5 words (0xFFFFFFFF, 0xAA995566, 0x2800E002, 0x00000000, 0x00000000) I deassert CS_B on the next falling edge. On the following falling edge I assert CS_B whilst deasserting RDWR_B, this ensures that RDWR_B does not change whilst CS_B is asserted, causing an abort. I should now be able to read back the response to my command. Unfortunately, as soon as I deassert CS_B, the FPGA asserts BUSY, indicating an abort. I am clearly doing something wrong, I just have no idea what it is.

The application note does not make clear where in the process of Table

17 the actual read operation takes place. I have also tried waiting until all 9 words have been written before attempting to read back. Exactly the same problem occurs.

I am currently tearing my hair out over this, so any help or advice anyone can give me would be greatly appreciated.

Thanks in advance,

-- Peter

Reply to
Peter Mendham
Loading thread data ...

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.