After a year of waiting, it’s time for ORCONF. If you are not familiar with ORCONF, then allow me to encourage you to examine their web-page, and look over the abstracts of the presentations that will be given this year. Looks like it will be quite the lineup.

This year, I’ll be giving two presentations.

My first presentation will be a quick update on the ZipCPU. Since last year, the ZipCPU has been updated so as to support …

  • 8-bit byte-level access across the 32-bit bus.

    Prior to this redesign, the ZipCPU was one of a few rare 32-bit byte machines.

    Now, the ZipCPU fully supports 8-bit bytes instead of the 32-bit bytes it supported before.

    This required a bit of instruction set redesign. Opcodes were re-ordered. Rotate left ROL and population count POPC instructions have been removed. The load and store instructions have been renamed load word LW and store word SW instructions. Four basic instructions have been added as well: load half-word LH, store halfword SH, load byte LB and store byte SB.

  • A compressed instruction set (CIS).

    The ZipCPU has always had a CIS, although it was previously mis-named as a Very Long Instruction Word (VLIW) set of instructions–which it never really was. The CIS instruction set allows you to integrate pairs of 16-bit instructions together with the 32-bit instructions. It provides some increased code density as a result.

    Over the last year, I’ve had the opportunity to test the CIS instructions on the ZipCPU and work out the bugs within them. The current toolchain builds with CIS instructions enabled by default.

  • Nearly the same number of LUTs

    Despite all of these changes, the number of LUTs used by the ZipCPU remains roughly the same.

As a result of these changes, the newlib C-library now runs on the ZipCPU–something it didn’t do before. That means you can now play 4x4x4 Tic-Tac-Toe on the ZipCPU!

My second presentation will be an overview of AutoFPGA. Here’s the abstract:

Placing a CPU into a new environment can be a daunting task. Components need to be selected, resources allocated, addresses given, interrupts assigned, and peripherals configured–not only in the HDL code, but also for all of the software support. The problem with this approach to designing hardware is that it works very well for one-off solutions, but not as well for quickly creating generic solutions to new problems. This is where AutoFPGA comes in.

Given a set of components, AutoFPGA builds the boiler plate files, the top level and main design files, the Wishbone interconnect, and the software header files necessary for software support within that design. As a result, I can reconfigure a project with new hardware in a matter of minutes, rather than the days it took before.

When I get back, I’ll post about my experiences and thoughts. When the presentation video’s are posted on youtube, I intend to post those links here as well.