What about the posibility of a smaller package ( TQFP32 )?· I could use the processing power but need a physically smaller footprint.· Don't always need that much I/O.
I broke down and registered so I could get a look at the SEAForth24 documentation. (hardly have to give them any info to be "registered") They've released the data sheet for the 24A chip. The data sheet and the descrition of the instruction set on the web-site give a much better idea of the architecture of the chip.
The instruction set is simple to the extreme on this chip. For math instructions it has a Not, Shift-left, Shift-right, Add, and Shift-add. Add and Shift-add are two-cycle instructions to give time for carry bits to move a full 18-bits. The shift-add instruction allows "fast" multiplies to be done, just repeat the instruction once for each bit multiplied. (this only give the low 18-bits of the result) The rest of the instructions are flow control, stack management, and data movement instructions. Heh, it's no wonder that the chip can crank through 2 billion instructions per second per core, there's hardly anything to a core!
yea, the 18-bit thing seems odd to me too. Why not 16-bit or 32-bit? I'm guessing the 18-bit thing came from 2 x (8-bit + parity-bit).
I do LIKE how the cores of a SEAForth chip handle core-core transfers. The automatic waiting for data is nifty.
So in my opinion, the SEAForth is a very powerful chip but it won't be easy to program. The Forth complier will help, but the core interconnect setup forces an extra layer of complexity on the coder. (but that same interconnect will allow the chip to scale well to more cores)
I'll stick with the Prop for future projects [noparse]:)[/noparse]
Marty Lawson
I'm a doctor not an engineer... I am interested in the next generation of smart weapons. I don't care if the next generation propeller has 8 cogs or 16... I don't care how much memory it has... the only thing I care about is that it is as completely discussed and documented as the current version.
I cannot tell you how much I enjoy simply following this forum. I started looking at the propeller because I thought I might be able to implement a vision algorithm... that is important to me ... at the machine level. No go-> memory management probs. But... I have always wanted to understand exactly what it is that you are go gloriously explaining in a context that would be useful...
What I really want is a propeller on an FPGA that does anything remotely interesting... fully documented... with a place to go to asks questions that is as glorious as this forum.
Congratulations to the entire Parallax team and to everyone who posts simple questions here.
I have looked into the SEAforth chips, and didn't really understand them until I started watching the movies at http://www.ultratechnology.com/rmvideo.htm.
I learned alot about George Moore and his bent toward simpler computing.....kinda reminded me of Chip Gracy in that way. I still don't understand the 18bit thing, you would think that with 5 bit instructions and the abililty to load them several at a time( depending on the width of your data bus) the databus would be a multiple of 5bits, but no
I don't get it. Anyway, I really do like the Transputer like communication mechanism.....really slick and scalable, and all of the SPI interfaces of the B version, but the thing looks like a real beast to program. I too will stick with the propeller for my current projects, and hopefully prop2 for the future ones. I like assembly, and enjoy having a full 32 bits, and 64 or so useful instructions. I would REALLY also like a single cycle hardware multiplyer Hint Hint!. Another cool thing about the propeller is that it is small enogh, and sips power, so I can even use it for battery run unattended applications run off a capacitor or small battery... just turn the clock to RCSlow and WaitCNT to lower power while sleeping. If I need more power, I would just tie another one in (though I haven't figured out how to boot a prop from a prop)
·Um a forethough here, would it be economically and physically feasable to include the EEPROM right on the new chip? Could a dedicated data bus also be included so that multiple Propellers could communicate faster with one another in a multi-Prop application?· I know, ignorance is bliss, lol.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Definetly a E3 (Electronics Engineer Extrodinare!)
"I laugh in the face of imposible,... not because i know it all, ... but because I don't know well enough!"
RinksCustom,
This has been discussed at length earlier in this thread. It's not physically feasable to include EEPROM on the new chip. I believe the biggest problem is the "process" needed for EEPROM is different from the "process" intended for the processor. The reason why a dedicated data bus was not included is chip area. Any time you bring signals off chip, you need physically large and relatively power hungry I/O pin drivers. The trade-off in terms of chip area just isn't considered "worth it". For inter-prop communications, you can always allocate a block of I/O pins, particularly in a 64 I/O pin package.
This was buried on Chuck Moore's website (www.colorforth.com), concerning Forth processors he developed:
X18
Recently, I realized the potential of .18um technology and designed an 18-bit computer to match available fast SRAM. It is even more aggressive, using dynamic latches, and has on-chip ROM and DRAM to sustain 2400 Mips. Its small size and on-chip memory leads to the 25x with multiple computers on the same die.
Chip managed to fit a very efficient SPIN interpreter into that.
Others have managed BASIC and FORTH interpreters.
Sure, having more RAM would be nice some times, but that would mean that they'd have to change the structure of the assembler commands, and that can be rather... messy...
Besides, if you want the speed of assembler, but also to use larger programs, search the forum for 'large memory model' thread, also mentioned earlier in this thread...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Don't visit my new website...
I registered at SeaForth and took a look. As far as I could see, the most significant difference between the Propeller and the SeaForth implementation isn't in the hardware... true, the bandwidth diffs are there... true there are applications, which I can easily see that could be implemented on the SeaForth and where the instruction set limits are a perfect match... so for that kind of implementation, there is no question that SeaForth could handle those problems more efficiently in a carbon neutral sort of way. But, in my mind the issue doesn't boil down to the instruction set or bit depth... the real difference is in the business philosophy. There is plenty of room for both philosophies... and both chips... IBM has the Cell architecture and what looks like a similar business philosophy; I would think that the most appropriate comparison would be between those architectures and business models.
I didn't see a forum like this at the SeaForth site.
And IBM is not exactly welcoming the home-brew crowd to the world of cell processing. Yes, you can buy a PlayStation3 and yes you can learn to program it... but if you want to do anything really interesting... that requires you to go to IBM... and so far... that gets you into the stratosphere in terms of development costs and probably depends upon the number of engineers/sq. inch that you have available to get anything like a response from IBM/Sony et al.
I didn't try... so I could be wrong... but that's the way it looks to me.
Does SeaForth have anything like the flexible clocking or facile counter architecture that comes with a $12 propeller?
Does IBM have an evaluation platform for $79 for the cell architecture?
I want Parallax to build the chip that Chip wants... and ignore the rest of us.
scotta,
There was a great deal of discussion when the Propeller first came out about copy protection and how easy it is to break, even when you've got a OTP ROM on-chip. That may cause a casual hacker to spend their time with someone else's system, but won't stop a determined, well equipped thief and there are other ways to discourage a casual hacker.
There already is a D/A & A/D capability on each I/O pin (pair of pins for A/D) using a couple of external passive components. The on-chip circuitry is going to be improved to reduce noise and increase performance for the A/D conversion particularly.
More than 512 longs per cog isn't going to happen. It's hard-wired into the instruction set. The cogs were not intended for large programs, but for small, very fast I/O driver type functions with SPIN the glue that binds them together. Bill Henning's Large Model scheme provides a very nice intermediate speed mechanism and it looks like this will be supported by a C compiler "sometime soon" from ImageCraft.
I half expect someone to pop up and say... "Yes, but their copy protection is encrypted."
So, before anyone says it... please let me respond... that won't work either. All you have to do is manage your data stream... make your correlations and deduce the schema. And that is where bit depth really does matter.
After looking at the SeaForth24 processor line, and looking at how they cores communicate, I have network register envy. A network register between adjoining props would solve the hub bandwidth handily. I don't know easily this would be handled in the instruction set, but I would guess that 4 longs, North, South, East, and West. could be added to the dedicated cog registers. A 4x4 array of cogs would still have the hub, but you could also use this alternate communication meathod between the cores. It looks pretty nifty!.
The more I listened to Chuck Moore, the more I understand his wa of thinking. I am still not a fan of the Minimal Instruction Set, or a forth programmer, but I do like his idea of computing outside of windows or other complex OS. Chip was talking about having this, and developing/running right on the prop. I, for one, would welcome such a platform, as long as I can still tie it into other platforms via Network or Serial.
Was sure hoping that Parallax had some comments on the 2nd Generation of the Propeller. Guess they are way too busy (from Army days, "elbows and a**holes").
Sure would like to hear what the official name is for the next wonderful Prop.
Comments
pjr
The instruction set is simple to the extreme on this chip. For math instructions it has a Not, Shift-left, Shift-right, Add, and Shift-add. Add and Shift-add are two-cycle instructions to give time for carry bits to move a full 18-bits. The shift-add instruction allows "fast" multiplies to be done, just repeat the instruction once for each bit multiplied. (this only give the low 18-bits of the result) The rest of the instructions are flow control, stack management, and data movement instructions. Heh, it's no wonder that the chip can crank through 2 billion instructions per second per core, there's hardly anything to a core!
yea, the 18-bit thing seems odd to me too. Why not 16-bit or 32-bit? I'm guessing the 18-bit thing came from 2 x (8-bit + parity-bit).
I do LIKE how the cores of a SEAForth chip handle core-core transfers. The automatic waiting for data is nifty.
So in my opinion, the SEAForth is a very powerful chip but it won't be easy to program. The Forth complier will help, but the core interconnect setup forces an extra layer of complexity on the coder. (but that same interconnect will allow the chip to scale well to more cores)
I'll stick with the Prop for future projects [noparse]:)[/noparse]
Marty Lawson
I'm a doctor not an engineer... I am interested in the next generation of smart weapons. I don't care if the next generation propeller has 8 cogs or 16... I don't care how much memory it has... the only thing I care about is that it is as completely discussed and documented as the current version.
I cannot tell you how much I enjoy simply following this forum. I started looking at the propeller because I thought I might be able to implement a vision algorithm... that is important to me ... at the machine level. No go-> memory management probs. But... I have always wanted to understand exactly what it is that you are go gloriously explaining in a context that would be useful...
What I really want is a propeller on an FPGA that does anything remotely interesting... fully documented... with a place to go to asks questions that is as glorious as this forum.
Congratulations to the entire Parallax team and to everyone who posts simple questions here.
Rich
I have looked into the SEAforth chips, and didn't really understand them until I started watching the movies at http://www.ultratechnology.com/rmvideo.htm.
I learned alot about George Moore and his bent toward simpler computing.....kinda reminded me of Chip Gracy in that way. I still don't understand the 18bit thing, you would think that with 5 bit instructions and the abililty to load them several at a time( depending on the width of your data bus) the databus would be a multiple of 5bits, but no
I don't get it. Anyway, I really do like the Transputer like communication mechanism.....really slick and scalable, and all of the SPI interfaces of the B version, but the thing looks like a real beast to program. I too will stick with the propeller for my current projects, and hopefully prop2 for the future ones. I like assembly, and enjoy having a full 32 bits, and 64 or so useful instructions. I would REALLY also like a single cycle hardware multiplyer Hint Hint!. Another cool thing about the propeller is that it is small enogh, and sips power, so I can even use it for battery run unattended applications run off a capacitor or small battery... just turn the clock to RCSlow and WaitCNT to lower power while sleeping. If I need more power, I would just tie another one in (though I haven't figured out how to boot a prop from a prop)
Doug
for you guys that understand csh
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Definetly a E3 (Electronics Engineer Extrodinare!)
"I laugh in the face of imposible,... not because i know it all, ... but because I don't know well enough!"
This has been discussed at length earlier in this thread. It's not physically feasable to include EEPROM on the new chip. I believe the biggest problem is the "process" needed for EEPROM is different from the "process" intended for the processor. The reason why a dedicated data bus was not included is chip area. Any time you bring signals off chip, you need physically large and relatively power hungry I/O pin drivers. The trade-off in terms of chip area just isn't considered "worth it". For inter-prop communications, you can always allocate a block of I/O pins, particularly in a 64 I/O pin package.
X18
Recently, I realized the potential of .18um technology and designed an 18-bit computer to match available fast SRAM. It is even more aggressive, using dynamic latches, and has on-chip ROM and DRAM to sustain 2400 Mips. Its small size and on-chip memory leads to the 25x with multiple computers on the same die.
Chip managed to fit a very efficient SPIN interpreter into that.
Others have managed BASIC and FORTH interpreters.
Sure, having more RAM would be nice some times, but that would mean that they'd have to change the structure of the assembler commands, and that can be rather... messy...
Besides, if you want the speed of assembler, but also to use larger programs, search the forum for 'large memory model' thread, also mentioned earlier in this thread...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Don't visit my new website...
I didn't see a forum like this at the SeaForth site.
And IBM is not exactly welcoming the home-brew crowd to the world of cell processing. Yes, you can buy a PlayStation3 and yes you can learn to program it... but if you want to do anything really interesting... that requires you to go to IBM... and so far... that gets you into the stratosphere in terms of development costs and probably depends upon the number of engineers/sq. inch that you have available to get anything like a response from IBM/Sony et al.
I didn't try... so I could be wrong... but that's the way it looks to me.
Does SeaForth have anything like the flexible clocking or facile counter architecture that comes with a $12 propeller?
Does IBM have an evaluation platform for $79 for the cell architecture?
I want Parallax to build the chip that Chip wants... and ignore the rest of us.
There was a great deal of discussion when the Propeller first came out about copy protection and how easy it is to break, even when you've got a OTP ROM on-chip. That may cause a casual hacker to spend their time with someone else's system, but won't stop a determined, well equipped thief and there are other ways to discourage a casual hacker.
There already is a D/A & A/D capability on each I/O pin (pair of pins for A/D) using a couple of external passive components. The on-chip circuitry is going to be improved to reduce noise and increase performance for the A/D conversion particularly.
More than 512 longs per cog isn't going to happen. It's hard-wired into the instruction set. The cogs were not intended for large programs, but for small, very fast I/O driver type functions with SPIN the glue that binds them together. Bill Henning's Large Model scheme provides a very nice intermediate speed mechanism and it looks like this will be supported by a C compiler "sometime soon" from ImageCraft.
I half expect someone to pop up and say... "Yes, but their copy protection is encrypted."
So, before anyone says it... please let me respond... that won't work either. All you have to do is manage your data stream... make your correlations and deduce the schema. And that is where bit depth really does matter.
Rich
What would you want more of, cogs or RAM? subject.
Wondering if there is any 'progress report' for us restless Prop-heads?
Has it been named yet? Prop II, Full Prop, Prop64, etc?
Might it be known yet whether it will be a 8 or 16 cog? (Sure hoping 16)
Packaging?
ETA still on schedule?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Harley Shanko
h.a.s. designn
The more I listened to Chuck Moore, the more I understand his wa of thinking. I am still not a fan of the Minimal Instruction Set, or a forth programmer, but I do like his idea of computing outside of windows or other complex OS. Chip was talking about having this, and developing/running right on the prop. I, for one, would welcome such a platform, as long as I can still tie it into other platforms via Network or Serial.
TurboProp?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
I stand on the shoulders of giants
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
'Necessity is the mother of invention'
Post Edited (QuattroRS4) : 3/7/2007 2:40:35 PM GMT
Can't wait for the WarpDriveProp!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
I stand on the shoulders of giants
Sure would like to hear what the official name is for the next wonderful Prop.
And any other 'good words' on it.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Harley Shanko
h.a.s. designn
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer
Parallax, Inc.
Thought a guesstimate on the forum some months ago was 'about a year'.
Much more patience, huh?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Harley Shanko
h.a.s. designn
Like I said 2 years is the conservative estimate, it will likely be between 1 and 2 years.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer
Parallax, Inc.