Microchip announces PIC64 ... and it's RISC-V. - Page 1
Forum section: electronics / general

author: MK14
author_rank: Super Contributor
timestamp: July 05, 2024, 05:25:31 pm
content: Is it only intended for Radiation-Hardened, Space flights, and low-Earth-Orbit projects. With my presumed, MCU pricing, outside of the reach, for other MCU use applications?E.g. Looking here:https://www.microchip.com/en-us/products/microprocessors/64-bit-mpus/pic64-hpsc/ecosystemOnly seems to show, space flight and Radiation Hardened project related things.Quote

author: coppice
author_rank: Super Contributor
timestamp: July 05, 2024, 05:49:33 pm
content: Quote from: MK14 on July 05, 2024, 05:25:31 pmI see the rad hardened PIC64-HPSC line and the PIC64GX commercial grade line on Microchip's site.

author: MK14
author_rank: Super Contributor
timestamp: July 05, 2024, 06:39:59 pm
content: Quote from: coppice on July 05, 2024, 05:49:33 pmThanks!That's great news for me then!I'm a fan (or was) of the PIC32MZ series (I like the straightforward peripheral set, Microchips very long production schedules, i.e. parts remain available for a very long time, with good, but not too many pages, documentation/datasheets/manuals), and the double capable floating point, with the reasonably high end performance.So, for them to introduce a modern PIC64 series (available, sooner or later for commercial/hobby projects), is good news for me, and everyone else, who is interested.I have an interest in Risc-V. But I try and avoid the Chinese (West based ones, who get them made in China is fine, but not where the chip itself, originates from China) version of these chips. Mainly because of fears over Chinese language documentation, lack of documentation, inaccurate documentation, substandard parts, lack of support, possibly supply issues in the future (e.g. they stop producing, with no notice, go bankrupt, or modern day sanctions), and other possible reasons, including possibly poor driver/**IDE/etc availability and support.**IDE = What I really mean here, is appropriate tool-chain support, as in GCC and whatever else is needed, e.g. For USB/Ethernet/WiFi etc, drivers/tools and so on.Also, I don't really like to buy stuff from some of the Chinese sources/suppliers, partly because importing into the UK, is not so straightforward, fast, easy or cheap, necessarily. I much prefer Digi-key/Mouser and other Western sources.

author: JPortici
author_rank: Super Contributor
timestamp: July 05, 2024, 06:59:40 pm
content: Quote from: brucehoult on July 05, 2024, 03:25:34 pmhow did i miss that? (huge MCHP fanboy and of course it's the main MCU line i work with)EU masters are going to be much much more interesting than anticipated...Quote from: MK14 on July 05, 2024, 06:39:59 pmand debugger backdoors.of course>implying there are no backdoors in western chips

author: SiliconWizard
author_rank: Super Contributor
timestamp: July 05, 2024, 10:00:53 pm
content: Cool stuff. A bit odd that they would choose to start with RISC-V with a high-performance chip (probably very expensive) rather than simple MCUs, in particular to replace their MIPS cores.

author: coppice
author_rank: Super Contributor
timestamp: July 05, 2024, 10:04:58 pm
content: Quote from: SiliconWizard on July 05, 2024, 10:00:53 pmWhy would they want to compete with themselves, when they can put that effort into exploring new markets?

author: MK14
author_rank: Super Contributor
timestamp: July 05, 2024, 10:09:59 pm
content: Quote from: SiliconWizard on July 05, 2024, 10:00:53 pmMicrochip seem to have very, very big release cycles. I'm not sure exactly, but perhaps 10 years. Which is a very long time-span, with technological things.So, to go for a huge (presumably), powerful, speedup/performance, by aiming for RISC-V, 64-bit, with powerful vector instructions as well. Makes sense, at least to me.Presumably, they have researched what customers (or at least the ones, they are aiming for), want, need and are currently requesting (from Microchip).They may (or may not), have obtained the IP (I know RISC-V is basically free, but if you want to get the know-how, to make a powerful, fast, RISC-V design, that can be produced, with the minimum delay and resources, then that makes a lot of sense).I.e. Going back to the MIPs, they did in the past, it was something they 'bought-in', rather than something they did themselves. If I understand things correctly.

author: SiliconWizard
author_rank: Super Contributor
timestamp: July 05, 2024, 10:18:15 pm
content: Yes of course, they bought MIPS IPs, as they would have ARM IPs if they had gone with ARM. They just got a much better deal with MIPS, and the MIPS cores they chose looked attractive at the time.Problem is, now, MIPS is dead. So they are maintaining products on essentially dead technology. I think it would make sense to work on replacing those PIC32s with a RISC-V core, and that would be a much simpler, and shorter, endeavour, to begin with RISC-V. A much cheaper investment too. But maybe they are actually working on that, and they just communicate about the longer-term projects, and leave the surprise for shorter-term ones, which wouldn't be a silly communication strategy.Anyway, Microchip clearly tends to make "odd" decisions - at least compared to their competitors - and that seems to work ok for them, so, yeah. We'll see. Until they get bought by a bigger fish. That day will feel sour.

author: brucehoult
author_rank: Super Contributor
timestamp: July 06, 2024, 12:26:01 am
content: Quote from: coppice on July 05, 2024, 05:49:33 pmOh, interesting.https://www.microchip.com/en-us/products/microprocessors/64-bit-mpus/pic64gx- 4x SiFive U54 Linux capable cores- 1x SiFive E51 real-time core- pinout compatible with PolarFire SoCSo it's basically an FU-540 (HiFive Unleashed) with added peripherals such as dual gigE (FU-540 had one), PCIe, USB, CAN.Or, it's a PolarFire SoC, without the expensive FPGA.Should be cheap(ish)?Dev kit: CURIOSITY-PIC64GX1000-KIT-ESNo price or ordering yet it seems.https://www.microchip.com/en-us/development-tool/CURIOSITY-PIC64GX1000-KIT-ES

author: brucehoult
author_rank: Super Contributor
timestamp: July 06, 2024, 12:40:03 am
content: Quote from: SiliconWizard on July 05, 2024, 10:00:53 pmThe PIC64GX should be much much cheaper -- 4x U54 + 1x E51, basically a FU-540 from HiFive Unleashed (2018) with more peripherals, or a PolarFire SoC without the expensive FPGA.That *could* be similar price to the various quad Arm A53 chips, as in e.g. Pi Zero 2. In time.https://www.microchip.com/en-us/development-tool/CURIOSITY-PIC64GX1000-KIT-ES

author: brucehoult
author_rank: Super Contributor
timestamp: July 06, 2024, 12:51:20 am
content: Quote from: MK14 on July 05, 2024, 10:09:59 pmSure, of course.The space-rated chip uses SiFive X280 cores: dual issue in-order (like U74 in VisionFive 2 etc) but with a honking big 512 bit RVV 1.0 vector unit.There are 8 of them in the chip, which can be run as 4 lockstep pairs.We will soon see four  of the same X280 cores in the SG2380 SoC as an "NPU", alongside 16 2.4 GHz P670 cores (Arm A78-class, with 128 bit vector unit) for running the main OS.The Milk-V "Oasis" will have this SoC, they say for $120 (I think without any RAM or storage) in, they now say, Q4. Sipeed also said they will have a board for $300, presumably populated with RAM and storage. I expect we'll also see this SoC in laptops (probably including an updated main board for Framework) and MiniITX form factor during 2025. early materials said eight, but as at April and about to tape out it was four

author: MK14
author_rank: Super Contributor
timestamp: July 06, 2024, 02:16:01 am
content: Quote from: brucehoult on July 06, 2024, 12:40:03 amSo 2018, initial availability (not Microchip then, I presume, or at least, not only Microchip, then), has given that processor series, time for them to fix, any errata, that is going to be fixed.Time to at least note and list, other errata.Time for 'validated' processor(s), to be created.As, it is all good and dandy, for them to have lockstep, hardware versions available. But if the fundamental accuracy/robustness of the way the CPU handles instructions, hasn't been extensively tested/validated/fixed/etc. Then that would sort of limit, the usefulness of lock stepping each pair of applicable cores.Its datasheet (at least the PIC64GX1000 version, I can't seem to find any others, at least not publicly available ones). Seems to indicate, that the usual peripheral set, that much of the PIC series chips had. Such as A2D inputs, and other stuff, is missing, from these newer chips. But they do include some of what might be expected, from the older PIC chips, such as timers, I2C, serial capabilities, CAN bus, etc.It seems to have, what would suit a Linux appliance, along with low power consumption (the datasheet doesn't seem to mention what they mean, by low or its value).Somewhat fast cores, with double capable floating-point, MMU and other stuff.A long list of secure cryptographic capabilities. Allowing, what seems to be a very high level of security, and robustness confirmation.It looks to me, as if Microchip are aiming these products, at specific, niche parts of the (arguably) huge marketplace, for all sorts of Microprocessor/MCU etc devices.It is an interesting device. Because it is a sort of half-way house, between pure MCUs, but which typically can't run Linux, and actual Microprocessors, which can run full Linux's, but have little or no, MCU like, built in peripherals.But then there are SoC's, which this seems similar to. Which are also, a sort of half-way house, in some cases, between Microprocessors and MCUs.Since it essentially has, 4 Microprocessor cores, and one MCU core. The 'algorithm' bits can go in the Microprocessor sections, and the possible real-time embedded, MCU I/O stuff, can go in the MCU section. Keeping everyone happy.I think the PIC32MZ, was partly hurt, by the huge availability, of potentially cheaper, faster, and well equipped (peripheral wise), arm based offerings. From a large number of possible competitors. So, it was difficult to make a big impact/success with the PIC32MZ.Plus their (Microchips) big and significant errata, sometimes introducing long lists of delayed (or even never solved), errata, which could sometimes be in basic, reasonably assumed to be working features. Such as its (originally) high speed/specced A2D converter. IIRC significantly downgraded, to get it (A2D) working, compared to the original/launch, claimed capabilities.Would put some/many potential customers, completely off their product line(s).

author: brucehoult
author_rank: Super Contributor
timestamp: July 06, 2024, 02:57:59 am
content: Quote from: MK14 on July 06, 2024, 02:16:01 amSiFive produced the FU-540 SoC and the HiFive Unleashed board within their first $8m of funding (and the 32 bit microcontroller FE-310 and HiFive1 a year earlier).The FU-540 was basically the already well-proven Berkeley Rocket CPU (as was the Kendryte K210) with a very minimal set of peripherals added to make an SoC -- basically just gigE, DDR3/4 2400 (128 GB max), SPI, i2c, GPIO, and UART.An LTT video from 2018 showing the HiFive Unleashed running Linux and Quake 2 ...

author: MK14
author_rank: Super Contributor
timestamp: July 06, 2024, 03:27:05 am
content: Quote from: brucehoult on July 06, 2024, 02:57:59 amThanks!I've just enjoyed watching the video (link removed, to avoid its automatic expansion in my reply).I suspect and partly remember, watching the video, somewhat soon after it was first released. Nice watching it again, anyway.The chip(s), to me (of this thread), look really suitable, to release/make a Linux RISC-V laptop/notebook/smartphone-size-not-functionality type of device.Even if some (RISC-V) already exist. What I really mean is low cost, affordable ones. E.g. Final Amazon/Digi-Key/Etc price, is circa £100/$100 for the end customer.But even $150 .. $250, might be ok.I wish Raspberry PI, would release something like that, but so far, it has yet to materialize (at least as regards OFFICIAL ones). Although there have been some earlier kit laptop ones, which might have been official, I'm not 100% sure.

author: brucehoult
author_rank: Super Contributor
timestamp: July 06, 2024, 04:21:59 am
content: Quote from: MK14 on July 06, 2024, 03:27:05 amBear in mind that case / screen / battery / keyboard / trackpad have some significant cost if you want reasonable quality, even if the CPU costs zero.The non-space chip they've announced runs at 650 MHz, so it's not a speed demon.The K210 chip (dual core 64 bit, 400 MHz but they say easily overclocked to 800 MHz) has been around since 2019, and for example the MaixAmigo using it since 2021:https://wiki.sipeed.com/soft/maixpy/en/develop_kit_board/maix_amigo.htmlIt's a cute little machine. The main limitation is the 8 MB of on-chip RAM. It's currently $9.60:https://www.aliexpress.us/item/1005002802675701.htmlThe next SiFive core generation after the U54 being used by Microchip in their "industrial" line, the U74, is similar to an Arm A55, but without NEON. You can get a quad core 1.5 GHz one with 2 GB RAM in the "Milk-V Mars Compute Module" for $30:https://arace.tech/products/milk-v-mars-cmOr in SBC form as the Milk-V Mars, StarFive VisionFive 2, Pine64 Star64.Or as a tablet with keyboard cover as the Pine64 PineTab-V with 4 GB RAM and 64 GB eMMC for $160:https://pine64.com/product/pinetab-v-10-1-4gb-64gb-risc-v-based-linux-tablet-with-detached-backlit-keyboard/Or, you can get it in the DeepComputing "Roma" laptop for $299:https://store.deepcomputing.io/products/dc-roma-risc-v-laptopOr, recently announced, DeepComputing have it as a mainboard for the Framework 13 laptop for a not yet announced price.Framework 13 itself starts from $779 with an i5-1340P CPU, no RAM, no storage. Perhaps they'll offer it without a CPU at all (or with the RISC-V one) for less later.There also currently other laptops with the Chinese THead TH1520 SoC, which uses THead C910 cores similar to Arm A72, primarily the Sipeed Lichee Book 4A and Lichee Console 4A:https://www.aliexpress.us/item/1005007204555493.htmlhttps://www.aliexpress.us/item/1005006174268912.htmlSo there's already quite some choices, but $100 is going to be hard to hit for a useful and robust portable device, even if the CPU costs zero.QuoteThere's the Pi 400. Still BYO monitor, of course.

author: MK14
author_rank: Super Contributor
timestamp: July 06, 2024, 04:59:16 am
content: Quote from: brucehoult on July 06, 2024, 04:21:59 amActually, I've got a PI400. I really like it! My only real complaint, is that they never released a 8 GB ram version. The 4 GB ram it has (most people say), is enough for almost everything, one would do with a PI400. So, I suspect it is more a psychological want, or because I sometimes like to do more strenuous things, with them.I'm sure you're right, and I'm just being completely unrealistic, with my laptop pricing.The popular and well established laptop/tablet etc models, with Windows or Android as standard, sell in huge quantities. Which creates huge bulk buying, economies of scale, and somewhat predictable sales targets.Hence they can be released, at not too unreasonable price points.But a Linux device (which, sadly but realistically speaking), because it doesn't run WINDOWS, is already heading for a tiny percentage of the available market. Plus it being RISC-V, which doesn't directly run X86 or Arm code. Is significantly further, limiting the market, very much into a big downward spiral, as regards possible sales.So such a laptop/device, with such (relatively) tiny possible sales. Would incur, massive component/assembly costs, not to mention NRE costs, for all the custom bits. Such as a neat case for it. The NRE costs, which instead of being divided down by millions of sales, to affordable amounts per sale.Would instead (NRE) be divided down by a considerably smaller (order of magnitudes) number, probably meaning that, that alone would make it prohibitively expensive.Just as you say, the CPU is only a relatively small percentage of the overall cost.Then there is further (NRE) engineering costs, to develop the internal (possibly custom) battery, and all sorts of compliance issues, which can cost a small fortune to get right, especially if you want to be able to sell it, worldwide, using normal sales channels.I've seen (on internet) and somewhat wanted the Pine64 laptop. But either encountered lack of availability and/or too tricky with it not being available to directly buy, from places such as Amazon. To go ahead and buy it.(Olimex would have been ok), but in the past, Olimex, refused to sell to the UK, because of the UKs onerous import/export documentation, that the seller in a different country, had to obey. (To charge impart duties/VAT, related to Brexit leaving the EU).I'm not sure of the latest situation with Olimex, or if they even sell the Pine64.But maybe it helps you understand why I am so reluctant, to buy, outside of the usual/main UK distributors.E.g. You can have to pay import duties, VAT, then excessive administration fees for the privilege of paying those fees. Making eye-watering totals. It can also cause extra time delays, before you receive the goods. In addition, the importing delivery company, can invoice you for all those extra charges (they even charge VAT, on top of the delivery charges, and maybe extra fees (i.e. the delivery company fees, gets further VAT added to them) as well, on top of the other taxes/VAT).Until you pay the invoice (on top of already paying for the item, when you first bought it), you don't receive your item(s).So it can appear, you are even paying extra VAT, on top of the VAT charge itself, as the delivery company charges for the VAT so far plus its own fees, that total might get its own VAT bill (I'm not sure, but there are many complaint threads about it, on the internet).So in short, (hypothetically) a $50 thing, might really finally cost $80 .. $120, delivered.Then there are the import duties (in addition to the VAT charges), which also get complicated, and added to the bill. If the item costs more than a certain threshold, which is something like $115, I'm not sure.Also, there is VAT to pay, for the import duty tax!Which to me, seems really silly.How can you need to pay extra VAT (a tax) again/more, on the (import duties) tax bill part of the transaction.So hopefully, you can understand some of my frustration, with the import tax systems.I don't think I'd be complaining, if 20% VAT was added to the bill, then that was it. But all this nonsense, making it more like perhaps +100% or more, seems silly.Also the system is so complicated, I'm not clear what the final price is going to be, or how it all works. With many companies refusing (I don't blame them) to deal with the UK, because they have to register (even just for one sale for say $0.99), with the UK Government, and fill out these somewhat long and complicated forms.N.B. I could easily be confused (wrong) about any of the specific details I mentioned, as regards the import taxes/VAT/bills etc. As I don't do it often, and it seems very complicated, and to vary, depending on which courier imports the item(s).But the basic concept is correct, so get your wallet ready.

author: brucehoult
author_rank: Super Contributor
timestamp: July 06, 2024, 05:33:51 am
content: Quote from: MK14 on July 06, 2024, 04:59:16 amThere's really no need to design a new case / screen / battery. No problem to use an off-the-shelf laptop designed for x86 and just put in a different motherboard.I just checked and the cheapest x86 laptop (an Acer N100) and cheapest chromebook (a Lenovo) I can find in a major NZ store are both $450 (US$275, $240 before tax) so even that volume doesn't get you anywhere near $100.QuotePoint of order!The UK leaving the EU necessarily results in UK products being sold into the EU getting import duties.BUT Brexit has ALSOLUTELY ZERO to do with products from the EU, USA, Asia, New Zealand or anywhere else having import duties or administration charges when brought into the UK.That is ENTIRELY the choice of the UK government. They could simply choose not to do that.Here in NZ we got rid of all  such duties in the late 1980s. The vast majority of imports are charged only the 15% GST that is also added to things made in NZ. Private imports valued under $1000 ($400 before October 2018) come in without any charges or administration at all.Foreign retailers (such as Alibaba or Amazon, but for example Pimoroni doesn't appear to make the threshold) that send more than $60,000 of goods to individuals (not registered for GST) in NZ in a year have to themselves register in the GST system and add NZ GST to their prices at the point of sale.Such purchases, no matter what the value is, once again sail through the border unmolested.If tiny NZ can do this, the UK could too. except on some very few products that attract either sin taxes or else had some NZ manufacturer that was granted a phase out period before being exposed to world prices, shoes and some clothing being one.

author: mariush
author_rank: Super Contributor
timestamp: July 06, 2024, 05:39:09 am
content: Quote from: brucehoult on July 06, 2024, 12:26:01 amI'd like to see one of these chips come with at least let's say 32 or 64 MB of ram on the chip, or maybe up to 256-512 MB by having a chip stacked on top of the die .... wouldn't designers be interested in such a chip? Would be enough memory for some applications and save you from having to do layout for ddr4, buy ddr4/ddr4l chips add extra voltage regulators on the board.I'm thinking ebook readers for example where you need a bit of ram to parse an epub (decode html, format fonts etc), decompress a pdf file and render, maybe do some text to speech, or play audio books... yeah I guess these chips are overkill for such uses, could be done with simpler 1-2 32 bit cores.

author: MK14
author_rank: Super Contributor
timestamp: July 06, 2024, 06:03:19 am
content: Quote from: brucehoult on July 06, 2024, 05:33:51 amVery good point.The $100 original price point I posted, was WISHFUL thinking on my part. I should have thought abut it more (which is so easy now, you have given me the hindsight).I feel increasingly silly/mistaken for suggesting it and NOT thinking it through.You're right. It could even be, that they sell the X86 version, as a Windows machine, and the RISC-V version (as you say, different motherboard), as the Linux version, of the same laptop series.But I think Microsoft licensing terms, charges the Windows license fees, on all of that companies computer/laptop sales, so that wouldn't turn out too good.But given the costs of developing that custom (so it fits as a replacement, to the original motherboard for that laptop, with strange shapes/sizes, from what I seem to see) motherboard, complete with the extra compliance testing and other engineering, needed for the special Linux RISC-V version. I suspect, it would cost a fair bit extra, with potentially limited final sales, of that model.Quote from: brucehoult on July 06, 2024, 05:33:51 amYou're right, I agree with you.But, unfortunately, the UK (Governments), can get crazy and very heavy-handed, when they design such systems.I'm VERY disappointed, with the system the UK government(s), have come up with. Expecting the foreign seller(s), to have to fill in UK complicated Government forms, is just so, over the top, in my mind.Your NZ system, sounds much better, at least for the consumer. I get REALLY infuriated, when the +20% VAT bill, gets turned into something like +100%, because of all the commissions, administration fees, and extra bits and pieces, that get added onto the bill.If you ask me, I think what they have come up with and implemented, as regards small private individual, low value sales. Such as a $1.99 small module, from a Chinese seller.Is NOT good, at all.(Wild rumor only, I DON'T know for sure, what happens) The ironic joke, is that the Chinese sellers, in some cases. If I have understood some report(s) I've read about it. End up filling a container(s), full to the brim of these items. Importing it, exploiting loop-holes in the laws/regulationsand/or using some of the profit, a brown paper envelope with such cash, and meetings in a local drinking establishment, after-hours, between the Chinese importer, official(s), to pass certain container loads, through without proper checking.HOPEFULLY NOT, as this would be illegal.Anyway. Suspiciously, it can be possible, to buy something from a supposedly Chinese seller, on Ebay (UK). For it to arrive the next day or so, after ordering it. E.g. A cheap Arduino clone.I.e. They have some warehouses, somewhere in the UK, with these container loads, of popular well selling items. Then use cheap, possibly illegal (not in the country legally) labour, to fulfill the orders.EDIT: Struck out some of the text, as I don't have evidence that, that is what occurred. Maybe it was just loop-holes in the law, or similar. Maybe there are legitimate reasons which explain it.

author: brucehoult
author_rank: Super Contributor
timestamp: July 06, 2024, 06:12:15 am
content: Quote from: mariush on July 06, 2024, 05:39:09 amSure, a single 1.0 GHz 64 bit core is plenty for such tasks:Boards:- Milk-V Duo, 64 MB RAM, $3:https://arace.tech/products/milk-v-duo- Duo S, 512 MB RAM, $10:https://arace.tech/products/milkv-duo-sThe same site also sells the bare chips (in packs of 5), the CV1800B from the Duo and SG2000 from the Duo S, but they cost more than the above boards.

author: MK14
author_rank: Super Contributor
timestamp: July 06, 2024, 08:39:47 pm
content: Maybe another way of my sub $100 'laptop'. Might be, a RISC-V processor, coupled to a touch screen LCD, perhaps 7 inch, running an OS, which allows tablet like, fundamentally Linux, operation.So a RISC-V board with at least 512 MB of RAM, perhaps $15A 7 inch touch screen, colour LCD, perhaps $20 (Chinese)A plug in battery pack, assuming it plugs into the RISC-V board, perhaps $15A cheap/simple case, perhaps $10.So around 15 + 20 + 15 + 10 = $60A bit like some of the ESP32-S3 things, which include the colour LCD touch screen (and sometimes a simple case).I.e. A mini RISC-V tablet, self build, perhaps 5 or 7 inch colour LCD touch screen, running a tablet version of Linux, or similar.At those price points, it would be AliExpress parts.I.e. This sort of thing (but a bit bigger screen, and RISC-V rather than ESP32):QuoteAt $32.99.https://www.waveshare.com/esp32-s3-touch-lcd-4.3.htm

author: EverydayMuffin
author_rank: Regular Contributor
timestamp: July 09, 2024, 01:38:48 pm
content: More information released today on the PIC64-HPSC and PIC64-GX.https://www.eetimes.com/microchip-launches-pic64-portfolio-for-embedded-and-space-apps/

author: DavidAlfa
author_rank: Super Contributor
timestamp: July 09, 2024, 02:15:05 pm
content: It seems they learned the lesson after not taking the ARM train in time, they later bought Atmel, but ST and NXP were already very strong.

author: westfw
author_rank: Super Contributor
timestamp: July 09, 2024, 09:47:40 pm
content: I don't know if I "trust" Microchip to design "Application processor" style chips (ie 500MHz+, "designed to run linux")It might end up with something important "missing" (like RPi's rp2040 (in the other direction): "oh - you want some sort of code protection? Huh.")

author: EverydayMuffin
author_rank: Regular Contributor
timestamp: July 09, 2024, 09:55:05 pm
content: Quote from: westfw on July 09, 2024, 09:47:40 pmMicrochip already has a line of Application-class processors capable of running Linux.SAM9 (Arm9), SAMA5 (Arm Cortex-A5) and SAMA7 (Arm Cortex-A7).The PIC64-GX isn't even their first chip using this RISC-V processor core. PolarFire SoC is Linux capable and has been around a few years.

author: PCB.Wiz
author_rank: Super Contributor
timestamp: July 09, 2024, 09:57:31 pm
content: Quote from: westfw on July 09, 2024, 09:47:40 pmVery different markets and very different customers.Seehttps://edacafe.com/nbc/articles/1/2080615/Microchip-Unveils-Industrys-Highest-Performance-64-bit-HPSCMicroprocessor-MPU-Family-New-Era-Autonomous-Space-Computing

author: brucehoult
author_rank: Super Contributor
timestamp: July 09, 2024, 10:16:37 pm
content: Quote from: EverydayMuffin on July 09, 2024, 09:55:05 pmYes, the Microchip/Microsemi PolarFire SoC uses the SiFive U54-MC core complex (five cores and cache) inside an FPGA, much like Zynq uses Arm. A dev kit ("Icicle") using an early run 250k LE chip shipped in July 2020 and mass production, including versions down to 23k LEs shipped a couple of years later.Microsemi also made a specialised I/O expansion board for the HiFive Unleashed -- which debuted the U54-MC core complex -- in June 2018.It's not really all that surprising Microsemi decided to make a zero-FPGA LEs version of the PolarFire SoC. The surprising thing is that Microchip decided to call it "PIC64".

author: glenenglish
author_rank: Frequent Contributor
timestamp: July 09, 2024, 10:43:28 pm
content: Does anyone know what semiconductor node it is manufactured on ? Can get some idea from the VddCore...We're STILL waiting for Polarfire2.....

author: brucehoult
author_rank: Super Contributor
timestamp: July 09, 2024, 11:31:01 pm
content: Quote from: glenenglish on July 09, 2024, 10:43:28 pm“PIC64GX is 28nm from UMC, and the PIC64-HPSC is fabricated using GlobalFoundries' 12nm 12LP+ process node"https://www.electronicsweekly.com/news/products/micros/microchip-picks-risc-v-to-go-64bit-but-will-do-64bit-arm-too-2024-07/625 MHz is very conservative for 28nm! The same cores in the FU540-C000 in 2018 were also in 28nm. It was designed for "up to 1.5 GHz", though out of the box it's set to 1.0 GHz. I've always run mine at 1.45 GHz and never had a problem (in a temperature-controlled domestic environment, not in industrial conditions)

author: glenenglish
author_rank: Frequent Contributor
timestamp: July 10, 2024, 12:01:59 am
content: really ?I'm never considered 625 MHz conservative for 28nm, although I am used to FPGA structures, not ASIC structures like this. . I would consider 625MHz 28nm fairly fast stuff in fpga world.... Depends on the dielectric etc, whether low static is an issue, speed etc tradeoffs.I wonder what Polarfire2 is going to be . I think its 16nm. 28nm polarfire isnt fast (380 MHz multipliers) otherwise I'd be using it.

author: brucehoult
author_rank: Super Contributor
timestamp: July 10, 2024, 01:16:20 am
content: Quote from: glenenglish on July 10, 2024, 12:01:59 amWell, yes, FPGA is different. You've got quite a lot of gate delays in every LUT -- something like 6 ASIC gate delays for a Xilinx LUT6 I think. That's maybe not too bad compared to random logic when you actually have a single output calculated from 6 inputs, but I suspect a lot of the time they're actually used to implement one 2 input function and an independent 3 input function which is probably two gate delays in random logic. So you're likely losing a factor of three in propagation delay / MHz right there. And then there are the routing delays which are likely to be a lot bigger than in an ASIC.

author: SiliconWizard
author_rank: Super Contributor
timestamp: July 10, 2024, 01:57:21 am
content: For sure. To get an idea of what you can achieve on a 28nm process in terms of CPU performance, you can have a look at Intel CPUs. You'll have to look back. I don't think Intel used a 28nm process though (that I could find), but the closest would be 32nm for its second-gen Core i7. The i7-2700K was running at up to 3.90 GHz. Yes, on 32nm. And yes, an Intel Core i7, immensely more complex logic-wise than any RV64 core.

author: brucehoult
author_rank: Super Contributor
timestamp: July 10, 2024, 02:24:49 am
content: Quote from: SiliconWizard on July 10, 2024, 01:57:21 amMore complex, yes, but the SG2380 due later this year is expected to have around Nehalem or Sandy Bridge performance -- maybe more like Core i3 (no turbo) than Core i7. We'll see. It's on a 14nm process.The JH7110 found in half a dozen different SBCs and laptops now is 28nm and 1.5 GHz. The SpacemiT K1/M1 is also 28nm and runs at 1.6 GHz in the plastic package and 2.0 GHz in the metal package (they claim it runs cooler than the 1.6 GHz at the same load). The die appears to be designed for 2.4 GHz and maybe that's doable with an actual heatsink & fan.The difference I believe is in the sophistication of manual or semi-manual layout use by Intel, and the engineer-hours expended on that, vs the automatic methods used by RISC-V vendors.Another data point is that the Pentium III and PowerPC G4 were hitting around 1.2 GHz speeds on 180nm, while the first RISC-V chip, the FE310, did 320 MHz, and Cortex-M3/M4 on 180nm is generally 180 MHz.Shorter pipelines also play a part in the Arm and RISC-V designs. Pentium III has 10 pipeline stages, while the last G4s had 7 (early ones had 4). Cortex M3/M4 have 4 pipeline stages, the E31 in the FE310 has 5.

author: SiliconWizard
author_rank: Super Contributor
timestamp: July 10, 2024, 02:53:50 am
content: Quote from: brucehoult on July 10, 2024, 02:24:49 amYes, that and the fact Intel have their own optimized logic cell libraries, compared to using just whatever you're given with some PDK.But anyway, 2GHz+ should definitely be achievable with an optimized RISC-V design on a 28nm node, IMO.Regarding pipelines, yes, but keep in mind that while Intel went for ridiculously long pipelines with the Pentium 3 and much worse, Pentium 4, they have reversed the trend with the Core series. I don't remember the number of stages on the last gen Core iX, but it's not that big anymore. Even on a 2nd gen core i7, I think it was much shorter than on the (infamous) P4.

author: brucehoult
author_rank: Super Contributor
timestamp: July 10, 2024, 05:27:51 am
content: Quote from: SiliconWizard on July 10, 2024, 02:53:50 amAccording tohttps://en.wikipedia.org/wiki/List_of_Intel_CPU_microarchitectures...5: 486 / Pentium6: Pentium MMX14: Pentium Pro, II12: Pentium III20: Pentium 4 (early)10: Pentium M / Centrino31: Pentium 4 (late)12: Core / Core 220: Nehalem (first Core i7 etc)14: Sandy Bridge - Cyprius Cove (aka 11th gen desktop)12: Golden Cove (12th gen P cores), Raptor Cove (13th & 14th gen P cores)I've got a 16" Lenovo laptop with a 13th gen i9-13900HX with 8 P cores (16 theads) and 16 E cores and it's MIGHTY.It beats the 32 core ThreadRipper 2990wx tower I built in early 2019 by a little on absolutely everything (e.g. Linux kernel, LLVM builds), and by up to 50% on bursty loads (e.g. binutils / gcc / glibc builds), all while using 1/3 the peak power (I've measured the ThreadRipper at 375W).The idle power also seems to be about 1/3. It's hard to tell for sure as you can't disable the battery, but I just measured 28W at the wall with the screen closed (when not travelling I use it via ssh from my M1 Mac Mini). Pegging 1 CPU with an infinite loop at 5.3 GHz took it to 68W. The ThreadRipper idles at 80W. I just reset the kWh & minutes counters on my meter and I'll leave it for a few hours and see what the average is for the laptop.

author: coppice
author_rank: Super Contributor
timestamp: July 10, 2024, 12:30:15 pm
content: Quote from: brucehoult on July 09, 2024, 11:31:01 pmNow that is interesting. Someone has a hardened process up and running at 12nm. You might expect the hardened versions to be in a coarser process than the commercial ones.

author: glenenglish
author_rank: Frequent Contributor
timestamp: July 10, 2024, 08:25:06 pm
content: and note that have the usual variable tiers of rad - ie rad hard, had tol, suggesting they are going all in on this.and.. they will have an engineering equivilent silicon for the HPSC available. Probably $ not within reach of non-pros, though, given the likely numbers they'll make.https://ww1.microchip.com/downloads/aemDocuments/documents/MPU64/ProductDocuments/Brochures/PIC64-HPSC-Evaluation-Platform-00005464.pdf4 x dual lockstep X280 processors plus a boot controller- this is a serious play by the company.. I m guess that something like this will turn out also combined with an FPGA arch on package.

author: westfw
author_rank: Super Contributor
timestamp: July 11, 2024, 11:56:29 pm
content: QuoteHmm. Any recent developments AFTER the Atmel acquisition? (at least they re-formatted the datasheets)For that matter, were the Atmel parts actually "successful" ?

author: EverydayMuffin
author_rank: Regular Contributor
timestamp: July 12, 2024, 10:24:44 am
content: Quote from: westfw on July 11, 2024, 11:56:29 pmLatest device announced in 2022.https://www.microchip.com/en-us/about/news-releases/products/new-1ghz-sama7g54-is-the-first-single-core-mpu-with-mipi-csi-2

author: iMo
author_rank: Super Contributor
timestamp: July 12, 2024, 04:41:00 pm
content: Quote from: westfw on July 11, 2024, 11:56:29 pmMCHP tried some ~10y back with the PIC32MZ_DA, there is/was 32+MB stacked on-chip dram, afaik.No much visible success, imho..PS: not sure if the pic32MZ got an MMU, afaik not (so no linux)..https://www.microchipdirect.com/product/PIC32MZ2025DAG176-I/2J?samples=true

author: SiliconWizard
author_rank: Super Contributor
timestamp: July 14, 2024, 11:57:25 pm
content: Finding its market can be tough.10 years ago, ARM was clearly dominating for what was called "application processors". They were not necessarily running Linux (often not), but some proprietary OS's.It was probably hard for the PIC32MZ with that much RAM to meet its market.The strong point of Microchip has always been to be where others weren't.The Atmel acquisition gives them a (small) share of the ARM market, but that's probably not where they should focus new developments. Directly competing with hundreds of other vendors is not a clever strategy. My thought is that they'll do just enough not to lose Atmel customers, and/or they'll try to convert them to other Microchip products.One thing they don't have (well, technically they do, with the PIC32) are competitive 32-bit MCUs - I consider now the PIC32/MIPS as a dead end. So, meanwhile, they have Atmel MCUs for the "32-bit" market. They're going to release 64-bit RISC-V processors. I would find it reasonable to work on a new line of 32-bit RISC-V MCUs to replace their PIC32 line over time. Maybe they are.

author: Psi
author_rank: Super Contributor
timestamp: July 15, 2024, 01:35:31 am
content: I think I'll wait for the PIC128

author: brucehoult
author_rank: Super Contributor
timestamp: July 15, 2024, 01:55:19 am
content: Quote from: Psi on July 15, 2024, 01:35:31 amRISC-V has that covered...

author: coppice
author_rank: Super Contributor
timestamp: July 15, 2024, 02:32:47 pm
content: Quote from: SiliconWizard on July 14, 2024, 11:57:25 pmMicrochip wouldn't accept that MCUs mostly differentiate on what is not in the core - interesting peripherals, interesting mixes of things, service, etc. This was weird, as for years Microchip claimed their competitive edge was great service to customers of varying sizes. They went down the MIPS path to be different more than anything else. This was clearly dumb, as the licence burden of using an ARM core was not that great, and they were not able to offer seriously interesting mixes of peripherals and other functionality to stand out. Cores rarely stand out. Something like the MSP430 core stands out a bit, but the special features that really help that core do bursty ULP jobs exceedingly well could have been transplanted to other cores, like the ARM ones, making them do bursty ULP just as well. The fact that it hasn't says a lot about the clunky ARM licencing model, and which markets ARM has focussed on with the cores they offer. The patents on what the MSP430 does well have expired, so that is not a blocker.

author: glenenglish
author_rank: Frequent Contributor
timestamp: July 16, 2024, 05:37:40 am
content: am surprised mfrs are keeping variable length instructions these days, must play merry hell with the prefetcher/pipeline.Still unsure what is the real advantage of having a 64 bit processor for most embedded, small application projects...more memory used, more cache required in hand, more of everything for the occassional handling of 64 bit data...I guess for my applications, I see the amount of stuff you can hold in a single cache line reduces, so need more cache. cache misses hurt.sure the thing can swap between 4 byte, 8 byte instructions , surely that consumes more area ?OK, great for number crunching, but isnt heavy number crunching these days best dealt with long vector instructions ?I guess doubles are handled natively in single cycles with a 64bit processor... one advantage.if you are moving data around, that should all be via DMA, so the processor shouldnt care.I'm probably just looking at this through my own window....post script- I'm in need of some perspective modification, I think after writing this, that this view is a fairly narrow, current view of my own requirements, without having 'vision' of future requirements and progress in all things. More about that in my following post of the 32 v 8 bit revolution.

author: brucehoult
author_rank: Super Contributor
timestamp: July 16, 2024, 08:52:33 am
content: Quote from: glenenglish on July 16, 2024, 05:37:40 amArm very probably would not be the first they are today without Thumb/Thumb2. Being able to run at 1 CPI off 16 bit wide RAM with no cache was critical to them getting the Nokia deal, and no doubt all the other "feature phones".You should see how the deeply embedded world screams if your RISC-V code size is even 5% or 10% bigger than what they're already using (Cortex-M)! "Our ROMS are full -- we can't use your ISA if we have to take features out and we want to reduce the BoM not increase it". Hence recent extensions aimed specifically at embedded, adding things such as 2-byte instructions for load/store byte, table-jump, and push/pop multiple registers.There are a few designs meant for controlling things in an FPGA soft core, but I have not yet seen any RISC-V microcontroller vendor -- no matter how tiny their chip -- choose to leave out the 2-byte instructions. Even the $0.10 CH32V003 drops the CPU registers from 32 to 16 to save space, but they keep the variable length instructions. At 48 MHz they can run one of the 2-byte instructions per clock cycle, while taking two clock cycles to run the 4-byte instructions -- limited by fetch speed from flash, which I think is 4 bytes wide but takes two cycles to access.The corresponding $0.10 PUYA PY32 Arm-based microcontroller uses ARMv6-M which is very cut down compared to ARMv7 but is still also mixed instruction length -- it's Thumb1 plus half a dozen 4-byte instructions to make a viable stand-alone ISA.QuoteNone, if you've got single digit KB to a few hundred KB of RAM and flash. But you might as well If you've got 10s of MB or more. You don't have to be feeling cramped in 4 GB before you switch -- and in particular if you want to ensure you've got room to grow your application without having to switch ISAs again.QuoteVery little more. The code size for 32 and 64 bit is identical (at least in RISC-V, near enough). Structures and arrays containing pure data don't change in size -- only if you put pointers in them, which pretty much implies you're using a heap, which you don't do anyway on tiny machines. Most sensible data structures have a lot more data in them than pointers, which are overhead whether they are 2, 4, or 8 bytes. The biggest change is doubling the size of saved registers and return addresses on the stack. Who cares when you've got a singe-digit KB stack on your many-MB machine?QuoteTiny machines don't have data cache, they have SRAM. But see the previous point "sensible data structures keep the percentage used for pointers low anyway". Slightly non-tiny machines start to have icache, especially to help running from flash. See "32 bit and 64 bit code size is essentially the same".QuoteThe processors that are the main subject of this thread of course have 512 bit vector registers. And they're running dual-issue at 1 GHz. Inside spacecraft is an "embedded" use, but the CPUs aren't all that small. This is not an RP2040 competitor. (also ARMv6-M)

author: glenenglish
author_rank: Frequent Contributor
timestamp: July 16, 2024, 09:05:46 pm
content: Thanks Bruce for your thoughtfully written post and the references to Thumb are goodYou are dead right about having a gigabyte spare so who cares. data structures will be the same size.It's interesting then the rise of the not so small machines . Maybe I am seeing the rise of the 64 bit machine, just like the rise of 32 bit ARM cores that superseeded the 8 bit cores.The big advantage on 32 v 8 is that the usual quantities and precisions that I deal with (now) are very much more suited to a 32 bit variable size. Look at the cycle cost of doing a 3 bit right shift of a 32 bit int in AVR........ 64 bits would be more corner cases (for my work currently- or rather- the WAY i write currently) , although again having 64 bit accumulators , doubles etc, there becomes a point where the programming effort (which dominates low volume projects) dwarfs any silicon cost.The only reason I continue to use (modern)AVR (like AVR64DB64) on some basic projects for clients is when they take over the source maintenance , that the chips and tools in general a simpler to work with for the non expert, For me, it has become 'why bother with 8 bit ' with extra work and lower throughput for same clock speed of an 8 bit AVR core when I am handling 32 bit precisions all the time now.Perhaps the same shift will follow with 64 bit microcontroller cores.On MPSoC, I run the A53 in 64 bit mode, and with a half a gigabyte, I dont care too much except that as usual, I am very cache aware on globals (and frequently accessed ones are in locked cache lines) .

author: NorthGuy
author_rank: Super Contributor
timestamp: July 19, 2024, 01:34:35 pm
content: Quote from: brucehoult on July 16, 2024, 08:52:33 amObjects (e.g. C++ objects) may have huge portion of pointers in them, double-linked lists with little payloads may have more pointers than data (not to mention payloads may be pointers as well), tables of strings will be arrays of pure pointers ...However, empirically there's nearly no difference between 32-bit and 64-bit software on PC, so this shouldn't be a big concern.

author: brucehoult
author_rank: Super Contributor
timestamp: July 19, 2024, 02:07:07 pm
content: Quote from: NorthGuy on July 19, 2024, 01:34:35 pmYes they could, but that's a very stupid way to program from both a size and speed perspective. If you have double-linked lists at all then they should have 20 or 30 payload items in each one. Sliding things around inside an array is much cheaper than chasing pointers -- at least assuming you have a cache or VM. But it also gets the pointer overhead down, which is important no matter whether pointers are 4 or 8 bytes.QuoteTables of pointers to strings will be, obviously, but that's not the only or best way to make a table of strings.

author: NorthGuy
author_rank: Super Contributor
timestamp: July 19, 2024, 03:51:52 pm
content: Quote from: brucehoult on July 19, 2024, 02:07:07 pmObviously, you can rewrite anything without using pointers, unless of course you decide that any array is also a pointer. This will minimize pointer overhead.The world thought that 32-bit pointers were to small, so they move towards 64-bit pointers. They dream and guess how soon is the time to go to 128-bit pointers. Then just few years later they realize that 64-bit pointers are too big and decide to chop off few bits and use them as a secure pointer signatures to make hacker's life harder. Does RISC-V do this too?

author: brucehoult
author_rank: Super Contributor
timestamp: July 19, 2024, 04:32:31 pm
content: You mistake me, sir.I did not suggest to write things without using pointers, I suggested to make each thing that contains pointers also contain (much) more data than pointer.When I was but an 18 year old pup in my first year at university they put us on a PDP-11/34 with only a primitive line editor to write our code. Both myself and one of my classmates found this intolerable and we independently wrote (in Pascal) simple full-sceen editors. We both arranged the text file as a linked list of lines, and each line as a linked list of characters, but he put 1 character plus a pointer (2 bytes on PDP-11) in each list node, while I put an array of 6 characters plus 1 pointer in each node, making the whole node take 8 bytes.His program ran out of memory on relatively small text files, mine didn't.

author: NorthGuy
author_rank: Super Contributor
timestamp: July 19, 2024, 05:51:26 pm
content: Quote from: brucehoult on July 19, 2024, 04:32:31 pmI also wrote a text editor in Pascal (mixed with Assembler), although I guess that was much later, for Windows 3.1. It had a double-linked list of lines, but the lines themselves were structures containing flags and a variable-length array for characters. This worked very fast and could edit huge files.

author: glenenglish
author_rank: Frequent Contributor
timestamp: July 19, 2024, 08:29:35 pm
content: While on the subject of pointers----Now, do we all remember PowerPC? Wasnt it that was extra C++ friendly, with two offset registers (like a global and local) being used together to get a bit of data ?and the local offset could be either 16 or 32 bits. I really liked powerpc assembler, although I didnt do much of it. Why didnt this catch on ? (no abs addr in ld/st IIRC)Northguy,Have you got any urls / papers for me to read discussing secure pointers ? interesting topic.

author: NorthGuy
author_rank: Super Contributor
timestamp: July 19, 2024, 09:00:26 pm
content: Quote from: glenenglish on July 19, 2024, 08:29:35 pmIt is the PAuth extension in ARM-8.3 (or ARM 8.5?) which allows for that. You can read it in ARM docs, probably here:https://developer.arm.com/documentation/ddi0487/ka/?lang=enApple came the farthest to implement it and created ARM64E (not mandatory yet, but you know Apple):https://developer.apple.com/documentation/security/preparing_your_app_to_work_with_pointer_authenticationMicrosoft does use pacibsp instruction in their System DLLs on Windows on ARM, but it is harmless so far:https://devblogs.microsoft.com/oldnewthing/20220819-00/?p=107020

author: ejeffrey
author_rank: Super Contributor
timestamp: July 20, 2024, 01:39:01 am
content: Quote from: glenenglish on July 16, 2024, 05:37:40 amIt doesnt really. Risc-V instructions are always multiples of 16 bit, 16 bit aligned, and you can always tell the instructions length from the first 16 bit chunk. Currently all instructions are either 16 or 32 bits. Decoding x86 sucks but other variable length instructions are not bad.On the other hand the improvement in code density can be quite significant. That improves power efficiency and makes the best use of cache / sram and memory bandwidth. The logic needed to add compressed instruction support is tiny compared to the savings you get elsewhere.QuoteFor many none at all, but I have definitely worked on very embedded applications where 64 bit arithmetic would be useful and performance was critical.

author: brucehoult
author_rank: Super Contributor
timestamp: July 20, 2024, 05:27:00 am
content: Quote from: ejeffrey on July 20, 2024, 01:39:01 amI wrote something about how to decode RISC-V's mixed instruction widths on very wide CPUs e.g. decoding 16 bytes, 32, 64, 128 etc in parallel. It's slightly harder than decoding arm64's fixed width instruction, but not enough to matter:https://news.ycombinator.com/item?id=40993502QuoteIt's hard to be exact about the size / cost ratio for random logic to implement the 16-bit to 32-bit instruction predecoder vs extra cache and DRAM or flash to store bigger code, and this will vary between microcontrollers (code is in flash), applications processors (code is loaded into DRAM, then cached), and minimal cores doing specialised tasks in an ASIC or FPGA.But as far as I can tell, by the time you have about 3-4 KB of program code in cache, SRAM, or BRAM, the savings from using the C extension (usually 25% to 30%) is enough to pay for the area of the C decoder. The crossover number would be bigger if you run from flash or DRAM without caching, but only 2 or 3 times bigger. I guess FPGA vs LUTRAM is the clearest comparison. If you save 1 KB of program code then that's 128 LUT6, which is enough to implement an RVC to RV32I decoder.

author: glenenglish
author_rank: Frequent Contributor
timestamp: July 20, 2024, 08:12:09 pm
content: So, feeling like I wasnt informed enough for this conversation, my knowledge is of Thumb, Thumb2I read the short 21 pages ofhttps://riscv.org/wp-content/uploads/2015/11/riscv-compressed-spec-v1.9.pdfOK- so the compressed extensions in this case are purely compressions of their full size instructions, IE they simply get expanded, and tas Bruce points out, easily identified.31% static code size reduction for Linux Kernel (RV64) is substantial improvement- this is not small beans .

author: glenenglish
author_rank: Frequent Contributor
timestamp: July 21, 2024, 08:52:26 pm
content: What is the business case for a niche space qual device for Microchip ?Small quantities, small market (unless perhaps Starlink is going to use it) . ?The device certainly has broad non-rad environment attractiveness. Does a company launch this in media on fanfare and prowess of a space chip and expect commercial industry to adopt based on its cool credentials or rather on the company's cool credentials of this device? The dual lockstep multicore is special . According to early media info, there will be equivalent silicon for engineering work but that's not the same as saying there will be a commercial version.for those interested, this document covers quite a bit of groundhttps://arxiv.org/pdf/2303.08706

author: brucehoult
author_rank: Super Contributor
timestamp: July 21, 2024, 11:53:28 pm
content: Quote from: glenenglish on July 21, 2024, 08:52:26 pmThey (Microsemi) have been a major player in rad-hard and rad-tolerant FPGAs for a long time.Quote.. sky high prices, big margins, locked in customers.They've been selected by NASA to make a replacement for the RAD750, a (max) 200 MHz PowerPC, which sold for $200,000 per chip in the early 2000s and probably more now.

author: Nominal Animal
author_rank: Super Contributor
timestamp: July 22, 2024, 02:49:20 am
content: Quote from: brucehoult on July 19, 2024, 04:32:31 pmYep. The text editor example is still valid, although rather than running out of memory, having more data per node makes traversal faster, and thus the text editor more responsive. (In GUI editors, the problem is even more complex, since it boils down to not only finding the bounding rectangle for each displayed glyph, but also being able to discover the interglyph position given any relative 2D coordinate. Fortunately, windowing toolkits and widget toolkits typically provide that.)Choosing an efficient data structure and algorithms typically makes an order of magnitude bigger difference than optimizing the same code at the instruction level. For machine-formatted text like HTML, CSS, obfuscated JavaScript et cetera, the text content may not contain any newlines or paragraph breaks at all, so just storing each line separately is inefficient, too: to insert or delete a single character, the entire file might have to be moved in memory because the entire file is essentially a single line, and that wreaks havoc with CPU and OS-level caching if the file is large, making everything on that core slower than necessary. Splitting at word boundaries may generate too many words, making traversal slow, too. There is no good solution that would work well in all situations, so instead you'll want something that can split large nodes and combine small nodes to more optimal sizes as their access patterns change.(Interestingly, doing something similar for binary search trees –– balancing the tree instead of splitting and combining nodes to keep the tree structure close to optimal –– lead tored-black treedata structures in the 1970s.)The exception is data structures describing graphs and networks, where the pointer itself is the data.As an example, consider the C code I posted about a month ago implementing adependency managerby describing the dependencies as edges in a directed graph. It has two abstract data structure types: one for fast lookup by name (hash table entries forming a linked list, payload being a pointer to the dependency graph node, the DJB XOR2 hash of the name, and the name as a string), and the other to describe each node, consisting of three or more pointers (next in two unrelated linked lists, a reference to the name, and any number of directed edges to other nodes), a mutable unsigned integer (tag) used during tree traversal, and the number of unfulfilled dependencies (edges) from this node. As the pointers are the most interesting data in the nodes, the nodes consist mostly of pointers.Some of the discussion in that thread following the example explains how sets of such data structures can be efficiently stored in pre-allocated arrays. I first encountered those in scientific Fortran code, so the technique is decades old already, and well tested in practice in terms of reliability and efficiency.If we listed all edges in a single one-dimensional array (of unsigned integer values), with the edges sharing the same source consecutive in the array, with each such consecutive set preceded by the number of edges in the set (and optionally the source edge), we'd have aVerlet list, first described by Loup Verlet in 1967. It is not as amenable to editing (deletion or masking out being important for the dependency graph processing in the example above), but if one uses signed integers with zero reserved for padding and negative values referring to "deleted" targets, and only positive non-zero values to identify each node, it works well even for the abovementioned dependency graph.I personally don't see any big difference in the Verlet list/array approach and one using C99 structures as nodes with a flexible array member containing pointers to the targets myself. To me, that difference is just a practical implementation detail, and translating code using one to code using the other is more or less just a mechanical translation and not a creative one. The important thing to me is the cost of access. Whether the code uses pointers or element indexes or something else is irrelevant. What is relevant is the amount of practical work needed (at the machine code level) to arrive at the desired target, in optimal, typical, and pessimal (worst-case) cases. (It is also why I prefer to examinemedianaccess time instead ofaverageaccess time. Average is skewed by outliers and thus not at all useful to me, whereas median tells the maximum time taken in at least 50% of the cases. Depending on the amount of outliers due to noise and testing system behaviour in general, 85%/95%/99% limits can be even more useful and informative.)

author: brucehoult
author_rank: Super Contributor
timestamp: July 22, 2024, 04:23:13 am
content: Quote from: Nominal Animal on July 22, 2024, 02:49:20 amBetter B-trees. They were developed for on-disk use, but these days make sense in RAM too.Making each node use an entire cache block, or a couple of adjacent cache blocks is much better than using tree nodes that are a fraction of a cache block in size. You've read the whole cache block -- better to use all the data you just read, not a small part and then jump randomly somewhere else.Or even make each node the size of an MMU page. If you're getting into VM paging then that's going to be optimal, but even without that TLB misses and refills can be as expensive or even more than cache misses.QuoteDoesn't even have to be arrays.If your complete graph is going to take up less than 4 GB of memory then you can just use a 4 GB (or smaller) heap with a register dedicated to pointing to the base of it and the internal pointers 32 bit offsets from that register. Or if -- as is standard practice these days -- the minimum malloc() is 16 bytes then this technique will work up to a 64 GB heap size.Well, maybe just scale the 32 bit offset by 8 for a maximum 32 GB heap. All of amd64, arm64, and riscv64 can extend an unsigned 32 bit index to 64 bits, multiply it by 8, add it to a base address, add a further offset (to access a struct field), and load a byte/short/int/long from the final address ... in two instructions:Code:short foo(short *base, unsigned int index){return *(short*)((long)base+8*(long)index+6);}foo:mov esi, esimovzx eax, WORD PTR [rdi+6+rsi*8]retfoo:add x8, x0, w1, uxtw #3ldrh w0, [x8, #6]retfoo:sh3add.uw a1,a1,a0lh a0,6(a1)retWith a x16 scale factor x86 and RISC-V expand to three instructions. Arm is still just two.Conversely, they all still need two instructions just for pointer + 32 bit index even if you don't scale the index, so you might as well scale it...

author: asmi
author_rank: Super Contributor
timestamp: July 22, 2024, 08:34:55 pm
content: devkit is $150 shipping Oct 25th (if ordered today as perhttps://www.microchip.com/en-us/development-tool/curiosity-pic64gx1000-kit-es) It's cool to FINALLY see a SoC with something more than PCIE2x1. Also I like that they support LPDDR4, which is significantly easier to route than DDR4.I wish they'd make higher clocked SKUs of these things, as 625 MHz doesn't sound too exciting. 1GHz and above would be way more interesting.

author: glenenglish
author_rank: Frequent Contributor
timestamp: July 22, 2024, 09:10:56 pm
content: In terms of editors and trees, what does VI and nano use internally for allocation?WHile its all good to talk about gigabytes, there's still us embedded folk running linux in 16MB or 128MB. Of course plenty for text editors even with one element per linked list, but if the editor was thrashing the cache (not full lines in use), then on an embedded system that was doing something moderately real time , the effect of the editor on the real time ish application due to cache eviction (of one element used per list, sparsely allocated, not contiguous) etc is a significant concern. IE it doesnt really matter the RT executable is running FIFO etc priority if that at every chance, the lowly editor kicks out all the juice out of the small cache.

author: glenenglish
author_rank: Frequent Contributor
timestamp: July 22, 2024, 09:17:21 pm
content: and this new PIC64 looks identical to the existing Polarfire SoC FPGA with the FPGA chopped off the side.so the tools probably at least function....

author: brucehoult
author_rank: Super Contributor
timestamp: July 23, 2024, 12:53:52 am
content: Quote from: glenenglish on July 22, 2024, 09:10:56 pmHeh. As the person who raised editor data structures ... the machine we were using was a 16 bit PDP-11/34 which naturally meant a maximum of 64k for each program, but in fact I think in practice the heap couldn't be over 32k. Furthermore, the entire machine had only 256k of RAM shared between 22 users on 22 Visual 100 terminals (plus two LA120 printers), a 5 MB disk pack to store the OS and another 5 MB disk pack to store students' home directories. From memory, you couldn't log off if you had more than 32k of disk files -- you had to delete some first.And we thought ourselves lucky. 1st year students at all other universities in the country were using punched cards.

author: Nominal Animal
author_rank: Super Contributor
timestamp: July 23, 2024, 03:14:01 am
content: Quote from: glenenglish on July 22, 2024, 09:10:56 pmA doubly-linked list of lines, the content on each line being consecutive in memory. Seesrc/definitions.h:typedef struct linestructnear line 475 or so. However,nanois relatively recent (replacement for thepicoeditor as used by e.g.pinemail client), first released in 1999, at which point typical workstations were already 32-bit with megabytes of memory available.Only a decade later, 64-bit workstations were already common. (I mention this because in 2011, Ishowedhow you can use virtual memory to memory-map a terabyte data structure (1,099,511,627,776 bytes) into virtual memory and manipulate it as if it was all stored in RAM in Linux on any 64-bit architecture. Didn't even need a gigabyte (one thousandth) of that of RAM to work well, too.)The way e.g. Apache handles dynamic content (coming from CGI programs, a reverse proxy, or internally via filters) is more interesting. You'll find it in library form in Apache Portable Runtime library,apr-util: Bucket Brigades. It also uses memory pools,apr-util: Memory Pools, for dynamic allocation, so that instead of tracking and releasing/freeing each dynamic allocation separately, each pool can be released/freed at once. (Such pool approach is very efficient for service daemons, as each connection can use their own pool, and that pool released when the connection is closed. We could discuss whether e.g. Boehm GC would be even more effective, but the pool approach makes per-connection resource management easier.)Quote from: glenenglish on July 22, 2024, 09:10:56 pmYep, me included. I have several routers and even aMikrotik RBM33G(MT7621A SoC, MMIPS architecture; running OpenWRT, andplenty(256 MB) of RAM). I remember well the days when I used a Power Macintosh 7200 with 32 MB of RAM to scan and edit very large full-color images and text files in MacOS 7.5.3 very effectively and having fun, too. Iknowfrom experience things are possible; it is just a matter of effort, organization, choosing correct algorithms and approaches, and being willing and able to do the work needed.I also want my userspace applications to tell me when they detect my precious data might have been lost or garbled. Yet, whenever I implement something likeif (close(fd) == -1) {fprintf(stderr, "%s: Error closing file: %s.\n", filename, strerror(errno));exit(EXIT_FAILURE);}I still have todefendit from clueless developers and users examining the code, who don't understand that while this will never trigger for desktop users using one of the most used filesystems, it can still hit users using FUSE or filesystems using delayed flushing like NFS, and is thus worth the "overhead". And if I precede that withif (fdatasync(fd) == -1) {fprintf(stderr, "%s: Error syncing data: %s.\n", filename, strerror(errno));exit(EXIT_FAILURE);}for the most important data files, Ialwayshave to defend having it there, even if everybody involved had already agreed the data was important and we should make sure the OS tells us it has been correctly stored in the filesystem before we exit. It's pretty depressing, really.I think it is a cultural issue. Robust, secure, and efficient code is just not appreciated or considered important anymore; getting new product out quick and often with glitzy features and fanservice is much more important. Bugs can be fixed and security added on top later on (if we happen to win an intergalactic jackpot at some point).

author: glenenglish
author_rank: Frequent Contributor
timestamp: July 23, 2024, 03:26:32 am
content: interestingOn memory pools. I only started splitting up my memory pools (per your example of APache maintainging multiple owned pools) - I only started splitting up my memory pools when I starting including webservers in my devices (FreeRTOS) and had to avoid situations where tight memory availability together with HTTP dynamic situations, and hung up HTTP sessions etc could only hurt those that caused the problem, as the meat of the application allocated all its buffers and vars it needed at start of runtime and they'd never be revisited apart from the occassional very large sprintf debug/ journaling job (where again I could have used a static allocation for sprintf instead of a malloc - but theres a point in life where you say F**k It, I want to be concentrating on the algorithms and not have to concentrate on having this device survive on an oily rag of memory.As for "Robust, secure, and efficient code is just not appreciated or considered important anymore;"do you think this is the domain of old folk (like me) that used to work inside 4k of 2114 ram on 6800s. Well probably not precisely, since there was really no concept of secure back then. I think Robust and efficient is a cultural thing needing to be mentored into people. As for efficient - Back in 1978, efficient was all that would fit...Or is this about that few people that work on stuff that it is very bad if it fails to work as required ? glen.

author: Nominal Animal
author_rank: Super Contributor
timestamp: July 23, 2024, 05:17:21 am
content: Quote from: glenenglish on July 23, 2024, 03:26:32 amEven when you have lots of memory, you can still have even more active connections, and start to suffer from all sorts of buffer issues, especially when the content is generated dynamically or reverse proxied from another device... I too have gone down this rabbit hole, so deep that I eventually emerged with a simple two-part proposal for replacing the underlying protocol and the HTML syntax with better ones, a combined one that needs very little buffering and allows multiplexing multiple data streams (like metadata and content, or even multiple requests in parallel; especially useful for TLS-secured connections). One day, I might be ready to try and publish them.Quote from: glenenglish on July 23, 2024, 03:26:32 amThe recently published Linux Foundation survey onsoftware security educationis a very good read to see how Linux developers self-report about security.As to robust and efficient: About three decades ago in mid-90sDaniel J. Bernsteinpublishedqmail, a rock solid email transfer agent, at the same time when Sendmail was king and as secure as an empty car running with driver's door ajar and a wallet in the passenger seat in a bad neighborhood. Every time I interacted with other sysadmins, I had to defend my use of qmail instead of sendmail, for no other reason except "everybody else is using sendmail so it must be superior". Similarly for djbdns/bind – although they are not exactly equivalent in terms of features; djbdns is better suited for smaller and simpler installations. And I still use the DJB2 Xor hash for hashing human-readable names when examining the length of the name; it's an excellent hash especially on embedded targets for that. I do not know DJB as a person, but I definitely appreciate his work output, because it is proof that robustness and efficiency is achievable in practice. Unfortunately, it is also proof that if you manage to do so, you'll be targeted by those who are either unable or unwilling to achieve the same, and basically vilified.For my part, I've resigned to point out and help in how to do better when someone obviouslywantsto do better, but it is becoming a chore as I always end up having to defend "useless error checks" and "paranoia" from those who believe security and bugs is what you may work onafteryou've sold the product, not before. In particular, I believe that even beginners should include all the necessary error checks, and work on writing useful comments (describingwhyandhowthe author intends the code to work, instead of describing what the code obviously does), because if you learn to write bad code with no comments, it is double the work to un-learn and re-learn to write good maintainable code with useful comments later on –– and most developers just don't bother to, because they're only human. Me too: I still struggle to write better comments.I'm not sure how this all relates to RISC-V.Ifeelit is an useful development, combining a huge amount of experience and knowledge into a new architecture design that all can use, somewhat similar to how free/open software is an attempt to avoid similar experience and knowledge from being locked up in dead-end products and rediscovered again and again; and I think there is some connection to the cultural/education issues or changes needed to truly exploit the possibilities we have here, but it is just a feeling or an opinion I am not clear or certain about yet. I do wish it will soon-ish (say, within the decade) get similarly open competitors that approach the problem from a completely different angle, perhaps directed more towards hard real-time and massively concurrent tasks (somewhat similar to xCORE, NPUs, or general purpose GPU computing); if not for any other benefit, then just for the competition that will keep the field alive and avoid stagnation. I'm tempted to extend the concept into new programming languages, but that's another can of worms that tends to end up derailing threads... suffice it to say that programming languages have added many new useful abstractions on top, and compiler technology has progressed with leaps and bounds especially in optimization, but at the core, there has been very little true evolution at the core of programming languages, even though our needs (especially wrt. parallel and distributed computing) are changing.

author: NorthGuy
author_rank: Super Contributor
timestamp: July 23, 2024, 03:46:59 pm
content: Quote from: Nominal Animal on July 23, 2024, 03:14:01 amMany people consider that "efficient" means using as little resources as possible. Hence, they think if you have lots of resources, there's no need to be efficient. That's the main reason the efficiency is not considered important nowadays.I believe that "efficient" means using the available resources to maximize your benefits. For example, if you use more memory to simplify your algorithms making them faster and more reliable, this makes your code more efficient. On the other hand, if you waste resources on various forms of bloat, this is not efficient because resources are used, but there's no benefit. Similarly, if you leave the majority of resources unused, this cannot be considered efficient because the unused resources don't bring any extra benefits.

author: Nominal Animal
author_rank: Super Contributor
timestamp: July 23, 2024, 06:14:26 pm
content: Quote from: NorthGuy on July 23, 2024, 03:46:59 pmIt is an acceptable definition, yes. To me, it is about efficiency and robustness as a tool.Even in the example I mentioned, by choosing a better approach one can use more CPU resources but less wall clock time (by reading data into a self-sorting structure instead of reading all data first and then applying a sorting algorithm, because transfer from storage takes more time than sorting does),if that is what makes the users' work flows more efficient. (In that sense, for a proprietary embedded device, people might disagree as towhosebenefits should be maximized: the vendor/provider, or the end user, for the device to be "efficient".)The issue, as I see it, is that "efficiency" in any definition just isn't a concern. Even user data collection is based on what the vendor can get away with, rather than what the vendor actually needs, with the data needed for debugging known issues appended at end, often as an afterthought in later revisions."Robustness" is not a concern either. I consider it to be the ability to deal with unexpected data and situations, and to report any causes for concern including possible loss of data. For embedded devices and microcontrollers without user-accessible logging facilities, we do need to use a slightly different definition, perhaps the ability to recover from problem situations with minimal effect on the human users and whatever data/control the device deals with.I personally use these terms in the generic sense, to be defined in detail for each product/tool, depending on how the product/tool is used.

author: DiTBho
author_rank: Super Contributor
timestamp: August 02, 2024, 03:45:29 am
content: Quote from: brucehoult on July 06, 2024, 05:33:51 amSome company located in the UK also have a warehouse in ireland, which is import-free to Europe.If you are lucky and find they have, you can ask to have your goods shipped not from the UK but from Ireland