Search this site

Effective UI/UX and graphic design are crucial for building user-friendly applications in today's digital world. At Whileone Techsoft Pvt. Ltd., we blend creativity with technical expertise to deliver visually appealing, high-performance products that drive business success. Our UI/UX and Graphic Design is all about: Why Us? We leverage a diverse set of design and development tools to create high-quality visual and interactive content. Our expertise spans various creative processes, ensuring that each project is enhanced with tailored, impactful visuals and elements that align with the client's goals. We deliver UI/UX and Development Together: As UI/UX and development are interconnected, our Designers create wireframes and prototypes that serve as blueprints for developers. Our expertise in tools like React and Vue.js facilitates this transition, ensuring a smooth development process. Collaboration between design and development teams results in visually consistent and high-performing applications. Our Experience in the Semiconductor Industry: Our UI/UX designs help simplify complex systems. Our services, where development and design go hand in hand, helped the customer deliver data with precision. Intuitive interfaces we created made visualizing and interacting with intricate technical data easier, reducing user error and enhancing productivity. … And customers achieved seamless improvement in their processes. CONTACT US FOR: At Whileone Techsoft Pvt. Ltd., we specialize in user-centric UI/UX and graphic design that aligns with business goals and technical needs. By working closely with development teams, we deliver cohesive digital products that enhance user engagement, improve workflows, and boost performance. Whether you're in any technical field, our design solutions simplify complex ideas with precision and clarity.

In a rapidly changing world, to keep the audience glued to websites, designs are frequently changed, and more features are constantly added. As such, rapid shipping is the norm. When designs change frequently, or new components get added, a system/workflow needs to be in place to enable such rapid changes. ​ Our cases: ​ Challenges: ​Enabling development of frontend components and viewing those components with multiple themes during development. Enabling component UI/UX review with multiple themes. Check and improve accessibility at component level. The CMS is used by stakeholders across all departments. Several departments lack a web development background. This means any new feature that we ship requires that we document so that the usage can be propagated across the stakeholders. So, an easy to use documentation. Multiple developers ship code, including interns, junior developers and senior developers. This adds a risk that a change in one place can cause regression at multiple pages across the website. Understanding that changing one component doesn’t cause any change in any other component with as little effort as possible. Understanding if the components are accessible and mobile responsive is equally important. Our solution: For every new component UI/UX design, We develop the frontend component using Storybook. Storybook gives us an isolated way of developing components. Using Storybook, at the component level we can understand the accessibility issues, if any, and address those. Build components that work well across different themes. We build & publish the Storybook to Chromatic. Chromatic enables us to understand what changed by checking the snapshots. This is useful to understand if any change has caused any regression. We get a UI/UX review within Storybook before merging the feature branch to target branch. On UI/UX approval, then build the same component on CMS. When the stakeholders managing the content access CMS and see the new components that could be used, they refer to the Storybook hosted on Chromatic to see if the component suits their content needs. When there are large additions, the stakeholders scroll through available components and identify components they could use on a particular page. Once a component is identified on the Storybook, they then check the Storybook docs to understand which field relates to which content on the component. Referring to this, they can easily add/update the content in CMS. This process enables the stakeholders to easily add/edit CMS content, without a difficult-to-read documentation. Storybook essentially serves as our component documentation here. With this, we don’t have to document anything component specific. We still document other aspects of the website like: Overall structure of website - an overview of our site in relation to the internal jargon. Details on identifying the content type within the CMS from the url structure of an existing page on the website. Specifics on pages that have content populated based on the relations created between different entities. The Storybook acts as a component documentation for the developers as well. That way, developers can use components across all products. Summary: Storybook + Chromatic combination enables component development, testing and documentation. It enables development and testing with different themes, accessibility and creating documentation with ease.

For some months, we at WhileOne Techsoft Pvt. Ltd. have been helping our customer setup a system to validate the performance of their SoC platform. In this context, we had to bring up an aarch64 Linux based target image to run on their proprietary hardware SoC platform. Part -1 of this series explains how to build an external toolchain with BuildRoot. Part -2 of this series explains how to build a target Linux image using an external toolchain (that we built in Part -1) Part -3 of this series explains how to integrate the generated toolchain binaries in the target linux image that we are going to build with BuildRoot. Use Case: The reason for integrating external toolchain binaries (especially in an embedded system) is required to run benchmarks on the target. The benchmark software requires a toolchain to be available on the target! In the following steps we shall configure the Buildroot to use the External Toolchain tarball (refer Part -1) to build the Kernel, Rootfs images and copy the extracted tarball binaries to the target under directory /usr We have to modify the configuration and then rebuild using clean option. This will delete all output folders and files. So, its very important to move the tarball to some other location outside the ‘buildroot’ folder. If not yet done, please do this before proceeding ahead 1. Start by opening menuconfig make menuconfig We only modify a few options. Rest of the options will remain the same as was configured earlier. Target Options and Build Options shall remain same. So no need to change them 2. Modify Toolchain Options: a. Select option ‘External Toolchain’ b. Modify option of Toolchain origin to ‘Toolchain to be downloaded and installed’ c. Update URL to ‘file:///path/to/sdk-tarball’ d. Modify External Toolchain GCC version to ’11.x’ e. Modify External Toolchain kernel headers series to ‘5.4.x’(This was same configuration that we had kept for tarball earlier..) f. Modify External Toolchain C library to ‘glibc/eglibc’ g. Disable ‘Toolchain has RPC support’ (Please disable if it was not selected earlier during tarball generation) h. Enable support for C++ and Fortran(This was enabled earlier for tarball configuration) a. Modify Init system from ‘None’ to ‘BusyBox’ b. Enable option ‘Use symlinks to /usr for /bin, /sbin and /lib c. Modify default BusyBox shell from ‘None’ to ‘/bin/sh/’ d. Update the folder name (gcc-11.x) for option ‘Root filesystem overlay directories’. We haven’t created this folder yet! Just add the name. 4. Create a folder (gcc-11.x) in root location of ‘buildroot’ 5. Extract the sdk tarball and copy contents to this folder 6. Inside folder gcc-11.x, create a folder named ‘usr’ and move the folders bin, lib and sbin to usr/ This step is very important because when BR2_ROOTFS_MERGED_USR (This flag corresponds to the option enabled in step 2 above) is enabled, then the overlay must not contain the /bin, /lib or /sbin directories, as Buildroot will create them as symbolic links to the relevant folders in /usr. In such a situation, should the overlay have any programs or libraries, they should be placed in /usr/bin, /usr/sbin and /usr/lib. The same should also be followed for other folders inside gcc-11.x. Once this is completed, then we can proceed ahead. If the above changes are not done, then we will encounter an RSYNC error. 7. Now, save and exit from menuconfig 8. Build with new configuration settings make clean all 9. The resulting images can be seen in the folder ‘output/images’ 10. Finally, verify that the Target folder contains the Toolchain binaries in path ‘output/target/usr/bin’, ‘output/target/usr/lib’, ‘output/target/usr/sbin’. This means that the final Linux Image will be having these binaries integrated in it. 11. The only way to verify is to boot the Linux image on your end and once booted and logged in, you need to ensure that you do not forget to set the LD_LIBRARY_PATH variable to point to the /usr/lib where the Toolchain libraries will be installed. Conclusion: We were able to successfully build an External Toolchain (generated as an SDK tarball) [This concludes our final Part in the BuildRoot series] A quote that has inspired me for a long time… “Obstacles don’t have to stop you. If you run into a wall, don’t turn around and give up. Figure out how to climb it, go through it, or work around it.” — Michael Jordan Part 1- https://www.whileone.in/post/how-to-create-an-external-toolchain-in-buildroot-part-1 Part 2 - https://www.whileone.in/post/external-toolchain-in-build-root-from-part-1-to-generate-rootfs-linux-part-2

For some months, we at WhileOne Techsoft Pvt. Ltd. have been helping our customer setup a system to validate the performance of their SoC platform. In this context, we had to bring up an aarch64 Linux based target image to run on their proprietary hardware SoC platform. Part -1 of this series explains how to build an External Toolchain with BuildRoot. Part -2 of this series explains how to build a Target Linux image and Rootfs in BuildRoot using the External Toolchain that we built in Part -1 Part -3 of this series explains how to integrate the generated External Toolchain binaries inside the Target Linux image using BuildRoot In the following steps we shall configure the Buildroot to use the External Toolchain tarball(refer Part -1)to build the Kernel and Rootfs images and copy the extracted tarball binaries to the target under directory /usr We have to modify the configuration and then rebuild using clean option. This will delete all output folders and files. So, its very important to move the tarball to some other location outside the ‘buildroot’ folder. If not yet done, please do this before proceeding ahead 1. Start menuconfig make menuconfig We only modify a few options. Rest of the options will remain the same as was configured earlier in Part -1. Target Options and Build Options shall remain same. So no need to change them 2. Modifying Toolchain Options: a. Select option ‘External Toolchain’ b. Modify option of Toolchain origin to ‘Toolchain to be downloaded and installed’ c. Update URL to ‘file:///path/to/sdk-tarball’ as shown below. d. Modify External Toolchain GCC version to ’11.x’(We used GCC-11.x to cross-compile the external toolchain in Part -1) e. Modify External Toolchain kernel headers series to ‘5.4.x’(This was same configuration that we had kept for tarball earlier in Part -1) f. Modify External Toolchain C library to ‘glibc/eglibc’ g. Disable ‘Toolchain has RPC support’(Please disable if it was not selected earlier during tarball generation) h. Enable support for C++ and Fortran(This was enabled earlier for tarball configuration) a. Modify Init system from ‘None’ to ‘BusyBox’ b. Enable option ‘Use symlinks to /usr for /bin, /sbin and /lib c. Modify default BusyBox shell from ‘None’ to ‘/bin/sh/’ 7. Now, save and exit from menuconfig 8. Build with new configuration settings make clean all 9. Once the build is successful, the resulting images can be seen in the folder ‘output/images’ We were able to generate Rootfs and aarch64 Linux images by compiling with the External Toolchain that was earlier built in Part 1 https://www.whileone.in/post/how-to-create-an-external-toolchain-in-buildroot-part-1 [Check out Part -3 to know more on how to integrate the External Toolchain binaries inside the Target Linux Image https://www.whileone.in/post/how-to-integrate-external-toolchain-generated-in-part-1-inside-the-target-linux-image-in-buildroot ] A quote that has inspired me for a long time… “Obstacles don’t have to stop you. If you run into a wall, don’t turn around and give up. Figure out how to climb it, go through it, or work around it.” — Michael Jordan

Background: ​ For some months, we at WhileOne Techsoft Pvt. Ltd. have been helping our customer setup a system to validate the performance of their SoC platform. In this context, we had to bring up an aarch64 Linux based target image to run on their proprietary hardware SoC platform. Part-1 of this series explains how to build an External Toolchain with BuildRoot. Part -2   of this series explains how to build a Target Linux image and Rootfs in BuildRoot using the External Toolchain that we built in Part-1 Part -3   of this series explains how to integrate the generated External Toolchain binaries(built in Part -1)inside the Target Linux image using BuildRoot Tools and Development station: Buildroot ( www.buildroot.org ) AWS aarch64 ubuntu based instance with 50GiB SSD and 8GiB RAM(Free Tier instances with drive space < 20GiB will fail during build process) SSH client(Putty or WSL2 Ubuntu VM for windows ) Why Buildroot? Buildroot is a tool that automates the process of building a complete Linux system for an embedded system, using cross compilation. It has a significantly lesser learning curve as compared to another popular tool Yocto. Yocto supports designing complex Linux systems using a plethora of recipes(customization scripts) whereas Buildroot supports quicker prototype designs targeted mainly for embedded systems. Challenges? Although Buildroot does not support toolchains generated by Yocto, OpenEmbedded or even GCC. So, any of these toolchain binaries cannot be used directly as the external toolchain. But, Buildroot provides an alternate way where we can create an external toolchain based on glibc, musl or uClibc-ng and cross-compile these with a choice of GCC v11.x or v12.x Prepare the remote system for build: First, we need to log in to the remote (aarch64) instance with IP address using either Putty or any other SSH tool of your choice. I have connected to the remote instance via SSH from WSL2 (Windows Subsystem Linux) Ubuntu on Windows 11. On successful login to ubuntu instance, we need to prepare it by installing needed dependencies for Buildroot to work properly. 1. From AWS website, using your account, launch an AWS Ubuntu aarch64 instance (c6g.2xlarge) [around 8GB RAM and 50GB SSD volume], generate keypair and store on local windows 11 system (Tutorial for launching your own instances can be found online or on aws website) 2. Launch WSL2 Ubuntu OS (Installation of WSL2 is beyond the scope of this article) Welcome to Ubuntu 20.04.4 LTS (GNU/Linux 5.10.16.3-microsoft-standard-WSL2 x86_64)* Documentation: https://help.ubuntu.com   Management: https://landscape.canonical.com   Support: https://ubuntu.com/advantage@:~$ 3. To copy the keypair on local system to Ubuntu WSL2, we need to open location “\\WSL$” in windows explorer. This will display folder structure with Ubuntu as primary and the only folder. Navigate to “Ubuntu/home/” and copy the keypair to this location (other location can also be used as per convenience) 4. Run the below command to connect to remote aws instance ssh -i ubuntu@ 5. If connection is successful, an ubuntu prompt shall be displayed Welcome to Ubuntu 20.04.4 LTS (GNU/Linux 5.13.0-1029-aws aarch64)* Documentation: https://help.ubuntu.com * Management: https://landscape.canonical.com * Support: https://ubuntu.com/advantageSystem information as of Fri Jul 1 13:55:38 UTC 2022System load: 0.0 Processes: 186 Usage of /: 41.2% of 28.91GB Users logged in: 0 Memory usage: 7% IPv4 address for ens5: 172.31.58.93 Swap usage: 0%* Ubuntu Pro delivers the most comprehensive open source security and compliance features.https://ubuntu.com/aws/pro11 updates can be applied immediately. To see these additional updates run: apt list --upgradableLast login: Thu Jun 30 20:05:55 2022 from 17x.4x.3x.5x ubuntu@ip-17x-3x-5x-9x:~$ 6. Run below command to verify system details of remote instance 7. Run below required commands to install dependencies. The package libncurses-dev is needed for menuconfig to work properly sudo apt updatesudo apt-get install build-essential libncurses-dev 8. Clone buildroot repository git clone git:// git.buildroot.net/buildroot 9. Prepare the build for aarch64 platform. Get command from readme.txt vi buildroot/board/aarch64-efi/readme.txt 10. Execute the command to configure for aarch64 make aarch64_efi_defconfig 11. Execute command to display menuconfig GUI make menuconfig 12. Menuconfig is visible as shown below 13. Modify Target Options (Select Architecture): 14. Modify Toolchain Options: Select toolchain as Buildroot toolchain, C library as glibc, Kernel headers < version of kernel that is built, gcc version 11.x, Enable Fortran support 15. Modify options for System configuration: 16. Modify options for Target packages (Disable option busybox): 17. Modify options in Filesystem Images: 18. Save and exit from "menuconfig" UI 19. Run command “make sdk” on terminal 20. SDK is built successfully. The log after generation of SDK is shown below. >>> Rendering the SDK relocatablePER_PACKAGE_DIR=/home/ubuntu/buildroot/output/per-package /home/ubuntu/buildroot/support/scripts/fix-rpath hostPER_PACKAGE_DIR=/home/ubuntu/buildroot/output/per-package /home/ubuntu/buildroot/support/scripts/fix-rpath staging/usr/bin/install -m 755 /home/ubuntu/buildroot/support/misc/relocate-sdk.sh /home/ubuntu/buildroot/output/host/relocate-sdk.shmkdir -p /home/ubuntu/buildroot/output/host/share/buildrootecho /home/ubuntu/buildroot/output/host > /home/ubuntu/buildroot/output/host/share/buildroot/sdk-location>>> Generating SDK tarballtar czf "/home/ubuntu/buildroot/output/images/aarch64-buildroot-linux-gnu_sdk-buildroot.tar.gz" \--owner=0 --group=0 --numeric-owner \--transform='s#^home/ubuntu/buildroot/output/host#aarch64-buildroot-linux-gnu_sdk-buildroot#' \-C / home/ubuntu/buildroot/output/host 21. Verify if the tarball ‘aarch64-buildroot-linux-gnu_sdk-buildroot.tar.gz’ is available in the folder ‘buildroot/output/images’ 22. Copy this tarball to some external location in ‘home/ubuntu’ outside the ‘buildroot’ directory. mv output/images/aarch64-buildroot-linux-gnu_sdk-buildroot.tar.gz ~ In Part-2, we will use this tarball for generating a root file system and a kernel image by compiling the kernel with the newly generated External Toolchain Conclusion: A quote that has inspired me for a long time… “Obstacles don’t have to stop you. If you run into a wall, don’t turn around and give up. Figure out how to climb it, go through h it, or work around it.” — Michael Jordan Part 2 : https://www.whileone.in/post/external-toolchain-in-build-root-from-part-1-to-generate-rootfs-linux-part-2 Part 3 : https://www.whileone.in/post/how-to-integrate-external-toolchain-generated-in-part-1-inside-the-target-linux-image-in-buildroot

Modern compute platforms - from cloud hyperscale CPUs to edge processors - deliver unprecedented parallelism and instruction-set capabilities. But to truly understand performance, you need the right benchmarking tools. Whether you're comparing cloud instances, evaluating Arm-based servers like Ampere, or validating x86, RISC-V, or AI-accelerated hardware, the ecosystem offers several battle-tested frameworks. In this blog, we explore the most widely-used CPU benchmarking toolkits today - what they do, where they shine, and when to use each. 1. Ampere Performance Toolkit (APT) Ampere’s servers built on Arm architecture are optimized for cloud-native performance and power efficiency. The Ampere Performance Toolkit provides a set of scripts, automation, and recommended benchmarks to evaluate real-world workloads. Key Features Best For ✔ Evaluating Arm server performance ✔ Cloud benchmarking on Ampere instances ✔ Developers migrating workloads from x86 to Arm 2. PerfKit Benchmarker (Google) Originally built by Google, PerfKit Benchmarker (PKB) is the gold standard for cloud performance benchmarking across providers. Key Features Best For ✔ Comparing cloud VM types ✔ Reproducible benchmark automation ✔ Cloud procurement and architectural evaluations Fun fact: PKB has become the foundation for multiple forks and extensions across companies and academia for transparent benchmarking. 3. Phoronix Test Suite (PTS) The Phoronix Test Suite is one of the largest open-source benchmarking ecosystems—great for developers and hardware reviewers. Key Features Best For ✔ Broad CPU and system benchmarking ✔ Linux performance testing ✔ Reviewers, researchers, and enthusiasts 4. SPEC CPU Suite The Standard Performance Evaluation Corporation (SPEC) CPU suites are industry-trusted benchmarks for vendors and OEMs. Key Features Best For ✔ Enterprise-grade server benchmarking ✔ Official vendor comparisons ✔ Performance engineering and compiler tuning Note: Requires paid license. 5. Microbenchmark Suites (Core Latency, Memory, IPC) Sometimes, detailed architectural behavior matters more than high-level scores. Popular Tools Best For ✔ Low-level CPU behavior ✔ Memory latency & bandwidth analysis ✔ Performance debugging ML & AI-Centric Benchmarks (Emerging) Even CPU evaluations increasingly involve AI workloads. Best For ✔ AI inference on CPUs ✔ Edge compute & acceleration evaluations Bonus: Build-Your-Own Benchmark Harness Cloud providers and silicon vendors often implement custom harnesses around: Docker-ized workloads Kubernetes load-generation frameworks Real-app benchmarking (Redis, NGINX, PostgreSQL, Spark) For engineering teams, custom workload pipelines often reveal more than synthetic scores. Summary Table Toolkit Scope Best Use Case Ampere Performance Toolkit Server-class Arm systems Cloud-native Arm benchmarking PerfKit Benchmarker Multi-cloud benchmarking Cloud instance comparisons Phoronix Test Suite Broad system benchmark suite Linux and multi-OS testing SPEC CPU Industry standard CPU benchmarks Formal server performance publication sysbench / lmbench / perf Microbenchmarks & counters CPU profiling & tuning MLPerf / HPL / HPCG AI & HPC performance Compute-heavy + scientific workloads

1. The Software Ecosystem is Now the Core Focus The most significant shift was the overwhelming emphasis on software, tools, and developer experience. Platform Mindset: Keynote speakers, including executives from major players, stressed the need to view RISC-V not just as an ISA (Instruction Set Architecture) but as an ecosystem that requires platform-level thinking. The message was clear: no single company can build the entire software stack alone; continued, sustained community collaboration is essential for scaling. "Paved Road" for Datacenters: Google highlighted its efforts in creating a "paved road" for RISC-V adoption, including using AI-driven tooling to automate the complex process of porting their software stack from proprietary architectures to RISC-V. This signals that major hyperscalers are actively engineering solutions to remove friction for developers. 2. High-Performance Computing & AI Get a Massive Boost RISC-V's expansion into high-end compute was the major theme, driven by announcements from key hardware and software vendors. Data Center and Chiplet Traction: Companies showcased their progress with "real silicon, real systems," emphasizing their full-stack approach to high-performance RISC-V for data center and automotive platforms, often using advanced chiplet-based designs. 3. The Rise of Vertical-Specific Dominance The Summit showcased clear evidence of RISC-V achieving market dominance in specific vertical industries beyond its traditional embedded roots. Aerospace & Defense: NASA's presence and keynotes highlighted the critical role of RISC-V in the High Performance Spaceflight Computing (HPSC) initiative, with radiation-hardened Microchip processors (using SiFive cores) becoming the standard for next-generation space missions. Security & Sovereignty: Keynotes explored the convergence of RISC-V with modern cryptography and blockchain technologies, demonstrating its potential to power the next wave of secure, decentralized systems and enhance technological sovereignty for nations and enterprises. 4. Standardization Efforts Mature (RVA23 and Beyond) Technical standardization gained clarity, providing a more stable target for both hardware and software development. RVA23 Stability: The focus was on the recently ratified RVA23 Profile (RISC-V Application Profile 2023), which provides a stable baseline for application-class processors. The community signaled a move toward incremental updates (like RVA23p1, RVA23p2) rather than annual major releases, which helps stabilize the software ecosystem. Developer Training: The addition of an official, separately ticketed Developer Workshop track and a RISC-V 101 track showed the community's commitment to aggressively onboarding new talent and accelerating the application of the open standard. 5. New Open-Source Development Programs A major announcement focused on making RISC-V hardware and software more accessible to the global open-source community: DeepComputing's Global RISC-V Support Programs: DeepComputing launched a major initiative designed to accelerate open innovation by providing hardware and ecosystem support to three key areas: "100 Open Source Projects" Program: This is specifically designed to support open-source communities with RISC-V hardware (like the DC-ROMA AI PC), testing environments, and collaboration opportunities to drive upstream contributions to the RISC-V software stack. The initiative also includes "100 Schools & Universities" and "100 AI Startups" programs, broadening the use of open RISC-V platforms. The Scaleway Labs Elastic Metal RV1 (EM-RV1) is a notable open-source platform, primarily because it's the world's first dedicated RISC-V server offering in the cloud.1 Scaleway, a European cloud provider, launched this offering in early 2024 as part of their Scaleway Labs to enable developers and companies to easily test and develop on the RISC-V architecture. While it wasn't launched at the RISC-V Summit North America 2025 (as its launch date was earlier), it represents a major milestone for the open-source ecosystem, providing essential cloud infrastructure for RISC-V software development, and was certainly a topic of discussion at the summit. Key Specifications and Open-Source Relevance Feature Details Open-Source Relevance Type Bare Metal (Dedicated) Server in the Cloud Full control of the RISC-V hardware, ideal for kernel development and low-level testing. SoC Alibaba T-Head TH1520 Utilizes an open-source-friendly processor with an RISC-V core. CPU 4x T-Head C910 RISC-V 64GC cores @ 1.85 GHz Provides a modern, multi-core RISC-V development environment. RAM 16 GB LPDDR4 Sufficient memory for building and testing complex applications. Storage 128 GB eMMC Basic storage, consistent with its use as an affordable development/CI/CD platform. Operating Systems Debian, Ubuntu, Alpine Linux Support for major open-source Linux distributions, highlighting software ecosystem maturity. AI Capabilities Integrated NPU (4 TOPS @ INT8) Allows for testing and development of AI/ML workloads on the RISC-V architecture using open-source frameworks like TensorFlow and ONNX. Design Designed and assembled in-house in Paris (Scaleway Labs) A commitment to technological independence and fostering the European RISC-V supply chain. The ISCAS RUyiBook (or Ruyi Book) is a RISC-V-based laptop, developed through a collaboration that includes the Institute of Software at the Chinese Academy of Sciences (ISCAS), Milk-V, and Inchi. It is a significant project in the open-source hardware and software community, aiming to create a fully functional, mainstream-capable computing platform based on the open-standard RISC-V Instruction Set Architecture (ISA). Key Features and Specifications The RuyiBook is an effort to demonstrate the maturity of the RISC-V ecosystem for general-purpose computing. Component Details Significance Processor (SoC) XiangShan Nanhu (second-generation) An impressive high-performance, open-source RISC-V chip design. CPU Clock Up to 2.5 GHz This clock speed pushes RISC-V toward performance parity with established x86 and ARM architectures for mainstream tasks. Memory 8GB DDR5 Utilizes modern, high-speed memory for better system performance. Graphics AMD RX 550 (Discrete GPU) Uses a closed-source but powerful discrete GPU to handle modern graphical workloads and external displays up to 4K resolution. Operating System Primarily runs openEuler OS (with EulixOS 2.0-RV/PolyOS 2.0-RV desktop options) Showcases a full, streamlined RISC-V software stack, from the bottom-layer processor to large-scale office software like LibreOffice. Goal Technological Independence Part of a broader effort in China to reduce reliance on proprietary foreign technologies (like x86 and ARM) by leveraging the open and royalty-free nature of RISC-V. 6. The QiLai SoC Chip The heart of the platform is the QiLai System-on-Chip (SoC), which is a test chip manufactured on TSMC's advanced 7nm process technology. It features a heterogeneous computing architecture, combining two different types of high-performance Andes RISC-V cores: Component Description Target Application Main CPU Cluster (AX45MP) A quad-core cluster of RV64GC 64-bit processors. It has an 8-stage superscalar pipeline, a Memory Management Unit (MMU), and a 2MB Level-2 cache with a coherence manager. Running rich operating systems like Linux (including a Linux SMP system) and general-purpose application processing. Vector Processor (NX27V) A dedicated RV64 GCV 64-bit vector processor with a streamlined 5-stage scalar pipeline and a large data cache. It features a 512-bit vector length (VLEN) and data path width (DLEN). High-throughput data processing and acceleration for AI/ML workloads. Performance The AX45MP can run up to 2.2 GHz, and the NX27V up to 1.5 GHz. The entire SoC has a low power consumption of approximately 5W at full speed. 7. The Voyager Development Board The QiLai SoC is integrated onto the Voyager Development Platform, a Micro-ATX form factor motherboard. This board provides a full PC-like environment for developers, including: System Memory: Support for up to 16GB of external DDR4 memory. Storage: M.2 NVMe SSD support and MicroSD card socket. Expansion: Multiple PCIe Gen4 slots (x16, x4) for integrating peripherals like external GPUs, SSDs, and AI accelerator cards. 8. Target Applications and Ecosystem The QiLai Platform is a crucial step in maturing the RISC-V ecosystem for high-end computing. Its target applications include: AI/ML and Edge AI: The heterogeneous architecture allows the AX45MP to run the main OS while the NX27V is dedicated to accelerating machine learning inference and training. High-Performance Computing: General-purpose computing, augmented reality (AR), virtual reality (VR), and multimedia processing. RISC-V PC Development: The platform is the foundation for collaborative projects, such as the effort with DeepComputing to develop the "World's First RISC-V AI PC" running Ubuntu Desktop. The platform is supported by a full software stack, including the OpenSUSE Linux distribution, Andes' toolchains (AndeSight), and their dedicated AI/ML SDK (AndesAIRE NN SDK). The SiFive HiFive Unmatched is a high-performance RISC-V development platform designed by SiFive to facilitate the creation and porting of software for RISC-V-based desktop and server applications. It is notable for being one of the first RISC-V development boards to adopt a standard PC form factor, making it much easier to integrate into a standard computer enclosure with common peripherals. Key Features and Specifications Component Detail SoC SiFive Freedom U740 (FU740) CPU Architecture Heterogeneous Multi-core: A cluster of five 64-bit RISC-V cores. Cores Quad-core SiFive U74-MC (U-series are Linux-capable application cores) and Single SiFive S7 (S-series is a real-time monitor core for auxiliary/deterministic tasks). Core ISA RV64GC ($\text{RV64IMAFDC}$) for the U74 cores, RV64IMAC for the S7 core. Frequency Up to 1.2 GHz (initial releases), with later revisions capable of higher speeds. Cache 2MB Coherent Banked L2-Cache, plus L1 caches per core. Form Factor Mini-ITX ($170 \text{ mm} \times 170 \text{ mm}$), enabling use with standard PC cases. System Memory 16 GB of 64-bit DDR4 DRAM. Expansion Slots 1x PCI Express Gen 3 x16 connector (with 8 lanes useable) for graphics cards or accelerators. Storage 1x M.2 M-Key (PCIe Gen 3 x4) for NVMe SSD. Connectivity Gigabit Ethernet (10/100/1000 Mbps), 4x USB 3.2 Gen 1 Type-A ports, M.2 E-Key for Wi-Fi/Bluetooth. Power Standard 24-pin ATX power connector. Software Ships with a bootable SD card containing the Freedom U-SDK (based on Yocto/OpenEmbedded Linux), OpenSBI, and U-Boot. It is supported by various Linux distributions like Debian and openSUSE.

Inspiration In high-throughput production environments, every sensor reading tells a story. Test systems continuously record Pressure, Temperature, and Differential Loss (DL) across thousands of cycles, but much of this data remains passive, observed but not interpreted. We set out to change that by deploying machine learning directly at the edge on a BeagleBone Black board. The goal was not anomaly detection, but live inference: to compute what the ideal DL should be (DL_pred) under current conditions and instantly compare it to the measured DL. The outcome was a self-aware test station capable of interpreting its own sensor data in real time. Use Case: Predicting DL via Edge Inference During each test cycle, the system measures: Pressure (P): applied load during testing Temperature (T): ambient or component temperature Differential Loss (DL): observed pressure decay Because DL depends heavily on both T and P, fixed thresholds can mislead operators when environmental drift occurs. Our solution trains a regression model that learns the baseline relationship between these variables and deploys it locally to predict DL_pred for every new test. At runtime: The sensors stream T and P values to the model. The model infers DL_pred = f(T, P) in real time. The system computes the deviation: Deviation=DLactual−DLpred\text{Deviation} = DL_{actual} - DL_{pred}Deviation=DLactual​−DLpred​ This enables contextual interpretation, distinguishing true defects from environmental variation instantly, without recalibration or cloud dependence. Mathematical Foundation: Ridge Regression at the Edge We model the relationship as: DL=β0+β1T+β2P+ϵDL = \beta_0 + \beta_1 T + \beta_2 P + \epsilonDL=β0​+β1​T+β2​P+ϵ Since T and P often correlate, we apply Ridge Regression with L2 regularization: Loss=∑i=1n(DLi−DLi^)2+λ∑j=1pβj2\text{Loss} = \sum_{i=1}^{n}(DL_i - \hat{DL_i})^2 + \lambda \sum_{j=1}^{p}\beta_j^2Loss=i=1∑n​(DLi​−DLi​^​)2+λj=1∑p​βj2​ Why Ridge Regression? Stabilizes results under multicollinearity Penalizes large coefficients to avoid overfitting noisy sensor data Lightweight and suitable for low-power boards Explainable, as coefficients show how T and P affect DL Easily portable to TensorFlow Lite for edge inference Experiment Methodology 1. Data Acquisition and Pre-processing Gathered Pressure and Temperature from onboard sensors Collected DL from completed test cycles Aligned data by timestamp (HH:MM) Filtered operational ranges (Temp 46–48 °C, DL 20–32) Exported cleaned_pressure_data.csv for model training 2. Model Training (Offline) Algorithm: Ridge Regression (DL ~ Temp + Pressure) Validation: PCA and Mutual Information for feature strength Conversion: TensorFlow Lite FP32 model via Docker docker run --rm -it -v "$PWD":/work -w /work tensorflow/tensorflow:2.4.0 bash 3. Edge Inference (Runtime) Deployed on BeagleBone Black using tflite-runtime with Python 3.9. import tflite_runtime.interpreter as tflite interpreter = tflite.Interpreter(model_path="ridge_linear_fp32.tflite") interpreter.allocate_tensors() At each cycle: Read T and P in real time Feed inputs into the model Run inference to generate DL_pred Compare DL_pred with DL_actual to compute deviation DL_pred is generated dynamically after each inference cycle, not pre-calculated. 4. Diagnostics Interface A built-in local web dashboard provides: Real-time DL vs DL_pred visualization Network configuration (DHCP/Static) CPU usage, logs, and debug metrics Results Metric Description Outcome Model Type Ridge Regression (L2) Lightweight and robust Device BeagleBone Black ARM Cortex-A8 CPU Inference Latency Time per DL_pred computation 15 ms Prediction Accuracy Mean absolute error ±1.5 DL units Memory Usage Runtime footprint < 40 MB Network Dependency Fully local operation Edge inference at 15 milliseconds per cycle delivers immediate feedback to operators, enabling process decisions before the next test unit enters evaluation. Key Advantages Real-time predictive insight at the data source Eliminates false rejects caused by ambient drift Explainable regression coefficients for auditability No cloud latency, ensuring on-bench decision-making Minimal resource consumption, scalable across multiple setups Future Enhancements Expansion to multi-sensor fusion (temperature, torque, flow, vibration) Integration of non-linear regressors or compact neural networks for complex patterns Incremental learning for continuous self-calibration Visualization through Grafana dashboards for centralized monitoring Conclusion By generating the predicted DL (DL_pred) directly on-device after each inference cycle, the system evolves from a static tester into a real-time predictive platform. This architecture minimizes false rework, enhances test reliability, and demonstrates that intelligence can reside within the manufacturing floor rather than in remote data centers. Fifteen milliseconds is all it takes to transform raw sensor data into actionable insight at the edge.

In the world of software development, the GNU Debugger (GDB) is an essential tool for programmers. It allows us to peer inside a running program, find bugs, and understand complex code. As new hardware architectures emerge, it's crucial that our tools keep pace. One such rising star is RISC-V, an open-source instruction set architecture that is rapidly gaining popularity, particularly with its new vector extensions for high-performance computing. The Challenge: An Unknown Instruction Recently, our team took on a task to get a few bug fixes into gdb. The challenge: GDB was unable to recognize or debug vector instructions for the RISC-V architecture. This was a significant gap, hindering developers who were working with advanced RISC-V features. Without this support, debugging modern, high-performance RISC-V applications was a major challenge. My task was to dive into the GDB source code and enable this missing capability. Navigating a Sea of Code The first and most significant hurdle was the sheer scale of the GDB codebase. As a newcomer to such a vast and mature open-source project, understanding the intricate flow of control and finding the right place to intervene was a daunting task. The initial phase involved a lot of learning and exploration, and I'm grateful for the guidance of my colleagues who helped me navigate the complexities and build a mental map of the system. Through a careful process of debugging the debugger itself, we were able to trace the execution path for instruction processing. The breakthrough came when we identified the root cause of the issue: there was a missing function call responsible for reading and interpreting the new vector instructions. The logic was there, but it was never being invoked for this specific case. With the problem identified,we implemented an initial solution. Our contribution involved a hardcoded fix that proved the concept and successfully enabled GDB to recognize the vector instructions. This initial patch paved the way for a more robust and integrated solution that was later refined by other contributors in the open-source community. The result is a direct enhancement to a critical developer tool. Programmers working with RISC-V can now debug vector-based code more effectively, accelerating development and improving software quality within the ecosystem. https://www.sourceware.org/pipermail/gdb-patches/2025-May/217880.html

We recently worked on extending Intel Perfspect (https://github.com/Whileone-Techsoft/PerfSpect/tree/Neoverse-native-support), a robust, command-line performance analysis tool that implements the Top-Down Microarchitecture Analysis Method (TMAM). It fully supports the Arm Neoverse-V2 architectures. This project required mapping the Performance Monitoring Unit (PMU) events on the ARM cores to the metrics of TMAM methodology. We can now get the Level 1 breakdown (Frontend Bound, Backend Bound, Retiring, Lost) to pinpoint the bottlenecks on respective systems, which was previously incompatible with this tool. Through debugging the code, it became possible to generate the continuous series graphs to understand if the bottleneck. This extension of Perfspect for Arm (our code allows native compilation on ARM) allowed the capture of the CPU utilization HeatMap generated in Telemetry reports, which shows the distribution of work across all cores over time. The challenge was mapping the Arm events to the TMAM formulae, and then correctly comparing the captured values through the modified Perfspect tool with the values that were manually calculated using the formulae. The key learnings from this project were quickly adapting to a new programming language like Go(Golang) and making significant changes in the code to get the appropriate results, also adding to the knowledge of TMAM methodology and the specific challenges of cross-architecture analysis, particularly in translating PMU events from the Intel ecosystem to Arm's Neoverse-V2 core.

The Leap into the Unknown Stepping out of the academic bubble and into the professional world is often painted as a daunting transition. For us, it was less a leap of faith and more an excited dive into the deep end, specifically, into the innovative waters of WhileOne.Our motivation to join was simple yet profound: we sought a place where curiosity was celebrated, challenges were seen as growth opportunities, and real-world impact was a daily pursuit. Little did we know that this internship would not just introduce us to company life but fundamentally reshape our technical acumen and career outlook. Interns Interning Unpacking the Technical Toolkit: What we've Learned: Tanaya Ajgar: Diagnostic Configuration Dashboard for BeagleBone Black: I developed a diagnostic configuration page for the BeagleBone Black board, which gave me valuable hands-on experience in full-stack development. I worked on building a responsive React + HTML frontend and integrated it with a Python Flask backend to enable seamless communication with the board. Through this, I learned how to design and implement interactive dashboards that allow users to configure system parameters such as IP addresses and ensure that the updates persist at the system level. I also gained practical knowledge of storing configuration results in both SQLite databases and JSON files for reliability and easy retrieval. This project helped me strengthen my understanding of REST APIs, data flow between frontend and backend, and the importance of efficient database integration in embedded system applications. I also improved my debugging skills while resolving real-time hardware-software interaction issues. Additionally, I learned how to apply UI/UX practices to make technical dashboards more intuitive and user-friendly. Overall, the project enhanced my skills in embedded system integration, web technologies, and problem-solving in a real-world scenario. Soham Gargote: During my internship, I had the valuable opportunity to contribute to two diverse and impactful projects. I delved into low-level systems programming by extending the open-source GDB debugger to enable support for RISC-V vector instructions. In parallel, I was instrumental in creating a new internal tool for benchmark management, where I developed the backend for its UI/UX visualization capabilities. This dual exposure to both open-source contributions and internal tool development made for an incredibly fun and enriching learning experience, significantly strengthening my software engineering skills. Saee Gade : RISC-V Toolchain Validation & Compiler Fuzzing As an intern, my work on RISC-V toolchain validation taught me the immense value of compiler fuzzing and its role in software reliability. I gained hands-on experience using tools like Csmith to automatically generate complex test cases and uncover hidden bugs. Beyond just bug hunting, the project's most significant takeaway for me was the process of creating high-quality, actionable bug reports. I learned the critical skill of creating minimal, reproducible test cases and effectively communicating findings to developers on platforms like Bugzilla. Contributing to major open-source projects like GCC and LLVM showed me the real-world dynamics of collaborative development and the tangible impact my work could have on improving the stability of a key toolchain for an entire ecosystem. Ruchi Joshi : Technical takeaways from Benchmarking project: Through hands-on experience with benchmarking, I learned to evaluate system performance using industry-standard HPC benchmarks like MiniFE and HPCG. I gained practical skills in writing automated shell scripts to test CPU and GPU performance across different architectures. This project also provided me with the opportunity to work with low-level hardware performance counters, learning to collect data on retired instructions, cache misses, and branch mispredictions. I now understand how to translate this raw data into higher-level microarchitecture insights using Intel's Top-Down Microarchitecture Analysis Methodology (TMAM) to identify critical bottlenecks. Furthermore, I explored ARM's Performance Monitoring Unit (PMU), which gave me insight into the distinct tooling and counter availability between Intel and ARM ecosystems. This holistic experience has provided me with a comprehensive understanding of performance analysis from high-level application benchmarks down to low-level hardware counters. The WhileOne Way: A Glimpse into Company Life Our general experience as interns has been overwhelmingly positive. The atmosphere at WhileOne is one of collaborative energy, where questions are encouraged, and mentorship is readily available. It’s a far cry from the sometimes solitary nature of academic projects. Joining WhileOne feels like becoming part of a forward-thinking family. There’s a palpable sense of innovation and a shared drive to create impactful solutions. The differences between college and company life are stark but refreshing. In college, deadlines can feel somewhat arbitrary, and projects often exist in a vacuum. Here, every task has a purpose, directly contributing to a product or service. The pace is faster, the stakes are higher, but the support system is robust. Learning is continuous, driven by real-world problems rather than theoretical exercises. Navigating Opportunities and Challenges Our internship presented a wealth of opportunities: Direct contribution to live projects: This was incredibly motivating, seeing our codes go into production. Mentorship from experienced engineers: Their guidance has been instrumental in our growth. Exposure to diverse technologies and methodologies: Expanding our technical horizons significantly. Challenges were equally present and equally valuable: Steep learning curve: Rapidly adapting to new tools and complex systems. Problem-solving under pressure: Learning to debug efficiently and think critically when faced with unexpected issues. Balancing multiple tasks: Juggling different responsibilities and prioritizing effectively. A New Beginning As we reflect on our journeys from curious students to contributing members of the WhileOne team, we are filled with gratitude and excitement. This internship has been more than just a stepping stone; it's been a foundational experience that has shaped our technical abilities, professional outlook, and career aspirations. The transition from classroom concepts to production code has been challenging yet incredibly rewarding. If you're considering an internship, especially one where real impact is made, we wholeheartedly recommend diving in. The future, for us, is bright and brimming with code, collaboration, and continuous learning all thanks to my transformative time at WhileOne.

Performance analysis can often feel like searching for a needle in a haystack. When your application isn't running as fast as you'd like, where do you even begin to look? Is it a memory bottleneck? Are you stalling in the CPU's front-end? Answering these questions is critical, but traditional tools can be complex and overwhelming. This is where Intel's PerfSpect comes in. And now, thanks to some recent contributions, this powerful tool is no longer just for x86 systems. I'm happy to share - how I've been able to natively compile PerfSpect on ARM architecture- enabling deep performance analysis on platforms like Neoverse series for processors like Ampere, AWS Graviton, Google Axion, NVIDIA Grace and Microsoft Cobalt series of Processors supporting. Why PerfSpect? A Simpler Path to Performance Insights PerfSpect is a lightweight, command-line performance analysis tool. Its primary strength lies in its use of the Top-Down Microarchitecture Analysis (TMA) methodology. Instead of drowning you in hundreds of raw performance counters, TMA provides a structured, hierarchical way to identify the primary bottleneck in your system. It breaks down CPU cycles into a few high-level categories: Front-End Bound: The CPU isn't getting instructions fast enough. Back-End Bound: Instructions are available, but the execution units are stalled. This is further broken down into: Core Bound: The computation units are the bottleneck. Memory Bound: The CPU is waiting on data from memory or caches. Retiring: The CPU is successfully executing instructions. This is the "good" category. Bad Speculation / Miss: The CPU wasted work on instructions that were ultimately discarded (e.g., due to branch misprediction). By presenting performance data through this lens, PerfSpect makes it incredibly easy to pinpoint the character of your bottleneck and tells you exactly where to focus your optimization efforts. The Competitive Landscape: How Does PerfSpect Compare? PerfSpect doesn't exist in a vacuum. The Linux ecosystem is rich with powerful profiling tools like perf, Intel VTune Profiler, AMD uProf. PerfSpect's unique value is its combination of simplicity, structured TMA methodology, and now, cross-architecture support. It provides actionable insights without the steep learning curve of raw perf or the complexity of a full-blown GUI profiler. My Contribution: Native Support for ARM My primary contribution was to port PerfSpect, enabling it to build and run natively on ARMv8/ARMv9 architectures. This involved mapping the ARM Performance Monitoring Unit (PMU) events to the TMA categories, allowing the same intuitive reporting to work seamlessly on platforms from Ampere, Amazon, and Microsoft. Now, developers can use a single, familiar tool to analyze workloads across different server fleets. Get Started: Build and Run PerfSpect on ARM Ready to try it on your ARM machine? Here’s how you can get it up and running. Prerequisites Ensure you have Python, pip, and the standard Linux performance tools installed. # For Debian/Ubuntu-based systems $ sudo apt-get update $ sudo apt-get install -y python3 python3-pip linux-tools-common linux-tools-generic Step 1: Clone the Repository $ git clone -b Neoverse-native-support https://github.com/Whileone-Techsoft/PerfSpect.git $ cd PerfSpect Step 2: Build Tools Docker for aarch64 $ ./builder/build.sh Step 3: Build Perfspect natively on aarch64 $ make -j Sample TMA image for Graviton4