https://open-source-silicon.dev logo
Join SlackCommunities
Powered by
Trying to get my previous RTL/GL simulations runni...
# mpw-2-silicon
m
Trying to get my previous RTL/GL simulations running again. Unfortunately, they do not! It seems to be something with Caravel boot up since I never get to my code (that just blinks GPIO 0)
I see activity on the flash bus (clk, csb, io0, io1) in my simulation. Is there something I can look for to see when it stops loading the program over the flash interface and jumps to user code? It runs a while then just settles on address 0x100000B0 and doesn't appear to do anything more. Yet the flash bus is still rattling on...
t
I find it hard to follow what the VexRISC is doing a lot of the time, especially with its small registered instruction cache. But you should at least be able to look at the disassembled program and see what instruction is at address 
b0
.
You should have a 
.lst
file for the program?
m
This should be picorv32 since it is MPW2/3, right?
Hrm, it does seem to be running off the end of my code.
t
No, it's VexRISC from MPW-two onward (blame Tim Ansell for that one). If it does go off the end of the code, it can execute a loop which is just a jump to itself---which would match what you see in the program counter (program counter = next program counter). The flash controller will continue to prefetch garbage from past the end of data, although it should not do that for more than a few 32-bit words, because that's about all the space it has for instructions.
m
Why does it say "picorv32" in the verilog??
Yeah, it was jumping off the end. Now I'm trying to figure out why the GPIO isn't being set to output.
*  PicoRV32 -- A Small RISC-V (RV32I) Processor Core
*
*  Copyright (C) 2015  Clifford Wolf <<mailto:clifford@clifford.at|clifford@clifford.at>>
*
t
Where are you reading that verilog from?
m
The caravel directory that I stashed with my project back then...
caravel/verilog/rtl
t
I do know that people were designing to the picoRV32 before the version with the VexRISC was pushed. There is no picoRV32 in the repository with the last official tag used for the MPW-two tapeout.
m
WTF
This means all of my simulations may have were wrong
t
The VexRISC was pushed on us rather late in the game. I don't think that the processor core type is going to change anything significantly, but there will probably be a number of register addresses that might need changing. If you post your simulation code, I can take a look over it.
m
I just used the mpw2 and mpw3 tags of the user project directory as we were told to do.
t
The mpw2 tag is the schizophrenic one. There is an mpw2 tag in the last version of the repository that was the development version for MPW-two before the VexRISC version. That is probably the repository you were working in and still have. That repository got renamed to "caravel_mpw-one". Then the new "caravel" repository was created, with the VexRISC, and also with an mpw2 tag.
m
Yes, that is the one that I am using.
Renaming a repository doesn't make us update to point to the new one...
t
Just tarball your simulation code and I'll help you get it working on the tapeout repository. I've done those conversions before; it's not too painful.
m
I'm just trying to blink GPIO 0
Actually, simpler than that. Set it to 1.
Is there a way I can clone the correct tape-out repository?
I want to eventually try some things where I can combine two of my test modes if I can't use some of the GPIO.
t
The main thing that breaks hex code between the PicoRV32 and the VexRISC is that the VexRISC doesn't support compressed instructions. The PicoRV32 version had the compiler switch set to compressed instructions + multiplier; that needs to be turned off.
m
(My project uses both the LA and some GPIO pins and I might be able to go back and forth a bit...)
t
I don't think you'll have any problem with the code accessing the LA and GPIO. I think your problems are all going to come from the compiler environment setup.
m
Is there a base user-project-wrapper that is representative of the final mpw2?
t
There should be. Let me get you commit or tag numbers on all the bits and pieces.
Caravel: https://github.com/efabless/caravel commit 7d7eb3d1dd59d578e8e30572739c1760c9ebac64, tag mpw-2b
m
(unless you use the git version instead of the submodule, then it just uses "master")
t
Yes, I see that. . .
Looks like 
mpw-5b
is the first version of the user project repository that matches the VexRISC. It should be the same as the MPW-2 tapeout version.
m
I'm now stuck trying to figure out which version of the IO library RTL models to include. Seems to be some in the PDK dir (sky130-fd-io.v and sky130-ef-io.v) but there is another copy in the management core warpper verilog/cvc-pdk directory that define these missing modules:
Copy code
*** These modules were missing:
        sky130_ef_io__gpiov2_pad_wrapped referenced 8 times.
        sky130_ef_io__vccd_lvc_clamped3_pad referenced 2 times.
        sky130_ef_io__vssd_lvc_clamped3_pad referenced 2 times.
*
t
We are about to have a meeting on getting users information about how to set up the environment correctly for the MPW-two tapeout version of Caravel. The above looks more like a trivial detail, though. I'll take a look at it as soon as we have finished the discussion. We might try to loop you in if you're available.
👍 1
I don't know what the verilog/cvc-pdk directory is for. Probably compatibility with the cvc verilog simulator, which is needed for doing delay annotation. What you should be including is the library from the PDK directory. The 
sky130_ef_io.v
contains cells which are all composites of base cells and overlays; the base cells are the ones from 
sky130_fd_io.v
, so you'll need both libraries.
m
Ok, let me know if I can help.
t
I think it's more a matter of you letting us know how we can help you.
m
FYI, I've been just copying the hex from the caravel_board directory to use for my sims. That resolves the build issues.
t
I thought your simulations were using the repository with the PicoRV32.
m
They were. I'm converting it to the vexRISC
I'd like to simulate the actual hardware that I'm testing.
t
So you're passing the hex code for the VexRISC to the simulation that has the PicoRV32?
m
No, I'm using entirely VexRISC now.
t
Okay, got it.
m
I'm using the correct versions of caravel with my old project.
Or trying to.
I've got it running. There was a lot of hacking of the caravel_netlists.v file and include paths.
Though, it seems to fail after a couple instructions.
VexRiscv is harder to debug. 😕
t
Yes, VexRisc is painfully hard to debug compared to the PicoRV32.
Is there anything I can do to help with the debugging? Post the hex file?
It would be really nice if you could make a quick writeup of what you did to convert your design environment. I looked back at our messaging around MPW-two and it was not made clear that we were swapping in a new processor (more like mentioned in passing), so I expect there are more designers than you who will end up faced with the same problem and could benefit from your experience.
m
I did this: 1. Clone https://github.com/efabless/caravel_mgmt_soc_litex branch main as mgmt_core_wrapper in my project directory. 2. Clone https://github.com/efabless/caravel.git branch mpw-2b as caravel in my project directory. 3. Copy RAM256.v from caravel_mgmt_soc_litex/verilog/gl/RAM256.v to caravel_mgmt_soc_litex/verilog/rtl/RAM256.v. Not sure why there isn't an rtl version like the RAM128.v 4. Apply caravel.patch to update the caravel includes as well as remove the .sram* signals from caravel. (Not sure if that is right?) 5. Apply mgmt_core_warpper.patch to remove vccd1/vssd1 from the VexRISC instantiation in mgmt_core.v (I'm not sure if other things need USE_POWER_PINS, but they aren't defined on the rtl core of VexRISC. 6. Change the includes on my project as well as prevent over-writing the .hex file in Makefile with project.patch 7. I'm also using my sky130A technology directory from the mpw2 tapeout.
caravel.patchproject.patchmgmt_core_wrapper.patch
This is my gpio_test.hex. It is the one that was used in the caravel_board repo.
gpio_test.hex
Actually, I generated that with my GPIO def file, so the scan timing is wrong.
I replaced the timing with one that has everything independent and created this hex file. I get an exception on one of the first instructions. The cause is "2" which comes to a reserved exception.
gpio_test.hex
It's fetching instruction 0x00000000
There are two spiflash modules. /caravel/verilog/dv/caravel/spiflash.v /caravel_mgmt_soc_litex/verilog/dv/vip/spiflash.v I wonder if I'm getting the wrong one.
Eh, they're the same, just $display a bit different
This has to do with the read-only SRAM ports on mgmt_core that I commented out because they were missing, I think
I reverted caravel_mgmt_soc_litex back to mpw-2b (I was using main) and that has the sram ports. However, the spi doesn't seem to load anything now. The flash interfaces does a cycle maybe then jumps to code which is 0's
Ah hah, the spiflash didn't have "powered_up = 1"
I don't quite understand the boot up, so it's executing something, but not getting anything done.
t
Sorry, I've been busy with debugging something in magic. I've run across the 
powered_up
problem before, don't remember when. I don't know what the VexRISC boot process does, but it's not long. Normally there's nothing that needs to be done at startup; it may be zeroing the registers.
p
@Matthew Guthaus re: reprocibility of the environment: there is also an archive of the project submission for MPW-2 under: https://foss-eda-tools.googlesource.com/third_party/shuttle/sky130/mpw-002,
2 Views
Open in Slack
PreviousNext
Powered by