Mity CPU Platforms » MityDSP-L138 (ARM9 Based Platforms)

Hi Rob,

Right now, we don't have an easy way to verify configuration cooked up.

The current MityDSP-L138F family of SOMs unfortunately do not connect the DONE pin to the OMAP or 1808. I think the INIT pin is available to monitor checksum faults, but you'd need to get into and modify the linux driver code or the u-Boot code to make use of it. The implementation uses 8 bit SelectMap. If you wanted to do a read-back via SelectMap, it might be possible, but it would mean leaving the data pins in the SelectMAP state (as opposed to user defined I/O) after configuration, and you'd no longer have an EMIF bus access capability to the part. I don't think you'd want to go that route. The JTAG pins are unfortunately only run to the external connector and not to the OMAP, so that option is out as well.

However, it looks like Xilinx has created a primitive called the ICAP_SPARTAN6 that appears to allow insertion of a SelectMAP style configuration interface into the fabric of the FPGA. You might be able to instantiate one of these and marry it to the normal EMIF bus logic to allow reading configuration registers/memory out of the device to validate configuration information. I don't know how many resources this might consume, but I expect not that many. There is also POST_CRC_INTERNAL primitive that may also be used (again, inside your logic fabric) to detect a configuration problem during runtime (see chapter 8 of the Xilinx Spartan 6 configuration Guide). I've not tried it.

Our current applications verify that the FPGA got programmed by checking for valid register entries (such as the DNA register in our base module, or some other "known" registers, etc.). It's admittedly not robust, but we've not had a problem with configuration via the SelectMAP interface with a valid FPGA prom file that we initially test with visual inspection on the DONE LED light on the board as well as INIT pin monitoring. I'm tempted to try out the ICAP_SPARTAN6, but it's unlikely I'll get to it anytime soon.

Hope this helps.

-Mike

Mike, I figured that readback may be an issue, but thanks for confirming it for me. Does the INIT pin provide proof (via CRC?) that the .bit file has been programmed correctly, or just that it's been taken out of programming mode?

The two primitives may provide what I'm looking for. The ICAP_SPARTAN6 primitive could be used to verify the .bit file CRC after programming, and the POST_CRC_INTERNAL is a good option for background CRC monitoring while the device is running.

I'll still need a method to inject a configuration bit flip to test that I'm using the POST_CRC_INTERNAL correctly. It appears that if I use ICAP to re-configure a portion of the FPGA, the CRC will pause during the configuration cycle and re-calculate afterwards. Any ideas on this would be appreciated...

Regards,
Rob Gillis

Rob,

The INIT_B pin (connected with external pullup to OMAP pin D2, AXR7/EPWMITZ⁰/GP1¹⁵) is an open drain output during/after config. If a CRC error is detected, it asserts low. So you could check the state of that pin after you run your program cycle to see if there was an error detected in the stream. That actually might be a fairly simple test... I may try it here using a bad configuration file to start.

Your ICAP test should be a great way to catch runtime config flips.

-Mike

Hi Mike,

FYI, I just had a chance to try a bad configuration file, and the INIT pin was indeed low after programming.

Thanks,
Rob