setup.py is not installing subpackages

[philipaxer]

Hi,

the setup.py is not installing the subpackages (cpuif, field_logic, hwif ...). Changing the hardcoded packages statement in setup.py as follows, includes all subpackages under peakrdl: packages=setuptools.find_namespace_packages(include=["peakrdl*"]) ,

regards Philip

[amykyta3]

Thats odd. I've deployed multiple other namespaced packages the exact same way without issue. Either way, it might be better to install in editable mode for now since this is all still pre-release code. I'll work out any kinks in the deployment when it comes time to do that.

Another thing you may be running into is that the tool currently requires a version of systemrdl-compiler that is still unreleased. Development of this tool has been informing a lot of the newer features in the compiler, so you'll need the pre-release version of that too.

Try installing as follows:

# Install dev version of systemrdl-compiler first directly from the repository
python3 -m pip install -U git+https://github.com/SystemRDL/systemrdl-compiler.git

# clone & Install the regblock exporter in editable mode
git clone git@github.com:SystemRDL/PeakRDL-regblock.git
python3 -m pip install -e ./PeakRDL-regblock

And lastly a reminder - This project is still a work in progress so I totally expect there to be some quirks. Thanks for taking an interest in it!

[philipaxer]

Acknowledged. I really like the architecture decisions that you made by bundleing the structs in "in" and "out" and using arrays where possible. A lot of generators will unroll signals, causing enormous re-wiring overhead while integrating the CSR bank in the final design. I am already using the latest systemrdl-compiler. You probably know this, but the HEAD of systemrdl-compiler is not yet at "systemrdl-compiler>=1.22.0", so I needed to force the install.

A general question I have, is this. How is the systemrdl overall clocking architecture envisioned? Lets say you run APB3 in its own pclk domain. For the sake of the question lets assume i have a counter that is counting events generated in a different (probably faster) clock domain (sys_clk). I would expect that the counter counts the cycles (in sys_clk ticks) that the signal is asserted (i.e. level not edge). In the generated RTL, you have solved this implicitly by running everything (including APB) on sys_clk. In reality this might not always be the case. Out of interest, is there a way in SystemRDL to specify clock domains?

[amykyta3]

SystemRDL doesn't really have a direct mechanism to describe the concepts of clock domains, so currently I only plan to support a single clock domain. I also want to to keep initial scope of the project reasonable.

What you describe is definitely a situation I encounter pretty often. Although the language doesn't provide a concept for clock domains, SystemRDL does provide a mechanism to define individual registers & fields as "external" - meaning that they are structurally handled outside of the usual exporter. This would allow the designer to implement a unique clock domain crossing for that particular register as needed. That would probably be the way I'd approach this situation. Ultimately it becomes a trade based on the particular register block's clock domain partitioning. If most/all fields need to be synchronous to sys_clk, then the designer really ought to use an APB clock crossing bridge from their library prior to the auto-generated register block. On the other hand, if most of the registers are synchronous to the APB clock and only a few outliers are on a foreign clock domain, I'd recommend the external register approach I described earlier.

[amykyta3]

@philipaxer - Just published the first release to PyPI! Let me know if there are any install/package import issues