Chip, please continue on with the P2. Many of us are looking forward to using it in the future. I'm sure it will be used in many projects and products. I believe it will be a big success. I thank you for your persistence on the P2, and I look forward to using it soon.
Yes, it would be a shame to come this far and not produce a real chip. Is there really a big risk that the chip will have some fatal bug? How could the design be tested better before synthesis to make that less likely?
A P2 without the proposed analog features is like a country with a digital president. I'm absolutely sure, when 50k$ are needed as a supplement we will find this money from those, that need a P2!
Have you looked into MOSIS? You will still need to pay the synthesis costs as that is cheaper than buying the very expensive tools. You'll get 40 or more die, and that will satisfy the forum. And if some volume customer tries it and likes it you can go from there. It would also open up P3 and beyond at more competitive IC fab technology. At 180 nm I see no commercial use for the P2, it might have been competitive 10 years ago,
2 words about where the P2 as described, will fit in my world:
Ham Radio.
Some see a dying hobby, I see it changing, becoming more digital. Lots of new electronics hobbyists play with Ham Radio. In truth, even though many won't admit it, there are more HAMS now than ever before.
Display capabilities, Goertzel on every smart pin, Lots of potential throughput in the CORDIC suite of functions... WOW! Two chip CW skimmer anyone?
Sure, you have high jitter at certain frequencies.. There are things like the SI570 clock that can be changed on the fly for a more favorable Fin>Fout. Widely used already.
Solve the jitter with a programmable oscillator, or just plan for one frequency (I.F. anyone remember that?) Then it's CORDIC to the rescue again! Very easy to experiment with QAM, AM, SSB, FM, FSK and anything else you can dream up, with only changes to the program..
Upon release, I predict it will be one of the hottest (Figuratively...) chips in the Ham Radio arsenal!
YES, absolutely. In my little niche, internal combustion engine control, accuracy, predictability and very low latency are extremely important.
Most designers satisfy that with a cheap off the shelf micro and a small FPGA. The FPGA gives you much higher resolution than the proposed 80 MHz P2.
So, how long does it take to get an ARM chip and an FPGA onto a circuit board, then program each one so that they work together? What if that same system could be built with one easy-to-wire chip (plus an 8-pin flash) that provided an integrated approach to all the problems? One programming tool, instead of at least two. One design methodology, instead of two. Configuration turn-around in 1 second without plugging/unplugging, as opposed to 3 to 5 minutes with a few cable connects/disconnects.
So, how long does it take to get an ARM chip and an FPGA onto a circuit board?
Not very long, good high level language support on the ARM. You can program the FPGA in RTL, which building PMW, or timers or other simple pin controls are fairly straight forward. Tools are free for many parts. Yes a little learning curve, but a lot less than learning an assembly language. As for programming time, those are fairly fast and no need to reconfigure cables or the like. I've been doing this kind of thing for more than 20 years, and have done a wide range of things from video to networking to motion control.
You would also have to build the PCB in either system as there will be actuators or other things not in the "logic" system. And if you are talking high speed, fly wires and plug boards don't cut it.
Is there really any chance that Parallax will decide not to build the P2? If so, what happens to all of the education material based on the P1? Do you migrate it over to ARM?
Is there really any chance that Parallax will decide not to build the P2? If so, what happens to all of the education material based on the P1? Do you migrate it over to ARM?
We are in the process of getting the P2 done. To abort, at this point, would be a huge change of course. We are heading towards completion. We are on the cusp of spending a lot of money to finish it.
I don't know what we would do for our educational products, as chips go, if there was no new Propeller chip. As it is, the innards are increasingly shielded by things like Blockly and C, so it wouldn't matter what was inside.
Is there really any chance that Parallax will decide not to build the P2? If so, what happens to all of the education material based on the P1? Do you migrate it over to ARM?
We are in the process of getting the P2 done. To abort, at this point, would be a huge change of course. We are heading towards completion. We are on the cusp of spending a lot of money to finish it.
I don't know what we would do for our educational products, as chips go, if there was no new Propeller chip. As it is, the innards are increasingly shielded by things like Blockly and C, so it wouldn't matter what was inside.
It won't matter what is inside unless some of the Blockly blocks take advantage of the exact timing and multi-processor nature of the Propeller. I think some already do and that would certainly be a way to distinguish the Parallax products from other ARM-based educational products. Of course, the real distinguishing feature is the excellent Parallax educational material. Unfortunately, I'm not sure people are willing to pay for just that without bundling it with a hardware component like the ActivityBoard. I guess an ActivityBoard-ARM might be an option...
Listen, we need to have faith in this design. It's a great design. Frankly, the analog capabilities are insane great, and that will drive sales and uses of this chip. As for games, and other expectations, forget them. People will do things a bit differently on this chip, and when they do, it will be robust and attractive to others. The vast majority of P1 users use library code and it's easy, robust, gets things done. A minority of P1 users push it, and they often contribute more library code.
(besides, for games? This thing is a freaking playground! Trust me, no worries on that.)
P2 will play out exactly the same way. And as it does, that simple nature will be there. The difference is more depth. Don't let that depth get in the way of the vision and or set expectations that run counter to what this whole thing has been about. Please.
My suggestions are:
Get the test analog chip, validate it, pay the $50k and do what it takes to begin synthesis with the highest chance of success.
That $50k is our feature lock. The world is telling us to quit messing with it. Great! What we've got is pretty awesome, and very highly differentiated from everything else out there. Know what that means? It makes no sense to begin to compare and meet expectations set by everything else out there. Right? This is by design, deliberate, and that die is cast.
From there?
Chip, you should complete a lean, SPIN with in-line PASM. Make only the changes needed for SPIN to make sense on the larger memory model. We discussed a lot of advanced stuff. Forget it. That can be a revision / addition to the language over time. Make a baseline SPIN+PASM that can be the basis for library code, framework for PASM drivers, etc... and make this simple, like SPIN is today. One file, the works. Keep this lean, simple, so that library code can be used in other environments, including improved SPIN over time. Let the software community handle this. KISS on SPIN+PASM is super valuable for baseline, library code everyone will need and benefit from.
Throw everything out of SPIN that you can, leaving only the easy, useful nubs. This baseline SPIN+inline PASM is the foundation, library, driver, systems code. The smaller and simpler it is, the more easily it can be programmed in, and that also means it will be easier for others, who will build more advanced things, to take that code and use it and build on it. It also means a simple, useful, self-hosted image will be possible. Great. Nail all the basics with one simple effort. And finally, the smaller and simpler this all is, the easier it is to say it's done. Needs to be done.
It can and will be improved later, but our library code, getting the goodies people need to get started need to be written and written on something that will remain stable. This is the closest, easiest to achieve thing. Very important. This is the single most significant factor in the overall success of P1. Driver code written on day one is usable today. I cannot over emphasize just how valuable and important that really is.
All of us need to test / debug. No new features. Really. It's time. We need to find what's broken, if things are really broken and make what is there robust as all get out. Doing that will matter more than any little optimization will. And I'll be frank, the vast majority of users will not care about that optimization, and or will have done it differently surprising us and making that optimization redundant, or marginalized anyway. Have some faith. It's been a long road.
Every ask costs $50K, so don't do it. Debug and mean it.
Anyone with a testing framework could publish, and others could take it and start exercising things.
From there, the moment we can say feature lock and mean it, and I think that $50K is a nice, effective feature lock, real tool production can begin.
Parallax + interested others discuss both C and Blockly and kick off the minimum projects needed to bring those environments to the P2. There is no need to tie SPIN to any of this. Software filters, translators can be made, and will be made, and that's all going to work out just fine.
Anyone interested can begin to build driver / library code just like we did for P1. That code will be baseline, offering up good capability, but no where near the max capability, just like P1. And there are a bunch of things we can do. Video, sound, serial, USB(?), demos on test, measure, analog capture / sample, analog out, math, graphics, PS2 keyboard (worth it, simple), mouse, SD card, basic filesystem support. All of that can be done in the baseline SPIN, and the moment C gets to a place where it makes sense, make the tools that translate a lot of that over, and since it's in-line PASM, it can largely get sucked right in, useful.
Truth is, we don't even know what that max capability is! Just like P1, software will drive a lot of new stuff, and it will be used by people as it happens. Let that happen, and remember, for it to happen, people need a baseline set of stuff they can get going on right away.
We are here, end of a long road. We have a great design. People want it. And they want it for the highly differentiated design. It scratches itches that the other stuff does not, and that is why we did this in the first place! No backing out now, or it's all for nothing! I'll tell you right now, that does not sit well with me AT ALL.
I know people using P1 for products right now who want the P2 and not a damn thing we've got in the can puts them off.
Have some faith here. It's largely done. A ton of second guessing right now will undo a ton of work. Labors of love. And it will kill plans, that spark we need from people to be successful. Don't do it.
That's why I'm suggesting a MOSIS multi-project die run, as it would be a lot more cost effective than full custom tooling. And in the end you'll have some real prototype parts. At that point you can get some real customer feedback or build some real demos to show it off.
It's much easier to convert to full production, and frankly the analog won't be characterized until it is sharing silicon with some pretty noisy digital.
I'm on task to accomplish what Potatohead is saying, exactly.
I'll have a new FPGA release out today that reflects what is going to get synthesized.
While those images compile, I'm working on the new Spin. KISS, indeed.
That's great news! Somehow I read one of your recent post as suggesting you were not sure if you were going ahead with the P2. I'm glad you've clarified that you are.
That's why I'm suggesting a MOSIS multi-project die run, as it would be a lot more cost effective than full custom tooling. And in the end you'll have some real prototype parts. At that point you can get some real customer feedback or build some real demos to show it off.
It's much easier to convert to full production, and frankly the analog won't be characterized until it is sharing silicon with some pretty noisy digital.
We could opt to use an OnSemi shuttle, at first, instead of paying for full tooling. We may do that.
I'm on task to accomplish what Potatohead is saying, exactly.
I'll have a new FPGA release out today that reflects what is going to get synthesized.
While those images compile, I'm working on the new Spin. KISS, indeed.
That's great news! Somehow I read one of your recent post as suggesting you were not sure if you were going ahead with the P2. I'm glad you've clarified that you are.
Well, if it seemed not worth doing, we wouldn't want to proceed, right? This is a big commitment.
I'm on task to accomplish what Potatohead is saying, exactly.
I'll have a new FPGA release out today that reflects what is going to get synthesized.
While those images compile, I'm working on the new Spin. KISS, indeed.
That's great news! Somehow I read one of your recent post as suggesting you were not sure if you were going ahead with the P2. I'm glad you've clarified that you are.
Well, if it seemed not worth doing, we wouldn't want to proceed, right? This is a big commitment.
The P2 is different enough from what else is out there that it might not be possible to predict success or failure until you actually start trying to sell it. I assume you'll need some largish-volume commercial customers to make it successful and not just the Parallax education department and us hobbyists.
I'll have a new FPGA release out today that reflects what is going to get synthesized.
While those images compile, I'm working on the new Spin. KISS, indeed.
Sounds great.
Will that FPGA release include builds to allow 120MHz, 96MHz, 80MHz testing ?
( seems a >= 480Mhz PLL setting and post-divider of 4,5,6 can cover those in one FPGA build ?)
The USB issues testing may benefit from a choice of MHz speeds.
It is a big commit. And thank you Chip + Parallax for it.
People invested here, and I know that's not the same as hard dollars, but it's still significant. Know it's appreciated and valued.
I personally believe this design will be successful, and it will be successful because it does have some features that are high value, not generally available, or not available with either the price point or accessibility P2 can deliver.
Can't tell you how big that is. Nobody can, but it's at least a very solid basis to justify having a product. And that success will depend on people using the product and sharing what they do and how they do it.
In my above P1x example, I have gone for total backward compatibility. Hardly anything new except hub ram, so minimal risk..
Only you have not actually achieved that "total backward compatibility".
The P1 has many Analog sections, that are not in a Verilog build
* Brownout
* RC Slow
* RC Fast
* Xtal Oscillator
* PLL, both SysCLK and Video
Those all need to be designed and proven. There is a PAD Ring being done for P2 that does that.
Whist your path needs a NEW PAD Ring for P1x...
However, 180nm parts have a 1.8V Vcc, so "total backward compatibility" goes *poof* right there, unless you add another Analog cell
* Internal 1.8V regulator ( decoupling tbf ?? )
Note adding this brings power dissipation issues into the mix & may limit upper MHz ....- and I'm unsure how much Icc can be pin-less (no decoupling)
The $250k++ costs are pretty much there for either pathway.
Next, you 'fall between two stools' over Memory :
i2c keeps part of "backward compatibility" tickbox, but now requires ROM housekeeping - if you desire the "total backward compatibility"
64kB of i2c is nowhere enough for an expanded memory device, but i2c tops out at 128kB/256kB, with SPI Flash being FAR cheaper.
So maybe that points to a dual-boot.... but notice that "total backward compatibility" is quietly slipping away...
All up, I'm not seeing lower development cost (from where P2 is now), or less work, but certainly a far less saleable device.
There is a whole world of low to mid volume products out there, many with healthy margins in them due to their niche / specialized nature, that aren't BOM cost sensitive.
P1 chips are being used now, where the capability is a good match. P2 expands on that very nicely.
In the US at least, these kinds of products are on a growth path too. Specialized, they nail a problem, are worth the money, and time to market, features, robustness are primary drivers that people who buy those products will pay for.
Initial prospects for P2 include:
US, hobby, general interest
Product design on P1, expanding to P2
Education (as it becomes available)
That's not a bad start. It's enough to get word out and build on. More than a lot of people have to go on. There may be a few larger fish in that product design pool too. Ken would know.
I'll have a new FPGA release out today that reflects what is going to get synthesized.
While those images compile, I'm working on the new Spin. KISS, indeed.
Sounds great.
Will that FPGA release include builds to allow 120MHz, 96MHz, 80MHz testing ?
( seems a >= 480Mhz PLL setting and post-divider of 4,5,6 can cover those in one FPGA build ?)
The USB issues testing may benefit from a choice of MHz speeds.
It's just the same as before: 60MHz settable to 120MHz.
If Garryj can tell me which board he has, I can do a special compile for him at 80MHz to replicate how things used to be.
We could opt to use an OnSemi shuttle, at first, instead of paying for full tooling. We may do that.
I'd say that's a very good idea.
Have a read of this link (run via translator) http://www.stcmcudata.com/sample-request/STC8-sample.TXT
This shows the revisions made by an experienced MCU IC vendor, bringing up a new device.
This is far from the first IC they ever did, but the new family errata makes sobering reading.
They are up to Rev D and Rev F, but do seem to be quite quick in doing a new revision.
I'll have a new FPGA release out today that reflects what is going to get synthesized.
While those images compile, I'm working on the new Spin. KISS, indeed.
Sounds great.
Will that FPGA release include builds to allow 120MHz, 96MHz, 80MHz testing ?
( seems a >= 480Mhz PLL setting and post-divider of 4,5,6 can cover those in one FPGA build ?)
The USB issues testing may benefit from a choice of MHz speeds.
It's just the same as before: 60MHz settable to 120MHz.
If Garryj can tell me which board he has, I can do a special compile for him at 80MHz to replicate how things used to be.
OK, the final P2 allows on the fly clock speed change - can you not give some better clock speed granularity, by using a higher PLL start setting in the FPGA ?
It would be important test coverage to be able to test P2 code at varying clock speeds.
I can find a quite old Altera Corporation 1 March 2003, ver. 1.2 Application Note 251AN-251-1.1 that mentions "In Cyclone FPGAs, the VCO ranges from 300 to 800 MHz.", so I guess all newer parts can manage at least that.
Looks like 480MHz is a practical VCO starting point, to then allow 120MHz, 96MHz, 80MHz... selection ?
I'll have a new FPGA release out today that reflects what is going to get synthesized.
While those images compile, I'm working on the new Spin. KISS, indeed.
Sounds great.
Will that FPGA release include builds to allow 120MHz, 96MHz, 80MHz testing ?
( seems a >= 480Mhz PLL setting and post-divider of 4,5,6 can cover those in one FPGA build ?)
The USB issues testing may benefit from a choice of MHz speeds.
It's just the same as before: 60MHz settable to 120MHz.
If Garryj can tell me which board he has, I can do a special compile for him at 80MHz to replicate how things used to be.
OK, the final P2 allows on the fly clock speed change - can you not give some better clock speed granularity, by using a higher PLL start setting in the FPGA ?
It would be important test coverage to be able to test P2 code at varying clock speeds.
I can find a quite old Altera Corporation 1 March 2003, ver. 1.2 Application Note 251AN-251-1.1 that mentions "In Cyclone FPGAs, the VCO ranges from 300 to 800 MHz.", so I guess all newer parts can manage at least that.
Looks like 480MHz is a practical VCO starting point, to then allow 120MHz, 96MHz, 80MHz... selection ?
Right now, we have an NCO running at 240MHz. The MSB of the NCO is used as the Prop2 clock. I'd need to change that whole scheme to a divide-by-N system to get jitter-free clocking.
Garryj, I think I asked before, but do you have a Prop123-A9 board? I can do an updated A9 compile today and post it. It uses bit 3 of the readback status in the USB mode to tell whether SE0/K/J have been valid for 7+ USB bit periods, while bits 2/1/0 express immediate SE0/K/J states, without any delays.
The new compile would also cover the bug where CALLPA/CALLPB and the event jumps couldn't branch backwards using 9-bit relative addresses.
Yep, a Prop123-A9, and the status bit changes look good.
Right now, we have an NCO running at 240MHz. The MSB of the NCO is used as the Prop2 clock. I'd need to change that whole scheme to a divide-by-N system to get jitter-free clocking.
The PLL VCO must be above 240MHz, so you could do a simple/fast 4-5 bit Divide-by-N, that should give a SysCLK of 120MHz..30 or 15MHz ?
Simplest /N design has 50% duty at /4 and it can be fixed high time at lower sysclks - IIRC you have no falling edge action anyway, so duty cycle is don't-care ?
So, it's easy to make a chip that uses a foundry's own IP, or some other proven IP, but to introduce your own transistor-level circuitry creates a huge ripple in the process.
If all that was required for this project was submitting a set of Verilog files, it would be so easy. Without good analog pins, though, we'd be missing a lot of functionality.
This is maybe a $50k expense. In the end, they have a "Liberty" file which makes your foreign I/O pin all part of the highly-detailed soup. I suppose this has to do with humans being trusted less and less to provide raw input to the process. Everything must be known, exactly.
Since so much is automated, where does the $50k come from ?
You have a SCH that the layout was made from, so do they need to re-create a new SCH from the physical design, to exactly include the routing delays etc
Even there, $50k is not that large a cost, as it is a one-off.
It's for extracting a schematic from layout and then simulating it to learn the exact performance. The extraction includes all parasitic capacitances and resistances of wires. The layout-to-schematic extraction is an automated process. They just need to know how to stimulate various nodes to evoke the timing behavior on internal flop nodes and external pins. $50k feels like a lot of money. And if you make a change...
Chip,
Sorry, I totally misunderstood this last paragraph. I thought the ring soup had to be chucked out, and replaced with OnSemi logic somehow, meaning all this verification work on the ring had to be redone.
However, this does not change my view that a Bigger P1 is now, more than ever, the immediate requirement! Now I see you can use the P2 ring soup with the P1 extras.
From my reference frame, the P2 requires too much reliance on "free" time donated by others external to Parallax to be a success. The tasks ahead are by no means simple, and will take a long elapsed time to be done. What needs to be done...
1. Spin2 completed
2. P2 Spin2 and PASM2 compiler (ie OpenSpin2 or PropTool2)
3. An IDE (Windows, Linux and Mac) for OpenSpin2/PropTool2
4. GCC (I see this as a huge external task)
4A. Fix PropellerIDE and/or SimpleIDE for P1, and then...
4B. Convert PropellerIDE and/or SimpleIDE to P2
5. BlocklyProp (another big task)
6. Documentation of P2 (hardware, instructions spin2 and PASM2, smart pins)
7. Documentation for GCC (think this is still missing for P1)
8. Documentation for BlocklyProp
9. A lot of P1 Objects and Demos need to be rewritten for P2 (big job)
10. Parallax Education Documentation needs to be rewritten for P2. Task unknown.
Only when all these are done, can the P2 really become "properly" usable.
I note here that the P1 is still not properly supported by Parallax, more than 10 years later. We still don't have a proper, clear and detailed documentation of P1. We still don't have a proper and workable replacement for PropTool. PropellerIDE and SimpleIDE are not ready for "prime time"! This is obvious from the regular P1 forum comments. So, we don't have Parallax support for the basic compile time options that "homespun" and "bst" brought us.
At least a "Big P1" would bring us backward compatibility, such that all the P1 software, objects, demos and tools could be used from day one of silicon. P2 has now moved too far away from P1 compatibility that it must be considered a new beast, not an upgraded P1.
The expense of $250K, or is it $300K, to be spent on a piece of silicon that potentially has a number of bugs, and therefore likely requiring another silicon respin, together with all the other pieces to be done, no longer makes any sense to me.
Seems a more prudent way forward would be to use the "P2 ring frame" together with a "P1 compatible CPU innards" plus safe extensions, thereby guaranteeing as far as is humanly possible, a working saleable piece of silicon that can immediately leverage all the existing software, demos, etc.
The existing P2 design does not need to be abandoned, just placed on temporary hold while the P1 compatible is done, at which time work can continue without quite so much pressure that proper testing and debugging can be done before committing to silicon. Meanwhile the P1 replacement work can be leveraged in the full knowledge that the ring frame is proven.
It is all about mitigating risk, together with a saleable product, for the least amount of expenditure.
cluso99, your comments are not conducive to getting the P2 as soon as possible. Could you please refrain from proposals that are counter to the P2? Parallax has made a commitment to producing the P2. We should all work together to support the P2 development.
Comments
-Mike R...
Ham Radio.
Some see a dying hobby, I see it changing, becoming more digital. Lots of new electronics hobbyists play with Ham Radio. In truth, even though many won't admit it, there are more HAMS now than ever before.
Display capabilities, Goertzel on every smart pin, Lots of potential throughput in the CORDIC suite of functions... WOW! Two chip CW skimmer anyone?
Sure, you have high jitter at certain frequencies.. There are things like the SI570 clock that can be changed on the fly for a more favorable Fin>Fout. Widely used already.
Solve the jitter with a programmable oscillator, or just plan for one frequency (I.F. anyone remember that?) Then it's CORDIC to the rescue again! Very easy to experiment with QAM, AM, SSB, FM, FSK and anything else you can dream up, with only changes to the program..
Upon release, I predict it will be one of the hottest (Figuratively...) chips in the Ham Radio arsenal!
So, how long does it take to get an ARM chip and an FPGA onto a circuit board, then program each one so that they work together? What if that same system could be built with one easy-to-wire chip (plus an 8-pin flash) that provided an integrated approach to all the problems? One programming tool, instead of at least two. One design methodology, instead of two. Configuration turn-around in 1 second without plugging/unplugging, as opposed to 3 to 5 minutes with a few cable connects/disconnects.
You would also have to build the PCB in either system as there will be actuators or other things not in the "logic" system. And if you are talking high speed, fly wires and plug boards don't cut it.
We are in the process of getting the P2 done. To abort, at this point, would be a huge change of course. We are heading towards completion. We are on the cusp of spending a lot of money to finish it.
I don't know what we would do for our educational products, as chips go, if there was no new Propeller chip. As it is, the innards are increasingly shielded by things like Blockly and C, so it wouldn't matter what was inside.
Listen, we need to have faith in this design. It's a great design. Frankly, the analog capabilities are insane great, and that will drive sales and uses of this chip. As for games, and other expectations, forget them. People will do things a bit differently on this chip, and when they do, it will be robust and attractive to others. The vast majority of P1 users use library code and it's easy, robust, gets things done. A minority of P1 users push it, and they often contribute more library code.
(besides, for games? This thing is a freaking playground! Trust me, no worries on that.)
P2 will play out exactly the same way. And as it does, that simple nature will be there. The difference is more depth. Don't let that depth get in the way of the vision and or set expectations that run counter to what this whole thing has been about. Please.
My suggestions are:
Get the test analog chip, validate it, pay the $50k and do what it takes to begin synthesis with the highest chance of success.
That $50k is our feature lock. The world is telling us to quit messing with it. Great! What we've got is pretty awesome, and very highly differentiated from everything else out there. Know what that means? It makes no sense to begin to compare and meet expectations set by everything else out there. Right? This is by design, deliberate, and that die is cast.
From there?
Chip, you should complete a lean, SPIN with in-line PASM. Make only the changes needed for SPIN to make sense on the larger memory model. We discussed a lot of advanced stuff. Forget it. That can be a revision / addition to the language over time. Make a baseline SPIN+PASM that can be the basis for library code, framework for PASM drivers, etc... and make this simple, like SPIN is today. One file, the works. Keep this lean, simple, so that library code can be used in other environments, including improved SPIN over time. Let the software community handle this. KISS on SPIN+PASM is super valuable for baseline, library code everyone will need and benefit from.
Throw everything out of SPIN that you can, leaving only the easy, useful nubs. This baseline SPIN+inline PASM is the foundation, library, driver, systems code. The smaller and simpler it is, the more easily it can be programmed in, and that also means it will be easier for others, who will build more advanced things, to take that code and use it and build on it. It also means a simple, useful, self-hosted image will be possible. Great. Nail all the basics with one simple effort. And finally, the smaller and simpler this all is, the easier it is to say it's done. Needs to be done.
It can and will be improved later, but our library code, getting the goodies people need to get started need to be written and written on something that will remain stable. This is the closest, easiest to achieve thing. Very important. This is the single most significant factor in the overall success of P1. Driver code written on day one is usable today. I cannot over emphasize just how valuable and important that really is.
All of us need to test / debug. No new features. Really. It's time. We need to find what's broken, if things are really broken and make what is there robust as all get out. Doing that will matter more than any little optimization will. And I'll be frank, the vast majority of users will not care about that optimization, and or will have done it differently surprising us and making that optimization redundant, or marginalized anyway. Have some faith. It's been a long road.
Every ask costs $50K, so don't do it. Debug and mean it.
Anyone with a testing framework could publish, and others could take it and start exercising things.
From there, the moment we can say feature lock and mean it, and I think that $50K is a nice, effective feature lock, real tool production can begin.
Parallax + interested others discuss both C and Blockly and kick off the minimum projects needed to bring those environments to the P2. There is no need to tie SPIN to any of this. Software filters, translators can be made, and will be made, and that's all going to work out just fine.
Anyone interested can begin to build driver / library code just like we did for P1. That code will be baseline, offering up good capability, but no where near the max capability, just like P1. And there are a bunch of things we can do. Video, sound, serial, USB(?), demos on test, measure, analog capture / sample, analog out, math, graphics, PS2 keyboard (worth it, simple), mouse, SD card, basic filesystem support. All of that can be done in the baseline SPIN, and the moment C gets to a place where it makes sense, make the tools that translate a lot of that over, and since it's in-line PASM, it can largely get sucked right in, useful.
Truth is, we don't even know what that max capability is! Just like P1, software will drive a lot of new stuff, and it will be used by people as it happens. Let that happen, and remember, for it to happen, people need a baseline set of stuff they can get going on right away.
We are here, end of a long road. We have a great design. People want it. And they want it for the highly differentiated design. It scratches itches that the other stuff does not, and that is why we did this in the first place! No backing out now, or it's all for nothing! I'll tell you right now, that does not sit well with me AT ALL.
I know people using P1 for products right now who want the P2 and not a damn thing we've got in the can puts them off.
Have some faith here. It's largely done. A ton of second guessing right now will undo a ton of work. Labors of love. And it will kill plans, that spark we need from people to be successful. Don't do it.
I'll have a new FPGA release out today that reflects what is going to get synthesized.
While those images compile, I'm working on the new Spin. KISS, indeed.
It's much easier to convert to full production, and frankly the analog won't be characterized until it is sharing silicon with some pretty noisy digital.
We could opt to use an OnSemi shuttle, at first, instead of paying for full tooling. We may do that.
Well, if it seemed not worth doing, we wouldn't want to proceed, right? This is a big commitment.
Sounds great.
Will that FPGA release include builds to allow 120MHz, 96MHz, 80MHz testing ?
( seems a >= 480Mhz PLL setting and post-divider of 4,5,6 can cover those in one FPGA build ?)
The USB issues testing may benefit from a choice of MHz speeds.
People invested here, and I know that's not the same as hard dollars, but it's still significant. Know it's appreciated and valued.
I personally believe this design will be successful, and it will be successful because it does have some features that are high value, not generally available, or not available with either the price point or accessibility P2 can deliver.
Can't tell you how big that is. Nobody can, but it's at least a very solid basis to justify having a product. And that success will depend on people using the product and sharing what they do and how they do it.
Only you have not actually achieved that "total backward compatibility".
The P1 has many Analog sections, that are not in a Verilog build
* Brownout
* RC Slow
* RC Fast
* Xtal Oscillator
* PLL, both SysCLK and Video
Those all need to be designed and proven. There is a PAD Ring being done for P2 that does that.
Whist your path needs a NEW PAD Ring for P1x...
However, 180nm parts have a 1.8V Vcc, so "total backward compatibility" goes *poof* right there, unless you add another Analog cell
* Internal 1.8V regulator ( decoupling tbf ?? )
Note adding this brings power dissipation issues into the mix & may limit upper MHz ....- and I'm unsure how much Icc can be pin-less (no decoupling)
The $250k++ costs are pretty much there for either pathway.
Next, you 'fall between two stools' over Memory :
i2c keeps part of "backward compatibility" tickbox, but now requires ROM housekeeping - if you desire the "total backward compatibility"
64kB of i2c is nowhere enough for an expanded memory device, but i2c tops out at 128kB/256kB, with SPI Flash being FAR cheaper.
So maybe that points to a dual-boot.... but notice that "total backward compatibility" is quietly slipping away...
All up, I'm not seeing lower development cost (from where P2 is now), or less work, but certainly a far less saleable device.
There is a whole world of low to mid volume products out there, many with healthy margins in them due to their niche / specialized nature, that aren't BOM cost sensitive.
P1 chips are being used now, where the capability is a good match. P2 expands on that very nicely.
In the US at least, these kinds of products are on a growth path too. Specialized, they nail a problem, are worth the money, and time to market, features, robustness are primary drivers that people who buy those products will pay for.
Initial prospects for P2 include:
US, hobby, general interest
Product design on P1, expanding to P2
Education (as it becomes available)
That's not a bad start. It's enough to get word out and build on. More than a lot of people have to go on. There may be a few larger fish in that product design pool too. Ken would know.
It's just the same as before: 60MHz settable to 120MHz.
If Garryj can tell me which board he has, I can do a special compile for him at 80MHz to replicate how things used to be.
I'd say that's a very good idea.
Have a read of this link (run via translator)
http://www.stcmcudata.com/sample-request/STC8-sample.TXT
This shows the revisions made by an experienced MCU IC vendor, bringing up a new device.
This is far from the first IC they ever did, but the new family errata makes sobering reading.
They are up to Rev D and Rev F, but do seem to be quite quick in doing a new revision.
OK, the final P2 allows on the fly clock speed change - can you not give some better clock speed granularity, by using a higher PLL start setting in the FPGA ?
It would be important test coverage to be able to test P2 code at varying clock speeds.
I can find a quite old Altera Corporation 1 March 2003, ver. 1.2 Application Note 251AN-251-1.1 that mentions
"In Cyclone FPGAs, the VCO ranges from 300 to 800 MHz.", so I guess all newer parts can manage at least that.
Looks like 480MHz is a practical VCO starting point, to then allow 120MHz, 96MHz, 80MHz... selection ?
Right now, we have an NCO running at 240MHz. The MSB of the NCO is used as the Prop2 clock. I'd need to change that whole scheme to a divide-by-N system to get jitter-free clocking.
Seems like an 80MHz compile could be useful. Looks like Garryj has the Prop123-A9 board based on this exchange from Page 10 of the USB thread:
Simplest /N design has 50% duty at /4 and it can be fixed high time at lower sysclks - IIRC you have no falling edge action anyway, so duty cycle is don't-care ?
Sorry, I totally misunderstood this last paragraph. I thought the ring soup had to be chucked out, and replaced with OnSemi logic somehow, meaning all this verification work on the ring had to be redone.
However, this does not change my view that a Bigger P1 is now, more than ever, the immediate requirement! Now I see you can use the P2 ring soup with the P1 extras.
From my reference frame, the P2 requires too much reliance on "free" time donated by others external to Parallax to be a success. The tasks ahead are by no means simple, and will take a long elapsed time to be done. What needs to be done...
1. Spin2 completed
2. P2 Spin2 and PASM2 compiler (ie OpenSpin2 or PropTool2)
3. An IDE (Windows, Linux and Mac) for OpenSpin2/PropTool2
4. GCC (I see this as a huge external task)
4A. Fix PropellerIDE and/or SimpleIDE for P1, and then...
4B. Convert PropellerIDE and/or SimpleIDE to P2
5. BlocklyProp (another big task)
6. Documentation of P2 (hardware, instructions spin2 and PASM2, smart pins)
7. Documentation for GCC (think this is still missing for P1)
8. Documentation for BlocklyProp
9. A lot of P1 Objects and Demos need to be rewritten for P2 (big job)
10. Parallax Education Documentation needs to be rewritten for P2. Task unknown.
Only when all these are done, can the P2 really become "properly" usable.
I note here that the P1 is still not properly supported by Parallax, more than 10 years later. We still don't have a proper, clear and detailed documentation of P1. We still don't have a proper and workable replacement for PropTool. PropellerIDE and SimpleIDE are not ready for "prime time"! This is obvious from the regular P1 forum comments. So, we don't have Parallax support for the basic compile time options that "homespun" and "bst" brought us.
At least a "Big P1" would bring us backward compatibility, such that all the P1 software, objects, demos and tools could be used from day one of silicon. P2 has now moved too far away from P1 compatibility that it must be considered a new beast, not an upgraded P1.
The expense of $250K, or is it $300K, to be spent on a piece of silicon that potentially has a number of bugs, and therefore likely requiring another silicon respin, together with all the other pieces to be done, no longer makes any sense to me.
Seems a more prudent way forward would be to use the "P2 ring frame" together with a "P1 compatible CPU innards" plus safe extensions, thereby guaranteeing as far as is humanly possible, a working saleable piece of silicon that can immediately leverage all the existing software, demos, etc.
The existing P2 design does not need to be abandoned, just placed on temporary hold while the P1 compatible is done, at which time work can continue without quite so much pressure that proper testing and debugging can be done before committing to silicon. Meanwhile the P1 replacement work can be leveraged in the full knowledge that the ring frame is proven.
It is all about mitigating risk, together with a saleable product, for the least amount of expenditure.