unexpected character error

[Mingyu Park]

First of all, the current build-setup.sh( 51b66dd) seems to have more errors than the previous version.
 It seems that the difference in the init-submodules-no-riscv-tools-nolog.sh file is interrupting the installation process to download the proper executable.  

Hopefully this issue will be resolved soon.

However, I am unable to build verilator and vcs after building .conda-env using an older version of the init-submodules-no-riscv-tools-nolog.sh file.

I keep getting the following error
Build fails because some names are kept as `1`, `2`.

[Jerry Zhao]

Regarding the build-setup issues. Can you open an issue on the github with screenshots of the error?

Regarding the build error, I was unable to reproduce this issue, and it does not show up in our automated testing. Can you send the entire .fir file which manifests the error?

--
You received this message because you are subscribed to the Google Groups "Chipyard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chipyard+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/chipyard/e00f2483-37e6-458e-b86c-be0926490812n%40googlegroups.com.

[Mingyu Park]

Here is an attached file for fir error.
It creates such error for other configuration too.

2024년 8월 25일 일요일 오후 7시 3분 15초 UTC-4에 jerr...@berkeley.edu님이 작성:

[Jerry Zhao]

Can you report what `firtool --version` is for you?

-Jerry

To view this discussion on the web visit https://groups.google.com/d/msgid/chipyard/128eeedf-a504-45a9-b15d-88a8059c95fen%40googlegroups.com.

[Mingyu Park]

It reports as follow
$firtool -version
LLVM (http://llvm.org/):
  LLVM version 17.0.0git
  Optimized build with assertions.
CIRCT unknown git version

I also tested it on my old version from Gemini github, and it gives the same result.
btw, this problem might be related to the one I upload on the chipyard github issue page.
As current build-setup.sh doesn't generate mandatory executable: firtool and verillator in the .conda-env/bin, I copy the one that I generated during gemmini project.

2024년 8월 26일 월요일 오전 1시 6분 32초 UTC-4에 jerr...@berkeley.edu님이 작성:

[Mingyu Park]

This issue was caused by an incorrect way to download the .conda-env. Once successfully set up, I can use vcs and verilator to generate the appropriate sverilog code.
Thanks for your help Jerry.

I've been successfully utilizing Gemmini SoCs and would like to utilize Saturn with the recent update. I have a few questions, if you don't mind me asking?

1) Saturn seems to be used with Shuttle, which is a variant of Rocket core, but are there any plans to merge with other systems?
Also, https://chipyard.readthedocs.io/en/latest/Generators/Saturn.html recommends using GENV256D128ShuttleConfig, is there any particular reason for this?

2) With Gemmini, I was able to simulate different workloads and get the waveforms through VCS. 

Will i be able to simulate all workloads in the same way on Saturn? Probably, workloads with a lot of vector operations would be meaningful.

3) This is a problem I faced while utilizing Gemmini SoC. Currently sverilog seems to generate all memory units as register based. This is probably chosen for universality, but in real chip design, L2, L1 cache, etc. should use sram macro, so I utilized it by naming matching through memory generator.
However, this can cause some problems in VCS simulation.  As the existing register cell is changed to sram macro, the swtiching activity of the memory is not applied correctly.
Have you thought about this at all, and if so, any advice would be appreciated.

Again, thanks for Berkeley's opensource project and especially for the effort you've put into the recent updates to Saturn.

2024년 8월 26일 월요일 오전 10시 23분 51초 UTC-4에 Mingyu Park님이 작성:

[Jerry Zhao]

1. If you open SaturnConfigs.scala, you can see there are many configs which use Rocket. For now I recommend `GENV256D128ShuttleConfig` as a performant baseline configuration. The documentation on the meaning and differences across all the different configurations is not ready for release yet.

2. Yes, you can simulate vector workloads using the Saturn configurations.

3. When doing PD for a tapeout, we use MacroCompiler to generate SRAM macros instead of sverilog mems. When doing RTL sim, we don't do this, and rely on the synchronous sverilog mems. Both flows result in logically equivalent verilog.
There should be no problem running RTL sims with the sverilog mems.

-Jerry

To view this discussion on the web visit https://groups.google.com/d/msgid/chipyard/98367e29-7b19-43df-84a3-de8aee2a9094n%40googlegroups.com.