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?
Yes, it is confusing. I think what it means is the COG will not be able to use SDRAM directly as the code fetch/execute or load/store space. That makes sense because of the number of operations required to access SDRAM.
Of course having more pins makes the interface faster and simpler, but to have a straight interface to 32 bits 51 pins are required for one chip without latching (assuming fixed DQM/CS low and CKE high). For byte granularity and power conservation, 56 pins would be necessary. Full featured multi-chip interface number of pins required = 52 + 4*ChipCount. Of course with a hub cache, byte granularity is not necessary, but you still need a DQM pin per chip.
Some Propeller 2 features will help SDRAM. As I recall, a 3rd counter can be used for clocking the SDRAM or other address stepping devices. There is rumor that the new LUT can be used as an on COG cache. Having indexed indirect instructions will allow faster setup and burst terminate operations - a generic programmable burst queue would be faster (the LUT has queue features, but functions are to be revealed).
I see Ale answered some of this. As far as clock synchronization with HUB goes, it is possible to collect data synchronously, but a full per cycle (activate,operation,dataN) non-burst interface implementation for access is most likely not possible.
Chip claims 320MB/s throughput using SDRAM for video applications, so something good will come of it one way or another.
I guess what I was hoping for was not so much the ability for COG instructions to be able to access SDRAM directly but instead an address translation mechanism that would allow a cache in hub memory to be accessed directly with RD/WR instructions at hub memory speeds unless a miss occurs in which case software could take over to fill a cache line and restart. This software could even be running in a separate COG since the Propeller has no concept of a "trap" instruction to invoke the fill operation. All they would need to do is freeze the COG and store the address that caused the fault somewhere in hub memory or in a register that could be read by the cache fill COG.
Alas, that's a really complex sort of operation involving several hub interactions that would be very expensive to implement (in terms of chip area and complexity of changes to other structures). This is the sort of thing where you'd be much better off building a separate memory controller interface with its own built-in cache.
If there is some sort of HW to put out the control commands for SDRAM, that would speed things up a little, and if it automatically handles the refresh on the SDRAM that would save some time in some COG. Based on my understanding of what has been said about the Propeller II; it would seem that if you used a SDRAM with 512 Byte row, that is 16-Bits wide, if you had to bit bang the commands and address, and read the pins, in the same way we do with the Prop I, you should be able to load 128 longs in 768 clocks, at 160MHz that is 4.8 Micro seconds for 128 Longs. For most uses I would be quite happy with this.
The Prop II is still a micro. It is NOT an x86 or 68K or anything similiar. It does not have an external address/data bus.
The main help will be in being able to use the SDRAM as a screen buffer and an external code repository to enable fast hub overlays or XMM processing.
Well, that is certainly true. I keep thinking I should find an application well suited to the Propeller 1/2 and stop trying to run "big machine" programs on it.
The Prop II is still a micro. It is NOT an x86 or 68K or anything similiar. It does not have an external address/data bus.
The main help will be in being able to use the SDRAM as a screen buffer and an external code repository to enable fast hub overlays or XMM processing.
Propeller 2 will be a very nice VGA controller that will enable some complex and fully colored/textured graphics capabilities.
With 128KB on board HUB RAM Propeller will finally be practical for most small applications and bizarre memory interfaces will not be as necessary. Today's Propeller is a practical micro-controller for lots of "micro" applications.
Even a Propeller PDA or "Pad" with LCD 24bit interfaces and lots of goodies may be practical. It may not be as fast with applications as some alternatives but should be sufficient. Whether that would be price competitive with the full-featured alternatives is of course to be determined.
I don't plan to waste my life getting Propeller 2 to run Linux. Still a native (non-emulated) fully sponsored GNU tool-chain would be appreciated by many professional and non-casual users - except Ross .
Well, that is certainly true. I keep thinking I should find an application well suited to the Propeller 1/2 and stop trying to run "big machine" programs on it.
I think that is one of the most sane statements I have read on this "external memory for the Prop" issue for a long time.
However as a programable lump of logic to add to a system being able to get data in and out as fast as possible is an issue.
In that respect any help for fast serial I/O on the Prop II is welcome. And perhaps we are looking at this memory bus issue backwards.
I migh propose a parallel bus interface that allows an external processor to access the Prop like a memory or peripheral device.
Imagine the HUB had 9 slots in it's cycle. One reserved for that external CPU that wants to access the HUB as fast as possible.
I keep thinking I should find an application well suited to the Propeller 1/2 and stop trying to run "big machine" programs on it.
Now now. Is it not to push the limits the source of our fun? I am looking to finishing an XGA/SXGA 15BPP VGA controller for the Propeller 1. As a side project (only work on it when board), I am also trying to emulate the MC68000 at a decent speed on the Propeller 1. I would love to some day soon put to gather a complete Propeller 1 based Desktop computer, with some arcane OS written specifically for it. Remember for these applications the Prop 1 is already more capable than the desktop CPUs of 1990.
Imagine the HUB had 9 slots in it's cycle. One reserved for that external CPU that wants to access the HUB as fast as possible.
Wow what an idea. If this ever happens could you imagine the possibilities for multiple Propeller based systems? One prop being able to read from and write to another props hub mem directly, wow many possibilities. But it does not appear to be there. Maybe Prop3 :-) ?
Seven instructions between hub access instructions will be possible. Not 9, but still useful. I just wish HUB access could be available on demand for one COG in a Strict Priority scheme rather than Round-Robin temporarily. Such a mode is not unprecedented: ATM (not the bank teller) allowed SP-WRR, but the design was very complicated.
Now now. Is it not to push the limits the source of our fun?
That is certainly true! After having played with the Propeller for a few months I think I would find going back to some single-core MCU really dull. :-)
I just heard a rumour.... to be announced Friday next week...
Ken has just received a special discount for straight-jackets. There are plenty of users here who are in line for one, me included
Seriously though, why do we push the prop to these extremes when other chips could do these jobs???
Here are my reasons...
1. The Prop is a joy to program
2. The Prop concept is revolutionary (and did I mention, fun to program)
3. The Prop can be made to perform the job of a whole family of chips with it's soft intelligent peripherals (and did I mention, great to program)
4. The Prop has internal hub SRAM (32KB was lots 5 years ago) so we can use it how we want... code, variables, etc (and did I mention, fantastic to program)
5. The Prop has NO interrupts to worry about interrupting the flow (and did I mention, love to program it)
6. The Prop has so many features that we can push the limits - we have so much further to go yet (oh! and did I mention, I just get so much satisfaction programming it)
Now Ken, you best send me the first straight-jacket... I think I am in need it before Chip
I think I will need more than a straight-jacket when Prop II arrives!!!
Cluso99:
I very much enjoy programming the Propeller, it is the most fun I have had in recent years. Do you like programming the Propeller, not quit sure from your post .
There is a Propeller board that's mostly Arduino shield compatible. It works with many shields and doesn't work with a few. Check out the website here.
It's not on the website yet because it's still under development, but there's a plug-in adapter that uses the expansion connector to provide a micro-SD card, PS/2 keyboard, and TV display. There's a thread that discusses this as the Mini-Terminal.
Cluso99:
I very much enjoy programming the Propeller, it is the most fun I have had in recent years. Do you like programming the Propeller, not quit sure from your post .
Comments
Yes, it is confusing. I think what it means is the COG will not be able to use SDRAM directly as the code fetch/execute or load/store space. That makes sense because of the number of operations required to access SDRAM.
Of course having more pins makes the interface faster and simpler, but to have a straight interface to 32 bits 51 pins are required for one chip without latching (assuming fixed DQM/CS low and CKE high). For byte granularity and power conservation, 56 pins would be necessary. Full featured multi-chip interface number of pins required = 52 + 4*ChipCount. Of course with a hub cache, byte granularity is not necessary, but you still need a DQM pin per chip.
Some Propeller 2 features will help SDRAM. As I recall, a 3rd counter can be used for clocking the SDRAM or other address stepping devices. There is rumor that the new LUT can be used as an on COG cache. Having indexed indirect instructions will allow faster setup and burst terminate operations - a generic programmable burst queue would be faster (the LUT has queue features, but functions are to be revealed).
I see Ale answered some of this. As far as clock synchronization with HUB goes, it is possible to collect data synchronously, but a full per cycle (activate,operation,dataN) non-burst interface implementation for access is most likely not possible.
Chip claims 320MB/s throughput using SDRAM for video applications, so something good will come of it one way or another.
The main help will be in being able to use the SDRAM as a screen buffer and an external code repository to enable fast hub overlays or XMM processing.
Well, that is certainly true. I keep thinking I should find an application well suited to the Propeller 1/2 and stop trying to run "big machine" programs on it.
Propeller 2 will be a very nice VGA controller that will enable some complex and fully colored/textured graphics capabilities.
With 128KB on board HUB RAM Propeller will finally be practical for most small applications and bizarre memory interfaces will not be as necessary. Today's Propeller is a practical micro-controller for lots of "micro" applications.
Even a Propeller PDA or "Pad" with LCD 24bit interfaces and lots of goodies may be practical. It may not be as fast with applications as some alternatives but should be sufficient. Whether that would be price competitive with the full-featured alternatives is of course to be determined.
I don't plan to waste my life getting Propeller 2 to run Linux. Still a native (non-emulated) fully sponsored GNU tool-chain would be appreciated by many professional and non-casual users - except Ross
I think that is one of the most sane statements I have read on this "external memory for the Prop" issue for a long time.
However as a programable lump of logic to add to a system being able to get data in and out as fast as possible is an issue.
In that respect any help for fast serial I/O on the Prop II is welcome. And perhaps we are looking at this memory bus issue backwards.
I migh propose a parallel bus interface that allows an external processor to access the Prop like a memory or peripheral device.
Imagine the HUB had 9 slots in it's cycle. One reserved for that external CPU that wants to access the HUB as fast as possible.
Sorry, I just could not resist myself
Ken has just received a special discount for straight-jackets. There are plenty of users here who are in line for one, me included
Seriously though, why do we push the prop to these extremes when other chips could do these jobs???
Here are my reasons...
1. The Prop is a joy to program
2. The Prop concept is revolutionary (and did I mention, fun to program)
3. The Prop can be made to perform the job of a whole family of chips with it's soft intelligent peripherals (and did I mention, great to program)
4. The Prop has internal hub SRAM (32KB was lots 5 years ago) so we can use it how we want... code, variables, etc (and did I mention, fantastic to program)
5. The Prop has NO interrupts to worry about interrupting the flow (and did I mention, love to program it)
6. The Prop has so many features that we can push the limits - we have so much further to go yet (oh! and did I mention, I just get so much satisfaction programming it)
Now Ken, you best send me the first straight-jacket... I think I am in need it before Chip
I think I will need more than a straight-jacket when Prop II arrives!!!
I very much enjoy programming the Propeller, it is the most fun I have had in recent years. Do you like programming the Propeller, not quit sure from your post
It's not on the website yet because it's still under development, but there's a plug-in adapter that uses the expansion connector to provide a micro-SD card, PS/2 keyboard, and TV display. There's a thread that discusses this as the Mini-Terminal.
Absolutely. Perhaps to the point of obsession
Thanks,
Max
It'll get here when it gets here.
-Phil
Yes, see
http://forums.parallax.com/showthread.php?125543-Propeller-II-update-BLOG
Latest I think is a shuttle run in December, is due to include Prop II - { which will, of course, all work first time
Please be careful about the desire for those jackets of minimal freedom. Foe a long time I have been taunted by the promise of one.
PS will the Prop 2 prevent those voices ?