-
Quote
but I read in their advertisement that it has single cycle 32-bit MAC and two cycle float64 operations.
I don’t think it has two-cycle float operations. It has a “double precision accelerator” coprocessor, and while it’s instructions might take two cycles, I think there is quite a gap between its instructions, and what most of us consider an actual dp operation.
And the point is to be able to do more complex operations on the data streams it CAN handle. For example, there were several people trying to optimize a 32x32->64 integer multiply for mp3 decode on CM0 chips. I’ll bet that they are pretty happy right now!
“I’m just disappointed that it doesn’t have an 8k gpu, cryptocoin mining accelerators, or AI!” :-)
-
I thought that more smaller process should allow to run at higher frequency and has less power consumption.
A 130nm speed optimised process has no problem running at 480MHz, especially for fairly simple comms logic. We had 1GHz x86 processors in 180nm, and well above 1GHz in 130nm. It all about the speed power trade off. If you use a low power variant of a particular node it can really hit your maximum clock rate. MCUs usually use low power processes, because so much of the MCU market, while not exactly ULP, wants modest power consumption, and low standby leakage.
Why 130nm process allows to run at 480 MHz and 40nm don't allow?
-
With no high speed communication interface all that speed is almost useless...
For *your* application. Which is a hint that maybe it's not targeted at the things you want it to do.
And if you want to shoe-horn the chip into your problem, I still don't see any issue with adding on the FT232H in FT1248 mode. It'll give you an actual throughput peak of 240Mbit/sec and it's basically an OctoSPI interface with buffers to help speed up the data transfer, which ought to be really easy to do, even if you *don't* use the PIO.
-
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?
I did not say 40nm does not allow USB HS. Implementations of USB HS exists for more than 20 years. It is just that inclusion of USB in general in MCU's was slow. And for HS even more slow. I was guessing this was due to power consumption but there might be more reasons like licensing from USB-IF and low customer demand.
A few examples:
About 15 years ago I used an ancient NXP ISP1581 transceiver to do about 14MB/s transfer. This one had high power consumption (about 0.5W from what I can remember). I did not find on what node it was, I'm guessing either 180 or 130nm as the datasheet is from 2002.
STM32F4xx is on 90nm but needs external ULPI for USB HS.
Arduino Due has SAM3X8E with USB HS. I'm guessing 90nm also.
Yes, its frustrating to have that fast PIO and be limited by USB FS. Pico is probably alone in this situation where its PIO would benefit from a HS interface in some applications. But its only in some applications.
LE: and speaking of Arduino Due, here is the Dynamic Power Consumption for USB HS Port:
Values would be undoubtedly better for 40nm Pico but still significant.
-
IMXRT is build on 40nm, and it has HS USB. Entry level MIMXRT1011DAE5A (80 LQFP) with high speed GPIO (M7 domain) at mouser is 3.5€ (quantity 10). There are FlexIO, less powerful than PIO, and "only" one core (M7@500MHz). My second choice after new pico.
-
IMXRT is build on 40nm, and it has HS USB. Entry level MIMXRT1011DAE5A (80 LQFP) with high speed GPIO (M7 domain) at mouser is 3.5€ (quantity 10). There are FlexIO, less powerful than PIO, and "only" one core (M7@500MHz). My second choice after new pico.
I've used the larger i.MXRT chips a couple of times. I think the learning curve for the development environment is a lot steeper than the pico - basically Eclipse + a load of custom wrinkles vs VSCode's simpler "build, run, debug". I also found the UI to be awfully, terribly, glaciers-are-created-and-destroyed *slow* when you have a lot of pins configured on that screen... Maybe it's not so terrible with the smaller parts.
Also, the description of how FlexIO works hurts my brain. I find it much easier to grok the assembly of a PIO than I do to understand the shifters and bit-manipulation of FlexIO. I'm sure it is very powerful, but it doesn't ingratiate itself for *me*. Others mileage may vary...
I didn't know the smaller ones were that cheap though, so maybe I ought to keep an open mind
-
Thanks for that detail.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.)
I should have said you cannot poll IRQ as quickly or efficiently as you can poll a pin, using JMP.
It's shame those SMx_ series registers failed to allow for flip of PIN polarity, (none I can see?) as that would avoid the need to use TWO GPIO pins for alternating PIO sampling.
-
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.
The RP2350B appears to be at an A2 stepping level (from the photos I've seen). I will be getting a couple Pimoroni RP2350B carrier boards on Weds so will know for sure by then. At 9 GBP each with about 10 GBP DHL shipping, it was a no brainer to buy. -
I think I like it so far. I'll be waiting for the version with integrated flash.
-
Hmm. The Integrated flash will preclude using a larger external flash, right?
-
Hmm. The Integrated flash will preclude using a larger external flash, right?
Not necessarily, Someone mentioned multiple CS pins for flash and PSRAM. -
Hmm. The Integrated flash will preclude using a larger external flash, right?
You can have up to two QSPI devices, in any external / "internal" combination, of any type (RAM, Flash), each can be 16MB in size
I say "internal" because the one that comes with 2MB of flash is just a package-on-package that bonds to the 6 QSPI pins. You can configure one of the GPIOs as the /CS for the second QSPI, if you have it. -
The RP2350B appears to be at an A2 stepping level (from the photos I've seen). I will be getting a couple Pimoroni RP2350B carrier boards on Weds so will know for sure by then. At 9 GBP each with about 10 GBP DHL shipping, it was a no brainer to buy.
For the possible SMPS issues, I'd be much more worried, with the bare MCU chips, which are not for sale yet. Because getting the PCB design right, ideally first time, would be rather tricky, given the possible hiccups, with the SMPS (inductor) component orientation, and maybe other things, like the layout, and specific capacitors, used.
Then, testing the SMPS, under differing conditions, would also be worrying and more important, than if it was not under suspicion of being difficult to deal with.
But, the complete development boards. Given they may well have got direct advice from the Raspberry PI foundation, be using the correct part number(s), which don't seem to have been publicly released yet, as regards the specific/'special' inductor, with orientation dot.
Also the testing when those development boards were developed, should improve things.
So, there is a good chance, those early development boards, should be fine.
It is going to take time, for the various websites with PICO RP2040 hardware and software information, to get updates with the PICO 2 stuff.
Also, time for updated IDE's (depending on what flavor of IDE you like, such as Arduino Studio).
So, (for me), waiting, probably improves the situation, anyway. -
I thought that more smaller process should allow to run at higher frequency and has less power consumption.
A 130nm speed optimised process has no problem running at 480MHz, especially for fairly simple comms logic. We had 1GHz x86 processors in 180nm, and well above 1GHz in 130nm. It all about the speed power trade off. If you use a low power variant of a particular node it can really hit your maximum clock rate. MCUs usually use low power processes, because so much of the MCU market, while not exactly ULP, wants modest power consumption, and low standby leakage.
Why 130nm process allows to run at 480 MHz and 40nm don't allow?
... and the RP2040 was already widely criticised for not having what people considered to be a sufficiently low power sleep mode. -
Speaking of process nodes, the STM32F334 (72Mhz main clock) HRTIM are feed from a clock multiplier by cascading delay cells (DLL, Delay Locked Loop), i think it was and some pulse shaping
You are not listening, do you?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.
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.
stuff to get the 4,6Ghz clock feeding the HRTIM, how is this done if the wafer are made on the same process node? 90nm would do up to 3,2Ghz, consuming lots of power of course.
-
I don't think anything is actually running at that frequency in that block. You can enable a delay on the signal, giving you the appearance of higher frequency timer. Here they talk about "equivalent frequency:
Speaking of process nodes, the STM32F334 (72Mhz main clock) HRTIM are feed from a clock multiplier by cascading delay cells (DLL, Delay Locked Loop), i think it was and some pulse shaping
You are not listening, do you?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.
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.
stuff to get the 4,6Ghz clock feeding the HRTIM, how is this done if the wafer are made on the same process node? 90nm would do up to 3,2Ghz, consuming lots of power of course.
https://www.researchgate.net/figure/HRTIM-time-resolutions-and-frequency-limits-versus_tbl1_362293274 -
One of the reasons people are moving to those self-calibrating delay lines for fine PWM is to avoid having fast high consumption clocking. The die area for all those delay stages is small these days, so its no big deal to throw gates at the problem. The trick is to be able to calibrate them.Speaking of process nodes, the STM32F334 (72Mhz main clock) HRTIM are feed from a clock multiplier by cascading delay cells (DLL, Delay Locked Loop), i think it was and some pulse shaping
I don't think anything is actually running at that frequency in that block. You can enable a delay on the signal, giving you the appearance of higher frequency timer. Here they talk about "equivalent frequency:
stuff to get the 4,6Ghz clock feeding the HRTIM, how is this done if the wafer are made on the same process node? 90nm would do up to 3,2Ghz, consuming lots of power of course.
https://www.researchgate.net/figure/HRTIM-time-resolutions-and-frequency-limits-versus_tbl1_362293274
-
BTW, about smps issues... I'm no expert, is the only problem orientation? Anyway, I hope there will be suitable inductors from multiple sources.
Here is another thing. If you guys look closely on these PCBs with rp2350 here, you'll see they use different inductors and different layouts: https://www.raspberrypi.com/for-industry/powered-by/product-catalogue/?category=RP2350 . I'm not sure what that means.
PS I really hoped that the new mcu would require less external components. I didn't like that rp2040 requires external flash. Now instead of external flash we have external inductor
-
It does get a little tight with them bunching all the non-GPIO things together. It might have been easier if they were more spread out. I'm laying out using their recommended crystal, capacitor sizes, and the same-size inductor (until the real part comes along) and it gets a bit squashed-in by the SMPS parts, next to the USB, next to the flash (and I want to put some QSPI PSRAM in there on a different build, so I'll need to use it), all in amongst the decoupling caps.
-
One of the concerns I have about the design is the 1.1V switcher's inductor. As others have noted in the "Hardware design with RP250" document they go on and on about the proper orientation of the inductor and how they worked with Abracom to get a special part distributed. They go so far as to say they can't guarantee any design that does not use the specific Abracom part which is listed as TBA. Kind of hard to order without the actual number.
Is this them just being unconfident? I see a number of designs for sale that use the RP2350 part so if these are actually being manufactured, why can't they get us the Abracom inductor part number? Or, I'm guessing, the orientation isn't that critical? Hopefully they will get the design doc updated soon.
Looking at the KiCad project files provided on the raspberry pi website, it seems like the inductor uses the AOTA-B201610SR47MT 3D model. Although in the schematic a 3.3 uH is used.
-
Inductor orientation occasionally matters for EMC: there is a self-shielding effect that exists if the switch node is connected to the inside windings in a multi-later windup. This would imply they had major issues with E-field coupling to internals. It would be pretty crazy if there was a functional issue, though I hope it's more of a ADC ENOB thing or something more benign.
-
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.
-
.. they got a lot of issues..
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?
The reason I ask, is that the Pimoroni Pico 2 Plus board doesn't seem to have the same inductor, nor the same orientation, and "operates" (in that it successfully powers up - I have not measured anything nor tried to run a heavy processing load to try to exercise that core voltage regulator).
-
.. they got a lot of issues..
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?
The reason I ask, is that the Pimoroni Pico 2 Plus board doesn't seem to have the same inductor, nor the same orientation, and "operates" (in that it successfully powers up - I have not measured anything nor tried to run a heavy processing load to try to exercise that core voltage regulator).
I get the impression (since the claimed 600 mA, sounds too much, for the on-chip version), it has its own (external) regulator (I'm not sure if it's linear or switching), or if it takes over 100%, or shares its duties with the on-chip version.
The 'Pimoroni Pico Plus 2' still says on its product page:QuoteDownload a printable PDF version
Schematic (coming soon)
So, I don't seem to easily be able to find out more, at the moment, as to exactly what they have done.
But, Pimoroni, seem to have a good reputation (I've bought stuff from them in the past, and been pleased with the results, but it was not stuff they designed, themselves).
In fact, they seem to be one of the main, or even the biggest, supplier and maker of Raspberry PI, (add-on) hardware, across their range.
Many of the other PI suppliers, actually sell Pimoroni branded hardware.
There is a very good chance, your board is fine.
It is just so early in the release cycle, it is hard to get definitive information, yet. -
This would imply they had major issues with E-field coupling to internals.
..
I think this is a big mistake to share MCU die with switching converter..
On pico2 original they use the "RT6150 buck-boost SMPS, which generates a fixed 3.3V output
for the RP2350 device and its IO" (see the schematics in the DS).
It allows the powering the pico2 from 1.8-5.5V..
By cutting off the RT6150 chip with the inductor etc. and replacing it with an LDO linear regulator you solve the problem, imho (like all other boards do, afaik)..
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..