On my own P2 board which I have on hold I was able to get RasPi header compatibility with pins mapping over 1:1 to GPIO numbers, but this certainly made the PCB routing somewhat harder...
I was a bit more pragmatic, because P2 can do anything on any pin, and the main focus is peripherals, I skipped any nominal 1:1 port-pin notation on Pi, and instead focused on
5V/3v3/GND, and then filled in the gaps with P2 pins. That covers UART/i2c/SPI links, and Powering, which are the main uses I can forsee.
That makes the board routing a whole lot simpler, and leaves just getting to all 32 io on P2. That also has a simple solution....
Here, there are 4 pins that can be GND on Pi, or IO pin P2, which still leaves connects to 4 GNDs to Pi boards. End result is a full 32io and Pi compatible
I'm running my P2D2 with revB silicon at 355MHz continually with the VGA cog and playing music files. With the ambient at 25'C I am measuring 43'C max at the very center of the chip top or bottom and 47'C if I point the gun down the 3mm center hole. This is just the plain Jane double-sided pcb, no heatsinking etc.
I will do some more tests and append them to this post later.
5V in @225ma for 355MHz no I/O load (other than LEDs etc) = 1.125W .
I'm running my P2D2 with revB silicon at 355MHz continually with the VGA cog and playing music files. With the ambient at 25'C I am measuring 43'C max at the very center of the chip top or bottom and 47'C if I point the gun down the 3mm center hole. This is just the plain Jane double-sided pcb, no heatsinking etc.
I will do some more tests and append them to this post later.
5V in @225ma for 355MHz no I/O load (other than LEDs etc) = 1.125W .
That would roughly be less than 500mA at 1V8 based on nothing at 3V3 and 80% efficiency. IIRC you have a 1V8 reg following the switcher, so it will be quite a bit less than 500mA tho. I'm interested to know the 1V8 and 3V3 current if you get a chance t measure it. Meanwhile, this is impressive
The 1.8V is straight from the switcher whereas the 3.3V rails are split from a dual output LDO which is fed 3.6V from the other half of the switcher. I need to do another run of P2D2 pcbs so I am tweaking the pcb to include test points suitable for pogo pin probing during testing. However the original P2D2 had jumpers for testing these currents but I am content to feed in an external 1.8V if I want to measure the current.
As I have been manufacturing these P2D2s to get them out to everyone I have also been making revision to the artwork for various improvements both in terms of assembly and design. The assembly improvements are mainly footprint and placement adjustments but the main design improvement is the addition of a RPi header next to the P0..P31 header. I wanted to make this a snapoff section but it is just as easy to guillotine it off if it is in the way. Otherwise you can plug a Pi hat straight into it or plug it into the RPi.
I will send off the artwork this week and have these boards back next week. (I need to as I need more pcbs anyway)
Here is a preview.
That is some darned-Skippy good work there, Peter!
Thanks, for 2 layers it is about as compact as you can get I think using nothing smaller than 0603. But don't forget the actual board itself is far smaller and can be cut off at the 50mil headers either as through-hole or half-way through as SMD mount. Then it is really compact!
Even the left hand strip with the serial header and 0805 LEDs and reset button can be trimmed without problems since it was designed as an option.
... The assembly improvements are mainly footprint and placement adjustments ..
Gets better all the time
Did you manage to get larger footprint options for XO1 ? If 5032 is too much effort, allowing 3225 does gain more choices of Oscillator.
.. and it's nice if XO1.pin1 can have some user access - either a pad or smd-jumper to a nearby P2 port, to allow DAC operation on VCTCXO parts.
Here is a cutdown version of the P2D2 that still has through hole pads although these could be castellated for SMD and reduce the pcb a bit more. But it is totally safe to chop it off.
Hi Peter, have you started any shipping yet, or is it still mainly assembly and test right now?
Hi Roger, I did have some delays last week and some teething problems and didn't make up enough for a US shipment yet, so I can send a few off today for the locals
I expect to have the rest of the shipment assembled this Wednesday and shipped this week and then next week with the new r4 version which will be part of the EU shipment.
(I will copy this into the ordering thread in case there are more questions) (Those who ordered 16GB SD cards end up getting 64GB for the same price!)
Was there a reason the P18 signal was skipped on the RasPi header leaving the pin gap in groups of P2 signals sent? Was it just too hard to route?
While taking into account the pins we can't route to, I can change this to suit if you have a better arrangement. Just yesterday I changed it to group it a bit differently but if you say P18 etc, then P18 it is.
It could be handy to allocate a contiguous block of GPIO pins for wide data transfers etc, rather than skip any pins. Not so much for RasPi use directly as that has it's own crazy pin mapping anyway but for any other homegrown breakout boards for LCDs or other things that might be attached here. It also lets you do captures over the full set of pins in say some logic analyser application with no bit gaps.
I thought there might have been some special reason P18 was skipped. If you can make it contiguous before you spin the board all the better I say. Leaving 4 free pins at the top of the port for other use is nice too - eg. VGA video out with DACs likes to use 4 contiguous pins. It wouldn't really be able to use the left over P18, P27, P29, P31 for example. And things like USB want pin pairs.
It could be handy to allocate a contiguous block of GPIO pins for wide data transfers etc, rather than skip any pins. Not so much for RasPi use directly as that has it's own crazy pin mapping anyway but for any other homegrown breakout boards for LCDs or other things that might be attached here. It also lets you do captures over the full set of pins in say some logic analyser application with no bit gaps.
I thought there might have been some special reason P18 was skipped. If you can make it contiguous before you spin the board all the better I say. Leaving 4 free pins at the top of the port for other use is nice too - eg. VGA video out with DACs likes to use 4 contiguous pins. It wouldn't really be able to use the left over P18, P27, P29, P31 for example. And things like USB want pin pairs.
Since I don't have any preference or idea at present as to what might be suitable, would you like to nominate which pins we can use then? I've attached that part of my schematic and as you can see I will try and keep all the even pins on the one side and I'm kinda thinking that as much as I avoid solder bridges, that maybe I might connect P18 up to P25 as default and simply allow for solder bridge to ground or something. Or maybe make both of them solder bridges since cutting very fine tracks is awkward. In fact, 0402 makes for a tidy solder bridge since the pads are so close and that can still use a component if necessary.
Since I don't have any preference or idea at present as to what might be suitable, would you like to nominate which pins we can use then? I've attached that part of my schematic and as you can see I will try and keep all the even pins on the one side and I'm kinda thinking that as much as I avoid solder bridges, that maybe I might connect P18 up to P25 as default and simply allow for solder bridge to ground or something. Or maybe make both of them solder bridges since cutting very fine tracks is awkward. In fact, 0402 makes for a tidy solder bridge since the pads are so close and that can still use a component if necessary.
Great idea - That's exactly what I already did
Here is my evolved Pi pinout - after a few iterations, this is what I settled on as the most flexible and most compact. Feel free to clone it.
This connects all P2 pins, and has 4 jumper/bridges on the pins suffixed j.
This allows one connector to cover ALL P2 access and Pi access, and the routing is simple enough to not move the connectors placements.
Both connectors are also now identical, meaning users do not care which they plug into.
RTC changes
The RTC has been moved successfully onto the top component side of the board and there are a couple of enhancements.
First is basic but we can add an extra 11mF chip cap to the bottom to boost the standby capacity of the main chip cap. At present this seems capable of maintaining the time for several days or a week even. Adding another cap simply boosts that but of course the other option of a larger button cap of 220mF is also possible although they are nowhere as compact.
Secondly, the CKO timing output is brought out to an I/O through a high value resistor just like the INT output. Since this is a weak signal it can easily be overridden by the P2 or external device. The EVI input hasn't changed but allows for the RTC to capture the timestamp of an external event even while it is in standby.
Since I don't have any preference or idea at present as to what might be suitable, would you like to nominate which pins we can use then? I've attached that part of my schematic and as you can see I will try and keep all the even pins on the one side and I'm kinda thinking that as much as I avoid solder bridges, that maybe I might connect P18 up to P25 as default and simply allow for solder bridge to ground or something. Or maybe make both of them solder bridges since cutting very fine tracks is awkward. In fact, 0402 makes for a tidy solder bridge since the pads are so close and that can still use a component if necessary.
You could either go with jmg's approach which allows all pins, though this may be redundant if you have port A anyway, but perhaps could still be useful for full IO monitoring over an expansion cable while your P2D2 board is already plugged into a system board.
The other idea is just to take P0-P27 from the P2 through to the RasPi connector which is what I do on my own board, and I think this should work well with parallel LCDs using the mappings discussed in the parallel LCD thread. This leaves the top 4 pins unused pins together and still available for other pin group use such as VGA/USB/TV+audio etc from the system board.
I'm less worried about P2 pin allotment within the RasPi header itself as that is a bit of a dog's breakfast anyway.
Secondly, the CKO timing output is brought out to an I/O through a high value resistor just like the INT output. Since this is a weak signal it can easily be overridden by the P2 or external device. The EVI input hasn't changed but allows for the RTC to capture the timestamp of an external event even while it is in standby.
I hope these 100k resistors will be okay with HyperRAM data sharing the same pins. I wonder what limiting effect they might have on it's transfer speed. I plan to add HyperRAM memory on those pins, it seems to be a natural location for it, and I think ozpropdev's HyperRAM code can gain a speed optimisation if the RAM data bus is on the lowest 8 pins of a port.
If they slow it down I guess we can desolder these resistors or cut tracks etc. It would be neat if the RTC could tri-strate these outputs too, but I've not looked at the data sheet to check, if so they could be enabled and used at will when RAM is shutdown etc.
Secondly, the CKO timing output is brought out to an I/O through a high value resistor just like the INT output. Since this is a weak signal it can easily be overridden by the P2 or external device. The EVI input hasn't changed but allows for the RTC to capture the timestamp of an external event even while it is in standby.
I hope these 100k resistors will be okay with HyperRAM data sharing the same pins. I wonder what limiting effect they might have on it's transfer speed. I plan to add HyperRAM memory on those pins, it seems to be a natural location for it, and I think ozpropdev's HyperRAM code can gain a speed optimisation if the RAM data bus is on the lowest 8 pins of a port.
If they slow it down I guess we can desolder these resistors or cut tracks etc. It would be neat if the RTC could tri-strate these outputs too, but I've not looked at the data sheet to check, if so they could be enabled and used at will when RAM is shutdown etc.
100k drive is fine for low speed stuff and so far out of the way of being able to influence any other real signal driving those pins. Effectively "tri-state" if you like and I can't see any reason why they wouldn't work. Being a 2 resistor network it is also small enough to flick off with the tip of a hot iron but once again that would not normally be needed. If HyperRAM or any other device didn't work with these 100k "pull-up/downs" then there is something drastically wrong with these devices.
Looking at the application manual for this RTC. It appears INT is open drain which is good so it could be made tri-statable without interrupts. EVI appears to be an input. CLKO may be the only one actively driven hi/lo.
Perhaps if EVI is only an input you could put it's 100k pullup directly on pin 8 and still leave it's series resistor to the P2. Then we can desolder these 3 series resistors from the RTC if the output/pullups get too strong for high speed HyperRAM. It says it this pin shouldn't float so the design as is would kill its EVI pullup if you desolder the series resistor. That might be an issue.
The thing is if you move it you may have to increase it's pullup resistor value to be somewhat higher than the series resistor so the external P2 pin can still drive the logic level high/low.
Looking at the application manual for this RTC. It appears INT is open drain which is good so it could be made tri-statable without interrupts. EVI appears to be an input. CLKO may be the only one actively driven hi/lo.
Perhaps if EVI is only an input you could put it's 100k pullup directly on pin 8 and still leave it's series resistor to the P2. Then we can desolder these 3 series resistors from the RTC if the output/pullups get too strong for high speed HyperRAM. It says it this pin shouldn't float so the design as is would kill its EVI pullup if you desolder the series resistor. That might be an issue.
The thing is if you move it you may have to increase it's pullup resistor value to be somewhat higher than the series resistor so the external P2 pin can still drive the logic level high/low.
I can't see your reasoning in regards to "100k pull-up/down". This shouldn'twill not and can't affect any known memory device. The resistors are implemented as 2 way resnets to keep the element size down while making it easier to manufacture with larger components. The EVI input therefore has a pullup and the series resistor, once again a value of 100k, of no impact on any drive in or out.
Ok, no dramas then if it won't reduce the HyperRAM speed by any noticeable amount. I guess 100k is so far away from the driven impedance it shouldn't be of much consequence.
Ok, no dramas then if it won't reduce the HyperRAM speed by any noticeable amount. I guess 100k is so far away from the driven impedance it shouldn't be of much consequence.
Yes, 100k is insignificant, a bigger issue may be the longer traces and extra loading.
The Eval A board showed that effect, but there they were very much longer...
Yeah passing the signal through from the P2D2 to my board through the pins and my trace lengths from the pins to the RAM may swamp the effect of a short stub terminated with 100k. I guess HyperRAM is generating fundamental signals around the 100MHz frequency band for typical P2 operation depending on the sys clock divider approach used. How significant this will be I'm not sure yet. I'm still hoping for targeting >100MB/s performance for full depth 800x480 LCD graphics use with external memory.
Peter I vaguely recall a while back you may have talked about a HyperRAM plug in board for P2D2. How would such a thing strap itself over your port pins? I wonder if that is a better solution for me going forward and if you are still planning it and if it is mechanically/pin compatible with my own needs (it may not be unless you planned using P32-P4x for it, which is a good place by the way).
Yeah passing the signal through from the P2D2 to my board through the pins and my trace lengths from the pins to the RAM may swamp the effect of a short stub terminated with 100k. I guess HyperRAM is generating fundamental signals around the 100MHz frequency band for typical P2 operation depending on the sys clock divider approach used. How significant this will be I'm not sure yet. I'm still hoping for targeting >100MB/s performance for full depth 800x480 LCD graphics use with external memory.
Peter I vaguely recall a while back you may have talked about a HyperRAM plug in board for P2D2. How would such a thing strap itself over your port pins? I wonder if that is a better solution for me going forward and if you are still planning it and if it is mechanically/pin compatible with my own needs (it may not be unless you planned using P32-P4x for it, which is a good place by the way).
The HyperRAM would sandwich itself onto the bottom of the P2D2, effectively becoming another pcb "layer". As such the signal paths are very short and it can take advantage of the aux clock outputs from the clock gen if need be. Send me the schematic of what you would need just so I can make sure that it is all compatible and I will cobble up a sandwich pcb today to send off with the P2D2.
If you make this sandwich board ideally to converse pins for other use it would be something like this...
HyperRAM data bus on P32-P39 (HyperRAM D0 on P32 etc)
HyperRAM CLK P40
HyperRAM CS P41
HyperRAM RWDS P42
The last 3 pins I need to quickly check with ozpropdev as to which order makes sense if any. Ideally any drivers may need the ability to define the three control pins independently so they can be shared over different systems.
The P2-EVAL Hyper board defines these 3 signals (and more) a certain way because it is a dual part board and also has the luxury of burning a full 16 pins so it can spread the signals over different pins leaving some gaps if you go RAM only, but that arrangement may not be ideal on the P2D2 for everyone as it uses so many pins.
Also any future combined FLASH + RAM board would need to use more pins. I think a first board you make could be simple RAM only as it keeps plenty of IO free. Just use the first 11 pins of portB for this and it frees the remainder of port B for other main board things like HDMI, USB, I2C, SD etc, and also leaving port A completely free.
Update: phoned ozpropdev and he said the control pins are fine. It's arbitrary in his driver code. Having the clock signal immediately following the 8 bits of data may help with any byte banging using 9 bit direct writes to portB with alternating top bits for the clock. You could set CS low manually before the transfer and directly send bytes+clock using individual writes, so I think the mapping above is handy.
If you make this sandwich board ideally to converse pins for other use it would be something like this...
HyperRAM data bus on P32-P39 (HyperRAM D0 on P32 etc)
HyperRAM CLK P40
HyperRAM CS P41
HyperRAM RWDS P42
The last 3 pins I need to quickly check with ozpropdev as to which order makes sense if any. Ideally any drivers may need the ability to define the three control pins independently so they can be shared over different systems.
The P2-EVAL board defines these 3 signals (and more) a certain way because it is a dual part board and also has the luxury of burning a full 16 pins so it can spread the signals over different pins leaving some gaps if you go RAM only, but that arrangement may not be ideal on the P2D2 for everyone as it uses so many pins.
Also any future combined FLASH + RAM board would need to use more pins. I think a first board you make could be simple RAM only as it keeps plenty of IO free. Just use the first 11 pins of portB for this and it frees the remainder of port B for other main board things like HDMI, USB, I2C, SD etc, and also leaving port A completely free.
Are the spare clock generator clocks any use to you then? They can be setup to any phase and frequency and rise/fall time etc
Comments
5V/3v3/GND, and then filled in the gaps with P2 pins. That covers UART/i2c/SPI links, and Powering, which are the main uses I can forsee.
That makes the board routing a whole lot simpler, and leaves just getting to all 32 io on P2. That also has a simple solution....
Here, there are 4 pins that can be GND on Pi, or IO pin P2, which still leaves connects to 4 GNDs to Pi boards. End result is a full 32io and Pi compatible
I will do some more tests and append them to this post later.
5V in @225ma for 355MHz no I/O load (other than LEDs etc) = 1.125W .
That would roughly be less than 500mA at 1V8 based on nothing at 3V3 and 80% efficiency. IIRC you have a 1V8 reg following the switcher, so it will be quite a bit less than 500mA tho. I'm interested to know the 1V8 and 3V3 current if you get a chance t measure it. Meanwhile, this is impressive
I will send off the artwork this week and have these boards back next week. (I need to as I need more pcbs anyway)
Here is a preview.
Thanks, for 2 layers it is about as compact as you can get I think using nothing smaller than 0603. But don't forget the actual board itself is far smaller and can be cut off at the 50mil headers either as through-hole or half-way through as SMD mount. Then it is really compact!
Even the left hand strip with the serial header and 0805 LEDs and reset button can be trimmed without problems since it was designed as an option.
Gets better all the time
Did you manage to get larger footprint options for XO1 ? If 5032 is too much effort, allowing 3225 does gain more choices of Oscillator.
.. and it's nice if XO1.pin1 can have some user access - either a pad or smd-jumper to a nearby P2 port, to allow DAC operation on VCTCXO parts.
Hi Roger, I did have some delays last week and some teething problems and didn't make up enough for a US shipment yet, so I can send a few off today for the locals
I expect to have the rest of the shipment assembled this Wednesday and shipped this week and then next week with the new r4 version which will be part of the EU shipment.
(I will copy this into the ordering thread in case there are more questions) (Those who ordered 16GB SD cards end up getting 64GB for the same price!)
and hope then will be another shipment to EU
[edit] wrong thread - moved over
https://forums.parallax.com/discussion/170840/looking-for-a-parallel-lcd-solution-with-p2-streamer#latest
Was there a reason the P18 signal was skipped on the RasPi header leaving the pin gap in groups of P2 signals sent? Was it just too hard to route?
While taking into account the pins we can't route to, I can change this to suit if you have a better arrangement. Just yesterday I changed it to group it a bit differently but if you say P18 etc, then P18 it is.
I thought there might have been some special reason P18 was skipped. If you can make it contiguous before you spin the board all the better I say. Leaving 4 free pins at the top of the port for other use is nice too - eg. VGA video out with DACs likes to use 4 contiguous pins. It wouldn't really be able to use the left over P18, P27, P29, P31 for example. And things like USB want pin pairs.
Since I don't have any preference or idea at present as to what might be suitable, would you like to nominate which pins we can use then? I've attached that part of my schematic and as you can see I will try and keep all the even pins on the one side and I'm kinda thinking that as much as I avoid solder bridges, that maybe I might connect P18 up to P25 as default and simply allow for solder bridge to ground or something. Or maybe make both of them solder bridges since cutting very fine tracks is awkward. In fact, 0402 makes for a tidy solder bridge since the pads are so close and that can still use a component if necessary.
Here is my evolved Pi pinout - after a few iterations, this is what I settled on as the most flexible and most compact. Feel free to clone it.
This connects all P2 pins, and has 4 jumper/bridges on the pins suffixed j.
This allows one connector to cover ALL P2 access and Pi access, and the routing is simple enough to not move the connectors placements.
Both connectors are also now identical, meaning users do not care which they plug into.
~~~~~~~~~~~~~~~~ P2D2Pi FLiP and Pi4 Pin mappings ~~~~~~~~~~~~~~~~~ https://www.element14.com/community/docs/DOC-92640/l/raspberry-pi-4-model-b-default-gpio-pinout-with-poe-header Some GND pins have SB jumpers (NO) for P2 signals, allowing all 32 IO per 40 pin header. PI4 P2D2Pi FLiP CN1 (Other 40 pin, CN3 Pm = P(n-32 )) P2 Pi4 Std Pi .___. Std Pi Pi4 P2 VBP +3V3---1-|O O|--2--+5V 5V P32 (SDA1) GPIO2---3-|O O|--4--+5V 5V P33 (SCL1) GPIO3---5-|O O|--6--_ GND P35 TXD3 (GPIO_GLCK) GPIO4---7-|O O|--8-----GPIO14 (TXD0) P34 P37j PiGND _--9-|O.O|-10-----GPIO15 (RXD0) P36 P39 (GPIO_GEN0) GPIO17--11-|O O|-12-----GPIO18 (GPIO_GEN1) P38 P41 (GPIO_GEN2) GPIO27--13-|O O|-14--_ PiGND P40j P43 (GPIO_GEN3) GPIO22--15-|O O|-16-----GPIO23 (GPIO_GEN4) P42 VBP +3V3--17-|O O|-18-----GPIO24 (GPIO_GEN5) PWM0 P44 P46 (SPI0_MOSI) GPIO10--19-|O.O|-20--_ PiGND P45j P48 (SPI0_MOSO) GPIO9 --21-|O O|-22-----GPIO25 (GPIO_GEN6) P47 P50 (SPI0_SCLK) GPIO11--23-|O O|-24-----GPIO8 (SPI0_CE0_N) P49 GND _-25-|O O|-26-----GPIO7 (SPI0_CE1_N) RTS3 P51 P53 SDA0 (EEPROM) ID_SD---27-|O O|-28-----ID_SC ID EEPROM SCL0 P52 P55 RXD3 GPIO5---29-|O.O|-30--_ P54j P57 CTS3 GPIO6---31-|O O|-32-----GPIO12 PWM0 P56 F.IO1 P58 PWM1 GPIO13--33-|O O|-34--_ GND F.CLK P60 GPIO19--35-|O O|-36-----GPIO16 P59 F.IO0 U.TXD P62 GPIO26--37-|O O|-38-----GPIO20 P61 F.CSN GND _-39-|O O|-40-----GPIO21 P63 U.RXD '---' 40W 0.1" PIN HDRThe RTC has been moved successfully onto the top component side of the board and there are a couple of enhancements.
First is basic but we can add an extra 11mF chip cap to the bottom to boost the standby capacity of the main chip cap. At present this seems capable of maintaining the time for several days or a week even. Adding another cap simply boosts that but of course the other option of a larger button cap of 220mF is also possible although they are nowhere as compact.
Secondly, the CKO timing output is brought out to an I/O through a high value resistor just like the INT output. Since this is a weak signal it can easily be overridden by the P2 or external device. The EVI input hasn't changed but allows for the RTC to capture the timestamp of an external event even while it is in standby.
You could either go with jmg's approach which allows all pins, though this may be redundant if you have port A anyway, but perhaps could still be useful for full IO monitoring over an expansion cable while your P2D2 board is already plugged into a system board.
The other idea is just to take P0-P27 from the P2 through to the RasPi connector which is what I do on my own board, and I think this should work well with parallel LCDs using the mappings discussed in the parallel LCD thread. This leaves the top 4 pins unused pins together and still available for other pin group use such as VGA/USB/TV+audio etc from the system board.
I'm less worried about P2 pin allotment within the RasPi header itself as that is a bit of a dog's breakfast anyway.
I hope these 100k resistors will be okay with HyperRAM data sharing the same pins. I wonder what limiting effect they might have on it's transfer speed. I plan to add HyperRAM memory on those pins, it seems to be a natural location for it, and I think ozpropdev's HyperRAM code can gain a speed optimisation if the RAM data bus is on the lowest 8 pins of a port.
If they slow it down I guess we can desolder these resistors or cut tracks etc. It would be neat if the RTC could tri-strate these outputs too, but I've not looked at the data sheet to check, if so they could be enabled and used at will when RAM is shutdown etc.
100k drive is fine for low speed stuff and so far out of the way of being able to influence any other real signal driving those pins. Effectively "tri-state" if you like and I can't see any reason why they wouldn't work. Being a 2 resistor network it is also small enough to flick off with the tip of a hot iron but once again that would not normally be needed. If HyperRAM or any other device didn't work with these 100k "pull-up/downs" then there is something drastically wrong with these devices.
Perhaps if EVI is only an input you could put it's 100k pullup directly on pin 8 and still leave it's series resistor to the P2. Then we can desolder these 3 series resistors from the RTC if the output/pullups get too strong for high speed HyperRAM. It says it this pin shouldn't float so the design as is would kill its EVI pullup if you desolder the series resistor. That might be an issue.
The thing is if you move it you may have to increase it's pullup resistor value to be somewhat higher than the series resistor so the external P2 pin can still drive the logic level high/low.
I can't see your reasoning in regards to "100k pull-up/down". This shouldn't will not and can't affect any known memory device. The resistors are implemented as 2 way resnets to keep the element size down while making it easier to manufacture with larger components. The EVI input therefore has a pullup and the series resistor, once again a value of 100k, of no impact on any drive in or out.
Yes, 100k is insignificant, a bigger issue may be the longer traces and extra loading.
The Eval A board showed that effect, but there they were very much longer...
Peter I vaguely recall a while back you may have talked about a HyperRAM plug in board for P2D2. How would such a thing strap itself over your port pins? I wonder if that is a better solution for me going forward and if you are still planning it and if it is mechanically/pin compatible with my own needs (it may not be unless you planned using P32-P4x for it, which is a good place by the way).
The HyperRAM would sandwich itself onto the bottom of the P2D2, effectively becoming another pcb "layer". As such the signal paths are very short and it can take advantage of the aux clock outputs from the clock gen if need be. Send me the schematic of what you would need just so I can make sure that it is all compatible and I will cobble up a sandwich pcb today to send off with the P2D2.
HyperRAM data bus on P32-P39 (HyperRAM D0 on P32 etc)
HyperRAM CLK P40
HyperRAM CS P41
HyperRAM RWDS P42
The last 3 pins I need to quickly check with ozpropdev as to which order makes sense if any. Ideally any drivers may need the ability to define the three control pins independently so they can be shared over different systems.
The P2-EVAL Hyper board defines these 3 signals (and more) a certain way because it is a dual part board and also has the luxury of burning a full 16 pins so it can spread the signals over different pins leaving some gaps if you go RAM only, but that arrangement may not be ideal on the P2D2 for everyone as it uses so many pins.
Also any future combined FLASH + RAM board would need to use more pins. I think a first board you make could be simple RAM only as it keeps plenty of IO free. Just use the first 11 pins of portB for this and it frees the remainder of port B for other main board things like HDMI, USB, I2C, SD etc, and also leaving port A completely free.
Update: phoned ozpropdev and he said the control pins are fine. It's arbitrary in his driver code. Having the clock signal immediately following the 8 bits of data may help with any byte banging using 9 bit direct writes to portB with alternating top bits for the clock. You could set CS low manually before the transfer and directly send bytes+clock using individual writes, so I think the mapping above is handy.
Are the spare clock generator clocks any use to you then? They can be setup to any phase and frequency and rise/fall time etc