Continue to Site

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.

  • 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.

Status
Not open for further replies.

glowbrain

New Member
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.
 
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.
 
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.
 
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:
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.
 
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.
 
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: 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.
 
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.
 
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?
 
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.
 
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.
 
Status
Not open for further replies.

Latest threads

New Articles From Microcontroller Tips

Back
Top