Open tausen opened 10 months ago
I have been considering doing this for a while. It has to be done on both the sync and async FIFOs. But, I have not yet sorted out the best set of parameters to add to the modules. I'm thinking it's perhaps time to add additional parameters for target, vendor, family, device, etc. and then set stuff like this based on that, which will hopefully keep things a bit more manageable vs. adding a bunch of vendor-specific parameters. I think a good rule of thumb is that if a parameter name contains a vendor name, you're probably doing something wrong. Also, this method could probably also help to override tool heuristics that pick the wrong type of memory by instead picking the type based on the depth parameter.
additional parameters for target, vendor, family, device, etc. and then set stuff like this based on that, which will hopefully keep things a bit more manageable vs. adding a bunch of vendor-specific parameters
That does sound like a cleaner approach... I spent some time wondering what (* ramstyle = "no_rw_check" *)
meant in axis_fifo.v
, until I realized it was ramstyle
(Intel/Altera) and not ram_style
(AMD/Xilinx).
I'm not sure how one would go about choosing BRAM vs URAM on AMD/Xilinx devices, though. There are some cases where only BRAM will work, but many cases where either URAM or BRAM would work. I usually find myself wanting to control how my precious memories are allocated depending on the rest of the design. Are there similar "almost but not quite the same" higher-density memories in Intel/Altera FPGAs?
Allows the user to guide the synthesis tool when choosing memory type in
axis_fifo
.Without guidance, Vivado will gladly use all available BRAM instead of targeting URAM in UltraScale FPGAs. I don't have Intel/Altera tools installed, so that part is untested. Shouldn't change anything with default options.