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.

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

Kintex7 Frame Missmatch #2136

Open
fred-freeman opened this issue Mar 29, 2023 · 0 comments
Open

Kintex7 Frame Missmatch #2136

fred-freeman opened this issue Mar 29, 2023 · 0 comments

Comments

@fred-freeman
Copy link

I'm trying to make sure I understand the database format before working on this project and seem to be miss understanding something.

Specifically I am using Vivado 2017.2 and targeting the Kintex xc7k70tfbg484-1.

I generated a simple target project where I see the following in the bitstream
30004000 500b7a78. This to my knowledge means I have 0xb7a78 words of data or 7448 frames.
I compare this with part.json for the chip by summing the number of frame_count fields in there. There I come up with 7432 frames.
Lastly I compare this with tilegrid.json by totaling unique base_address/frames. There I come up with 6988 frames.

From what I read on the fuzzer for tilegrid.json I think I am missing something because I'm fairly sure tilegrid will contain all the frames but #444 does bring my some concern.

The primary reason I care about this is because the FDRI register does autoincrementing and moves to the next valid address. Unless I know how many frames are in each address and what every base address is how could I possibly know what address FDRI is currently looking at. It seems that bitstreams start at address 0 and load every value in one go so you need to know all of the addresses to have any chance of correctly placing bits where they belong.

Somewhat unrelated I noticed in the documentation https://f4pga.readthedocs.io/projects/prjxray/en/latest/architecture/bitstream_format.html
There is the statement

Between each frame, COMMAND will be rewritten with 0x1 which re-arms the next write

I neither see this behavior in my bitstream nor does Xilinx imply this in UG470 where they simply show all FDRI writes happening sequentially. Am I miss understanding something or is this simply wrong?

Thank you for any help and this project has done some awesome work :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant