32 bit SDRAM

Pence128

With lots of glue logic, it would be possible to read/write SDRAM (or any other memory) 32 bits at a time. This would allow you to load code into a cog faster than a coginit instruction, or even load up to four cogs simultaneously. I/O would have to be multiplexed, and it would be disabled for everything else for about 15us at a time.

Is this worth pursuing? Are there any applications that need lots of code but little I/O?

Mike Green

Only the COGINIT instruction can initialize a cog and force data into its memory. The only possible source for this data is a 2K block of hub memory. There is no way to transfer I/O data directly into a cog's memory. A cog can overlay itself from hub memory or I/O by using a loader running in that cog that was started at some point using a COGINIT.

A high speed SDRAM interface could be useful, but it would depend heavily on the specifics of the application

jazzed

Pence128 wrote: »

With lots of glue logic, it would be possible to read/write SDRAM (or any other memory) 32 bits at a time.

The problem with 32bit SDRAM with Propeller today would be not having a pin to control the clock. It's possible to do almost anything with lots of glue logic of course. As Mike said though, you can't start a cog from anything but HUB memory.

Pence128

Sorry, I wasn't clear. I did mean with a loader already in the cog, probably a long line of mov 0..255, ina

Heater.

Pence128,

And how will the loader get into the COG? Perhaps with COGINIT...

Pence128

yeah, but only once. you can re-use it.

Heater.

Pence128,

But that implies that every "blob" of code that you load into COG also includes the SDRAM loader code so that it can "chain load" another "blob".
Many times there is not going to be space in COG to do that.
Besides I've never heard it said that COG loading time was an issue.

jazzed

You could do overlays from any memory - i.e. load a block of code into a COG. SDRAM would be fast after the address setup and for a 256 *item* read burst would be faster than many solutions, but 32 bits is impractical. Byte wide memory would probably be accessed as fast as word wide memory though. Heater is right about keeping code to do the load. It can be less than 256 instructions of course.

Pence128

The loader wouldn't overwrite itself. I wasn't thinking when I said 255, it would have to be smaller than that. Maximum would be 248 mov's if you always put a jump #0 at the end of every block and if another cog handled addressing.

The half baked idea was sort of a large memory model. It would be like regular PASM, but there would be a subroutine for "long jumps" that would load a block of code corresponding to the high address bits, and then jump to the low address bits.

The problem with 8 and 16 bit widths is the difficulty in assembling them into longs. It's faster to write them to hub and then read them back. At that point you might as well write them to hub and do a coginit.

jazzed

Pence128 wrote: »

The half baked idea was sort of a large memory model. It would be like regular PASM, but there would be a subroutine for "long jumps" that would load a block of code corresponding to the high address bits, and then jump to the low address bits.

Your half-baked idea has lots of history and working examples called Overlay. LMM is a degenerate case descendant from Overlay. I have a few overlay cogs laying around as does Heater and others.

In the 8/16 bit case, you're right of course. I use a cache cog to load code from SDRAM to HUB. A problem with that approach is the time to restart a cog is huge like 100us or so. So your idea of loading from SDRAM has merit even with 8 bit access. I'm working with dual Quad SPI Flash these days which is simpler and almost as fast as SDRAM - faster if you count repeated power up boot cycle times.

Pence128

Since it would be so much work, and I don't have definite use for it, I've decided not to try to do this. I will get a 16 bit device though since I want to experiment with hi res video. Thanks for all your input.