xesscorp / xula

Everything to do with the XuLA FPGA board: schematics, layout, firmware, example FPGA designs, documentation, etc.

XuLA FPGA Board Repository

Where you'll find everything XuLA-related!

This repo integrates everything for the XuLA FPGA board into one place:

pcb/:

Here's where you'll find the schematic and PCB layout stored as Eagle 5 files.

fmw/:

This contains the firmware for the microcontroller that manages the XuLA USB interface.

boot/:

This is the boot code that manages the reflashing of the uC firmware over the USB link.

user/:

This is the code that runs during normal operations of the XuLA board. It manages the interface between the FPGA and the USB link.

FPGA/:

Some example FPGA designs for the XuLA are stored in here. (You can find others in the StickIt! repository under the subdirectories for the modules they support.)

docs/:

Look in here for the source of the XuLA manual and other supporting documentation.

misc/:

This is a random, grab-bag of stuff.

xula's Issues

XuLA board (completely Linux based source tree completed), and question about XSUSB PIC18F firmware as related to XuLA boards firmwares

Hello.

I'd like to ask, to @devbisme, the creator of such wonderful utilities and board designs: is there any means you could share here the codebase for the XSUSB firmware (i.e., the 'user' and 'boot' portions for the PIC18F4455 interfacing uC between the USB and LPT ports) ?

It would be so great to have it for me to analyze/ recompile in Ubuntu MPLAB-X, which I just did with the XuLA-2 firmware, included in this repo. But most importantly, I need the PIC source to be able to debug appropriately what might be going on with my personal "port" of XSTOOLS to the 64-bit Ubuntu realm and toolchain/s...

My purpose is to find means to analyze trouble I am having with my squeaky clean, GCC 5+, Ubuntu/Debian cleanly and smoothly "makeable", modern Autotools compatible tree of the XSTOOLS source I've painstakingly derived in recent weeks from the Windows XSTOOLS.

The code of these "clean port to modern 64bit Ubuntu" of XSTOOLS works allright except that: it seems it can't get to program the 'xessjtag.svf' successfully upon the XC9572XL CPLD via the PIC, e.g. via 'xstest' when an attached XSA-3S1000 has the CPLD witout the "<5>!" signature yet, or just lost it.

The capabilities, port initialization, reading of CPLD previous USERCODE after flashing the '.svf' on Windows environment (which works), and all that works for this Ubuntu "port". It's just the new '.svf' writting phase that is breaking, and I don't know why. In Windows this step works smoothly, on Linux it doesn't somehow...

To sum up:

1. I've got a squeaky clean, Autotools-compliant, modern 64bit Ubuntu/ Debian source tree of XSTOOLS working for me (except the support for XSUSB)
2. XSUSB utils e.g. like 'xstest' work all good if we try to flash 'xessjtag.svf' on CPLD of XSA-3S1000 via de XSUSB, in Windows system.
3. I've tried to "port" / recode the 'xsusb' alongside my code in point 1) above, but doesn't work. If the CPLD was just flashed in Windows, then the Linux port for 'xstest' reads good the '<5>!' signature, but if it was not there to begin with, the Ubuntu/ Linux code is unable to write the '.svf' (same exact .svf) via LIBUSB.
4. All other LIBUSB calls and stuff seem to work great (e.g. it reads the signature when it's there, things like that), so it's not the issue some people refer to when comparing e.g. LIUSB 1.x vs. LIBUSB 0.x, difference which is known to be a PITA for some Linux environments.

Thank you for all insight you all can give me about this.

Regards from Spain

Quartus ii 13.1 web edition failed to compile the coding

My project aims to use the DE1 SoC FPGA board for obstacle and these are the components used:
i. ultrasonic sensor
ii. TRDB LTM LCD
iii. TRDB D5M
when compiling the coding, i got this error
why?