Skip to main content ↑ ↓
Topic: Revision 2 design discussion. (Read 11414 times) previous topic - next topic

Re: Revision 2 design discussion.

Reply #30 –
[quote author="jack.gassett"]
It's funny how you think you can do something and then reality comes along and smacks you right in the head when you sit down to do it.

It looks like there are not nearly enough pins with the existing design to add SRAM.
[/quote]

Here's a quick thought if you are hurting for pins. Since the memory will only be accessed in a sequential manner (incoming data is stored sequentially, and read back to the pc sequentially), you could use an external counter to drive the address lines. 74HC4020 is a 14 bit counter that could be used to drive some of the lines of the SRAM- say the upper 14- while only requiring a clock input. This would reduce the number of lines from the FPGA required to drive the RAM by 12 (replacing 14 of the address lines with 1 clock for the counter and 1 reset). I'm not sure if the additional complexity is worth it, but I thought I'd add this to the discussion.

On digikey, a 100 MHz part is $1.30 (QTY 1), while slower parts are under $.20. Keep in mind that the upper address bits change slower, and so a slower counter maybe used as long as timing hazards are taken into account (you may want to look at synchronous counters, eg 74xx160, but you usually get a lot fewer bits; you may have to chain multiple chips together).

Re: Revision 2 design discussion.

Reply #31 –
The complexity of a four-layer board isn't just the cost (which is about ^2 more expensive) for boards, it's that eagle only supports 2 layers in the free version. I have a registered copy for my work, but it's not the 'big' version. If we used the 'big' version, then most people wouldn't be able to use the files.
Got a question? Please ask in the forum for the fastest answers.

Re: Revision 2 design discussion.

Reply #32 –
Why not use a header, and move some of the peripheral circuitry to a wing?
or alternatively
If we can't handle 4 layer boards then why not a stacking shield AKA Arduino, if the pins are set at all 4 sides some horizontal and some vertical we could expand functionality without the Gerber/Eagle issue and/or expanding the maximum area required for the free Eagle option?

Mac

Re: Revision 2 design discussion.

Reply #33 –
Following swissMacs idea ... stacking the SRAM (and some of the peripheral circuitry) on a shield might open two options: keeping the design to 2-layers and ... making the base platform the high-speed JTAG adapter ian is working on ;)

Beyond that users could chose if they need and/or want to spend extra money on the external SRAM and extra features or go with a basic LA and a versatile JTAG adapter.

Re: Revision 2 design discussion.

Reply #34 –
[quote author="ian"]eagle only supports 2 layers in the free version. If we used the 'big' version, then most people wouldn't be able to use the files.[/quote]I totally understand.
I just hope that people actually make use of the Eagle files in a significant way. I worry that anyone who actually has the money to produce a board on their own is probably going to be able to afford to license Eagle anyway, in which case a 4-layer board would perform better in more than one way.

[quote author="swissMac"]
Why not use a header, and move some of the peripheral circuitry to a wing?
or alternatively
If we can't handle 4 layer boards then why not a stacking shield AKA Arduino, if the pins are set at all 4 sides some horizontal and some vertical we could expand functionality without the Gerber/Eagle issue and/or expanding the maximum area required for the free Eagle option?[/quote]There's a big problem with this. Stacking a pair of two-layer boards does not solve the same problems that a 4-layer board can handle. If you can actually route all signals to headers, then you probably can route the same signals to chips on the board. Sometimes the signals are too tight and jumbled, such that you can't actually access all of them without drilling down to other layers - then a 4-layer board is your only choice. It really helps to have power on the added layers because chips like the VLSI have many redundant power and ground pins, and those can drill directly to a power plane with a via under the chip, making it possible for the non-power signal traces to be routed away from the chip with less congestion. There are also many problems with power that are solved with power planes (although some new problems are created).

Another issue is that designing high-speed circuits which span multiple boards is a bit harder than the same design that's confined to a single board. Perhaps 200 MHz is not fast enough to be an issue, but I suggest that multi-board designs be avoided unless absolutely necessary. The DSO Wing for the OLS makes sense as a daughter board because it is so vastly different than the core.

As for peripheral circuitry, especially optional chips like additional SRAM, it has already been suggested that pads be placed on the PCB but not populated by default. Then users can add the chips without the cost of a second board. This assumes that there is room. Of course, 2-layer requires more space between chips since the traces cannot use more layers, so things can get tight very quickly.

In any case, I mention these issues just so they're considered. If there are a great deal of people using these designs on their own, then perhaps the balance of tradeoffs will shift.

Re: Revision 2 design discussion.

Reply #35 –
Does the input level-shifting buffer need additional bypass capacitance?

A few people have reported seeing noise at high frequencies on some channels on the buffered inputs. A quick look at the datasheet shows 4 separate Vcc lines but they're not bypassed separately, there's only a single bypass cap at the top of the chip, which is likely too far away for the lower power/gnd lines.

Just a thought.

Re: Revision 2 design discussion.

Reply #36 –
Gridstop, thank you for the input/thought. We will look into this but as of now the noise/glitches reported appear to be mainly related to the RLE feature (they seem to occure only when RLE is enabled). The problems related to the RLE feature will have to be addressed/fixed in the VHDL code.

I agree that we should consider adding at least one more bypass capacitor on the other side of the input buffer chip if the redesign will have onboard buffers.

Re: Revision 2 design discussion.

Reply #37 –
if youre gonna add SRAMs, you can go for infinite capture length...
changing the usb controller to something like an FX2 would improve the transfer speed tremendously (you can use wide data buses between the FX2 and the FPGA to transfer data very fast, much faster than any UART could, or SPI)
this would enable the infinite/buffered capture

Re: Revision 2 design discussion.

Reply #38 –
Adding SRAM will not give unlimited capture length (the RAM still has a maximum size), also a faster USB chip won't give it either since USB is the limiting factor. USB2.0 speeds won't go upto 24Mbit/s sampling (this is the reason why sealogic and comparable devices had this as limit).

BTW I don't think many applications need very large buffersizes, since the interesting things only happens in a small area. With good trigger and carefull clocksetting i think you get everything you want to see in [s:]32k@8[/s:] 16k@8 channels.

Re: Revision 2 design discussion.

Reply #39 –
The High Speed of FX2 is impressive, but there is a tradeoff because it has more limitations on endpoints than the PIC.  As Sjaak says, the FX2 is still way too slow for 100 MHz sampling (less than 1/4 of the speed that's needed).

Questionable idea

Reply #40 –
I started a new topic titled "Use PIC SPI to feed Configuration to FPGA?"
I'm considering this as a suggestion for Revision 2, but it's a bit too involved and also potentially infeasible, so I decided not to tie up this thread beyond simply dropping a link.
http://dangerousprototypes.com/forum/index.php?topic=594.0