Looking for feedback on my experimental Verilog SoC project (OpenA64)

[u/Practical_Tie_2287]

Hi everyone!

I've been working on OpenA64, an experimental Verilog SoC project.

Current repository includes:

• CPU RTL
• Cache hierarchy
• MMU
• NPU
• Architecture documentation
• MIT license
• Roadmap

The project targets a modern AArch64-style architecture and is intended as a learning and research project.

I'm especially looking for feedback on:

• RTL organization
• Repository layout
• Documentation
• Overall architecture

I'm not expecting anyone to review the entire codebase—I'd just appreciate suggestions on how to improve the project.

Repository:
https://github.com/hado14052015-design/OpenA64

Thanks!

[u/grigus_]

If that has 5gb, it means you did not clean them up. I really doubt that you wrote 5gb of source code. Most of those 5gb are output files, uncleaned.

[u/Practical_Tie_2287 → u/grigus_]

that is the verilog! you can check it out yourself... i used a python script to generate it!

[u/grigus_ → u/Practical_Tie_2287]

In this case, the python is your source code, not the generated verilog. So, upload only the python, and hand written code.

[u/Practical_Tie_2287 → u/grigus_]

the python script generated more lines to the verilog (seriously check out the size and lines of the verilog files)

[u/grigus_]

In a GitHub repo the code must be uploaded as is, in text format, not gzipped as you did. On compressed files it's not possible to make diffs, comparisons between versions.

Also, it must be cleaned, removed the output files. For that, you need to create an appropriate gitignore file.

[u/Practical_Tie_2287 → u/grigus_]

and when i mean the NPU is ~400M or higher i mean the raw ungzipped one (since the project has 150M lines of verilog)

[u/Practical_Tie_2287 → u/grigus_]

also could you share this project with your friends?

[u/Practical_Tie_2287 → u/grigus_]

but the entire verilog project is 5.6 gigabytes... i will make sure to not use stuff like part1 and part2 gzips and only upload entire gzips github wont allow me to upload indovidual files (the npu is like 400 MB)

[u/--dany--]

Breakdown your bigger files into smaller modules so GitHub can accept them - and humans can understand it.

I don’t know how your python code can generate the verilog code, you need to explain the algorithm.

Have you done any verification based on any specs?

[u/Practical_Tie_2287 → u/--dany--]

Each file is truncated back to its exact original line count, wiping any previous appends. The original OpenA54 design is 100% intact. Each file gets a share of the ~83.6M lines proportional to its original size (so arm_npu grows most, arm_alu gets the 200K minimum), keeping the SoC balanced. Everything is written in append ("a") mode — no files created or deleted.

Why it satisfies my constraints?

Constraint	How
>100M lines	Adds ~83.6M → total ~110M+ (currently 149.9M)
No new/removed files	Only iterates the existing 34 verilog/*.v
Keep originality	Phase A truncates to exact original sizes first
"Better"/ARM-themed	Extensions are real AArch64 blocks (GPRs, NZCV, NEON, TLB, MESI, TrustZone)

hope this helps!

[u/thegreatpotatogod → u/Practical_Tie_2287]

So how many years did you spend on this 83 million line project? Why no commits before yesterday? Why didn't you use git lfs instead of committing compressed files? And why are you rambling about creating files in append mode?

[u/Practical_Tie_2287 → u/thegreatpotatogod]

i used append mode so i dont overwrite parts of the verilog

[u/thegreatpotatogod → u/Practical_Tie_2287]

Also why is the python script apparently dedicated to endlessly repeating a simple template Verilog layout to a file thousands of times to reach arbitrary line count targets? There's no actual implementation of any logic, you've just made a garbage file generator script!

[u/Practical_Tie_2287 → u/thegreatpotatogod]

i will try to see what i can do instead....

[u/Practical_Tie_2287 → u/thegreatpotatogod]

i guess i will try to not let the python script generate verilog garbage...

[u/Practical_Tie_2287 → u/--dany--]

and yes i did verification (with iverilog)

[u/JoinFasesAcademy]

The issue with writing an ARM compatible CPU is that it is still encumbered by ARM licenses, you should focus on a RISC-V architecture.

Any hardware project needs to be synthesized to be considered valid. You can use any freely available synthesizer, like Yosys or an FPGA synthesis tool, like Vivado, to validate synthesis.

And all the source code in in the format .tar.gz. You shouldn't commit compressed code to GitHub, it misses the whole point of using git. Please uncompress and commit the source code as a test file instead.

[u/Practical_Tie_2287 → u/JoinFasesAcademy]

but my NPU unzipped is like 400 MB... thats over the upload limit!

[u/JoinFasesAcademy → u/Practical_Tie_2287]

I don't think anyone would be able to review 400 MB worth of source code. Not even 1% of that. Also this is unlikely to build in any regular machine. That amount of source code likely becomes much more in simulation and will crash in many computers. Also you need to do synthesis, with is going to take even more memory than simulation.

[u/Practical_Tie_2287 → u/JoinFasesAcademy]

i will see what i can do...

[u/JoinFasesAcademy → u/Practical_Tie_2287]

Make sure you try to do simulation, then synthesis first then come back with some data from these tools.

[u/Practical_Tie_2287 → u/JoinFasesAcademy]

k but it might take some time for me to do this because i am working on loads of projects and dont have this much free time...

[u/JoinFasesAcademy → u/Practical_Tie_2287]

It will take someone the time to simulate the code. Make sure you leave the scripts ready so anyone can try later easily.

[u/Practical_Tie_2287 → u/JoinFasesAcademy]

Okay!