Blog Post Actions
Group Actions
Engagement
Author: johnbeetem
Date Created:
Views: 363
Likes: 3
Comments: 10
Related
Recommended

XXICC (21st Century Co-design) release 0.0r

johnbeetem

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: https://code.google.com/archive/p/xxicc/

 

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.

Anonymous
  • in reply to groventov

    Reynel --

     

    Thank you for the compliment.  It's nice to know that people are actually looking at XXICC.

     

    XXICC is on the back burner.  I was within a month or two of a major new release at the end of 2017.  Then 2018 dropped a bunch of family obligations on me, which are only now starting to subside.  One of the non-XXICC activities was moving from California to Colorado, and there are a bunch of house projects that I need to complete before winter.  So there are still a couple months before I can get back to XXICC.  Task 1 will be figuring out where I was at the end of 2017.  When you get back a project after a long break, it can be difficult to remember whether a feature was implemented, partially implemented, or just conceived and not implemented at all

     

    Meanwhile, Catalin Baetoniu's The Art of FPGA Design series is doing an excellent job of pointing out why new users are daunted by the steep learning curve of standard languages like VHDL

  • What happend to this marvelous project. No activity since one year ago!!!

  • No activity for more than one year. What happened to XXICC?

  • in reply to violet

    There's a nice concise description of the difference between blocking (=) and non-blocking (<=) assignment at Nandland.com: https://www.nandland.com/articles/blocking-nonblocking-verilog.html

     

    Basically, in an "always" block the blocking assignment (=) gives you combinational logic while the non-blocking assignment (<=) gives you sequential (clocked) logic.  It's awful nomenclature IMO.  Why not call them "combinational assignment" and "clocked assignment"?

     

    When I write Verilog, I use "always" blocks exclusively for clocked logic and all the assignments in them use '<='.  I put all my combinational logic in "assign y = expr" statements or as part of a "wire" declaration: "wire x = expr".

  • in reply to violet

    lucie tozer wrote:

     

    Its definitely a good idea to produce a language/compiler which feels more comfortable to work with. My recent escapades in Verilog proves so, as a basic example I was using multiple [always @] blocks to perform seperate tasks but later found out that wire/reg types could only be modified in 1[always @]block. This led me to re-writing the entire thing to work around the compilers constraints.

    Hi Lucie,

     

    I've not actually done much Verilog, but I have done a tonne of VHDL. Designing FPGA based hardware was my job for many years. I think what you are seeing here is because when writing HDL, you need to think about the physical hardware and how what you write will infer different pieces of available hardware and how they are connected rather than thinking of it as just like software where (multi threading aside) everything happens sequentially. If you have the same signal driven out of different registered blocks you are effectively trying to connect the Q output of two or more D types together which you wouldn't try to do if you were wiring physical devices on a breadboard. I think once you get your head round that and try to think a little more about the underlying hardware you are trying to target then it'll all become a lot easier.

     

    Best Regards,


    Rachael