low speed communication

Hi everybody,
I have two Virtex4 FX12 Minimodules and I'd like to make them
communicate eachother.
These modules don't have any special transciver (RocketIO, ...) and
are equipped with one PPC.
The communication doesn't require high bandwidth, I need at least 30
Mbps (more it's better).
The application is designed to implement a special math algorithm so
the communication isn't the focus of the application and thus I cannot
use all the resources for the communication.
I'm using xilinx ISE and XPS to develop the application.

Any suggestions on what I can I do? Protocols? Cores? Hardware issues
that I should take in account? Design references from where I can
start?

Thanks,

Andrea

"Andrea05" <cispa@email.it> wrote in message 
news:1180116308.623745.246240@g4g2000hsf.googlegroups.com...
> Hi everybody,
> I have two Virtex4 FX12 Minimodules and I'd like to make them
> communicate eachother.
> These modules don't have any special transciver (RocketIO, ...) and
> are equipped with one PPC.
> The communication doesn't require high bandwidth, I need at least 30
> Mbps (more it's better).
> The application is designed to implement a special math algorithm so
> the communication isn't the focus of the application and thus I cannot
> use all the resources for the communication.
> I'm using xilinx ISE and XPS to develop the application.
>
> Any suggestions on what I can I do? Protocols? Cores? Hardware issues
> that I should take in account? Design references from where I can
> start?
>
> Thanks,
>
> Andrea

How abstract is your communication?
If you're implementing a fixed data path, it's easy: clock and data.
If you want to transfer data, exchange code segments, and post an email 
through a PPC-based webserver, the need for more advanced communications and 
protocols become attractive. 

On 25 Mag, 20:21, "John_H" <newsgr...@johnhandwork.com> wrote:
> "Andrea05" <c...@email.it> wrote in message
>
> news:1180116308.623745.246240@g4g2000hsf.googlegroups.com...
>
>
>
>
>
> > Hi everybody,
> > I have two Virtex4 FX12 Minimodules and I'd like to make them
> > communicate eachother.
> > These modules don't have any special transciver (RocketIO, ...) and
> > are equipped with one PPC.
> > The communication doesn't require high bandwidth, I need at least 30
> > Mbps (more it's better).
> > The application is designed to implement a special math algorithm so
> > the communication isn't the focus of the application and thus I cannot
> > use all the resources for the communication.
> > I'm using xilinx ISE and XPS to develop the application.
>
> > Any suggestions on what I can I do? Protocols? Cores? Hardware issues
> > that I should take in account? Design references from where I can
> > start?
>
> > Thanks,
>
> > Andrea
>
> How abstract is your communication?
> If you're implementing a fixed data path, it's easy: clock and data.
> If you want to transfer data, exchange code segments, and post an email
> through a PPC-based webserver, the need for more advanced communications and
> protocols become attractive.- Nascondi testo tra virgolette -
>
> - Mostra testo tra virgolette -

Yes clock and data seems to be sufficient but there isn't a peripheral
for such kind of communication. All the SPI peripherals that I found
are Master only for off-chip communication. Moreover at 30bps there
are some electrical issues which increase the bit rate error.

Have you already implemented a peripheral for this kind of job?

Andrea,

Since there are no MGT's, you will need to use some IO's from IO banks.

You can use: some number of LVDS 100 ohm differential drivers to 
receivers (one direction only, use two sets of buses), a group of single 
ended IOs matched to a ribbon cable (with ground, signal, ground, 
dignal, this is close to 50 ohms, and can go perhaps 10 meters at the 
speed you need).

I suggest the single ended groups, perhaps 8 wires for data, and one 
forwarded clock (for nine signals), and a bus like this for each direction.

Clocking these 8 wires at even 10 MHz, would provide 80 Mb/s.  At this 
slow a rate, you don't really need to clock forward, but I still would 
suggest it (along with the data, there is the clock on the ninth wire to 
strobe the other end).  That way, you don't have to figure out how to 
get the clock off of one pcb, and get it to the other one (for a system 
synchronous solution).

Just have registers at each end, and create your own (very simple) 
protocol.  If a "data valid" or "data waiting" signal is needed, just 
use another wire.  20 wire ribbon cables are pretty common (ten signal, 
ten grounds).  Drive the transmit end with something like LVCMOS 8 mA 
FAST, which is very close to 50 ohms, and there should be no overshoot, 
or undershoot, and the Signal integrity will be good.  If that is still 
too strong, 6 mA, and even 4 mA drivers can be selected.

The only reason a protocol is required with the MGTs (like aurora:
http://www.xilinx.com/products/design_resources/conn_central/grouping/aurora.htm
is that designers need huge bandwidth, and in order to re-synchronize 
multiple MGTs (channel bonding), a layer is required to manage all that 
stuff.

With a simple parallel interface, you pretty much only need to implement 
what you need.

To connect these buses to the 405PPC, you will either have to interface 
to the PLB bus, or create an input and output port that is connected to 
the 405PPC.  Depending on how fancy you want this to be, it could be as 
simple as input and output instructions (you create the protocol in 
software), or as fancy as a FIFO buffer with DMA into memory mapped into 
the 405PPC data memory (the protocol commonly used here is referred to 
as "flags placed under a rock" which is a reference to one processor 
just waits for a memory location to change, which tells it that the data 
it is waiting for is all there, and ready to be read from memory...the 
transmitting processor sends all the data, and sets the flag to tell the 
receiving processor to pick up the data.

Lots of choices here, and not many "standards" as the task is very 
simple, and folks tend to use only what logic they need to in order to 
do the job.

Once you pop up to MGTs, there are many more choices, only because there 
are more complex interfaces:  ethernet, fibre channel, PCIe, etc.....

If you don't need fibre channel, then you don't need media access 
controllers (MAC), etc.
http://www.xilinx.com/products/design_resources/conn_central/solution_kits/index.htm



Austin

On 25 Mag, 20:45, austin <aus...@xilinx.com> wrote:
> Andrea,
>
> Since there are no MGT's, you will need to use some IO's from IO banks.
>
> You can use: some number of LVDS 100 ohm differential drivers to
> receivers (one direction only, use two sets of buses), a group of single
> ended IOs matched to a ribbon cable (with ground, signal, ground,
> dignal, this is close to 50 ohms, and can go perhaps 10 meters at the
> speed you need).
>
> I suggest the single ended groups, perhaps 8 wires for data, and one
> forwarded clock (for nine signals), and a bus like this for each direction.
>
> Clocking these 8 wires at even 10 MHz, would provide 80 Mb/s.  At this
> slow a rate, you don't really need to clock forward, but I still would
> suggest it (along with the data, there is the clock on the ninth wire to
> strobe the other end).  That way, you don't have to figure out how to
> get the clock off of one pcb, and get it to the other one (for a system
> synchronous solution).
>
> Just have registers at each end, and create your own (very simple)
> protocol.  If a "data valid" or "data waiting" signal is needed, just
> use another wire.  20 wire ribbon cables are pretty common (ten signal,
> ten grounds).  Drive the transmit end with something like LVCMOS 8 mA
> FAST, which is very close to 50 ohms, and there should be no overshoot,
> or undershoot, and the Signal integrity will be good.  If that is still
> too strong, 6 mA, and even 4 mA drivers can be selected.
>
> The only reason a protocol is required with the MGTs (like aurora:http://www.xilinx.com/products/design_resources/conn_central/grouping...
> is that designers need huge bandwidth, and in order to re-synchronize
> multiple MGTs (channel bonding), a layer is required to manage all that
> stuff.
>
> With a simple parallel interface, you pretty much only need to implement
> what you need.
>
> To connect these buses to the 405PPC, you will either have to interface
> to the PLB bus, or create an input and output port that is connected to
> the 405PPC.  Depending on how fancy you want this to be, it could be as
> simple as input and output instructions (you create the protocol in
> software), or as fancy as a FIFO buffer with DMA into memory mapped into
> the 405PPC data memory (the protocol commonly used here is referred to
> as "flags placed under a rock" which is a reference to one processor
> just waits for a memory location to change, which tells it that the data
> it is waiting for is all there, and ready to be read from memory...the
> transmitting processor sends all the data, and sets the flag to tell the
> receiving processor to pick up the data.
>
> Lots of choices here, and not many "standards" as the task is very
> simple, and folks tend to use only what logic they need to in order to
> do the job.
>
> Once you pop up to MGTs, there are many more choices, only because there
> are more complex interfaces:  ethernet, fibre channel, PCIe, etc.....
>
> If you don't need fibre channel, then you don't need media access
> controllers (MAC), etc.http://www.xilinx.com/products/design_resources/conn_central/solution...
>
> Austin

Thank you Austin for your reply, I found it very intresting.
I'll search something about your hints over internet and I'll post the
results (and surely other questions).

Just another little question. Why, in your opinion, even Xilinx in its
SPI core doesn't support off-chip Master? SPI peripheral seems to fit
well to my design requrements but it has this huge limitation... I
don't understand why... Any ideas?

Andrea05 wrote:

> Hi everybody,
> I have two Virtex4 FX12 Minimodules and I'd like to make them
> communicate eachother.
> These modules don't have any special transciver (RocketIO, ...) and
> are equipped with one PPC.
> The communication doesn't require high bandwidth, I need at least 30
> Mbps (more it's better).
> The application is designed to implement a special math algorithm so
> the communication isn't the focus of the application and thus I cannot
> use all the resources for the communication.
> I'm using xilinx ISE and XPS to develop the application.
> 
> Any suggestions on what I can I do? Protocols? Cores? Hardware issues
> that I should take in account? Design references from where I can
> start?

How far does this need to travel ?
Fibre optic modules perhaps ?
Maybe HDLC type protocol, sped up to FPGA speeds.
-jg

On May 25, 3:02 pm, Andrea05 <c...@email.it> wrote:
> On 25 Mag, 20:45, austin <aus...@xilinx.com> wrote:
>
>
>
>
>
> > Andrea,
>
> > Since there are no MGT's, you will need to use some IO's from IO banks.
>
> > You can use: some number of LVDS 100 ohm differential drivers to
> > receivers (one direction only, use two sets of buses), a group of single
> > ended IOs matched to a ribbon cable (with ground, signal, ground,
> > dignal, this is close to 50 ohms, and can go perhaps 10 meters at the
> > speed you need).
>
> > I suggest the single ended groups, perhaps 8 wires for data, and one
> > forwarded clock (for nine signals), and a bus like this for each direction.
>
> > Clocking these 8 wires at even 10 MHz, would provide 80 Mb/s.  At this
> > slow a rate, you don't really need to clock forward, but I still would
> > suggest it (along with the data, there is the clock on the ninth wire to
> > strobe the other end).  That way, you don't have to figure out how to
> > get the clock off of one pcb, and get it to the other one (for a system
> > synchronous solution).
>
> > Just have registers at each end, and create your own (very simple)
> > protocol.  If a "data valid" or "data waiting" signal is needed, just
> > use another wire.  20 wire ribbon cables are pretty common (ten signal,
> > ten grounds).  Drive the transmit end with something like LVCMOS 8 mA
> > FAST, which is very close to 50 ohms, and there should be no overshoot,
> > or undershoot, and the Signal integrity will be good.  If that is still
> > too strong, 6 mA, and even 4 mA drivers can be selected.
>
> > The only reason a protocol is required with the MGTs (like aurora:http://www.xilinx.com/products/design_resources/conn_central/grouping...
> > is that designers need huge bandwidth, and in order to re-synchronize
> > multiple MGTs (channel bonding), a layer is required to manage all that
> > stuff.
>
> > With a simple parallel interface, you pretty much only need to implement
> > what you need.
>
> > To connect these buses to the 405PPC, you will either have to interface
> > to the PLB bus, or create an input and output port that is connected to
> > the 405PPC.  Depending on how fancy you want this to be, it could be as
> > simple as input and output instructions (you create the protocol in
> > software), or as fancy as a FIFO buffer with DMA into memory mapped into
> > the 405PPC data memory (the protocol commonly used here is referred to
> > as "flags placed under a rock" which is a reference to one processor
> > just waits for a memory location to change, which tells it that the data
> > it is waiting for is all there, and ready to be read from memory...the
> > transmitting processor sends all the data, and sets the flag to tell the
> > receiving processor to pick up the data.
>
> > Lots of choices here, and not many "standards" as the task is very
> > simple, and folks tend to use only what logic they need to in order to
> > do the job.
>
> > Once you pop up to MGTs, there are many more choices, only because there
> > are more complex interfaces:  ethernet, fibre channel, PCIe, etc.....
>
> > If you don't need fibre channel, then you don't need media access
> > controllers (MAC), etc.http://www.xilinx.com/products/design_resources/conn_central/solution...
>
> > Austin
>
> Thank you Austin for your reply, I found it very intresting.
> I'll search something about your hints over internet and I'll post the
> results (and surely other questions).
>
> Just another little question. Why, in your opinion, even Xilinx in its
> SPI core doesn't support off-chip Master? SPI peripheral seems to fit
> well to my design requrements but it has this huge limitation... I
> don't understand why... Any ideas?- Hide quoted text -
>
> - Show quoted text -

Andrea,
  I looked at ds464 OPB SPI interface, and it indicated it supports
both master and slave modes.  Is slave mode different from off-chip
Master mode?

-Newman

On May 25, 11:55 pm, Newman <newman5...@yahoo.com> wrote:
> On May 25, 3:02 pm, Andrea05 <c...@email.it> wrote:
>
>
>
>
>
> > On 25 Mag, 20:45, austin <aus...@xilinx.com> wrote:
>
> > > Andrea,
>
> > > Since there are no MGT's, you will need to use some IO's from IO banks.
>
> > > You can use: some number of LVDS 100 ohm differential drivers to
> > > receivers (one direction only, use two sets of buses), a group of single
> > > ended IOs matched to a ribbon cable (with ground, signal, ground,
> > > dignal, this is close to 50 ohms, and can go perhaps 10 meters at the
> > > speed you need).
>
> > > I suggest the single ended groups, perhaps 8 wires for data, and one
> > > forwarded clock (for nine signals), and a bus like this for each direction.
>
> > > Clocking these 8 wires at even 10 MHz, would provide 80 Mb/s.  At this
> > > slow a rate, you don't really need to clock forward, but I still would
> > > suggest it (along with the data, there is the clock on the ninth wire to
> > > strobe the other end).  That way, you don't have to figure out how to
> > > get the clock off of one pcb, and get it to the other one (for a system
> > > synchronous solution).
>
> > > Just have registers at each end, and create your own (very simple)
> > > protocol.  If a "data valid" or "data waiting" signal is needed, just
> > > use another wire.  20 wire ribbon cables are pretty common (ten signal,
> > > ten grounds).  Drive the transmit end with something like LVCMOS 8 mA
> > > FAST, which is very close to 50 ohms, and there should be no overshoot,
> > > or undershoot, and the Signal integrity will be good.  If that is still
> > > too strong, 6 mA, and even 4 mA drivers can be selected.
>
> > > The only reason a protocol is required with the MGTs (like aurora:http://www.xilinx.com/products/design_resources/conn_central/grouping...
> > > is that designers need huge bandwidth, and in order to re-synchronize
> > > multiple MGTs (channel bonding), a layer is required to manage all that
> > > stuff.
>
> > > With a simple parallel interface, you pretty much only need to implement
> > > what you need.
>
> > > To connect these buses to the 405PPC, you will either have to interface
> > > to the PLB bus, or create an input and output port that is connected to
> > > the 405PPC.  Depending on how fancy you want this to be, it could be as
> > > simple as input and output instructions (you create the protocol in
> > > software), or as fancy as a FIFO buffer with DMA into memory mapped into
> > > the 405PPC data memory (the protocol commonly used here is referred to
> > > as "flags placed under a rock" which is a reference to one processor
> > > just waits for a memory location to change, which tells it that the data
> > > it is waiting for is all there, and ready to be read from memory...the
> > > transmitting processor sends all the data, and sets the flag to tell the
> > > receiving processor to pick up the data.
>
> > > Lots of choices here, and not many "standards" as the task is very
> > > simple, and folks tend to use only what logic they need to in order to
> > > do the job.
>
> > > Once you pop up to MGTs, there are many more choices, only because there
> > > are more complex interfaces:  ethernet, fibre channel, PCIe, etc.....
>
> > > If you don't need fibre channel, then you don't need media access
> > > controllers (MAC), etc.http://www.xilinx.com/products/design_resources/conn_central/solution...
>
> > > Austin
>
> > Thank you Austin for your reply, I found it very intresting.
> > I'll search something about your hints over internet and I'll post the
> > results (and surely other questions).
>
> > Just another little question. Why, in your opinion, even Xilinx in its
> > SPI core doesn't support off-chip Master? SPI peripheral seems to fit
> > well to my design requrements but it has this huge limitation... I
> > don't understand why... Any ideas?- Hide quoted text -
>
> > - Show quoted text -
>
> Andrea,
>   I looked at ds464 OPB SPI interface, and it indicated it supports
> both master and slave modes.  Is slave mode different from off-chip
> Master mode?
>
> -Newman- Hide quoted text -
>
> - Show quoted text -


Andrea,
  Oh, I see your point.  In the features portion, it says it supports
master and slave SPI modes, but down in the functional description, it
says at this time only off-chip SPI slave devices are allowed. This is
because the artifact of software master control arbitration is not
guaranteed if off-chip masters were allowed and due to some issue with
asynchronous external clocks.

  I saw a web page where an Altera SPI was connected to an off-chip
master as a slave instance.

-Newman

On May 25, 9:02 pm, Andrea05 <c...@email.it> wrote:
> On 25 Mag, 20:45, austin <aus...@xilinx.com> wrote:
>
>
>
> > Andrea,
>
> > Since there are no MGT's, you will need to use some IO's from IO banks.
>
> > You can use: some number of LVDS 100 ohm differential drivers to
> > receivers (one direction only, use two sets of buses), a group of single
> > ended IOs matched to a ribbon cable (with ground, signal, ground,
> > dignal, this is close to 50 ohms, and can go perhaps 10 meters at the
> > speed you need).
>
> > I suggest the single ended groups, perhaps 8 wires for data, and one
> > forwarded clock (for nine signals), and a bus like this for each direction.
>
> > Clocking these 8 wires at even 10 MHz, would provide 80 Mb/s.  At this
> > slow a rate, you don't really need to clock forward, but I still would
> > suggest it (along with the data, there is the clock on the ninth wire to
> > strobe the other end).  That way, you don't have to figure out how to
> > get the clock off of one pcb, and get it to the other one (for a system
> > synchronous solution).
>
> > Just have registers at each end, and create your own (very simple)
> > protocol.  If a "data valid" or "data waiting" signal is needed, just
> > use another wire.  20 wire ribbon cables are pretty common (ten signal,
> > ten grounds).  Drive the transmit end with something like LVCMOS 8 mA
> > FAST, which is very close to 50 ohms, and there should be no overshoot,
> > or undershoot, and the Signal integrity will be good.  If that is still
> > too strong, 6 mA, and even 4 mA drivers can be selected.
>
> > The only reason a protocol is required with the MGTs (like aurora:http://www.xilinx.com/products/design_resources/conn_central/grouping...
> > is that designers need huge bandwidth, and in order to re-synchronize
> > multiple MGTs (channel bonding), a layer is required to manage all that
> > stuff.
>
> > With a simple parallel interface, you pretty much only need to implement
> > what you need.
>
> > To connect these buses to the 405PPC, you will either have to interface
> > to the PLB bus, or create an input and output port that is connected to
> > the 405PPC.  Depending on how fancy you want this to be, it could be as
> > simple as input and output instructions (you create the protocol in
> > software), or as fancy as a FIFO buffer with DMA into memory mapped into
> > the 405PPC data memory (the protocol commonly used here is referred to
> > as "flags placed under a rock" which is a reference to one processor
> > just waits for a memory location to change, which tells it that the data
> > it is waiting for is all there, and ready to be read from memory...the
> > transmitting processor sends all the data, and sets the flag to tell the
> > receiving processor to pick up the data.
>
> > Lots of choices here, and not many "standards" as the task is very
> > simple, and folks tend to use only what logic they need to in order to
> > do the job.
>
> > Once you pop up to MGTs, there are many more choices, only because there
> > are more complex interfaces:  ethernet, fibre channel, PCIe, etc.....
>
> > If you don't need fibre channel, then you don't need media access
> > controllers (MAC), etc.http://www.xilinx.com/products/design_resources/conn_central/solution...
>
> > Austin
>
> Thank you Austin for your reply, I found it very intresting.
> I'll search something about your hints over internet and I'll post the
> results (and surely other questions).
>
> Just another little question. Why, in your opinion, even Xilinx in its
> SPI core doesn't support off-chip Master? SPI peripheral seems to fit
> well to my design requrements but it has this huge limitation... I
> don't understand why... Any ideas?


OPB_SPI sucks because it does not support off-chip clock input. Xilinx
guys, please remedy this in future versions!!!
It is much easier to implement parallel interface for your case if you
can afford additional pins. If the distance is not too great even
single ended signals could do the job.
Regarding reference designs for V4 MiniModule; search here:
http://www.em.avnet.com/evk/home/0,1719,RID%253D0%2526CID%253D25726%2526CCD%253DUSA%2526SID%253D32214%2526DID%253DDF2%2526SRT%253D1%2526LID%253D32232%2526PRT%253D0%2526PVW%253D%2526BID%253DDF2%2526CTP%253DEVK,00.html

Cheers,

Guru

Thank you guys for the suggrstions.

I must transfer data for about 20cm in an almost continuous way.

Guru have you tried the OPI_SPI with an off-chip master?
Reading the datasheet it seems that Xilinx doesn't *guarantee* that
with an off-chip Matster the OBP_SPI works but it seems (I hope) that
sometime a missynchronization may occour...

If you read the XAPP265 you can see that the peripheral they realize
is *very* similar to an SPI... It doesn't seem that there are problems
even at the high rate stated in the application note (840 Mb/s if i
remember well...)

Now I'm working on another project so I can't try to use OBP_SPI with
off-chip master, but does anybody tried an OPB_SPI with an off-chip
mater ?

Let me know...

Cheers,
Andrea