Skip navigation

Here is the new release 0.0r of XXICC.  I've been horrifically busy with work and family obligations over the last two years so I wasn't able to keep up with XXICC.  Also, 0.0r is a major release since it adds integer nets and operators to GCHD, and can now program Lattice iCE40 FPGAs using the open-source IceStorm tools.  So there was lots of testing and documentation updates.


XXICC (21st Century Co-design) is a not-for-profit research project which attempts to bring digital hardware/software co-design into the 21st Century using an improved programming language and a Reduced Software Complexity philosophy.  Its goal is to make it easier and more enjoyable to write and maintain digital hardware and software. XXICC is pronounced "Chicken Coop", so-called because it has so many layers.


For an overview of XXICC, see XXICC: 21st Century Co-design.  For details on the GalaxC programming language, XXICC Object Editor, and GalaxC extensions for Hardware Design (GCHD), here are the latest documents and source code:


Release notes for XXICC rev 0.0r

Programming in the GalaxC Language rev 0.0r: reference and user guide for the GalaxC programming language.

The XXICC Anthology rev 0.0r : collection of miscellaneous XXICC topics, including user guides for the XXICC Object Editor, GCHD, Flavia, and IceStorm.

XXICC code release 0.0r : source code for XXICC.

XXICC source code listing rev 0.0r: source code listing as PDF.

XXICC executable binary for Windows rev 0.0r : XXICC executable binary for Microsoft Windows.

GalaxC sample/demo programs rev 0.0r: sample GalaxC programs and GCHD logic libraries.

GalaxC sample/demo program listings rev 0.0r: PDF listing of the sample GalaxC programs and GCHD examples.

Installing and Running XXICC rev 0.0q: Document describing how to install and run XXICC, unchanged for 0.0r.

Compiling and Running GalaxC Programs rev 0.0k: Document describing how to compile and run your own GalaxC programs, unchanged for 0.0r.

Editable XXICC documentation files rev 0.0r: editable XOE files for XXICC documentation.

GCHD examples for IceStorm rev 0.0r: these are for generating Lattice iCE40 FPGAs using IceStorm, using either a Lattice iCEstick or Nandland Go Board as the target.

Data files for FlaviaP40 release 0.0r for Papilio One 250K: Data files for the FlaviaP40 implementation of the Free Logic Array.

Data files for FlaviaP60 release 0.0r for Papilio One 500K: Data files for the FlaviaP60 implementation of the Free Logic Array.

Data files for FlaviaPD59 release 0.0r: Data files for the FlaviaPD59 implementation of the Free Logic Array for Papilio DUO.

Data files for FlaviaLP60 release 0.0r for LOGI-Pi: Data files for the FlaviaLP60 implementation of the Free Logic Array for the ValentF(x) LOGI-Pi.

Data files for FlaviaLB60 release 0.0r for LOGI-Bone: Data files for the FlaviaLB60 implementation of the Free Logic Array for the ValentF(x) LOGI-Bone.

Taming the Wild Bitstream (unchanged for 0.0r): Supplement to Flavia: the Free Logic Array.


I've tested XXICC 0.0r on GNU/Linux (Ubuntu on x86 PCs and ODROID-C1 Ubuntu).  I haven't tested it yet on Raspberry Pi Raspbian or BeagleBone Debian.  I tested it on Windows 2000 and 7.  My main machine is Ubuntu, so the others are more likely to have anomalies.  Constructive comments and suggestions are most welcome.  I'd especially like to find out how to reproduce some of the bugs that have been eluding me.


The previous version of XXICC is: XXICC (21st Century Co-design) release 0.0q

The earliest versions of XXICC are at Google Code:


XXICC is a FLOSS (Free as in Liberty Open Source Software) project.  Software is licensed under GPLv3 and other content is licensed under Creative Commons CC-BY-SA 3.0.

Ive been recently using an M74HC590 binary counter to capture some data from an opto-encoder and thought that since I'd modelled a basic binary counter into the FPGA, why don't I go the whole hog and model this real world component into it too and make a final blog post in this series.


Here's the front page and the pinout  in the datasheet for the M74HC590 that I'll be modelling:












So we know what the inputs and outputs are of the device are but what about the way it functions internally? Well I looked through the datasheet and found a truth table that I could work things out from.





Using this data, I made up the following Verilog file:













As you can see Ive copied the pin labels etc.. and used nested if's to do most of the logic.



























Once were happy with the Verilog file, we generate the board symbol shown here. Theres the corresponding input pins and the output pins QA throught to QG are shown as a single wire representing the 8bit output bus.






In the following schematic, Ive added the symbol for the Verilog file and made some connections to it:






The CCKEN and G pins have been connected to an internal Ground and CCLR has been connecting to an internal voltage source (VCC). These could have been broken out to real pins on the DE0-NANO P0082 board and connected manually but I did it this way for simplicity.


The RCK and CCK pins have both been connected to a push button on the development board.


The QA - QG outputs have all been connected to the LED's on the development board and the RCO pin has been left unconnected for the time being. This output would be connected to another 8-bit counter if they were being cascaded into a 16-bit counter.




From here it was just a case of assigning the LED's and pushbutton to the correct pins and the device is ready to test. The video at the bottom of this shows the final programmed development board. Because the CCK and RCK pins were attached to a push button, simply pressing that button causes the device to count up press by press.


Heres the compiler summary for the above component, very few of the actual resources were used (in most cases less than 1%):





Hopefully this gives an insight into how fpga's can be utilised by modelling existing components that we already know, this is the final blog post in this mini-series but I will be posting occasional updates of my progress on an rgb led matrix driver that Im working towards with the DE0-NANO. I intend to cheat a little bit to start with and initialise some registers with a test pattern while I work out how to drive the signal properly. Once that's done I can work backwards into a more complex design.






So far the DE0-NANO P0082 development board and the associated user guides have given me a basic overview on how to develop with FPGA's and introduced me to a simple Verilog HDL file. To move forwards in FPGA development I would need to learn more about Verilog HDL and while Terasic have done a great job creating resources that teaches the basics of development I wouldn't expect them to provide me with a full Verilog HDL learning resource and so I looked elsewhere.


The first resource I found on Google was at and so I spent some time looking through their tutorials and examples, as with most new things I'm learning I find it useful to learn the basics and take a few days break. When I come back to the subject I find myself more able to understand what I'd learn previously and also learn more as I go.


After having a few days break, I decided to alter the files for the bitstream I made in Part 3 of this blog series. My intention was to create an 8-bit counter that displays on the LED's and the ability to change the direction of counting when one of the user buttons are pressed. Here is my new board layout :




In the board layout you can see I kept the pll to provide the clock source, the simple_counter module now has an additional button input and Ive removed the multiplexer, choosing to output 8 bits from the counter bus straight to LED's.


Before we look at the Verilog file for the simple_counter component lets investigate that counter bus a little bit more in depth. The counter bus is a single trace here but its representing a 32 bit bus with 32 wires, so here we've connected wires 18,19,20,21,22,23,24 and 25 to LED's and left the others disconnected. Its possible to connect a consistent range of 8 wires from anywhere in this bus and the LED's will still show an 8 bit counter.


Whats really going on is that simple_counter actually outputs as a 32-bit counter on that bus and were selecting a range, if we select a range of 0,1,2,3,4,5,6 and 7 the counter will be running so fast as thats where the least significant bits are that we won't see the LED's change (they'll just appear constantly on) and if we select the range 24,25,26,27,28,29,30 and 31 the LED's will count too slowly this is because as we move up the range the speed of the bits changing becomes less frequent.


It's entirely possible to just get the simple_counter component to output an 8-bit bus rather than a 32-bit one and alter the pll to change its counting speed to one that would be more suitable but I just left this one in for well, who knows why I left it in, it was just there already I suppose!


Right lets look at the new Verlog HDL file:




I added an extra button input and a new register component. Registers are similar to variables only you declare the size in bits you would like that register to be. So reg [31:0] is like a 32 bit variable and reg[0:0] is a single bit which Im using here like a Boolean to keep track of the direction.


You'll notice a new section titled "initial begin" this is a place you can initialise the values of the registers at the beginning of the bitstream launching/simulating.


Notice that there's 2 "always" blocks. These are functions that run automatically when their conditions are met. so the statements in the "always @ (posedge BUTTON_1)" block between "begin" and "end" will run automatically whenever a new positive edge is detected on the button (ie. whenever the button is pressed or goes high).


Multiple "always" statements are allowed in a component and can all run simultaneously.


and thats it for today, see the video below to see this in action



Filter Blog

By date: By tag: