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
Support IOB tiles with only one site (IOB_SING) #488
Conversation
Signed-off-by: John McMaster <johndmcmaster@gmail.com>
Signed-off-by: John McMaster <johndmcmaster@gmail.com>
Signed-off-by: John McMaster <johndmcmaster@gmail.com>
Signed-off-by: John McMaster <johndmcmaster@gmail.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What does the segbits file look like for a negative base word offset?
Do the negative base word offset round trip (bits -> fasm -> bit -> fasm)?
No, there is not a negative segbits file. Only the upper half of the file is used |
Not sure I understand what is being suggested. Are we saying that LIOB33_SING_X0Y100 and LIOB33_SING_X0Y149 will use different database entries? LIOB33_SING_X0Y100 will use Y1 entries and LIOB33_SING_X0Y149 will use Y0 entries? |
Signed-off-by: John McMaster <johndmcmaster@gmail.com>
the latter |
@@ -11,24 +11,19 @@ | |||
|
|||
|
|||
def gen_iobs(): | |||
''' | |||
IOB33S: main IOB of a diff pair | |||
IOB33M: secondary IOB of a diff pair |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IOB33S
was actually the main? I would have guess the S
and M
stood for Master
, Slave
or Main
, Secondary
.
If I understand correctly, what you are saying is that;
How do we deal with this in
Isn't the IOB just three cases like below?
Is it really hard to make the tools able to handle the " |
Tim: is that question for me or @litghost ? Maybe to answer: the problem is that the tile_type for "IOB33S_TOP" and "IOB33S_BOT" is the same |
Exactly, IOB33S_TOP and IOB33S_BOT are both just IOB33_SING. To make matters worse, the existing convention for tile type definition of IOB33_SING doesn't even defined a site Y0 and site Y1, only a site Y0. The current way tile types are generated has no ability to detect whether the _SING tile is a top or bottom and generate a site Y0 only for the top and site Y1 only for the bottom (or vise-versa). The ideal case would've been for these tiles to shares the same segbits. I assume we've confirmed this is not the case? |
Can we just special case |
Sure, we just need to agree on an approach. If we go with iob_top and iob_bot, it changes how the fuzzers will output database data. The original approach was to have both _top and _bot in the same segbit. It's not obvious which requires less rework overall, but I'd say that iob_top and iob_bot is probably most consistent with how the other tiles work. |
Fixes #341
These were held off because they generate some weird special cases I didn't want to think about at the time. So here's a proposed solution.
First, the problem: in a7, IOBs are typically in LIOB33 tiles. These have two IOB sites, just like a SLICE has several CLBs. However, unlike CLBs, these IOBs are sometimes split into LIOB33_SING tiles, which only have a single IOB33. The problem is that in some cases the single instance is the Y=1 case, which basically starts at word 2 in our LIOB33_SING tile (if you follow the pattern in LIOB33 or want a Y=0 and a Y=1 LIOB33_SING to have a consistent address space). The issue is that this actually occurs at FDRI word 0, meaning we essentially have a negative tile address (-2) if we want the reference bits, starting at address 2, to be in frame 0.
Sample tilegrid output from running this fuzzer:
I ran segprint and the 030-iob fuzzer. Both seemed happy with this, so I'm inclined to commit this as is and move forward.