Skip to content

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

Conversation

acomodi
Copy link
Collaborator

@acomodi acomodi commented Dec 15, 2021

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

  • Bug fix (change which fixes an issue)
  • New feature (change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

  • My change requires a change to the documentation
  • I have updated the documentation accordingly
  • I have added tests to cover my changes
  • All new and existing tests passed

@acomodi acomodi requested review from tangxifan and vaughnbetz and removed request for vaughnbetz December 15, 2021 15:03
@github-actions github-actions bot added libarchfpga Library for handling FPGA Architecture descriptions VPR VPR FPGA Placement & Routing Tool labels Dec 15, 2021
@acomodi
Copy link
Collaborator Author

acomodi commented Dec 15, 2021

@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.

@acomodi acomodi force-pushed the acom/fpga-interchange-improve-arch-reading branch from 64cb803 to 7a1a6fa Compare December 21, 2021 10:32
@acomodi acomodi force-pushed the acom/fpga-interchange-improve-arch-reading branch from 7a1a6fa to 21728dd Compare December 22, 2021 16:18
@acomodi acomodi force-pushed the acom/fpga-interchange-improve-arch-reading branch from 21728dd to f439cd4 Compare January 13, 2022 15:57
Copy link
Contributor

@tangxifan tangxifan left a 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.

@@ -118,6 +118,8 @@ void uniquify(Container container) {

int get_pid();

char* stringf(const char* format, ...);
Copy link
Contributor

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?

Copy link
Collaborator Author

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

@acomodi acomodi requested a review from tangxifan January 21, 2022 10:43
acomodi and others added 13 commits January 21, 2022 12:04
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]>
These workarounds can be removed once the RR graph generation is in
place

Signed-off-by: Alessandro Comodi <[email protected]>
@acomodi acomodi force-pushed the acom/fpga-interchange-improve-arch-reading branch from 77f2ea9 to 821bff9 Compare January 21, 2022 11:04
Copy link
Contributor

@tangxifan tangxifan left a 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;
Copy link
Contributor

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.

Copy link
Collaborator Author

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?

Copy link
Contributor

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.

@acomodi
Copy link
Collaborator Author

acomodi commented Jan 25, 2022

All CI checks passed. Merging

@acomodi acomodi merged commit 44f9683 into verilog-to-routing:master Jan 25, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
libarchfpga Library for handling FPGA Architecture descriptions VPR VPR FPGA Placement & Routing Tool
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants