First thing you have to do is get people's attention then make the sale. I see none of this. People are assuming that the PII FPGA will automatically win new users win over. Doubtful, It will probably win over current users of the P1, but I don't see it winning non Prop users unless it offers them something very compelling that current products don't have. It certainly won't be on price. However given that the current promoters of the soft PII are gun shy on direct product comparisons. I just wonder how they'll peddle it. Except as "trust us, it's better than x".
That's fine if you're selling car stereos out of the trunk of your car in the middle of the night. It doesn't work for micros..It will just elicit snickers.
I look at what happened when Parallax released the Verilog code for the P-1 a bunch of hard core posters here went overboard thinking it would usher in a new era of Propeller prosperity. Some even going for far as bragging how Parallax was ahead of all the big dogs in the semi-conductor business. Instead it landed like a lead balloon. A handful of people ended up playing with it, but there have been no commercial adoptions of it.
They didn't factor in that few are really into FPGA's compared to microcontrollers or that it's a old design with quirky limitations.
Or lets go back further when the gang was figuring out ways of winning over Arduino users. It was a massive failure. They refused to consider that Arduino users aren't like Prop users(much older and experienced) but artists, noobs and the like who just liked doing some simple things.
I also don't think soft-peripherals are a selling point anymore either. I look at the automotive controllers from Freescale and Infineon, they are loaded with a set of H/W peripherals the Prop could never hope to emulate. Not to mention having all the right certifications and meeting industry standards. I doubt Parallax is going to pay for that stuff or has the resources to do white papers, product comparisons, getting a booth at Design West, etc.
I do think the PII can find a niche in the less sexy markets but higher profit margin industrial controllers and the like. It won't clean up but I bet money it will do okay.
So, if thats a 2K cell device for 1 COG, the cheapest 16K cell I see is 10M16SCU169C8G for $21. Though not being into FPGA, I don't know if that covers everything a standard P1 contains.
Assuming a P1v 200 Mhz can be completely expressed within the FPGA, it an FPGA P1v 8 Core would run at least $21/FPGA, misc. board and Manf. BOM, and some amount X for per unit Licensing. $0.50, $1, 3, 5 ?
EDIT- OK the Nano itself is $89 and appears obvious that there is significant additional components and design needed.
Even with lower FPGA costs, is it even reasonable to expect some sort of P1v 200Mhz to be able to come in at $50-60?
I
think it may be difficult enough as it is to get more people interested
in a $20 P2, but $50 for a fast P1 seems just a waste of time.
Actually,
is there anything really stopping anyone from doing this now, with the
OSS P1 released? Is this a situation where there is a clear market
potential, or we're looking to make a market?
That last was
really for Potatohead. I might be wrong, but it looks like all the
variants are currently doable now, so shouldn't there be inquiries on
the forum if there were any interest?
Actually,
is there anything really stopping anyone from doing this now, with the
OSS P1 released? Is this a situation where there is a clear market
potential, or we're looking to make a market?
That's why I favour the P1V for now.
Keep in mind that the MAX 10 is very new, and I think release of a P1 and P1V on a board makes sense initially & some significant step in MHz would clearly help.
If P1V runs only at 80MHz, it is left to other areas to get attention.
However, if it can get 200+MHz, then things change.
Is there a Spin compiler for P2-hot? There isn't a C/C++ compiler that I know of. I ported propgcc to an earlier instruction set but never updated it when Chip started changing things dramatically. I guess that means that anyone who adopts P2-hot will have to code in assembler with PNut?
We never got one. Chip did a first pass, but it was pretty broken.
Yep, PNut it is! Baggers and I were kicking around with the idea of making a macro assembler to tide us over.
If you don't mind python, you might be able to Orochi (https://github.com/Seairth/Orochi) to get you going. I originally created it for P1V, primarily to make it very easy to add support for new/experimental instructions.
However, it may also be a good starting point for P2. When the final P2 instruction set is released, I'll probably make a variant of Orochi for this very purpose. Of course, it will need a new name...
We never got one. Chip did a first pass, but it was pretty broken.
Yep, PNut it is! Baggers and I were kicking around with the idea of making a macro assembler to tide us over.
If you don't mind python, you might be able to Orochi (https://github.com/Seairth/Orochi) to get you going. I originally created it for P1V, primarily to make it very easy to add support for new/experimental instructions.
However, it may also be a good starting point for P2. When the final P2 instruction set is released, I'll probably make a variant of Orochi for this very purpose. Of course, it will need a new name...
It's hard to know when we'll have a "final P2 instruction set". Once the new FPGA image is released, I'm sure there will be lots of suggestions for improvements some of which might involve instruction set changes. Might be best to wait for the actual silicon.
I'm just now following the MAX 10 thread. Is the thought that it might be possible to fit a "stock" P1V on a MAX 10 breakout board for maybe $50? If that could be done with no other changes except a faster clock speed and Port B support, I think you'd have a fantastic product! Out of the box, you'd basically get a turbo-charged P1. But, for those designs that don't require all 8 cogs, you could tweak the "stock" P1V for the precise number of cogs needed, drop unused capabilities (e.g. vid), etc. and free up LEs for all sorts of domain-specific functionality.
That seems like a real winner to me! I'd definitely buy such a product from Parallax! Further, this allows Parallax to focus on what appears to be their core business: hobbyists and education.
Further, I don't think it would hurt the existing P1 business, where price will still prevail.
And it won't hurt the potential P2 business, because the P2 is so much more than the P1 (or P1V). In fact, it might even be possible that that a P1V MAX 10 breakout board will help P2 sales. After all, if someone uses the P1V version with faster clock speeds and more I/O pins, then wants to take it to an ASIC/ASSC, the P2 would be the logical choice.
"Licensing the Propeller 2 FPGA: For Serious Commentary and Consideration"
I have come to the conclusion that it's a silly idea. Because:
1) If I have a problem that can be solved with a regular off the shelf MCU/SoC with it's plethora of peripherals and programmable in C/C++ and very cheap, then that is what I will use.
2) If I have a problem that requires some weird, real-time, high speed, IO handling that those MCU/SoCs cannot handle I might use an FPGA and do my thing in some HDL.
3) Perhaps my FPGA solution could do with some regular, not so fast, management. OK there are dozens of ways of putting a CPU core into my FPGA and programming that to do what I want.
So, where in this space is the need for any Propeller core in my FPGA?
The Propeller, perhaps more the PII and for sure the XMOS devices exactly fill some space where a regular off the shelf MCU/SoC do not quite cut it but an FPGA solution becomes to complex and expensive.
Basically, if I want a CPU in my FPGA design there are many to choose from, many of them are open source and free. Why would I want a Propeller core in there?
"Licensing the Propeller 2 FPGA: For Serious Commentary and Consideration"
I have come to the conclusion that it's a silly idea. Because:
1) If I have a problem that can be solved with a regular off the shelf MCU/SoC with it's plethora of peripherals and programmable in C/C++ and very cheap, then that is what I will use.
2) If I have a problem that requires some weird, real-time, high speed, IO handling that those MCU/SoCs cannot handle I might use an FPGA and do my thing in some HDL.
3) Perhaps my FPGA solution could do with some regular, not so fast, management. OK there are dozens of ways of putting a CPU core into my FPGA and programming that to do what I want.
So, where in this space is the need for any Propeller core in my FPGA?
The Propeller, perhaps more the PII and for sure the XMOS devices exactly fill some space where a regular off the shelf MCU/SoC do not quite cut it but an FPGA solution becomes to complex and expensive.
Basically, if I want a CPU in my FPGA design there are many to choose from, many of them are open source and free. Why would I want a Propeller core in there?
But an FPGA with a P1v configuration programmed into it is just a kind-of-expensive MCU, right? Why not consider that like you would any other MCU? However, if we're talking about using it as a soft core to be combined with customer RTL, then I guess I agree.
David,"But an FPGA with a P1v configuration programmed into it is just a kind-of-expensive MCU, right?"
Right.
"Why not consider that like you would any other MCU?"
Perhaps because it's a lot more expensive and has a lot less features.
If I need that custom HDL to get my job done then I don't need the Propeller's real-time bit twiddling capabilityanymore. I've got HDL to do that.
David,"But an FPGA with a P1v configuration programmed into it is just a kind-of-expensive MCU, right?"
Right.
"Why not consider that like you would any other MCU?"
Perhaps because it's a lot more expensive and has a lot less features.
If I need that custom HDL to get my job done then I don't need the Propeller's real-time bit twiddling capabilityanymore. I've got HDL to do that.
I guess I had assumed some compelling features would be added to the FPGA to distinguish it from a run-of-the-mill P1 chip. Of course, I guess that violates the Propeller philosophy of soft peripherals. If we're talking about an enhanced COG then we run into the tools issue. It would be great to add XIP or hub exec to the P1 but where would you get the tools to take advantage of that?
I don't know.
Soft peripherals is what the Prop is about.
It's also what the XMOS devices are about.
To fill that space between MCU and FPGA or ASIC.
The XMOS guys seem to have figured out that is not enough. Their latest devices include hardware for USB and whatever peripherals. After all it's only a very small additional area to the devices.
It makes sense to me to include a few very commonly needed peripherals like UART, SPI, I2C, and probably USB if they don't take too much space. Sure you might find you need more than are on the chip but then you can build the rest as "soft peripherals".
I think that XMOS still implements high-speed USB and most other peripheral functions in software. It's just the Phy that they implement in hardware, as well as ADCs.
Have P2 HDL code don't helps much for any one that will implement it in FPGA.
That can be good for real time compilation BUT it is not possible to implement SMART IO pins inside FPGA so that give not any advantages to build Yours own complete P2 in FPGA.
If it is software, why show a USB block in the architecture diagram next to the cores and RAM and stuff, as in the document I linked to above?
Or is this another XMOS sham like how they say threads are cores?
It clearly states in the data sheet (page 3) that the USB block is just the PHY and the USB functionality is via a library:
USB The USB PHY provides High-Speed and Full-Speed, device, host, and on-thego
functionality. Data is communicated through ports on the digital node. A
library is provided to implement USB device functionality. Section 10
See page 19 for details of the USB. The PHY is just connected to Tiles 0 and 1, there is no dedicated USB hardware, although only Tiles 0 or 1 may be used.
That USB block in the diagrams is a combination of hardware (the PHY) and software. The same applies to the RGMII Ethernet block.
It clearly states in the data sheet (page 3) that the USB block is just the PHY and the USB functionality is via a library:
USB The USB PHY provides High-Speed and Full-Speed, device, host, and on-thego
functionality. Data is communicated through ports on the digital node. A
library is provided to implement USB device functionality. Section 10
See page 19 for details of the USB. The PHY is just connected to Tiles 0 and 1, there is no dedicated USB hardware, although only Tiles 0 or 1 may be used.
This comes down a little to semantics, and the 'PHY' for HS USB has to be doing some bit-level helping, as well as the low voltage differential signaling.ie I cannot see SW doing bit stuff/destuff at 480MBd
That level of bit-level assist, is also suited to a P2/P1V
Yes, Leon, that does not detract from my observation that they felt compelled to put such peripherals on there instead of using software to implement them.
Customers probably asked for ARM peripherals, as they already had software supporting them and they were familiar with them. It also makes more of the XMOS cores available, which might be advantageous.
Thanks for exploring this discussion. Sadly, there has been no "official" input on this in three pages of discussion and 1.5k of views, so it's probably pointless to explore this further. Perhaps I'm the wrong person to have brought the topic to the table with my recent offences to Parallax.
I'd better close this message before I say something stupid again..
Comments
First thing you have to do is get people's attention then make the sale. I see none of this. People are assuming that the PII FPGA will automatically win new users win over. Doubtful, It will probably win over current users of the P1, but I don't see it winning non Prop users unless it offers them something very compelling that current products don't have. It certainly won't be on price. However given that the current promoters of the soft PII are gun shy on direct product comparisons. I just wonder how they'll peddle it. Except as "trust us, it's better than x".
That's fine if you're selling car stereos out of the trunk of your car in the middle of the night. It doesn't work for micros..It will just elicit snickers.
I look at what happened when Parallax released the Verilog code for the P-1 a bunch of hard core posters here went overboard thinking it would usher in a new era of Propeller prosperity. Some even going for far as bragging how Parallax was ahead of all the big dogs in the semi-conductor business. Instead it landed like a lead balloon. A handful of people ended up playing with it, but there have been no commercial adoptions of it.
They didn't factor in that few are really into FPGA's compared to microcontrollers or that it's a old design with quirky limitations.
Or lets go back further when the gang was figuring out ways of winning over Arduino users. It was a massive failure. They refused to consider that Arduino users aren't like Prop users(much older and experienced) but artists, noobs and the like who just liked doing some simple things.
I also don't think soft-peripherals are a selling point anymore either. I look at the automotive controllers from Freescale and Infineon, they are loaded with a set of H/W peripherals the Prop could never hope to emulate. Not to mention having all the right certifications and meeting industry standards. I doubt Parallax is going to pay for that stuff or has the resources to do white papers, product comparisons, getting a booth at Design West, etc.
I do think the PII can find a niche in the less sexy markets but higher profit margin industrial controllers and the like. It won't clean up but I bet money it will do okay.
Good thread all.
Not sure where that puts things for you Jeff, but this topic saw some ideas and good discussion.
So, ($2.84/1k gives you (roughly) 1 P1V COG)
So, if thats a 2K cell device for 1 COG, the cheapest 16K cell I see is 10M16SCU169C8G for $21. Though not being into FPGA, I don't know if that covers everything a standard P1 contains.
Assuming a P1v 200 Mhz can be completely expressed within the FPGA, it an FPGA P1v 8 Core would run at least $21/FPGA, misc. board and Manf. BOM, and some amount X for per unit Licensing. $0.50, $1, 3, 5 ?
EDIT- OK the Nano itself is $89 and appears obvious that there is significant additional components and design needed.
Even with lower FPGA costs, is it even reasonable to expect some sort of P1v 200Mhz to be able to come in at $50-60?
I
think it may be difficult enough as it is to get more people interested
in a $20 P2, but $50 for a fast P1 seems just a waste of time.
Actually,
is there anything really stopping anyone from doing this now, with the
OSS P1 released? Is this a situation where there is a clear market
potential, or we're looking to make a market?
That last was
really for Potatohead. I might be wrong, but it looks like all the
variants are currently doable now, so shouldn't there be inquiries on
the forum if there were any interest?
Actually,
is there anything really stopping anyone from doing this now, with the
OSS P1 released? Is this a situation where there is a clear market
potential, or we're looking to make a market?
That's why I favour the P1V for now.
Keep in mind that the MAX 10 is very new, and I think release of a P1 and P1V on a board makes sense initially & some significant step in MHz would clearly help.
If P1V runs only at 80MHz, it is left to other areas to get attention.
However, if it can get 200+MHz, then things change.
Yep, PNut it is! Baggers and I were kicking around with the idea of making a macro assembler to tide us over.
Yep, PNut it is! Baggers and I were kicking around with the idea of making a macro assembler to tide us over.
If you don't mind python, you might be able to Orochi (https://github.com/Seairth/Orochi) to get you going. I originally created it for P1V, primarily to make it very easy to add support for new/experimental instructions.
However, it may also be a good starting point for P2. When the final P2 instruction set is released, I'll probably make a variant of Orochi for this very purpose. Of course, it will need a new name...
Yep, PNut it is! Baggers and I were kicking around with the idea of making a macro assembler to tide us over.
If you don't mind python, you might be able to Orochi (https://github.com/Seairth/Orochi) to get you going. I originally created it for P1V, primarily to make it very easy to add support for new/experimental instructions.
However, it may also be a good starting point for P2. When the final P2 instruction set is released, I'll probably make a variant of Orochi for this very purpose. Of course, it will need a new name...
It's hard to know when we'll have a "final P2 instruction set". Once the new FPGA image is released, I'm sure there will be lots of suggestions for improvements some of which might involve instruction set changes. Might be best to wait for the actual silicon.
That seems like a real winner to me! I'd definitely buy such a product from Parallax! Further, this allows Parallax to focus on what appears to be their core business: hobbyists and education.
Further, I don't think it would hurt the existing P1 business, where price will still prevail.
And it won't hurt the potential P2 business, because the P2 is so much more than the P1 (or P1V). In fact, it might even be possible that that a P1V MAX 10 breakout board will help P2 sales. After all, if someone uses the P1V version with faster clock speeds and more I/O pins, then wants to take it to an ASIC/ASSC, the P2 would be the logical choice.
I have come to the conclusion that it's a silly idea. Because:
1) If I have a problem that can be solved with a regular off the shelf MCU/SoC with it's plethora of peripherals and programmable in C/C++ and very cheap, then that is what I will use.
2) If I have a problem that requires some weird, real-time, high speed, IO handling that those MCU/SoCs cannot handle I might use an FPGA and do my thing in some HDL.
3) Perhaps my FPGA solution could do with some regular, not so fast, management. OK there are dozens of ways of putting a CPU core into my FPGA and programming that to do what I want.
So, where in this space is the need for any Propeller core in my FPGA?
The Propeller, perhaps more the PII and for sure the XMOS devices exactly fill some space where a regular off the shelf MCU/SoC do not quite cut it but an FPGA solution becomes to complex and expensive.
Basically, if I want a CPU in my FPGA design there are many to choose from, many of them are open source and free. Why would I want a Propeller core in there?
I have come to the conclusion that it's a silly idea. Because:
1) If I have a problem that can be solved with a regular off the shelf MCU/SoC with it's plethora of peripherals and programmable in C/C++ and very cheap, then that is what I will use.
2) If I have a problem that requires some weird, real-time, high speed, IO handling that those MCU/SoCs cannot handle I might use an FPGA and do my thing in some HDL.
3) Perhaps my FPGA solution could do with some regular, not so fast, management. OK there are dozens of ways of putting a CPU core into my FPGA and programming that to do what I want.
So, where in this space is the need for any Propeller core in my FPGA?
The Propeller, perhaps more the PII and for sure the XMOS devices exactly fill some space where a regular off the shelf MCU/SoC do not quite cut it but an FPGA solution becomes to complex and expensive.
Basically, if I want a CPU in my FPGA design there are many to choose from, many of them are open source and free. Why would I want a Propeller core in there?
But an FPGA with a P1v configuration programmed into it is just a kind-of-expensive MCU, right? Why not consider that like you would any other MCU? However, if we're talking about using it as a soft core to be combined with customer RTL, then I guess I agree.
Right.
"Why not consider that like you would any other MCU?"
Perhaps because it's a lot more expensive and has a lot less features.
If I need that custom HDL to get my job done then I don't need the Propeller's real-time bit twiddling capabilityanymore. I've got HDL to do that.
Right.
"Why not consider that like you would any other MCU?"
Perhaps because it's a lot more expensive and has a lot less features.
If I need that custom HDL to get my job done then I don't need the Propeller's real-time bit twiddling capabilityanymore. I've got HDL to do that.
I guess I had assumed some compelling features would be added to the FPGA to distinguish it from a run-of-the-mill P1 chip. Of course, I guess that violates the Propeller philosophy of soft peripherals. If we're talking about an enhanced COG then we run into the tools issue. It would be great to add XIP or hub exec to the P1 but where would you get the tools to take advantage of that?
Soft peripherals is what the Prop is about.
It's also what the XMOS devices are about.
To fill that space between MCU and FPGA or ASIC.
The XMOS guys seem to have figured out that is not enough. Their latest devices include hardware for USB and whatever peripherals. After all it's only a very small additional area to the devices.
Have P2 HDL code don't helps much for any one that will implement it in FPGA.
That can be good for real time compilation BUT it is not possible to implement SMART IO pins inside FPGA so that give not any advantages to build Yours own complete P2 in FPGA.
Here is the data for a USB audio CORE-200 chip
https://www.xmos.com/download/private/XE216-512-TQ128-Datasheet(1.2).pdf
The USB functionality is definitely implemented in software:
ThThe XMOS XUD software component runs in a single logical core with endpoint andapplication cores communicating with it via a combination of channel communica-tion and shared memory variables."
XUD is the USB software library:
https://www.xmos.com/download/public/XMOS-USB-Device-(XUD)-Library-(documentation)(2.2.1rc0.a).pdf
Or is this another XMOS sham like how they say threads are cores?
USB The USB PHY provides High-Speed and Full-Speed, device, host, and on-thego
functionality. Data is communicated through ports on the digital node. A
library is provided to implement USB device functionality. Section 10
See page 19 for details of the USB. The PHY is just connected to Tiles 0 and 1, there is no dedicated USB hardware, although only Tiles 0 or 1 may be used.
That USB block in the diagrams is a combination of hardware (the PHY) and software. The same applies to the RGMII Ethernet block.
USB The USB PHY provides High-Speed and Full-Speed, device, host, and on-thego
functionality. Data is communicated through ports on the digital node. A
library is provided to implement USB device functionality. Section 10
See page 19 for details of the USB. The PHY is just connected to Tiles 0 and 1, there is no dedicated USB hardware, although only Tiles 0 or 1 may be used.
This comes down a little to semantics, and the 'PHY' for HS USB has to be doing some bit-level helping, as well as the low voltage differential signaling.ie I cannot see SW doing bit stuff/destuff at 480MBd
That level of bit-level assist, is also suited to a P2/P1V
You are right.
I linked the wrong thing. The XMOS device I was thinking of is this one http://www.xmos.com/products/silicon/xa-seriesLoads of peripheral hardware in there.
I' think yo are right there. Ergo, so was I. Soft cores alone was perceived as insufficient.
Thanks for exploring this discussion. Sadly, there has been no "official" input on this in three pages of discussion and 1.5k of views, so it's probably pointless to explore this further. Perhaps I'm the wrong person to have brought the topic to the table with my recent offences to Parallax.
I'd better close this message before I say something stupid again..
http://forums.parallax.com/discussion/161545/propeller-1-2-3-fpga-board-60054-available-to-forum-members-375#latest