I'm not familiar with automotive use. I would think they would have been a much bigger company if there had been much automotive use of their parts. Just one design win is 500,000 a year in that market.
I sort of lump space, avionic and defense into the same category since they have similar requirements and are all much smaller than commercial markets. Perhaps we can call this generically "high rel" and also include the small commercial market segment. High markup, low volume...
That is the crux of the problem. While some brands of FPGAs do a reasonable job of detecting power on and resetting the entire device, it sounds like the Actel doesn't bother since... well, since it doesn't need to as long as it can rely on the user to reset it.
I'm not clear on this. It sounds like you are using the timer in
*place* of the lock signal from the PLL. My point was to condition the lock signal from the PLL. But since you say below that you don't know the state of the PLL lock signal at power up I suppose this won't work. It would be a simple matter to test it though. Or you can contact the factory. Since there is no configuration process the logic of the PLL should be ready and working on power up I would expect.The fact that you are checking the upper bits prevents any pruning of the counter. I think your approach is to help assure that the counter has been reset before it will count down. I would not think this was workable. Either the counter is reset properly or the circuit can malfunction by lockup, possibly with global_rst = '0'. Also be aware that you are really only using 5 check bits since the sixth is used to flag end of timeout.
If this is a high rel application, I would not want to rely on a five bit checksum to control a reset. You say "guarantee" and "random", but I see the possibility that the counter starts up in the done state with reset never having been asserted, 1 in 64 chance. If you check all the bits in the counter for the done state it is still a 1 in 4096 chance of malfunctioning without ever producing a reset out.
If you can't rely on the PLL lock signal to be asserted at power up, I don't think you can rely on *any* logic in the FPGA to compensate for this. Why not investigate and find out if the PLL signal will work as a power on reset? Contact the factory and/or test it yourself on the bench. Bring the LOCK signal out to a pin and scope it while powering up the unit.
I think you need a reset signal for the device, period. Even if you manage to supply a reset to all the FFs in your logic, is there nothing else on the chip that requires a reset like the PLL itself? What other circuits are on the device other than the user configurable logic? Does the data sheet talk about a requirement for the reset signal?
The PLL issue and the idea of using the I/O pin to generate a reset are both issues I would contact the factory about. If I were in your shoes, I would push hard to have the module disqualified since the FPGA can not be assured to have been reset. That is the part that is insanity!