but I read in their advertisement that it has single cycle 32-bit MAC and two cycle float64 operations.
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?
With no high speed communication interface all that speed is almost useless...
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?
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.
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.)
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.
Hmm. The Integrated flash will preclude using a larger external flash, right?
Hmm. The Integrated flash will preclude using a larger external flash, right?
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 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?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.
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.
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.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
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.
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
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:
https://www.researchgate.net/figure/HRTIM-time-resolutions-and-frequency-limits-versus_tbl1_362293274
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.
This would imply they had major issues with E-field coupling to internals.
.. they got a lot of issues..
.. 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).
Download a printable PDF version
Schematic (coming soon)
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..