Any Possibility of Getting SDRAM (or General Port) Pins?
JRetSapDoog
Posts: 954
If I recall correctly, the P2 module with 32MB of SDRAM (that Parallax has a preliminary design for) uses in the neighborhood of 44 pins (atm, the exact number escapes me). That was back on the P2 design with 92 I/O pins. With the design for the P16X32B having 64 pins, that's concerning, as it might only leave 20 pins or so for other interfacing/signal handling. I suppose extra chips could be used to save pins, but such a solution seems inelegant and could be slower. Moreover, it seems a shame to be cut off from the resources of nearly two-thirds of the smart pins because they are tied up with straight-digital memory stuff.
As such, one wonders if some kind of address or data bus (such as 16 or 25 lines) couldn't be integrated into the P16X32B. Such a dedicated bus (if that's the righ term) could use "dumb" pins, such that it would require as little logic as possible. And such pins could be driven as either data or address pins via software depending on the interfacing needs). Maybe a special memory location in the hub could be set aside to control a latch to accomplish this. Or perhaps all cogs could dedicate one cog register out of 512 for this, or'ed together, which could also be used for inter-cog communication (if any bits were left over or external memory wasn't used).
Of course, this would necessitate a different package, but that wouldn't seem like a deal breaker (though it'd likely result in a slightly more expensive (and applicable) part). It might be argued that such a scheme with such dedicated pins would break the symmetry of the new chip or its design philosophy of software as a peripheral. But isn't this the one place that such an exception (if that's what it is) makes sense? It also might be objected that this is a misguided attempt to turn the new chip into a general microprocessor. Maybe, but the new chip (in it's current design) is shaping up to nicely bridge the gap between the microcontroller world and application processors. It'd sure be great to have the possibility of interfacing SDRAM at fast speeds (such as in a newly designed Parallax module) and still retain the bulk of those smart pins. And such a pin setup would seem to only enhance the software-as-a-peripheral approach by freeing up more pins to be used in that flexible way.
As such, one wonders if some kind of address or data bus (such as 16 or 25 lines) couldn't be integrated into the P16X32B. Such a dedicated bus (if that's the righ term) could use "dumb" pins, such that it would require as little logic as possible. And such pins could be driven as either data or address pins via software depending on the interfacing needs). Maybe a special memory location in the hub could be set aside to control a latch to accomplish this. Or perhaps all cogs could dedicate one cog register out of 512 for this, or'ed together, which could also be used for inter-cog communication (if any bits were left over or external memory wasn't used).
Of course, this would necessitate a different package, but that wouldn't seem like a deal breaker (though it'd likely result in a slightly more expensive (and applicable) part). It might be argued that such a scheme with such dedicated pins would break the symmetry of the new chip or its design philosophy of software as a peripheral. But isn't this the one place that such an exception (if that's what it is) makes sense? It also might be objected that this is a misguided attempt to turn the new chip into a general microprocessor. Maybe, but the new chip (in it's current design) is shaping up to nicely bridge the gap between the microcontroller world and application processors. It'd sure be great to have the possibility of interfacing SDRAM at fast speeds (such as in a newly designed Parallax module) and still retain the bulk of those smart pins. And such a pin setup would seem to only enhance the software-as-a-peripheral approach by freeing up more pins to be used in that flexible way.
Comments
If there's room for one exception, there's room for hundreds. If dedicated RAM pins are added, you might as well as dedicated SPI, serial, usb, I2C, etc. pins. They don't use analog, so why should they take up smart pins? Since video output doesn't need ADCs, its pins don't need them, so also add dedicated pins for video output. Then we'll add dedicated SD card pins, dedicated programming pins, and, while we're at it, dedicated interrupt pins that make a cognew happen when the pin gets triggered. Before you know it, we'll be left with any old processor that's lost the beauty of the Propeller.
Please don't add dedicated pins for anything.
electrodude
Such that the Propeller can become a peripheral to an ARM, or whatever, that is handling that big code/data you require.
There's already enough pins for multiple instances of SPI/serial/USB/I2C. However, there's an arguable need for more pins if we want SDRAM, and there very well may not be enough logic space (not sure about power) left at 180nm to add more smart pins if we don't want to cut into the 512KB of hub (though I suppose it's a possibility). Dedicated pins could be an effective compromise due to significantly reducing the amount of additional logic that would be required to get more pins for SDRAM. Don't you also perceive a likely need (beyond just desire) for more pins if SDRAM is needed? If so, are you saying to just "suck it up" or to find another chip? Would you be philosophically upset if Chip added such digital pins (and not other types)? I'd gladly take 'em if I could get 'em.
I'm not requesting dedicated SDRAM hardware (other than the pins themselves with their latches). Most or all processing would still be done in s/w, though Chip may have some h/w tricks in mind to expedite things. I wouldn't necessarily be opposed to built-in SDRAM processing, but I'm not suggesting it. The pins that I am suggesting could also be used for other purposes if one didn't need them for SDRAM, such as I2C (implemented via software). And I wouldn't advocate for separate pins for video, as the current pins flexibly handle at least some forms of video (without locking one into only video). But video typically demands a lot of memory, hence a need for SDRAM in some (not all) video cases.
We don't know how the 64 smart pins will be used. We're willing to pay the price of not using some functionality for the added flexibility. The smart pins along with the whole soft-peripheral approach maintains maximum flexibility. But I think SDRAM is an exception due to the number of pins involved and the fact that memory is fundamental to so many applications that people will envision. Parallax must have also thought SDRAM was important (for many applications) to include it on the P2 module, but that was back when we had 92 total pins available.
I guess it could go both ways (it would need to, anyway, if used for data lines instead of address lines). BTW, I wasn't suggesting that it be any more "high-speed" than any of the other pins can provide (not that you were saying that I was). Tossing in an ARM complicates things immensely, however, in terms of layout and the need to program for two separate architectures, though it would (and will) have its uses. And ARM sourcing and EOL are other things to consider. Anyway, I don't really think that you are implying that the new Propeller has no business directly running applications that need to talk to an SDRAM, even though it's a stretch. I see the features that we've both mentioned as compatible in the sense that added (not-so-smart) pins could target ether application.
That's not quite what I'd call Dedicated SDRAM Pins, more just parallel port io, if SW handles Address / signals.
There have been requests for DACs to map to parallel pins, and that naturally also extends to read pathways.
There would be some small logic for strobe and SyncClocks but the data flow other than small bursts would be SW controlled.
Besides RAM, a quite large market exists for Direct LCD Display drive - here 9/12/16/18/24b are the common widths.
I'm not sure extra pins are needed, but certainly a parallel-bus mode would be very useful.
The request by some of us to provide an option to connect the WAITVID circuitry directly to pins, bypassing the DAC's, for directly driving LCD's could use either smart pins or the above dumb (or port) pins. I'd be willing to use smart pins for that, as I likely wouldn't implement 24-bit color, and the number of pins is less than what's needed for off-chip memory, but, if available, using a general-purpose port would be a nice option. Directly driving displays would seem quite desirable, as you mention. Elsewhere, I mentioned it'd be good to have a separate thread on that, such that we could learn about or discuss the difficulties of implementing that on the current (or older) design. It may not be as straight-forward as it would seem. But such a thread has not been created, yet. In my case, I guess I felt I've created enough (dead-end) threads for the time-being (though I just threw up this one), and I'm sure Chip's hands are quite full for now and the foreseeable future. Still, I'd like to understand the "direct-connect" situation better.
One obvious variant of D/A bypass keeps the video buffer, but does not go thru the D/A, instead maps the Video to a Group of pins. ( ie a bit like P1 does now, as it has no D/A )
Hopefully such a mode will be included.