Altera HSMC connector

R

Rick C. Hodgin

Guest
Hello all. I'm looking for some information about Altera's FPGA. I have
this Cyclone V GX dev board:

https://www.altera.com/products/boards_and_kits/dev-kits/partners/kit-terasic-cyclone-v-gx-starter.html

It has a 160-pin HSMC connector, which connects using this flexible cable:

https://www.altera.com/en_US/pdfs/literature/ds/hsmc_spec.pdf
http://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English&No=275

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?

Best regards,
Rick C. Hodgin
 
Rick C. Hodgin wrote:

Hello all. I'm looking for some information about Altera's FPGA. I have
this Cyclone V GX dev board:

https://www.altera.com/products/boards_and_kits/dev-kits/partners/kit-terasic-cyclone-v-gx-starter.html

It has a 160-pin HSMC connector, which connects using this flexible cable:

https://www.altera.com/en_US/pdfs/literature/ds/hsmc_spec.pdf
http://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English&No=275

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?

Best regards,
Rick C. Hodgin

It's a bit of a pain as connectors go.
http://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English&CategoryNo=67&No=322&PartNo=1 makes a convenient breakout. You want the (M), to mate the dev kit, not the (F).

--
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order. See above to fix.
 
On Tuesday, April 5, 2016 at 2:53:15 PM UTC-4, Rob Gaddi wrote:
Rick C. Hodgin wrote:
Hello all. I'm looking for some information about Altera's FPGA. I have
this Cyclone V GX dev board:

https://www.altera.com/products/boards_and_kits/dev-kits/partners/kit-terasic-cyclone-v-gx-starter.html

It has a 160-pin HSMC connector, which connects using this flexible cable:

https://www.altera.com/en_US/pdfs/literature/ds/hsmc_spec.pdf
http://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English&No=275

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?

It's a bit of a pain as connectors go.
http://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English&CategoryNo=67&No=322&PartNo=1 makes a convenient breakout. You want the (M), to mate the dev kit, not the (F).

--
Rob Gaddi, Highland Technology -- www.highlandtechnology.com

Thank you, Rob. That's exactly what I was looking for.

Best regards,
Rick C. Hodgin
 
On Tuesday, April 5, 2016 at 3:03:53 PM UTC-4, Rick C. Hodgin wrote:
On Tuesday, April 5, 2016 at 2:53:15 PM UTC-4, Rob Gaddi wrote:
Rick C. Hodgin wrote:
Hello all. I'm looking for some information about Altera's FPGA. I have
this Cyclone V GX dev board:

https://www.altera.com/products/boards_and_kits/dev-kits/partners/kit-terasic-cyclone-v-gx-starter.html

It has a 160-pin HSMC connector, which connects using this flexible cable:

https://www.altera.com/en_US/pdfs/literature/ds/hsmc_spec.pdf
http://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English&No=275

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?

It's a bit of a pain as connectors go.
http://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English&CategoryNo=67&No=322&PartNo=1 makes a convenient breakout. You want the (M), to mate the dev kit, not the (F).

--
Rob Gaddi, Highland Technology -- www.highlandtechnology.com

Thank you, Rob. That's exactly what I was looking for.

Ordered. Thank you again.

Best regards,
Rick C. Hodgin
 
On 4/5/2016 3:23 PM, Rick C. Hodgin wrote:
On Tuesday, April 5, 2016 at 3:03:53 PM UTC-4, Rick C. Hodgin wrote:
On Tuesday, April 5, 2016 at 2:53:15 PM UTC-4, Rob Gaddi wrote:
Rick C. Hodgin wrote:
Hello all. I'm looking for some information about Altera's FPGA. I have
this Cyclone V GX dev board:

https://www.altera.com/products/boards_and_kits/dev-kits/partners/kit-terasic-cyclone-v-gx-starter.html

It has a 160-pin HSMC connector, which connects using this flexible cable:

https://www.altera.com/en_US/pdfs/literature/ds/hsmc_spec.pdf
http://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English&No=275

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?

It's a bit of a pain as connectors go.
http://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English&CategoryNo=67&No=322&PartNo=1 makes a convenient breakout. You want the (M), to mate the dev kit, not the (F).

--
Rob Gaddi, Highland Technology -- www.highlandtechnology.com

Thank you, Rob. That's exactly what I was looking for.

Ordered. Thank you again.

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?

--

Rick
 
Rick C. Hodgin wrote:
Rick C. Hodgin wrote:
Rob Gaddi wrote:
It's a bit of a pain as connectors go.
http://www.terasic.com.tw/cgi-bin/page/archive.pl?Language= English&CategoryNo=67&No=322&PartNo=1
makes a convenient breakout. You want the (M), to mate the dev kit, not the (F).

--
Rob Gaddi, Highland Technology
www.highlandtechnology.com

Thank you, Rob. That's exactly what I was looking for.
Ordered. Thank you again.

Received. Fits the board like it was made for it. :)

Best regards,
Rick C. Hodgin
 
rickman wrote:
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?

I'll need enough capacity to simulate my ISA, as well as drive the Am386. They will more or less execute together, with off-device debugging signals to control operations.

Would the capacitance be an issue at a few hundred KHz max? I plan to make the custom Am386 plug straight in to the three GPIO ports.

Best regards,
Rick C. Hodgin
 
Rick C. Hodgin wrote:

Rick C. Hodgin wrote:
Rick C. Hodgin wrote:
Rob Gaddi wrote:
It's a bit of a pain as connectors go.
http://www.terasic.com.tw/cgi-bin/page/archive.pl?Language= English&CategoryNo=67&No=322&PartNo=1
makes a convenient breakout. You want the (M), to mate the dev kit, not the (F).

--
Rob Gaddi, Highland Technology
www.highlandtechnology.com

Thank you, Rob. That's exactly what I was looking for.
Ordered. Thank you again.

Received. Fits the board like it was made for it. :)

Best regards,
Rick C. Hodgin

I'm glad all the research effort I put in of looking
over at the stack of same sitting on the corner of my desk and
writing down the number from the box came in handy.

--
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order. See above to fix.
 
Rob Gaddi wrote:
I'm glad all the research effort I put in of looking over at the
stack of same sitting on the corner of my desk and writing down the
number from the box came in handy.

Me too! :)

Nonetheless, and regardless of how trivial the effort was, it got me
exactly what I needed, and it was/is appreciated.

Best regards,
Rick C. Hodgin
 
rickman wrote:
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 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
easily extensible.

I look forward to LibSF 386-x40 coming to life.

Best regards,
Rick C. Hodgin
 
On Mon, 11 Apr 2016 11:12:04 -0700, Rick C. Hodgin wrote:

rickman wrote:
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?

I'll need enough capacity to simulate my ISA, as well as drive the
Am386. They will more or less execute together, with off-device
debugging signals to control operations.

Would the capacitance be an issue at a few hundred KHz max? I plan to
make the custom Am386 plug straight in to the three GPIO ports.

Best regards,
Rick C. Hodgin

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
PCIe now.



--
Chisolm
Republic of Texas
 
rickman wrote:
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.

Lol, if you don't know the purpose, that's not very good vision.

I don't know the purpose because it's your suggestion. Mine is to
use my dev board. It's been my plan all along. It's why I bought it,
for my LibSF 386-x40 CPU design.

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.

Ah:

https://github.com/RickCHodgin/libsf/tree/master/li386/oppie
http://www.libsf.org/li386/indexmain.html
https://m.facebook.com/groups/726083540851343?view=info

> You seem to be plotting a path without clear objectives.

You seem to see things incorrectly, and always disparaging toward me.

Best regards,
Rick C. Hodgin
 
On 4/11/2016 2:12 PM, Rick C. Hodgin wrote:
rickman wrote:
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?

I'll need enough capacity to simulate my ISA, as well as drive the Am386. They will more or less execute together, with off-device debugging signals to control operations.

Would the capacitance be an issue at a few hundred KHz max? I plan to make the custom Am386 plug straight in to the three GPIO ports.

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.

--

Rick
 
rickman <gnuarm@gmail.com> wrote:
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.

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
clock inputs.

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.

Theo
 
rickman wrote:
> I will refrain from posting.

My loss.

Best regards,
Rick C. Hodgin
 
Theo Markettos wrote:
... if Rick needs ~100 IOs there aren't many to play with. Each socket
has (if I remember) 34 I/Os and two clock inputs.

I need 92 GPIO pins. The remaining 40 are Vcc, Vss, or not connected.

Best regards,
Rick C. Hodgin
 
On 4/11/2016 5:23 PM, Rick C. Hodgin wrote:
rickman wrote:
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 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.

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.


As I understand it, the level shifters will introduce a delay, which should
not be an issue at much slower clock rates.

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.


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.

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


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
easily extensible.

I look forward to LibSF 386-x40 coming to life.

Good luck.

--

Rick
 
On 4/11/2016 7:13 PM, Rick C. Hodgin wrote:
rickman wrote:
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.

Lol, if you don't know the purpose, that's not very good vision.

I don't know the purpose because it's your suggestion. Mine is to
use my dev board. It's been my plan all along. It's why I bought it,
for my LibSF 386-x40 CPU design.

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.

Ah:

https://github.com/RickCHodgin/libsf/tree/master/li386/oppie
http://www.libsf.org/li386/indexmain.html
https://m.facebook.com/groups/726083540851343?view=info

You seem to be plotting a path without clear objectives.

You seem to see things incorrectly, and always disparaging toward me.

That's the second time you have indicated you don't appreciate my
comments. I will refrain from posting.

--

Rick
 
On Monday, April 11, 2016 at 8:44:07 PM UTC-4, Rick C. Hodgin wrote:
Theo Markettos wrote:
... if Rick needs ~100 IOs there aren't many to play with. Each socket
has (if I remember) 34 I/Os and two clock inputs.

I need 92 GPIO pins. The remaining 40 are Vcc, Vss, or not connected.

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.

Best regards,
Rick C. Hodgin
 

Welcome to EDABoard.com

Sponsor

Back
Top