-
Notifications
You must be signed in to change notification settings - Fork 9
Genesys2 failure diagnostics #6
Comments
This design appears to be suitable:
|
and we can try a fairly free choice of constraints such as:
resulting in the following allocation: Info: Constraining 'clkio' to site 'IOB_X0Y281' ergo, we have constrained both pins to IOB_X0 |
I have tried the new blinky.v in Vivado on the Genesys2, and it is a happy bunny. |
I have tried the nextpnr generated bitstream on the Genesys2, and it doesn't work, not a happy bunny. |
The next stage is to invoke the magic converter to read the nextpnr bitstream back into Vivado, and run a DRC. |
Implementation saved in branch ring-oscillator |
ring-oscillator does not work yet. Clocking from a limited number of external pins (none of them official clock pins) is possible. 8-bit counter with manual clocking is operational. |
If nextpnr is run with the ffg900 variant, and the QMTECH constraints, it works. This might be because the QMTECH constraints just happen to be confined to the IOB_X0 block:
Info: Constraining 'clk' to site 'IOB_X0Y126'
Info: Constraining 'led' to site 'IOB_X0Y114'
whereas the Genesys2 constraints are not:
Info: Constraining 'clk' to site 'IOB_X1Y24'
Info: Constraining 'led' to site 'IOB_X0Y127'
Unfortunately I haven't been able to find a combination of clocks and LEDs that are on the IOB_X0 block only. However there can be no objection to the LED mapping which is almost the same as QMTECH.
The suggestion would be to try an internal ring oscillator as the next step to flush out any other issues.
The text was updated successfully, but these errors were encountered: