Can separate RWDS signals be used to advantage, without also making CK signals separate?
My concern is that we promote some odd use case that winds up being used out of apparent recommendation by us, and forever haunts objects. It looks to me like the HyperRAM people recommend common signals for everything except CS's, which makes sense.
VonSzarvas and I talked about this at length yesterday. I'm kind of worried that if we make the INT signals available from the HyperFlash chips, people will suppose they ought to be used over simple polling, making future OS-level software reliant on external events from extra pins, rather than maintaining control by polling at intervals to determine write-done status. We don't want the tail wagging the dog, maybe.
If the RESET function can be handled by software writing a status register in the HyperRAM chip, that might be preferable to using an extra pin to control, and forever establishing that a pin be used for RESET. More tail-wagging-the-dog concerns of mine.
The aim to have two separated RWDS signals was to be able to copy content between chips (flash>ram and ram<->ram) without driving databus.
Can you actually do that copy, with common clocks ?
I think the CS# always resets the delivery state engine, and that expects the CMD address to follow - but you need that separate for Flash/RAM, before you can hit the big 'go' button to stream from one to the other.
It could work with separate clocks ?
Even there, I'm not sure how large a block you can stream, before the RAM refresh rules bite...
So, there's some interest in getting rid of RESET# control and having separate RWDS lines for the flash and RAM groups?
If you wanted local copying, I think you also need separate clocks....
Maybe the somewhat wasteful 4 lines for chipselects can reduce to a CS_F and CS_R, and then an A/B group select, and a Logic chip.
Then you have pin for CLK_F and CLK_R, to support ready each device for a block move.
That means any-of-4-chip to any-of-4chip copy is lost, but you can do A_Flash <=> A_Ram, then B_Flash <-> B_Ram
Is that flexible enough ?
I've been musing about this all day long (since yesterday, to be true).
I'm having a huge problem with Diptrace, Eagle (official, student licensee) and Kicad, thus I'm unable to post a good schematic of the results.
Hope the following description is found to be enough, but sure, I'm here (or thru Skype, if there is any interest, just ask me thru a PM), to clarify any possible ambiguity.
So, here it goes:
Since during data transfers, CS# AND RESET# are "mostly" static signals (being RESET# an almost "single-throw" after power on, meant for device initialization and/or error recovery), IMHO, it's possible to use at least one 8-bit transparent latch (74LV573A' style), with both its OE# and LE connected to, says, (IO + 15). This way, (IO + 0) thru (IO + 7) would become latch's data input, that would be propagated to its output registers during the time (IO + 15) remains high (with a pull-up, the controlling P2 pin would wake-up 3-stated, from power on), then latched and simultaneously having its output enabled, when (IO + 15) is asserted low, under programm control.
This way, you could gain individual control over four individualized chip enables (CE#[3:0]), and also four other mostly static control lines (CL[3:0]).
So, by expending only one direct connection to a P2 pin (plus (IO + 0) thru (IO + 7)), there remains seven unnasigned pins.
HyperAnything CK signals are of utmost importance (timing wise), so it's advisable to reserve four directly connected P2 pins, to their exclusive use.
Since you'll need individualized access to up to two RWDSs, simultaneously, to make mostly unnatended copies, under not so stringent timing requirements as clock or data signals, you can use two 74CB3Q3253 dual high-bandwidth single-pole, quad-throw FET bus switches (in fact, only half of each device must be connected; the other half should be "muted" by tying their I/O pins to GND and OE#s to 3.3 V, thru a pull-up (due to noise pick-up concerns)), to select from/to where two other P2 pins, namely, P2RWDS0 and P2RWDS1 would be routed.
The needed addressing bits of the above switches would come from CL[3:2] and CL[1:0]; their OE# pins could safelly be left permanently connected to GND.
Four pull-down resistors, each one near its assigned HyperAnything device, could ensure their individual RWDS lines would not be left floating, when they are left "unconnected" to either P2RWDS0 or P2RWDS1.
At the end, it rests one connection to P2 still unnasigned, (IO + 14); It can be our beloved RESET# conveyor, but not that fast...
There are two unused halves of 74CB3Q3253, each one addressed by one of the CL[3:2] and CL[1:0] pairs. By tying their 1B1, 1B2, 1B3 AND 1B4 (OR 2B1, 2B2, 2B3 AND 2B4, whichever does better fits) to each HyperAnything RESET# pin, and the 1A (or 2A) to GND, one can exert control over its 1OE# (or 2OE#) pin, by means of pulling-low (IO + 14).
The fact that it would be, simultaneously, connecting P2RWDS1 (IO + 13) or P2RWDS0 (IO + 12) to the RWDS pin of the same device is totally irrelevant, both signal and timing wise.
Also, it's advisable to route CS0 and CS1 to both U100 and U101 (and CS2 and CS3 to both U102 and U103), in a manner we could assemble Multichip packaged devices at either (100 - 101, or 102 - 103) positions, but not both, at the same time, that have both chip selects, but routed to differing pins.
I think we should make do with direct connections to the P2, rather than introduce a logic chip. That becomes more headache in layout. Plus, these signals are toggling so quickly that any additional logic delay could be a show-stopper. Keep it simple, I think, in every way possible.
I think we should make do with direct connections to the P2, rather than introduce a logic chip. That becomes more headache in layout. Plus, these signals are toggling so quickly that any additional logic delay could be a show-stopper. Keep it simple, I think, in every way possible.
Ideally, yes, but there are not enough pins to deliver all the capability needed...
If RESET# is not meant to be used (I'm not completelly sure HyperFlashs would not need it, never, in order to resolve any of their complicated error states, including the ones that could awake during programming or erasing), then there is a spare connection to P2 (IO + 14), that could be put in good use to, says, leverage the unnused halves of the two 74CB3Q3253, and provide extra means of accessing, says, some QPI PSRAMs, or flash devices...
And the signals I've choose to interfere, are not high-speed, only D[7:0] and CK would really matter. RWDS, as it can be used by P2 (counting active borders or masking overwrites) is not a great deal, since those 74CB3Q3253 devices will introduce only 200 pS (yes, pico seconds) of delay, once selected.
P.S. and they are bidirectional pass-thrus, adding as little as 8 10 Ohm (maximum) to the resistive path of the signals (sure, some capacitive load too) (17 pF, maximum).
..., it's possible to use at least one 8-bit transparent latch (74LV573A' style), with both its OE# and LE connected
A weakness in this, is when you update the latch, you float the pins. If they have pullups to be safe during reset, any update will disturb CS# signals.
A MC74VHC259 Addressable latch can achieve a similar Reset-follow + control of CS# lines.
That was the reason I'd made every CK directly connected to P2, thus the rule of messing with CS# while CK is low (HyperBus specced) would ensure that nothing will harm EACH individual device, but you are right if one intends to change the CS# of any device, WHILE another device is being activelly used. That possibility needs to be rulled-out, under software control.
Since there is only a single data bus, the natural way of using the breakout would be selecting the device(s) of interest at the same time, while their CKs are brought LOW, under P2 control, then proceeding with command execution.
Even during copying from one device to another one, only the control of the two CKs would be exercised, during the CA phase, just after CS#s of the two are brought low.
The second device CK would be parked at LOW state, while the CA phase of the first device is being completed, then the first device CK's would be parked at LOW state, while transfering the CA phase of the second.
Then both clocks would be exercised, according to the number of programmed latency counts (can be individually set to differing values). The rest is completelly normal operation, of both devices, untill the last CK is brought LOW, then both CS# would be deasserted, thus brought High, simultaneously.
That way, individual Pull-ups at each device CS# would only help avoiding problems.
I've didn't used the '259 solution because it uses LE# and MR# active low, thus needing pull-downs at those lines, and also inverters at the outputs, at least four, to ensure each and every HyperAnything CS# would be brought high, during power on.
We plan to place two HyperRAMs and two HyperFlash devices on the board. If we just did one of each, we could get around all this deliberation, since we'd have four signals for each device. We could even have unique CK, RWDS, CS, with common RESET and the INT signal from the HyperFlash.
Tempting to go back to that. If more than 16MB HyperRAM is needed, then use two modules. Bandwidth would be doubled that way too.
Maybe that's the way to go. The first HyperRAM and HyperFlash chips on a module are 95% important, with additional HyperRAM/Flash devices being another 5% important, anyway. I like the idea of using two boards for much higher bandwidth.
After taking the final decision about the way it will be done, please, just remember to brought both CS#s to both land patterns, in a cross-coupled manner.
That way, there will be chance of assembling just one Ram + Flash multichip packaged device at either footprint, thus enabling the opportunity of doing some experiences with them too.
We plan to place two HyperRAMs and two HyperFlash devices on the board. If we just did one of each, we could get around all this deliberation, since we'd have four signals for each device. We could even have unique CK, RWDS, CS, with common RESET and the INT signal from the HyperFlash.
That may be better, as the traces are already long getting to these boards, and you can be sure larger memories will be released over time.. as demand grows.
Macronix show up to 2GB coming in their octaflash series, with 1Gb MX66LM1G45G showing as stocked.
That OctaFlash appears to be pin/ball compatible with HyperFLASH ?
OctaRAM parts show as M/P, but data sheets are elusive.
..., it's possible to use at least one 8-bit transparent latch (74LV573A' style), with both its OE# and LE connected
A weakness in this, is when you update the latch, you float the pins. If they have pullups to be safe during reset, any update will disturb CS# signals.
A MC74VHC259 Addressable latch can achieve a similar Reset-follow + control of CS# lines.
As a heads-up only (no relation with the final design that will be brought by VonSzarvas hands)...
Thanks jmg by making me thought think a little bit more about my early idea of using a 74LV573A' style transparent latch.
Due to the 3-state nature of P2 pins during power up, by ensureing enough High level drive at the (IO+0) thru (IO+7) and (IO+15) pins, by means of high ohmic valued pull-ups at those lines, is enough to ensure the latch would capture Highs at its input pins.
Thus (IO+15) could be exclusivelly connected to '573 LE pin, while its OE# pin could be permanently tyed to GND.
The following sequence of events would ensure proper selection at CS#[3:0] and CL[3:0] (address-like control lines to the RWDS-paths selection logic):
- before beggining any operation:
1- ensure no HyperAnything operations are active;
2- wait just a few P2 sysclks (mosly unneeded);
3- ensure (drive?) (CK[3:0]) = LOW;
4- ensure (drive?) (IO+15) = LOW;
5- drive the desired latch output configuration at the latch data inputs, using (IO+0) thru (IO+7);
6- drive (IO+15) = High;
7- wait just a few P2 sysclks (mostly unneeded);
8- drive (IO+15) = LOW;
9- proceed with new HyperAnything operation, as intended.
- at operation end:
Just repeat the above depicted sequence of steps, from 1 to 8, in order to deselect (drive High) any of CS#[3:0], in order to drop down current consumption and unleash HypeRam auto-refresh mechanism.
Please note that, as depicted above, the sequence lefts all four CK[3:0] lines driven (parked) LOW.
Don't bother with the states of CL[3:0] lines, they couldn't affect/harm anything. When in doubt, park them at High states.
Henrique
P.S. JIT; Because each of CL[3:2] and CL[1:0] pairs does controls the routing of the (prospective) four individual Hyper?? RWDS to one of (IO+13) and (IO+12), if one parks both pairs at the same selection (value), it would constitute some loop-back way of (early) identification (presence-detection) of the breakout board, without having to mess with any of the HyperSomethings.
Here's the dual-device version. Both HyperFootprints can be configured for either RAM, FLASH or DUAL. By default the plan is currently for 16MB RAM and 32MB FLASH.
When dual or same-devices are used, there's a 5-pin pad from which to grab the extra control signals.
The selectors are not fixed in stone, as layout may force something else. This is the aim as layout starts though!
So if it were me...
I would have all the unused pins terminate with a via - this allows easy access if required.
Similarly, I would connect those pins that are different between Ram and Flash to go to two vias and then to the respective connector. Again, this allows for the cutting of the track between those two serial vias, and a simpler rewiring.
As an extra, if space permits, having extra lines with vias near those connections to link an alternate connection helps extend the options.
With the above arrangement, using a bare pcb it should be fairly simple to solder a pair of Ram or a pair of Flash parts if desired.
I find that vias on a 0.050” grid works nicely to permit various options. Its easy to solder bridge two adjacent vias if necessary, and a cut of two adjacent vias is also quite easy.
IIRC ive used 0.032” dia via pads with 0.016-0.020” (0.4-0.5mm) holes. These will take 0.050” pin headers and links if desired.
No track cutting required to use this PCB for any combination of HyperRAM, HyperFLASH or HyperRAM-FLASH combo "dual Hyper".
We included 0603 package 10 ohm resistor shunts that can be moved (de-soldered / re-soldered) to re-map all the option and control pins to either share (where appropriate) or be separate.
The only pins which are not "brought out" are those that are required only for 1.8V operation. PSC,PSC#,CK#.
Once the layout is ready, I'll see about adding vias on those. It's pretty tight though. Reminds me of some trousers I found at the back of the wardrobe recently, which I'm sure were a great fit 30 years ago
Only PSC (but not PSC#) could, perhaps, be of any use if Cypress, ISSI, or any other player still to come, decides to produce a device that uses it, at 3.3 V.
Currently, it is used only at devices that have 1.8 V as power (main memory array and I/O).
Please remember that CK and RWDS are very busy signals, and need unbroken ground plane beneath or parallel ground traces beside. I'm sure you read the recommended layout docs.
I don't think the 1.8V signals you mentioned will ever be important. Better to use the space for tying together ground or power planes.
Will the bga chips be pre soldered? I'm up the creek if they aren't.
No track cutting required to use this PCB for any combination of HyperRAM, HyperFLASH or HyperRAM-FLASH combo "dual Hyper".
We included 0603 package 10 ohm resistor shunts that can be moved (de-soldered / re-soldered) to re-map all the option and control pins to either share (where appropriate) or be separate.
The only pins which are not "brought out" are those that are required only for 1.8V operation. PSC,PSC#,CK#.
Once the layout is ready, I'll see about adding vias on those. It's pretty tight though. Reminds me of some trousers I found at the back of the wardrobe recently, which I'm sure were a great fit 30 years ago
Excellent news. Those 1V8 signals will not be required for P2 as Chip is saying do not use 1V8 I/O on P2!
Finally took a look at your schematic and I did note R204 was shorting a propeller IO+15 to GND. Is this an error as it's not a good thing to do.
Finally took a look at your schematic and I did note R204 was shorting a propeller IO+15 to GND. Is this an error as it's not a good thing to do.
That's a 10K pulldown for RESET. By default all the RESETS will be held low until Propeller asserts IO+15.
Idea being that the memory will always have a clean start that way.
The pulldown can be removed is that's not preferred, as the Hyper chips have an internal weak pullup to keep them active.
Or the 10K could be moved to the other position, so that the Hyper RESET line can be accessed by one of the option-pads. From there, a F-F header-jumper wire could be used to jumper RESET to some other place, like the EVAL board RESn header pin.
Finally took a look at your schematic and I did note R204 was shorting a propeller IO+15 to GND. Is this an error as it's not a good thing to do.
That's a 10K pulldown for RESET. By default all the RESETS will be held low until Propeller asserts IO+15.
Idea being that the memory will always have a clean start that way.
The pulldown can be removed is that's not preferred, as the Hyper chips have an internal weak pullup to keep them active.
Or the 10K could be moved to the other position, so that the Hyper RESET line can be accessed by one of the option-pads. From there, a F-F header-jumper wire could be used to jumper RESET to some other place, like the EVAL board RESn header pin.
The way i saw that wired was that IO+15 was wired either to external reset or gnd. What am I missing???
Comments
My concern is that we promote some odd use case that winds up being used out of apparent recommendation by us, and forever haunts objects. It looks to me like the HyperRAM people recommend common signals for everything except CS's, which makes sense.
VonSzarvas and I talked about this at length yesterday. I'm kind of worried that if we make the INT signals available from the HyperFlash chips, people will suppose they ought to be used over simple polling, making future OS-level software reliant on external events from extra pins, rather than maintaining control by polling at intervals to determine write-done status. We don't want the tail wagging the dog, maybe.
If the RESET function can be handled by software writing a status register in the HyperRAM chip, that might be preferable to using an extra pin to control, and forever establishing that a pin be used for RESET. More tail-wagging-the-dog concerns of mine.
I think the CS# always resets the delivery state engine, and that expects the CMD address to follow - but you need that separate for Flash/RAM, before you can hit the big 'go' button to stream from one to the other.
It could work with separate clocks ?
Even there, I'm not sure how large a block you can stream, before the RAM refresh rules bite...
If you wanted local copying, I think you also need separate clocks....
Maybe the somewhat wasteful 4 lines for chipselects can reduce to a CS_F and CS_R, and then an A/B group select, and a Logic chip.
Then you have pin for CLK_F and CLK_R, to support ready each device for a block move.
That means any-of-4-chip to any-of-4chip copy is lost, but you can do A_Flash <=> A_Ram, then B_Flash <-> B_Ram
Is that flexible enough ?
I'm having a huge problem with Diptrace, Eagle (official, student licensee) and Kicad, thus I'm unable to post a good schematic of the results.
Hope the following description is found to be enough, but sure, I'm here (or thru Skype, if there is any interest, just ask me thru a PM), to clarify any possible ambiguity.
So, here it goes:
Since during data transfers, CS# AND RESET# are "mostly" static signals (being RESET# an almost "single-throw" after power on, meant for device initialization and/or error recovery), IMHO, it's possible to use at least one 8-bit transparent latch (74LV573A' style), with both its OE# and LE connected to, says, (IO + 15). This way, (IO + 0) thru (IO + 7) would become latch's data input, that would be propagated to its output registers during the time (IO + 15) remains high (with a pull-up, the controlling P2 pin would wake-up 3-stated, from power on), then latched and simultaneously having its output enabled, when (IO + 15) is asserted low, under programm control.
This way, you could gain individual control over four individualized chip enables (CE#[3:0]), and also four other mostly static control lines (CL[3:0]).
So, by expending only one direct connection to a P2 pin (plus (IO + 0) thru (IO + 7)), there remains seven unnasigned pins.
HyperAnything CK signals are of utmost importance (timing wise), so it's advisable to reserve four directly connected P2 pins, to their exclusive use.
Since you'll need individualized access to up to two RWDSs, simultaneously, to make mostly unnatended copies, under not so stringent timing requirements as clock or data signals, you can use two 74CB3Q3253 dual high-bandwidth single-pole, quad-throw FET bus switches (in fact, only half of each device must be connected; the other half should be "muted" by tying their I/O pins to GND and OE#s to 3.3 V, thru a pull-up (due to noise pick-up concerns)), to select from/to where two other P2 pins, namely, P2RWDS0 and P2RWDS1 would be routed.
The needed addressing bits of the above switches would come from CL[3:2] and CL[1:0]; their OE# pins could safelly be left permanently connected to GND.
Four pull-down resistors, each one near its assigned HyperAnything device, could ensure their individual RWDS lines would not be left floating, when they are left "unconnected" to either P2RWDS0 or P2RWDS1.
So, counting:
(IO + 7) -> (IO + 0) = 8 lanes; becomes HyperD[7:0]
(IO + 11) -> (IO+8) = 4 lanes; becomes HyperCK3 -> HyperCK0;
(IO + 13) -> (IO + 12) = 2 lanes; becomes P2RWDS(1) -> P2RWDS(0);
(IO + 15) = 1 lane; becomes "74LV573A" OE# and LE, simultaneously.
At the end, it rests one connection to P2 still unnasigned, (IO + 14); It can be our beloved RESET# conveyor, but not that fast...
There are two unused halves of 74CB3Q3253, each one addressed by one of the CL[3:2] and CL[1:0] pairs. By tying their 1B1, 1B2, 1B3 AND 1B4 (OR 2B1, 2B2, 2B3 AND 2B4, whichever does better fits) to each HyperAnything RESET# pin, and the 1A (or 2A) to GND, one can exert control over its 1OE# (or 2OE#) pin, by means of pulling-low (IO + 14).
The fact that it would be, simultaneously, connecting P2RWDS1 (IO + 13) or P2RWDS0 (IO + 12) to the RWDS pin of the same device is totally irrelevant, both signal and timing wise.
Also, it's advisable to route CS0 and CS1 to both U100 and U101 (and CS2 and CS3 to both U102 and U103), in a manner we could assemble Multichip packaged devices at either (100 - 101, or 102 - 103) positions, but not both, at the same time, that have both chip selects, but routed to differing pins.
Hope I didn't made any gross mistakes.
Henrique
Ideally, yes, but there are not enough pins to deliver all the capability needed...
If RESET# is not meant to be used (I'm not completelly sure HyperFlashs would not need it, never, in order to resolve any of their complicated error states, including the ones that could awake during programming or erasing), then there is a spare connection to P2 (IO + 14), that could be put in good use to, says, leverage the unnused halves of the two 74CB3Q3253, and provide extra means of accessing, says, some QPI PSRAMs, or flash devices...
Must think about this...
Henrique
P.S. and they are bidirectional pass-thrus, adding as little as 8 10 Ohm (maximum) to the resistive path of the signals (sure, some capacitive load too) (17 pF, maximum).
A MC74VHC259 Addressable latch can achieve a similar Reset-follow + control of CS# lines.
Since there is only a single data bus, the natural way of using the breakout would be selecting the device(s) of interest at the same time, while their CKs are brought LOW, under P2 control, then proceeding with command execution.
The second device CK would be parked at LOW state, while the CA phase of the first device is being completed, then the first device CK's would be parked at LOW state, while transfering the CA phase of the second.
Then both clocks would be exercised, according to the number of programmed latency counts (can be individually set to differing values). The rest is completelly normal operation, of both devices, untill the last CK is brought LOW, then both CS# would be deasserted, thus brought High, simultaneously.
That way, individual Pull-ups at each device CS# would only help avoiding problems.
Maybe that's the way to go. The first HyperRAM and HyperFlash chips on a module are 95% important, with additional HyperRAM/Flash devices being another 5% important, anyway. I like the idea of using two boards for much higher bandwidth.
That way, there will be chance of assembling just one Ram + Flash multichip packaged device at either footprint, thus enabling the opportunity of doing some experiences with them too.
That may be better, as the traces are already long getting to these boards, and you can be sure larger memories will be released over time.. as demand grows.
Macronix show up to 2GB coming in their octaflash series, with 1Gb MX66LM1G45G showing as stocked.
That OctaFlash appears to be pin/ball compatible with HyperFLASH ?
OctaRAM parts show as M/P, but data sheets are elusive.
As a heads-up only (no relation with the final design that will be brought by VonSzarvas hands)...
Thanks jmg by making me thought think a little bit more about my early idea of using a 74LV573A' style transparent latch.
Due to the 3-state nature of P2 pins during power up, by ensureing enough High level drive at the (IO+0) thru (IO+7) and (IO+15) pins, by means of high ohmic valued pull-ups at those lines, is enough to ensure the latch would capture Highs at its input pins.
Thus (IO+15) could be exclusivelly connected to '573 LE pin, while its OE# pin could be permanently tyed to GND.
The following sequence of events would ensure proper selection at CS#[3:0] and CL[3:0] (address-like control lines to the RWDS-paths selection logic):
- before beggining any operation:
1- ensure no HyperAnything operations are active;
2- wait just a few P2 sysclks (mosly unneeded);
3- ensure (drive?) (CK[3:0]) = LOW;
4- ensure (drive?) (IO+15) = LOW;
5- drive the desired latch output configuration at the latch data inputs, using (IO+0) thru (IO+7);
6- drive (IO+15) = High;
7- wait just a few P2 sysclks (mostly unneeded);
8- drive (IO+15) = LOW;
9- proceed with new HyperAnything operation, as intended.
- at operation end:
Just repeat the above depicted sequence of steps, from 1 to 8, in order to deselect (drive High) any of CS#[3:0], in order to drop down current consumption and unleash HypeRam auto-refresh mechanism.
Please note that, as depicted above, the sequence lefts all four CK[3:0] lines driven (parked) LOW.
Don't bother with the states of CL[3:0] lines, they couldn't affect/harm anything. When in doubt, park them at High states.
Henrique
P.S. JIT; Because each of CL[3:2] and CL[1:0] pairs does controls the routing of the (prospective) four individual Hyper?? RWDS to one of (IO+13) and (IO+12), if one parks both pairs at the same selection (value), it would constitute some loop-back way of (early) identification (presence-detection) of the breakout board, without having to mess with any of the HyperSomethings.
When dual or same-devices are used, there's a 5-pin pad from which to grab the extra control signals.
The selectors are not fixed in stone, as layout may force something else. This is the aim as layout starts though!
Do the RAM and Flash have the same footprints and pinouts? (havent had time to check)
Please connect the unused pins to vias, so that can be wired with kynar wire if they are required by someone in the future.
footprint same. pinouts almost... . CS is in different position, and a couple extra pins for Flash (INT and RSTO)
So if it were me...
I would have all the unused pins terminate with a via - this allows easy access if required.
Similarly, I would connect those pins that are different between Ram and Flash to go to two vias and then to the respective connector. Again, this allows for the cutting of the track between those two serial vias, and a simpler rewiring.
As an extra, if space permits, having extra lines with vias near those connections to link an alternate connection helps extend the options.
With the above arrangement, using a bare pcb it should be fairly simple to solder a pair of Ram or a pair of Flash parts if desired.
I find that vias on a 0.050” grid works nicely to permit various options. Its easy to solder bridge two adjacent vias if necessary, and a cut of two adjacent vias is also quite easy.
IIRC ive used 0.032” dia via pads with 0.016-0.020” (0.4-0.5mm) holes. These will take 0.050” pin headers and links if desired.
No track cutting required to use this PCB for any combination of HyperRAM, HyperFLASH or HyperRAM-FLASH combo "dual Hyper".
We included 0603 package 10 ohm resistor shunts that can be moved (de-soldered / re-soldered) to re-map all the option and control pins to either share (where appropriate) or be separate.
The only pins which are not "brought out" are those that are required only for 1.8V operation. PSC,PSC#,CK#.
Once the layout is ready, I'll see about adding vias on those. It's pretty tight though. Reminds me of some trousers I found at the back of the wardrobe recently, which I'm sure were a great fit 30 years ago
Only PSC (but not PSC#) could, perhaps, be of any use if Cypress, ISSI, or any other player still to come, decides to produce a device that uses it, at 3.3 V.
Currently, it is used only at devices that have 1.8 V as power (main memory array and I/O).
Please remember that CK and RWDS are very busy signals, and need unbroken ground plane beneath or parallel ground traces beside. I'm sure you read the recommended layout docs.
I don't think the 1.8V signals you mentioned will ever be important. Better to use the space for tying together ground or power planes.
Will the bga chips be pre soldered? I'm up the creek if they aren't.
Yes. Fully assembled, ready to use.
Finally took a look at your schematic and I did note R204 was shorting a propeller IO+15 to GND. Is this an error as it's not a good thing to do.
That's a 10K pulldown for RESET. By default all the RESETS will be held low until Propeller asserts IO+15.
Idea being that the memory will always have a clean start that way.
The pulldown can be removed is that's not preferred, as the Hyper chips have an internal weak pullup to keep them active.
Or the 10K could be moved to the other position, so that the Hyper RESET line can be accessed by one of the option-pads. From there, a F-F header-jumper wire could be used to jumper RESET to some other place, like the EVAL board RESn header pin.
The way i saw that wired was that IO+15 was wired either to external reset or gnd. What am I missing???
If you look at the schematic again, you'll see 10K written beside the default-position line graphic.