Shop Learn
64 MB PSRAM module using 16 pins? --> 96 MB w/16 pins or 24 MB w/8 pins - Page 4 — Parallax Forums

64 MB PSRAM module using 16 pins? --> 96 MB w/16 pins or 24 MB w/8 pins

1246789

Comments

  • YanomaniYanomani Posts: 1,419
    edited 2022-06-19 19:30

    @evanh said:
    I don't run the DRC. It complains too much about the outlines overlapping. I'm happy with interactive copper clearances for keeping me on the right track. ... I see the DRC is reporting one error where C8 overlaps the connector. I know that has enough room in reality.

    Interestingly, the unconnected VSS/VDD nets aren't reported in the DRC report. The two fill zones are spec'd for VSS and VDD so sensibly they are accounted for, I presume. But there is a bunch of data tracks reported as unconnected at various vias ... EDIT: Nothing wrong with them! All tracks are connected to those vias.

    EDIT2: Ah, lots of VSS/VDD are reported when the fillszones are not filled in, ie: when CTRL-B'd

    EDIT3: I did change the board setup part way through, from a 2-layer to a 4-layer. I got my four layers, and no odd-ball behaviour resulted. Shrug, dunno why it's got warnings at some of the vias.

    By solely refering to the layouts you've published (right now, I'm just downloading Kicad's last version; it'll take many "eons" on this crappy wi-fi I'm using...) I can't be totally sure, so need to ask it to you, anyway (if my eyes are not fooling me, once more): are there two differing VIO's (comming from two 12-pin interface connectors) shorted togheter at a common 3.3V plane?

  • VonSzarvasVonSzarvas Posts: 2,712
    edited 2022-06-19 20:52

    Such a VIO short would be bad. I'm also wondering if you have a trace connecting each of the TH pins to the SMT pads on that connector... if not, could be a cause of many DRC errors.

  • RaymanRayman Posts: 12,650

    Is connecting two vio really bad?
    I thought about it a while and thought it was better than just using one of them..

  • YanomaniYanomani Posts: 1,419
    edited 2022-06-19 22:37

    Since Hyper_Things/OPI_Psrams have separate VDD and VDDQ connections, in principle, it's ok to designate the VIO that pertains to the same connector from where DQ[7:0]-lanes come from as VDDQ (responsible for power-feeding the whole device's I/O pin-block (CE#, CLKs, DQS/DM (RWDS fro Hypers), and DQ[7:0]), and the other VIO as VDD (responsible for delivering power to the rest of each device's internal circuitry, including the (heavy-consuming) main memory array).

    The chip-enables and clock-lines are input-only (from each Ram/Flash-device's standpoint), so a very-low-value resistor, inserted in series with each of those signals (near their entry point, closer to the connector) should be enough to mitigate any voltage-difference-induced waveform distortion; as for the DQS/DMs (and Hyper-RWDSs), they are bidirectional, and most of the time they'll tend to switch at the same rate as DQ[7:0].

    The only reliefing-factor is that all those I/O-capable signals (DQs, DQS/DMs (and RWDSs)) don't really change direction too fast (at least not as fast as device's operational clock rate), thus there shouldn't be any low-series_impedance-related conflicts between the differing VIO's that would be driving them; perhaps a single very-low-value resistor, inserted in series between the connection of signal's entry-point and the lane that connects all devices togheter can be proved as good enough.

    It's important to note that the number of decoupling capacitors would need to be doubled (at least) and it could be wise to leave provisions for two extra ~1 to 4.7uF capacitors, closer to those VIO entry points (near the two connectors).

    P.S. Signal integrity concerns wiselly demands that no high-switching-rate lanes could be routed as transposing any power-related plane-splittings.

    When this rule must be forcefully violated, there are extra (and specific) ways of mitigating the consequent impedance discontinuities (aka: suitable high-frequency capacitors, closely surounding the signal lanes, connecting the two "halves" of split-planes, near the transposition (think in some kind of bridge parapet walls))

  • evanhevanh Posts: 13,106

    @VonSzarvas said:
    Such a VIO short would be bad.

    Like Rayman, I figured it was better to have them both together than only use one.

    I'm also wondering if you have a trace connecting each of the TH pins to the SMT pads on that connector... if not, could be a cause of many DRC errors.

    Nope, kept well clear of those header pin holes. Had to spend extra time being creative with those routes compared the regular header sockets.

    I did have to shrink the default clearances in Kicad to work with those BGA chips though. The biggest change was the via ring size down to 0.6 mm.

  • evanhevanh Posts: 13,106

    @Yanomani said:
    Since Hyper_Things/OPI_Psrams have separate VDD and VDDQ connections, in principle, it's ok to designate the VIO that pertains to the same connector from where DQ[7:0]-lanes come from as VDDQ (responsible for power-feeding the whole device's I/O pin-block (CE#, CLKs, DQS/DM (RWDS fro Hypers), and DQ[7:0]), and the other VIO as VDD (responsible for delivering power to the rest of each device's internal circuitry, including the (heavy-consuming) main memory array).

    Maybe. I'm not rushing to it.

    The only reliefing-factor is that all those I/O-capable signals (DQs, DQS/DMs (and RWDSs)) don't really change direction too fast (at least not as fast as device's operational clock rate), thus there shouldn't be any low-series_impedance-related conflicts between the differing VIO's that would be driving them; perhaps a single very-low-value resistor, inserted in series between the connection of signal's entry-point and the lane that connects all devices togheter can be proved as good enough.

    Software could conflict in this way but unlikely to be damaging. We want the speed - Fix the bugs.

  • evanhevanh Posts: 13,106
    edited 2022-06-20 01:14

    I am thinking about reinstating the 74HC138 I had earlier. Those things are built just for doing low-active chip selects on a common bus. I threw it away because I didn't have another purpose for all the spare I/O so they all became chip selects.

  • evanhevanh Posts: 13,106

    @Yanomani said:
    ... it'll take many "eons" on this crappy wi-fi I'm using...

    I'm guessing wired is not an option.

  • roglohrogloh Posts: 4,217
    edited 2022-06-20 03:09

    @evanh said:
    I am thinking about reinstating the 74HC138 I had earlier. Those things are built just for doing low-active chip selects on a common bus. I threw it away because I didn't have another purpose for all the spare I/O so they all became chip selects.

    Did you consider the extra cycles it could take in SW to setup the address bits on each access to generate a chip select with a 74HC138 vs driving a single CE pin high/low? In my case I have the CE pin number already known from my per bank information lookup, hence it only takes one extra instruction to drive it either high or low with drvh/drvl on that pin, easy. A 138 decoder would need the 3(?) address pins correctly setup from the bank/address bits. You'd likely need to SHIFT, OR or AND a bit mask to one of the OUTx registers and you'd need to know which OUTA/B register to use as well. Could be slower...

  • evanhevanh Posts: 13,106

    @rogloh said:
    ... You'd likely need to SHIFT, OR or AND a bit mask to one of the OUTx registers and you'd need to know which OUTA/B register to use as well. Could be slower...

    Sorted. Appropriate choice of address pins to align to a whole nibble helps greatly. SETNIB can operate directly on OUTx registers.

  • roglohrogloh Posts: 4,217
    edited 2022-06-20 03:30

    Will you need to patch the executable with the correct nibble and correct OUT register?

  • evanhevanh Posts: 13,106
    edited 2022-06-20 03:59

    The nibble is dynamic depending on bank being addressed, it is almost extra address lines. Selecting OUTA/OUTB to suit where the accessory board is plugged in I guess will need patching at init.

    EDIT: "almost extra address lines" ... On that note, in my experimenting I've got the RAM chips selecting using Y1..Y6, with Y0 and Y7 unused. Maybe I should add pull-ups on the nibble pins and shift the RAMs onto Y0..Y5 instead.

  • evanhevanh Posts: 13,106
    edited 2022-06-20 12:20

    @rogloh said:
    Will you need to patch the executable with the correct nibble and correct OUT register?

    Oh, the nibble number is immediate addressing ... ALTSN + SETNIB might be the way - so one extra instruction ...

    EDIT: Yep, that works a treat:

            mov bcdlen, #8
            mov portnum, ##OUTA<<3
    .loop1
            mov banknum, #5
    .loop2
            mov outb, #0
            mov outa, #0
    
            altsn   portnum
            setnib  banknum
    
            mov pa, outb
            call    #itoh
            mov pb, #","
            call    #putch
            mov pa, outa
            call    #itoh
            call    #putsp
            djnz    banknum, #.loop2
    
            call    #putnl
            incmod  portnum, ##OUTA<<3+14  wcz
        if_nc   jmp #.loop1
            call    #putnl
    

    gives the following output:

    00000000,00000005   00000000,00000004   00000000,00000003   00000000,00000002   00000000,00000001   
    00000000,00000050   00000000,00000040   00000000,00000030   00000000,00000020   00000000,00000010   
    00000000,00000500   00000000,00000400   00000000,00000300   00000000,00000200   00000000,00000100   
    00000000,00005000   00000000,00004000   00000000,00003000   00000000,00002000   00000000,00001000   
    00000000,00050000   00000000,00040000   00000000,00030000   00000000,00020000   00000000,00010000   
    00000000,00500000   00000000,00400000   00000000,00300000   00000000,00200000   00000000,00100000   
    00000000,05000000   00000000,04000000   00000000,03000000   00000000,02000000   00000000,01000000   
    00000000,50000000   00000000,40000000   00000000,30000000   00000000,20000000   00000000,10000000   
    00000005,00000000   00000004,00000000   00000003,00000000   00000002,00000000   00000001,00000000   
    00000050,00000000   00000040,00000000   00000030,00000000   00000020,00000000   00000010,00000000   
    00000500,00000000   00000400,00000000   00000300,00000000   00000200,00000000   00000100,00000000   
    00005000,00000000   00004000,00000000   00003000,00000000   00002000,00000000   00001000,00000000   
    00050000,00000000   00040000,00000000   00030000,00000000   00020000,00000000   00010000,00000000   
    00500000,00000000   00400000,00000000   00300000,00000000   00200000,00000000   00100000,00000000   
    05000000,00000000   04000000,00000000   03000000,00000000   02000000,00000000   01000000,00000000   
    

    EDIT: Here's a revised code loop that eliminates the double #'s and makes the port number a simple index of OUT nibbles.

            mov bcdlen, #8
            mov portnum, #14
    .loop1
            mov banknum, #5
    .loop2
            mov outb, #0
            mov outa, #0
    
            altsn   portnum, #OUTA
            setnib  banknum
    
            mov pa, outb
            call    #itoh
            mov pb, #","
            call    #putch
            mov pa, outa
            call    #itoh
            call    #putsp
            djnz    banknum, #.loop2
    
            call    #putnl
            djnf    portnum, #.loop1
            call    #putnl
    
  • VonSzarvasVonSzarvas Posts: 2,712
    edited 2022-06-20 08:39

    @evanh said:
    Like Rayman, I figured it was better to have them both together than only use one.

    You really should have some isolation because the VOUTs will vary- at least balancing resistors. I think our friend Yanomani already covered reasons, and this app-note also explains:
    https://fscdn.rohm.com/en/products/databook/applinote/ic/power/linear_regulator/parallel_ldo_an-e.pdf

    Nope, kept well clear of those header pin holes. Had to spend extra time being creative with those routes compared the regular header sockets.

    I meant that the DRC check might consider the 12 TH's as unconnected and throw an error. You could route to either the hole or the smt pad (assuming the TH's are plated), but that's another thing. I was just thinking of reasons that the DRC might bug you, and that it could be upset if it expects all the smt AND TH pads to be connected to the net, whereas you may not have connected the TH's in the layout. Sure, that all depends on the part creation and schematic too... just hunting for gotchas!

    One other reason to ensure the SMT and TH pads are physically connected on the layout- in case you run out of the nifty low-profile connectors and decide to stick some TH sockets instead. Then you will need those TH pads joined to the signal traces.

    -This all might be moot. Your part may have the pads joined at the hip anyway ! Not used KiCAD, so I don't actually know how/when it would throw DRC errors on such a part.

  • Incidentally, if your aim was to source more current, then would 500mA be sufficient ? One of those LDO's will provide that.

    300mA is the nominal output current, yet the NCP114's are capable of providing up to 600mA (in theory) current limit. In testing I noted that 500mA was a reliable expectation without significant voltage drop across a range of temps.

  • evanhevanh Posts: 13,106
    edited 2022-06-20 09:49

    @VonSzarvas said:
    -This all might be moot. Your part may have the pads joined at the hip anyway ! Not used KiCAD, so I don't actually know how/when it would throw DRC errors on such a part.

    They are pads but aren't assigned a signal. They're type "NPTH, Mechanical". Which I take to mean just a drill hole.

    DRC only has a single error for C8 overlapping of J2. There is a hundred warnings for touching silkscreens, but also a few for unconnected vias too.

  • roglohrogloh Posts: 4,217

    @evanh said:

    @rogloh said:
    Will you need to patch the executable with the correct nibble and correct OUT register?

    Oh, the nibble number is immediate addressing ... ALTSN + SETNIB might be the way - so one extra instruction ...

    EDIT: Yep, that works a treat:

    Not too bad.

  • evanhevanh Posts: 13,106

    @VonSzarvas said:
    ... and this app-note also explains:

    My feeling is, since the LDOs are not only from the same manufacturer but also the same batch, they'll be well matched. Within 0.5% of each other.

  • RaymanRayman Posts: 12,650
    edited 2022-06-20 10:24

    @VonSzarvas got to the first paragraph:
    Even though the two LDOs may use the same rated output voltage, in actuality the output voltages vary between manufacturers.

    But I’d guess you have not just same manufacturer but same batch in most cases, right? (Ooops @evanh already said this)

    Also, looks like worst case is that all current supplied by just one ldo. I think that’d be ok for this particular application.

    But I do like the idea of ballast resistors when high power is needed.

  • VonSzarvasVonSzarvas Posts: 2,712
    edited 2022-06-20 10:30

    Yeah, the issue is that even from the same batch/mfg, VOUT will vary by some tolerance. However small, whatever the variance amount (which will increase with load), it will mean one LDO carries the weight. If you keep below 500mA total load then it may not matter. Generally you'd want to add the shunt resistors though, which will introduce some voltage drop and additional power dissipation, so not an ideal solution. Better to use one larger LDO on the addon if you need more current and a common rail, or just split the voltage busses according to which LDO is related to which set of IOs.

    • Edit: Then again- it's a prototype, so go wild ! :) Over obsessing delays play !
  • evanhevanh Posts: 13,106
    edited 2022-06-20 11:09

    Henrique's idea of one for VDD and one for VDDQ is a decent approach but there isn't a spare layer for distributing split rails so it would need hand layout to split a layer. Something I don't know how to quickly and not much interested in the tediousness of every chip.

  • YanomaniYanomani Posts: 1,419

    @evanh said:

    @Yanomani said:
    ... it'll take many "eons" on this crappy wi-fi I'm using...

    I'm guessing wired is not an option.

    No, unfortunatelly it's not.

    The only-lonelly wires here are the power cords and some mundane cables, connecting things like the VGA monitor, and sure, some USB interconnections too (though I'm still lacking any 3.0 Hub)...

    Coax and fiber are available at the neighbourhood (at a premium), but my 4G-wi-fi contraption is "gratis" anyway, so the speed-penalty happens to be my solelly option... :smile:

  • evanhevanh Posts: 13,106

    4G is cellular. How is that not billed to you?

  • YanomaniYanomani Posts: 1,419

    @evanh said:
    4G is cellular. How is that not billed to you?

    There's this friend-of-mine who runs a very large business, where 4G and wi-fi are a must have; their success depends on it.

    So a large number of ever-ready spare equipment is essential, just in case something went haywire (accidents, equipment crashes, whatever). As technology evolves, old stuff is left behind, replaced by new (and feature-enhanced) stuff. I just need the basics, for everyday use.

    He uses to call whenever some consulting/support is needed, and I'm happy to provide as much help as possible. :smile:

  • evanhevanh Posts: 13,106
    edited 2022-06-21 06:11

    Decided to have a play with splitting a layer for power. Learning the tools. It worked out a breeze using zone priorities. The biggest hassle was the doubling up of capacitors and vias for them, shifting labels. (And some bug with VDD changing to VCC after every edit of the schematic. :( )

    And snap of schematic:

    EDIT: Updated with revised pins for bank select nibble and SCLK.

  • roglohrogloh Posts: 4,217
    edited 2022-06-21 04:57

    How big are these memories @evanh ? Is it 8MB or 16MB per device?

  • evanhevanh Posts: 13,106
    edited 2022-06-21 05:03

    @rogloh said:
    How big are these memories @evanh ? Is it 8MB or 16MB per device?

    Take your pick. I've not ordered any parts. I'm assuming HyperRAMs will fit also.

  • roglohrogloh Posts: 4,217

    Well 16MB is a better match for my bank size in my driver if you need contiguous banks. 8MB will incur some foldover currently, but for single bank setups this is not typically an issue.

    Doesn't seem like you save any IO pins with the 138 decoder in the 6 device setup, this board still burns two 8 bit expansion ports and has 3 IO pins left.

  • evanhevanh Posts: 13,106
    edited 2022-06-21 06:13

    @rogloh said:
    Doesn't seem like you save any IO pins with the 138 decoder in the 6 device setup, this board still burns two 8 bit expansion ports and has 3 IO pins left.

    Yep, I liked the nibble approach above. So two spare I/O for something else. Could make the board larger.

    EDIT: I suppose DQS could be moved to high bit of the nibble. It'll default as an input during bank select. That'll free up the third I/O pin. EDIT2: Maybe SCLK would be better choice. Its OUT is overridden by the clock smartpin.

    EDIT3: Done. The post (#116) with files attached is updated.

  • RaymanRayman Posts: 12,650

    Tried to run MegaYume with the 24 MB (3 chip, 4-bit) module today.
    Doesn't seem to work with any of these settings I've tried:

    PSRAM_WAIT  = 10'10
    PSRAM_DELAY = 3'3
    

    Did test with @rogloh 's video test at the same clock freq and that works...

    Added pullup resistors on the other two chip's CS lines, but that didn't help.

    Might try removing the two unused chips.
    Or, maybe wait for @Wuerfel_21 and @rogloh to get their modules and figure it out...

Sign In or Register to comment.