Artix-A7 CMOD I/O Pins - Need more I/O Pins

[tnet]

Board: https://reference.digilentinc.com/reference/programmable-logic/cmod-a7/start

(Artix CMOD A7-35T).

This board comes with 48 I/O pins only. Is this board able to handle some extension board connector to allow me to use more I/O pins (~ 84 Digital I/O Pins)? If so, please state the name.

Is there any other method you know of?

Thank You.

 

Update: This board has 1 PMOD connector with 8 Digital I/O). Can I not use a PMOD IOXP: I/O Expansion Board to handle 19 I/O? Let me know.

PMOD IOXP: https://store.digilentinc.com/pmod-ioxp-i-o-expansion-module/

[zygot]

@tnet,

My assumption is that if you had any digital design experience you wouldn't be asking the question; and the truth is that no one can answer your original question without having more information such as do you want... 84 inputs, 84 outputs or 84 IOs, how much are you willing to pay, etc.

With that in mind I'll answer the question that I believe you really want to ask. Is there a cheap Artix board with 84 IO pins accessible through connectors?

Look at Opal Kelly. There are probably more options but I don't have specific experience with them. Boards with HSMC connectors will meet your requirements but they generally don't use Xilinx devices.

If cost isn't too important either of the Digilent boards with an FMC connector will work and you can buy a debug adaptor from Xilinx to provide your IO.

[xc6lx45]

for slow outputs:

https://www.sparkfun.com/products/10680

Actually, "slow" is relative. This can get pretty darn fast by CPU- or PC standards.

I use them extensively (the 74HC595, not the board), driven from an FT2232H chip using MPSSE mode at 30 MHz.

The edge-sensitive input will respond to glitches (cable reflections) in the x00 MHz range so I need to pay some attention to wiring: Either short lines, or arbitrarily long but terminated in Z0, which is e.g. 100 ohms for a ground-signal-ground-... ribbon cable or a scavenged ethernet cable.

[zygot]

@xc6lx45 ,

Well I can think of quite a few ways to increase IO for specific applications too. It just seems to me that suggesting selecting an appropriate FPGA board for a particular application is the most sensible reply to the question.  Sure, if you understand digital design and know exactly what your interface requirements will be by the time a project is done you can find ways to increase the number of inputs or latched outputs. Likely, the venture will cost more than just buying the board that meets your initial requirements. There are a lot of ways to get custom logic wrong, either in design or implementation. I have no problem encouraging someone to spend a lot of time learning but hesitate to push someone into a lengthy and time consuming adventure that is doomed to failure.

1 hour ago, xc6lx45 said:

The edge-sensitive input will respond to glitches (cable reflections) in the x00 MHz range so I need to pay some attention to wiring: Either short lines, or arbitrarily long but terminated in Z0, which is e.g. 100 ohms for a ground-signal-ground-... ribbon cable or a scavenged ethernet cable.

I'll use this sincere but inadequate advice as an example. When transmitting signals there are a lot of requirements to meet. For a uni-directional signal you have a driver ( of various topologies ) , media, and a receiver ( of compatible topologies ). The bandwidth requirement of the media has to be high enough to support the characteristics of a  particular driver and is proportional to the rise/fall times of the switching output. Reflections are an artifact that will occur where there are discontinuities of impedance from the driver, through the media, to the receiver. Driver output impedance, receiver input impedance, PCB traces, vias, stubs, connector pins, device pins or balls, wires, etc are all factors to take ito account and getting any of them wrong can contribute to all kinds of issues. There's a good deal more to be considered for competent digital design but you get the idea. Can a novice get lucky if what he wants to do is set mostly static outputs or know how to handle crappy inputs in his FPGA design? Sure. Can he generate all kinds of problems that he might not be able to diagnose much less resolve? Likely.

That's the basis for my reply.