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

Re: Revision 2 design discussion.

Reply #15
One issue with only 16 channels is that you won't be able to use the DSO wing together with the logic channels. Guess daisy chaining will work, although it does make it significantly more expensive.

Re: Revision 2 design discussion.

Reply #16
Another issue with 32 channels SRAM is that I cannot find reasonably priced 32 bit SRAM chip. Does anyone have any leads on one?
Jack.

Re: Revision 2 design discussion.

Reply #17
[quote author="jack.gassett"]Another issue with 32 channels SRAM is that I cannot find reasonably priced 32 bit SRAM chip. Does anyone have any leads on one?[/quote]You can just design with two 16-bit SRAM and store half words in parallel. All control signals would be identical for each SRAM, but you'd need 32 separate data lines, 16 to each chip. For that matter, if pricing dictates and board area isn't cramped, you can design with four 8-bit SRAM or eight 4-bit SRAM. The only thing that doesn't change is the number of I/O pins on the FPGA.

I thought we'd given up on support for 32 channels with external SRAM? Doesn't adding the SRAM take away from the I/O pins such that you have to drop to 16 channels for extra storage? ... or are you looking at bigger FPGA parts with lots of I/O?

Re: Revision 2 design discussion.

Reply #18
I'm getting tired towards the end of the week, I should have thought of two chips...

I think 16 channels is what is making sense here but I just want to take one last look before starting. I don't want to regret not taking a second look later. I was rejecting the pq208 chip for now because it is $5 more and quite a bit bigger. Once you start adding in the price of a larger pcb and two 16 bit SRAM chips the price starts to add up. I'm going to take another look at the 144 pin chip though, if it is only $2 more then maybe that is a better fit.

Re: Revision 2 design discussion.

Reply #19
[quote author="jack.gassett"]I'm getting tired towards the end of the week, I should have thought of two chips...[/quote]No worries. Look at the DSO wing topic, where I had a Homer moment after suggesting a MUX and Digital Pot that each only handle audio frequencies for a scope that hopes to support 100x to 1,000x the analog bandwidth.  D'oh!

I actually like the informal nature of this forum, where folks can shoot from the hip and not worry so much about asking an ill-informed question.

Quote
I think 16 channels is what is making sense here but I just want to take one last look before starting. I don't want to regret not taking a second look later. I was rejecting the pq208 chip for now because it is $5 more and quite a bit bigger. Once you start adding in the price of a larger pcb and two 16 bit SRAM chips the price starts to add up. I'm going to take another look at the 144 pin chip though, if it is only $2 more then maybe that is a better fit.
I like your thinking. It's often a very good idea to investigate features that might seem like too much at first glance. Sometimes the pieces all fall into place and it doesn't actually cost that much more.

Re: Revision 2 design discussion.

Reply #20
[quote author="jack.gassett"]
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.
[/quote]

Just a note:
I have tried to synthesize the first SDRAM controller (the very first i found on Opencores) it seems to occupy roughly 256slices (about 10% in the 250k fpga)

Re: Revision 2 design discussion.

Reply #21
Thanks, that is good information to have. Now the other concern is speed.

Re: Revision 2 design discussion.

Reply #22
The maximum clock that the synthesis process spit out was ~63Mhz.

Re: Revision 2 design discussion.

Reply #23
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. I had forgotten about all the pins that get used up with configuring the SPI flash. It looks like we need to upgrade to the tq144 or pq208 part whether we want to or not. I guess my take is if we are going to put the work into a new chip then we might as well go with the more expensive pq208 so we can offer 32 channels with 2 sram chips. The end design will be more expensive but we can offer a version with only 1 sram populated and an empty footprint.

Checked into svn are two design variations, 1 with the tq144 chip and one with p208 chip. All the pins needed for a basic configuration are connected, we just need to connect all the I/O.

Here are my notes on pin requirements:
VQ100
• According to datasheet 66 max I/O, 7 input only
   â—‹ 66-7=59 free I/O pins
   â—‹ 13 used for SPI, variant, oscillator, and m1-2 configs
   â—‹ 10 used for external triggers, PIC connections, and 2 LED's
   â—‹ Total of 59-13-10=36 I/O bidirectional pins available
   â—‹ 36-16=20 Available for SRAM
      
TQ144
• According to datasheet 108 max I/O, 28 input only
   â—‹ 108-28=80 free I/O pins
   â—‹ 13 used for SPI, variant, oscillator, and m1-2 configs
   â—‹ 10 used for external triggers, PIC connections, and 2 LED's
   â—‹ Total of 80-13-10=57 I/O bidirectional pins available
   â—‹ 57-16=41 Available for SRAM
   â—‹ 57-32=25 Available for SRAM
   
PQ208
• According to datasheet 108 max I/O, 28 input only
   â—‹ 158-32=126 free I/O pins
   â—‹ 13 used for SPI, variant, oscillator, and m1-2 configs
   â—‹ 10 used for external triggers, PIC connections, and 2 LED's
   â—‹ Total of 126-13-10=103 I/O bidirectional pins available
   â—‹ 103-16=87 Available after 16 bit Wing header
   â—‹ 103-32=71 Available after 32 bit Wing header   

   
Pins Required for SRAM
• Worst case
   â—‹ 18 address
   â—‹ 16 data
   â—‹ 5 misc: OE,CS,WE,BHE,BLE
   â—‹ 18+16+5=39
• Best case
   â—‹ 18 address
   â—‹ 16 data
   â—‹ 2 misc:BHE,BLE
   â—‹ 18+16+2=36



Re: Revision 2 design discussion.

Reply #26
An interesting thought with the pq208 is that maybe we can manage to keep the vq100 footprint inside the pq208 footprint so one circuit board can be used as either a low cost without sram option or a higher cost with sram option.

Re: Revision 2 design discussion.

Reply #27
Plus+1 on the multi-site, but are you sure a 2-sided PCB will route with both footprints?  I almost thought you'd already done the routing when I glanced at the PNG image above, but I see that they're not routed yet.

Re: Revision 2 design discussion.

Reply #28
That is one big chip. It should be easier to route with a bigger chip, I remember last time we were sometimes struggling to find pins that didn't need crazy routing.

I'm open to anything, but I'm inclined to want a 16bit prototype before taking on a 32bit board with 2xSRAM. The 32bit design seems really complex.

I'm going to grab the datasheet and take a look at how many power/ground pins there are, and get a feel for placement.
Got a question? Please ask in the forum for the fastest answers.

Re: Revision 2 design discussion.

Reply #29
How much more expensive is 4-layer? Would it help to have a couple of extra planes for power and ground?

I did a 4-layer design in Eagle with GND, 3.3V and 1.2V, and used the bottom layer to place a small plane near the chip that needed the 1.2V supply, leaving most of the rest of the bottom for normal traces.

By the way, I support sticking to a 16-bit prototype. There is still a lot that could be learned.