Quarter-Prop?
Skogsgurra
Posts: 231
I haven't read all 615 posts in the·"What do you want more of.." thread. So, this may have been covered before. Anyhow. It is something that may need to be discussed in a separate thread. Like this.
There are many applications where less would be more. A small, say DIP18, package is sometimes all you need and it would make a great peripheral processor. (BTW, that's how the·PIC processors started. They were just that - Peripheral Interface Computers - for the CA systems).
An 18 pin package would give you a full byte of GPIO plus the EEPROM, USB, XTL, BOEN, RESET·and Power connections. I am not so sure about the XTL, the RC clock would be OK for bit-banging and simple one-wire interfacing.·Which would make a DIP16 the natural choice. Do we always need the RESET and BOEN? Without them, and with the RC clock, we could have 12 GPIO in a DIP18.
Has this been discussed? Would it be a reasonable addition to the family? Thoughts?
Edit: Corrected "Peripheral Interface Computers"
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Post Edited (Skogsgurra) : 9/16/2007 5:19:11 AM GMT
There are many applications where less would be more. A small, say DIP18, package is sometimes all you need and it would make a great peripheral processor. (BTW, that's how the·PIC processors started. They were just that - Peripheral Interface Computers - for the CA systems).
An 18 pin package would give you a full byte of GPIO plus the EEPROM, USB, XTL, BOEN, RESET·and Power connections. I am not so sure about the XTL, the RC clock would be OK for bit-banging and simple one-wire interfacing.·Which would make a DIP16 the natural choice. Do we always need the RESET and BOEN? Without them, and with the RC clock, we could have 12 GPIO in a DIP18.
Has this been discussed? Would it be a reasonable addition to the family? Thoughts?
Edit: Corrected "Peripheral Interface Computers"
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Post Edited (Skogsgurra) : 9/16/2007 5:19:11 AM GMT
Comments
Cost, Performance, (Program-) Memory, Pins
Note those parameters are tightly coupled.
Parallax has trickily avoided the Program-Memory dimension by using an external EEPROM as well as by the bottle neck of the HUB RAM. On the other hand there is the option of a much wider performance scope than with most other architectures, where the choice is rarely more but: 8 Mhz Lowpower / 12 MHz standard / 20 MHz advanced, "tiny" or "mega" instruction set
So what one could wish for is
- low pin-out (for reduced real estate)
- low power (4 COGs, for reduced price)
- low price as such (whatever best suited; don't say: "Just buy 10,000")
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Even a "half-prop" would be useful, or maybe just the standard core with only a limited number of pins bonded.
Having said that, it kinda dilutes the per-device quantities and I'd guess would reduce the profit margins on the ultimate end products.
My ideal proto-tool used to be the PIC 16C876. 28 pin skinny dip. Never took up a lot of space, easy to work with and had enough IO for pretty much anything I used to do.
I'd have no problems paying current prop prices for a form factor like that, even given the need to supply external program memory.
I guess I just need to gear up for SMD work and make my own boards. That'd take a lot of the sting out of it as-is.
32KB HUB RAM: ?
COG (x8): ?
HUB-Logic: ?
32KB ROM: ?
Pin-Out (40p DIP): ?
it is often stated, that more cog ram makes no sense due to limited 9 Bit adresses. But, this is only true for immediate access, addressing via registers in the "normal" cog memory gives access to as much memory, as is available. A two level pointer structure wouldn't event limit the number of pointers, a single long in normal cog memory could hold the address of the first pointer in the expanded memory.
Such an solution should be great!
me to replace my asic library with propellers. This would go
over even better if they had a rom inside. Given I know they
are going to concentrate on bigger fish first.
Scott
(Chuck Moore's latest adventure in chipmaking; article does offer some basis upon which the propeller should be critiqued -- intercog communication and memory issues. See page 4, which does seem to be directed right here.)
Post Edited (Fred Hawkins) : 9/16/2007 4:04:47 PM GMT
He seems mostly concerned with dataflow issues, which - as we have learnt - can be a bottleneck...
High end DSPs (Shark, Blackfin,...) however still play in another league than the Prop...
It clarifies the huge difference between us bitbangers and you multimedia guys. We are happy if we can have a set of very fast processors and if we can get predictable performance. The memory acess is not an issue in most such applications. I think that the length of you-know-which thread is a result of that difference being poorly understood. The Prop (to me) is a mean bitbanging machine with some AV capability. And that is just fine (still my view).
The last part of the article mentions FORTH as a native machine language. Harris had a chip (the RTX 2000) that was based on that. It was a very clean design. And it packed up to four (IIRR) instructions in a 16 bit word. I won a design contest on that machine. It was very nice to use, but somewhat unstable (I think it was the development system, actually). I still have it in the attic. It did cost around USD 3000 at that time. Anyone interested?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Ditto on the propstamp, would be useful for lots of things but is too expensive (very possibly with good reason).
Graham
Even just 12 IO lines would be awesome if it was in a cheap/small package. Why bother changing anything. I'm definitely grasping here, but how possible would it be to take the current design and package it into a smaller pin count design with just leaving the unused pins not connected (hopefully they'd still be available from cog-to-cog communications)
I know resources are limited and need to be put where they reap the most benefit, but this would definitely be a huge plus to the propeller product line IMHO.
-Chad
and the cogs take up almost exactly half of the current die area, with the hub taking the rest(wish I could locate the die layout picture that was posted awhile back)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Parallax Forums - If you're ready to learn, we're ready to help.
Ah.. A man can dream...
A 2COG would be easy to use as a 'buffering protocol changer', going between RS232/SPI/I2C and so on...
It could also be used for datalogging and transmitting, without the need to stop logging while doing the transmission. With 8 I/O-pins it should be possible to get it into a 16 or 18 pin package.
While a 2COG chip may be able to generate a Video signal, it doesn't have much 'spare' capacity to do image processing, a 4COG would make a decent 'graphics subsystem' Stick it with 16 I/O-pins and it should fit into a 24pin package. IT should also work well as a general sub-processor, network hub(serial or whatever), datalogging with interpretation. Of course, this probably won't be much cheaper or smaller than the normal 8COG model, so the economic viability is rather low.
Then there's the question of COG/HUB timing. Should the Round-robin HUB-access scheme be adapted so that the slots come more often, or should it be kept at the same 'access every 16 clock ticks' pace to keep compatibility with existing code?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Don't visit my new website...
Without conditional compilation or, better still, ability to determine type of chip being executed upon, differences will cause a nightmare for object re-use and in porting code prototyped on a larger chip ( using on-chip logic analysers, VGA/TV for debugging and other gizmo's ) to a smaller one.
I think any debate on scaling-down is as difficult as that on scaling up. Some people will want huge processing power but need few pins, others will need more pins but not so much processing power. My pragmatic approach would be; same as what we have, just less pins connecting to silicon die. Drop BOE, just one power pin etc, yes, but otherwise 'the same insides'
The same too for any 'fancy improvements'; across the board or not at all.
Apart from the debate on how many legged variants, the lack of variants is one of the big advantages I see.