Expose IO DDR register from top level of hm2 about mksocfpga HOT 4 OPEN

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]

from mksocfpga.

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.

from mksocfpga.

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.

from mksocfpga.

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

from mksocfpga.