Shop OBEX P1 Docs P2 Docs Learn Events
Propeller PC and Other Musings — Parallax Forums

Propeller PC and Other Musings

jazzedjazzed Posts: 11,803
edited 2009-11-18 09:44 in Propeller 1
Seems my Propeller "relationship" is migrating between stages these days.

While slogging through some Verilog, my mind drifted to a "different" Propeller XMM design.
Such a design would use 2 Propellers, up to 4MB (or 8MB) unlatched SRAM access, and allow
5MB/s (@80MHz) inter-Propeller communications (good for video frame updates). A block
diagram and text describing the design is included below.

LMM instruction long at a time "single thread" direct access performance may be > 1 MIPS.
A "HUB cached" 6 COG "single thread" design could do > 2 MIPS. LMM becomes the bottleneck.
An alternate swap and run for native PASM might yield better results, but the programs would
have to be very tiny by nature, and the COG manager may be complicated ....

Of course with some of the Page Mode features of SDRAM and other devices, the performance
can be even better to a point (but a dedicated controller or even more Propeller pins is necessary).
All performance numbers assume 80MHz operation. Throughput is horribly inefficient ... yuck.

Now, with a dedicated instruction fetch and execute COG engine, performance could
increase dramatically. but that would be a different chip .... While that is achievable, it is
a long hard slug to make a synthesizable Propeller FPGA clone design and I am getting very
burned out on it.

---

A Dual Prop 4MB XMM "Propeller PC" Block Diagram:

    +----------------+
    |                |   +-----------+
    | Propeller      +-D-+ 4MB SRAM  |
    | XMM Host       +-A-+ Unlatched |
    |                |   +-----------+
    |                |   +-----------+
    |                +---|  EEPROM   |
    |                |   | Gated SCL |
    |                |   +--------+--+
    +-+--------------+            |
      | 9bit 5MB/S BUS            |
    +-+--------------+            |
    |                +-> EEDIS* >-+
    |                |   +-----------+
    |                +---|  VGA      |
    |                |   +-----------+
    |  Propeller     |   +-----------+
    |  Peripheral    +---|  KBD-MSE  |
    |  Devices       |   +-----------+
    |                |   +-----------+
    |                +---|  uSDCARD  |
    |                |   +-----------+
    |                |   +-----------+
    |                +---|  SERIAL   |
    |                |   +-----------+
    |                |   +-----------+
    |                +---|  EEPROM   |
    |                |   +-----------+
    +----------------+




The block diagram describes a two Propeller XMM solution with up to 4MB XMM SRAM.

Theoretical SRAM long read throughput is > 16MB/S using 5 COGS. The SRAM address/data
bus is unlatched similar to Cluso99's "RAM Blade" design. Large 8 bit 1 COG buffer reads
can approach 2.5MB/s burst, 1 COG single byte read would be about 2MB/s, and 1 COG
single long reads would be about 4 MB/s. ... all assuming 80MHz operation.

4MB SRAM is possible because the "device" Propeller disables "host" EEPROM SCL
effectively disabling SDA assert. Also, communications between Propellers is via a
9 bit bus (8 data + 1 select). Using an 8 bit magnitude comparator to memory map
the select pin would allow 8MB of XMM SRAM.

Since the inter-Propeller data bus is 8 bit parallel with 1 bit "select" (or transfer
enable), up to 5MB/s bursts are possible. This is fast enough for the XMM host Propeller
to update display memory in the device Propeller between frame swaps.

The device Propeller operates as a "slave". This means the XMM Host manages all
transactions including device event polling and data transfers. This bus is similar
to the way OctoProp works except there is no need for multiple device IDs or event
driven asynchronous notifications.

Code would not require RPCs although a protocol is necessary for handling device data.

---

Ken Gracey's suggestion that the 2010 UPEW is a good venue for releasing Propeller II
is very welcome. Propeller II is rumored to have 384KB of internal HUB SRAM among other
wonderful features. While this increase is excellent especially in the video buffer realm and
for larger code space, the device will still be limited to a certain class of applications.

Retro gaming will get a big boost, network enabled micros will be more popular, retro
"Propeller PC" computing will be more meaningful (the 5 or 6 CPM users will have a blast
running WordStar and Lotus 123 orders of magnitude faster), GUI based O/S may start to
come from Xerox Palo Alto RC again, and Basic users may still bemoan Spin's missing GOTO.

Thing is, 384KB will be very small again no doubt. And given that two of today's Propellers
working together can have almost as many free pins as a Propeller II would have, we will
still be pinched for pins and addressable memory. So, we're essentially back to square one.

Propeller II will enable a better class of applications, but in the end may still just be an appetizer.

---

I just bought a fully functional Windows XP Single Core 1.6GHz 1GB Net-book for $300. It's a
little small and sometimes (but rarely) a little slow. I can run any Windows program including
the ISE Verilog tool on it and connect to "any" available WiFi network to check up on what's
happening on the forum, ... AND the battery charge lasts about 7 hours which is just amazing.

Well, I guess the Netbook could be used for anything including running an autonomous
vehicle, I can use my favorite development environment to do it, and I don't have to hack
away at a bunch of hardware that mis-fits my goals.

I can still use devices like Propeller for interfacing with servos, steppers, etc... for robotics
control and sensor applications. Of course having a neat little interconnect with the Netbook
would be useful (most likely my next Propeller project).

I thought that post #2112 would be a good one to say I'm giving up on this stuff ... sort of
an end of the world prophecy thingy. But no, it's just a re-evaluation, and possibly a re-birth
kind of post. I should not ever expect Propeller in any incarnation to be more than a
microcontroller, accept that, and be productive with the role it can reasonably play.

That's a tall order for me though considering how much I like messing around with this stuff.

---

In an attempt to ween myself from crazy Propeller urges, I plan to limit my forum posts to once per week.

Cheers.
--Steve

Comments

  • Nick MuellerNick Mueller Posts: 815
    edited 2009-11-18 09:44
    > While this increase is excellent especially in the video buffer realm and
    > for larger code space, the device will still be limited to a certain class of applications.

    > Propeller II will enable a better class of applications, but in the end may still just be an appetizer.

    It's a micro-controller. Not a processor! I never understood why people try to run a real OS on that chip (except for the fun of it). If you do with the Prop what he's intended to do by definition (µC) he's a great piece of silicon to consider. But if you try to abuse him, he will fail like all other controllers and processors. As soon as you need external RAM to execute code, your decision for that platform was a wrong decision.

    The Propeller I is not a processor, he is a controller.
    The Propeller II will be a more capable controller. Nothing more.


    Nick

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Never use force, just go for a bigger hammer!

    The DIY Digital-Readout for mills, lathes etc.:
    YADRO
Sign In or Register to comment.