clash-compiler
clash-compiler copied to clipboard
clash-lang
Tdp blockram configurations
Different configurations for TDP Ram, for each port you can configure the write mode (WriteFirst, ReadFirst or NoChange) and whether or not to use additional output registers.
trueDualPortBlockRam takes a TDPConfig argument that contains these parameters, default set to WriteFirst and not using additional output registers.
This branch also implements conflicts for write collisions and BlackBox functions that generate the HDLs based on the configuration.
Still TODO:
- [x] Make sure the haskell model adapts to the three different configurations: WriteFirst, ReadFirst and NoChange.
- [x] Make sure the different configurations generate the correct HDL
- [ ] Check that Vivado and Quartus both correctly infer the configurations.
- [x] Make sure the Haskell model and HDLs have the same behavior by using the tests implemeting in the clash-testsuite under DualBlockRam
- [ ] Write a changelog entry (see changelog/README.md)
- [ ] Check copyright notices are up to date in edited files
Future goals:
- [ ] Add reset signals to the primitive.
- [ ] Implement reset behavior in Haskell.
- [ ] Write tests with test whether the reset behavior is the same.
- [x] Add optional output registers
We might want to postpone writing new tests until we can use e.g. Hedgehog to test the implementations.
For other blockRAMs, we implement Read First and then provide readNew to adapt that into Write First. A similar adapter could be written for No Change.
Has this option been explored? It could very well be that not all synthesis tools will infer the correct type of blockRAM (or maybe only with flags set to non-default values), but I'd like to explore this option. Also note that even if it is not correctly inferred, it might lead to the exact same result. That is, a particular FPGA might very well have a blockRAM that really only does Read First and implement other options with regular LEs around the blockRAM. So in that case it doesn't matter if the synthesis tool recognises the adapter or not, since it's the exact same end result.
Maybe the renaming should be a separate commit so the functional changes are easier to grok?
We've decided to close this; writing generic, cross-vendor true dual port blockrams is pretty much impossible. We'll add vendor specific ones to clash-cores instead.
