I agree with Bean's comments. I'd like to support the Prop II with Catalina (some parts of Catalina were designed specifically with Prop II features in mind).
I just hope Parallax realizes how much lead time we will need. From having a finalized instruction set to having solid and reliable third-party tool support may take many months (depending - of course - on how extensive the changes are!).
I'd hate to see the Prop II launched to great fanfare and much acclaim, only to see it languish while the various third-party software suppliers (free and commercial) scramble to catch up.
However, like Cluso, I'm fairly confident this will not happen, and that Parallax wil start releasing solid information soon.
I've been thinking about this list. Here's the thinking (my port assignments) on the pins and power (my assumed distribution):
Item #pins
-------+--
Port A 32
Port B 32
Port C 20
Port D 8
Xtal 2
Reset 1
BOE 1
-------+--
Subtotal 96
128 pin SMT package
- 96 pins above
------
32 for power/ground
1.8v 4 or 8
3.3v 12 or 8
Gnd 16
----------
32 check!
I created a PCB part for it, at the time. I split it up into eight gates for the eight groups of I/Os with their supplies, one for the clock etc. and one for the power and ground connections.
I would go with something closer to the attached image here...
Leon,
If you created the PCB part based on the 100 pin image, you'll need to revise the part.
Note: in the attached image all of the IO/s should be correct, however there is some 'flux' as to the correct order of the power/ground... in other words, they are generally in the correct position, but they could be swapped.
In regards to the couple posts about a DIP40 compatible version of the Prop2, that is a piece of cake. PCB cost may be a concern, but depending on the final choices of SMT packages that the 128 pin Prop2 comes in, creating an adapter PCB will not be an issue. My M44D40+ module can be used simply as a propeller QFN to DIP 40 adapter when you only load the QFN and headers. Doing the same with a larger SMT package only means that the headers need to be surface mount and on the bottom side so that the chip can have it's room. The nice thing is that the "oversized DIP40 PCB" will have room for the 1.8v circuit to make it truly Prop1 DIP40 compatible. Snapshot attached shows a QFP128 on a DIP40 pattern just to get the idea of how oversized the adapter PCB would need to be if that is the chosen package. Obviously a QFN, BGA, or LGA package would suit an adapter much nicer.
I helped with a design for a similar adapter board a few years ago for a 44 pin QFP that ended up in a DIP 32 socket. It was for a legacy product with a heavy amount of field units. The original DIP32 part was obsoleted and a new board design was created with a QFP44. However, to support field units, an adapter was a better option then telling a customer they had to purchase a new unit. The adapter PCB was almost twice the width of the DIP32, but worked out nicely. Top side had the QFP44, some bypass caps, and other basic support circuitry. The bottom side had surface mount headers with 0.018 diamter pins that fit perfectly into the legacy boards' DIP32 socket.
Helps when one knows the 'language'. Don't think this ancient engr. would have guessed that for a long time. That makes much more sense.
I suppose the actual port pins will be assigned later as the Prop 2 full silicon layout is done? (My thinking here is there might be Ports An, Bn, Cn and maybe a Dn for the full I/O assignments, where 'n' is from 8 to 32 (better yet, 0..7 up to 0..31).
We were talking about how the different "Ports" or blocks of 32 pins would be accessed. I would think it wouldn't be too far out of Chip's/Beau's reach to make it possible to have all I/Os accessible directly by the number. So we just have OUT (no A or B or C). And in the [] we have a range between 0 and 91. If the registers are aligned, I think this could work. It may be similar to accessing an array of longs with .byte[x], it just overflows to the next long. It may only be directly an option in SPIN, but if it can be done in SPIN, it can be done [at least] indirectly in PASM.
Is this even remotely possible? This would make writing object and software in general so much easier. If it is done just by calling OUTA/B/C it makes object a lot less portable. You would have to go through the entire object and change all the pin calls to the port letter you are working with.
Maybe it could be done with a nested array like DIRA[2][31] this would affect the second port's P31.
If the ports are not ID'd with Port A ... D type labeling it might be sometimes confusing in Prop 2 programming to account for 32-bit variable bits vs. I/O 'pins' running from P0..P91.
Presently in Prop 1 we have 32 I/O and 32-bit variables/registers. If the second and later I/O ports were further labeled in alphabetic letters (B, C, D, etc.) if might be more convenient to think of or account for the bit positions.
Anyway, it is Parallax's call. Would have been nice if this was already nailed down. I still think it might depend on silicon layout routing. Hopefully the labeling can remain 'unscrambled' as Beau has indicated. 'Nuf said'.
If I remember correctly, the Zener breakdown voltage is about 7V ... 5V is living in dangerous territory with that considered.
The process is designed to accept 1.8V and 3.3V comfortably.
As it has been indicated, the core voltage is 1.8V period, no if and's or buts. The I/O's can be configured in groups of 8 to have anywhere from 1.8V to 3.3V ... in a way they 'ARE' level shifters. Suppose you dedicate one group of 8 for 3.3V, another for 2V, and another for 2.5V ... Yup!! all three could live happily as long as those voltages stayed true to each group of 8 that were configured that way.
Ohh, and the Voltage configuration is done external in hardware based on what you supply to the Power for each group. - All grounds are the same, GIO and GND are 'locked' together within one diode drop by two parallel back to back diodes, so there is 'some' noise immunity between GIO and GND.
Incredible! Video, math and memory upgrades are going to be VERY worth the wait! Suppose we can get the hardware gods here to create a "C4" creation which will replace my power hungry PC's with Propeller based systems?
Sapieha,
"Will it be possible with that waveform generators be possible to generate 3-phase waves" - Another function of the DAC output, this type of output control should be very easy to accomplish.
So that means a single COG + Dual Counter [32 bit? 40 bit? ], can create the 6 Gate drive signals typically needed for a 3 phase bridge ?
- and can it also support fast current limiting.
The better Timer/PWM modules, have hardware Pulse-abort pins, for over current limiting.
Another timer detail question:
Q: Can the two timers/COG, be configured for Reciprocal Counting ?
This is not complex, but too often overlooked, in chips.
One timer captures a fast timebase (160MHz+prescaler)), when driven from the OTHER timer overflow output. That other timer, is used as a simple Pin-Divider.
ie it takes a user-CLK-pin, and divides by 1..2^N, user selectable.
So you need :
** Capture of one Fast Timebase timer, on Overflow event of other timer.
(clear-on-capture is optional)
** Divide by N from a Pin
( this could include a non sampled pin prescaler divider, to allow highest possible
pin rates, without needing highest MHz on Core.)
Frequency is Cycles/time, so
f = [PinDividerSetValue]/([TimeCaptureValue]*ClkPeriod) or
f = ClkFrequency* [PinDividerSetValue]/([TimeCaptureValue]) or
The Timebase timer, should run as fast as silicon can support.
That might be < 160MHz for reliable 32 bit count and capture on the fly ?
If the timers cannot get to 160MHz, then a split PLL output /N (2?) to 160MHz,
and /3 to give 100MHz timers could be workable ?
Anyways, Why can't the propeller access the SDRAM for code? 128KB of Ram won't be enough. you got eight cogs on board, thats 16KB code space per cog if equally shared. (However it's more than the prop I with 4 KB per cog )
Please at least have SDRAM code access for SPIN 2, even if it has to use another cog. Bring the problem to light and maybe the community could workout a idea.
Form Factor: I Appreciate more pins, However a DIP package might be better for prototyping and then a SMT package could be used for production/more stable designs. I wouldn't mind a dip package with 128 pins
Performance: Awesome... 1.28 BIPS...
Math: Why do we need a CORDIC system if we have hardware Multipliers/Dividers?
I/O Features: Great, Shouldn't change a thing (Except if your adding more ) However, will the ADC/DAC be 32 bit?
Each COG will get 2K code space. 512 instructions. That space is not part of the main HUB memory, currently targeted at 128KB.
COGs only execute code directly from their local memory. When a COG is started, the local memory is copied from the HUB to the COG, then code execution begins. Prop I also has 2K code space per COG, as the design is the same in that respect.
It is possible to fetch code from storage, fire off a COG, then use that HUB memory for something else.
Personally, I think the 128KB is too small, but too small for data, not code. Lots of streaming from external memory could impact the parallelism, but we don't have chips or full instructions yet, so... maybe it's not a worry at this point.
SPIN could be modifed to run from the external RAM, and it's highly likely the community will do this. We've already done a lot of work with LMM and XMM code execute models, both of which will be improved on Prop II.
(LMM is the fetching of PASM code from the HUB, then running it in the COG inside a small supervisor kernel. XMM is doing the same from a storage outside the Propeller.
Potatohead said... COGs only execute code directly from their local memory. When a COG is started, the local memory is copied from the HUB to the COG, then code execution begins. Prop I also has 2K code space per COG, as the design is the same in that respect.
Well, not strictly true in the sense that the Spin code is in hub so it could be a full 128KB. But the interpreter itself is in cog and executes within that 2K limit. With the extensions of Spin LMM it maybe that the new interpreter for the Prop II may also use some LMM code which could in fact be within the ROM.
As for a DIP package - forget it as it will never happen! (This is one time I feel confident I can say it cannot be done and not expect to eat a prop ). Can you imagine a 128pin DIP? Someone would have to put up a lot of cash to make a DIP 128 package.
I used to work with 64pin QUIP (two rows each side of the package offset by 0.1" and stagered at 0.05"). They were modem chips made by Rockwell in the late 80's. They were very fragile pins and we had more problems with sockets than we did with the rest of the circuits.
Will it be possible with that waveform generators be possible to generate 3-phase waves for industrial 3-phase MOTOR control in one COG/generator --> And if possible even with simultaneously controlling its amplitude. If not that will be not so usable in industry
First of all, there is no reason why you can't use 3 COGs for that. COGs are there for a reason, you pay for them -- may as well use them. Or you may use a CORDIC, I just don't know if there's one CORDIC per pin or per COG. This is all if you are up for plain-jane PWM output, which may not be all that great. PWM has rich harmonic content and is not cheap to filter EMI from -- when compared, say, to magic sinewaves. If you're driving many kilowatts into a 3 phase motor (induction or brushless), the EMI filters don't come cheap.
Personally I'd dedicate one COG to do a table-lookup-based 3-phase magic sinewave output. I don't know what's your target amplitude resolution, that would affect the table size. Even on current Propeller doing a 3-phase CORDIC PWM running at a couple kHz for 3 phases isn't that big of a deal -- you can very comfortably fit two phases onto one COG.
As for a DIP package - forget it as it will never happen! (This is one time I feel confident I can say it cannot be done and not expect to eat a prop ). Can you imagine a 128pin DIP? Someone would have to put up a lot of cash to make a DIP 128 package.
I used to work with 64pin QUIP (two rows each side of the package offset by 0.1" and stagered at 0.05"). They were modem chips made by Rockwell in the late 80's. They were very fragile pins and we had more problems with sockets than we did with the rest of the circuits.
I, for one, would be perfectly happy with a DIP-40 with the same pinouts as the current chip... if that's possible. In other words, a drop-in replacement with more ram and faster cogs.
Yes, it would not have the additional I/O's...externally. But they could still be used for inter-cog communication...
jazzed:
SDRAM does not need some special support, it is to simple of an interface. It can be done by any programmer so simply, on any microcontroller that supports dynamic use of IO pins, that I do not understand what could be implemented in HW that could be helpful for this. In sum: the prop supported SDRAM the first day it functioned. My question was what HW is added that could possibly make accessing SDRAM any simpler than it already is. It is already easier than I2C or SPI.
david: The simple fact is we want the SDRAM running at the prop clock speeds. We are not happy to slow it down by pulsing the pins with out software. Jazzed has already done that on the Prop. I have SRAM running, etc. But one of our prop I problems is a lack of pins.
What could be included to ease the use of SDRAM? I have used SDRAM in many a project and have not had any difficulty. Hou could it be any easier?
On a traditional micro-processor system all code and data lives off the CPU chip, in RAM, EPROMS, ROMS and such. Think about your PC for example. (OK it has huge on chip cache now a days but never mind).
The processor has a hardware bus interface. That interface takes care of putting out addresses on the address bus, reading/writing data on the data bus and wiggling the appropriate READ/WRITE and other control signals for the bus. The programmer does not need to know how any of this works. It works fast.
On a micro-controller like the Prop there is no such dedicated memory bus hardware. One has to write software to drive the general purpose I/O pins and create memory accesses. It is slow. Code cannot be executed directly from such memory at the full speed of the CPU.
So clearly hardware could be added to the Prop to help speed this up. Imagine having instructions like RDBYTE/WRBYTE that instead of working on HUB RAM automatically generated the bus signals required to access external memory devices. Or what about block reading/writing at high speed. And so on.
Of course the simplest form of external memory support is just to have more I/O pins to drive it.
SDRAM is also available for the PropellerPlatform today and can be used with Zog C/C++.
The P2 feature list that you liked to is confusing. It says that the P2 will have support for external SDRAM but that code cannot be executed from SDRAM. What does that mean? Does that mean simply that you can't point the COG PC at SDRAM and have it execute or does it mean that even RDBYTE/WRBYTE, etc won't work with SDRAM? Interpreters like Spin and ZOG and LMM would even benefit from extending the RD/WR instructions with the ability to address external SDRAM if it was possible to dedicate part of hub memory as a cache. I've worked with processors that allowed some of their local memory to be used as a cache into a larger external address space and it worked quite well. Any idea of Parallax is planning something like that for P2?
I think it means that you do not have to bit-bang the interface to read/write the SDRAM. A couple of opcodes maybe provided for that... and maybe refresh will occur automatically after any access. For it to be part of HUB it should be synchronized to the clock and be 32 (128) bits wide and well it is just not possible as it is. think of the transfer of 4 longs at the same time scenario and every clock !. Have a look at the datasheet of a SDRAM and you will see that you have to load address/command and then read...3 or 4 clock will be needed for each access. A synchronous SRAM would be another story...
Comments
I just hope Parallax realizes how much lead time we will need. From having a finalized instruction set to having solid and reliable third-party tool support may take many months (depending - of course - on how extensive the changes are!).
I'd hate to see the Prop II launched to great fanfare and much acclaim, only to see it languish while the various third-party software suppliers (free and commercial) scramble to catch up.
However, like Cluso, I'm fairly confident this will not happen, and that Parallax wil start releasing solid information soon.
Ross.
92 I/Os
8 VP0-7 power 1 per 8 I/Os (1.8v - 3.3v)
8 GP0-7 grounds 1 per 8 I/Os
8 VDD 1.8v Core power
8 GND
1 RESn Reset
2 XTAL Clock
1 BOEn Brown Out
That diagram only shows a 100 pin package.
I would go with something closer to the attached image here...
Leon,
If you created the PCB part based on the 100 pin image, you'll need to revise the part.
Note: in the attached image all of the IO/s should be correct, however there is some 'flux' as to the correct order of the power/ground... in other words, they are generally in the correct position, but they could be swapped.
I helped with a design for a similar adapter board a few years ago for a 44 pin QFP that ended up in a DIP 32 socket. It was for a legacy product with a heavy amount of field units. The original DIP32 part was obsoleted and a new board design was created with a QFP44. However, to support field units, an adapter was a better option then telling a customer they had to purchase a new unit. The adapter PCB was almost twice the width of the DIP32, but worked out nicely. Top side had the QFP44, some bypass caps, and other basic support circuitry. The bottom side had surface mount headers with 0.018 diamter pins that fit perfectly into the legacy boards' DIP32 socket.
What is the VPn pins? Appears to be a 12-pin port. Or is that for 3.3v and VDD for 1.8v?
I'd guess the actual ports, that is 32 I/O port A and 'B' is part of the Pn assignments?
GP = general purpose I/O?
GP = grounds for I/Os
VDD = 1.8v Core power
GND = core power ground
Helps when one knows the 'language'. Don't think this ancient engr. would have guessed that for a long time. That makes much more sense.
I suppose the actual port pins will be assigned later as the Prop 2 full silicon layout is done? (My thinking here is there might be Ports An, Bn, Cn and maybe a Dn for the full I/O assignments, where 'n' is from 8 to 32 (better yet, 0..7 up to 0..31).
Is this even remotely possible? This would make writing object and software in general so much easier. If it is done just by calling OUTA/B/C it makes object a lot less portable. You would have to go through the entire object and change all the pin calls to the port letter you are working with.
Maybe it could be done with a nested array like DIRA[2][31] this would affect the second port's P31.
Presently in Prop 1 we have 32 I/O and 32-bit variables/registers. If the second and later I/O ports were further labeled in alphabetic letters (B, C, D, etc.) if might be more convenient to think of or account for the bit positions.
Anyway, it is Parallax's call. Would have been nice if this was already nailed down. I still think it might depend on silicon layout routing. Hopefully the labeling can remain 'unscrambled' as Beau has indicated. 'Nuf said'.
At the 09 UPEW I asked Chip the 5V compatibility question and he
said the process they are using for Propeller 2 is only good for 3.5
volts or so.
If I remember correctly, the Zener breakdown voltage is about 7V ... 5V is living in dangerous territory with that considered.
The process is designed to accept 1.8V and 3.3V comfortably.
As it has been indicated, the core voltage is 1.8V period, no if and's or buts. The I/O's can be configured in groups of 8 to have anywhere from 1.8V to 3.3V ... in a way they 'ARE' level shifters. Suppose you dedicate one group of 8 for 3.3V, another for 2V, and another for 2.5V ... Yup!! all three could live happily as long as those voltages stayed true to each group of 8 that were configured that way.
Ohh, and the Voltage configuration is done external in hardware based on what you supply to the Power for each group. - All grounds are the same, GIO and GND are 'locked' together within one diode drop by two parallel back to back diodes, so there is 'some' noise immunity between GIO and GND.
Propeller 2 is going to be a 'beauty' with all its features. And Parallax lets us in on its development. Wow!
OBC
So that means a single COG + Dual Counter [32 bit? 40 bit? ], can create the 6 Gate drive signals typically needed for a 3 phase bridge ?
- and can it also support fast current limiting.
The better Timer/PWM modules, have hardware Pulse-abort pins, for over current limiting.
Another timer detail question:
Q: Can the two timers/COG, be configured for Reciprocal Counting ?
This is not complex, but too often overlooked, in chips.
One timer captures a fast timebase (160MHz+prescaler)), when driven from the OTHER timer overflow output. That other timer, is used as a simple Pin-Divider.
ie it takes a user-CLK-pin, and divides by 1..2^N, user selectable.
So you need :
** Capture of one Fast Timebase timer, on Overflow event of other timer.
(clear-on-capture is optional)
** Divide by N from a Pin
( this could include a non sampled pin prescaler divider, to allow highest possible
pin rates, without needing highest MHz on Core.)
Frequency is Cycles/time, so
f = [PinDividerSetValue]/([TimeCaptureValue]*ClkPeriod) or
f = ClkFrequency* [PinDividerSetValue]/([TimeCaptureValue]) or
The Timebase timer, should run as fast as silicon can support.
That might be < 160MHz for reliable 32 bit count and capture on the fly ?
If the timers cannot get to 160MHz, then a split PLL output /N (2?) to 160MHz,
and /3 to give 100MHz timers could be workable ?
Thanks!
Anyways, Why can't the propeller access the SDRAM for code? 128KB of Ram won't be enough. you got eight cogs on board, thats 16KB code space per cog if equally shared. (However it's more than the prop I with 4 KB per cog
Please at least have SDRAM code access for SPIN 2, even if it has to use another cog. Bring the problem to light and maybe the community could workout a idea.
Form Factor: I Appreciate more pins, However a DIP package might be better for prototyping and then a SMT package could be used for production/more stable designs. I wouldn't mind a dip package with 128 pins
Performance: Awesome... 1.28 BIPS...
Math: Why do we need a CORDIC system if we have hardware Multipliers/Dividers?
I/O Features: Great, Shouldn't change a thing (Except if your adding more
I can't wait for the sample/production devices.
COGs only execute code directly from their local memory. When a COG is started, the local memory is copied from the HUB to the COG, then code execution begins. Prop I also has 2K code space per COG, as the design is the same in that respect.
It is possible to fetch code from storage, fire off a COG, then use that HUB memory for something else.
Personally, I think the 128KB is too small, but too small for data, not code. Lots of streaming from external memory could impact the parallelism, but we don't have chips or full instructions yet, so... maybe it's not a worry at this point.
SPIN could be modifed to run from the external RAM, and it's highly likely the community will do this. We've already done a lot of work with LMM and XMM code execute models, both of which will be improved on Prop II.
(LMM is the fetching of PASM code from the HUB, then running it in the COG inside a small supervisor kernel. XMM is doing the same from a storage outside the Propeller.
Well, not strictly true in the sense that the Spin code is in hub so it could be a full 128KB. But the interpreter itself is in cog and executes within that 2K limit. With the extensions of Spin LMM it maybe that the new interpreter for the Prop II may also use some LMM code which could in fact be within the ROM.
As for a DIP package - forget it as it will never happen! (This is one time I feel confident I can say it cannot be done and not expect to eat a prop
I used to work with 64pin QUIP (two rows each side of the package offset by 0.1" and stagered at 0.05"). They were modem chips made by Rockwell in the late 80's. They were very fragile pins and we had more problems with sockets than we did with the rest of the circuits.
Personally I'd dedicate one COG to do a table-lookup-based 3-phase magic sinewave output. I don't know what's your target amplitude resolution, that would affect the table size. Even on current Propeller doing a 3-phase CORDIC PWM running at a couple kHz for 3 phases isn't that big of a deal -- you can very comfortably fit two phases onto one COG.
I, for one, would be perfectly happy with a DIP-40 with the same pinouts as the current chip... if that's possible. In other words, a drop-in replacement with more ram and faster cogs.
Yes, it would not have the additional I/O's...externally. But they could still be used for inter-cog communication...
What could be included to ease the use of SDRAM? I have used SDRAM in many a project and have not had any difficulty. Hou could it be any easier?
Support is already there. http://www.parallax.com/Propeller2FeatureList/tabid/898/Default.aspx
SDRAM is also available for the PropellerPlatform today and can be used with Zog C/C++.
SDRAM does not need some special support, it is to simple of an interface. It can be done by any programmer so simply, on any microcontroller that supports dynamic use of IO pins, that I do not understand what could be implemented in HW that could be helpful for this. In sum: the prop supported SDRAM the first day it functioned. My question was what HW is added that could possibly make accessing SDRAM any simpler than it already is. It is already easier than I2C or SPI.
The processor has a hardware bus interface. That interface takes care of putting out addresses on the address bus, reading/writing data on the data bus and wiggling the appropriate READ/WRITE and other control signals for the bus. The programmer does not need to know how any of this works. It works fast.
On a micro-controller like the Prop there is no such dedicated memory bus hardware. One has to write software to drive the general purpose I/O pins and create memory accesses. It is slow. Code cannot be executed directly from such memory at the full speed of the CPU.
So clearly hardware could be added to the Prop to help speed this up. Imagine having instructions like RDBYTE/WRBYTE that instead of working on HUB RAM automatically generated the bus signals required to access external memory devices. Or what about block reading/writing at high speed. And so on.
Of course the simplest form of external memory support is just to have more I/O pins to drive it.
The P2 feature list that you liked to is confusing. It says that the P2 will have support for external SDRAM but that code cannot be executed from SDRAM. What does that mean? Does that mean simply that you can't point the COG PC at SDRAM and have it execute or does it mean that even RDBYTE/WRBYTE, etc won't work with SDRAM? Interpreters like Spin and ZOG and LMM would even benefit from extending the RD/WR instructions with the ability to address external SDRAM if it was possible to dedicate part of hub memory as a cache. I've worked with processors that allowed some of their local memory to be used as a cache into a larger external address space and it worked quite well. Any idea of Parallax is planning something like that for P2?