Hello all. I'm looking for some information about Altera's FPGA. I have
this Cyclone V GX dev board:
It has a 160-pin HSMC connector, which connects using this flexible cable:
I'm wondering if this connector can be used for general purpose off-board
communication for custom uses outside of connecting to other Mezzanine
boards? Could I, for example, connect some wires to the pins and signal
them independently for GPIO?
Or... is this cable interface something proprietary that only allows
interconnect between Mezzanine devices?
Rick C. Hodgin
I think you are better off not using the FPGA eval board and just making
your own board with the 386 and the FPGA. The adapters and cables are
going to add a lot of capacitance and noise to your signals. Why mess
with the added complexity?
You may need to slow down the Cyclone IO edges. If memory serves the
V has sub ns rise times. Your cable and 386 input cap will help limit
that some. Of course pay close attention to the setup and hold times
the 386 is going to require.
At one time PLX had local bus to pci chips. I have not checked on them
lately. They got bought by Avago some time back. They may only do
You won't have trouble with lines that are essentially data lines, you
don't care if they ring. The trouble will be with clock like lines.
That will include the actual clock and potentially the read/write
strobes depending on how you implement the interface circuit.
More importantly, you may have trouble with ground bounce. I've put my
scope on the far end of disk drive ribbon cables before and the noise on
the ground can be horrendous.
The issue is not the clock rate, it is the edge rate. You can configure
the FPGA for slower edge rates, but you can't do anything about the 386
edge rates. Running 100+ signal lines over a ribbon cable is just not a
good idea unless you use differential signalling. You may get away with
it, you may not. Since you are building a custom board anyway, why not
just include the FPGA?
The other way to do this is to use a set of bidirectional
latches/buffers and let the FPGA access the interface via a simple
serial interface using LVDS signalling. The FPGA already includes this
functionallity. You just need to add a few interface chips to the 386
board along with your quickswitch devices.
The board I intend to build will have three female mates to the
three male GPIO interface ports on the HSMC adapter card. It will
plug straight into it. No ribbon cables. Just a direct connection.
As I understand it, the level shifters will introduce a delay, which should
not be an issue at much slower clock rates.
I do intend to build a direct coupling board. I could envision also a
second FPGA on it for some purpose. Not sure what that would be, but
I could see it.
BTW, my goals are not to have 30 year old technology, but rather to
start somewhere. I am familiar with 386, it is ubiquitous, and it's
I look forward to LibSF 386-x40 coming to life.
Rick C. Hodgin
That's better, but the issue is as much the length as it is how the
connection is made. I suppose there will be many ground connections on
all of the sockets? Signal integrity is key.
If you use the quickswitch parts you get less than a nanosecond delay.
They aren't buffers, they are transmission gates that limit the voltage
range on the 3.3 volt side.
Lol, if you don't know the purpose, that's not very good vision. Try
focusing on the things you can see clearly. Normally a goal is in mind,
then the path is selected to reach a number of smaller goals on the way
to the main goal. You seem to be plotting a path without clear
Assuming this is the standard Altera/Terasic 40 way pinout, there aren't.
There's two ground, one 3.3V and one 5V per socket, at roughly 1/3 2/3
positioning. The rest is GPIO. You might get away with purposefully
grounding some GPIOs at the other end, but if Rick needs ~100 IOs there
aren't many to play with. Each socket has (if I remember) 34 I/Os and two
On the other hand, we get away with driving 40MHz video signals over ribbon
cable with that connector so there is some leeway. YMMV of course.
I began studying the 80386 data sheets last night. There are only 19 control
pins which will be used in a 32-bit bus implementation that does not support
address pipelining. And only 16 if a math-coprocessor is not used. And only
14 if there isn't an arbitrated system bus. The rest are 30 address pins, 32
data pins, and either Vcc, Vss, or not connected.
Of those 14 pins:
1 is the clock signal
4 are address byte enablers (32-bit writes, 1 pin
per byte to read 8-bit, 16-bit, 24-bit, or 32-bit)
4 define the bus cycle definition
2 defines the bus control operation
2 define interrupt, non-maskable interrupt
1 is reset
It is an incredibly simple design. The Intel 80386 manuals also define
timing for their 20 MHz to 33 MHz parts. I'm assuming the Am386 would
follow similar protocols.
Edge timing appears to be 4 ns, so that will need slowed. The rest
would seem to fall within the clock cycle timing, but requires a certain
amount of time to pass before the data on the pins is valid, typically
in 20 or less ns, and often 4, 6, or 7 or more ns.
Rick C. Hodgin