Is VS Code integration something that is being looked into in terms of supporting an IDE? It already has a bunch of great features, and platforms such as PlatformIO have made great use of it for something that is cross platform and runs great. This might free up some time from IDE support to specific features which would be great!

If this is not something that is/will be considered, I would be interested in implementing something similar since that is what I always use, and I am slow to adopt new IDEs.

Is there a projected time frame for when on board SRAM is going to be supported? I have no problem writing support, but I would like to know I am not re-implementing something that is almost done, or already done by the board supporters!

Currently the only way that I can think of to utilize simulations, for Lucid or Verilog, is to either, import the transpiled (or native) Verilog code into Vivado, then write my test bench there for simulation purposes. This is sorta clunky, but the simulations are very useful for more complex designs. 

Is there any future plans to implement some sort of simulation process into Alchitry Labs, or is this going to be the normal process?

Background:
While trying to build the demo project for the CU using the 1.0.3 version of the Alchitry IDE and IceStorm, I had found the same .sdc constraint issue later mentioned by kitlaan in the General Questions forum.  Seeing that the IDE was looking to arachne-pnr instead of nextpnr, and that nextpnr had a qt GUI dependency that I didn't want to deal with, falling back to ICEcube2 looked to be the solution.  ICEcube2 did not seem to recognize the free license.

The system in question here is a Fedora 28 64bit, though it does apply to other distributions as well.


Problem found:
ICEcube2 want's it's license bound to the MAC address of the network device eth0 when on Linux.

Some modern Linux systems name the network interfaces based upon the slot, or more accurately which data bus it connects to the CPU through, such as enp5s2.  This is great on server systems with multiple wired interfaces, as the kernel could swap the interface that eth0 and eth1 were bound to under some circumstances otherwise.  However useful this may be, it doesn't really serve much purpose on systems with one interface.


Solution found:
Adding two parameters ( net.ifnames=0 biosdevname=0 ) to the kernel boot command as per this StackExchange article solved the problem.


Extra notes:
Comments in the article also mention it working for versions of CentOS and Ubuntu.

If the system was set up with a static IP address in it's network settings, then that will have to be configured again as well.
Also check firewall configuration if the system has rules based on interface names.

If the system does not have a standard wired interface at all, then other methods may be necessary.  Renaming an interface using udev rules instead for example.

On the Fedora system running Gnome desktop, for some reason I was unable to lock the screen after applying this fix.  The dconf setting for org.gnome.desktop.lockdown disable-lock-screen had toggled to true for unknown reasons and needed set back.  This change didn't make sense and may have been coincidental.

Hi,
I was hoping that somebody (probably at Alchitry) might feel like writing a short tutorial about how to use Structs and Globals.
I feel like they could help simplify my designs, but I am honestly at a loss for how to use them. 

I bought Justin's book (see cheesy photo), and that was a great help when I was just starting with my first projects, but the sections on structs and globals have just left me confused.

For instance, how "global" really is a globally defined struct? 
Can I define it in one module, then make an instance of it in another module, and assign members to different things like a dff?
Can I even have multiple instances of the same struct? 
Is that question even meaningful? 
Does a struct either have to be wholly an input or wholly an output?
If something is a global (like a struct), why would I bother putting it in a module port list as an input or output, since I should just be able to refer to it from anywhere. ???

I have read the relevant sections multiple times, and attempted to just figure out structs/globals out by trial and error, but honestly, I'm just confused as hell.

I'll keep spreading the good word about Alchitry/Lucid regardless, but any help would be greatly appreciated. 

Using Alchitry Labs 1.0.3 on Linux using the ubuntu-provided IceStorm packages (fpga-icestorm et al).

I had the IDE create a new Lucid "Cu IO Element Demo" project and built it.

It fails with:

Whenever I attempt to build a project that I'm working on, I get the following error, and I'm unsure as to how to fix it:

I am currently working on a Mac OS machine and to access the Cu/Au board I am using a virtual machine running debian buster.

To get the loader to work I had to use the new one and install the udev rule (obviously, as documented), but this is not sufficient per-se.

Usually, once the VM is running I'm doing everything from the MacOS terminal by ssh-ing to the VM (to avoid to deal with the «GUI» of the VM). When doing this the loader does not work (or in a very chaotic way). In particular it would «see» the board only if it was plugged in during the boot, flashing would sometime stop and reset in the middle of the process… (I am sure it is not a «board problem» since they work perfectly well with a «real» debain buster machine).

Indeed there seems to be small compatibilities issues with vritualbox; so here are the workarounds I have found to get a working solution :

* Setting the VM to use the xHCI (USB3.0) controller (in the configuration->ports->USB)
* Opening a GUI session on the VM (even if not really using it)

With this on (the «proper» virtual USB controller, and the session being opened) I can use the loader (indeed even within my ssh session rather than the «local session within the VM»).

These indeed seems to me more problems from virtual-box than from the Alchitry software, but I guess some other might be trying to using a similar technique to work on a Mac (or other unsupported OS).

Hope this will help.

Hi,
in the schematic I can see, that two pins of the ICE40 are connected as RxD and TxD to the FTDI chip. Is this a serial interface to communicate the FPGA?
If yes: how do I connect to on PC side? The FTDI did not appear as /dev/tty* device on my Linux machine.

-RRC

For other users using the ancient 32-bit processor architecture the software package is not executable directly as it is only compiled for 64-bit computers. Fortunately it is possible to emulate such a processor with qemu-x86_64 contained by the qemu-user package in the Debian distribution. I was successfully able to upload a bitstream to my Alchitry Cu by executing