-
Notifications
You must be signed in to change notification settings - Fork 415
FPGA Interchange: improve arch reader #1937
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
FPGA Interchange: improve arch reader #1937
Conversation
@tangxifan @vaughnbetz I opted to open a bigger PR to include all the changes necessary to have a LUT design to be placed and routed with the interchange format. The diff is quite big, but all the major changes are only corresponding to the interchange arch reader, to which I have added some high level comments. |
64cb803
to
7a1a6fa
Compare
7a1a6fa
to
21728dd
Compare
21728dd
to
f439cd4
Compare
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.
@acomodi Changes make sense to me. Major comments are on the API comments and code clean-up. Feel free to tell me if there is anything confusing.
libs/libvtrutil/src/vtr_util.h
Outdated
@@ -118,6 +118,8 @@ void uniquify(Container container) { | |||
|
|||
int get_pid(); | |||
|
|||
char* stringf(const char* format, ...); |
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.
Is it possible add comments on this API?
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 API is actually not really required. The fact is that IMO it is better to make wider use of std::string
and C++ standards to build strings. I have changed the interchange reader to avoid using this string formatter API
This commit also reworks the way the name is assigned to the null types Signed-off-by: Alessandro Comodi <[email protected]>
Signed-off-by: Alessandro Comodi <[email protected]>
Signed-off-by: Alessandro Comodi <[email protected]>
Signed-off-by: Alessandro Comodi <[email protected]>
Signed-off-by: Alessandro Comodi <[email protected]>
Signed-off-by: Alessandro Comodi <[email protected]>
These workarounds can be removed once the RR graph generation is in place Signed-off-by: Alessandro Comodi <[email protected]>
Signed-off-by: Alessandro Comodi <[email protected]>
Signed-off-by: Maciej Dudek <[email protected]>
Signed-off-by: Alessandro Comodi <[email protected]>
Signed-off-by: Alessandro Comodi <[email protected]>
Signed-off-by: Alessandro Comodi <[email protected]>
Signed-off-by: Alessandro Comodi <[email protected]>
Signed-off-by: Alessandro Comodi <[email protected]>
Moreover, this commit reduces code verbosity to get directions of pins Signed-off-by: Alessandro Comodi <[email protected]>
Signed-off-by: Alessandro Comodi <[email protected]>
Signed-off-by: Alessandro Comodi <[email protected]>
Signed-off-by: Maciej Kurc <[email protected]>
Signed-off-by: Alessandro Comodi <[email protected]>
Signed-off-by: Alessandro Comodi <[email protected]>
77f2ea9
to
821bff9
Compare
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.
@acomodi Thanks for the effort. Most comments have been well addressed. Just some minor details to cover.
@@ -653,6 +653,9 @@ struct t_physical_tile_type { | |||
|
|||
// Does this t_physical_tile_type contain an outpad? | |||
bool is_output_type = false; | |||
|
|||
// Is this t_physical_tile_type an empty type? | |||
bool is_empty = false; |
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.
When we will refactor the data structure, I think I will not keep a boolean variable. Currently, as far as I see, to identify an empty physical_tile
, there are multiple ways. I see in some codes, the name is used as a reference, while in other codes, the index is used as a reference. That will create issues. That is why we need an API is_empty()
to provide a general reference. I do not have a strong opinion whether to use name or index. But we should use an API so that developers have a standard way to follow.
For example:
bool is_empty() {
return std::string(name)== EMPTY_BLOCK_NAME;
}
I am open to discussion. Let me know what you think.
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.
Right, I have actually implemented this change in 162ca07. Also, I think that for now, the Interchange can also make use of the default name for the EMPTY
blocks, but it is worth noticing that, if this can be a customizable parameter, relying on its name to verify whether a block is empty could not be the best solution.
I am thinking that maybe we can use the same approach as for the architecture name?
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.
@acomodi The approach for the architecture name makes sense to me. We follow this way.
Signed-off-by: Alessandro Comodi <[email protected]>
Signed-off-by: Alessandro Comodi <[email protected]>
All CI checks passed. Merging |
Description
This PR is to improve and add missing features to be able to correctly read the interchange device, and place and route a design using the automatically generated RR graph.
This is true for all the currently available interchange architectures, namely xilinx series7, lattice nexus and the basic test-architecture.
Given that the RR graph is auto-generated, the route file will be invalid, but we can start adding regression tests to verify that the whole flow is correct.
Motivation and Context
This is in the contect of adding support to the FPGA interchange format
How Has This Been Tested?
Unit C++ tests
Types of changes
Checklist: