0

I recently asked some questions for an application in hope to gain more clarity on how to accomplish an emulation of an input device peripheral (in my case an input mouse) in simulation. Following several attempts of debugging and simulation I actually accomplished a simulation of this peripheral. I am faced with with a question of feasibility. The controller is a design that will run on my FPGA board. The actual peripheral runs alongside the board but externally connected. At present the mouse does not reach proper state to communicate movement data to the FPGA.

I have considered that if I make the peripheral run inside the FPGA by making it as close to the scenario as possible I can figure out why I can not get the mouse to initialize properly outside.

I do not have internal specifications of the actual mouse so I created my own description as best and as close to a PS/2 mouse as I could. I got the simulation to display mouse packets received by the controller on the simulation waveform.

I have refrained from posting the RTL code because it might add too much unnecessary information but if relevant parts are needed I can post them.

Questions

Is this approach of bringing the mouse closer to the design on chip by somehow mimicking behavior of the mouse feasible?

If so, can it be accomplished preserving the bidirectional nature of communication somehow on an FPGA?

Vahe
  • 171
  • 1
  • 11
  • 1
    *"Is this approach ... feasible?"* - sure, why not? You have basically created a simulated mouse. But since you have a real mouse readily available, I am not sure why would you need a simulated one. *"If so, can it be accomplished preserving the bidirectional nature of communication somehow on an FPGA?"* - what does that mean? Your simulated mouse can simulate bidirectional communication, if it is designed to do so. – Eugene Sh. Jan 16 '23 at 20:18
  • While the mouse is externally connected, I fail to initialize, and so I want a way to see why this is happening? The design consists of a software running code to initialize the mouse. What I don't see is data coming back in proper order from the peripheral. How do I allow the bidirectional behavior preserved on chip as I was only aware of in or out signal flow inside the FPGA. That is what my feasibility question is asking. As to if it is possible, how do I accomplish a such a channel on chip. Or do I need to separate inputs from outputs on each block? – Vahe Jan 16 '23 at 20:25
  • In you "mission" design, you have a top-level entity (lets call it U) with bi-directional ports, that are supposed connect to the mouse, right? You map these to physical pins of the FPGA. If you want to implement a simulated mouse instead, you implement it as a separate entity with it's own inputs and outputs (call it M). So now you will have two entities - U and M. Now you create a top-level "testbench", where you instantiate and interconnect U with M. The connections are *internal* to the FPGA. You could split-route them to the FPGA pins though, if you want to monitor the signals externally. – Eugene Sh. Jan 16 '23 at 20:31
  • Eugene, thank you for the updated information, I do not yet have familiarity with a split route approach but it seems to clarify my doubts. Based on my setup and what I have described, can you confirm that it is possible to keep the mission module (U) with the respective inout signals present so that when it connects to a separate module (M) once again on the fpga, that resides separate from this module? Module U and Module M are inside the FPGA but still have the inout ports on their module definition. Is this at all possible? Can inouts reside between modules residing on the FPGA? – Vahe Jan 16 '23 at 20:42
  • I realize I might be conjuring up something not doable, but my imagination is running a little high recently. Thanks for your help. – Vahe Jan 16 '23 at 20:45

1 Answers1

1

If this is your final design:

schematic

simulate this circuit – Schematic created using CircuitLab For this you would have your top module defined something like

module U
(
    input        a_in,
    output       b_out
);

This is your simulation setup:

schematic

simulate this circuit

For this you will create you simulated mouse module M similar to this:

module M
(
    input        b_in,
    output       a_out
);

and the top-level test module, which will instantiate and interconnect the above two sub-modules:

module test
(
    output test_a,
    output test_b
);

    wire a;
    wire b;

    U u_inst( .a_in(a), .b_out(b) );
    M m_inst( .a_out(a), .b_in(b) );

    // Optionally rout the signals outside the top module to fpga pins 
    // for monitoring
    assign test_a = a;
    assign test_b = b;
endmodule
Eugene Sh.
  • 9,986
  • 2
  • 26
  • 41
  • Thank you Eugene, I really appreciate the graphical depiction of the response. – Vahe Jan 16 '23 at 22:13
  • The only caveat is that in my case those two pins are actually declared as inouts on both sides. I was thinking of actually physically corresponding pins from the fpga so that the pin a of the M module would connect to pin a of the M module and pin b of the U module would connect to the pin b of M module of. Is this safe, do I need external resistors to accomplish this loop back connection and if so would I avoid any issues to the FPGA as far as potential risk of damage? – Vahe Jan 16 '23 at 22:50
  • 1
    @Vahe that means you have used a tri-state buffer primitive to convert inout to in+out+out, correct? To my limited knowledge, FPGA synthesizers can't deal with inout internally - only at the pins - and you must have connected it to one of these buffers? Then consider taking the in+out+out and connecting those to the simulation instead of the inout – user253751 Jan 17 '23 at 11:29
  • @user253751, I actually did do that after creating the necessary tristate declarations at the top most wrapper module, clock, and data from the mouse now loop back to clock and data to the system module but only in simulation, it is painfully slow and might take many hours to reach necessary initialization state. If I do this loopback connection in hardware do I need series resistors? I just want to make sure there is no current surge if I create this loop, I suspect not. usually in IC's like FPGA's if an IO pin is looped back to another IO pin with just a wire, and no resistor is it ok? – Vahe Jan 17 '23 at 14:33
  • By the way, the IO on the edge of the FPGA does get used, and the design does successfully synthesize, as well as place and route, I have yet to load a bitstream on the FPGA but before I try to run this successfully I need to connect the 4 loop back connections (2 clock, 2 data) - i.e 2 wires total, outside the board so that the loopback connection is created. I just don't know if I need current limiting resistors for this connection or is that properly managed already. I use a FMC-CE expansion board with a 6 pin header (4 are GPIO) to serve as the access point to create the loopback. – Vahe Jan 17 '23 at 14:44
  • 1
    Consider that an inout pin is just a pin that switches between in and out. "Current limiting" is not concern unless you switch them both to output at the same time, and output different values. If you think you will do that, accidentally, then may as well put the resistors. Depending on your FPGA type and I/O standard, it's possible that it doesn't need resistors as the current is already limited, but may as well not rely on that. – user253751 Jan 17 '23 at 15:02
  • On second consideration, I might need pullup resistors but am unsure because the PS/2 protocol has clock and data lines at high when not transmitting. I am still simulating to check if this would be the case. – Vahe Jan 17 '23 at 16:10
  • I think the PULLTYPE property is what I need as opposed to inserting a physical pullup resistor. https://docs.xilinx.com/r/en-US/ug912-vivado-properties/PULLUP – Vahe Jan 17 '23 at 16:43