I am in the process of moving about 40 projects from Labs1 to Labs2. At first, with simple ones, I was surprised at how easy it was. I don’t even use most of the things where the syntax changed. As I continued, I found some syntax that generate errors and are easily fixed, stuff like:
sel needs to be select
seg needs to be segment
The RAM module wants WIDTH and ENTRIES instead of SIZE and DEPTH.
I can no longer use sp.q-1 as an index. The -1 makes the system think it is out of range by definition!?!
Again, these generate errors and are easy to find and fix.
Others are a little harder. I found, for example, that using “char” as the name of an output generated mysterious behavior, but I figured it out and changed the name.
I have read the posting about Lucid 1 vs Lucid 2 and used the Lucid 2 Reference. The projects are continuing to get more complicated. I have started running into problems I can’t fix - several of them. I get a bunch of errors at first. I fixed all the errors, change things like “char” that I know about, Vivado builds it with 0 errors and gives me “Built Successfully”, but it just doesn’t work at all, and I have no idea why.
Have others had this kind of problem? And know any other trick that might make a project work correctly in Labs2?
sp.q-1will be out of range unless you set an INIT value for sp. When it’s reset, sp.q is 0 and that’s causing the error. It should be a warning though. I created an issue to remind me to change that.
I think the char issue should be fixed.
If you have a project you can share, I’d be happy to help try to figure out any build issues. It’s possible you’re finding a bug.
Thanks Justin. I really was asking if anyone else had found issues that I don’t know about. Sorry to keep bothering you with my problems.
I did figure out using INIT to get it to accept -1 in the index, just yesterday.
I will keep working at this myself for now, and let you know if I find anything I think is a bug. I have many iterations of these projects in Labs1, which is making the conversion to Labs2 mistake prone. I need to work more on fixing my own issues.
FYI, if you are moving projects from Labs1 to Labs2, here is another minor difference you might want to know about. This is not a new discovery, but one I forgot to mention in my original message above:
Using the serial terminal on Labs1, I looked for a CR (hex 0D) to detect end of entry. Using the serial terminal on Labs2, I had to switch to a LF (hex 0A) to detect it, as a CR wasn’t entered into the serial stream by Labs2 serial terminal.
This is (maybe) platform dependant : Windows uses CR+LF to end a line, where Linux usually uses LF alone.
But maybe Labs overrides this in the serial terminal?
This is pretty nit-picky, but just to document, one more difference between Labs1 Serial Terminal and Labs2 Serial Terminal: backspace (ASCII 08) is implemented in Labs1 and absent in Labs2, i.e. backspace does not generate a character.
Looking into the code and thinking about it more, I’m going to leave index out of bounds as errors. If you have a strong case as to why they should be warnings, let me know. There’s no reason you should index out of bounds and it is easy to avoid it (in @DougD 's case, the DFF should be initialized to avoid the -1 situation).
I think this is the same kind of thing as languages providing null safety. Yeah Java lets you do whatever you want will nulls but Kotlin’s null safety really cut down on the number of bugs in Labs V2.
I will make one more plea for the warning instead of the error, by just explaining the problem it creates.
Whether I fix the negative index or initialize the dff to something other than 0, the result is same. I am using the dff as a stack pointer, and either fix precludes using the first position in the stack.
The index in question is in a conditional when I pull something off the stack. I can’t push it onto the stack in the first place at 0 is dff is INIT at 1, and I can’t get it off the stack once it’s on at 0 if I can’t use a negative index.
I don’t need the error to tell me I can’t pull something off the stack until I put something on the stack! Not a huge problem, but kind of annoying and unnecessary.
If you aren’t using the value, you could wrap it in an if statement (ie, if stack is not empty) and that would also remove the error as dead code is ignored.
I don’t see why you need the index to be negative? Could you share a snippet?
You’re saying you want to use the first version without INIT right? I think this would better be considered a bug in identifying dead code as the case statement shouldn’t throw the error unless the case is active. I’ll have to double check how that’s setup.
I just fixed this by adding an “inactive” block check and it’ll be in the next release. The code before only checked for dead code (that could never be reached).