Shop OBEX P1 Docs P2 Docs Learn Events
P2D2 - An open hardware reference design for the P2 CPU - Page 23 — Parallax Forums

P2D2 - An open hardware reference design for the P2 CPU

1202123252638

Comments

  • jmgjmg Posts: 15,140
    rogloh wrote: »
    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 :)


  • If there is a reserve list for P2D2s i'd like to put my name down for two
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2019-11-10 03:34
    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 .
  • Cluso99Cluso99 Posts: 18,066
    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 :smiley:
  • 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.
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2019-11-25 00:35
    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.

    P2D2r4%20PCB-3D.png
    1830 x 1034 - 1M
    1743 x 1362 - 1M
  • That is some darned-Skippy good work there, Peter!
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2019-11-25 02:06
    JRoark wrote: »
    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.
  • jmgjmg Posts: 15,140
    ... 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.




  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2019-11-25 02:32
    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.

    P2D2r4%20SMD%20PCB%203D.png
    1848 x 1083 - 1M
  • Hi Peter, have you started any shipping yet, or is it still mainly assembly and test right now?
  • rogloh wrote: »
    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!)
  • MJBMJB Posts: 1,235
    edited 2019-11-25 17:53
    I am waiting for a P2D2 until the Dev-Board is available ...
    and hope then will be another shipment to EU
    [edit] wrong thread - moved over
  • roglohrogloh Posts: 5,122
    edited 2019-11-27 12:20
    I was discussing the new P2D2 rev in this thread relating to LCD video here

    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?
  • rogloh wrote: »
    I was discussing the new P2D2 rev in this thread relating to LCD video here

    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.


    2414 x 602 - 153K
  • 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.


  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2019-11-27 23:39
    rogloh wrote: »
    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.
    620 x 942 - 62K
  • jmgjmg Posts: 15,140
    edited 2019-11-28 00:42
    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 :smile:

    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 HDR                              
    




  • 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.
    1870 x 1011 - 113K
  • roglohrogloh Posts: 5,122
    edited 2019-11-28 00:53

    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.
  • roglohrogloh Posts: 5,122
    edited 2019-11-28 01:04

    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.
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2019-11-28 01:27
    rogloh wrote: »

    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.
  • roglohrogloh Posts: 5,122
    edited 2019-11-28 01:39
    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.
  • rogloh wrote: »
    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'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.
  • 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.
  • jmgjmg Posts: 15,140
    rogloh wrote: »
    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).
  • rogloh wrote: »
    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.
  • roglohrogloh Posts: 5,122
    edited 2019-11-28 05:27
    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.
  • rogloh wrote: »
    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
Sign In or Register to comment.