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.zipno 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.
What is Verilog?
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.
VGA-text controller (05/05/2001readme 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
http://www.xess.com - Xess's homepage
http://www.verilog.com - Learn about Verilog
< © 2001 firstname.lastname@example.org >