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

[radiolistener]

I think you and I are doing very different things, which might explain why we seem to have a different opinion on this MCU. I want response times in tens of nanoseconds

I'm interesting in realtime capture, DSP processing and transferring high speed streams. The main focus is to keep processing with no breaks, because it leads to broken realtime stream. If there is 100 ns delay that's not a problem, because CPU is fast enough to process more data on next 100 ns... 

Raspi Zero 2w has pretty fast 4 cores, so processing speed is not a problem to run linux in background.
But small memory size is noticeable bottleneck. My tasks don't require so many memory, but when running some linux tasks it is very noticeable.

[PCB.Wiz]

I don't know any chips in this size with usable USB HS, you?

WCH have a HS-USB MCU that comes down to TSSOP20.

[tszaboo]

I think you and I are doing very different things, which might explain why we seem to have a different opinion on this MCU. I want response times in tens of nanoseconds

I'm interesting in realtime capture, DSP processing and transferring high speed streams. The main focus is to keep processing with no breaks, because it leads to broken realtime stream. If there is 100 ns delay that's not a problem, because CPU is fast enough to process more data on next 100 ns... 

Raspi Zero 2w has pretty fast 4 cores, so processing speed is not a problem to run linux in background.
But small memory size is noticeable bottleneck. My tasks don't require so many memory, but when running some linux tasks it is very noticeable.

The Zero is has A cores on it with the intention is to run Linux.
These have M cores on them.

USB HS is not trivial for microcontrollers, because you have to be able to run transistors in your design at 480MHz to be able to send the data.
This microchip run at a max of 150 MHz, despite that you repeatedly call it 300 MHz, it's not that much. You cannot add the MHz together. Nor can you compare overclocked performance with design specifications.
You need to work on different semiconductor nodes to have USB HS. Your transistors that are available are different.
And the target audience is different. People want to run Micropython and have USB mass storage and a serial terminal on this, not stream data.

[radiolistener]

This microchip run at a max of 150 MHz, despite that you repeatedly call it 300 MHz, it's not that much. You cannot add the MHz together. Nor can you compare overclocked performance with design specifications.
You need to work on different semiconductor nodes to have USB HS. Your transistors that are available are different.
And the target audience is different. People want to run Micropython and have USB mass storage and a serial terminal on this, not stream data.

Mass storage also needs high speed.

Regarding to the frequency, if I understand correctly, they can simply use PLL block to generate higher clock frequency and run USB peripherals at higher speed, then synchronize it with slower core clock, so the core can continue to run at 150 MHz and will be able to configure USB and it's DMA which can transfer data from core or directly from other peripherals like memory, ADC, GPIO, etc. Isn't it?

If it can run entire Cortex-M33 core from 300 MHz clock with no issue, I'm sure transistors on that silicon can run at higher clock.

You're talking like there is some fundamental limitation, but I don't see where is the limit? Even if core will send data to USB module at 120-240 MBps that's not a big issue. 240 MBps also pretty good speed in comparison with 12 MBps.

Regarding to micropython, I don't see the real purpose for that. If you want to run interpreter at real time through console you can use Raspi Zero, but if you're programming some function for MCU, there is no reason to use python. This is just a toy to run something like print("Hello world") from console and say "Cool! It can run python..." 

[iMo]

@radiolistener: I got two pi-zero-2W at a local ham radio flea market almost free this spring and spent a couple of weeks with it. It is a barely usable board, imho. Well, good for a headless "business as usual" experiments with linux. I even ran OMV nas on them. Not suitable for smaller or specialized projects where we usually utilize mcus for many reasons. A flop I would say..

It seems to me the Pico and Pico2 have been developed by a group of people with an access to only a limited set of silicon libraries and dev tools, I would say more-less talented graduates who got a limited support from a large manufacturer with "show us what you can do but it should be cheap"..
We cannot compare that effort and results with mcus from full fledged vendors like STM, Freescale, Microchip, etc. 

[MK14]

Look, it's a moderately powerful, from $0.80 a chip, and low cost development platform (from around $4 a board).

Some people in this thread, seem to want it to act like a reasonably powerful single board computer, with fast/powerful USB connection(s), and other powerful stuff.

If that is what you want, then be prepared to fork out tens of dollars and get the PI Zero or bigger, full PI versions.

Overclocking it to 300MHz, insisting they put USB2 or even USB3 on it, is perhaps being a little over the top.

Its PIO system, can be very powerful and useful, in some applications.

I agree, it's a pity, they didn't give it more I/O fabric, such as some timers, input captures, output compares and other typical I/O things.

But missing USB2 or even USB3, is really going outside what I think this device should be reasonably used for.

At its official/guaranteed 150 MHz, you can't process lots of data, that quickly (with some probably simple task, such as data movement between devices, highly optimized exceptions, occasionally), so would be better off, with a proper high speed MCU, appropriately fast USB interfaces (2 or 3), along with the (usually) considerable increase in cost of the device.

[brucehoult]

I agree, it's a pity, they didn't give it more I/O fabric, such as some timers, input captures, output compares and other typical I/O things.

I don't think I've ever read a motorcycle review, whether 250cc or 1250cc, that didn't say "It would be better with 50cc more...".

Same deal here.

Sure, but then it would be a different product, in a different class. Other products already exist in that class ... buy one of them and let this one do the job it was designed to do, at the price it was designed to be.

[radiolistener]

At its official/guaranteed 150 MHz, you can't process lots of data, that quickly, so would be better off, with a proper high speed MCU, appropriately fast USB interfaces (2 or 3), along with the (usually) considerable increase in cost of the device.

I didn't worked with RP series MCU, but I read in their advertisement that it has single cycle 32-bit MAC and two cycle float64 operations. After all it can write at least 32-bits per cycle. At 150 MHz it can produce up to 4800 MBps with simple bit-banging... And even can do something more complicated and useful, like applying filter to the realtime stream on the fly.

And since it has 2 core, it can produce up to 9.6 GBps stream with dumb write in a loop. This is 800 times higher than USB HS 480 MBps bandwidth.

With 300 MHz overclock it can produce up to 19.2 GBps, but USB bottleneck is just 0.012 GBps... which is 1600 times slower than MCU can produce...

With no high speed communication interface all that speed is almost useless...
What is the reason for two cycle float64 operation or single cycle MAC if there is no way to get the data at higher than 12 Mbps?
And no way to transfer processed data out of the chip at speed higher than 12 MBps...

[MK14]

With the original release of the PICO (RP2040), there was a bug(s) in the original initial revision (IIRC A1), which meant that floating point operations (singles worked but not double, IIRC), via its inbuilt software library (like) feature.

But, a few months later (I can't remember exactly how long it was, it might have been only a few weeks, or it could have been a lot longer), they released (IIRC) the A2 version, which was working just fine.

I'm not happy with what I'm hearing about the built in SMPS, which sounds like it might be problematic and/or very tricky to design that feature of the device.

If that is the case, I'm hoping they fix it, or at least improve the situation.

It is not clear if the current crop of development boards, that are for sale.  Will work alright, as regards possible voltage regulator (SMPS) issues, or not.

I'm probably being overly cautious here (maybe way so).  But since I don't have any PICO 2's yet.  I'd prefer to wait, until they fix any issues, as necessary.

[SiliconWizard]

This SMPS issue sure is disappointing. I don't know if they can easily fix it with a "small" silicon revision. We'll see.

[MK14]

I didn't worked with RP series MCU, but I read in their advertisement that it has single cycle 32-bit MAC and two cycle float64 operations. After all it can write at least 32-bits per cycle. At 150 MHz it can produce up to 4800 MBps with simple bit-banging... And even can do something more complicated and useful, like applying filter to the realtime stream on the fly.

But with no high speed communication interface all that speed is almost useless...
What is the reason for two cycle float64 operation or single cycle MAC if there is no way to get the data at higher than 12 Mbps? And no way to transfer processed data out of the chip at speed higher than 12 MBps...

Lots and lots of things.

For starters, the (encouraged to use, by the PI foundation) Micropython is an interpreter,  so is not going to set any speed records.

Some things, even in C/C++, can need quite a few lines of code, maybe hundreds, thousands or more, in order to process the algorithms and do all the calculations.

In which case, they probably would not handle or need that much data throughput, going in and out.

I agree there is the odd edge case, where the task is so simple, like moving data between devices, that it could easily overload the slower, old USB interfaces.
But that is just one of tens of thousands (or more), of possible application areas.

Basically, with MCUs, you get what you pay for.

If you want a quad core 900 MHz operations, dual-issue, out-of-order execution, MCU, with 276 pins, full range of possible I/O devices, USB3 built in, etc.  16MB of on-chip SRAM, 32MB of built in flash, all on the same die.  Quad 10 MHz 16 bit analogue converters, quad 14 bit DACs, with 8 spare very high speed op-amps, analogue comparators, etc.

Then the MCU, usually costs more than the $0.80, I originally mentioned.
Even tens times as much, $8 (I'm not sure, but definitely a lot more than $0.80 each), probably wouldn't be nearly enough.  Unless the quantities involves were massive, perhaps 100,000 or even millions, needed.

[tszaboo]

This microchip run at a max of 150 MHz, despite that you repeatedly call it 300 MHz, it's not that much. You cannot add the MHz together. Nor can you compare overclocked performance with design specifications.
You need to work on different semiconductor nodes to have USB HS. Your transistors that are available are different.
And the target audience is different. People want to run Micropython and have USB mass storage and a serial terminal on this, not stream data.

Mass storage also needs high speed.

Regarding to the frequency, if I understand correctly, they can simply use PLL block to generate higher clock frequency and run USB peripherals at higher speed, then synchronize it with slower core clock, so the core can continue to run at 150 MHz and will be able to configure USB and it's DMA which can transfer data from core or directly from other peripherals like memory, ADC, GPIO, etc. Isn't it?

If it can run entire Cortex-M33 core from 300 MHz clock with no issue, I'm sure transistors on that silicon can run at higher clock.

You're talking like there is some fundamental limitation, but I don't see where is the limit? Even if core will send data to USB module at 120-240 MBps that's not a big issue. 240 MBps also pretty good speed in comparison with 12 MBps.

Regarding to micropython, I don't see the real purpose for that. If you want to run interpreter at real time through console you can use Raspi Zero, but if you're programming some function for MCU, there is no reason to use python. This is just a toy to run something like print("Hello world") from console and say "Cool! It can run python..." 

It cannot run it at 300MHz. You can overclock it and maybe run it at room temperature at 300MHz and it kinda sorta works sometimes, and you haven't verified all the rest of the datasheet values. There is no immediate step for USB. You ether run it at 12 Mbit, or 480 Mbit, there is no in between. The clocking speed is going to be the same, but half the time it's not going to send data.
The mass storage class is there to write the 4 Mbit flash memory with code. You don't need high speed for it, since most of the time it's used to edit the code. Writing is going to be seriously limited by the flash erase anyway, reading is like 3 seconds.

Despite what you think, Micropython is the main purpose of this chip. I guess 99% of users are either running micropython or the Arduino IDE and core for this chip.

[iMo]

..
What is the reason for two cycle float64 operation or single cycle MAC if there is no way to get the data at higher than 12 Mbps? And no way to transfer processed data out of the chip at speed higher than 12 MBps...

That could be useful for I/Q based DSP (today's standard) when you are going to process data from an external simultaneously sampling ADCs and the results are fed into an external something (like DAC or codec or similar in case of an SDRadio).
They still have a problem with that simple ADC, it seems, because of the internal noise, or they do not have better ADC silicon libraries handy, or lack of experience (ie the ADC bug in the previous pico version where they messed up the sizes of the weighting capacitors in their SAR ADC - a not easy to fix bug cheap as you would need to generate many new masks for a lot of $$ ).
The same with USB2.0 - it may need silicon libraries, royalties to pay (perhaps), and much better signal integrity in the overall design as atadarov wrote..

[radiolistener]

You ether run it at 12 Mbit, or 480 Mbit, there is no in between. The clocking speed is going to be the same, but half the time it's not going to send data.

You can run USB module from 480 MHz or whatever you want frequency. USB module can have its own small buffer to perform operations at max speed with no needs to wait for the main core intervention. Its not a big deal to implement clock domain crossing synchronizer, so the core can continue to work at slower clock.

[PCB.Wiz]

But with no high speed communication interface all that speed is almost useless...
What is the reason for two cycle float64 operation or single cycle MAC if there is no way to get the data at higher than 12 Mbps? And no way to transfer processed data out of the chip at speed higher than 12 MBps...

Surely the QSPI can go well above 12mbd ?
The native QSPI port looks very fast, but is shared with boot flash, (and I think is master only?) so you may prefer PIO.

 The WCH CH347 is a low cost TSSOP20 HS-USB part that has a QSPI interface they claim 60MHz for, so that's 240 Mbd

The posts like here
https://forums.raspberrypi.com/viewtopic.php?t=321476#p1924376
suggest a clocked QSPI slave using PIO can manage something under 50MHz, (~200MBd) it would need tsu/th checks on the CH347 pairing.
Choices would be 50MHz / 37.5MHz / 30MHz / 25MHz etc if you pick whole clk_peri/N matching, tho that's not mandatory.

The std SPI peripherals say this too

At the maximum SSPCLK (clk_peri) frequency on RP2350 of 150MHz, the maximum peak bit rate in mastermode is 70.5Mb/s.
In slave mode, the same maximum SSPCLK frequency of 150MHz can achieve a peak bit rate of 150 / 12 = 12.5Mb/s.

[tszaboo]

You ether run it at 12 Mbit, or 480 Mbit, there is no in between. The clocking speed is going to be the same, but half the time it's not going to send data.

You can run USB module from 480 MHz or whatever you want frequency. USB module can have its own small buffer to perform operations at max speed with no needs to wait for the main core intervention. Its not a big deal to implement clock domain crossing synchronizer, so the core can continue to work at slower clock.

You are not listening, do you?
The transistors in the node don't switch at that speed. You need a different process node to have transistors that are designed to work at that speed. And with that, your entire digital design is different.

[radiolistener]

That could be useful for I/Q based DSP (today's standard) when you are going to process data from an external simultaneously sampling ADCs and the results are fed into an external something (like DAC or codec or similar in case of an SDRadio).

Yes! This is wonderful feature, but the problem here is that there is no fast enough communication between core and external world.

What is the reason to do some DSP operation at 1 cycle if core will needs to waste next 800 cycles just to wait for the next data word? 

They still have a problem with that simple ADC, it seems, because of the internal noise, or they do not have better ADC silicon libraries handy, or lack of experience

I'm sure this is because they put switching converter inside MCU. This is definitely a bad idea. ADC needs to place any switching mode converters far away as you can. And if you use switching converter in your circuit at all, it requires serious effort to filter and block the noise to avoid any leakage to ADC circuit. When you put switching converter on the same die with ADC, it will be impossible to get good ADC performance.

You are not listening, do you?
The transistors in the node don't switch at that speed. You need a different process node to have transistors that are designed to work at that speed. And with that, your entire digital design is different.

Sorry, I'm not familiar with modern chip design. I see it something like design for FPGA, when you design or buying some verilog IP and combine it, like you can do using FPGA, but with converting verilog to the mask layout instead of generate gateware for programmable gates. Is that correct?

On FPGA you can generate several different clock sources and clock two circuits from different clocks. When you needs to communicate between these circuits you can implement clock domain crossing synchronizer. So there is no issue to run more complicated logic at lower clock and some simple logic at higher clock together on the same FPGA. Is that approach possible for a usual chip mask layout design?


For example STM32 use different clock for core and peripherals. I worked with FPGA and don't see something strange here. But if this is impossible for a usual chip with mask layout design then how they doing it on STM32?

[iMo]

That could be useful for I/Q based DSP (today's standard) when you are going to process data from an external simultaneously sampling ADCs and the results are fed into an external something (like DAC or codec or similar in case of an SDRadio).

Yes! This is wonderful feature, but the problem here is that there is no fast enough communication between core and external world.

What is the reason to do some DSP operation at 1 cycle if core will needs to waste next 800 cycles just to wait for the next data word?

Again, you may use that 64bits for processing of something coming from outside's world (as I wrote above you need double precision when doing math with 20-32bit data, therefore 64bit FP is something I would expect in any modern mcu) and where you represent the result as a single number, or a set of numbers, or a graph (like nanovna) or a lower frequency signal (music, speech, simple picture like a waterfall in any SDR radio)
You might not need 64bit FPU inside the mcu for a DSP where you want process all that data at the host (ie a 16core 6GHz Intel) streaming via USB2.0/3.0 or via couple of PCIe lines..

[rteodor]

At its official/guaranteed 150 MHz, you can't process lots of data, that quickly, so would be better off, with a proper high speed MCU, appropriately fast USB interfaces (2 or 3), along with the (usually) considerable increase in cost of the device.

I didn't worked with RP series MCU, but I read in their advertisement that it has single cycle 32-bit MAC and two cycle float64 operations. After all it can write at least 32-bits per cycle. At 150 MHz it can produce up to 4800 MBps with simple bit-banging... And even can do something more complicated and useful, like applying filter to the realtime stream on the fly.

And since it has 2 core, it can produce up to 9.6 GBps stream with dumb write in a loop. This is 800 times higher than USB HS 480 MBps bandwidth.

With 300 MHz overclock it can produce up to 19.2 GBps, but USB bottleneck is just 0.012 GBps... which is 1600 times slower than MCU can produce...

With no high speed communication interface all that speed is almost useless...
What is the reason for two cycle float64 operation or single cycle MAC if there is no way to get the data at higher than 12 Mbps?
And no way to transfer processed data out of the chip at speed higher than 12 MBps...

AHB bandwidth in RP2040 is 2GB/s at 125MHz (4 transfers of 32 bit per clock cycle). Mentioned in RP2040 Datasheet chapter 2.1.
I do not expect RP235x AHB transfer width to be bigger.

On a brief search I found that "RP2350 is manufactured on a modern 40nm process node". I think that's on the edge of what USB HS needs: multi GHz PLL and fast line transistors. IMHO power consumption would be the issue in this case (and with that problematic converter everyone is talking about ...).

[radiolistener]

Again, you may use that 64bits for processing of something coming from outside's world

The question is what is the reason to use single cycle accelerators if you cannot get any performance improvement? Just because the speed at which the data coming from outside world to MCU through USB FS is so slow that MCU will waste 800 times more time for waiting one data sample from USB, than to process this one data sample with single cycle accelerator...

You can do the same processing without accelerators and it still will be faster than waiting data from USB FS. Because the main bottleneck here is not processing, but USB speed...

[iMo]

Why do you need an USB?
You might have two external 16bit 10Msamples/sec simultaneously sampling ADCs (an example only) wired to the Pico's GPIO pins (or perhaps via its SPI), process the incoming data via Pico's FPU (double precision) and you may show a result in a form of an animated graph on a 320x200 TFT LCD display wired to the Pico's pins..
PS: all latest ham SDR radios (incl the cheapo ones) do it that way, incl. all nanovna-like boxes.. No need for high speed USB as you transfer only pretty low speed (low bit rates) results, like pictures (ie 320x200 2-3x per sec) or sound (mono 3kHz BW) or data (perhaps 9k6 with data/packet modems)..

[tszaboo]

Sorry, I'm not familiar with modern chip design. I see it something like design for FPGA, when you design or buying some verilog IP and combine it, like you can do using FPGA, but with converting verilog to the mask layout instead of generate gateware for programmable gates. Is that correct?

On FPGA you can generate several different clock sources and clock two circuits from different clocks. When you needs to communicate between these circuits you can implement clock domain crossing synchronizer. So there is no issue to run more complicated logic at lower clock and some simple logic at higher clock together on the same FPGA. Is that approach possible for a usual chip mask layout design?


For example STM32 use different clock for core and peripherals. I worked with FPGA and don't see something strange here. But if this is impossible for a usual chip with mask layout design then how they doing it on STM32?

Me neither, so I try to make this simple, and more knowledgeable forum members are going to extend on it or correct me.
You select a process node for your design, for example 40nm LP = Low power. That will have a library of components, like output transistors, gates and whatnot, that you can use for your digital design. This constrains you to the type of transistors that you can use, and everything must come from the library. Now, RP foundation doesn't design everything themselves. They are going to buy Cortex M33 from ARM, maybe do the PIO themselves, and use a lot of other standard building blocks.
If you change the process node, your basic transistor will be different in size, shape, leakage, power... Once you need just one transistor to run at 480MHz instead of 150 MHz, that means your entire design changes. Because all the parts need to come from that library. And you need to talk to every IP supplier to get them to supply their IP with that process node. It's not a drop-in replacement. Imagine, that you have a PCB design with SOT563 BC817 transistors, and suddenly you need to use SOT23 transistors. Your entire PCB design changes. Plus, I bet you that USB HS is a large chunk of silicon compared to a CM33, and you need to design everything around that.
In an FPGA everything is designed to run at high speed (oversimplification) and you make it slower.

[langwadt]

Again, you may use that 64bits for processing of something coming from outside's world

The question is what is the reason to use single cycle accelerators if you cannot get any performance improvement? Just because the speed at which the data coming from outside world to MCU through USB FS is so slow that MCU will waste 800 times more time for waiting one data sample from USB, than to process this one data sample with single cycle accelerator...

You can do the same processing without accelerators and it still will be faster than waiting data from USB FS. Because the main bottleneck here is not processing, but USB speed...

that clearly and obviously depend on what processing you are doing ....

[dave j]

That's a plus, but you cannot poll a IRQ, you can only stall as you wait.

You can with the RP235x. The configuration of the MOV x, STATUS instruction has been extended to include checking the state of IRQs. (See the documentation for the SMx_EXECCTRL registers, table 993, in the datasheet.)

[radiolistener]

On a brief search I found that "RP2350 is manufactured on a modern 40nm process node". I think that's on the edge of what USB HS needs: multi GHz PLL and fast line transistors. IMHO power consumption would be the issue in this case (and with that problematic converter everyone is talking about ...).

On a brief search I found that CY7C68013A is manufactured on C8 Technology process, there is no details, but I found that L8C-3R technology (which is Derivative of the C8 Technology) uses CMOS, 0.13 μm process and it's transistors supports USB HS with no issue and it don't have power consumption issue, why?

I thought that more smaller process should allow to run at higher frequency and has less power consumption.
Why 130nm process allows to run at 480 MHz and 40nm don't allow?