This is a new thread to continue the SUMP hardware development.
Also posted in the new thread...
PIC side is tentatively routed, files checked into SVN. Will do DRC and cleanup tomorrow.
Changed:
*Routed PIC power.
*Moved MCLR resistor.
*Moved, cleaned up power supply.
*Added 5volt supply pin to UART connection
*Added ground VIAs to all ground pins.
*Moved a few traces here and there for cleaner routing.
Need to do:
*Connect buffer control pins, power.
*Route FPGA DONE pullup
*Choose pins for FPGA ARMED/TRIGGER LEDs
I checked in a new revision with the following important addition that I wanted to get some opinions on:
I added a ground pin on each side of the Wings connectors IO lines. This makes the Wing footprint the same as the buffered connector. So any leads that we can come up with should work with the buffered connector and the Wing connector.
Is the VIA in the middle of the FPGA power pad needed? I think I might have dropped that by accident.
I like the extra ground pad.
It looks like that via can go away. I removed it and and added to SVN.
Other changes checked into SVN:
-HSWAP connected to ground. This is how I have it with the design I tested SPI Flash with.
-Power partially routed for the buffer.
-Header added to the top of circuit board.
New version is checked into SVN.
-Everything is routed.
-Passes DRC.
-Added new header with Ext_Clock_In and Ext_Trigger_In
Ian, I had to add a new header for Ext_Clock and Ext_Trigger and it required moving some connections to the microcontroller around. Can you take a look and make sure everything still looks good on that side? I'm not too happy abou the location of this header but the Ext_Clock input needs to be on a Global Clock which limits us.
We can make branch of this board with two buffers, since it will change the size of the board I want to hear from Ian before proceeding.
TODO
-Make corrections to the anchor point on the Wing footprint.
-Make sure constraints are correct for SeedStudio.
-Much more verification.
I posted this to the old tread by mistake
Attached are the zip files for the 16 bit buffer option I proposed.
note the following changes
I moved the termination resistors to minimize the added board length.
I slid inputs 1-9 down a pin on the FPGA to accomodate the direction control pin routing
The input0-7 order has been reversed on the connections to the FPGA
inputs 8-15 have been attached to the FPGA's pins 2-5 & 9-12 The direction control for port b was attached to FPGA pin 15. I wasn't sure if pin 13 (IP) could be used? Was it okay to use these pins for the second port?
I am not a FPGA expert so let me know if I screwed up the FPGA connections
The board is 4.4in long verses the original 3.65in but with a little effor it can be reduced Also we could use the SOP package which is .1in narrower
re IPenguin remarks on the old thread:
Let me reiterate the main idea is to add a little extra board space for depopulated options (<$.50). The base board would not include the 2nd tranceiver or termination resistors. The Resistor pads would be initially bridged. All the user would need to do, would be to use an Xacto to cut the bridges and add resistors of his/her choise.
As to 1x18 etc or 2x9 configuration, with the 2x9 configuraton the user would purchase either 1 or2 probe cables since they would be identical. This keeps the base offering at a cheaper 8 probe cable.
Ideally an addon kit would be availabe having the 2nd probe set and transceiver and maybe a few termination resistors. The same 2x9 header could be used on a future "wing" to provide 24 or 32 channels
i have been keeping an eye on this cause i think its a great idea.
I have a question thats been bugging me
Why the funny layout for the addon board connecctor? wouldnt a 2x 24 (or what ever size) be cheaper and easier to work with?
anyway im sure you have a reason but just seems strange to me. Also i would suggest aligning the headers across the top of the board. just look better.
hey just noticed the license on the board is CC BY/SA/NC...since im pretty gungho about completely open source hardware im going to bow out of following this project - but please keep me updated when its in RC state, as its very very cool and i'll post about it on adafruit :)
Checked in design using a 16 Bit Transceiver with 4.5ns speed rating.
http://www.onsemi.com/pub_link/Collateral/MC74LCX16245-D.PDF (http://http://www.onsemi.com/pub_link/Collateral/MC74LCX16245-D.PDF)
I have a question about peoples opinions about numbering. The Sump Java client starts numbering with Channel 0. Do people prefer starting with Channel 0 or Channel 1?
Jack.
@Scorpia: the fancy looking header on the right bottom of the PCB is the wing adapter I/O header. The holes inbetween the pins are for standoffs to give wing boards more stability.
@ladyada: hmmm, I can see your point. On the Eagle schematics it says: "this work is licensed under the Creative Commons NONCOMERCIAL License" - yes there is a typo! ;)
/EDIT
Eventhough noncommercial is certainly a restriction (and would apply to anyone producing and selling the design) making it not completely open, I am not sure if Ian and Jack have come to a final decision under what kind of license they will release the design once it is completed. ;)
/END EDIT
@Jack: nice to see the 16-bit transceiver instead of the 8-bit buffer ... makes it even more versatile now. ;)
I prefer the numbering to start with '0' as this seems to be the most commonly used notation for data and address busses in data sheets and designs - at least I am more used to it and it will make referencing easier when using the SUMP client.
Jack. Looks good to me, I wish you could have found room for the Res pads ,
I noticed the Dir pins on the buffer IC were not routed , I hope you plan to control them with the FPGA
I prefer to start with 0 but no great conviction.
Jack question was concern for the added length because of the 10x10cm limit imposed by Seeed's Fusion promotion?
@RichF: the 10cm x 10cm limitation does not only pertain to Seeed's fusion service but to the free version of Eagle CAD as well ... maybe Ian and Jack considered this as well.
Checked in new revision with following changes:
-Routed OE and DIR pins on buffer.
-Connected Wing ground pins to ground.
-Added two number sets to the LA headers.
I think at this point is just needs a thorough checking and then it will be ready.
Rich, I looked at routing the control pins to the FPGA but wasn't able to do it without seriously disrupting the ground plane.
Jack.
The design looks like it's getting very very close to be sent to the PCB manufacturer for prototypes soon! :)
Updated the block diagram to the latest PCB design release (http://http://whereisian.com/forum/index.php?topic=184.msg1235#msg1235)
(http://http://img44.imageshack.us/img44/6136/lablockdiagramrev02d.th.png) (http://http://img44.imageshack.us/i/lablockdiagramrev02d.png/)
A quick note on the license:
Jack and I discussed it a while back, and I documented the change in the change log. I don't speak for Jack, but I had two motivations for the license change.
First, I copied parts from some of my previous CCTs that included SparkFun library parts. The (old) SparkFun library was NC, so until those parts are out of the design it has to be NC to comply with the SparkFun license.
Second, because I do the preorder thing with Seeed there's a delay in the hardware being available. It's embarrassing when my new projects are ready for delivery on eBay before I can deliver my first unit (last 2 Bus Pirate designs, for example), and I feel like that's unfair to the people who support my work through hardware purchases.
My current inclination for my personal projects (not necessarily this design because it's a partnership) is to initially release them as CC-BY-SA-NC, then toss them in the public domain after the initial preorder is delivered. For my projects, I'm really only concerned about the final PCB art, I don't usually place limitations on the schematic or firmware, for example.
[quote author="ian"]
A quick note on the license:
Jack and I discussed it a while back, and I documented the change in the change log. I don't speak for Jack, but I had two motivations for the license change.
First, I copied parts from some of my previous CCTs that included SparkFun library parts. The (old) SparkFun library was NC, so until those parts are out of the design it has to be NC to comply with the SparkFun license.
Second, because I do the preorder thing with Seeed there's a delay in the hardware being available. It's embarrassing when my new projects are ready for delivery on eBay before I can deliver my first unit (last 2 Bus Pirate designs, for example), and I feel like that's unfair to the people who support my work through hardware purchases.
My current inclination for my personal projects (not necessarily this design because it's a partnership) is to initially release them as CC-BY-SA-NC, then toss them in the public domain after the initial preorder is delivered. For my projects, I'm really only concerned about the final PCB art, I don't usually place limitations on the schematic or firmware, for example.
[/quote]
completely understand - i'll assume the current license is the 'final one' - but if you & jack decide otherwise please post up your decision :)
also, where is this mysterious changelog? all ive seen are attachments. is there a git repository i didnt see?
I'm sorry, I thought I linked to the post:
http://whereisian.com/forum/index.php?t ... 45#msg1145 (http://whereisian.com/forum/index.php?topic=156.msg1145#msg1145)
It's not so much a change log, as a log of our changes :) I posted a copy of what I wrote in the SVN commit notes to the 'rough design' topic. The project files are hosted in Jack's SVN at the Gadget Factory, and it should have a record of our daily commits.
Here's another update. I didn't post a log for the last one, so this is actually my previous two commits change log:
*Reordered PIC->FPGA connection to get rid of via/jumper.
*Reordered buffer->FPGA connection for shorter, straighter connections.
*Changed a few caps to 0603
*Moved PROG_B resistor to a better spot.
*Made a mess of LED and PROG_B routing, but will fix later.
*DRC is OK for all FPGA->buffer connections.
part II:
*Swapped PIC->ROM connections for cleaner routing.
*Cleaned up LED and PROG_B traces, I think it's much nicer now.
*Moved JTAG TDI so it doesn't cross as many I/O traces.
*cleared all possible DRC errors at 8mils.
*Moved top input traces down, made shorter, straighter.
*Where parts still had numbers: moved for readable placement (mostly PIC side).
*Added DP logo
Still to do:
*Add Gadget Factory logo
*I still think the PIC->ROM connection could be cleaner
*Verify 20mhz crystal footprint/package
*Improve ground plain
*Value/part number labels???
I could be missing it but I do not see the CLK and Trigger out headers in the schematic that are in the block diagram. There is a trigger out pin that is connect to a LED but no pin header.
Changes:
Jack made these changes:
-Fixed all traces with funny angles.
-Verified all nets on transceiver, s3e, and SPI Flash.
-Created ucf file and synthesized with VDHL design to verify placement of pins.
I made these:
*Changed crystal to cheap HC49 package
*Removed 0.01uF cap from Vusb
*Changed Vusb cap to 0603
*Rerouted MCLR for better ground plain
*Cleaned up around ROM to fit HC49 crystal
*Reoriented LEDs so traces are away from crystal
*Changed 10uF tantalum VREG output caps to 1uF 0805
*Added extra ground jumper under Q2 to PIC side
*Renumbered a few parts so like values are together
*Changes pass Fusion DRC (added DRC to SVN)
*Fixed labels on parts I disturbed.
After we sleep on this, it might be ready to go!
I don't know how often I looked at this, but it did never register that there are no mounting holes for the board. Do you have a matching case that does not need them? If used without a case at least some holes for a stand-off would be nice. Any metallic residue on the work surface might kill it otherwise.
You're right. We should size it for an available case when the design is complete, and add mounting holes.
Good point, mounting holes would be much nicer than glueing rubber feet under the board ...
For the Clk_Out and Trigger_Out signals it's correct that those signals are not brought out to a header.
Unless Jack will go through the effort of routing them to the wing header they will have to be implemented in VHDL by using I/O signals on the wing header when needed ...
I will wait for Ian's and Jack's final say before updating the block diagram.
How important are the Clk_Out and Trigger_Out signals? What are the usage scenarios?
Here are some possible solutions to add them:
-Assign Clk_Out and Trigger_Out to the Clk_in and Trigger_in headers in the ucf files. This may not work with some of the usage scenarios people may have had in mind.
-Assign Clk_out and trigger_out to the RHCLK lines on the Wing header. We will only be using one DCM so it should be able to be placed in the correct quadrant to drive the RHCLK lines. I've never done this before so there is always the possiblility that it will not work like I think it works in which case we will not be able to drive clk_out since it is not connected to a global clock line.
-If we assume that we can place the DCM in the correct quadrant to have clk_out on a RHCLK or LHCLK line then we could use one of the LHClk lines on the top for a clk_out header and have the trigger_out LED also connected to a header.
-If we want to place clk_out on a global clock line then we would have to sacrifice one of the fpga_aux lines going to the PIC. I don't think we want to do this.
I want to gauge how important this is because placing a header, especially a global clock header will require some rework and possibly some compromises.
Jack.
Ok, I just looked at the board design and how about this?
What if we add two more pins to the clock in and trigger in header and then we route fpga_aux3 which is connected to a global clock to clock_out. Then we connect fgpa_aux2 to trigger out. So fpga_aux2 and fpga_aux3 can either be used as a connection to the PIC or as clock and trigger outputs.
We would then use fpga_aux0 and fpga_aux1 for the rx and tx lines from the fpga to the Pic.
Jack.
Just checked in a potential way to route the Osc_in and Trigger_in pins.
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 ...
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
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'.
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.
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 ...
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.
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.
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
Ah, thank you for being on top of that. I did those changes and routing, and I didn't realize they were input only.
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.
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
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
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
This PIC has PPS, we assign the peripherals to any of the RPx pins. It keeps the routing as easy and clean as possible.
Per:
http://www.xilinx.com/support/documenta ... es/xapp453 (http://www.xilinx.com/support/documentation/application_notes/xapp453).
says resisters are need to couple 3.3v signals to the dedivated pins of the FPGA "jtag. Prog etc" when Vccaux is 2.5v
I didn't see them in the current design
I took a look through xapp453. We aren't using an 3v3 on the JTAG pins. Done and PROG_B are held to 2v5 with a pullup (open collector config), so the pic will only pull them low. INT_B is held to 3v3 with a pullup as specified in the other programming datasheet.
The only thing I'm not sure about is the ROM chip connections. The ROM chip is at 3v3, but I believe that's OK on all four interface pins.
I'm still learning about the FPGA setup though, so I could certainly have missed something.
We should be ok with the FPGA header. The JTAG pins are always at 2.5V, even if VCCO is set to 3.3V the JTAG pins still operate at 2.5V. The 3.3V app note is if you are going to use a 3.3V JTAG programmer (Such as a 3.3V ft2232). In our case we have put 2.5V on the VREF pin, which is the pin that will provide power to any attached JTAG programmer. So any attached JTAG programmer will operate at 2.5V as well instead of 3.3V.
The SPI pins are dependent on the VCCO settings which we have connected to 3.3V. So all SPI communications should happen at 3.3V.
This is my understanding of how both systems should work, it is great to have other people take a look to see if they agree.
Jack.
The PCBs finally arrived. They left the factory on 12/28, then sat in sorting (according to tracking) until 1/14 and arrived on 1/20. The actual shipping wasn't bad, just the processing.
I haven't assembled one, but I'm about to start.
There's a minor issue with the USB jack we chose, the retaining bump placement is non-standard. It's fine if you cut/sand then off (I used finger nail clippers). I tested with one of the USB jacks I usually use, and it fits, but the shield connector doesn't align with the footprint. This isn't usually a problem, but some idiot put a power via between the pads where the shield would land on it (that was me). Thankfully, this is easy to correct in the final revision (and/or we use a correct jack).
Here's a picture of the parts.
One board done, one to go. The first one took about 90 minutes, including e-mail breaks. I had to reseat the buffer chip about 3 times, it was a real pain.
Argh! I built the board in stages and tested after adding each major chip. It was all good until I added the FPGA at the end. Short.
I inspected with my loupe like crazy and couldn't find anything. Then I noticed that the FPGA has two dots, the larger one and the smaller one next to the folded edge. The folded edge is obviously the 'correct' dot, but I just looked for the dot and not the edge. You can see clearly in the photo that I put the FPGA in backwards. I removed it and put in a different chip correctly, now it powers up fine. Unfortunately I imagine I killed one first FPGA.
Ian,
I did the same exact thing with the first board I built that uses the Spartan 3E chip, but it took me a lot longer to realize my mistake. If memory serves me correctly, it was a couple years ago, the chip was fine once it was oriented correctly.
Jack.
Ian,
As far as the buffer chip goes do you think we need to adjust the footprint to make it easier to solder? I used a script from the cadsoft website to generate the tsop footprint. Do the pads need to be lengthened?
Jack.
I thought it's just a lot of tiny pins to get lined up, I didn't think anything could be done.
nice looking board in the end.
but damm that pic looks big. is it worth looking into a smaller footprint for the pic on a later revision?
might free up some board space or reduce the pcb size a little.
either way, looks nice guys.
The 18f2550 usb pic has an integrated 3v3 regulator and only comes in SOIC. I thought the 24j50 was the same, but it turns out there's an SSOP version. I'd have no problem using it in the future, but we still need the board space for the other components.
Here's another picture of a built prototype board:
I received a prototype assembled by Ian yesterday - close to pick and place quality - thank you very much :)
(http://http://img145.imageshack.us/img145/7356/p1250541.th.jpg) (http://http://img145.imageshack.us/my.php?image=p1250541.jpg)
Ian, if you need an extra FPGA or any of the other components, let me know. I have some spares and can ship them to you.
Better quality picture of prototype board.
Hi
For a new revision, I would consider logic input gates and an adc, so an input voltage treshhold could be set.
The trend goes to lower and lower voltage systems. Such a feature would be much more important for me than bandwith.
Cheers
Rubi