Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Does xc7a35t and xc7a50t share the same arch.timing.xml file? #221

Open
MidsummerNight opened this issue Dec 7, 2021 · 3 comments
Open

Does xc7a35t and xc7a50t share the same arch.timing.xml file? #221

MidsummerNight opened this issue Dec 7, 2021 · 3 comments

Comments

@MidsummerNight
Copy link

Arty boards only come in xc7a35t and xc7a100t versions, however xc7a50t keeps popping up all over SymbiFlow's projects. Why?

When installing symbiflow-examples one step is to wget -qO- https://storage.googleapis.com/symbiflow-arch-defs/artifacts/prod/foss-fpga-tools/symbiflow-arch-defs/continuous/install/459/20211116-000105/symbiflow-arch-defs-xc7a50t_test-ef6fff3c.tar.xz | tar -xJC $INSTALL_DIR/xc7/install. This would create a xc7a50t directory containing one single arch.timing.xml, three RR graphs (real, lookahead, place_delay) for xc7a50t, one single vpr_grip_map.csv, and one directory for xc7a35ttcpg236-1, xc7a35ttcsg324-1, xc7a50ttcsg324-1 each that holds the pinmap.csv for the parts. But xc7a50t shouldn't share the same architecture xml file with xc7a35t, should it?

Architecture Definitions' tutorials uses xc7a50t as the parameter when targeting the Arty board as well.

I'm really confused, why does SymbiFlow keeps using xc7a50t when it really seems to mean xc7a35t? @mithro
@mithro
Copy link
Contributor

mithro commented Dec 7, 2021

The xc7a35t doesn't really exist. All xc7a35t hardware is actually xc7a50t hardware internally.

@mithro
Copy link
Contributor

mithro commented Dec 7, 2021

To answer

Does xc7a35t and xc7a50t share the same arch.timing.xml file?

Yes.

@MidsummerNight
Copy link
Author

Okay, thanks for explaining. Where did you find this out though? Is the xc7a35t using the exact same silicon die as the xc7a50t, except with a portion of the latters' resources somehow disabled by Xilinx, and when generating bitstreams, both Vivado and Symbiflow simply configure those disabled resources as zero?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@mithro @MidsummerNight