Added by foft over 8 years ago. Updated over 7 years ago.
0%
Description
Investigate why... On the v1 core this occurred when running the PLL at very high fVCO. However we already fixed that in v1, so not sure why.
Ijor recommended I try registering the input directly from SDRAM. I've done this and see if it helps.
He is also kindly helping me write some correct timequest rules, really appreciated:)
I've still had bad builds since registering the sdram input directly.
I tried to specify an externally switchable input clock for timequest as a proxy for ntsc/pal clocks. However it doesn't make it past derive_pll_clocks, so I guess I need to define multiple pll outputs. I'm not sure of the impact here in terms of clock grouping definitions etc.
Interesting when I build on AWS I get completely screwed up builds with the registered sdram input. Seemingly every time.
changed the Core to v8 and when chancing the video mode to NTSC the screen crashes
Nir
ndary wrote:
changed the Core to v8 and when chancing the video mode to NTSC the screen crashes
Nir
I remember that this was ok in mine board. Are you use the prototype 2 area to get the firmware?
Not seen this for months, think it was an issue around this time that has been fixed. Marking as normal priority for now.
On second thoughts... closing until we see it again.