I would like to expose the DDR register pins from the top level of hostmot2. This allows us to externally add a component that can perform logic on the IO pins, such as ANDs and ORs, in a manner that can be synthesized.
Presently, if you try to intercept the IO bits outside of hostmot2, the synthesizer will pass but the implementation portion of compiling fails miserably with multiple drivers. By exposing the DDR bits, we can have proper tristate bus logic.
Summary of benefit - We can do basic ladder logic in the fpga, because, hey, it's good at doing logic. Plus, this allows for hardware IO pin debouncing, etc. without wasting clocks at the control level.
I cannot see any side affects that will impact any of the existing designs since all of the files are using named generics already. Should be totally transparent unless you want the ability to implement extra logic in the fpga (which I really, really, really do).
Three files would be affected if you wanted to expose the ddr pins in the manner my pull request does:
- hostmot2 has an additional output port at the top level called ioddrbits the same dimensions as IOBits
- wordPR gets an additional output port that exposes the ddr register full time
- The top level hostmot wrapper file native to Altera or Xilinx tools would need to also expose the new port.
I have a small pull request ready to go if you guys are cool with this that I will submit, I just wanted to get some feedback first.
I would like to expose the DDR register pins from the top level of hostmot2. This allows us to externally add a component that can perform logic on the IO pins, such as ANDs and ORs, in a manner that can be synthesized.
Presently, if you try to intercept the IO bits outside of hostmot2, the synthesizer will pass but the implementation portion of compiling fails miserably with multiple drivers. By exposing the DDR bits, we can have proper tristate bus logic.
Summary of benefit - We can do basic ladder logic in the fpga, because, hey, it's good at doing logic. Plus, this allows for hardware IO pin debouncing, etc. without wasting clocks at the control level.
I cannot see any side affects that will impact any of the existing designs since all of the files are using named generics already. Should be totally transparent unless you want the ability to implement extra logic in the fpga (which I really, really, really do).
Three files would be affected if you wanted to expose the ddr pins in the manner my pull request does:
I have a small pull request ready to go if you guys are cool with this that I will submit, I just wanted to get some feedback first.