• Welcome to our site! Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

High Switching Speed, High GPIO Count dev board.

Thread starter #1
Hi All,

I'm looking for recommendations for a fast switching embedded controller to switch up to 155 GPIO pins within 10ns of a clock pulse.
Many of the FPGA solutions we looked at are clocked a little to slow to easily manage it (50Mhz), so a higher clocked Arm with dedicated code might be the go. But I'm open to suggestions. Up till now we've looked at the PicoZed, Zynq-7000, and the snickerdoodle. PicoZed doesn't quite have the pins (although we'd make do), and the snick is a little unreliable, and they are both just a smidge too slow.

thanks in advance.
 

ronsimpson

Well-Known Member
Most Helpful Member
#2
How many I/Os will switch at one time?
I don t see how a arm can compete with a fpga. 10nS is FPGA speed. I have made HDMI 850mhz data on multiple outputs. Please tell us what you are doing.
 

kubeek

Well-Known Member
#3
There are two different aspects to that, clock to data valid timing, and clock speed. What is the data rate, 100Mhz as well or something else?
My thinking is that you would definitely need to have the data prepared in a buffer, and then clock it out to the outputs, because I don´t think you can do even much of combinatorial logic within 10ns on a not insanely costly fpga.
 

dknguyen

Well-Known Member
Most Helpful Member
#4
Did you look at the FPGA modules from Trenz? Available from Digikey.

Newer FPGAs also have PLLs onboard so you can up the frequency from the oscillator on the PCB so I wouldn't care too much about how slow the crystal actually is.
 
Last edited:
Thread starter #5
ronsimpson. preferably all of them will switch simultaneously. Application is not very exciting, just swtiching RF filters, and other custom RF stuff. Just needs to be quick.
Kubeek RE: bandwidth, it will only change every 400ns or so, but has to have GPIO changed within 10 ns of the pulse.
Yes, bitmaps definitely in a buffer, and that can happen in slow time in the background or at startup.
 
Thread starter #6
dknguyen: Thanks for the tip. Nice boards. Bit pricey, but looking good.
I've fouond most FPGA boards, even with programmable PLL's have them tuned up to the highest they can get to without hitting impedance problems. If you try "overclocking" some of the outputs start becoming flakey.
 

ronsimpson

Well-Known Member
Most Helpful Member
#7
all of them will switch simultaneously.
If 150 pins changed state in 10nS the supply will pull large spikes of current. 0 to 1 and 1 to 0. But probably most pins will stay in the same state. 0 to 0 and 1 to 1.

If you have 160 pins to update every 400nS then thats 20 bytes. One byte in 20nS. No ARM can do that. I don,t think that much data can be moved by DMA.

Have not looked at data sheets recently but clock to output delay is under 10nS.
 

dknguyen

Well-Known Member
Most Helpful Member
#8
dknguyen: Thanks for the tip. Nice boards. Bit pricey, but looking good.
I've fouond most FPGA boards, even with programmable PLL's have them tuned up to the highest they can get to without hitting impedance problems. If you try "overclocking" some of the outputs start becoming flakey.
There is also zynqboard...if you can get them to respond. Wish there was a minimalist Artix 7 board like that with just flash and clock but no power supplies.
 

ronsimpson

Well-Known Member
Most Helpful Member
#9
Yes, bitmaps definitely in a buffer, and that can happen in slow time in the background or at startup.
Many FPGAs have large memories that can be configured to look like RAM to the computer.
I did several FPGAs where the IO pins needed to be updated too fast for the computer to keep up with. So a table of 32 configurations of 150 pins are stored in memory. Then every 400nS the output is updated with out any computer help.
 
Thread starter #10
If you have 160 pins to update every 400nS then thats 20 bytes. One byte in 20nS. No ARM can do that. I don,t think that much data can be moved by DMA.
Really? at 600MHz, that's 1.6ns per cycle. Even without pipelining you should be able to do a 64bit LDM in a couple of cycles. What's the limiting factor?
 

ronsimpson

Well-Known Member
Most Helpful Member
#11
I am using a 60mhz ARM and updating at 30mhz on a port. The Raspberry Pi2 can do 100mhz pin writes. Out put 50mhz square wave. Set low, set high.

Sorry for not knowing. Please disregard every thing I said.
 
Thread starter #12
I am using a 60mhz ARM and updating at 30mhz on a port. The Raspberry Pi2 can do 100mhz pin writes. Out put 50mhz square wave. Set low, set high.

Sorry for not knowing. Please disregard every thing I said.
No Problems. Thanks for taking the time to pitch in. All genuine input is good for the discussion.
 

Latest threads

EE World Online Articles

Loading

 
Top