6 ms·
Sipeed unveils RISC-V tablet, portable Linux console, and cluster
- sylware 3y agoMoving forward. That said I still dunno which 64bits risc-v MCU board I'll use for my future keyboard (if I ever get the brain time and energy). For the moment I am targetting a mango pi with a D1 (yeah, completely overkill, but I really don't want to code the firmware in 32bits, as I would code it in 100% assembly, without abusing any preprocessor of course). Hopefully RISC-V will be successul. For that, it must have extremely performant implementations in major use cases (server/desktop/mobile).
- packetlost 3y agoWhy is 64-bits a requirement?
- sylware 3y agoBecause I will code once 64bits risc-v assembly.
- RetroTechie 3y agoSounds like a one-off custom project. So RV32 or RV64 shouldn't matter. Apart from the register size, assembly for these is very similar if not the same. Disadvantage of complex SoCs is that even if you use just a few peripherals, several other peripherals might get in the way or need initialization even if you're not using them (like onboard flash, DRAM controller timings, or power management). To some degree bootloaders take care of this. Which leaves you with an overly complicated (+ time consuming) boot process before your code can do useful stuff. Not to mention power consumption. Or the cost of keeping spares around. If you want to go RISC-V route for this, I'd recommend to just pick a lowly uC (or more likely, a board it sits on), like: GigaDevices GD32VF103 WCH CH32V series A step up: Bouffalo Lab BL808 Allwinner F133 Milk-V Duo I'm not aware of an extensive / complete list of such parts or boards. But there are more out there (and new ones popping up).
- packetlost 3y agoI would personally reach for a BL602 or BL616. They're RV32IMAFC MCU cores that would be good for a keyboard project.
- sylware 3y agoI know risc-v 32bits and 64bits instructions are very similar... but it is not the same in the end: I prefer to write 64bits risc-v code paths once and for all. I have already a few GD32VFG10[12] boards, but the MCU is 32bits, I avoid them. BTW, the bouffalo has a 32bits risc-v MCU, the 64bits risc-v is only a "guest" processor. And of course, initing a complex SOC can be a nightmare if really badly done, it all depends on the SOC, but the code is usally around. But do you know of a mini-board with plenty of available GPIOs (~30), a USB-C port and a USB device block, RV64 ofc. The only one seems to be the mango pi with the D1.
- snvzz 3y agoNote this is the same TH1520 in the same module as Lichee Pi4A. I prefer StarFive's JH7110 and the devices based on it (VisionFive 2, Pinetab-V, Star64...), due to their documentation and upstreaming effort[0], alongside its higher power efficiency. 0. https://rvspace.org/en/project/JH7110_Upstream_Plan https://rvspace.org/en/project/JH7110_Upstream_Plan
- FullyFunctional 3y agoThe JH7110 is also standards compliant unlike the TH1520 which includes a significant amount of proprietary extensions as well as an incompatible RVV extension. However the TH1520 is roughly twice as fast as the JH7110. What we really need to for a faster and standards compliant core to come out to make this a moot issue.
- snvzz 3y ago>The JH7110 is also standards compliant unlike the TH1520 which includes a significant amount of proprietary extensions as well as an incompatible RVV extension. I do not think this is true. Having custom extensions is allowed in RISC-V: There is instruction encoding space reserved for them. It does not prevent execution of standard code, RVA20 (roughly what most call RV64GC) code will run with no issue in these processors. >as well as an incompatible RVV extension. AIUI, this pre-ratification 0.7.1 version of RVV is just a custom extension in practice. These chips won't run V 1.0 code, nor will V 1.0 processors run code for 0.7.1, but that's about it incompatibility-wise. RISC-V is designed to accommodate this sort of thing well. >However the TH1520 is roughly twice as fast as the JH7110. In some cases. In others (e.g. compiling code) it turns out to be actually slower. The reasons are not currently understood. Note TH1520 draws more than twice the power on load. TH1520 will definitely need active cooling, whereas JH7110 can in many applications get by w/o even a heatsink, thus being adequate for different scenarios. Built to tolerate 125C, JH7110 will barely reach 70C on VisionFive 2 while compiling w/o heatsink, thus it will be other components in the board that'll make a heatsink desirable. I added it because I specifically don't want the M.2 SSD under the same board to get hot.
- jauntywundrkind 3y ago
- fweimer 3y agoThe slots have separate load averages in https://sipeed.com/assets/cluster-la.45176f2b.jpg https://sipeed.com/assets/cluster-la.45176f2b.jpg, so it really is a cluster with multiple kernels running.
- snvzz 3y agoThe cluster seems most non-sensical to me. I'd instead look at SOPHON SG2042[0], such as in the Milk-V Pioneer[1] board. 0. https://www.sophgo.com/product/introduce/sg2042.html https://www.sophgo.com/product/introduce/sg2042.html 1. https://milkv.io/pioneer https://milkv.io/pioneer
- brucehoult 3y agoWe don't know the price yet. The cluster might work out to similar price/performance to the Pioneer, just with half of each and a worse programming model. Have you noticed the Pioneer price has increased from $1999 to $2499? You can buy 16 of the 8 GB RAM + 8 GB eMMC Lichee Pi 4As for $1904 and you'll have the same 64 cores, the same 128 GB RAM, and now $600 left over to buy power supply, case, some nice ethernet or USB3 switch. You won't have that 64 MB of L3 cache, and you'll have a cluster programming model instead of a single OS instance. I assume the 7 module cluster will give at least some cost savings over buying individual LPi4As, and certainly more convenience, though less so than a Pioneer.
- snvzz 3y ago>and a worse programming model. Having several computers in a cluster is not comparable to having the same amount of cores in a single chip. A worse programming model indeed, by no less than an order of magnitude. The one use I see for it would be research into scaling in clusters.
- fweimer 3y agoSuch a cluster might be useful for a distribution build farm, where you can fan out builds across the cluster (instead of trying to distribute a single build). It depends on whether the hardware is actually shipping now (obviously), how stable it is, and if the system has decent remote management. Of course, most people in the RISC-V camp probably hope to move beyond such hacks sooner than later.
- retrocryptid 3y agoSure... but I'm focusing on hardware I can actually order.
- RetroTechie 3y agohttps://aliexpress.com/item/1005005532736080.html https://aliexpress.com/item/1005005532736080.html
- retrocryptid 3y agoWhoops. I confused thus with the pinetab. Happy to see you can actually order this hardware. I don't have a lot of time for projects at the moment, but the price is pretty reasonable as well. Thx for the link.
- brucehoult 3y agoThat is changing on a monthly basis.
- jauntywundrkind 3y agoPart of me really wants to be the chip design startup that makes multi-host chips. Let everyone else make cores, & focus on making NIC + switches designed for a dozen small systems, designed for low power clusters like this.
- packetlost 3y agoI don't really see a point in investing in these devices unless you're particularly interested in porting applications to non-standard RISC-V and being married to the T-Head fork of GCC. Yeah, it's a pretty fast CPU for a new-ish ISA, but there are better options for RISC-V SBCs out there for porting and testing.
- camel-cdr 3y ago> unless you're particularly interested in porting applications to non-standard RISC-V You can totally use these devices to work on porting applications to standard RISC-V and they are currently the best available for that, if you what to port to rvv. Yes rvv 0.7.1 and rvv 1.0 are a bit different, but having a device with rvv 0.7.1 allows you to actually make performance estimates/tests. It pretty doable to implement a smaller algorithm with rvv 1.0 intrinsics, use clang to get the assembly, then convert the few instructions that differ between version and use the older gcc toolchain that supports rvv 0.7.1. (no custom thead stuff required) I would buy one of these devices for my self if I didn't already have ssh access to a milk-v pioneer board (thanks perxlab btw).
- KerrAvon 3y agoI haven’t compiled a Linux kernel in decades — how do those cluster compile times compare to something like an Intel i7-11k? They sound slow.
- daveguy 3y agoA Ryzen 9 7950X compiles 5.18 in less than 40 seconds[0], so yes. 60 minutes per module or 15 minutes with 7 modules is very slow. I think these risc blade architectures are interesting from a home-lab perspective -- low-cost complex-architecture playgrounds. [0] https://www.phoronix.com/review/amd-ryzen-7900x-7950x-linux/4 https://www.phoronix.com/review/amd-ryzen-7900x-7950x-linux/...
- camel-cdr 3y agoOr 400 seconds with a allmodconf build, idk what they build in the OP. If they build allmodconf and I understood the benchmarks correctly, then one C910 core is about 4 times slower in building the Linux kernel than a single Ryzen 5 5600x core (60/(1491/6*4/60)). That would be pretty good wouldn't it? Probably to good to be true, but I don't think we can just compare these two numbers directly anyways.
- brucehoult 3y ago> if ... then one C910 core is about 4 times slower ... than a single Ryzen 5 5600x core 4x is the number I work with to approximate C910 vs current x86. Which makes 64 core Milk-V Pioneer possibly comparable to a 16 core 7950x, but at $2k ready to use it's a lot cheaper than 7950x boxes I see on Amazon. If your workload can keep 64 cores busy, of course. Many can't.
- mixmastamyk 3y agoDoes anyone know if either of the tablets mentioned can play an HD movie acceptably? Say 1-2GB H264 .mkv or .mp4 files? Looking to retire a decade old android.
- Havoc 3y agoI doubt any of the risc-v gear has hw decoding running already
- brucehoult 3y agoThe recent Explaining Computers youtube review of the Lichee Pi 4A showed it playing 720p from youtube very well, but struggling a little on 1080p. The SoC should be easily up to 1080p but perhaps more work is required on the software side -- the non-beta boards have only been shipping for two months. In general, on the JH7110 and TH1520 boards, right now you get ImgTech's driver and thus hardware decoding if you run the official manufacturer's OS image, but not if you run some generic RISC-V Linux image.
- snvzz 3y ago>The recent Explaining Computers youtube review of the Lichee Pi 4A showed it playing 720p from youtube very well, but struggling a little on 1080p. The same video does, earlier on, demonstrate vlc or mpv playing 1080p w/o issue. Chromium, specifically, is what has trouble keeping up.
- brucehoult 3y agoOr the CODEC youtube wanted. I recall comments on the video suggest using a plugin to force youtube to serve H.264/5 make it work better.
- snvzz 3y agoBoth JH7110 and TH1520 have hardware video codec blocks. Find the details of what they can handle in the official specs, but note they are much better than the Raspberry Pi 4, which many find sufficient for the task.
- Havoc 3y agoThat still seems a little underwhelming like for like, but the progress is certainly swift
- snvzz 3y agoIt's getting interesting, dollar per dollar. e.g. the JH7110 and TH1520 devices at around Raspberry Pi 4 price are IMHO a better deal. Relative to the Pi 4, the CPU can be lower power (JH7110) or faster (TH1520), whereas GPU, video codecs, crypto acceleration, RAM and periphals are better in both.
- MagaMuffin 3y ago[dead]