Skip to content
AevornixAEVORNIX
Developer CloudIn Development

Develop for a machine you do not own.

The practical starting point for RISC-V work: hosted build and test environments, an emulated target, dependency and package scanning, and a report you can act on, none of which requires RISC-V hardware on your desk.

Workflow

10 steps, repository to store listing.

Each step carries its own stage. Where a step is planned, the description says what it will do, not what it does today.

  1. Connect repositoryPlannedOpen

    Point RVStack at a source repository and choose the branch and directory a build runs from.

  2. Select targetIn DevelopmentOpen

    Choose the RISC-V profile to build against. The choice fixes the instruction-set baseline and the capability set every later step is checked against.

  3. Build for riscv64In DevelopmentOpen

    Cross-compile and link against the selected profile, producing target binaries and the debug information the later steps need.

  4. Run in emulatorPrototypeOpen

    Execute the build inside an emulated RISC-V machine, so behaviour on the target is observable without owning the hardware.

  5. Scan dependenciesIn DevelopmentOpen

    Walk the dependency tree for native libraries, architecture-specific binaries and system calls the target does not provide.

  6. Test application behaviourPrototypeOpen

    Run the project test suite inside the emulated profile rather than on the development machine, so failures reflect the target and not the host.

  7. Benchmark performanceResearchOpen

    Record timing and memory behaviour under the emulated profile, with the emulation overhead stated alongside the figures.

  8. Generate reportPlannedOpen

    Collect the build, scan, test and benchmark output into one report naming what was checked and what was not.

  9. Publish certificationPlannedOpen

    Turn a passing report into a published compatibility statement carrying the profile and the date it was tested.

  10. Submit to storePlannedOpen

    Attach the certification to a Store listing so the architecture support and scan results travel with the product.

Capabilities

What the environment provides.

Eight subsystems, at four different stages. None is open to developers yet; preview applications are.

Repository integration

Connect a GitHub repository and build from a branch on push or on demand.

Planned

Build logs

Full toolchain output, retained per build, addressable by commit.

In Development

RISC-V emulator

An emulated 64-bit RISC-V machine builds are executed inside.

Prototype

Native library scanner

Finds compiled dependencies with no RISC-V build available.

In Development

AI model scanner

Reports model format, operator coverage, precision and estimated memory.

Research

Package report

What the package contains, what it requires, and what is missing for the target.

In Development

Security report

Supply-chain findings, signing state and a software bill of materials.

Research

Store readiness

Whether a listing has everything a RISC-V category entry requires.

Planned

In the pipeline

The cloud is the first five stages.

Build, emulation, compatibility scanning, security scanning and model checking all run here. Certification, publishing and deployment take the report this produces and act on it.

Emulation is not the same as running on silicon. Any timing this environment produces is stated with the emulation overhead alongside it, and performance work will need physical hardware before it can be called measured.

RVStack pipeline
RVStack pipeline, 9 stages first to last: 01 Developer input, 02 Build system, 03 Emulation, 04 Compatibility scanner, 05 Security scanner, 06 AI runtime, 07 Certification, 08 Store publishing, 09 Deployment.
  1. Developer input

    A repository, a package or a model, plus the profile it is meant to run on.

  2. Build system

    Cross-compilation and linking for the selected 64-bit RISC-V target.

  3. Emulation

    Execution inside an emulated RISC-V machine matching the profile.

  4. Compatibility scanner

    Native libraries, architecture-specific binaries and missing system services.

  5. Security scanner

    Supply chain, signing state and a software bill of materials.

  6. AI runtime

    Format, operator coverage, precision and memory for any model in the package.

  7. Certification

    One report naming the profile, the date and exactly what was checked.

  8. Store publishing

    A listing carrying the architecture, licence, badges and tested date.

  9. Deployment

    Delivery to an emulated profile, a Linux RISC-V machine or a managed fleet.