I can’t seem to delete the top module in lucid and create a new one in verilog. Why isnt this possible. I dont want to use lucid
Labs V2 is a Lucid IDE with limited Verilog support.
If you’re planning to go the full Verilog route, you should likely just use Vivado directly and the Alchitry Loader (or reflash the FTDI to work directly in Vivado).
Note that if you want to start from any of the templates, you can make a project in Alchitry Labs, build it, and the build folder is a Vivado project. You can copy this somewhere else and use it as a starting point.
Is Labs V2 going to gain Verilog support any time soon?
Using the new boards with Verilog would be refreshing from Vivados blinding color palette. As far as i can see, it should not be that hard to just allow a Verilog top module, and maybe a Verilog project template.
If you don’t like the Vivado’s code editor, I read it’s possible to bind it Visual Studio Code, then you can add Verilog support with an extension.
But you will still have to use Vivado to run the builds or write a custom launch.json to control Vivado’s build from VS Code.
You may still have to open Vivado once in a while for advanced settings or debugging, and if you want to use IP generator or GUI for piping your modules together, but at least you can do all the coding in the much more eye-friendly VS Code 
There is even a support plugin for Lucid syntax, but no Labs automation (yet?).
Yeah, I read about that too, but for some reason could not get it to work, and it seems quite annoying to have 2 windows open for just one board. The reason i asked about Labs is because no matter what I did, I could not find a way to change Vivados color palette. I Have limited access to the colors, and am only able to change stuff like the schematic window, log panel, messages panel, etc. but not anything else, like the text editor. Having Labs is such a nice design experience, building with one click of a button, flash and ram, etc. The only problem is V2’s limited support of Verilog or VHDL. I would rather use those two, as they are industry standard. Thank you for your reply, but again, I am at a crossroads. On one side there is Vivado, in which I can either blind myself, or manage 2 windows at once, both of which are annoying, and on the other, Labs, in which i have to use some workarounds instead of having a Verilog top module. I will say, having to wire Verilog with Lucid is very annoying, but more doable than Vivado. Once again, thank you for your reply, but Vivado is a pain to work with.
I really appreciate you like Alchitry Labs. I started writing it because of my mutual hatred for Vivado as an IDE.
I can’t say it’ll be “soon” but I do want to add better Verilog support. The issue is just that Verilog is such a vast language that properly supporting it is going to be a massive amount of work.
The biggest next step right now is getting a simplified grammar.
If you take a look at the Lucid grammar the entire file is just 158 lines.
The Verilog grammar (from Antlr’s repo) on the other hand is split into a 457 line lexer and a 1939 lines parser.
This could be simplified a lot since the Verilog grammar seems to be trying to do a lot of error checking in it (constant expressions and basic expressions are split). The Lucid grammar was written pretty promiscuously with the idea that the rest of the code would do the more contextual error checks. This is better since the error messages are more meaningful (eg. “this expression must be a constant” instead of “failed to match token type ____ expected _____, ___, …”
The current Verilog support only looks at a tiny subset of what that grammar provides to attempt to build out the module interface. It’s not hard to break it with anything complicated.
Alchitry Labs V1 plays fast and loose with basically everything while V2 builds up an internal model of the HDL that makes it much more robust. I don’t want to just slap Verilog in there hastily and have it be spaghetti internally.
OK, thank you, glad to see that we both hate Vivado. I would seriously take days off of my projects just to see if I could change the colors. Thanks for Labs, though. Alchitry is not really an Arduino, only useful for small and not too complicated projects. I can wait for better Verilog support.
I totally agree that Vivado’s is pretty slow and his code editor is pretty basic.
I initially started to play around with Labs and Lucid, but since one of my goals is to learn Verilog, I had to give Vivado a try, and yes, the code editor is lacking many basic feature that we could except for a modern tool.
Because of this, I looked around toward VS Code, since I already used it with the excellent PlatformIO extension for microcontroller programming.
I found many basic Verilog language support extensions and the pretty good and much more complete Sigasi one.
It’s free for private use so I gave it a try and it’s pretty complete with code completion, many refactor tool, and a strong code analysis that gives very useful advises tips and tools that helps a lot for learning.
And because it runs inside VS Code, you get everything that the IDE itself provides such as source control, etc.
It’s only a (very good) language support extension, it does not allow to remote-control Vivado, but I managed to write a simple launch.json that allows me to run a synthetization or a full build with a press on F5
I even found a (basic) Lucid language support extension 
All of this made me wonder, wouldn’t it save some development workload to have Labs actually developed as a VS Code extension instead of a dedicated editor?
End users can even choose the 100% open-source variants VS Codium or OpenVSCode without any worry since the extensions API are exactly the same.
1 Like
Hello there,
So I’m trying this Vivado->Compile->Alchitry Loader approach for learning more Verilog while working with a Cu-based devboard, and I’m having issues getting started, considering the ICE40HX is a Lattice-based FPGA and not a Xilinx-based one; when I go to click Synthesis within Vivado, the compilation runs for a decent amount of time, but it ultimately fails as it says:
[Common 17-345] A valid license was not found for feature 'Synthesis' and/or device 'xc7vx485t'. Please run the Vivado License Manager for assistance in determining
which features and devices are licensed for your system.
Resolution: Check the status of your licenses in the Vivado License Manager. For debug help search Xilinx Support for "Licensing FAQ". If you are using a license server, verify that the license server is up and running a version of the xilinx daemon that is compatible with the version of Xilinx software that you are using. Note: Vivado 2021.1 and later versions require upgrading your license server tools to the Flex 11.17.2.0 versions. Please confirm with your license admin that the correct version of the license server tools are installed.
This is after I moved the initial, build-produced Vivado-compatible sources and constraints from the Alchitry Labs project directory to the Vivado project directory. I also moved the generated TCL script from AL to Vivado, and changed the associated directory structure within said file in order to reflect the migration change, then executed this script within Vivado’s TCL console. Doing this just seems to generate a copy of the same *.sv/.xdf sources that I moved into the Vivado project in the first place.
Additional questions:
- In Cu via Lucid, we’re expected to use different HDL syntax to access the dip switch signals due to having to implement a faked pull-down scheme. How would this be handled in straight Verilog, if it’s still a functional concern?
- The Lucid source tutorial for the IO shield has us write a line or two in order to hook up the RST button/line to one or more given LED-associated output signals from the device. In the generated Vivado-compatible *.sv file, this assignment/operation does not seem to appear within the file (or its associated reset_conditioner module) at all. I’m confused! I’m sure there’s other tutorials out there on Verilog for connecting a button signal to an output pin but I wanted to make sure there aren’t more board/translation-specific quirks to be wary of here…
Any tips?
Hi,
You can’t use Vivado with the Cu.
You need either Lattice IceCube2 or the open-source toolchain (IceStorm + Yosys) instead.
Yeah I was going to say the same thing but I thought maybe he did something.