That's cool! I hope we can get to see how the P2 work and probably get a cool development board to play with before Christmas!
By the way, we would have some competition from the other vendors, like FTDI. The FTDI EVE is one of them, and apparently, the chip is very reminiscent to the Nintendo Entertainment System's PPU (Picture Processing Unit), but with more colours and an audio module inside.
I read in the earlier posts that the P2 can handle sprites, but not in the "macro" sense of way. You have to do it pixel-by-pixel. In the NES' PPU, they have "nametables" which you can directly manipulate the palette and a memory space to temporarily stow your bits of 8x8 bitmaps into the SRAM. Plus, you can determine how you arrange the sprites into tiles in a matrix form, and you can even extend the "playing field" or background into two/four areas. The chips are old, but the method is very clever for memory constrained systems. You got to see how those el-cheapo 8-bit game consoles (which disguised as Ben10 999-in-one or whatever) still use that kind of technology, and hasn't been changed since 20 years ago. Believe me, I tried playing with these rubbish, hooking them to the microcontroller, and yeah, using a PIC/AVR to communicate with these things.
Since P2 is already in production and testing, I guess it would be more fun to write the PPU emulation into the system. Anything goes for the P2.
Let's see, David has to solder 4 BRAND NEW, NEVER BEFORE SEEN, FIRST LIVE P2 CHIPS IN THE WORLD for Chip and Ken plus a waiting throng of fans. How careful would *YOU* want to be with that soldering???
Then apply power.....how careful would *YOU* want to be to not let out any magic P2 smoke?
It's been a long time coming, a few more hours won't kill anybody!
Reminds me of the waiting room outside the delivery room.
Anticipation and hope...
Exactly.
I talked to Dave about a half hour ago. He checked the impedance among the VDD pins and then the GND pins, and they all looked okay. The resistance between VDD and GND measured ~31k ohms, which is to be expected, as there are millions of core 1.8V transistors which all leak a little. The 3.3V power/ground pins show about 300k ohms of resistance, which is appropriate.
Right now, he's soldering the VDD's together and the GND's together, and then he'll power them up to 1.8V with a current-limit of 50mA. If that goes okay, he'll power up VP11 and GP11 to 3.3V w/50mA current limit. Then we can check for signs of life.
Given some of the early current projections, I would have guessed it would be something less than 5K.
Maybe premature, but we could do a typical current consumption pool with the following parameters:
1.8VDC core +/- 7%
3.3VDC VDDIO (VPP) on all IOs
160MHz system clock (or whatever is selected as standard)
Single COG running a repeat statement (no other code)
There were 45 users logged in this morning, so a 7x7 matrix should work.
25ma increment per square (25ma to 1225mA left to right, top to bottom).
The first device Dave wired up had too-high current consumption. It was drawing 85mA on VDD, or 41mA when reset was held low. That's odd.
He's wiring up another chip and will call me again soon. We should expect maybe 1 in 4 devices to be bad. If we see the same current draw on another chip, there's quite certainly a design problem. This high current consumption is occurring in the core, which is a black box to us.
Something is running to some degree - it is using >2x the current when out of reset.
The 41mA consumption when in reset makes me wonder if it is something in all those nice smart pins that is drawing current - after all, when in reset, the cogs should not be drawing much current at all...
Could it be that the pull-up resistors are coming up active by default?
The first device Dave wired up had too-high current consumption. It was drawing 85mA on VDD, or 41mA when reset was held low. That's odd.
He's wiring up another chip and will call me again soon. We should expect maybe 1 in 4 devices to be bad. If we see the same current draw on another chip, there's quite certainly a design problem. This high current consumption is occurring in the core, which is a black box to us.
You are not the only one. I've been on the edge of my seat all day, refreshing every 5 minutes for the latest. (I bet parallax is dealing with the most traffic they've seen in a while!)
Chip, we've all got our fingers crossed for ya! I'm sure the suspense is just as bad for you as it is for us (if not worse!)
We should expect maybe 1 in 4 devices to be bad. If we see the same current draw on another chip, there's quite certainly a design problem.
Well, 93% isn't quite certainty although it would look bleak. I once watched a Roulette player lose 12 bets in a row. It would have been impressive enough a run of bad luck if he hadn't been Martingaling, doubling his bet on each loss. He started at 25 cents and hit the $1,000 table limit and made one more bet that wouldn't have covered his losses, but he lost it too. Then on the first roll where he didn't have action, his color came in.
If we expect 25% failure I'll be more concerned when all four chips do the same thing they're not supposed to do. Randomness can be perverse.
Dave wired up a second chip and it had similar current consumption patterns.
Now, he's going to power up all the VPx and GPx pins to 3.3V to see if the core's quiescent current goes down.
I'm thinking maybe there's an issue in having the I/O's not powered while the core is. The 3.3V-to-1.8V level converters may be drawing extra current on the 1.8V side because the 3.3V side is at 0V. When the 1.8V inverter loop snaps one way or another, it's pulling up on one of the 3.3V NMOS' drains, and raising that NMOS' gate voltage through parasitic capacitance, so that the 1.8V core supply may be dumping current through the 3.3V NMOS device to ground. Here is a picture of the level shifter in question. The single-line elements are 1.8V (core) and the double-line elements are 3.3V (I/O). There are hundreds of these in the I/O pin circuits:
Something is running to some degree - it is using >2x the current when out of reset.
The 41mA consumption when in reset makes me wonder if it is something in all those nice smart pins that is drawing current - after all, when in reset, the cogs should not be drawing much current at all...
Good point about something running Bill, I missed that. But the smart pins are on the 3v3 rail and it's the 1v8 rail that's overdrawing. That's the cogs.
On edit: Passed Chip on post. Fingers crossed that he's right about it just being 3v3 needed to tamp this down.
Good luck, but if all else fails www.eaglabs.com in Santa Clara helped us diagnose some high current conditions with just an IR sensitive camera looking through the backside of a die. All of the metal on top made it hard to see what was going on when we looked at the topside. Maybe there's some place closer, or you can DIY it.
When you get to my age, there isn't much to look forward to... the P2 is quite an exception.
I hope it works... but if it doesn't, the process is still a gift. And we all know that it is a matter of time.
I loved Ken's post of the shipping details:)
The Flash SPI_CS (P89) signal looks correct, which can only mean that it's running the booter program. We are not seeing the Flash SPI_CK (P88) toggling like it's supposed to, though, which doesn't make any sense. Those two phenomena should be inseparable.
Comments
By the way, we would have some competition from the other vendors, like FTDI. The FTDI EVE is one of them, and apparently, the chip is very reminiscent to the Nintendo Entertainment System's PPU (Picture Processing Unit), but with more colours and an audio module inside.
I read in the earlier posts that the P2 can handle sprites, but not in the "macro" sense of way. You have to do it pixel-by-pixel. In the NES' PPU, they have "nametables" which you can directly manipulate the palette and a memory space to temporarily stow your bits of 8x8 bitmaps into the SRAM. Plus, you can determine how you arrange the sprites into tiles in a matrix form, and you can even extend the "playing field" or background into two/four areas. The chips are old, but the method is very clever for memory constrained systems. You got to see how those el-cheapo 8-bit game consoles (which disguised as Ben10 999-in-one or whatever) still use that kind of technology, and hasn't been changed since 20 years ago. Believe me, I tried playing with these rubbish, hooking them to the microcontroller, and yeah, using a PIC/AVR to communicate with these things.
Since P2 is already in production and testing, I guess it would be more fun to write the PPU emulation into the system. Anything goes for the P2.
===Jac
It is! why aren't they reporting results yet???
Let's see, David has to solder 4 BRAND NEW, NEVER BEFORE SEEN, FIRST LIVE P2 CHIPS IN THE WORLD for Chip and Ken plus a waiting throng of fans. How careful would *YOU* want to be with that soldering???
Then apply power.....how careful would *YOU* want to be to not let out any magic P2 smoke?
It's been a long time coming, a few more hours won't kill anybody!
I suppose they are joking... aren't they? Anyway, the only thing I may be interested to know by the end of the day is if the monitor worked
Anticipation and hope.
Best wishes to all.
Exactly.
I talked to Dave about a half hour ago. He checked the impedance among the VDD pins and then the GND pins, and they all looked okay. The resistance between VDD and GND measured ~31k ohms, which is to be expected, as there are millions of core 1.8V transistors which all leak a little. The 3.3V power/ground pins show about 300k ohms of resistance, which is appropriate.
Right now, he's soldering the VDD's together and the GND's together, and then he'll power them up to 1.8V with a current-limit of 50mA. If that goes okay, he'll power up VP11 and GP11 to 3.3V w/50mA current limit. Then we can check for signs of life.
Refresh, Refresh, Refresh, Refresh...
Or even an unboxing video...
I'm busting here.
31K Ohms VCC to VSS on the main rail is not bad.
Given some of the early current projections, I would have guessed it would be something less than 5K.
Maybe premature, but we could do a typical current consumption pool with the following parameters:
1.8VDC core +/- 7%
3.3VDC VDDIO (VPP) on all IOs
160MHz system clock (or whatever is selected as standard)
Single COG running a repeat statement (no other code)
There were 45 users logged in this morning, so a 7x7 matrix should work.
25ma increment per square (25ma to 1225mA left to right, top to bottom).
Are you kidding? Right now, I think the YouTube request is quite constrained! Tell me you don't want to be right there, watching over Dave's shoulder!
He's wiring up another chip and will call me again soon. We should expect maybe 1 in 4 devices to be bad. If we see the same current draw on another chip, there's quite certainly a design problem. This high current consumption is occurring in the core, which is a black box to us.
Stay tuned.
Is that clocked, or static ? Plotting Idd/Vdd could give some clues.
Chip said these first tests would be static, with reset asserted.
Something is running to some degree - it is using >2x the current when out of reset.
The 41mA consumption when in reset makes me wonder if it is something in all those nice smart pins that is drawing current - after all, when in reset, the cogs should not be drawing much current at all...
Could it be that the pull-up resistors are coming up active by default?
I also know that me being there is not going to help.
I don't have fingernails left...
You are not the only one. I've been on the edge of my seat all day, refreshing every 5 minutes for the latest. (I bet parallax is dealing with the most traffic they've seen in a while!)
Chip, we've all got our fingers crossed for ya! I'm sure the suspense is just as bad for you as it is for us (if not worse!)
Well, 93% isn't quite certainty although it would look bleak. I once watched a Roulette player lose 12 bets in a row. It would have been impressive enough a run of bad luck if he hadn't been Martingaling, doubling his bet on each loss. He started at 25 cents and hit the $1,000 table limit and made one more bet that wouldn't have covered his losses, but he lost it too. Then on the first roll where he didn't have action, his color came in.
If we expect 25% failure I'll be more concerned when all four chips do the same thing they're not supposed to do. Randomness can be perverse.
Now, he's going to power up all the VPx and GPx pins to 3.3V to see if the core's quiescent current goes down.
I'm thinking maybe there's an issue in having the I/O's not powered while the core is. The 3.3V-to-1.8V level converters may be drawing extra current on the 1.8V side because the 3.3V side is at 0V. When the 1.8V inverter loop snaps one way or another, it's pulling up on one of the 3.3V NMOS' drains, and raising that NMOS' gate voltage through parasitic capacitance, so that the 1.8V core supply may be dumping current through the 3.3V NMOS device to ground. Here is a picture of the level shifter in question. The single-line elements are 1.8V (core) and the double-line elements are 3.3V (I/O). There are hundreds of these in the I/O pin circuits:
Good point about something running Bill, I missed that. But the smart pins are on the 3v3 rail and it's the 1v8 rail that's overdrawing. That's the cogs.
On edit: Passed Chip on post. Fingers crossed that he's right about it just being 3v3 needed to tamp this down.
You could also power the IOs at 1.8V, which should be ok in Digital modes ? - and that removes any 3.3-1.8V cross impedance effects.
I hope it works... but if it doesn't, the process is still a gift. And we all know that it is a matter of time.
I loved Ken's post of the shipping details:)
Thanks
The Flash SPI_CS (P89) signal looks correct, which can only mean that it's running the booter program. We are not seeing the Flash SPI_CK (P88) toggling like it's supposed to, though, which doesn't make any sense. Those two phenomena should be inseparable.