Extend XY_SPECIFIED syntax support to fixed layout XML files

[petergrossmann21]

The recent pull request for XY_SPECIFIED custom switch block specification #2664 was tested with an architecture with an <auto_layout> tag.

In the use case that I have for this feature the requirement will be to use it on layouts using the <fixed_layout> tag instead. Testing on an architecture of this type yielded the following error

Error 1: /projects/zeroasic/fpgaa_working/upgrade_custom_switchblock_xml/fpga_architect/test/fpga_gamma_vanilla_baby_falcon/cad/fpga_gamma_vanilla_baby_falcon.xml:489 Specifying SB locations for auto layout devices are not supported yet!

It would appear that the error message is checking for the wrong layout type (or reporting the wrong layout type).

@saaramahmoudi , is the feature expected to work for both layout types? If so, we can pick some fixed layout architecture and add an additional test case as part of closing the error message.

In the event that I'm the only user of the feature in this use case I may be able to contribute to the development of a fix, as long as we are lenient with respect to schedule.

[saaramahmoudi]

Hi @petergrossmann21,

The feature is not supported for auto_layout yet, but the process is very easy. When we are parsing the custom switchblock specification in read_xml_arch.cpp, I don't know what it the grid_width and grid_height if we are using auto_layout feature (since that is decided in packer step not in the parsing step). The solution would be to save these information from architecture file as a string in read_xml_arch.cpp and perform the actual parsing in rr_graph.cpp when the packer has already finished, meaning that we just need to move my code from one place to another.
I was planning to do that with my next PR. However, I am a bit busy right now and can't do that immediately.
Hope that helps and let me know if you have more questions.

[petergrossmann21]

@saaramahmoudi Thanks for checking in.

The issue is not that the feature is needed for auto_layout, it's the opposite of that. Your test case actually exercises auto_layout. See https://github.com/verilog-to-routing/vtr-verilog-to-routing/blob/master/vtr_flow/arch/custom_sb_location/stratixiv_arch.timing.xml line 4733.

If you are busy, I may have a little time to devote to a small PR to test fixed layout. I will keep you posted.

[saaramahmoudi]

@petergrossmann21 I used one of the existing architecture to create the task, however I passed --device in task config file if you look into this file: strong_custom_sb_loc

[petergrossmann21]

Update: I am able to reproduce the error message described above with the provided vtr_flow/arch/custom_sb_location/stratixiv_arch.timing.xml. Was testing as your latest reply came in; sounds like I don't have a firm grasp on how the architecture is converted to fixed layout in the testing.

That said, the architecture file I provide explicitly uses the fixed_layout tag. I know older versions of VPR used the style <layout type="auto"> or similar to specify layout type rather than using a child tag; is something like that required here?

[saaramahmoudi]

The architecture might contain both <auto_layout> and <fixed_layout> tags in the description. The command line will decide which one to use; if you --device in the command line and pass one of the fixed_layout tags' name, you should not see the error. If you don't use --device or use it as --device auto, the <auto_layout> will be used and since the feature is not supported within the auto_layout, you will see the error.
I am not sure about how the old version of VPR works since I wasn't around at that time, sorry!

[petergrossmann21]

Aha, right you are -- I see the fixed_layout tag below now in your example. This is a feature I was not familiar with.

My architecture contains only a fixed_layout tag; let me play around with --device and see what I turn up.

@vaughnbetz What are your thoughts on how features that require <fixed_layout> should be supported? Should it be possible for a feature of this type to work without use of the --device option at the CLI?

[petergrossmann21]

Update: adding a --device option to the VPR command line when running my own architecture works. It appears that the item to close is the matter of whether adding this command-line option should be required to use this feature.

[vaughnbetz]

Adding @AlexandreSinger since he was also wondering about how he'll handle multiple fixed devices in his testing. I think specifying a --device on the command line makes sense. We default to auto if it isn't specified, which seems reasonable. The only other default I can think of would be : the only layout in the arch (if there is only one), otherwise auto. Not sure if that would be more clear or more confusing though. From a coding standpoint it is a bit more messy as we'd have to defer figuring out the device until after parsing the arch file (i.e. a command line default is now a function of the arch file parsing, which seems a bit coupled/messy).

[petergrossmann21]

With the bias that I exclusively work with architecture files for which there is only one layout in the arch and it is of type <fixed_layout>, I find the "only layout" else auto default appealing. However, I'm not sure that it's really worth setting it up that way if it causes headaches. Happy to discuss further in a call (weekly sync-up or schedule a smaller discussion)

[AlexandreSinger]

@vaughnbetz I spent the last couple of days designing a way that works for me. We can discuss further but here is what I found so far. @petergrossmann21 You may find this interesting as well. For context, I am also working with fixed devices with fixed IO; but different circuits have different fixed IO. I am working on improving the VTR task infrastructure to allow me to do this all within one config file (which it cannot do at the moment).

I agree with what @saaramahmoudi said above; an architecture can specify both an auto_layout and fixed_layouts. The example I am working with locally:

As far as I can tell (I am still doing a bit more testing) when the --device argument is not specified, it will default to use the auto_layout in this case. From previous experience, if your architecture does not have an auto_layout specified, it will pick from the fixed_layouts if a device is not specified; but I have never checked this directly.

For what I am working on, I need to constrain different circuits to different devices and atom constraints in the same VTR task config file. I am working on introducing a new option to the config file called circuit_constraint_list_add which will "constrain" a circuit to a specific architecture, device, or constraint (it can be one or all of these). So it would look something like this:

Notice that in this example, I constrained the first three circuits to the mcnc_min_device and the last circuit to the mcnc_medium_device.

This is still WIP, but I hope to merge this in sometime in the next week or so.

[petergrossmann21]

From previous experience, if your architecture does not have an auto_layout specified, it will pick from the fixed_layouts if a device is not specified; but I have never checked this directly.

@AlexandreSinger I can confirm that it will pick a fixed layout with no --device option specified and no auto_layout provided.

If anyone has interest in the basic approach to layout construction I am using, a pair of examples are available in the open
here. These are starting to show their age a bit in certain respects but for this discussion are still on point.

I do not currently take advantage of the ability to specify multiple layouts in the same arch file, so many of the considerations here are intellectual curiosities for my use case rather than practical considerations. That said, I can imagine some very forward looking scenarios where diving deeper on this topic would be relevant for my work.

[petergrossmann21]

Based on industry sync meeting discussion, I'm opting to close this issue; we can reopen a related subtopic as a future issue if it needs additional discussion.