Thought it would help to make a topic to discuss V2 additions, for hardware and software.
So far I can not think of anything, so you are first.
After writing modules, we have to wire them together, and for this, I think there is nothing more intuitive than a GUI approach.
It’s visual and intuitive and I think a good schematic view is much more readable and less error-prone than the boilerplate wiring code that we need to write and copy-paste when the project start to get big.
I don’t know how hard it would be to implement, but I would definitely use it 
Great idea. Mixing this with the Vivado schematic view to also see inside of the module would be great. Actually, adding all Vivados views, Implementation, etc. would be neat.
Would be nice but probably too much work and most likely out of scope of Labs I guess.
But we can actually open Vivado if we really need, I do when I need to use the simulator and the debugger 
If we switch to the upcoming open-source toolchain, these views may become usefull since we won’t have Vivado anymore, and probably easier integrated because it’s most likely calling the right tool like we would do by CLI.
Sadly this toolchain it still in early beta for the gen7 afaik.
1 Like
Right now the open source tools are a bit of a novelty. I’ve been fairly disappointed with them when working with the Cu. They often fail to meet timing for basic designs that the proprietary tools have no issue with. They’ve come a long way and the fact that they work at all is impressive but they won’t be replacing Vivado any time soon.
Not such a great idea, now that I think about it.
For the wiring modules, maybe it could be a sort of simulation area too! Probe the signals on wires connecting the modules together. That would help a lot with the way I make verilog.
I realize this might be a bit late of a suggestion (as the V2 code development has started), but what about instead of writing a full IDE, Labs v2 leverages a pre-built IDE like VSCode?
1 Like
This comes up a lot with whatever IDE is currently in favor. I don’t think that this would actually save a ton of development work and would likely lead to more in the long term.
When I started the original IDE, Eclipse was the most popular IDE. It’s now all but dead. Having to maintain compatibility with another program seems like a ton of work over time. You’re also then limited to whatever the chosen IDE lets you do.
1 Like
VSCode seems pretty permissive, the PlatformIO and Sigasi extensions adds a whole lot of stuff (even custom GUI elements), but I can’t tell how much work they had to put to get that result.
I think a screen element would be fantastic. The rectangular form factor of the boards would work great with whatever screen you want there.
Do you mean like an LCD add-on board?
1 Like
Yes, kind of like the one used in the GPU demo, but add on, like the Io. It could be LCD, OLED, whatever you want.
Actually, nevermind. The split windows work, I just did not know how to use them 
.
Also, you could make mini add on sensor boards that have a single connector at the bottom to take up only one space on the boards, not taking up all (4 connectors on the old Aus and Cus). Maybe a microphone, speaker, temperature, etc.
I have a suggestion for Lab V2.
If I set up a stack:
dff stack[8][16]; // the stack - 8 deep
dff sp[3]; // stack pointer
and, in a conditional, I write:
stack.d[sp.q-1] = address;
the sp-1 gives me a hard error, as it could possibly be out of range in the stack. It is no more likely to be out of range than sp.q+1. sp.q+1 does not even get a warning.
Labs 1 didn’t call sc.q-1 a error, it doesn’t bother Vivado either. I don’t think Lab2 should call it an error. It’s not hard to work around this, but at least make it a warning instead of an error.
Thanks!
I have to strongly disagree with your reluctance to make use of VSCode, and urge you to reconsider.
I don’t think that this would actually save a ton of development work
You could devote all of your energy solely on the editor for many years, and never come within sight of the functionality and versatility of VSCode. I think you could do much more interesting and useful things by making use of a truly excellent and free editor that already exists.
See the Raspberry Pi Pico extension, for example. It makes use of VSCode’s ability to use nearly any toolchain, collects a bunch of other useful extensions for many of its features, and is left with just a small gap of usability it has to close itself.
Alchitry Labs doesn’t yet support page down- I’m not filled with hope that it’s going to someday get features I enjoy like multi-cursor editing, git support, SSH remote access, interactive file diffing, and on and on and on.
Also, all of the language features could be built into a language server, which would then be portable to any other modern editor that someday becomes popular. That’s designed to free people like you from having to make so much editor-specific code.
Eclipse was the most popular IDE
My memory is that everyone hated Eclipse even when it was popular.
You’re also then limited to whatever the chosen IDE lets you do.
VSCode has a very rich selection of extensions, and it allows them to do quite a lot.
I appreciate how clean and simple you’ve made Alchitry Labs, but being forced to use an editor that’s so much more limited is rather unpleasant. I’m sure it will become better, but you will honestly never close that gap, and you could do much more interesting things with your time than trying.
1 Like
I made the jump to direct Vivado development partly to get access to VSCode editing. I started with verilog but I’ve been trading up to SystemVerilog as I figure things out.
I’ve certainly gotten far enough along to appreciate what Lucid is trying to accomplish as a language! But man, I just could not stand the editor.
Oh, and OminousHum, I know a Schlock Mercenary reference when I see one! Great comic.
I wouldn’t be opposed to supporting a plugin in addition to Labs, at least for code editing. I’ll have to look into what it would take to bridge the existing code to a plugin.