Skip to content
This repository has been archived by the owner on Mar 9, 2023. It is now read-only.

Verify that only bank 14 I/O pins are functional on xc7k325tffg676-1 (QMTech) #9

Closed
unbtorsten opened this issue Feb 2, 2022 · 4 comments
Assignees
Labels
question Further information is requested

Comments

@unbtorsten
Copy link
Contributor

unbtorsten commented Feb 2, 2022

Based on observations in #7 and #8, we should be able to find unusable I/O on the QMTech board. @hansfbaier do you have schematics for the board and how it connects the I/O to the FPGA banks? A single example of an I/O that is not on bank 14 would prove the point. Also, is your proof-of-concept example using exclusively bank 14?

@unbtorsten unbtorsten added the question Further information is requested label Feb 2, 2022
@unbtorsten unbtorsten changed the title Validate that only bank 14 I/O pins are functional on xc7k325tffg676-1 (QMTech) Verify that only bank 14 I/O pins are functional on xc7k325tffg676-1 (QMTech) Feb 2, 2022
@hansfbaier
Copy link
Collaborator

@unbtorsten unbtorsten self-assigned this Feb 3, 2022
@unbtorsten
Copy link
Contributor Author

Thank you for the link. U11D on page 2 confirms that system clock and LEDs are indeed connected to bank 14:
image
The QMTech example is currently using pins F22 and J26, cf. https://github.com/kintex-chatter/xc7k325t-blinky-nextpnr/blob/main/blinky-qmtech.xdc)

@unbtorsten
Copy link
Contributor Author

I modified the blinky design to be

module blinky (
    input aux,
    output led
    );

    assign led = aux;
endmodule

Interestingly, I seem to be able to place various I/O from e.g. banks 13 (pin R22), bank 15 (pin C16), or bank 16 (pin A9) with constraints such as these:

set_property LOC R22 [get_ports aux]
set_property IOSTANDARD LVCMOS33 [get_ports {aux}]

However, these pins are PCB-internal.

On the other hand, if I connect switch SW2 (connected to bank 33)

set_property LOC AF9 [get_ports aux]
set_property IOSTANDARD LVCMOS33 [get_ports {aux}]

I get the previously known pattern of an assertion failure:

terminate called after throwing an instance of 'nextpnr_xilinx::assertion_failure'
  what():  Assertion failure: s != -1 (nextpnr-xilinx/xilinx/arch.h:1602)
./makeit.sh: line 26: 273163 Aborted                 nextpnr-xilinx --chipdb ${CHIPDB_DIR}/${PART}.bin --xdc ${PROJECT_NAME}-${BOARD}.xdc --json ${PROJECT_NAME}.json --write ${PROJECT_NAME}_routed.json --fasm ${PROJECT_NAME}.fasm --verbose --debug

This supports @jrrk2's hypothesis and the discussion in #8.

@unbtorsten
Copy link
Contributor Author

Questions answered, continue further discussion in #8.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants