Open
Description
This is a great work!!!
I am currently exploring the QEMU-based QBox project and looking for guidance on extending the peripheral access width for CPU-to-peripheral transactions. I want to ensure that the CPU model can support wider data transactions (e.g., 64-bit or more) while accessing peripherals. Here are the specific questions I have:
- Current Peripheral Access Width Determination
How does the current QBox determine the access width when the CPU communicates with peripherals (e.g., UART, memory-mapped devices)?
Which components or configurations influence this behavior? For example:
qemu-components/common/src/libqemu-cxx/cpu.cc for CPU model behavior.
MemoryRegionOps definitions for peripherals.
Bus protocols (e.g., AXI or PCI configurations). - Extending Access Width
If I want to extend the access width (e.g., from 32-bit to 64-bit or 128-bit) in the QBox:
What parts of the CPU model or peripheral implementation should I focus on?
Should I update the MemoryRegionOps in files like qemu-components/common/src/libqemu-cxx/device.cc?
How does the tlm_generic_payload or TLM extensions in SystemC interact with these configurations? - Testing and Validation
Are there existing tests in the tests/ directory that cover access width validation?
If not, what would be the recommended way to test such modifications in QBox? - General Recommendations
Are there any best practices or existing design patterns in QBox for handling wider transactions (e.g., outstanding transactions or batched access)?
I would like to extend the QEMU CPU model and peripheral interactions to support wider data transactions and understand the appropriate design choices. Any pointers, suggestions, or examples would be highly appreciated!
Metadata
Metadata
Assignees
Labels
No labels