I believe: yes they are concerned. Form a commercial point of view the P2 would never be launched and would never exist. The same is true for P1. And the wave of arduino and rasp-pies came over the business. Happily they survived that storm. Because education is so difficult, it need not the latest technology in components, but in teaching experience. And that means: slow evolution, not revolution. If you ever stood in a classroom, you understand what I say. We had a Z80 based multi processor microcomputer and shared mass storage (40 MByte) and Printer. 14 terminals in a classroom. Every one or two hours the course changed and the teacher just had to swap current image and recall another one and was ready to go. Then first PC's squeezed us out. But from this time the king was named chaos! Novell netware was just in the beginning, coax showed reflections, the teacher had to play floppydiskjokey. They finally realised, they took the wrong way, but that didn't help. So it need enthusiam and risk propensity to go this high wire! Congrates!
edit: to be concerned doesn't neccessarily mean, to be able to change this situation. Isn't it?
Are you sure? I have some vague memories that go like this:
1 ) Chip releases the Verilog
2 ) I download it and put it into repo on github under ZiCog.
3 ) I fixed the white space formatting issues and added some documents.
4 ) Chip and I exchanged a few PMs where he seemed keen to take ownership of my repo into a parallax github area.
5 ) Chip lost interest, was too busy, whatever, and that never happened.
6 ) Someone else from Parallax put the original files up on a parallaxinc repo.
7 ) I nearly deleted my repo at the time. Except I noticed others had cloned it and there is even a pull request on it.
8 ) I can do nothing with pull requests really. I have no way to test it. It's not really my project anyway.
WIth hindsight being the everyone's best friend...
The time to do this was when the decision was first made to embark down the road with a P2 design in Verilog before all the P2 stuff started. Test your process, test your fab partners, test your fortitude to deliver a product through the new pipeline with a mostly tested, established incrementatl step to a known product. Once you've cranked out a P1 with an incremental change (64 pins), then you have a bunch of useful infomration for the P2 project and have hopefully reduced the learning curves.
But, all this has nothing to do with the current situation, so we march onward, ever onward!!
The unoffical official P1V repo is here. It has all the variations and mods that anyone was willing/able to commit to github. The github resistors have changes sprinkled through the forum. Last I recal, Jac was unsuccessful in gettign Parallax to pull all these changes into their repo and I don't think they ever moved the original P1V repo to the new "company" github.
@prof_braino: I'm trying to avoid FPGA unless it fits in a small and easy package.
...
If only Parallax had what we wanted from the beginning, a P1 with more memory and I/O.......can't understand why one was never made ........ is Parallax at all concerned about this?
@Peter - how many COGs do you need? Usually Tachyon systems do NOT need a lot of COGs.
Kernel, Serian-IN, Timer + 1 extra.??
So a P1V with reduced # of COGs and more memory/IO might fit into a smaller/cheaper FPGA.
And could be done now ...
What we really need is a P1+ now, and P2 can follow a little later. I said that more than 2 years ago, and I still believe it today.
Ditto. And in regards to Peter's requirements (and no doubt those of many others) the P2 presents two drawbacks: 1) The biggie, it doesn't exist and no one can be sure when it will (probably not anytime soon). 2) Even when the P2 becomes available it very well could be prohibitively costly and complex, ie, overkill for those applications.
So a P1V with reduced # of COGs and more memory/IO might fit into a smaller/cheaper FPGA.
And could be done now ...
Yes, the simple maths shows FPGA is an expensive way to get 8 COGs and/or lots of RAM, but a P1+P1V can give you a COG or two, that does things a P1 cannot.
Memory is also a fluid choice - in the last couple of days, I see rogloh reports SDRAM with P1V working, hidden in a HUB cycle.
ISSI shows sampling on HyperRAM and HyperFLASH, which give lower pin impact than SDRAM.
There is also QuadSPI SRAMs available now, at more modest MHz.
Peter: Have you tried making a version of Tachyon that can run code from external memory? I realize it would be a lot slower than what you have now but it might be good enough for the high-level program logic leaving separate hub-only COGs to run the time-sensitive Tachyon code. I was surprised at how reasonable PropGCC performed with XMMC (only code in external memory) using a SPI flash chip.
Peter: Have you tried making a version of Tachyon that can run code from external memory? I realize it would be a lot slower than what you have now but it might be good enough for the high-level program logic leaving separate hub-only COGs to run the time-sensitive Tachyon code. I was surprised at how reasonable PropGCC performed with XMMC (only code in external memory) using a SPI flash chip.
There is already a mechanism to run Tachyon-Forth scripts from SD-Card.
This is ok for seldom used and non time critical code,
like 'shell'-commands in DOS. Scripts is text, that get's compiled and executed on the fly.
Since the dictionary can already be moved to high EEPROM or even SD-Card this frees up some space as well.
besides the pub/pri there could be an 'ext' word to define words where code as well could life e.g. in EEPROM
but this has quite some implications - so I better go to bed now ... you asked Peter anyhow :-)
Peter: Have you tried making a version of Tachyon that can run code from external memory? I realize it would be a lot slower than what you have now but it might be good enough for the high-level program logic leaving separate hub-only COGs to run the time-sensitive Tachyon code. I was surprised at how reasonable PropGCC performed with XMMC (only code in external memory) using a SPI flash chip.
My thoughts on memory and code models.
External address/data bus memory is a real kludge IMO as it consumes precious I/O, is awkward and slow to access, and makes no sense when much more efficient single-chip solutions exist with large amounts of Flash and RAM with access times measured in nanoseconds. Even running code from SPI is a desperate solution when the best option is to make the code fit in 32k which is why both Spin and Tachyon use bytecode with the difference being that Tachyon bytecode does not need to be decoded and is much faster. As for CMM I can't see any sense in it, why waste a byte for a partial machine code instruction when it takes so long to read in the first place. If you go that far you may as well do something more useful with each instruction. So CMM is more compact than LMM but it is still a waste of precious memory resources.
As MJB mentioned I have the option of compacting the dictionary to upper EEPROM and on the subject of the dictionary remember that Tachyon doesn't actually need a dictionary to run code, but it is necessary for interaction and development and also text commands that the app may need to execute. The dictionary can be stripped down to leave just the words that are required for the app if necessary although having the upper EEPROM method renders that option moot.
The reason I need more memory and I/O and still have 8 cogs is because we do more with the Prop than run test code. Real apps need I/O and quite a few of these are used to implement serial buses of all kinds. This then needs buffer memory and with a full Tachyon system with networking I still have room for an app but I need to expand beyond this. In my current project I am now steering towards using multiple P1s to avoid having to go the ARM route. One Prop handles multiple RS485 buses and also uses RS485 to communicate back to the main P1 and another Prop is dedicated to VGA graphics over RS485. The main P1 handles the standard Tachyon+FAT32+Ethernet and in fact I'm able to use existing DIN rail product I have designed for the communications and main controller while one of my PIXIE modules plugs into the back of a VGA monitor.
So this is my solution at least for development and field testing but I still need a secure processor for production. If it can't be a Prop then I will be using an ARM almost certainly. At present P2 is an interesting plaything, I have BeMicroCV-A9 for prototyping if need be but I can't order the chip from Digikey/Mouser, nor can I hope to this year, or even maybe the next. Imagine if it was "orderable" even with a 52 week leadtime? Who'd bother.
.... In my current project I am now steering towards using multiple P1s to avoid having to go the ARM route. One Prop handles multiple RS485 buses and also uses RS485 to communicate back to the main P1 and another Prop is dedicated to VGA graphics over RS485. The main P1 handles the standard Tachyon+FAT32+Ethernet and in fact I'm able to use existing DIN rail product I have designed for the communications and main controller while one of my PIXIE modules plugs into the back of a VGA monitor.
Peter: Have you tried making a version of Tachyon that can run code from external memory? I realize it would be a lot slower than what you have now but it might be good enough for the high-level program logic leaving separate hub-only COGs to run the time-sensitive Tachyon code. I was surprised at how reasonable PropGCC performed with XMMC (only code in external memory) using a SPI flash chip.
My thoughts on memory and code models.
External address/data bus memory is a real kludge IMO as it consumes precious I/O, is awkward and slow to access, and makes no sense when much more efficient single-chip solutions exist with large amounts of Flash and RAM with access times measured in nanoseconds.
I was assuming you wanted to stick with the Propeller. If you're willing to consider other processors, why not run the high-level code on an ARM and use a P1 as a peripheral?
Peter would obviously love to use a P1. But there are unresolvable problems.
If he gets forced to go the ARM route for the main processor, then he may as well use ARM for the rest of the designs. Easier to keep your head around one processor than mixed processors.
But if the P1+ was available, then Peter would love to use it, even in the bigger TQFP100.
We now that if a P1+ was done now, we know there is little risk in it being available shortly, there is already the development software available now. Its a no-brainer. There are a lot of potential users now who would go for it, but those users are dwindling all the time. Once you lose them, they are mostly lost forever. If the P1+ was pin compatible with the P2, then that would be a later upgrade path too.
The P2 still has a long way to go. Even if you say the design is frozen today, there is a lot of testing to be done. There are now only a few interested in helping as you can see via the P2 threads.
A P1+ has a lot of interest because of instruction compatibility, can be tested on cheap FPGA boards, and development software already exists, objects already run, etc, etc. Chip's time to do the mods to P1V for P1+ are minimal. Even if this delayed P2 by 1 month at the extreme, this would be worth it to have a P1+ test silicon in a few months, followed shortly thereafter with real silicon. We could definitely see production silicon well before the years end. In reality, there is no chance of real P2 silicon this year. And the tools will likely take another year.
There are immediate commercial customers for the P1+ NOW.
Call the P1+ a P2. Call the P2 the P3/P4 or even something else.
I guess Parallax has to weigh in on this. I'd love to see a P1+ as well. The problem I see is that as soon as you decide to do one, everyone will have "one little feature" they think can be added without risk. After a dozen or so of those we get back into the state we're in with P2. Maybe it would be better if there was a silent behind-the-scenes effort to make a chip and only announce it here when it is actually possible to order it in silicon. Releasing in FPGA just invites lots of suggestions for "small" changes. Of course, if you can stick to a "no enhancements" policy, maybe it would work.
Peter: Have you tried making a version of Tachyon that can run code from external memory? I realize it would be a lot slower than what you have now but it might be good enough for the high-level program logic leaving separate hub-only COGs to run the time-sensitive Tachyon code. I was surprised at how reasonable PropGCC performed with XMMC (only code in external memory) using a SPI flash chip.
My thoughts on memory and code models.
External address/data bus memory is a real kludge IMO as it consumes precious I/O, is awkward and slow to access, and makes no sense when much more efficient single-chip solutions exist with large amounts of Flash and RAM with access times measured in nanoseconds.
I was assuming you wanted to stick with the Propeller. If you're willing to consider other processors, why not run the high-level code on an ARM and use a P1 as a peripheral?
Yes, I want to try to stick with the Prop which is also why I detailed in the other thread that I would distribute the task across three distinct Props, one the multiple RS485 processor, the PIXIE VGA, and the main Prop which just runs Tachyon as normal with FAT32 and Ethernet although I may want to add WiFi too. The P2 if it existed would be perfect and discrete ARM chips and even RPi require too much extra at this and there are too many unknowns at this point in the development.
So my configuration for this project is:
Control Prop with SD and Ethernet + RS485 (+WiFi)
Bus Communications Prop (5 x RS485)
VGA Prop (PIXIE over RS485)
System monitor Prop + microSD (4xRS485 etc)
36 x Node control Props + microSD etc
6 x Acquisition Props + microSD etc
There are also over 84 tiny 8-pin MSOP PIC chips used for A/D work as well and practically all the Props are logging everything they've been told, know, and do, just in case.
So a single P2 could replace control, bus, and VGA Prop and still have plenty of memory and cogs to spare but at least this way I'm working with a known quantity as I can't spend years and years on this project, I only have a matter of a few months.
I guess this is your best approach if you only have a few months. There is little chance that either P2 or a custom-for-your-needs FPGA image of P1v will be ready for production in that timeframe. Your project sounds really interesting. I hope you'll describe it here in detail once you're ready for it to become public.
I guess this is your best approach if you only have a few months. There is little chance that either P2 or a custom-for-your-needs FPGA image of P1v will be ready for production in that timeframe. Your project sounds really interesting. I hope you'll describe it here in detail once you're ready for it to become public.
If by some miracle P1B or P2 was available by the time I need to redesign for production then they would be in like Flynn but P1B would provide an easier upgrade path.
Just out of curiosity, why is some of Chip's time needed to make a P1B? We have the Verilog code and various people here have figured out to make significant enhancements. Someone with the financial resources could contact companies like Treehouse and On Semi to get the design synthesized and fabricated couldn't they?
Just out of curiosity, why is some of Chip's time needed to make a P1B? We have the Verilog code and various people here have figured out to make significant enhancements. Someone with the financial resources could contact companies like Treehouse and On Semi to get the design synthesized and fabricated couldn't they?
Absolutely, but that requires time and Chip can do it better and Parallax themselves rather than someone else will have the P1B that everyone wants and have been wanting for commercial projects. What an instant market!.
Just out of curiosity, why is some of Chip's time needed to make a P1B? We have the Verilog code and various people here have figured out to make significant enhancements. Someone with the financial resources could contact companies like Treehouse and On Semi to get the design synthesized and fabricated couldn't they?
Absolutely, but that requires time and Chip can do it better and Parallax themselves rather than someone else will have the P1B that everyone wants and have been wanting for commercial projects. What an instant market!.
Very true and I certainly wouldn't want to take business away from Parallax but I wonder if they really have time for this as much as they might like to do it?
Very true and I certainly wouldn't want to take business away from Parallax but I wonder if they really have time for this as much as they might like to do it?
But the Prop IS their business. No one designing Props into new product = NO business. Make P1B NOW and there are plenty of projects I would start dropping them in and I sense C would become a lot more practical and faster which is also a bonus for their education market.
Very true and I certainly wouldn't want to take business away from Parallax but I wonder if they really have time for this as much as they might like to do it?
But the Prop IS their business. No one designing Props into new product = NO business. Make P1B NOW and there are plenty of projects I would start dropping them in and I sense C would become a lot more practical and faster which is also a bonus for their education market.
Here is what I guess is probably the reality. We can either have P2 late this year or early next or we can have P1B at about the same time and P2 a year later. So we wouldn't get P1B any sooner than we are likely to get P2 if the current schedule holds and no new features are "sneaked in" at the last minute.
Very true and I certainly wouldn't want to take business away from Parallax but I wonder if they really have time for this as much as they might like to do it?
But the Prop IS their business. No one designing Props into new product = NO business. Make P1B NOW and there are plenty of projects I would start dropping them in and I sense C would become a lot more practical and faster which is also a bonus for their education market.
Here is what I guess is probably the reality. We can either have P2 late this year or early next or we can have P1B at about the same time and P2 a year later. So we wouldn't get P1B any sooner than we are likely to get P2 if the current schedule holds and no new features are "sneaked in" at the last minute.
Extremely unlikely that we will have P2 this year and besides when samples do come back they might not work since it is a rather complex design and it takes quite a long time before the next ones come back and then quite a while before they are available in production quantities. My guess for actual production P2s is 2018 yet P1B can be produced this year as the design is proven for starters. P1B will only put P2 back a few months and what is a few months compared to years and years of P2 design dragging out with no commercial product for Parallax in the meantime while they are bleeding development co$t$.
Very true and I certainly wouldn't want to take business away from Parallax but I wonder if they really have time for this as much as they might like to do it?
But the Prop IS their business. No one designing Props into new product = NO business. Make P1B NOW and there are plenty of projects I would start dropping them in and I sense C would become a lot more practical and faster which is also a bonus for their education market.
Here is what I guess is probably the reality. We can either have P2 late this year or early next or we can have P1B at about the same time and P2 a year later. So we wouldn't get P1B any sooner than we are likely to get P2 if the current schedule holds and no new features are "sneaked in" at the last minute.
Most of the P1+ sections has already been done by a few of us.
But Chip has done this many times for the various P2 and would have a preferred way.
There are a few bits not done - the security fuses, and the PLL's required for the counter/video, and perhaps 16x16 multiply and a divide???
It would not take Chip long to do this, and release an FPGA so that we could all test it.
We would have a P1+ way sooner than a P2. The P2 is still untested, there are very few testing today, and bugs are being found. There is no point in spending the money on licence fees for the July shuttle to include any P2 cores as the project has not settled. The only delay to P2 would be the short time that we would want Chip to divert to mod the P1+, aside from financials. It would give Parallax/Chip the breathing space to ensure the P2 is bug free, as the P1+ would relieve a lot of pressure, and be generating revenue immediately, rather than waiting for tools that will be required for P2.
BTW none of us want to do the P1+ alone. We want Parallax to be the owner and the beneficiary of the profit from P1+. They already have marketing in place, customers in place, etc, etc. And of course it is their IP that is being used, even though they open sourced it.
BTW#2 It is an absolute must that the P1+ features do not creep. The requirements are well understood by those involved.
There are a few bits not done - the security fuses, and the PLL's required for the counter/video, and perhaps 16x16 multiply and a divide???
This is exactly why I think it will take longer than you think. Things keep getting added on: more pins, more hub memory, security fuses, the boot ROM support needed for security, new Spin ROM image to support the extra hub memory, multiply, divide, maybe boot from SPI flash instead of EEPROM, the list goes on. They are each probably simple but none are proven any more than the current P2 is. You're probably right that P1v is much lower risk but there is still some risk.
.... Maybe it would be better if there was a silent behind-the-scenes effort to make a chip and only announce it here when it is actually possible to order it in silicon. ...
Who decides which of the already many P1V variants is chosen ?
eg Do you include SDRAM support, which someone now has working, or not ?
The NRE costs would price such a part much more than a P1, and with a short life cycle once P2 is released.
Who would fund that, or commit to buy enough ?
For less NRE cost, and far less risk, you can design a BGA carrier for a FPGA, and I suspect if there really was a critical mass of P1+ demand out there, that would have already been done.
Once you remove the TQFP package constraint, you have many more choices in FPGA.
eg Lattice show a 10x10mm FPGA, 118 io, with > 112K of RAM, (sub $20 in the larger package, 197 io).
there is also a 64KB smaller LFE5U-12 with no price yet , but that might get close to $10 ?
Addit : Looking at the -12 part I find Feb 10th : " The ECP5 12K device ... Software and device samples are available upon request."
Feburary 22, 2016 ... Lattice Diamond® design tool suite, version 3.7 adds Software support for new ECP5 12K device
I see the P1B+ replacing the long in the tooth P1 in the long run. But it is not and should not be one of those enhanced P1Vs, that's not what is needed. We need a plain and simple Prop with more memory, more I/O (maybe 56 with 8 internal) and hopefully the same sized package by using QFP64. Yes, security "fuses" will need to be added. The thing is, absolute minimum fuss and features. P2 will be too big and fancy for a the bulk of the Prop requirements but P1 is a bit too basic now as is. Except for a security setting mechanism there should be no change to the Spin ROM, it can still be used the same way P1 is used now as there are other options for taking advantage of the extra memory now.
If though someone identifies a suitable FPGA such as the Lattice parts that will do a full P1+ then great, please let us know because I will also explore that option too.
Comments
edit: to be concerned doesn't neccessarily mean, to be able to change this situation. Isn't it?
I don't think it was ever added. We've all been working from https://github.com/ZiCog/P8X32A_Emulation (or one of the forks).
1 ) Chip releases the Verilog
2 ) I download it and put it into repo on github under ZiCog.
3 ) I fixed the white space formatting issues and added some documents.
4 ) Chip and I exchanged a few PMs where he seemed keen to take ownership of my repo into a parallax github area.
5 ) Chip lost interest, was too busy, whatever, and that never happened.
6 ) Someone else from Parallax put the original files up on a parallaxinc repo.
7 ) I nearly deleted my repo at the time. Except I noticed others had cloned it and there is even a pull request on it.
8 ) I can do nothing with pull requests really. I have no way to test it. It's not really my project anyway.
Or maybe I just getting senile already.
https://github.com/parallaxinc/Propeller_1_Design
And it's listed on page two:
https://github.com/parallaxinc?page=2
The time to do this was when the decision was first made to embark down the road with a P2 design in Verilog before all the P2 stuff started. Test your process, test your fab partners, test your fortitude to deliver a product through the new pipeline with a mostly tested, established incrementatl step to a known product. Once you've cranked out a P1 with an incremental change (64 pins), then you have a bunch of useful infomration for the P2 project and have hopefully reduced the learning curves.
But, all this has nothing to do with the current situation, so we march onward, ever onward!!
The unoffical official P1V repo is here. It has all the variations and mods that anyone was willing/able to commit to github. The github resistors have changes sprinkled through the forum. Last I recal, Jac was unsuccessful in gettign Parallax to pull all these changes into their repo and I don't think they ever moved the original P1V repo to the new "company" github.
Some times you get what you pay for.....other times, you get what you pay for!
Kernel, Serian-IN, Timer + 1 extra.??
So a P1V with reduced # of COGs and more memory/IO might fit into a smaller/cheaper FPGA.
And could be done now ...
Yes, the simple maths shows FPGA is an expensive way to get 8 COGs and/or lots of RAM, but a P1+P1V can give you a COG or two, that does things a P1 cannot.
Memory is also a fluid choice - in the last couple of days, I see rogloh reports SDRAM with P1V working, hidden in a HUB cycle.
ISSI shows sampling on HyperRAM and HyperFLASH, which give lower pin impact than SDRAM.
There is also QuadSPI SRAMs available now, at more modest MHz.
This is ok for seldom used and non time critical code,
like 'shell'-commands in DOS. Scripts is text, that get's compiled and executed on the fly.
Since the dictionary can already be moved to high EEPROM or even SD-Card this frees up some space as well.
besides the pub/pri there could be an 'ext' word to define words where code as well could life e.g. in EEPROM
but this has quite some implications - so I better go to bed now ... you asked Peter anyhow :-)
My thoughts on memory and code models.
External address/data bus memory is a real kludge IMO as it consumes precious I/O, is awkward and slow to access, and makes no sense when much more efficient single-chip solutions exist with large amounts of Flash and RAM with access times measured in nanoseconds. Even running code from SPI is a desperate solution when the best option is to make the code fit in 32k which is why both Spin and Tachyon use bytecode with the difference being that Tachyon bytecode does not need to be decoded and is much faster. As for CMM I can't see any sense in it, why waste a byte for a partial machine code instruction when it takes so long to read in the first place. If you go that far you may as well do something more useful with each instruction. So CMM is more compact than LMM but it is still a waste of precious memory resources.
As MJB mentioned I have the option of compacting the dictionary to upper EEPROM and on the subject of the dictionary remember that Tachyon doesn't actually need a dictionary to run code, but it is necessary for interaction and development and also text commands that the app may need to execute. The dictionary can be stripped down to leave just the words that are required for the app if necessary although having the upper EEPROM method renders that option moot.
The reason I need more memory and I/O and still have 8 cogs is because we do more with the Prop than run test code. Real apps need I/O and quite a few of these are used to implement serial buses of all kinds. This then needs buffer memory and with a full Tachyon system with networking I still have room for an app but I need to expand beyond this. In my current project I am now steering towards using multiple P1s to avoid having to go the ARM route. One Prop handles multiple RS485 buses and also uses RS485 to communicate back to the main P1 and another Prop is dedicated to VGA graphics over RS485. The main P1 handles the standard Tachyon+FAT32+Ethernet and in fact I'm able to use existing DIN rail product I have designed for the communications and main controller while one of my PIXIE modules plugs into the back of a VGA monitor.
So this is my solution at least for development and field testing but I still need a secure processor for production. If it can't be a Prop then I will be using an ARM almost certainly. At present P2 is an interesting plaything, I have BeMicroCV-A9 for prototyping if need be but I can't order the chip from Digikey/Mouser, nor can I hope to this year, or even maybe the next. Imagine if it was "orderable" even with a 52 week leadtime? Who'd bother.
That sound easy to manage.
Can you not add sufficient security via some small MCU, as a key / coprocessor ?
If he gets forced to go the ARM route for the main processor, then he may as well use ARM for the rest of the designs. Easier to keep your head around one processor than mixed processors.
But if the P1+ was available, then Peter would love to use it, even in the bigger TQFP100.
We now that if a P1+ was done now, we know there is little risk in it being available shortly, there is already the development software available now. Its a no-brainer. There are a lot of potential users now who would go for it, but those users are dwindling all the time. Once you lose them, they are mostly lost forever. If the P1+ was pin compatible with the P2, then that would be a later upgrade path too.
The P2 still has a long way to go. Even if you say the design is frozen today, there is a lot of testing to be done. There are now only a few interested in helping as you can see via the P2 threads.
A P1+ has a lot of interest because of instruction compatibility, can be tested on cheap FPGA boards, and development software already exists, objects already run, etc, etc. Chip's time to do the mods to P1V for P1+ are minimal. Even if this delayed P2 by 1 month at the extreme, this would be worth it to have a P1+ test silicon in a few months, followed shortly thereafter with real silicon. We could definitely see production silicon well before the years end. In reality, there is no chance of real P2 silicon this year. And the tools will likely take another year.
There are immediate commercial customers for the P1+ NOW.
Call the P1+ a P2. Call the P2 the P3/P4 or even something else.
Yes, I want to try to stick with the Prop which is also why I detailed in the other thread that I would distribute the task across three distinct Props, one the multiple RS485 processor, the PIXIE VGA, and the main Prop which just runs Tachyon as normal with FAT32 and Ethernet although I may want to add WiFi too. The P2 if it existed would be perfect and discrete ARM chips and even RPi require too much extra at this and there are too many unknowns at this point in the development.
So my configuration for this project is:
- Control Prop with SD and Ethernet + RS485 (+WiFi)
- Bus Communications Prop (5 x RS485)
- VGA Prop (PIXIE over RS485)
- System monitor Prop + microSD (4xRS485 etc)
- 36 x Node control Props + microSD etc
- 6 x Acquisition Props + microSD etc
There are also over 84 tiny 8-pin MSOP PIC chips used for A/D work as well and practically all the Props are logging everything they've been told, know, and do, just in case.So a single P2 could replace control, bus, and VGA Prop and still have plenty of memory and cogs to spare but at least this way I'm working with a known quantity as I can't spend years and years on this project, I only have a matter of a few months.
If by some miracle P1B or P2 was available by the time I need to redesign for production then they would be in like Flynn but P1B would provide an easier upgrade path.
Absolutely, but that requires time and Chip can do it better and Parallax themselves rather than someone else will have the P1B that everyone wants and have been wanting for commercial projects. What an instant market!.
Very true and I certainly wouldn't want to take business away from Parallax but I wonder if they really have time for this as much as they might like to do it?
But Chip has done this many times for the various P2 and would have a preferred way.
There are a few bits not done - the security fuses, and the PLL's required for the counter/video, and perhaps 16x16 multiply and a divide???
It would not take Chip long to do this, and release an FPGA so that we could all test it.
We would have a P1+ way sooner than a P2. The P2 is still untested, there are very few testing today, and bugs are being found. There is no point in spending the money on licence fees for the July shuttle to include any P2 cores as the project has not settled. The only delay to P2 would be the short time that we would want Chip to divert to mod the P1+, aside from financials. It would give Parallax/Chip the breathing space to ensure the P2 is bug free, as the P1+ would relieve a lot of pressure, and be generating revenue immediately, rather than waiting for tools that will be required for P2.
BTW none of us want to do the P1+ alone. We want Parallax to be the owner and the beneficiary of the profit from P1+. They already have marketing in place, customers in place, etc, etc. And of course it is their IP that is being used, even though they open sourced it.
BTW#2 It is an absolute must that the P1+ features do not creep. The requirements are well understood by those involved.
Who decides which of the already many P1V variants is chosen ?
eg Do you include SDRAM support, which someone now has working, or not ?
The NRE costs would price such a part much more than a P1, and with a short life cycle once P2 is released.
Who would fund that, or commit to buy enough ?
For less NRE cost, and far less risk, you can design a BGA carrier for a FPGA, and I suspect if there really was a critical mass of P1+ demand out there, that would have already been done.
Once you remove the TQFP package constraint, you have many more choices in FPGA.
eg Lattice show a 10x10mm FPGA, 118 io, with > 112K of RAM, (sub $20 in the larger package, 197 io).
there is also a 64KB smaller LFE5U-12 with no price yet , but that might get close to $10 ?
Addit : Looking at the -12 part I find Feb 10th : " The ECP5 12K device ... Software and device samples are available upon request."
Feburary 22, 2016 ... Lattice Diamond® design tool suite, version 3.7 adds Software support for new ECP5 12K device
If though someone identifies a suitable FPGA such as the Lattice parts that will do a full P1+ then great, please let us know because I will also explore that option too.