The Raspberry PI PICO 2, now has extra RISC-V cores

[ftg]

This would imply they had major issues with E-field coupling to internals.

Since it is caused with inductor, it looks more like H-filed coupling issue.
Which is even worse, because its hard to shield H-fied coupling in near field region.

I think this is a big mistake to share MCU die with switching converter. By embedding it inside MCU they got a lot of issues and now needs to spend a lot of time to fight with power supply issues instead of fix and improve MCU itself.

They needed to add USB HS instead of switching converter.   

Silicon Laboratories was able to pull off a rather decent DC-DC converter on the same die with an ARM MCU and dualband sub-1GHz and 2.4GHz radios in their EFR32 series.

[radiolistener]

I may have missed it (I scanned the thread but it's 6 pages). Is your comment speculation, or an opinion based solely on that text in the guide, or based on something else?

Regarding switching converter serious.

Regarding USB HS...  partly joke, partly tease, but partly serious...
I know most likely they wouldn't have added it anyway, but I'd like to see it, because it's not usable for my tasks without fast communication interface...

Silicon Laboratories was able to pull off a rather decent DC-DC converter on the same die with an ARM MCU and dualband sub-1GHz and 2.4GHz radios in their EFR32 series.

Yes, some chips have it together with analog parts sensitive to interference, but it adds more issues than good value. I think it's better to spend money and time which was used for its design to improve ADC, PLL and other MCU things.

[iMo]

..Is there somewhere an another switcher on the chip? 
PS: Yep there is one for the 1.1V DVDD..
But you may replace it with a linear LDO one as well, my bet..

From DS:

The regulator can be directly controlled by software, but must first be unlocked by writing a 1 to the UNLOCK field in the
VREG_CTRL register. Once unlocked, the regulator can be controlled via the VREG register.
The regulator’s operating mode defaults to Normal, at initial power up or after a reset event, but can be switched to High
Impedance by writing a 1 to the VREG register’s HIZ field. The regulator’s output voltage can be set by writing to the
register’s VSEL field, see the VREG register description for details on available settings. To prevent accidental overvoltage,
the output voltage is limited to 1.3 V unless the DISABLE_VOLTAGE_LIMIT field in the VREG_CTRL is set. The output
voltage defaults to 1.1 V at initial power-on or after a reset event.

Thus the simplest way (A) could be to wire a linear 1.1V LDO (1.2V would work fine imho) via a small resistor (like 4R7 or smaller, for example, it will work as protection when both regulators work and after switching off the internal switcher it will work as the RC filter/decoupling..) to the DVDD and after the reset simply do switch off the internal switcher by setting it into the HiZ state..
And (B) you may remove the 3u3 coil from your pcb (when the 3u3 coil has been removed you may remove/short the 4R7 as well)..

[SiliconWizard]

This would imply they had major issues with E-field coupling to internals.

Since it is caused with inductor, it looks more like H-filed coupling issue.
Which is even worse, because its hard to shield H-fied coupling in near field region.

I think this is a big mistake to share MCU die with switching converter. By embedding it inside MCU they got a lot of issues and now needs to spend a lot of time to fight with power supply issues instead of fix and improve MCU itself.

They needed to add USB HS instead of switching converter.   

Silicon Laboratories was able to pull off a rather decent DC-DC converter on the same die with an ARM MCU and dualband sub-1GHz and 2.4GHz radios in their EFR32 series.

Many do, that's certainly doable. The benefit is more integration, but also giving the ability for instance to shut down the buck converter internally in some low-power modes. IIRC, some STM32 MCUs do also have an integrated buck converter, and some others don't but do support external buck converters (and have a pin that can act as an enable for it).

I think what a few said is probably right, they probably don't have a ton of experience relative to analog microelectronics at the RPi and will occasionally get bitten by this kind of issues more so than other vendors.

[josip]

Is there any video, pdf, web page, whatever, with details about dual-issue common 16-bit instruction pairs on M33?

[brucehoult]

Is there any video, pdf, web page, whatever, with details about dual-issue common 16-bit instruction pairs on M33?

M33 is dual issue???

Hard to believe given it's only 7% faster on Coremark than the Hazard3 RISC-V core which was developed part-time by one of Raspberry Pi's own engineers.

Dual-issue M7 is 5.29 Coremark/MHz. M33 is quoted at 4.09, and the Hazard3 at 3.81.

I'll be running my primes benchmark on both cores as soon as I can get my hands on a board. Or if someone already has one, I'd welcome a submission.

[MK14]

Is there any video, pdf, web page, whatever, with details about dual-issue common 16-bit instruction pairs on M33?

M33 is dual issue???

Limited dual-issue of common 16-bit instruction pairs

Source:
Google search results, but it gave this as a source reference:
(Arm website, then it has a download of) Arm-Cortex-M33-Processor-Datasheet-1.pdf

Hence not that much of a speed up, seen on the benchmark.

But, could (in theory), allow better performance, in carefully hand-crafted code (assembly or C where you mess around with the source, until its outputted assembly, meets your desires and expectations).

[jnk0le]

Is there any video, pdf, web page, whatever, with details about dual-issue common 16-bit instruction pairs on M33?

M33 is dual issue???

Hard to believe given it's only 7% faster on Coremark than the Hazard3 RISC-V core which was developed part-time by one of Raspberry Pi's own engineers.

Dual-issue M7 is 5.29 Coremark/MHz. M33 is quoted at 4.09, and the Hazard3 at 3.81.

I think it's the same "limited dual issue" as on CM55 which has the official optimization guide here:
https://developer.arm.com/documentation/102692/0101

M33 -> M55 coremark difference is most likely HW loops or the 0 cycle branch (which is a reuse of LOB buffer from HW loops)

[MK14]

I've found/read/heard some rumors (also subject to me understanding it correctly), that seem to be correct, and make this new RP2350/PICO2, even more interesting and amazing.

Apparently, the additional RISC-V cores, don't add a significant amount to the transistor count.  Because, its design/layout was simply fed into the 'designer software' tool, which just combined/optimized, the whole lot, together.
Since, bigger blocks like the Multiply 32 x 32 ==> 64 bits, and fast divider and stuff, could be shared between the core types, as the tool was smart enough to realize/handle the fact, that you could only select one CPU type or the other.

Which would mean, that attempts to glitch/hack/force the chip into some kind of 4 core mode, would fundamentally NOT succeed, as they share so much logic.

Also, the boot ROM, was not big enough to store the code for both CPU types.  So, it only (or mainly) has Arm code in it.  But, a special emulator (**VARMULET) is run on the RISC-V core, during booting, which emulates Arm instructions, so that it can share enough of the code, to fit it all in (128 KiB or kB, IIRC).

** = https://github.com/raspberrypi/armulet

Also, the built in OTP, has flag bits, which allows one to permanently disable, core types, if you want.  E.g. Eliminate (disable) the RISC-V cores, permanently.
I'm not sure, exactly why.  Perhaps for security/reliability reasons, or maybe to allow them to be sold as different chip variants, for certain markets (possibly changing the Arm license fees, as well).

Additional rumors, are that there were/are fears, over very significant Arm license fee cost increases (for reasons).  So, the RISC-V's could either be replacements or bargaining chips, to get the best licensing fees.

EDIT:  Added name and link to emulator

[Postal2]

...... Also, the built in OTP, has flag bits, which allows one to permanently disable, ......

I liked it. It's like adding a "turn off forever" button on the TV remote control next to the "turn off" button.

[jnk0le]

M33 -> M55 coremark difference is most likely HW loops or the 0 cycle branch (which is a reuse of LOB buffer from HW loops)

or double wide scalar load/store (reuse of mve datapath)

[shabaz]

The 'Pimoroni Pico Plus 2' still says on its product page:

    Download a printable PDF version
    Schematic (coming soon)

Added some better photos in case anyone is interested to decipher the parts used. One is the PSRAM chip of course, but the other zoomed image shows a 6-pin 2mm x 2mm DFN style part labeled YE 1 IA
It seems to be the only IC that may be the DC-DC converter.

I just spent most of the day installing the new 2.0.0 SDK and ARM toolchain etc., on Windows. Not a fun exercise, eventually got it functioning.

[SpacedCowboy]

Interesting comment from the raspberry pi pico forums:

It has proved trivial to get MMBasic running on the RP2350 so many congrats to the developers for creating such a seamless environment.

Perfornance running MMbasic is >150% in general AND the chip overclocks just as well as the RP2040 (running at 378MHz with no issues)
At this overclocked rate performance is 50% of a STM32H743 which given the price comparison is amazing

See https://www.thebackshed.com for more details

[macaba]

I just spent most of the day installing the new 2.0.0 SDK and ARM toolchain etc., on Windows.

Hopefully will help the next person:
In VS Code, there is a “Raspberry Pi Pico” extension that takes seconds to install. The toolchain downloads after completing the “New Project” process (an option that appears on the new Raspberry Pi area that appears) and takes a minute (depending on internet speed).

The source of the extension is on GitHub so nothing secret/closed.

[jnk0le]

more info on the inductor thing from jdb:

The design guide gives somewhat undue attention to the inductor and the effects of the fringing magnetic field on the nearby components. A Pico 2 will work fine if you unsolder the inductor, throw it up in the air, then solder it back down in the orientation it landed in.

The main effects are on static regulation, where there's an unexplained offset voltage of the order of 30mV at a chip-dependent VDD current draw, and an unexplained slight efficiency degradation at this inflection point.

Hence the comment that we're still working with the IP vendor to find out why this is the case.

[exe]

Ha-ha, love the humor. Finally we've got details!

I'm surprised that the difference is that big (30mV), and that it is present under static (steady power consumption?) condition. I don't know much about SMPS, so, guys, tell me, is this normal? Actually, it probably is, as I quickly googled and found this article: https://www.analog.com/en/resources/analog-dialogue/articles/does-the-assembly-orientation-of-an-smps-inductor-affect-emissions.html .

I wonder, can I determine the best polarity with just a 100MHz scope just by probing at inductor? On the other hand, direct probing can be tricky due to dense layout of the board...

[MK14]

Thanks to EVERYONE, as there are many interesting and informative posts, in this thread.   

more info on the inductor thing from jdb:

The design guide gives somewhat undue attention to the inductor and the effects of the fringing magnetic field on the nearby components. A Pico 2 will work fine if you unsolder the inductor, throw it up in the air, then solder it back down in the orientation it landed in.

The main effects are on static regulation, where there's an unexplained offset voltage of the order of 30mV at a chip-dependent VDD current draw, and an unexplained slight efficiency degradation at this inflection point.

Hence the comment that we're still working with the IP vendor to find out why this is the case.

That's brilliant, and EXACTLY what I (and probably others), wanted to know.

So, even if this 'issue' manifests itself.  It doesn't sound too bad at all.  Unless the entire/full range of any datasheet information, is super-critical.  E.g. Trying to operate it at the bare minimum, or maximum voltages, or very near the minimum or maximum allowed, current ratings, etc.

As I understand it (so I could be mistaken here), in standard designs with the RP2350/PICO2, the ADC gets its reference voltage from that same supply voltage, so could be affected (back of envelope, wild estimate, ball park figure), by 1%, since 30 mV is about 1% of 3.3 V.

So, this issue, is sounding like it is not particularly important, for many applications, many of which, won't even be using the ADC, or won't be bothered by a theoretical 1% of extra error, under some circumstances, maybe?

Anyway, the ADC guide seems to discuss, changing (into fixed PWM mode?) or even disabling, the SMPS, when taking readings, if you want the best accuracy.

Which to me sounds far fetched, as software can be big and complicated.  Perhaps using many libraries, and a number of different people, contributing to writing it,

So, to have to change or even switch off the built in SMPS, seems tricky at best to arrange (if there is more than one software developer), and possibly problematic in its own right.

E.g. What if an interrupt or something, causes a (very relatively speaking, for this in general low current device, overall) high current, output device to suddenly turn on, while the SMPS is being messed around with, by the ADC reading software driver section.

In other words, I don't like the sound of changing or disabling the SMPS settings, while reading the ADC, as it sounds unprofessional, and potentially problematic, and possibly difficult to implement, as well.

I.e. It sounds like a hack or bodge, rather than a good feature.  On the other hand, it does give a rather low cost device, the capability, to act like a better, and much more expansive one, even if it is a bit fiddly to implement.

Anyway, the entry level chip, only has 4 ADC inputs, which is a very small number, relative to most modern MCUs, meant for that kind of operation.

EDIT: Typo and small changes

EDIT2: I think I was mistaken, and had inadvertently read stuff about the OLD PICO (RP2040), without realizing.  So, I've tried to correct (strike out), this post, to avoid spreading FUD.

Please ignore the following for the RP2350/PICO2, only here to show where my mistake came from, probably:
Probable mistaken information, was possibly from here:
https://www.reddit.com/r/raspberrypipico/comments/ptwkxu/noisy_analog_read/

[MK14]

Interesting comment from the raspberry pi pico forums:

It has proved trivial to get MMBasic running on the RP2350 so many congrats to the developers for creating such a seamless environment.

Perfornance running MMbasic is >150% in general AND the chip overclocks just as well as the RP2040 (running at 378MHz with no issues)
At this overclocked rate performance is 50% of a STM32H743 which given the price comparison is amazing

See https://www.thebackshed.com for more details

That is rather amazing in its own right.  The STM32H743 is quite a power house (and rather expensive), with its slightly greater than (claimed) 1,000 DMIPs of (M7 core) performance, claimed on the ST website.

Although, the overclocking is a bit naughty, and probably wouldn't suit production runs, anything even if vaguely critical/important, or (unsuspecting) customer releases.

But for fun hobby projects, and non-professional experiments, it sounds like fun.

It is not just the cost of M7 cores, that can be the issue, either.  Those modern, all singing and dancing, powerhouses, can be difficult, for a lone developer or hobbyist, to get around the vast and complicated, peripheral sets, they usually have.

Also, dependent, on if you want to program it yourself, in assembly(not necessarily applicable for the M7)/C/similar-languages, without much help from libraries and things.

In other words, I think something the size and complexity of the RP2350 (PICO 2 etc), can be handled, by a lone developer or hobbyist, without needing to resort to complicated operating systems (rather small simple OSs can be ok) and/or (big complicated) libraries and/or other stuff, to handle all the complexity.

A bit like older times, when 8 bit microprocessors and 8 bit MCUs, were common-place.  Where you could read the databook, over a weekend, and start programming it in anger, first thing, Monday.  In assembly code, if necessary.

[zapta]

Possibly they are the same cores, just switching at boot time a different microcode.

[MK14]

Possibly they are the same cores, just switching at boot time a different microcode.

I'm not sure if they are microcoded CPUs or hardwired.

Off-hand, I assumed/thought they would be hardwired, especially for the RISC type of CPU (as non-RISC CPUs, especially ones with massively big and complicated instruction sets, can get too complicated to readily hardwire the design), to give the highest speed and lowest power consumption.

But microcoding, does in theory, make the design process quicker, and (as you suggest), allow the same/similar CPU, to handle multiple instruction set formats.

[oPossum]

This is the RISC-V core: https://github.com/Wren6991/Hazard3

[MK14]

This is the RISC-V core: https://github.com/Wren6991/Hazard3

It was fed into the synthesis tool (or so I was led to believe), as 2005 Verilog, and optimized the entire chip, with it.  Adding very few transistors, to the overall transistor budget.

I don't know how accurate my original source is, so if you want to know for sure, best to wait or find a 100% safe source.

EDIT:  My (unspecified) source, is NOT hugely trustworthy (such as other forums), but may be true.

EDIT2:  Unfortunately, I didn't keep note of the original source(s), and read a number of things, potentially.

But it might have been, and was similar, to the following, which has additional details, as well:
https://news.ycombinator.com/item?id=41214307

[ataradov]

I don't think there are any tools that could just do that automatically. There would have to be corresponding Verilog code for sharing parts of the design. Tools would optimize the design, but the logic still should match what is written in the code. Otherwise verification of such "optimized" would be a real nightmare.

[MK14]

I don't think there are any tools that could just do that automatically. There would have to be corresponding Verilog code for sharing parts of the design. Tools would optimize the design, but the logic still should match what is written in the code. Otherwise verification of such "optimized" would be a real nightmare.

I can well believe it (what you just said).

It can be hard enough, just to get a simple (small) FPGA to do what you want.

I have noticed, the cycle counts (at a quick glance), of the 32 x 32 ==> 64 bit multiply, and (somewhat) fast integer divider, instructions, seem to be the same, between the Arm M33 and RISC-V cores.  Which makes me wonder, if they share the same units.

It is probably a bit too soon, for the proper information to come out.  But, in time, I expect there to be (somewhat) official videos or accounts.

Between, e.g. Jeff Girling and Eben Upton, with an hour long chat, perhaps at the Cambridge (UK) Raspberry PI Headquarters (again, IIRC), where such details, may be revealed.

[shabaz]

I just spent most of the day installing the new 2.0.0 SDK and ARM toolchain etc., on Windows.

Hopefully will help the next person:
In VS Code, there is a “Raspberry Pi Pico” extension that takes seconds to install....

Very useful info! I use JetBrains CLion which had a few complications in the setup unfortunately. Pico with CLion info here in case anyone else is using that. But would strongly suggest people try it from command line (Windows or Linux), or VS Code, as you suggest, and once successful, then try CLion if interested. I tend to install on both Windows and Linux, but decided with the new SDK to bite the bullet and try on Windows first since that usually is more problematic.