Shop OBEX P1 Docs P2 Docs Learn Events
SDRAM and the PropII — Parallax Forums

SDRAM and the PropII

Ym2413aYm2413a Posts: 630
edited 2013-12-16 19:04 in Propeller 2
Hello everyone.
Recently I've been seeing posts about SDRAM and the PropII. Does anyone know if SDRAM is going to be a common feature of the Prop2 and/or the Prop2 boards?
There are over 4,000 posts in the main P2 development thread and no easy way to search it for the answers (that I know of).

Thanks everyone. : ]
--Andrew L. Arsenault.
«13

Comments

  • ctwardellctwardell Posts: 1,716
    edited 2013-12-10 13:52
    At one point Chip was planning a module that would have a P2 and IIRC 32MB of SDRAM.

    http://forums.parallax.com/showthread.php/146802-Parallax-Prop2-Module-Questions-Facts-and-Speculation

    C.W.
  • Ym2413aYm2413a Posts: 630
    edited 2013-12-10 14:01
    Thanks C.W! : ]
  • cgraceycgracey Posts: 14,151
    edited 2013-12-10 15:10
    SDRAM will give the Prop2 big memory (32MB from a single chip).

    We have SDRAM drivers already working that move data between SDRAM and the hub RAM at full SDRAM and hub transfer speed.
  • SeairthSeairth Posts: 2,474
    edited 2013-12-10 15:57
    cgracey wrote: »
    SDRAM will give the Prop2 big memory (32MB from a single chip).

    We have SDRAM drivers already working that move data between SDRAM and the hub RAM at full SDRAM and hub transfer speed.

    So hardware support for DDR2 is off the table, then?
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2013-12-10 16:06
    SDRAM will give the Prop2 big memory (32MB from a single chip).
    We have SDRAM drivers already working that move data between SDRAM and the hub RAM at full SDRAM and hub transfer speed.
    That sounds brilliant!
    Prop I =32k. Prop II = 1000 times more :)
  • SeairthSeairth Posts: 2,474
    edited 2013-12-10 16:37
    Seairth wrote: »
    So hardware support for DDR2 is off the table, then?

    And as a follow-up question, are we still sticking to 8 cogs, or are you still able to squeeze 12 cogs in there? If 12, then giving up a cog to the software SDRAM driver will be even less of an impact.
  • cgraceycgracey Posts: 14,151
    edited 2013-12-10 16:38
    Seairth wrote: »
    So hardware support for DDR2 is off the table, then?

    It would take at least 38 pins that work at 1.8V to make a connection to DDR2 memory.

    We could get rid of 38 of the 3.3V I/O pins and replace them with 1.8V I/Os, keeping things within the same package, but that should maybe be another chip. The benefit would be 4x the bandwidth of SDRAM.
  • Ym2413aYm2413a Posts: 630
    edited 2013-12-10 17:19
    Seairth wrote: »
    And as a follow-up question, are we still sticking to 8 cogs, or are you still able to squeeze 12 cogs in there? If 12, then giving up a cog to the software SDRAM driver will be even less of an impact.

    Yeah from what I know, we're staying at 8 Cogs, but increasing HUB RAM to 256K. The doubling in HUB-RAM is also a doubling in bandwidth between the COGs and HUB-RAM since on-chip memory is added in some parallel fashion.
  • roglohrogloh Posts: 5,786
    edited 2013-12-10 18:48
    To fully gain the additional hub bandwidth Chip is making available to the COG using RDWIDE etc I think we'd have to use 32 bit wide SDR SDRAM instead of 16 bits. That would burn more P2 pins but is still hopefully doable for those designs wanting to make use of the higher transfer bandwidth. Old 16 bit wide DDR1 SDRAM might be a nice fit for the 2x increase in hub bandwidth but I think it only ran at 2.5V instead of 3.3V. The hub request latency and SDRAM driver arbiting is still going to be an issue for COGs not directly attached to the SDRAM. Unfortunately that aspect can't be improved in the existing P2 design as is, it is basically inherent. There is another thread that went into this in more detail with some analysis of bandwidth and latency and its variation with transfer size etc.
  • potatoheadpotatohead Posts: 10,261
    edited 2013-12-10 20:37
    16 bit SDRAM would still work, just not at the higher speed, making for a trade-off between throughput and pins. Pretty sure that was mentioned.
  • cgraceycgracey Posts: 14,151
    edited 2013-12-10 21:46
    potatohead wrote: »
    16 bit SDRAM would still work, just not at the higher speed, making for a trade-off between throughput and pins. Pretty sure that was mentioned.

    That's right. You can use a single 16-bit SDRAM, but you'd only have enough data to fill every other hub slot. With a 32-bit data path, you could hit every slot with 8 longs.
  • SeairthSeairth Posts: 2,474
    edited 2013-12-11 04:11
    cgracey wrote: »
    potatohead wrote: »
    16 bit SDRAM would still work, just not at the higher speed, making for a trade-off between throughput and pins. Pretty sure that was mentioned.
    That's right. You can use a single 16-bit SDRAM, but you'd only have enough data to fill every other hub slot. With a 32-bit data path, you could hit every slot with 8 longs.

    I didn't think the pin count was all that much different. I suppose the real issue with the pins is whether they could still be general-purpose, or whether they would have to be dedicated to the controller circuitry.
  • SeairthSeairth Posts: 2,474
    edited 2013-12-11 04:22
    Does anyone remember where the latest version of the SDRAM driver is posted?
  • SeairthSeairth Posts: 2,474
    edited 2013-12-11 04:25
    Also, was there a reference SDRAM chip that the driver was tested with?
  • ozpropdevozpropdev Posts: 2,792
    edited 2013-12-11 04:31
    Seairth wrote: »
    Does anyone remember where the latest version of the SDRAM driver is posted?

    http://forums.parallax.com/showthread.php/151904-Here-is-the-update-from-the-Big-Change!!!

    Look in balls.spin in the zip file.
  • cgraceycgracey Posts: 14,151
    edited 2013-12-11 04:33
    Seairth wrote: »
    Does anyone remember where the latest version of the SDRAM driver is posted?

    I think it's on the Prop2 Blog thread.

    I'm changing the way XFR works, though, so the new version will be different. I'm making XFR handle complete metered transactions on its own in the background, instead of needing the cog to hover over everything.
  • cgraceycgracey Posts: 14,151
    edited 2013-12-11 04:33
    Seairth wrote: »
    Also, was there a reference SDRAM chip that the driver was tested with?

    Go to digikey.com and search for SDRAM. We've been using a 256Mb chip that comes in a 54-pin package.
  • evanhevanh Posts: 15,912
    edited 2013-12-11 04:36
    Seairth wrote: »
    I suppose the real issue with the pins is whether they could still be general-purpose, or whether they would have to be dedicated to the controller circuitry.

    I think they could still be general digital I/O at 1.8 volts and a different impedance but all the other features vanish. And another likely reason is the moving target it presents to Beau.
  • ozpropdevozpropdev Posts: 2,792
    edited 2013-12-11 04:46
    cgracey wrote: »
    I think it's on the Prop2 Blog thread.

    I'm changing the way XFR works, though, so the new version will be different. I'm making XFR handle complete metered transactions on its own in the background, instead of needing the cog to hover over everything.

    Do you mean programmable intervals between samples and/or stopping when SPB == $FF ?
  • cgraceycgracey Posts: 14,151
    edited 2013-12-11 04:59
    ozpropdev wrote: »
    Do you mean programmable intervals between samples and/or stopping when SPB == $FF ?

    You give it a configuration and a count and it does the job. You can poll for when it completes, or wait. If you give another command, it will wait until it can dovetail it into the last one, so it doesn't skip a beat.
  • ozpropdevozpropdev Posts: 2,792
    edited 2013-12-11 05:02
    cgracey wrote: »
    You give it a configuration and a count and it does the job. You can poll for when it completes, or wait. If you give another command, it will wait until it can dovetail it into the last one, so it doesn't skip a beat.

    Nice! :)
  • potatoheadpotatohead Posts: 10,261
    edited 2013-12-11 08:19
    Agreed!

    Almost like the WAITVID for transfers.
  • Bill HenningBill Henning Posts: 6,445
    edited 2013-12-11 08:29
    If I am reading this right, it becomes something like:

    RDSDRAM sdramaddr, cog/aux addr, len
    WRSDRAM sdramaddr, cog/aux addr, len

    and you can test for completion, or if you have two in a row, the second will start as the first completes?

    Sounds fantastic!
    cgracey wrote: »
    You give it a configuration and a count and it does the job. You can poll for when it completes, or wait. If you give another command, it will wait until it can dovetail it into the last one, so it doesn't skip a beat.
  • jmgjmg Posts: 15,173
    edited 2013-12-11 14:18
    I found these parts via Digikey
    Manufacturer 	Description			Qty	USD	@ qty	Voltage  	Temperature	Package
AS4C1M16S-7TCN	SDRAM 16MBIT 143MHZ 50TSOP	319	0.80784	1000	3 V ~ 3.6 V	0°C ~ 70°C	50-TSOP II
AS4C4M16S-7TCN	SDRAM 64MBIT 143MHZ 54TSOP	1300	0.94248	1000	3 V ~ 3.6 V	0°C ~ 70°C	54-TSOP II
AS4C4M16S-6TIN	SDRAM 64MBIT 166MHZ 54TSOP	186	1.07712	1000	3 V ~ 3.6 V	-40°C ~ 85°C	54-TSOP II
AS4C2M32S-7TCN	SDRAM 64MBIT 143MHZ 86TSOP	299	1.26820	1000	3 V ~ 3.6 V	0°C ~ 70°C	86-TSOP II
AS4C16M16S-7TCN	SDRAM 256MBIT 143MHZ 54TSOP	260	1.58525	1000	3 V ~ 3.6 V	0°C ~ 70°C	54-TSOP II
AS4C16M16S-6TIN	SDRAM 256MBIT 166MHZ 54TSOP	161	2.00000	1000	3 V ~ 3.6 V	-40°C ~ 85°C	54-TSOP II
AS4C4M32S-7TCN	SDRAM 128MBIT 143MHZ 86TSOP	306	2.06250	1000	3 V ~ 3.6 V	0°C ~ 70°C	86-TSOP II
AS4C8M16S-7BCN	SDRAM 128MBIT 143MHZ 54TFBGA	582	2.18750	1000	3 V ~ 3.6 V	0°C ~ 70°C	54-TFBGA (8x8)
AS4C4M32S-7BCN	SDRAM 128MBIT 143MHZ 90TFBGA	483	2.18750	1000	3 V ~ 3.6 V	0°C ~ 70°C	90-TFBGA (8x13)
AS4C16M16S-7BCN	SDRAM 256MBIT 143MHZ 54TFBGA	684	2.81250	1000	3 V ~ 3.6 V	0°C ~ 70°C	54-TFBGA (8x8)
AS4C8M32S-7BCN	SDRAM 256MBIT 143MHZ 90TFBGA	441	4.37500	1000	3 V ~ 3.6 V	0°C ~ 70°C	90-TFBGA (8x13)

    The 54TSOP seems the most widely available, covering 64 & 256MBIT
    Industrial ones are faster, so they seem to have settled on <cheapest> and <highest spec> as two choices.
  • cgraceycgracey Posts: 14,151
    edited 2013-12-11 14:25
    Bill Henning wrote: »
    If I am reading this right, it becomes something like:

    RDSDRAM sdramaddr, cog/aux addr, len
    WRSDRAM sdramaddr, cog/aux addr, len

    and you can test for completion, or if you have two in a row, the second will start as the first completes?

    Sounds fantastic!

    You still need to hover, somewhat to feed the SDRAM its commands, but this will simplify things. For transfers that don't involve SDRAM, like between AUX and HUB, those transfers will become completely hands-free.
  • Bill HenningBill Henning Posts: 6,445
    edited 2013-12-11 14:37
    Sounds good... can't wait to see!
    cgracey wrote: »
    You still need to hover, somewhat to feed the SDRAM its commands, but this will simplify things. For transfers that don't involve SDRAM, like between AUX and HUB, those transfers will become completely hands-free.
  • Cluso99Cluso99 Posts: 18,069
    edited 2013-12-11 16:33
    cgracey wrote: »
    You still need to hover, somewhat to feed the SDRAM its commands, but this will simplify things. For transfers that don't involve SDRAM, like between AUX and HUB, those transfers will become completely hands-free.
    These improvements are going to be spectacularly useful!
    Think video filling the line in the background while the cog can do something useful.
    Think filling half aux while working with the other half for screen updates (game style engine)
    Think filling aux with an overlay that you know is coming up for use

    I am certain we are going to find all sorts of tricks with this mechanism.
  • Ym2413aYm2413a Posts: 630
    edited 2013-12-11 17:17
    This is all very impressive. : ]
    Having 32megabytes of quick access ram opens us up to a lot of data intense applications.
  • SeairthSeairth Posts: 2,474
    edited 2013-12-11 17:39
    cgracey wrote: »
    I'm changing the way XFR works, though, so the new version will be different. I'm making XFR handle complete metered transactions on its own in the background, instead of needing the cog to hover over everything.

    Is XFR still only going to move bits between pins and AUX/QUAD? If so, how easily could it be extended to write to cog memory at INDB?
  • SeairthSeairth Posts: 2,474
    edited 2013-12-11 18:27
    jmg wrote: »
    I found these parts via Digikey
    Manufacturer 	Description			Qty	USD	@ qty	Voltage  	Temperature	Package
AS4C1M16S-7TCN	SDRAM 16MBIT 143MHZ 50TSOP	319	0.80784	1000	3 V ~ 3.6 V	0°C ~ 70°C	50-TSOP II
AS4C4M16S-7TCN	SDRAM 64MBIT 143MHZ 54TSOP	1300	0.94248	1000	3 V ~ 3.6 V	0°C ~ 70°C	54-TSOP II
AS4C4M16S-6TIN	SDRAM 64MBIT 166MHZ 54TSOP	186	1.07712	1000	3 V ~ 3.6 V	-40°C ~ 85°C	54-TSOP II
AS4C2M32S-7TCN	SDRAM 64MBIT 143MHZ 86TSOP	299	1.26820	1000	3 V ~ 3.6 V	0°C ~ 70°C	86-TSOP II
AS4C16M16S-7TCN	SDRAM 256MBIT 143MHZ 54TSOP	260	1.58525	1000	3 V ~ 3.6 V	0°C ~ 70°C	54-TSOP II
AS4C16M16S-6TIN	SDRAM 256MBIT 166MHZ 54TSOP	161	2.00000	1000	3 V ~ 3.6 V	-40°C ~ 85°C	54-TSOP II
AS4C4M32S-7TCN	SDRAM 128MBIT 143MHZ 86TSOP	306	2.06250	1000	3 V ~ 3.6 V	0°C ~ 70°C	86-TSOP II
AS4C8M16S-7BCN	SDRAM 128MBIT 143MHZ 54TFBGA	582	2.18750	1000	3 V ~ 3.6 V	0°C ~ 70°C	54-TFBGA (8x8)
AS4C4M32S-7BCN	SDRAM 128MBIT 143MHZ 90TFBGA	483	2.18750	1000	3 V ~ 3.6 V	0°C ~ 70°C	90-TFBGA (8x13)
AS4C16M16S-7BCN	SDRAM 256MBIT 143MHZ 54TFBGA	684	2.81250	1000	3 V ~ 3.6 V	0°C ~ 70°C	54-TFBGA (8x8)
AS4C8M32S-7BCN	SDRAM 256MBIT 143MHZ 90TFBGA	441	4.37500	1000	3 V ~ 3.6 V	0°C ~ 70°C	90-TFBGA (8x13)

    The 54TSOP seems the most widely available, covering 64 & 256MBIT
    Industrial ones are faster, so they seem to have settled on <cheapest> and <highest spec> as two choices.

    I just noticed that 166MHz is the fastest speed listed. Now that the P2 might be clockable at 200MHz (or more?), none of these would be usable at full speed. Also, just to make sure I am understanding correctly, when I look at balls.spin, I don't see anything driving the CLK pin. I'm assuming this is being done implicitly by the FPGA. And I'm guessing that the final version of the driver will need to explicitly set up a counter output for CLK. So, even though it would be possible to clock the SDRAM at a lower rate and adjust command timing appropriately, the XFR would still be sampling at the internal clock rate.

    It looks like there are some packages that run at 200MHz, but with a maximum memory of 16MB. To get any faster, you have to start looking at DDR...
Sign In or Register to comment.