State machine with stack to implement "subroutines"

Interesting, and not at all crazy, but not new either.

Something similar was commonly done in the controller state machines used to manage bit-slice microprocessors (vintage

Of course, if you push this idea much further you'll find your "state register" slowly but surely mutating into a "program counter", and the procedures that implement each state's activity will become "instructions", and .... oh, how about that, I seem to have a programmable processor here....

Seriously though... the tradeoffs that give rise to a spectrum of controller organizations, from pure hardware state machine through to pure general purpose processor, are very interesting. For any given problem, there are sure to be many possible styles of solution with different benefits and drawbacks. Even more interesting, for me at least, is the fascinating social spectrum that mirrors this spectrum of design paradigms - with JavaScript programmers somewhere near one end, and soldering-iron users at the other.

Thanks

Jonathan wisely avoids suggesting which social group is uppermost!

As he says, the idea is not new. Many such techniques were developed when they were necessary (long before hardware became fast enough and cheap enough to allow a choice).

To solve a few specific problems, it doesn't usually make economic sense to invent a new programming language and write a compiler for it. Similarly, it doesn't usually make economic sense to invent a new processor (even a simple one like that described) to save logic elements in a few specific cases. It's fun and heroic, but usually takes too long to be economic.

Mike

Hi

I've just received a Sparkfun Spartan 3E Development Board,

I can use the Xilinx parallel port JTAG cable to program the FPGA but I can't figure out how to program the SPI PROM. This PROM, an Atmel AT45DB), has an SPI interface but does not have a JTAG one. You have to do some magic in the Spartan to add the SPI PROM as part of the JTAG chain.

Does anyone know how to do this? How can I use Impact to program an SPI PROM that does not have a JTAG interface?

thanks Bob Smith

Hi Bob,

Xilinx have a sample project for their S3E starter kit to program an SPI flash chip using a picoblaze processor:

Targets a "STMicro M25P16 SPI Flash" found on the S3e kit. (Not sure how compatible it is with the AT45DB, but would expect them to be fairly similar)

The design itself would be fairly easy to adapt to the Sparkfun board.

Red

Bob

The SPI and JTAG chain can share a header with some switchover of signals, or be entirely seperate as you will see in most of our products. The same 14 way cable(Xilinx pinout) is used for programming. In the IMPACT part of ISE there are seperate menu options for for boundary scan(JTAG) and SPI. When using SPI it is advisable to assert signal Prog_b low (if available) to avoid potential drive conflicts on the SPI.

There is supposed to be some JTAG programming of the SPI coming and this I believe works by loading a temporary design into the FPGA to allow access to the SPI I/O and thence waggling appropriately. There is a Xilinx answer on this and when it will become available. A link is on out Darnaw1 product page if you can't find it.

John Adair Enterpoint Ltd.- Home of Drigmorn1. The low cost FPGA Starter Board.

You can also do this with some software which will control the JTAG boundry scan register of the FPGA to toggle the pins connectes to the SPI PROM to generate a given programming sequence.

Petter

Push the idea one stage further, so that the instructions themselves can suspend to stack and resume operations, and things get even more interesting. Then instructions don't have to be trivial sequential operations, because you don't have to throw away their state and restart them, e.g. to service an interrupt or page fault.

"message send" instructions make compilation for OO programming very simple, hiding the details of searching a hierarchy of method tables.

Or for example, iterator instructions, e.g. to search an entire array, or other "high level" operations can become a seamless part of the instruction set. (Which may be interesting if you have ever pondered how to integrate something like a hardware search engine or FFT processor into software cleanly).

Or an instruction capable of walking a compiler's parse tree, executing whatever code it found at each node, for a halfway house between interpretation and compilation...

In 1980s terms, this was called "closing the semantic gap" (between the level at which people could most productively program, and the machine level).

Nowadays, of course, there IS no semantic gap, because people are taught to program in C or C++.

It makes me shudder to see so many fundamentally unnecessary layers of crud like pure abstract virtual base classes and templates piled on top of the basic simplicity of OO programming.

It doesn't even make things more efficient. The above message send, in C++, does result in a lengthy sequential search of the chain of method tables to find the correct method; while the "message send" instruction hits a cache and could usually be out in six cycles, even in a 1980s first-attempt technology demonstrator.

And common cases suffered much less penalty. "Send Integer +" can obviously add two integers. But in parallel, it can type check them both; and commence the message send process, and either: commit the sum, or continue the message send process, according to the type check results...

We have come such a long way since then.

(incidentally there's not much information online about the Linn Rekursiv, or its language Lingo, and much of that is pretty misleading)

- Brian

Thanks for posting your code. If you like your style and the design fits and makes timing, go ahead and use it. I agree that almost any description is better than one huge case statement.

There are two ways I know to use procedural code targeting programmable logic.

One way is to make an HDL description of a custom processor to "reduce" the problem to assembly language programming. This seems to be the default academic track found in textbooks. In this style, I would design a hardware processor to execute a custom instruction set. The downside, as Jonathan points out, is that before I can work on solving my problem, I must first designing a custom description language and hardware to run it.

The other way is to use a sequential HDL process to describe all of the clocked register updates by making use of variables, functions and procedures. This style uses the HDL itself as a virtual cpu to describe the cycle by cycle updates to the registers In this method, a simulator is used to debug code by tracing variable values and looking at waveforms. The advantage to this style is that the hdl "instructions" execute in zero time. The real hardware limits are found by static timing, and the design trade-off is pipeline ticks vs Fmax.

-- Mike Treseler