Skip to content

Noc description support and modelling in VPR #2010

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

Merged
merged 77 commits into from
Jun 30, 2022
Merged

Conversation

Srivat97
Copy link
Contributor

Extended the FPGA architecture description to now include NoC specific information. Then updated VPR to process the NoC information provided by the user and create an internal model. Finally, the graphics was updated to display the NoC to the user.

Description

libarchfpga

  • Updated the xml parser code to now include the additional tags used to describe the NoC. This information is then stored internally.

libvpr

  • Added a new class called NocRouter which represents a router within the NoC
  • Added a new class called NocLink which represents a link within the NoC (connections between routers)
  • Added a new class called NocStorage which represents the entire NoC (list of routers and links that together make up the NoC)
  • Created a new context called noc_ctx, this contains all the NoC related material so that it can be accessed globally
  • Added a new function called setup_noc that is called when the device is being created. This is responsible for building the NoC based on the information provided in the FPGA architecture description file. This includes creating all the routers and links.
  • Added a new set of command line options for the NoC.
  • Added a new button to display the NoC (draws the routers and links). Also can draw the NoC link usage as a heat map.

Related Issue

Motivation and Context

The eventual goal is to have a CAD tool that is capable of targeting FPGA architectures with an embedded NoC. But first we need to be able to get specifications about the NoC, such as its topology, location on the FPGA, and any design constraints (max link bandwidth, link latency, router latency and etc..). Once we have the NoC specifications, we need to model it so that we can ensure any steps taken in the CAD flow always meet the NoC design specifications. So the initial steps of getting the NoC information from the user and modelling it as done in this pull request.

How Has This Been Tested?

  • Unit tests were added to verify the newly developed functions
  • Additionally, sample FPGA architecture description files were created that included a description of an embedded NoC. VPR was run on the sample FPGA architecture description files with arbitrary designs and the NoC was displayed visually to ensure that the new feature worked correctly.

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

@Srivat97 Srivat97 requested a review from vaughnbetz April 13, 2022 03:17
@github-actions github-actions bot added libarchfpga Library for handling FPGA Architecture descriptions VPR VPR FPGA Placement & Routing Tool labels Apr 13, 2022
@Srivat97 Srivat97 force-pushed the noc_description_support branch from 5f40de0 to 7b96833 Compare April 13, 2022 17:03
@vaughnbetz
Copy link
Contributor

Should add an architecture file to test the overall flow works (augments the unit tests). It's OK if it's a simple architecture-in-progress.

Copy link
Contributor

@vaughnbetz vaughnbetz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good overall, but some changes requested.
Most important: unit tests must test the real code (not a copy).

@@ -204,6 +204,10 @@ void free_arch(t_arch* arch) {
if (arch->clocks) {
vtr::free(arch->clocks->clock_inf);
}

if (arch->noc) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can skip this if, as delete on a NULL pointer is safe (defined to be a no-op).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fixed

@@ -1773,6 +1773,29 @@ struct t_lut_element {
}
};

/* Network-on-chip(NoC) Router data type used to identify
* connections regarding individual routers in the network. */
struct t_router {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Comment this is used when parsing the arch file (not long term storage). Comment each data member (what is it, any rules or usage).
Best to make Doxygen comments for this.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done


/* Network-on-chip(NoC) data type used to store the network
* properties and used when builidng a dedicated on-chip network*/
struct t_noc_inf {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good to comment that we assume all links properties and router_latency are the same right now.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done


std::vector<t_router> router_list;

std::string noc_router_tile_name;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Worth commenting that this must match some tile type name in the arch file.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done

pugiutil::expect_only_attributes(topology_tag, {}, loc_data);

// stores router information that includes the number of connections a router has within a given topology and also the number of times a router was declared in the arch file using the <router> tag
// in the datastructure below, the router id is the key and stored data is a pair, where the first element is describes the number router declarations and the second element describes the numbe router connections
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is describes -> describes
the number -> the number of
numbe -> number of

Might also want to mention this is used only for error checking

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fixed

@@ -187,13 +189,26 @@ static void set_block_text(GtkWidget* widget, gint /*response_id*/, gpointer /*d
static void clip_routing_util(GtkWidget* widget, gint /*response_id*/, gpointer /*data*/);
static void run_graphics_commands(std::string commands);

// draw_noc helper functions
static ezgl::rectangle get_noc_connection_marker_bbox(const t_logical_block_type_ptr noc_router_logical_block_type);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If these could go in a separate file (draw_noc.cpp) that would be good as draw.cpp is too big.
But if they're using file scope variables we can leave them. Could be good task for summer students to clean up.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can I change some functions that I use externally from being static?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure. There's nothing too special about static; just a way to hide names inside a file if they aren't needed outside. If they are needed outside, feel free to remove the static and put their declarations in the .h file.

# include "vpr_error.h"
# include "vtr_math.h"

/**
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good to have a comment on what should go in this file.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done

return result;
}

// if we are here then the line has a slope, so we use the cross product to determine the angle
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think this is really the cross product --> maybe you're figuring it out from the dot product? A temporary variable or two might help here too.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, it was a dot product not a cross product. Changed and included comments.

link_coords.start.x += noc_connection_marker_quarter_width;
link_coords.end.x += noc_connection_marker_quarter_width;

link_coords.start.y += noc_connection_marker_quarter_height;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Might be able to simplify by defining an offset (either x_off and y_off or an ezgl point offset) then you may be able to just always add and subtract the offset; the set up code would have figured out whether x_off, or y_off was 0 or negative etc.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will leave as is for now. I'll think of a better solution and change later.


/*Re-defining static functions in setup_noc.cpp that are tested here*/

static void identify_and_store_noc_router_tile_positions(const DeviceGrid& device_grid, std::vector<t_noc_router_tile_position>& list_of_noc_router_tiles, std::string noc_router_tile_name) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Better to make this non-static and test the real code, not a copy.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done

@vaughnbetz
Copy link
Contributor

Infrstructure issue; CI should pass once I merge Alireza's change.
Good to get this merged soon; draw will have to be updated as it was heavily refactored.

Srivat97 added 23 commits June 24, 2022 20:47
… input. Also added a function that isolates noc router tiles from the device grid.
… router ids to the id system used for routers in the NoC
…e class that pre-allocates space for datastructures
…m found the closest physical router to each logical router, instead of the other way around.
Srivat97 added 23 commits June 24, 2022 20:56
…lay the noc links or also the bandwidth usage of each link.
…mody anything by making it a constant function
… links are seperated and not drawn on top of each other
…ure when running the Unit tests during a push
…e inside the src directory was used. Not doing this resultedin the main.cpp file inside the test folder also being used and this caused a failure in the github CI. Also note that this how other projects are also setup.
…lass to print its information and also added functions to directly access routers and links in the NoC
…dicate that the id is supplied by the user. Also improved the documentation for the NocLink class.
…Also changed the class so that instead of functions that returned member variables of the NocRouter and NocLink class, new functions were added to return the NocRouter and NocLink themselves.
…o setup_noc.h,improved commenting in setup_noc.cpp, fixed some comments in noc_storage.h and finally removed re-declaration of static funtions in test_setup_noc.cpp
…ter latency from the noc context and moved it to the NocStorage class. Changed the echo function to include these noc properties as well. Changed all calls to those properties from using the noc context to using the NocStorage class.
…xygen comments to explain a few of the NoC drawing functions that were poorly commented before.
… to draw_toggle_functions.cpp. This was done to match the previous refactor changes.
@Srivat97 Srivat97 force-pushed the noc_description_support branch from 33632a5 to 9b81271 Compare June 25, 2022 20:04
…scription of their topology. Updated README inside /home/srivat97/Research_Project/work/vtr_flow/arch/ to help users find these newly added files.
@Srivat97
Copy link
Contributor Author

@vaughnbetz This PR should be ready to merge. Fixed all requested changes or made a comment to explain why I didn't make the change.

I also added some sample architecture files I used to test this new feature. They can be found under "$VTR_ROOT/vtr_flow/arch/noc". There are two architecture files in there, one has a mesh topology and the other has a star topology. I also updated the README found in "$VTR_ROOT/vtr_flow/" to help new users find these files and explain their purpose.

@vaughnbetz
Copy link
Contributor

Looks good -- thanks!

@vaughnbetz vaughnbetz merged commit b30b9fa into master Jun 30, 2022
@vaughnbetz vaughnbetz deleted the noc_description_support branch June 30, 2022 21:18
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.

2 participants