-
Notifications
You must be signed in to change notification settings - Fork 66
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
Change the IO coding to synthetic #177
Conversation
The new coding system uses a logicinfo table to search for the right fuzes by given combinations of attributes. Actually required bits are taken from vendor's longval tables. The same tables are used to decode binary images. tiled_fuzzer.py calls the vendor compiler only once to get an empty image template. * All references to IO coding bits, including standards, are removed from the base structure. * Removed fuzzing IO. * Removed fuzzing corner bank cells - their own table is used for them. * Removed fuzzing of dual-purpose pins - their own table is used for them. * Real LVDS primitives TLVDS_IBUF, TLVDS_TBUF and TLVDS_IOBUF are implemented. * All emulated LVDS primitives are implemented: ELVDS_IBUF, ELVDS_OBUF, ELVDS_TBUF, ELVDS_IOBUF. * All new primitives can connect with IOLOGIC. * The OEN port of the I/O primitives (including differential ones) can be controlled by IOLOGIC. * Added detection of gross user errors like placing TLVDS in place of the emulated one. * It is possible to use as a differential special simplified IO elements located on the 6th row in the chips GW1N-1 and GW1NZ-1, but here may require additional research and in general the other pins should be enough. Signed-off-by: YRabbit <rabbit@yrabbit.cyou>
Forgot:
|
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.
Haven't tried it out yet but visual inspection looks good to me. Really love deleting code from tiled_fuzzer.
This doesn't change the chipdb format, or does it? Just want to make sure that if the final DB is different we maybe bump the db number, and if it isn't that we can compare the DB before and after this PR to make sure there are no unintended changes.
I'll try out the code tomorrow. Exciting!
@@ -109,19 +109,19 @@ def get_diff_cap_info(device, package, special_pins=False): | |||
is_diff = 'DIFF' in pin.keys() | |||
if not is_diff: | |||
res[str(pin['NAME'])] = (is_diff, is_true_lvds, is_positive) | |||
cotinue |
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.
oops lol
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.
This led me to believe that this situation never occurs in principle, otherwise it would have been discovered a long time ago, but left it for now just in case :)
|
||
# bank modes | ||
fse_banks(fse, db, corners) | ||
fse_iob(fse, db, pin_locations, diff_cap_info, locations); | ||
|
||
chipdb.dat_portmap(dat, db, device) |
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.
I'm thinking if it makes sense to restructure chipdb assembly a bit now. It used to be that here we extract data from fse and dat files, do fuzzing, and then feed it to the next stage doing clock stuff and such. I think it's fine as it is, but maybe there is opportunity to restructure things a bit. This file is hardly "tiled_fuzzer" any more haha
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.
there is still a call to the IDE compiler to get an empty image;) But yes, restructuring is called for.
if k not in iologic_attrids.keys(): | ||
print(f'XXX add {k} key handle') | ||
if k not in attrids.iologic_attrids.keys(): | ||
print(f'XXX IOLOGIC: add {k} key handle') |
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.
Another idea that I don't think is really required but could be interesting to do eventually is to use the logging module instead of printing, so we could use logging.warn here or something like that.
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.
That's for sure. print is very inconvenient because of the lack of structuring of messages - this XXX is a trick to be able to then search by type of messages in the output otherwise I just skipped my own debugging information :) But this is exactly a crutch.
Yes, the structure has changed to throw out unnecessary and irrelevant information about IO.
|
It was used to minimize the bit representation of various I/O cell features, but is no longer relevant due to the fact that bits are no longer defined by fuzzing and are not stored in the database. Signed-off-by: YRabbit <rabbit@yrabbit.cyou>
I tested a couple of examples and they all work so far. Except attosoc of course... |
Hmmm I tried to compare the chipdbs and it seems they are largely the same which is good news but there are a few differences, and I want to make sure they are expected. Need to try to remember what these values mean. |
It seems to be only portmaps that are slightly different. If this makes sense to you, I think it's good to merge. |
It makes sense and the portmap is not really different - just that some Bels are unloaded in a different order (sort of like IOBB was ahead of IOBA) and naturally drag their portmap with them. I don't know why this thing happens, but it doesn't affect nextpnr in any way :) |
The new coding system uses a logicinfo table to search for the right fuzes by given combinations of attributes.
Actually required bits are taken from vendor's longval tables. The same tables are used to decode binary images.
tiled_fuzzer.py calls the vendor compiler only once to get an empty image template.