I am using 10M04 FPGA. for some of the versions of my RTL project, if I download SOF file, it works great. if I download POF, it works partially right. this happends on all 3 boards that I have.
any one know what is the potential issue this is?
It's not really possible to answer without knowing what the design is supposed to do and what happens differently between the two files. Also, where is the .pof being stored? I presume in the CFM. Can you provide more details?
Thank you sstrell and JohnT.
Yes, after downloading the POF, I did power down and power up and reset.
The design is a UART receiver and CRC checker. If CRC passed, we update certain registers to the value received. if CRC failed, then we don't update the registers.
we have 3 version of the RTL,
- for first version, SOF and POF works great.
- for 2nd version, we changed some other logic not related the UART function. and for this compile, SOF works, and POF not working.
- based on 2nd version. I added signal tap analyzer in the design trying to debug where the problem is. I did not change any of the RTL. for this version, SOF and POF both works well.
So, this looks very strange to me, meaning, the 2nd version, the netlist is slightly different than the 1st or 3rd version, and this causes the POF not working.
Now I change the config device settings from "instant on" to "slow POR delay", and it fix the issue.
Not sure if this really fix the issue, or there is netlist change due to this different setting which avoid the cornor case having the issue.
May I know when you mention POF is not working then what is the issue observed? Is it the functionality is not working correctly?
When you change the config setting, I do not think that there is changes in the netlist and it is only changing so that the Max 10 device will have a slower time to enter usermode.
It is functionally not working correctly.
Now I have the following experiments that reveals the issue(FPGA start to config from CFM to Logic cells before Logic cells power up stably).
- after power up, I draw NCONFIG pin to low to force a re-configuration, and this fix the issue.
- I connect a 10UF capacitor between GND and NCONFIG pin, and this also fix the issue.
- As mentioned before, I change config settings from" instant ON" to "slow POR delay", and it fix the issue.
So, based on the 3 experiments above, my conclusion is that, right after Power up, FPGA start to config from CFM to Logic cells before Logic cells powered up stably.
Is there any other suggestions beyond my solution above?
May I know if you have tried to performed system reset on your design to see if the functionality recover? I would like to understand if the configuration is causing the issue or the design is not reset correctly after power on due to external component driving the FPGA.
The reason is that I do not think that the FPGA is configured incorrectly which usually will cause configuration failure rather then entering usermode if the power is still not stable.
May I know what type of functionality failure do you observed? Just would like to understand what is actually happening when resetting the system design is not helping. This is so that we are able to fixed the issue.
Here are the 2 major modules related.
there is a UART TxRx module "uart_comm", which translate the RS-232 level signal into a byte and valid data.
Then we use the byte and valid data to input it into a frame checker and CRC check checker module "command_ctrl".
when CRC pass, we update a certain register( "read_offset " register in the code) value. otherwise, the value did not get updated.
The issue we observe is that, the register value that we want to update, failed to update.
Please see file attached.
May I know which resistor value that you would like to update failed? Is it stuck or what is happenning? I just would like to understand if this is related to your state machine design where it is stuck or not.
what I can observe is that register "read_offset " is not updating.
I am not able to debug more. Since If I simply add a signal tap logic analyzer to debug(not changing any RTL), this problem will disappear. I think due to the POF file got changed with the additional signal tap logic function.
So it is really hard to find out the reason. any netlist change will affect the POF file, and then will make this issue disappear.
my question is, After configuration is done, does the FPGA read back the configuration in the Logic element and compare with the original data in the flash to make sure the configuration is effective?
Per my understanding, the POF in the CFM is the data source, and the LEs are the data destination.
I think the data out put from the CFM is correct, as it passes CRC check. But how do we make sure the data destination recieved it correctly? what if the destination electronic is in a meta-stability state, and the writing of the data to the destination is not successful. Is this possible?
Once the configuration is complete and CONF_DONE is high then the LE are ready to be function. That is why if you performed reset on your design then you should be able to recover from the issue.