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

List of "Guaranteed Optimizations" in SUS #4

Open
VonTum opened this issue Aug 13, 2024 · 0 comments
Open

List of "Guaranteed Optimizations" in SUS #4

VonTum opened this issue Aug 13, 2024 · 0 comments
Labels
good first issue Good for newcomers Request Input These are issues about the design of the language, and thus should be discussed

Comments

@VonTum
Copy link
Collaborator

VonTum commented Aug 13, 2024

So SUS is not doing optimization for the most part. The reason is mostly that the compiler can't know the developer's intention and thus can't know that it is actually optimizing. Be it for area, logic/register use, congestion, or critical timing paths.

However, what I do intend for SUS is to have a limited list of "Guaranteed Optimizations". These are there to reduce the number of distinct concepts (eliminating integer wire cutoffs as in Verilog for instance), or to undo pessimizations the Language's syntax forced upon the user.

  • Divisions & multiplies by constant powers of 2 are optimized to bitshifts (which is just wires)
  • Modulo by constant power of 2 also just becomes cutting of wires
  • Elimination of conditions on multiplexer if all valid Mux inputs are identical.

To illustrate that last one, take the following code:

module UseFIFO {
    interface pushData : bool pushValid, int data

    FIFO::<DEPTH=32; int> myFifo
    
    if pushValid {
        myFifo.push(data);
    }

    // ... pop blah blah
}

On myFIFO.data, there is a dependency from pushValid, just because it happens to be in a conditional scope because we only want to call myFifo.push(int data) when pushValid. While any synthesis tool probably optimizes the condition out as well (as the alternative is 'x), it still affects Latency Counting. It could be that data is available earlier than the condition, and we don't want to add an unnecessary dependency on that.

On the other hand, for looking at the waveform it might be nicer to preserve this 'x information, so I'm still not entirely decided on this one.

@VonTum VonTum added Request Input These are issues about the design of the language, and thus should be discussed Good for starters labels Aug 13, 2024
@VonTum VonTum added good first issue Good for newcomers and removed Good for starters labels Aug 24, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
good first issue Good for newcomers Request Input These are issues about the design of the language, and thus should be discussed
Projects
None yet
Development

No branches or pull requests

1 participant