PCB design

[jack.gassett]

Just checked in a potential way to route the Osc_in and Trigger_in pins.

[IPenguin]

I like this solution very much - just checked it from the repository - gives even more options than "just" Trigger_Out and Clk_Out if they would be brought out straight from the FPGA to a header. I guess Ian will have the final say ...

Honestly, I think for most users Trigger_Out and Clk_out will not be essential - they may never use them. The signals will be essential to those who want to cascade/syncronize the SUMP LA with (a second) SUMP LA(s) or other test equipment or syncronize with test circuitry/extensions. These features are usually found on professional LAs only ...

[LukeS]

I have no idea how often it will be used by others and probably is not essential to many but if it can be added without extra cost or a lot of work I would love to see it.  I use the trigger output quite a bit at work to trigger a scope.  It is a great way of catching glitches, noise, and other anomalies on datelines or other parts of the circuit that can not be seen with a LA.  I use clock_in but I don't think I have ever used clock_out so that is not as important to me, I would love to hear from others on this.  Some of the hobbyist USB LA's have clock_in, clock_out, and trigger_out like the USBee.

Jack, I like your solution and thanks for adding these two outputs

[ian]

It looks fine to me.

I moved the power supplies a little to fit the new VUSB capacitor on the board interior. Checked that in as 'g'.

Pin 38 in bank 2 is simply marked 'IP' and doesn't attach to anything. It's also GCLK0. Can we dedicate the current FPGA_AUX3 to the header, and route that pin to the PIC instead? That would give us a nice clean 4 wire interface for a future SPI data dump mode. I check this in (with g changes) as revision 'h'.

[ian]

Adding - I think it's a really great to have these professional features, even if they're placed awkwardly on the board. It really doesn't matter where they're placed if most people don't use them, and those who do just appreciate having these features on a low-priced board.

[IPenguin]

Ian, in this case I am inclined to disagree with you :D ... the 4 signals Clk_In/Out and Trigger_In/Out are not placed awkwardly at all. The header is placed out of the way of the two I/O interfaces keeping the electrical design rather clean and giving even more options than "just" the Trigger_Out and Clk_Out signals on a header.

Like LukeS, I like to use Trigger_Out and Clock_Out to take a close look at noise, glitches etc. you can't catch with the LA in circuitry before/after certain conditions are met. For this I will either keep a DSO running in continous loop-mode and stop it with the trigger signal (to look at a signal before the condition is met) or start the sampling with the trigger signal to look at it after the condition was met. Being lazy and to prevent errors when evaluating the results I use Clk_Out as a time reference when correlating the result on the DSO with the captured signals on the LA screen.

Clk_Out could be used as the Clk signal for the target circuitry as well. This allows to test the circuitry at different speeds while maintaining full syncronization with the LA without the need of an extra/external clock generator ... an other scenario is cascading two or even more SUMP LAs for situations that require more than 16/32 I/O channels. However, to take full advantage of this the existing SUMP LA client will have to be modified/extended ...

[RichF]

Am I only one that would like to see 8 bit assignable to outputs??  For use as a function genrerator extension to SUMP.   Although it would be great if I/O control was under the FPGA, I accept that routing would be difficult now.  What I see as possible woud be to add a 3 pin selection header/jumper near the bottom right corner routed to pin 1 on the transceiver(direction).
Just an idea. 

[ian]

TR1 looks tight, and there's no FPGA free pins on that side. TR2 is pretty clear, and there's free pins at the top. Would probably be OK if we moved trace 15/31 to the other side of the chip.

I've been pretty apprehensive about enabling that feature because it strays from the single-purpose LA design. The 16bits on the expander can already be used for 3v3 output, and a secondary board w/buffer can be added if necessary. On the other hand, it's nice to have another feature to list for essentially free. I'd like to hear Jack's thoughts on that, since he's worked with the buffer.

[RichF]

With the recent routing the FPGA Pins 88 & 89 have been used (which are input only) thus only the first 8 bits: TR1 can be bi directional.  As Ian pointed out there are no pins available on the right side, so routing the TR1 to a top FPGA pin would not be clean.  Therefore, I suggested control by way of a jumper.  NOTE: Not as clean, if holes were provided near the TR1 and at a top available FPGA pin, a jumper wire could be added if the user needed this feature to be controled by the FPGA.

Ian stated my opion its a "feature" that is basically free

[ian]

Ah, thank you for being on top of that. I did those changes and routing, and I didn't realize they were input only.

[jack.gassett]

I noticed that input only pins were used but figured it would be fine since the buffer was set to input only.

I'd like to keep things simple and just leave it as input only. The 16 bit Wing header can be used for function generator and other addon functionality. I would like for the primary functionality of this board to be dead simple. It could get confusing for people to have to make sure jumpers are setup properly. As it is using a Logic Analyzer might be challenge enough for some beginner hobbyist users without our complicating it even more.

[RichF]

On second thought it looks to me, routing TR1 following "tdi" signal to pin 11 on the FPGA is not bad, and minimal impact to ground plane.
If a feature can be added for no cost ....why not?? 
opps should have gone to TR2

[RichF]

As I suggested to Jackeariler, if you rotate the chip 180 deg on both the sch/brd (because the transceiver is symetrical it will not change the I/O pin assinments) the pin 1 of the buffer can be easily routed to the FGPA pin 11
Note Dir tr2 now is attached to 3v3

[LukeS]

I was looking through the PIC datasheet and the SPI data out pin (pin 18) is not connected to the FPGA in the USB-uC-FPGA-h Rev. 48 schematic

[ian]

This PIC has PPS, we assign the peripherals to any of the RPx pins. It keeps the routing as easy and clean as possible.