Verilog stuff

I posted a *preliminary* version (as in incomplete) of an XSOC-hosted keyboard/video BIOS. I've been working on this in my spare time for the past month. The keyboard BIOS reads scancodes from the XS40's PS/2 port (keyboard only, not mouse.) Scancodes need to be converted to ASCII chars, which is what the 'kbbios' is for. The video BIOS is a minimal set of functions for drawing alphanumeric characters to a virtual screen. The video BIOS emulates a text display, and has functions for scrolling, writing characters, and setting the screen width and height. To run the XSOC demo, you'll need a 128KB XS40 v1.4+ board (either the 05XL+ or 10XL+.) The demo will not run on the original 32KB XS40 boards, sorry :(

The package contains a demo XSOC program to show simultaneously show the new keyboard and text stuff. It doesn't do much - just echos keypresses on the VGA output.

As distributed, the included software library can't be recompiled. You'll need a patched version of lcc-xr16 and xr16-asm to compile the library. These are available as a separate download. Oh and before I forget, your Xess board must be set to 25MHz (oscillator = div4.)

Finally, with the last of some stupid bugs fixed, I'm almost ready to post a basic XR16 text-display library.

In order to get this simple text-library working, I had to do more sidework than I originally expected. First, I needed to extend the XSOC system library (libxr16.c.) I added integer math functions for signed mutiply, divide, and modulus. I only used 16-bit integer versions, but the code can be easily converted to 32-bit math. In order to correctly compile my new library file, I was forced to modify the lcc-xr16 C-compiler. System library functions must save ALL CPU registers, something that lcc-xr16 normally will not do. Finally, I corrected "bitshift-calls," so the lcc-xr16 properly recognizes them as function calls. At each step of the way, I asked myself, "Wouldn't it be easier to just correct the compiler output by hand?" Well faster maybe, but not easier in the long run. I don't want to have to whip out the text-editor each and every time I recompile the system library file.

Returning to the reason behind all this backend work, the text-library, its tested configuration is a display grid is 70x28 chars (560x450 pixels.) The text-library draws 'characters' to a bitmap graphics display, from a table of font bitmaps. I captured the font bitmap from my RadeonLE VGA BIOS. Performance is dog-slow, but at least it works! I can print simple text messages to the screen.

Printing text messages to screen isn't that exciting, so I coded a simple PS/2-keyboard input reader. The reader captures raw byte scancodes. Additional firmware (C-software) routines translate the byte scancodes into ASCII character values (1 byte.) The translation process is very rough, recognizing only a small portion of the full PC/AT keyboard.

Taking a detour from hardware development, I downloaded XSOC's c-compiler, lcc-xr16. A text-controller isn't quite as useful without a minimal firmware library, and the c-compiler lets me write simple screen manipulation routines. The minimal set includes character/string write (with auto-wrap), scroll, and clear-screen routines. The prototype firmware doesn't access xs40_text10s; instead it targets the stock pixel graphics display. By targeting the original graphics display instead of the untested xs40_text10, I can focus on debugging 1 unknown system instead of simultaneously debugging 2.

Although the c-compiler drastically accelerates code-writing speed (versus hand-coded assembly), it's not without its own set of problems. As released, XSOC's software development system has a few potentially crippling bugs/limitations. First and foremost, the XSOC assembler only supports short branches. I encountered this limitation first, and patched it by turning short branches into 'far branches' recommended in the XSOC specification. Second, the LCC-compiler's parser has a few quirks. It expects a newline '\n' at the very end of each source file, and for some reason it didn't like code-comments under certain conditions.

Today I tracked down an insidious compiler limitation. The defect affects the compiler's translation of 'non-native' instructions. The XSOC lacks hardware multiply/divide/barrel-shift support, so the XSOC's compiler backend converts these operations into 'library calls.' The compiler emits a 'call _mulXXX' in place of the multiply-operation. The call then reaches a library-function, (which is compiled like regular C-code, by the LCC-compiler.) Unfortunately, because the conversion is already buried in the backend, the front-end of the LCC-compiler doesn't properly check for register saving/restoration. (At least that's what it looks like.) Not being an assembly guy, this limitation took me a while to track down. Basically I compiled the broken firmware routine over and over, incrementally changing the code (by 1 line) each iteration. Eventually, I pinpointed a code critical-point : the position of 1 line of code made the difference between a broken/working C-function. From here, I simply had to stare at the compiler-generated assembler-listing until I saw something.

Continuing with my efforts to integrate xs40_text10 with XSOC, I've come up with a revised memory access interface for the text controller. In the released version, both the text-screen (character-code) fetch and the font-bitmap fetch assume immediate memory loading. This means the controller assumes the data comes back from SRAM exactly 1T after the respective request. In the XSOC architecture, the SRAM serves multiple clients, forcing clients to 'wait their turn', so to speak.

The revised memory interface tolerates several latency cycles between initial request and final completion (data acknowledge), making it more compatible with XSOC. The interface is pretty weak, and tolerates only a few cycles of latency. I had to chose between higher latency tolerance and design complexity. Even though the full design isn't terribly complex, maintaining a sub-20ns cycle-time (>50MHz) is the dominating consideration.

This leaves the memory datapath as the final hardware integration obstacle. The XS40's SRAM bus width is 8-bits. XSOC's logical bus width is 16-bits - the system is clocked at half-speed to squeeze two 8-bit bus-cycles into one 16-bit bit CPU cycle. The text-controller datapath is 8-bits, where it's most effiicient because the font-bitmaps are exactly 8-bits wide. Increasing the controller datapath to 16-bits requires additional logic to store character-codes between text-screen fetches. A 16-bit datapath is also very 'wasteful' in terms of font-bitmap fetches, because each fetch returns only 50% useful information (the first 8-bits of the 16-bit fetch.)

v1.01 - Minor update to xs40_text10s. To save a bit of online space, the updated source distribution xs40_text10s.zip no longer contains the demo-files. On the plus side, the package now contains working Xilinx Foundation 2.1I project libraries (v1.00 was broken.) And of course, the whole thing was done in XSE 2.1i.

The birth of this page! As I devise more and more profound circuits, I'll put them here for everyone to see.

Version 1.0 of the 'vga text controller' has been released. This project originated from my attempt to demonstrate a simple monochrome text-display in an FPGA. The demo-files are designed to run on the Xess XS40 FPGA-boards, revision v1.4 or later. I used an XS40-010XL+ v1.4 for development.

On an unrelated note, back in October of last year, I ordered an Avnet Virtex Development Board for work. Like other commercial Xilinx FPGA-boards, the Avnet is programmed with the Xilinx parallel download cable, a $99 piece of plastic + wires from Xilinx. The kit includes one cable, but I wanted to experiment with the board at my home PC without lugging a cable between home and work. Cheapskate that I was, I modified the Xess's XSTOOLs package to program the AVNET board through the Xess XS40's I/O pin-headers. I saved myself $100 cable, but wasted one morning stumbling through a bunch of hierarchical C++ code. The program-hack involved changing the pin-assignments, to remap them to unused XS40 pins. The XSLOAD program uses the slave-serial programming mode (CCLK, PROG, DIN) on Virtex and XC40xx BIT files. With this hack, I can program any Xilinx FPGA-board (Spartan2, Virtex, XC4000x) without having to buy the Xilinx cable. Of course, I didn't use the AVNET board at home beyond the first week, so I am left holding nothing but a program-hack with imaginary usefulness.

With revision v1.0 of the VGA-text controller finished, my next project will be integrating it with Jan Gray's XSOC. XSOC is a simple, RISC CPU design that fits on an XC4005XL (< 5000 logic gates!) With my text-controller's area-requirement at 35% of an XC4010XL, I hope to fit both on a single XC4010XL.

Verilog is a hardware description language useful for digital circuit design, modeling, and simulation. Verilog competes with VHDL, the hardware description language endorsed by the rest of the world, and the US Department of Defense.

The language syntax uses many constructs and operators familiar to computer programming langauges, like C. Of course, circuit modeling gives rise to constructs to capture hardware concepts, like registers and circuit delay.

Patch/bugfix for XSOC LCC-XR16 compiler, assembler, and library.

xr16fix1.zip - (v1 06/16/2001) binaries for xr16.exe and rcc-xr16.exe, source-code modifications

Text-display and keyboard 'firmware' for XSOC. Requires a 128KB XS40 v1.4 board! Set XS40 oscillator to "25.00 MHz" (divider=4.)

kvxsocp_01.zip - (v0.1 06/13/2001) demo files, partial source code, tested on XS40-010XL+ v1.4

VGA-text controller (05/05/2001 readme file)

Text-display controller for the Xess-XS40 v1.4. The controller generates (almost) standard VGA signals. The demo connects the Xess's PS/2 connector with a simple PS/2 port capture circuit. The capture circuit writes scancodes into the text screen area.

Two distributions are available :

xs40_text10.zip- (05/11/2001) Demo files only, no source code

xs40_text10s.zip - (05/11/2001) full source/schematic code, no demo files (contains current snapshot of the Xilinx Foundation 2.1i project)

http://www.fpgacpu.org - FPGA CPU architectures, a great site for hardware engineers interested in doing their own CPU-design. Get XSOC distribution here.

http://www.xess.com - Xess's homepage

http://www.verilog.com - Learn about Verilog

< © 2001 liaor@iname.com >