Expose IO DDR register from top level of hm2

[dkhughes]

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:

1. hostmot2 has an additional output port at the top level called ioddrbits the same dimensions as IOBits
2. wordPR gets an additional output port that exposes the ddr register full time
3. 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.

[cdsteinkuehler]

On 8/4/2016 4:56 PM, dkhughes wrote:

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'm totally cool with changing from the current tri-state I/O pin
scheme to something more sane like din/dout/ddir for both the I/O pins
and the read/write bus.

Using "tri-state" logic internal to the FPGA is just asking for
trouble. Even when it gets mostly correctly synthesized by the tools
(by getting turned into gigantic OR gates), funny and unexpected
things can happen.

Charles Steinkuehler
[email protected]

[dkhughes]

Using "tri-state" logic internal to the FPGA is just asking for trouble.

I agree with that completely, but the way the top level IOBits function right now (selectable direction at runtime by the hal) requires them to be inout or buffer types connecting to the fpga package pins. Originally, to avoid the tristate bus handling internally I put the logic module inside the hostmot2 file. There, we have unidirectional input register and output registers, but it required a custom hostmot2 at the IP level, and that just seemed like the amount of customized-but-99% identical IPs could grow exponentially.

I guess another way around would be adding dedicated logic blocks inside hm2 and having them resolve to wires unless a project customized them similar to the unique PIN files. That would avoid internal tristate design and IP duplication.

[the-snowwhite]

Sorry I have not been able to communicate much.

Please look at this example of what you are mentioning here:

the-snowwhite/mksocfpga-hm3_dev@fbc30b8

#38

#18

I think maybe mux was the wrong term, because I found out I could be implemented in a very simple but efficient way.

I cannot find where I placed the documentation right now, as I had no placeholder for it at that time, and not much time to find out how much has changed here since.

[dkhughes]

I'm not a verilog guy (yet at least), so I broke the gpio into two buses using VHDL. This required an external component that handles the top level tristate logic. I added that as an IP block on the zynq side. Right now, these changes are isolated in the zynq ip, but I really like the split bus since I can add logic and debounce registers in hardware instead of using ARM clocks at the HAL layer. Suggestions welcome on making this acceptable for the main hostmot2 source folder.

See the WIP here:
https://github.com/JDSquared/mksocfpga/tree/jd2_priv/HW/zynq-ip