Parallax P2 PCB Questions
Cluso99
Posts: 18,069
Is there any information on the pinout for the connector and pcb schematics? I would like to prepare a couple of pcbs and keep compatibility if possible.
Comments
I was looking for confirmation about the connector, looks like it's staying as PCIe-4x
7 of 8 is really irksome, kind of like one short of a dozen.
I know the question is "when does it stop?" The answer is when it's a nice multiple of 8. P0..P47 covers two full sides of the chip.
If I had to say what power/ground pad pin to omit, I'd suggest between P39 and P40.
Since I bet P48 and up is for the SDRAM, if an NC pad is annoying, then on the RESn pin connect something off the top, like P88 or P89 there... 48 + 1 extra I/O!
I know this is kind of pedantic, but would it also be possible to have at least one idiot light on the board?
It could even be so much as a dim power LED powered from the 1.8V core voltage.
Everyone screams about cost, but there's also the cost of troubleshooting... and a light that gives an honest answer on or off can be worth 10000x its BOM cost.
I agree, but the problem is that there are only 47 pins available. P47 is used to drive the SDRAM clock, leaving P0..P46 for general-purpose use. If we pulled the byte-mask pins off the SDRAM, we could get a whole 48 for the connector, plus one for an LED. That would restrict SDRAM use to block mode, as byte writes would no longer be possible. I would be in favor of doing this, but people are concerned about the possibility of byte writes going away, even though the SDRAM driver (just software) doesn't currently support byte writes.
I'm a little bit confused (slightly).
Are there still 92 I/O pins?
Just bear with me, I'm trying to understand the I/O pin assignment.
P91 = RXD in
P90 = TXD out
Your SDRAM driver uses P85..P48.
P47 is needed for the SDRAM CLK
P46..P0 go out to the edge, along with P91 and P90
Will this board have a slot for a micro SD card?
If it does, great.
If it doesn't, then could those 4 SD card pins P89..P86 be routed out to the edge connector, in case everyone decides to use those 4 pins as the default location for an SD card?
I need a half dozen Prop2 development boards ... sitting on my desk before the Prop2 module arrives.
Come on guys, let's get with the program:)
Rich
This thought might help people deal with the "irksome" factor of being an odd number and not a perfect multiple of 8. It helped me deal with it anyway but perhaps not for others with no interest in video.
I'd certainly prefer to keep the ability to do the byte qualified accesses if/when needed one day.
Roger.
Okay, thank you, that demystifies everything.
I'm having a hard time keeping up, despite checking this board every day.
Roger, that's a great way of looking at the odd-pin situation. I never thought of it that way.
I can see the byte write thing as important to the people that want to emulate 8-bit systems, Otherwise two consecutive byte writes would be a read-modify-write, read-modify-write (6 transactions) on a word.
Alright, I'm all caught up (for now).
Thanks guys.
Hey, that actually is not much of a penalty to bear for byte writes, is it? I'm thinking we could get rid of the two byte-mask pins. It would be nice to have the SDRAM clock on Port C, along with the other SDRAM signals, plus one more pin for an LED. Then, we've got a solid 48 pins for the connector.
We've gone over this pin issue a few times before, but I'm kind of thinking that the cost of latent byte-write support is too high (for the module, anyway). It would be better to have six solid ports on the connector and an indicator LED on the module.
Also, I think that many of us have experienced the situation where we weighed the pros-and-cons of an issue and made a fairly confident preliminary decision...only to change it later (and feel embarrassed by our earlier confidence). Re-evaluation or a re-weighting of the various factors affecting a decision (though hopefully not hastily) is fair game up until the point-of-no-return. By the way, of course Chip will do what he thinks is best (even if he chooses a conservative course just for the sake of being safe), but he's in a difficult position of trying to please as many as possible. I hope our input doesn't overly perplex him. Again, it's his call, "right" or "wrong" (which depends on who's evaluating). There's always going to be trade-offs. For example, there's a price to be paid for safety that sometimes exceeds the benefits. There's also something to be said for going with one's "gut feeling" or "informed instinct" (perhaps an oxymoron).
Anyway, I'll trust Chip's judgment in this matter (easy to say when there's no choice, I realize). We had a similar discussion over the connector situation. The way I was leaning or advocating for doesn't appear to have prevailed, but I'm guessing that I'll be pleasantly surprised in the end despite my reservations, again thinking back to the times that I've changed my reasonably certain mind in the past.
If You decide to made SDRAM without Byte access -- Can You made 2 Via's that we can manuals connect to any PORT for that propose ?
We will try to fit them in.
If you put two 10k (or 22k) pulldowns on the byte select lines, and have a way to jumper to them from pins, you can recover two pins AND let people have byte masks who need them (like me).
Or, possibly better:
have 805 R's on the back, 0R to prop pin, or 10K to Vss ... with default config being no byte enables.
It is easy enough to add 0R jumpers to connect the DQM's to pins, and there is a TON of space for this under the prop2 (back side of PCB)
Regards,
Bill
Or at least are the I/O ones separate from the main one? I can't tell from your images there...
We are only talking about 1 or 2 pins here. On the P1 we had 28 free pins (excluding the download and eeprom pins) whereas we now have 47 pins free. Seems that the loss of a pin to make 48 (6 sets of 8) and remove byte access to the SDRAM would IMHO be a big mistake. It's use is not just for old emulations, but all sorts of other uses. Remember, before the quad cache and rdxxxxc instructions, spin1 used byte accesses. Not everyone will want to use the software cache to access the SDRAM.
However, if you must remove the byte access pins, please, please leave us a simple method to reattach these pins. There are a few methods already suggested, and of course there are others. IMHO without access to these for byte access would be a big mistake.
An led could be placed on P46 using a 5K resistor and a high/ultra bright led to 3v3. In fact, I often use 10K. (note: the leds on the DE0-Nano are way too bright and I cannot look at them directly for long) This pin would still be usable as an I/O with the led attached.
Cluso99: If I understand correctly, it only affects byte writes. If you want to read a byte from an odd address, you'll still need to move it from data pins 15 to 8, into bits 7..0 of the receiving register, and LDQM and UDQM don't do anything useful. So, for as fast as possible performance for an 8-bit system, you might as well just ignore the upper byte.
Or, really cool, always use read-modify-write and use the upper byte of the word as a kind of flag system for debugging or snooping your emulated 8-bit system... a flag for if it was written to as data, a flag for if it was read from as data, a flag for if it was read as code, a flag if simulated DMA read from it, and a breakpoint flag bitmask for read/write/instruction read, etc.
If vias were placed on each of P46, P47, LDQM & UDQM then we could use kynar wire to join them. AWG30 wire is 0.010" dia and AWG26 wire is 0.016" dia, so an 0.016" via hole would work for AWG28 & AWG30 kynar wire (my kynar wire is AWG30).
Now we only need a way to cut the ground trace from LDQM & UDQM. This could be done by connecting the LDQM & UDQM pins thru the via and then a small track to the ground connection. It would be preferrable for a place to cut the P46 & P47 tracks also, to avoid the lines going to the connector and being influenced externally.
I note the led is on P85 and you are using a 1k resistor and taking the led/resistor to ground. This is of course the older way we put leds on pins. I now often use the led/resistor to +V to save software inversion as it makes more sense now we no longer have to worry about hi and lo drive capability. If you place a via on P85 we could use P85 as one of the LDQM/UDQM pins. I did see it was a long way from the connector.
The way SDRAM works is, you open a row and then issue column reads and writes to that row. When you issue a pre-charge command, that row is "put away", completing the access. Having no UDQM/LDQM pins means that you must do a column-read, mask operation, and column-write to affect a single byte. It comes down to a time penalty. It would still take a few, albeit less, clocks to manually control the UDQM/LDQM pins to effect a single-byte write. There is no functional loss in leaving UDQM/LDQM low - only a few clock cycles in the case where only one byte was desired to be affected. The inescapable problem with SDRAM is that it takes a lot of clock cycles to get anything done. The only way you can get good throughput is by doing large block reads and writes.
Do you have a size for the pcb module outline as it stands now?
Solderable pads for byte mode, and a user LED on P48, sounds just great.
thanks
Lachlan
I think it's about 1.35" square, including edge fingers.
Please also add a couple of solderable pads for two prop2 pins to make it easy (and do not flow copper near the two traces that need to be cut).