Skip to content
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

Primitive input pin permutability should be more general #2533

Closed
vaughnbetz opened this issue Apr 11, 2024 · 2 comments
Closed

Primitive input pin permutability should be more general #2533

vaughnbetz opened this issue Apr 11, 2024 · 2 comments
Assignees

Comments

@vaughnbetz
Copy link
Contributor

Currently we assume LUT input pins are permutable, and (I believe) other primitives are not. We should make this data-driven through the arch file so users can specify which inputs are permutable.

Proposed Behaviour

Users should specify the logical equivalence between primitive inputs. LUTs usually have equivalent inputs, but when used as pre-processing units in front of adders they usually have less equivalence. E.g. in Altera-like architectures, the 6-LUTs are divided into multiple 4-LUTs feeding the adders, so really we have 4-LUT groups of equivalent pins. Also, in Quartus synthesis output (used by Titan designs), we always have lcell_comb instead of LUTs (it is a LUT + adder) and the equivalence is a function of whether it is a LUT or not; if the adder is used there is less equivalence.

Current Behaviour

We assume LUTs are completely permutable, and every other primitive does not have permutable inputs.

Possible Solution

Connect to the existing arch file support that says whether ports are logically equivalent or not. Remove the current LUT-based permutability (automatically used) and generate a warning if the LUT pins are not marked as logically equivalent. Also need to fix a bunch of architecture files -- maybe an update script?

Context

With the flat router, it would be useful to have this extra degree of control. Both the clusterer and router should be connected to the new functionality.

@vaughnbetz
Copy link
Contributor Author

vaughnbetz commented Apr 11, 2024

Comment from @rs-dhow
May be able to handle this by ensuring we have different modes for arithmetic, 5 vs. 6-LUT etc. and never declare more inputs than can be swapped on the LUT in that mode.

@vaughnbetz
Copy link
Contributor Author

Decided this probably isn't needed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants