Feature Set

This section presents the features needed to use a spreadsheet as a high level language to program FPGAs. For each feature there may be one or more problems to overcome.

Save Formats
The spreadsheet should be able to run the program interactively for debugging and then be able to export the program as a C or Python program for faster execution on a computer. The spreadsheet should also be able to export the program as a Verilog module to be compiled for an FPGA.

Debugging
The spreadsheet should have the ability to single step, to run for a fixed number of steps, or to run until reaching a breakpoint.
The spreadsheet should be able to write a trace file of cell values versus time. The file format should be that used by gtkwave so that gtkwave can be used as the viewer.

Register Sizes
The user should have the ability to set the bit width of each cell in the spreadsheet. The upper bits are lost if an arithmetic operation exceeds the bit width.

Initial/Reset Values
The user should have the ability to set the reset or initial value for each cell in the spreadsheet. When saved as Verilog the program should have both a RESET line as well as an INITIAL clause.

Synchronous Updates
Spreadsheets normally recompute the cells going from top to bottom. This can make programming tricky since the programmer would have allow for a value to change immediately prior to use. A spreadsheet for state machines should store the new values for cells separately from the current values. A separate pass througth the sheet copies the new values to the visible values making the whole update look synchronous.

Comments
Documenting a design is critical to the success of a programming language. The spreadsheet should allow the definition of a block of cells such that a comment or description can be added to describe that block. Block can be nested so that the highest level might describe the program as a whole and the lowest level might describe the operation of a single cell.
Comments should be carried into all of the save file formats.
A problem is to decide how to allow the user to view comments at different levels of granularity.

Host Interface
The spreadsheet should have the ability to do file IO as it interacts with the host operating system. This may be how the spreadsheet simulates the system with known, test inputs. A problem to solve is how to make file IO transparent when saving as Verilog.

Primitives
Besides the usual arithmetic and logical operations the spreadsheet should include primitives to allow for RAM read and write, for stack pushes and pops, and for user defined low leverl operations.

Linking
Each pages of a spreadsheet might contain a complete design. For example, there might be a page with a VGA interface, one for a PS2 interface, and one for a SD card interface. The spreadsheet should allow other design pages to be linked to the current page. A problem is how to provide this linkage in a uniform way.

Virtual Logic
Newer FPGAs allow the possibility of reloading just part of the FPGA with new logic. Just as Von Neumann computers have virtual memory and page faults, so might an FPGA have virtual logic and page faults. The idea is that a set of logic surrounds a page and a page fault occurs when a pin going to another pages changes state. An operating system should detect the page fault, stop the running page, load the new page, link the wires/pins between them, and then release both pages to continue running.
Virtual logic is not part of the current effort.

Operating System
An operating system manages contention for shared resources in the system. The use of virtual logic requires an operating system of some kind to manage the pages of physical FPGA logic. This operating system could itself be implemented as logic and so reside entirely in the FPGA. This might allow much faster responses to page faults.
An FPGA operating system is not part of the current effort.