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?
1 Like
Hi,
You can’t use Vivado with the Cu.
You need either Lattice IceCube2 or the open-source toolchain (IceStorm + Yosys) instead.
1 Like
Yeah I was going to say the same thing but I thought maybe he did something.
1 Like
Yeah, makes sense - I thought so too but figured if the official support rep was suggesting it that I must’ve just overlooked some sort of custom config detail or something. Glad to know I’m not just lazy 
Yeah, it would have been a good idea for them to clarify the manufacturer tool-chains between the board offerings a bit better.
1 Like
Hey @MonoBunny what did you see that confused you? I’d love to make it more clear where possible.
We have our setup tutorial that goes over the tools needed for each board. Did you miss this or did you find something in it unclear?
To answer your other questions…
-
Unless you bought your boards a while ago, you don’t need to worry about this. See the big notice on this page for details. You can always see how something in Lucid is done by looking in the
builddirectory after building. There will be a source folder with system verilog files of your project.Here’s what the
fake_pull_downmodule looks like./* This file was generated automatically by Alchitry Labs 2.0.18-BETA. Do not edit this file directly. Instead edit the original Lucid source. This is a temporary file and any changes made to it will be destroyed. */ module fake_pull_down #( parameter SIZE = 1'h1 ) ( input wire clk, inout wire [(SIZE)-1:0] in, output reg [(SIZE)-1:0] out ); logic [3:0] D_flip_d, D_flip_q = 0; logic [(SIZE)-1:0] D_saved_d, D_saved_q = 0; logic [(SIZE)-1:0] IO_in; assign in = IO_in; always @* begin D_flip_d = D_flip_q; D_saved_d = D_saved_q; D_flip_d = D_flip_q + 1'h1; IO_in = D_flip_q ? {SIZE{1'bz}} : {SIZE{1'h0}}; if (D_flip_q > 2'h2) begin D_saved_d = in; end out = D_saved_q; end always @(posedge (clk)) begin D_flip_q <= D_flip_d; D_saved_q <= D_saved_d; end endmodule -
Did you build the project first? The build files are only updated when you click the hammer icon.
Yes, I’ve built the project during my initial practice tests with Lucid, no issues there.
A bigger issue I see at the moment is that it appears IceCube2 does not support importing SV files directly into their own program for edit/synthesis, and even attempting to convert those over to standard Verilog file-extensions afterwards seems to cause Synth errors (I’m guessing there are linked/compiled terms valid in SV that aren’t valid for V). This could be a problem for me, as it seems like the stock “Reset Conditioner” logic in-use on the Cu Lucid project template in order to ensure that the reset is sync’d is translated into this SV format along with the Top file as they get linked through the build process:
// alchitry_top.sv
localparam _MP_STAGES_1891378208 = 3'h4;
logic M_reset_cond_in;
logic M_reset_cond_out;
reset_conditioner #(
.STAGES(_MP_STAGES_1891378208)
) reset_cond (
.clk(clk),
.in(M_reset_cond_in),
.out(M_reset_cond_out)
);
and
// reset_conditioner.sv
module reset_conditioner #(
parameter STAGES = 3'h4
) (
input wire clk,
input wire in,
output reg out
);
logic [(STAGES)-1:0] D_stage_d, D_stage_q = {STAGES{1'h1}};
always @* begin
D_stage_d = D_stage_q;
D_stage_d = {D_stage_q[STAGES - 2'h2:1'h0], 1'h0};
out = D_stage_q[STAGES - 1'h1];
end
always @(posedge (clk)) begin
if ((in) == 1'b1) begin
D_stage_q <= {STAGES{1'h1}};
end else begin
D_stage_q <= D_stage_d;
end
end
endmodule
Additionally, IC2 makes use of SDC files, rather than XDC files. I’ve heard from some quick research that these files are likely “mostly” the same as one another, so I simply saved a copy of the original Lucid-generated constraints as SDCs instead, but wouldn’t be surprised if this turns out to be insufficient as well.
Also, to what extent are these TCL files required? Do I need to transfer the project.tcl file from Lucid to IC2 as well, or can that just be generated during Synthesis from build-to-build?
Did you select the Cu as your board in Alchitry Labs when you made the project? You won’t have xdc then but instead SDC and PCF.
iceCube2 definitely supports the subset of SystemVerilog used by Alchitry Labs but the GUI might be upset by the .sv suffix. You can edit it .v
The .tcl scripts are used to build the project. You might not need them if you’re using the GUI.
I did, and the Settings menu specifies “Cu Toolchain: Yosys (open source) [selected], IceCube2 (proprietary)”, so I know that’s how the project itself was configured. I also know I had selected the “IO Base” project template with it.
I just tried to build one more time in Alchitry Labs V2 and it’s definitely still producing XDCs, even though it’s been letting me successfully push to the Cu FPGA from the IDE the whole time.
Blockquote
iceCube2 definitely supports the subset of SystemVerilog used by Alchitry Labs but the GUI might be upset by the .sv suffix. You can edit it .v
As for this, I changed the extension, but when I attempt IC2 synthesis I get the following build errors:
Synopsys Verilog Compiler, version comp2016q3p1, Build 141R, built Dec 5 2016
@N|Running in 64-bit mode
Copyright (C) 1994-2016 Synopsys, Inc. All rights reserved. This Synopsys software and all associated documentation are proprietary to Synopsys, Inc. and may only be used pursuant to the terms and conditions of a written license agreement with Synopsys, Inc. All other use, reproduction, modification, or distribution of the Synopsys software or the associated documentation is strictly prohibited.
@I::"C:\lscc\iCEcube2.2020.12\synpbase\lib\generic\sb_ice40.v" (library work)
@I::"C:\lscc\iCEcube2.2020.12\synpbase\lib\vlog\hypermods.v" (library __hyper__lib__)
@I::"C:\lscc\iCEcube2.2020.12\synpbase\lib\vlog\umr_capim.v" (library snps_haps)
@I::"C:\lscc\iCEcube2.2020.12\synpbase\lib\vlog\scemi_objects.v" (library snps_haps)
@I::"C:\lscc\iCEcube2.2020.12\synpbase\lib\vlog\scemi_pipes.svh" (library snps_haps)
@I::"C:\Users\austi\OneDrive\Documents\alchitry_top.v" (library work)
@E: CG376 :"C:\Users\austi\OneDrive\Documents\alchitry_top.v":13:24:13:24|Expecting variable name
@I::"C:\Users\austi\OneDrive\Documents\reset_conditioner.v" (library work)
@E: CS187 :"C:\Users\austi\OneDrive\Documents\reset_conditioner.v":15:46:15:46|Expecting ,
@E: CS187 :"C:\Users\austi\OneDrive\Documents\reset_conditioner.v":31:0:31:8|Expecting endmodule
3 syntax errors
(I wish they gave more verbose error output)
My SV-built top file looks like the following:
/*
This file was generated automatically by Alchitry Labs 2.0.20-BETA.
Do not edit this file directly. Instead edit the original Lucid source.
This is a temporary file and any changes made to it will be destroyed.
*/
module alchitry_top (
input wire clk,
input wire rst_n,
output reg [7:0] led,
input wire usb_rx,
output reg usb_tx,
output reg [2:0][7:0] io_led,
output reg [7:0] io_segment,
output reg [3:0] io_select,
input wire [4:0] io_button,
input wire [2:0][7:0] io_dip
);
logic rst;
localparam _MP_STAGES_1891378208 = 3'h4;
logic M_reset_cond_in;
logic M_reset_cond_out;
reset_conditioner #(
.STAGES(_MP_STAGES_1891378208)
) reset_cond (
.clk(clk),
.in(M_reset_cond_in),
.out(M_reset_cond_out)
);
always @* begin
M_reset_cond_in = ~rst_n;
rst = M_reset_cond_out;
led = 8'h0;
usb_tx = usb_rx;
io_led = {{8'h0, 8'h0, 8'h0}};
io_segment = 8'hff;
io_select = 4'hf;
end
endmodule
and my (generated) SV for reset_conditioner:
/*
This file was generated automatically by Alchitry Labs 2.0.20-BETA.
Do not edit this file directly. Instead edit the original Lucid source.
This is a temporary file and any changes made to it will be destroyed.
*/
module reset_conditioner #(
parameter STAGES = 3'h4
) (
input wire clk,
input wire in,
output reg out
);
logic [(STAGES)-1:0] D_stage_d, D_stage_q = {STAGES{1'h1}};
always @* begin
D_stage_d = D_stage_q;
D_stage_d = {D_stage_q[STAGES - 2'h2:1'h0], 1'h0};
out = D_stage_q[STAGES - 1'h1];
end
always @(posedge (clk)) begin
if ((in) == 1'b1) begin
D_stage_q <= {STAGES{1'h1}};
end else begin
D_stage_q <= D_stage_d;
end
end
endmodule
Ok, I think I have at least some progress - I suppose IceCube2 has to be explicitly selected from within Alchitry Labs V2 as Selected Toolchain in order for the appropriate PCF/SDC constraints to be generated.
As for the verilog, will have to do more checking to see if this resolved that issue as well. Will report back.
Yeah, still seeing syntax errors on the SV->V side of things - running the Lucid build generator from Labs V2 w/ IC2 toolchain selected seems to work, but if I try to synthesize the V-converted files from directly within IC2 itself, syntax errors appear to break the process:
Copyright (C) 1992-2014 Lattice Semiconductor Corporation. All rights reserved.
==contents of Cu_Arcade_Custom_IC_Prototypes_Implmnt/Cu_Arcade_Custom_IC_Prototypes.srr
#Build: Synplify Pro L-2016.09L+ice40, Build 077R, Dec 2 2016
#install: C:\lscc\iCEcube2.2020.12\synpbase
#OS: Windows 8 6.2
#Hostname: DESKTOP-N5QBFD1
# Mon Dec 09 14:13:32 2024
#Implementation: Cu_Arcade_Custom_IC_Prototypes_Implmnt
Synopsys HDL Compiler, version comp2016q3p1, Build 141R, built Dec 5 2016
@N|Running in 64-bit mode
Copyright (C) 1994-2016 Synopsys, Inc. All rights reserved. This Synopsys software and all associated documentation are proprietary to Synopsys, Inc. and may only be used pursuant to the terms and conditions of a written license agreement with Synopsys, Inc. All other use, reproduction, modification, or distribution of the Synopsys software or the associated documentation is strictly prohibited.
Synopsys Verilog Compiler, version comp2016q3p1, Build 141R, built Dec 5 2016
@N|Running in 64-bit mode
Copyright (C) 1994-2016 Synopsys, Inc. All rights reserved. This Synopsys software and all associated documentation are proprietary to Synopsys, Inc. and may only be used pursuant to the terms and conditions of a written license agreement with Synopsys, Inc. All other use, reproduction, modification, or distribution of the Synopsys software or the associated documentation is strictly prohibited.
@I::"C:\lscc\iCEcube2.2020.12\synpbase\lib\generic\sb_ice40.v" (library work)
@I::"C:\lscc\iCEcube2.2020.12\synpbase\lib\vlog\hypermods.v" (library __hyper__lib__)
@I::"C:\lscc\iCEcube2.2020.12\synpbase\lib\vlog\umr_capim.v" (library snps_haps)
@I::"C:\lscc\iCEcube2.2020.12\synpbase\lib\vlog\scemi_objects.v" (library snps_haps)
@I::"C:\lscc\iCEcube2.2020.12\synpbase\lib\vlog\scemi_pipes.svh" (library snps_haps)
@I::"C:\Users\austi\OneDrive\Documents\Cu_LatticeICE40_Custom_ArcadeBoard_IC_Prototyping\alchitry_top.v" (library work)
@E: CG376 :"C:\Users\austi\OneDrive\Documents\Cu_LatticeICE40_Custom_ArcadeBoard_IC_Prototyping\alchitry_top.v":13:24:13:24|Expecting variable name
@I::"C:\Users\austi\OneDrive\Documents\Cu_LatticeICE40_Custom_ArcadeBoard_IC_Prototyping\counter.v" (library work)
@E: CS187 :"C:\Users\austi\OneDrive\Documents\Cu_LatticeICE40_Custom_ArcadeBoard_IC_Prototyping\counter.v":20:46:20:46|Expecting ,
@E: CG431 :"C:\Users\austi\OneDrive\Documents\Cu_LatticeICE40_Custom_ArcadeBoard_IC_Prototyping\counter.v":36:42:36:43|Expecting radix character (one of b, o, h, or d) or unsized single bit literal (one of '1, '0, 'x, 'z)
@E: CS187 :"C:\Users\austi\OneDrive\Documents\Cu_LatticeICE40_Custom_ArcadeBoard_IC_Prototyping\counter.v":48:0:48:8|Expecting endmodule
@I::"C:\Users\austi\OneDrive\Documents\Cu_LatticeICE40_Custom_ArcadeBoard_IC_Prototyping\decoder.v" (library work)
@I::"C:\Users\austi\OneDrive\Documents\Cu_LatticeICE40_Custom_ArcadeBoard_IC_Prototyping\fake_pull_down.v" (library work)
@E: CS187 :"C:\Users\austi\OneDrive\Documents\Cu_LatticeICE40_Custom_ArcadeBoard_IC_Prototyping\fake_pull_down.v":15:35:15:35|Expecting ,
@E: CS187 :"C:\Users\austi\OneDrive\Documents\Cu_LatticeICE40_Custom_ArcadeBoard_IC_Prototyping\fake_pull_down.v":39:0:39:8|Expecting endmodule
@I::"C:\Users\austi\OneDrive\Documents\Cu_LatticeICE40_Custom_ArcadeBoard_IC_Prototyping\fake_pull_down_2d.v" (library work)
@E: CG496 :"C:\Users\austi\OneDrive\Documents\Cu_LatticeICE40_Custom_ArcadeBoard_IC_Prototyping\fake_pull_down_2d.v":12:32:12:32|Expecting valid net type or name
@I::"C:\Users\austi\OneDrive\Documents\Cu_LatticeICE40_Custom_ArcadeBoard_IC_Prototyping\reset_conditioner.v" (library work)
@E: CS187 :"C:\Users\austi\OneDrive\Documents\Cu_LatticeICE40_Custom_ArcadeBoard_IC_Prototyping\reset_conditioner.v":15:46:15:46|Expecting ,
@E: CS187 :"C:\Users\austi\OneDrive\Documents\Cu_LatticeICE40_Custom_ArcadeBoard_IC_Prototyping\reset_conditioner.v":33:0:33:8|Expecting endmodule
9 syntax errors
Process took 0h:00m:01s realtime, 0h:00m:01s cputime
# Mon Dec 09 14:13:32 2024
###########################################################]
@END
Process took 0h:00m:01s realtime, 0h:00m:01s cputime
# Mon Dec 09 14:13:32 2024
###########################################################]
Synthesis exit by 2.
Synthesis failed.
Synthesis batch mode runtime 1 seconds
Now, I’ve just noticed that if I double-click one of the problem outputs from within IC2, my cursor is automatically moved and highlighted over the following from within the top file - here’s one mapped example:
The error:
@E: CG376 :"C:\Users\austi\OneDrive\Documents\Cu_LatticeICE40_Custom_ArcadeBoard_IC_Prototyping\alchitry_top.v":13:24:13:24|Expecting variable name
when double-clicked, links me to the following line in alchitry_top.(s)v:
output reg [2:0][7:0] io_led,
I’m not sure why or how this could be considered a syntax error though…
I understand that io_led is defined within the generated merged_constraints.pcf file, but I’ve included this within the IC2 project’s P&R Flow->Constraint Files directory (as well as having its accompanying SDC file within the project’s Synthesis Tools->Constraint Files directory).
Synthesis batch mode runtime 1 seconds"C:\lscc\iCEcube2.2020.12\sbt_backend\bin\win32\opt\synpwrap\synpwrap.exe" -prj "Cu_Arcade_Custom_IC_Prototypes_syn.prj" -log "Cu_Arcade_Custom_IC_Prototypes_Implmnt/Cu_Arcade_Custom_IC_Prototypes.srr"
Copyright (C) 1992-2014 Lattice Semiconductor Corporation. All rights reserved.
==contents of Cu_Arcade_Custom_IC_Prototypes_Implmnt/Cu_Arcade_Custom_IC_Prototypes.srr
#Build: Synplify Pro L-2016.09L+ice40, Build 077R, Dec 2 2016
#install: C:\lscc\iCEcube2.2020.12\synpbase
#OS: Windows 8 6.2
#Hostname: DESKTOP-N5QBFD1
# Mon Dec 09 14:13:32 2024
#Implementation: Cu_Arcade_Custom_IC_Prototypes_Implmnt
Synopsys HDL Compiler, version comp2016q3p1, Build 141R, built Dec 5 2016
@N|Running in 64-bit mode
Copyright (C) 1994-2016 Synopsys, Inc. All rights reserved. This Synopsys software and all associated documentation are proprietary to Synopsys, Inc. and may only be used pursuant to the terms and conditions of a written license agreement with Synopsys, Inc. All other use, reproduction, modification, or distribution of the Synopsys software or the associated documentation is strictly prohibited.
Synopsys Verilog Compiler, version comp2016q3p1, Build 141R, built Dec 5 2016
@N|Running in 64-bit mode
Copyright (C) 1994-2016 Synopsys, Inc. All rights reserved. This Synopsys software and all associated documentation are proprietary to Synopsys, Inc. and may only be used pursuant to the terms and conditions of a written license agreement with Synopsys, Inc. All other use, reproduction, modification, or distribution of the Synopsys software or the associated documentation is strictly prohibited.
@I::"C:\lscc\iCEcube2.2020.12\synpbase\lib\generic\sb_ice40.v" (library work)
@I::"C:\lscc\iCEcube2.2020.12\synpbase\lib\vlog\hypermods.v" (library __hyper__lib__)
@I::"C:\lscc\iCEcube2.2020.12\synpbase\lib\vlog\umr_capim.v" (library snps_haps)
@I::"C:\lscc\iCEcube2.2020.12\synpbase\lib\vlog\scemi_objects.v" (library snps_haps)
@I::"C:\lscc\iCEcube2.2020.12\synpbase\lib\vlog\scemi_pipes.svh" (library snps_haps)
@I::"C:\Users\austi\OneDrive\Documents\Cu_LatticeICE40_Custom_ArcadeBoard_IC_Prototyping\alchitry_top.v" (library work)
@E: CG376 :"C:\Users\austi\OneDrive\Documents\Cu_LatticeICE40_Custom_ArcadeBoard_IC_Prototyping\alchitry_top.v":13:24:13:24|Expecting variable name
@I::"C:\Users\austi\OneDrive\Documents\Cu_LatticeICE40_Custom_ArcadeBoard_IC_Prototyping\counter.v" (library work)
@E: CS187 :"C:\Users\austi\OneDrive\Documents\Cu_LatticeICE40_Custom_ArcadeBoard_IC_Prototyping\counter.v":20:46:20:46|Expecting ,
@E: CG431 :"C:\Users\austi\OneDrive\Documents\Cu_LatticeICE40_Custom_ArcadeBoard_IC_Prototyping\counter.v":36:42:36:43|Expecting radix character (one of b, o, h, or d) or unsized single bit literal (one of '1, '0, 'x, 'z)
@E: CS187 :"C:\Users\austi\OneDrive\Documents\Cu_LatticeICE40_Custom_ArcadeBoard_IC_Prototyping\counter.v":48:0:48:8|Expecting endmodule
@I::"C:\Users\austi\OneDrive\Documents\Cu_LatticeICE40_Custom_ArcadeBoard_IC_Prototyping\decoder.v" (library work)
@I::"C:\Users\austi\OneDrive\Documents\Cu_LatticeICE40_Custom_ArcadeBoard_IC_Prototyping\fake_pull_down.v" (library work)
@E: CS187 :"C:\Users\austi\OneDrive\Documents\Cu_LatticeICE40_Custom_ArcadeBoard_IC_Prototyping\fake_pull_down.v":15:35:15:35|Expecting ,
@E: CS187 :"C:\Users\austi\OneDrive\Documents\Cu_LatticeICE40_Custom_ArcadeBoard_IC_Prototyping\fake_pull_down.v":39:0:39:8|Expecting endmodule
@I::"C:\Users\austi\OneDrive\Documents\Cu_LatticeICE40_Custom_ArcadeBoard_IC_Prototyping\fake_pull_down_2d.v" (library work)
@E: CG496 :"C:\Users\austi\OneDrive\Documents\Cu_LatticeICE40_Custom_ArcadeBoard_IC_Prototyping\fake_pull_down_2d.v":12:32:12:32|Expecting valid net type or name
@I::"C:\Users\austi\OneDrive\Documents\Cu_LatticeICE40_Custom_ArcadeBoard_IC_Prototyping\reset_conditioner.v" (library work)
@E: CS187 :"C:\Users\austi\OneDrive\Documents\Cu_LatticeICE40_Custom_ArcadeBoard_IC_Prototyping\reset_conditioner.v":15:46:15:46|Expecting ,
@E: CS187 :"C:\Users\austi\OneDrive\Documents\Cu_LatticeICE40_Custom_ArcadeBoard_IC_Prototyping\reset_conditioner.v":33:0:33:8|Expecting endmodule
9 syntax errors
Process took 0h:00m:01s realtime, 0h:00m:01s cputime
# Mon Dec 09 14:13:32 2024
###########################################################]
@END
Process took 0h:00m:01s realtime, 0h:00m:01s cputime
# Mon Dec 09 14:13:32 2024
###########################################################]
Synthesis exit by 2.
Synthesis failed.
Synthesis batch mode runtime 1 seconds
When clicking these “Syntax errors” (specifically the first one seen that refers to “alchitry_top.(s)v”, I’m linked to the following line:
output reg [2:0][7:0] io_led,
But I don’t understand how this, for example, would be considered a syntax error??
Jagged array is a SystemVerilog feature, this syntax is not supported by “vanilla” Verilog.
There is way around by using this syntax instead :
output reg [2:0] io_led[7:0],
But you may have to adapt other parts of the code to match.
1 Like