Comment by smj-edison
5 days ago
Not sure why I'm being downvoted, would those who downvoted me explain why? I try to be accurate so if I missed any important details I'd like to know :)
5 days ago
Not sure why I'm being downvoted, would those who downvoted me explain why? I try to be accurate so if I missed any important details I'd like to know :)
I dont know how a Ring Osc specifically could burn out LUTs. All switching contributes to the device temperature. If they get too hot then they will enter thermal protection mode.
We run such oscillators as dummy payloads for thermal tests while we are waiting for the real firmware to be written.
To play devil's advocate, I wonder how well they handle more annoying things.
When a CMOS switches, it essentially creates a very brief short circuit between VCC and GND. That's part of normal dynamic power consumption, it's expected and entirely accounted for.
But I don't know how these cloud FPGAs could enforce that you don't violate setup and hold times all over the place. When you screw up your crossings and accidentally have a little bit of metastability, that CMOS will switch back and forth a little bit, burn some power, and settle one way or the other.
Now if you intentionally go out of your way to keep one cell metastable as long as possible while the neighbors are cold, that's going to be one hell of a localized hotspot. I wouldn't be surprised if thermal protection can't kick in fast enough.
It's just kibitzing though, I'm not particularly inclined to try with my own hardware
Timing analysis is usually part of the synthesis and seems very comprehensive to me (I realise this statement may traumatise some firmware people). How hard it is to actively bypass this would be an interesting question.
Ah, thank you for the clarification! I must've mixed up a couple facts...