Introduction: Using an FPGA The Circuit Board Loading a Program (Option #1) Loading a Program (Option #2)

Loading a Program (Option #3) The File Transfer Utility Itself General Notes (Sharing your Work) Questions?

One of the topics presented on the More Cool Stuff page is the concept of constructing a physical version of the DIY Calculator. One way to do this would be to use a silicon chip called a Field Programmable Gate Array (FPGA). This is a component that can contain a large number of logic gates (hundreds of thousands or millions of gates depending on the particular device) along with other things such as blocks of memory.

The great thing about FPGAs is that the actual function they perform can be configured by the user in the field. The different FPGA vendors each have their own design tools and development boards, so we won’t go into that aspect of things here. Instead, we’ll simply assume that whoever is in charge of this project has access to an appropriate design environment and knows how to use it.

Now, let’s remind ourselves that our virtual DIY calculator is based on the concept of a simple microcomputer system. This system comprises a central processing unit (CPU), some RAM and ROM memory devices that are used for storing programs, and some input/output (I/O) ports that are used to communicate with the outside world.

The point is that we could program (configure) the FPGA to implement all facets of this simple microcomputer system as shown below:

Note that we would still have a lot of the FPGA’s resources left over to realize some more cunning stuff as we shall discuss.

Some types of FPGA need to be configured (programmed) only a single time and they will retain this configuration data for ever. Other types of FPGA need to be re-configured whenever power is first applied to the system (in this case their configuration data is typically stored in an external memory device and this data is automatically loaded when the board is first powered up). For the purposes of these discussions we are not really interested in the type of FPGA that is being used; instead we need only note that our FPGA will eventually be mounted on a circuit board. The other main items that would have to be mounted on this circuit board would be the calculator’s buttons and its display device(s):

There would also be an On/Off button, a connector to an external power supply, and so forth (these items haven’t been shown here so at to keep things simple). Also, we might decide to build a system clock on the circuit board, or we could use some of the spare logic in the FPGA to implement this function.

Even after we’ve constructed our circuit board and configured our FPGA as discussed above, there’s still something missing, which is the machine code program we wish to run on this physical version of the DIY Calculator.

Let’s quickly remind ourselves as to how things work in our virtual world. First of all we create a source code program in the DIY Calculator’s assembly language and store it in a *.asm file. Next, we use the assembler to translate this program into an equivalent *.ram machine code file. For example, let’s assume that we are assembling a file called test.asm:

So, in the case of the physical version of the DIY Calculator, one approach would be to hard-code this test.ram machine code program into the FPGA at the same time as we configure the rest of the device (we would actually load our machine code program into one or more of the memory blocks in the FPGA, where these memory blocks would represent the DIY Calculator’s RAM).

The advantage of this technique is that it’s relatively simple. On the other hand, there is a problem with this approach in that it won’t be easy to subsequently change the program. In fact, in order to make any modifications, we would have to completely reprogram the entire FPGA.

A somewhat more sophisticated approach to loading a program into the DIY Calculator would be to add some extra logic into the FPGA as shown below:

The idea here is to create a special File Transfer application that runs on your main computer as discussed later on this page. This application would read in the contents of a *.ram machine code file and squirt it out of one of the computer’s USB or serial interface ports. In turn, this port would be linked by a cable to a connector on the calculator board:

Meanwhile, when a new program is being downloaded into the physical DIY Calculator, a block of logic we might call the master controller (MC) will work in conjunction with some more logic we might call the interface (IF) block to halt the DIY Calculator and to load the new program into the DIY Calculators’ memory (once again, the machine code program would actually be loaded into one or more of the memory blocks in the FPGA, where these memory blocks would represent the DIY Calculator’s RAM).

The advantage of this technique is that we can now easily download new programs into the physical version of the DIY Calculator. The disadvantage is that the calculator will forget these programs whenever power is removed from the system. In turn, this means that whenever we power-up the calculator, the first thing we are going to have to do is to load a program into it, which would be something of a pain (we’ll address this in the following topic).

Note that there are several different ways in which the contents of the MC and IF (and DIY Calculator) blocks could be represented. One option is to describe them in a special Hardware Description Language (HDL) such as Verilog or VHDL, and then use special logic synthesis and place-and-route tools to translate these descriptions into the configuration data used to configure the FPGA. Another option would be to create a schematic (circuit diagram) of registers and logic gates and then use this to generate the configuration data.

Also note that in the case of a simple serial interface, whoever is creating this utility [you or us] would probably end up generating both the MC and IF blocks ourselves. By comparison, in the case of a USB interface (which is a bit “hairy” complexity-wise), one would probably use an existing intellectual property (IP) block provided by a third-party vendor who specializes in such things to implement the IF block.

This is very similar to the previous technique, except that when the physical version of the DIY Calculator is first powered on, as soon as the FPGA has been configured, the first thing the master controller (MC) block – in conjunction with a new FLASH memory controller (FC) block – does is to load a machine code program from an external FLASH memory device into the physical DIY Calculator's memory (as usual, the machine code program would actually be loaded into one or more of the memory blocks in the FPGA, where these memory blocks would represent the DIY Calculator’s RAM).

The two key points about FLASH memory are that (a) you can reprogram it if you wish and (b) it will retain its current contents even when power is removed from the system.

So, once again, the idea here is to create a special File Transfer application that runs on your main computer as discussed in the following topic. This application would read in the contents of a *.ram machine code file and squirt it out of one of the computer’s USB or serial interface ports. In turn, this port would be linked by a cable to a connector on the calculator board:

In this case, when this new program is being downloaded to the physical DIY Calculator, the master controller (MC) will work in conjunction with the interface (IF) block and the FLASH memory controller (FC) block to halt the DIY Calculator and to load the new program both into the external F LASH memory and into the DIY Calculators’ memory. In this latter case, the machine code program would, as usual, actually be loaded into one or more of the memory blocks in the FPGA, where these memory blocks would represent the DIY Calculator’s RAM.

Note that an alternative approach would be for the master controller block to load the new program only into the external FLASH memory, and to then cause a soft-power-up sequence in which the FPGA reconfigured itself; as part of this sequence it would re-load the machine code program from the FLASH memory into the DIY Calculator’s memory.

The advantage of both of these approaches is that we can easily download new programs into the physical version of the DIY Calculator and these programs will persist even when power is removed from the DIY Calculator.

OK, your mission (should you decide to accept it) is to create a the special File Transfer application that runs on your main computer. This application should allow you to browse your main computer’s hard disk to locate one of the DIY Calculator’s *.ram files (by default it should look in the C:\DIY Calculator\Work folder. The application should then allow you to squirt this machine code file out of one of your computer’s serial interface ports or (preferably) out of a USB port.

A couple of points to note are as follows:

a)	The File Transfer utility should “handshake” with the logic in the physical DIY Calculator’s FPGA to initiate the transfer and to confirm whether or not the program has been successfully downloaded and report this fact back to the user.
b)	The best thing you can do with this interface utility is to keep it as general as possible. For example, the DIY Calculator’s programs currently all start at address $4000, which is the first location in the DIY Calculator’s RAM. However, this might not always be the case, so it would probably be a good idea to commence the transmission by first sending the desired start address for the program.
c)	With regard to the previous points, a suggested sequence of events for when the user clicks the “Download” button would be for the File Transfer utility to: (i) handshake with the physical system to make sure that it’s connected and ready to receive data, (ii) transmit the 2-byte start address of the program, (iii) transmit a 2-byte value representing the total number of bytes in the program, (iv) transmit the program itself, (v) transmit a 2-byte cyclic redundancy check (CRC) value for error-checking purposes, (vi) handshake with the physical system to check that it successfully received the program, and (vii) report back to the user.

1)	If you do decide to create a File Transfer utility as described here, we’re sure that other users would be very interested in seeing it and using it. We would be very happy to make such a tool available via the DIY Calculator website (giving full credit to you, of course).
2)	The format of the DIY Calculator’s *.ram files is fully documented under the File Formats topic on the More Tools page.
3)	Note that the ideas presented here are just a few thoughts that have popped into our minds during the course of writing How Computers Do Math. If you think of any other considerations we should note regarding our proposed File Transfer utility, email us as described on the About/Contact Us page on the main DIY Calculator website and we will add them to the list so that they are there should we (or someone else) decide to actually create such a tool.

There are always a lot of points to ponder before embarking on a new software development quest. We’ve had a head-start, because we’ve been pondering furiously for a long time. Thus, if you are interested in creating a File Transfer utility and want to bounce some ideas around, please feel free to drop us a line as described on the About/Contact Us page on the main DIY Calculator website.