Archive for June, 2007

On the nature of hardware (FPGA) input and output

Monday, June 25th, 2007

Many people who have exclusively worked with software bring their software notions of input and output to FPGA land and get frustrated with the development software. VHDL and Verilog are not languages suitable for programming in a software style unless you are only interested in simulation, as opposed to implementation.

Some folks are implementing ESL (electronic system level) languages for software types who won’t or can’t get their minds to think in terms of hardware. The tools require far more work to get decent results, because of the greater mismatch between hardware and software. As a result, these relatively new commercial products are currently very expensive.

In hardware, inputs and outputs are connections. They are not operations! Just think of any audio/video setup. The tuners and players have output connectors; the consoles, amplifiers, and other equipment (such as equalizers and mixers) have both input and output connectors; speakers and video monitors have input connectors. You use cables, which are basically bunches of wires, to connect inputs to outputs. The system will work with older analog systems, as well as with newer digital systems. In other words, the whole notion of executing input and output instructions is not needed. Going digital does not change this property of hardware.

When power is on and connections are established, there is no such thing as no input or no output. In a combinatorial (i.e., unclocked) circuit, the circuit reacts immediately to changes in the input. It also changes its outputs immediately. In a clocked circuit, a clock signal is used to “sample” or “capture” the input, and to “change” the output. Some digital outputs can also be set to a “high impedance” state, which is logically a “disconnect”. This last state is important for creating bidirectional I/O on FPGA’s.

Bootstrapping Lisp – accessing print names

Tuesday, June 5th, 2007

I’ve relented, and have attached print name strings to the atom. The format of an atom can be described as (atom-mark print-name-string). The cdr field of an atom was reserved for holding a property list. We have thus placed the print name string as the first item on this list. This is not in traditional property list form, which uses a linearized series of property-value pairs. The new atom format makes it possible to write a print function at the highest coding level. The atoms for true, false, and the byte atoms will not have print names (cdr = nil).

The new atom format eliminates the searching done in printb, and now the processing time for the read-list-write-list program is almost all due to the read-list routine, readb. After that, removing character and string construction from the initialization code reduced the amount of data handled by the self read program. The combination creates a self read program that completes in 1/4th the time as before the attachment of print names to the atom node.

Further optimization – reducing the parsing to a single phase – did not yield very much increase in speed. This suggests the slow speed is mostly due to symbol table searches.