Pawel Wodnicki

Over the past few days a brain storm brought a very cool idea to me. One basic feature of all RISC architectures reduces memory efficiency and there is a loss of performance due to wasted bandwidth. Values that are smaller than the word size of the processor are either zero or sign-extended before they can be used. This padding costs a lot in bus bandwidth and intermediate storage. CISC architectures do not always require such bloat when processing data. The ALU of a RISC processor is inherently scalar because it can only handle one value at a time. Since CISC processors can operate on values smaller than word size, the question arises: "How can the rest of the word width of the busses and ALUs be used?" The answer to this is SIMD or Single Instruction Multiple Data. Since 8-bit, 16-bit and 32-bit values can be processed without taking up the whole 64-bit bus/register width, you could do multiple of them in parallel. The feature that does this is what I call ϕSemiVec. ϕEng32/48's ALU will be designed in such a way that it can do vector operations using the word width of the architecture. That is, it can do one 64-bit operation, one or two 32-bit operations, one to four 16-bit operations or one to eight 8-bit operations in parallel. It will augment the existing scalar instruction set with little more than seven Count Prefix Bytes. And because Floating Point uses the same formats as the integer instructions, the same can be done with floating point instructions as well. The "Semi" part of ϕSemiVec means that the smaller data sizes can accommodate more data elements than the larger ones. What would require a loop in a RISC processor program might not with ϕEng32/48. Vectors of any size and dimension can be processed by unrolling them and doing them in chunks that are up to word size (double word size in floating point). I have already added the prefixes to the architecture and all I have to do is to update ϕAsm to make use of them. #computers #electronics #programming #SIMD #ISA #RISC #CISC

1

Today we will write two functions that are similar to ones we did earlier. But this time we will detect overflow for signed addition instead of unsigned addition. Doing the add is the same. But detecting overflow is more involved. We feel the pain of having limited resources with RISC-V. Overflow can only happen if the signs of the two source operands are the same. Then, and only then, an overflow happens if the sign of Src1 changes as a result of the add. Here is the RISC-V assembly source: sb_add_:  lb   t0,0(a1) #Src1           lb   t1,0(a2) #Src2           addi t2,x0,t0 #Src1 Copy           xor  t3,t1,t0 #Diff Signs           addi t4,x0,-1 #All 1's           xor  t3,t3,t4 #Same Signs           add  t0,t0,t1 #Do the Add           xor  t4,t2,t0           and  t2,t0,t3 #Chg in Sign           sb   t0,0(a0) #Store Sum           srl  a0,t2,31 #Get Bit           jalr ra       #Done RISC-V is a load/store ISA so we have to load both sources before we do anything else. We then have to make a copy of Src1 in t2 so that we can see if the sign changed. On the 3rd line we test to see if the signs are different using an XOR. But what we really need is to know whether they are the same instead. That means we neet to NOT the result. But RISC-V does not have a NOT. We have to XOR it with all 1's. Register x0 has all 0's but we don't have a register with all 1's so we have to make one in t3. To do this we just load −1 which is all 1's. Then we XOR that with t2 which is the same as a NOT. Next we actually do the add of the two sources. We can then store the byte to the Dst. Next we have to see if the sign changed using another XOR. Finally, we detect overflow with an AND. The high-order bit now contains our Signed Overflow bit which we isolate by shifting it all the way to the right using the srl instruction. This last step was easy and the 3-operand model lets us put it into the return register a0. Now let's do it with /ϕEng32. Our Flags will make it a trivial problem so let's use them! sb_add_: ld     ⓈQ0,sb:(Ⓧ1)         add?Ⓒ0 ⓈQ0,sb:(Ⓧ2)         st     ⓈB0,(Ⓧ0)         clr    ⓊQ0         bst#V  ⓊB0,#0         rts The 1st line loads Src1 and sign-extends it. This is implied since the Subject is a Quad while the source is a Byte. Since it is a Signed Byte, it will have to be sign-extended to fit the Dst. The same thing happens in the 2nd line except that it is used as Src2 in the add. Also, adds don't involve flags by default so we must specify a Flag Set which is Ⓒ0. On the 3rd line we store the result. Now comes the easy part. We first clear the return value which will contain the Overflow Flag. Next we just store the V flag to bit 0 of byte 0. Finally, we return. Wasn't that easy? The RISC-V code took 12 instructions for a total of 48 bytes. Our ϕEng32 function used 6 instructions for a total of 18 bytes. ϕEng32's code was only 35.75% that of RISC-V; just over 1/3 the size. #computers #ISA #electronics #assembly #programming

1

Hear Tristan Cool speak on the panel session: Energy Harvesting - Powering the Future of Sensor Networks and Controls at #SensorsConverge!

4

Powering Innovation: The Evolution of PCB Control Boards in Electronic Systems - Learn more about the evolution of control PCB boards and what influence they brought to electronic systems in RBB’s latest blog. https://hubs.ly/Q02QWhz20

6

The 2024.2 Intel HPC Toolkit is here! Stay at the forefront of parallel programming with the latest OpenMP standards. Manage thread usage with the Intel Fortran Compiler, leverage powerful loop optimizations, achieve faster performance with GPU-aware broadcasts, and more. Elevate your HPC applications! https://intel.ly/4dQBCus #HPC #OpenMP #oneAPI

22

1 Comment

👉 Enjoy the 2024.2 release of the Intel Software HPC Toolkit! 👉 It expands conformance enhancements for the latest #OpenMP standards, including 5.x and 6.0, for increased thread-usage control and more powerful loop optimizations; and adds OpenMP runtime library extensions for memory management, performance, and efficiency. 👉 You get a preview of the #OpenMPv6 features, which will officially be released in November 2024 during #SC24. Xinmin Tian #HPC

2

RISC Zero is coming to Optimism Unlimited RISC Zero’s Universal Verifier redefines scaling limits by bringing ZK validity proofs to OP Mainnet. This integration unlocks verifiable offchain execution for the thriving OP ecosystem. The future is verified. 🟡🔴

17

2 Comments

#ConsumerElectronics #Embedded   Fuel gauging is a critical component of today’s rechargeable embedded devices. In this episode of Chalk Talk, Amelia Dalton and Robin Saltnes of Nordic Semiconductor explore the variety of benefits that Nordic Semiconductor’s nPM1300 PMIC brings to rechargeable embedded devices, the details of the fuel gauge system at the heart of this solution and … Read More → "Ultra-low Power Fuel Gauging for Rechargeable Embedded Devices – Nordic Semiconductor and Mouser" https://lnkd.in/gdhWd2Vx

1

The latest update for #Memfault includes "Comparing Firmware Development Environments — #Linux, #Windows, WSL2, and VMWare" and "How Memory Usage Patterns Can Derail Real-time Performance". #IoT #debugging #embeddedsystems https://lnkd.in/dHGnqzR6

1

1 Comment

👀 What's the potential to be unlocked when you switch PCIe 2.0 to PCIe 3.0 of Raspberry Pi 5? In this video, we run Ultralytics #YOLOv8 Pose Estimation model on Raspberry Pi 5 with Raspberry Pi #AI Kit to show you the difference in fps, temperature, and power consumption. 👉 Check detailed wiki: https://bit.ly/46cfQ1b Get more insights about #RaspberryPi and #AI from our last week's #liveshow: https://lnkd.in/g8FeAxAS We also update all the content on our Github: https://bit.ly/4d6xTYK #AI #poseestimation #raspberrypi #edgeai #iiot #iot #raspberrypiai #edgeiot #edgecomputing

50

1 Comment

Learn how to leverage this powerful AutoML tool to create optimized models for low-power, small-footprint devices. https://lnkd.in/gB5Uc3nT #EmbeddedSystems #LowPower #AIModels #TechNews

5

Excellent assessment of the current FPGA market landscape.

28

1 Comment

Product Spotlight – LCR Embedded Systems’s DK3HS High speed VPX systems incorporating PCIe Gen 4 / Gen 5 and 100GBASE-KR4 protocols are here. The DK3HS supports 25Gb per lane data rates for 100Gb performance in new systems being developed for VPX and SOSA aligned payloads. It enables the early stages of system development with open access and flexible configurability resulting in faster time to deployment for critical mission requirements in new and emerging defense programs. DK3HS includes power and ground backplane, power supply, fan cooling and rear transition area. Backplane profiles are created using slot to slot cabling systems. Click the link below to learn more!! https://lnkd.in/e-Db8v5j #VPX #Development #Chassis #HighSpeed #DevelopmentChassis #SOSA

24

Silicon IP Secutity protection built in For all our Chip design friends.. see our newcomer partner CryptoQuantique’s hardware IP at the core of the Root of Trust includes the QDID™ PUF and True Random Number Generator (TRNG). QDID™ PUF is a NIST-compliant embedded hardware PUF IP that harnesses quantum tunnelling current variations on a standard silicon process as the source of entropy. It is a prerequisite component for authentication and product lifecycle management in scaling a robust, flexible, and affordable end to- end security proposition. The QDID™ PUF provides multiple internally generated unclonable identities, eliminating the need for costly hardware security modules (HSM) or secret key injection processes during manufacturing. The TRNG IP provides dynamic entropy to enable authentication schemes and can provide nonce/initialization vectors required for key generation or other cryptographic primitives. Contact us ITEC Ltd for more #authentication #PUF #TRNG #HSM #CryptoSecurity

1

Porting between different hardware configurations or OS/RTOS choices often presents an immense headache, especially when undertaken mid-development. There are many factors that can lead to this situation, the most recent being the worldwide chip shortage, but there are often few solutions other than rewriting, retesting and re-debugging portions of code. This is exactly why we created Clarinox SoftFrame, our award-winning adaptation layer. Clarinox SoftFrame brings our ClarinoxBlue and ClarinoxWiFi solutions into a cohesive, maintainable, portable package, and together with ClariFi it provides a powerful toolset for developers. It also comes with a comprehensive API for managing multi-threading, semaphores, mutexes, and event handling. The Clarinox SoftFrame abstraction layer enables embedded developers to easily migrate their Clarinox applications across different hardware and OS/RTOS environments. With Clarinox SoftFrame, the ability to switch between different target platforms is simpler than ever. Whether facing evolving requirements or navigating hardware availability challenges, Clarinox SoftFrame ensures your development stays on track.

10