enso:
Ken Chapman is one of my heroes. If you've not downloaded his "Know your priorities" white paper, and are working in VHDL/Verilog and FPGAs, you should do so.
I've been aware of the KCPSM, i.e. PicoBlaze, for a very long time. It is an out growth of work done by Xilinx in various techniques for improving signal processing applications of the XC4000/XC4000XL FPGA families of the mid to late 90's. The issue has always been the programming of Ken's Programmable State Machine (PSM). A further issue with Ken's PicoBlaze is that its instruction set and architecture is fixed. In many ways it resembles the Microchip PIC line of microcontrollers. As it stands, the PicoBlaze is a more like a ROM-based microcomputer than a programmable state machine. Being a microcontroller, a lot of the design and implementation work has been done. It is particularly impressive that the core implementation can be handled in a small number of slices.
For my work, I have extended the programmable state machine concept espoused by Ken, but my focus is on machines where the architecture is not predefined but is instead determined by the application. Instead of designing a fixed architecture for the state machine, I have instead chosen to use a microprogram controller/sequencer as the basis of my programmable state machines. I have placed an example of a modified version of the
Fairchild F9408 Microprogram Controller in my
MAM65C02 GitHUB repository. I do tend to use the F9408 Microprogram Controller (MPC) because it provides most of the basic functions required for sequencing, branching (unconditional, conditional, and multi-way), and also supports micro-subroutines. I have used another microprogram controller for building deeep FIFOs in Spartan-II block RAMs for UARTs after I ran out of FPGA resources using distributed RAM FIFOs. The controller, designed and developed by me, does not include a sequencer (program counter) function, and instead uses a simple next address field and a priority encoder to move from state to state.
In my recent work, I have used that microprogram controller to build Ethernet interfaces that implement several IP protocol stack elements, a hydraulic motor control system for 68 HP Vickers motors, a USB interface engine for an industrial print head controller, and many other state machines Also included in this list is the Verilog MAM65C02 implementation of the WDC65C02 that Windfall recently used for his ACORN add-on board project.
Like Ken Chapman, I lacked a programming tool for doing the development of complex state machines. The USB interface controller (Cypress FX-2 controller coupled to an FPGA-based image and printhead controller) mentioned above was completed before I had developed such a programming tool. Although it only required 128 states, it was extremely tedious to implement manually using manually edited HDL case statements. Since then I have developed a programming tool suitable for PSM's a la Ken Chapman. An executable of that programming tool, which I used to develop the MAM65C02, is found in this GitHUB public repository:
MAM65C02 Utilities. The readme.md file included there provides enough information regarding the Simple Microprogram ROM Tool (SMRTool) that you should be able to see how the microprogram for the MAM65C02 is used to implement the Execution Unit of that microprocessor. You'll also find an example of how the tool is used to create an instruction decoder ROM for the MAM65C02; a totally unrelated function. (The microprogram is sufficiently readable and understandable such that Windfall was able to find and correct an error in the first upload of the MAM65C02. And he did it without the benefit of the SMRTool because I had not yet pushed it to GitHUB. That's impressive, what a hoss.)
I lead a small team of HW designers, and they are now using a common state machine architecture based on another modified F9408. We are using the approach to implement FPGA-based I/O cards that respond directly to UDP/IP datagrams. The level of complexity of these state machines is on the order of 2k - 3k states, and several of these state machines are operating concurrently in each FPGA. Each electronics assembly uses between 4 and 6 circuit cards, each with a single FPGA. The number of lines of code that these designs are eliminating is very high, and the corresponding savings in SW life-cycle support costs are just staggering.
The algorithms previously implemented in SW have not changed in a decade or more, and the logic families in the current I/O cards are all obsolete. Hence the redesign of the HW in a processor-free manner using microprogrammed state machines. I avoid using the term programmable or reprogrammable state machines, although that capability is naturally included, because the first thing that outside observers would like to do is to place the project into the SW domain. In my world, HW is concrete, immutable, well tested/simulated. SW uses a state machine (instruction set processor) to implement an abstract model not directly supported by the state machine (instruction set processor), and due to various factors, is generally not well tested/simulated. From that stems the problems that most SW-based systems encounter when dealing with real world asynchronous events: interrupts, resource sharing, etc.
Login
Register
FAQ
Search
