Quartus bram factor

[jmitrevs]

Description

This enables the BramFactor functionality for the quartus backend. For now, it's very much a copy of how it is done for Vivado. We will test it's usefulness in the near future.

Type of change

• [x] New feature (non-breaking change which adds functionality)

Tests

The pytest, test_bram_factor.py, was broadened to cover this use case.

Checklist

• [x] I have read the guidelines for contributing.
• [x] I have commented my code, particularly in hard-to-understand areas.
• [x] I have made corresponding changes to the documentation.
• [x] My changes generate no new warnings.
• [x] I have installed and run pre-commit on the files I edited or added.
• [x] I have added tests that prove my fix is effective or that my feature works.

[jmitrevs]

I am not sure this is the best approach in quartus, however. I believe all pointer variables are put into one memory. It may be better to have explicit Avalon MM interfaces for the weights. The question then becomes whether it's better for them to be Host or Agent. In Host, the memory is external, and has to be optimized externally. With Agent, it's internal, optimized by the HLS compiler. I am not sure what's better.

[jmitrevs]

I think viewing this as code to put in a wrapper is useful. I think it's true that the performance wouldn't be good if this was used directly. I think making this perform better as is would make it more difficult to incorporate. One could argue in general if the component attribute is better left off the source code and put in the compilation flags only.