ISSUE OF CONNECTIVITY TO MINIMIZE OR ELIMINATE BRIDGE USE
The Terasic DE10-Nano board I am using has a wealth of connections and devices on the board, but those devices are connected to just one of the two sides of the System on Chip (SoC) Cyclone-V integrated circuit. Some are on one side, some are on the other.
Aspects of my design are best done on one side or the other. For example, the detailed hardware interaction with the IBM 1130 disk controller is best done in the Field Programmable Gate Array (FPGA) side while the user interactions to select virtual 2315 disk cartridges are best done under Linux on the Hard Processor System (HPS) side.
Maintaining a screen buffer and driving an LCD screen is much easier in software, thus on the HPS side, but some screens are driven by parallel I/O pins that are only wired to the FPGA side of this board. Serial interfaces such as SPI, I2C and UART are wired to the HPS side.
It is possible to access connections on the other side, but one has to make use of the bridges between sides such as HPS2FPGA, FPGA2HPS and HPS2FPGA-Lightweight which adds asynchrony, delays and complication compared to using a connection from the side where it is terminated. I therefore looked to locate my signals and external devices on the appropriate side of the SoC to minimize or even eliminate the bridge traffic.
NEED SIGNAL FROM 1130 TO HPS SIDE FOR HEAD LOADED STATUS
Almost every signal between the IBM 1130 disk controller and my board should be connected to the logic in the FPGA. There is one signal, however, that should also be visible to the HPS side. This is the HeadLoaded signal, which goes on when the drive is spun up, thus go ready to do input-output, and turns off when the drive is switched off to remove the physical cartridge.
My design has the HPS side application control whether the FPGA logic is activating the drive modeling (signal drive_ram) or is available to load and unload virtual cartridge images. A command from HPS is sent when we see the HeadLoaded signal go on to tell the FPGA to begin emulating the disk drive.
At the end of a session using a virtual cartridge on the disk drive, the user turns off the drive motor and our HeadLoaded signal goes off. At this time our SoC board contains the image of that cartridge which may have had data written or changed from the version when it was first loaded. Thus, our HPS side must perform an unload operation over the bridge with the FPGA to return the updated cartridge image to the file sitting on the SD Card. In order to do an unload, we must turn off drive_ram by a command from the HPS.
From a safety standpoint, the FPGA will also see the HeadLoaded signal so that it can stop handling reads or writes, thus it too can switch the drive_ram signal off. In order to keep the HPS and FPGA sides in sync, I have added commands to HPS which can ask the FPGA for the current value of drive_ram so that we can be sure both sides have it turned off when the disk is spun down.
There is one pin on the HPS side, located in the Linear Technologies Corporation (LTC) header, that is labeled GPIO. However upon investigation of the schematics of the DE10-Nano board I see that this pin is used to switch that LTC connection between the SPI and the I2C serial links that are hosted on it. Thus, it would interfere with the link as its value changes.
I did find one pushbutton on the board that is wired to the HPS side, named the HPS User Key. This button pulls down a line to ground when the button is activated. For my purposes, I can connect the HeadLoaded signal to the high side of the button. When the drive is not spinning with heads loaded, this will be at ground and the HPS will believe our pushbutton is depressed. When the drive is ready, it appears that the button is not depressed. The pushbutton is is therefore in parallel with our HeadLoaded signal, either can activate the line pulling it down to ground.
SCREEN AND OTHER UI ELEMENTS SHOULD ONLY CONNECT TO HPS SIDE
The lack of general purpose I/O pins on the HPS side requires me to find a means of connecting the user interface devices by one of the methods available there. I could use serial connections over the UART but that would require a separate terminal or computer running a terminal emulator. The LTC connector features I2C and SPI connectivity, although not simultaneously over its standard 2x7 connector.
I found a 3.5" LCD display that operates over SPI, which is a good size for use inside the IBM 1130. A user will swing open a side door and see the control box for this Virtual 2315 Cartridge facility, select from among all the disk cartridge image files that are located on the SD Card hosted on the DE10-Nano board and see the state of load and unload operations for files that were selected.
DIGGING THROUGH POORLY DOCUMENTED LCD MODULE
The documentation for this module, similar to all the hobbyist modules that come with great features at a low price from China, is very sparse. The module is intended for use with a Raspberry Pi Pico board, allowing that board to plug onto the back of the module. It offers the LCD, a touch interface, plus an SD Card reader and an on-board nonvolatile RAM to save parameters.
It is advertised as an SPI interfaced module, which would mean three wires plus select lines for each device on the module. I would have expected seven wires, but there are additional lines present. There is no overall guide written for this, only a Wiki entry with some datasheets for the included chips on the module and for the LCD panel along with a few demo programs intended for use on Raspberry Pi Pico.
I do have schematics and the individual datasheets, from which I pieced together answers about all the signal lines I see wired to the Pico socket. One confusing item is that the SD Card can be accessed with either SPI or I2C protocols, based on a header pin setting on the module. In I2C mode there are six signals which I can safely ignore, both because I would use only SPI and more importantly because I don't intend to use the SD Card on this module. I will ignore the NVRAM as well.
Thus, I only need the SPI link signals SCLK, MOSI, and MISO for the actual communications. One signal selects the LCD device and another selects the Touch interface atop the screen. That leaves just four more signals, power and ground that I have to account for.
One signal is used to turn the backlight of the LCD on and off. It will be hardwired on. One wire resets the LCD to a known state, which I will wire to my overall power-on-reset signal by routing it out of the FPGA side on an I/O pin where I will wire it to the LCD module reset. Two more signals are more interesting - Touch Interrupt which should be used to tell the HPS that we have a touch on the screen, an d LCD Data/Command which tells the LCD whether the SPI stream is a command or data for pixels.
Alas, that means I need another general purpose IO pin from the HPS side in order to properly inform the LCD module of the type of SPI stream it will receive. I made use of HPS User Key as an input, but now I needed to find an available output I could drive.
While there are devices on the HPS side we are not using, such as the UART or the G-force sensor, two issues complicate using them. First, they do not have external connections (the UART is converted to RS232 voltage levels through an FT232R chip). Second, these are controlled by Linux device drivers that I would have to modify in order to manipulate any of the signals.
The one remaining signal, which is an output, that I could conceivable use is the HPS LED signal, a user controlled LED. It does not have an external connector but I could desolder the 330 ohm resistor between the signal line and LED, then solder a wire onto the FPGA side of that resistor. I am not thrilled by having to tack solder two different wires to the DE10-Nano board but if it resolves a ton of extra work then I may have to accept this approach.
Using the touch feature of the module would dictate that I connect the interrupt line from the module to the HPS system somehow and use it to alert my application that the user has made a touch.
C libraries to control the LCD panel are available, originally used in Arduino and Raspberry Pi environments, that I should be able to modify slightly to run under the HPS Linux and manage my LCD module.
RETHINKING 1130 TO SOC BOARD ELECTRICAL CONNECTIVITY DESIGN
The nature of the SLT logic gates to which my FPGA will interface is that they are connected through diodes to an in internal pullup inside the gate. Thus, I don't have to source any voltage or current to output a logical 1. Sinking voltage to ground through the diode is how we output a logical 0. Thus it will be best fed by an open collector gate which either pulls to ground or does nothing.
My present interface board uses mosfet bidirectional level shifters, which would (uselessly) shift the FGPA output of 3.3 down to 3.0 (SLT level). In fact, an SLT gate won't care if it sees 3.3V on its input since it is isolated by the diode whose breakdown voltage is way way higher.
SLT gate outputs have a collector pull up resistor to bring the output up near 3V when the output should be high and it sinks down to ground when the output is low. Thus the bidirectional level shifter is still useful here as the FPGA input needs to hit its minimum high voltage to sense a valid high state.
 |
| Typical SLT NAND gate |
NEW PCB NEEDED FOR INTERFACE BETWEEN 1130 AND BOARD
I will design a new interface board that will simply route my outputs to the SLT gates directly. Alternatively I could put in a transistor inverter in open collector mode, but I don't think that is necessary. The PCB will reserve the mounting pads for this so that if I experimentally determine the need I can adjust the existing board easily.
Fewer of the level shifters are needed, since I have only a few outputs from my FPGA to the SLT logic. My design also changed in that I did have some circuits running to a 5V Arduino which is no longer part of the project. This should be an easy change to make to the KiCAD files and get these out to the foundry in advance of needing them.
No comments:
Post a Comment