- results of physical inspection of pluto-p board
22 ohm series resistors on 7 pins between FPGA and 10 pin header, including
+Q
pins 5, 8, 9, 10, 13, 16, 93
** these are din_1 through din_7 .. makes sense?
**DONE**
db25 pin 11 to sole pin side of one "1L" transistor, one lead to ground,
- 4.7k from remaining lead to pin 87
+ 4.7k from remaining lead to pin 87, another 4.7k between pins 87 and 90
db25 pin 11 is nWait .. so it looks like nWait is being driven by
a transistor from the FPGA DEV_CLRn output, not directly
**DONE**
+ why not treat all the parallel port input pins with transistors?
+
+ http://emergent.unpythonic.net/01165081407 has an answer, that they
+ are used as inverters because the FPGA has weak pull-ups on those
+ pins yet those pins need to be driven low or the PC can't configure
+ the FPGA by "printing to it" .. apparently that only applies to the
+ two pins that have the inverters on them.
+
+ Duh. Of course they're inverting... how'd I miss that?
+
+ **DONE**
+
pin 49 hooked to pin 51 .. nCONFIG driven by nConfig
**DONE**
**DONE**
26 pin header pins 11 and 12 to sole pin side of "G1" transistor, both other
- leads have caps to ground, one to pin 24, the other to pin 37, 35
+ leads have caps to ground
- those header pins are VCC?
- pin 37, 35 is VCCIO
- pin 24 is TMS
+ if it's an NPN transistor:
+ emitter attached to VCCINT
+ base and collector both to VCCIO
+ VCCIO is driven by 3.3V regulator, VCCINT is not
- WTF?
+ 4.7k between pins 87 and 90
- SOT-23 with G1 label could be:
+ pin 87 is DEV_CLRn driving nWait to the PC
- transistor, 1=B, 2=E, 3(sole)=C
- fet, 1=G, 2=S, 3=D
+ **DONE**
- so:
- TMS is driving base or gate
- 3.3V is on emitter or source
- header VCC is on collector or drain
+2013.04.28
+- studying design on the way home from POSSCON 2013, hoping to figure out
+ what the problem is between the parallel port and the FPGA that is causing
+ configuration to fail.
- TMS is 'test mode state' on the jtag interface, which drives the TAP
- controller state machine. TMS going low starts a cycle?
+ Something seems odd between the docs and what I think I found during
+ physical inspection of the pluto-p board.
- 4.7k between pins 87 and 90
+ I have nWrite on pin 75, while the KNJN document says nWrite is parallel
+ port pin 1 and that should be on FPGA pin 90. The pluto_servo.pin file in
+ the EMC2 pluto-p driver directory seems to say that pin 75 is a bidir DCLK
+ signale, and pin 90 is an nWrite *input*. The parallel port doc says that
+ pin 1 is nStrobe in SPP mode and nWrite in EPP mode. In both cases, that
+ seems like a signal from the PC to the FPGA (strobing data in). Reading
+ the verilog source, nWrite is indeed an input to the FPGA and is used to
+ determine the EPP mode.
- pin 87 is DEV_CLRn driving nWait to the PC
- pin 90 is CLOCK hooked to db25 pin 1 whcih is nWrite
+ The pluto_servo.pin file says that pin 87 is nWait which is an output from
+ the FPGA. Everything seems consistent in suggesting this should be driving
+ pin 11 on the parallel port through a transistor inverter.
- why not treat all the parallel port input pins with transistors?
+ I cannot fathom why pin 87 should have a 4.7k to pin 90.
+
+ I'm not at all sure how I ended up with pin 75 (DCLK) connected to parallel
+ port pin 1.
+
+ SO...
+
+ - I think FPGA pin 75 should not be part of the nWrite net.
+ - I think FPGA pin 90 needs to be part of the nWrite net.
+ - maybe try removing R23 which is the 4.7k between FPGA pins 87 and 90,
+ and/or figure out what I was counting wrong!
+2013.04.29
+- put the pluto-p under the microscope .. and low and behold, pin 75 and pin 90
+ on the FPGA are *both* connected to parallel port pin 1!
projects / hw / cncfpga / blobdiff