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

Revision 2 design discussion.

We are looking at the next revision of the OLS board that will include SRAM. If we stick with the current design and the VTQFP-100 footprint we will have to go to 16 channels in order to have enough I/O pins. For the next revision I propose the following changes:

-16 channels
-16 bit 4M sram chip
-One 16 bit Wing slot that uses a bus switch for bidirectional 5V tolerant I/O. For an example of using bus switches look at my Butterfly Uno board: http://www.gadgetfactory.net/gf/project/butterfly_uno/
The bus switches allow bidirectional 5V tolerance with very little propagation delay.

Here are two potential SRAM chips to use:
-4M part for 256K on 16 channels
   http://search.digikey.com/scripts/DkSea ... -1476-5-ND
-1M part for 64K on 16 channels
   http://search.digikey.com/scripts/DkSea ... -1450-5-ND


Jack.

Re: Revision 2 design discussion.

Reply #1 –
Why not use some SDRAM?

Re: Revision 2 design discussion.

Reply #2 –
I think for the first one with external RAM  we're kind of worried about the complexity of SDRAM on a 2-sided board.

Previously we had discussed using a cheaper (less BRAM) FPGA with an external RAM chip. Do you still think that's a possibility?
Got a question? Please ask in the forum for the fastest answers.

Re: Revision 2 design discussion.

Reply #3 –
i don't think that routing SDRAM is more difficult as SRAM. They have almost the same number of pins (SDRAM having few extras)

Smaller FPGA might do the trick,  it depends on the complexity of the VHDL code. I personally would go with prototype that has larger fpga, and mass production with smaller (if the design fits).

The price difference between 100k and 250k fpga is about the price of 128Mbit ram :)

Re: Revision 2 design discussion.

Reply #4 –
In my opinion it doesn't make sense to save $3 on less RAM, since it takes zero extra design or assembly effort. More samples, a faster sample rate and more channels are always better for a logic analyzer, so if you can increase one of those without much extra money or effort, you should do so.

Re: Revision 2 design discussion.

Reply #5 –
I originally was going to use SDRAM instead of SRAM but now I feel that SRAM is the better choice.

I'm not too worried about routing the SDRAM, it would be fairly straight forward. I'm more worried that SDRAM is a radical step away from the original Sump design. There is a LOT more work and uncertainty involved with using SDRAM instead of SRAM. Every thing is already in place for SRAM to just work and we can feel confident that the first prototype will be successful.

With SDRAM there are the following questions:
  • We need to achieve 100Mhz speed, will we be able to? I seem to recall from my distant experiments with SDRAM with the EDK that I always had to revert to 66Mhz to get my designs to work with the Spartan 3E.
  • We need to implement a SDRAM controller into the Sump core for SDRAM to even work at all. With SRAM everything is already in place.
  • Synchronous vs. Asynchronous. Are we going to have trouble at lower sampling speeds with a synchronous SDRAM running at 100Mhz?

These are obviously all things that can be worked out but the question is what does it buy us to commit to so much effort? SDRAM is cheaper but I think the 4M SRAM option is reasonably priced so that benefit is negated. The only benefit that I see is that we can get a LOT more memory using SDRAM. But then comes the question of how much is too much? Looking at the java client the highest sample depth is 256K which is exactly what we get with the 4M part.

This leads me to conclude that the price to pay, in effort and the potential for lost time, for SDRAM is not worth it and SRAM is the logical route to take here.

Re: Revision 2 design discussion.

Reply #6 –
Oh right,

Forgot to mention that the other consideration is that if we go with SRAM then we can most likely move to a 100k FPGA instead of the 250k. If we go with SDRAM then we will need to stick with the 250k FPGA in order to implement the SDRAM controller. So that is another huge reason to go with SRAM.

Jack.

Re: Revision 2 design discussion.

Reply #7 –
[quote author="jack.gassett"]
If we stick with the current design and the VTQFP-100 footprint we will have to go to 16 channels in order to have enough I/O pins.
[/quote]

While I see that you really would like to reduce the complexity and cost of the design, I think there would be significant value in retaining the 32 channel capability. While most people don't need more than a 16 channel logic analyzer, many of us would find running both the logic inputs and the wing connector at the same time very useful, allow the use of add-ons such as the proposed oscilloscope wing in parallel with the logic analyzer. This would enable mixed-signal scope functionality, which is something that I use regularly.

If you are concerned about pin count, I would suggest moving up to the 144-TQFP versions of the chip if possible. It isn't that much bigger, and would provide the necessary pins to support 32 channels and external SRAM. For both the 100K and 250K gate chips, the difference is about $2 (on digi-key, single unit qty). I would definitely pay more money to retain the 32 channels.

Re: Revision 2 design discussion.

Reply #8 –
Would it be possible to maintain the 32 input channels, but have the FPGA rearrange those samples to fit an 8-bit or 4-bit SRAM or something like that?  Glancing at the design, it looks like the OLS currently has 32 parallel inputs and produces 1-bit serial output data.  Changing that to feed a 16-bit SRAM certainly requires more I/O pins, but maybe the FPGA could rearrange those bits into 4-bit or 8-bit chunks instead.  I've not done any FPGA programming yet, so I have no idea how difficult that would be.

Re: Revision 2 design discussion.

Reply #9 –
If you were to rearrange the design to use 8 or 4 bit RAM, then you need twice or 4times the data rate to RAM.
I'm not sure, but it seems that 200Mhz is pretty much the edge of the -4 grade FPGA.

Standard JTAG header?

Reply #10 –
How about changing the JTAG to a 14-pin standard JTAG header, or some other standard?  I happen to have a 14-pin JTAG emulator that I am using for a TMS320VC5506 board that I designed and am now programming. I assume that I could use that to debug the OLS if it had a pin-compatible 14-pin header.
Also, the Dangerous Prototypes JTAG project could connect if a common standard were used.
I realize that the 14-pin JTAG standard is a bit wasteful, since it has 4 ground pins and a key, but those ground pins probably help prevent crosstalk between the data and clock signals which are reasonably high frequency.

Re: Revision 2 design discussion.

Reply #11 –
[quote author="robots"]If you were to rearrange the design to use 8 or 4 bit RAM, then you need twice or 4times the data rate to RAM.
I'm not sure, but it seems that 200Mhz is pretty much the edge of the -4 grade FPGA.[/quote]Ah, I see. The FPGA can write to its own limited memory at full speed, then download via serial in non-real-time. In order to expand the recording time, the SRAM would have to be as wide as the input bus. If all 32 pins were used as inputs, then the SRAM bandwidth would need to double again.

Here's a revised idea: Perhaps the Gadget Factory Butterfly Platform standard header and pinout could be maintained on the board, but with the caveat that the FPGA could either be programmed for Butterfly expansion, or the FPGA could be programmed to use the expanded SRAM, but not both at the same time.  This would allow a common platform to be manufactured that a larger group would find useful, even though it couldn't do everything all at once without reprogramming the FPGA.

Re: Revision 2 design discussion.

Reply #12 –
@rsdio and @leecbaker
Yes, that is the idea! The plan was to turn the header on the right side to a Wing connector and use the Bus Switches to make it 5V tolerant. If there is a need for 32 channels, or more, then multiple OLS's can be daisy chained together using the trigger in/out and clock in/out headers. This should allow mixed mode to be feasible as well, the Java client will just need to be updated to support multiple USB devices.

The other consideration for 32 channels is that we need 32 I/O lines and we need a 32 bit SRAM device if we are going to provide enough bandwidth to keep the 200Mhz sampling functionality. I've looked at this every which way over the last couple months and it always seems to come down to the need to sacrifice something. I figured that sacrificing 16 channels was the best approach since we should be able to daisy chain devices together to get back to 32 channels.

As far as the JTAG header goes, the footprint is actually a Xilinx standard footprint. It works with Xilinx JTAG programmers, for compatibility with other JTAG programmers I would get some flying leads so you can just connect what you need with minimal fuss.

Jack.

Re: Revision 2 design discussion.

Reply #13 –
[quote author="jack.gassett"]As far as the JTAG header goes, the footprint is actually a Xilinx standard footprint. It works with Xilinx JTAG programmers, for compatibility with other JTAG programmers I would get some flying leads so you can just connect what you need with minimal fuss.[/quote]Perfect. It makes more sense to use the Xilinx JTAG header with a Xilinx part. The 14-pin header is one that Texas Instruments uses, but even with them it isn't a universal choice.

Re: Revision 2 design discussion.

Reply #14 –
[quote author="jack.gassett"]
@rsdio and @leecbaker
Yes, that is the idea! The plan was to turn the header on the right side to a Wing connector and use the Bus Switches to make it 5V tolerant. If there is a need for 32 channels, or more, then multiple OLS's can be daisy chained together using the trigger in/out and clock in/out headers. This should allow mixed mode to be feasible as well, the Java client will just need to be updated to support multiple USB devices.
[/quote]

I see how daisy chaining OLSes can get the functionality that I was looking for. I had hoped that you could possibly run 2x 16 channel functions off of one device- this would reduce the hardware that I would need. However, I can see that it makes sense to support only the reduced hardware configuration (1 wing OR 16 digital channels), rather than allowing them to both be active at once.