I think you nailed down the only options here. I like the simplicity (in terms of signal flow and software work) of using 2 ports per SHARC into a central FPGA. It may add pin count to the FPGA, but in tems of routing, it's actually the same number of nets as the token ring approach, but they are just coming into one place instead of going around in a loop. If the SHARCs are laid out around the FPGA, it shouldn't be too bad to route that.

--- On Fri, 8/7/09, Mike Rosing wrote:

> From: Mike Rosing
> Subject: Re: [adsp] Sharc (non-Tiger) LINK Ports
> To: "Wachob, Chip"
> Cc: a...
> Date: Friday, August 7, 2009, 9:32 AM
> Howdy Chip,
>
> Check out chapter 9 in the 2106x SHARC user's manual.
> They have a bunch
> of possible topologies for link ports. It will at
> least give you a few
> more things to think about.
>
> The first thing to estimate is the bandwidth between
> processors. If you
> only have a few messages now and then, it is a lot easier
> to set up a
> token ring. But if you have to share a megabyte per
> second, life becomes
> a lot more difficult. That estimate is hard to do,
> but even an order of
> magnitude guess really tells you what won't possibly work
> and what is
> obviously overkill.
>
> Also look at chapter 7 on multiprocessing. That's a
> completely different
> approach, but it again will give you some ideas.
>
> The other thing to look at is physical layout. You
> won't have too much
> problem if all your coms traces are reasonably short.
> But if you have to
> lay things out with lots of separation then using the FPGA
> to boost/clean
> signal may be well worth it.
>
> Sounds like a fun challenge. Good luck!
>
> Patience, persistence, truth,
> Dr. mike
>
>
>
> On Fri, 7 Aug 2009, Wachob, Chip wrote:
>
> > Hello,
> >
> > I've been a long time reader of this forum but have
> never
> > posted before.
> >
> > I have a question out there for you folks that are
> using
> > the Sharc parts, not the Tiger Sharc parts.
> >
> > I'm trying to come up with an efficient and
> > straight-forward way to get a group of Sharc
> processors to
> > talk together, and with a host (host interface
> 32-bit).
> >
> > In total there are six Sharc processors and their
> LINK
> > ports need to Rx and Tx to the Host.
> >
> > I've been considering several topologies as
> possibilities:
> >
> > - Two ports (1Rx, 1Tx) per Sharc directly back to the
> > FPGA. This means a _whole_ bunch of routes on a PCB
> and
> > signal integrity galore. This also creates a
> complicated
> > and high pin-count FPGA.
> >
> > - The other is to do a 'token ring' arrangement where
> each
> > Sharc receives and transmits all messages and pulls
> their
> > messages off the stream. This arrangement would be
> simpler
> > to handle in terms of routing but there are concerns
> about
> > having enough processor time to handle checking the
> > messages. Simplifies the FPGA and reduces pin count
> > dramatically.
> >
> > - The last is to have one port per DSP that is
> > bi-directional. This would be a bit simpler than the
> first
> > concept (reduced routing on the PCB) but the Sharc
> > processor does not have any hardware 'built in' to
> handle
> > the bidirectional handshaking. Thus complicating the
> ISR
> > for messages. Again processor time is a premium and
> this
> > method would "steal" from that. This would reduce
> somewhat
> > the pin requirement for the FPGA but still makes for
> > complicated coding in the FPGA.
> >
> > We want to be able to run the LINK port at the
> maximum
> > rate. I believe this is around or approaching 150
> MHz.
> >
> > I wonder if there are other approaches out there that
> I've
> > not considered.
> >
> > Anyone have any suggestions?
> >
> > Thanks in advance for your thoughts.
> >
> >
> > Chip Wachob
> > Design Engineer
> > Allen Audio / Allen Organ
> > POB 36
> > 150 Locust St.
> > Macungie, PA 18062
> > V 610.966.2200
> > F 610.966.4684
> >
>
>
>
>
>
>
> _____________________________________
>
>
>
> mailto:a...
>
>
>

Howdy Chip,

Check out chapter 9 in the 2106x SHARC user's manual. They have a bunch
of possible topologies for link ports. It will at least give you a few
more things to think about.

The first thing to estimate is the bandwidth between processors. If you
only have a few messages now and then, it is a lot easier to set up a
token ring. But if you have to share a megabyte per second, life becomes
a lot more difficult. That estimate is hard to do, but even an order of
magnitude guess really tells you what won't possibly work and what is
obviously overkill.

Also look at chapter 7 on multiprocessing. That's a completely different
approach, but it again will give you some ideas.

The other thing to look at is physical layout. You won't have too much
problem if all your coms traces are reasonably short. But if you have to
lay things out with lots of separation then using the FPGA to boost/clean
signal may be well worth it.

Sounds like a fun challenge. Good luck!

Patience, persistence, truth,
Dr. mike

On Fri, 7 Aug 2009, Wachob, Chip wrote:

> Hello,
>
> I've been a long time reader of this forum but have never
> posted before.
>
> I have a question out there for you folks that are using
> the Sharc parts, not the Tiger Sharc parts.
>
> I'm trying to come up with an efficient and
> straight-forward way to get a group of Sharc processors to
> talk together, and with a host (host interface 32-bit).
>
> In total there are six Sharc processors and their LINK
> ports need to Rx and Tx to the Host.
>
> I've been considering several topologies as possibilities:
>
> - Two ports (1Rx, 1Tx) per Sharc directly back to the
> FPGA. This means a _whole_ bunch of routes on a PCB and
> signal integrity galore. This also creates a complicated
> and high pin-count FPGA.
>
> - The other is to do a 'token ring' arrangement where each
> Sharc receives and transmits all messages and pulls their
> messages off the stream. This arrangement would be simpler
> to handle in terms of routing but there are concerns about
> having enough processor time to handle checking the
> messages. Simplifies the FPGA and reduces pin count
> dramatically.
>
> - The last is to have one port per DSP that is
> bi-directional. This would be a bit simpler than the first
> concept (reduced routing on the PCB) but the Sharc
> processor does not have any hardware 'built in' to handle
> the bidirectional handshaking. Thus complicating the ISR
> for messages. Again processor time is a premium and this
> method would "steal" from that. This would reduce somewhat
> the pin requirement for the FPGA but still makes for
> complicated coding in the FPGA.
>
> We want to be able to run the LINK port at the maximum
> rate. I believe this is around or approaching 150 MHz.
>
> I wonder if there are other approaches out there that I've
> not considered.
>
> Anyone have any suggestions?
>
> Thanks in advance for your thoughts.
> Chip Wachob
> Design Engineer
> Allen Audio / Allen Organ
> POB 36
> 150 Locust St.
> Macungie, PA 18062
> V 610.966.2200
> F 610.966.4684
>

Hello,

I've been a long time reader of this forum but have never
posted before.

I have a question out there for you folks that are using
the Sharc parts, not the Tiger Sharc parts.

I'm trying to come up with an efficient and
straight-forward way to get a group of Sharc processors to
talk together, and with a host (host interface 32-bit).

In total there are six Sharc processors and their LINK
ports need to Rx and Tx to the Host.

I've been considering several topologies as possibilities:

- Two ports (1Rx, 1Tx) per Sharc directly back to the
FPGA. This means a _whole_ bunch of routes on a PCB and
signal integrity galore. This also creates a complicated
and high pin-count FPGA.

- The other is to do a 'token ring' arrangement where each
Sharc receives and transmits all messages and pulls their
messages off the stream. This arrangement would be simpler
to handle in terms of routing but there are concerns about
having enough processor time to handle checking the
messages. Simplifies the FPGA and reduces pin count
dramatically.

- The last is to have one port per DSP that is
bi-directional. This would be a bit simpler than the first
concept (reduced routing on the PCB) but the Sharc
processor does not have any hardware 'built in' to handle
the bidirectional handshaking. Thus complicating the ISR
for messages. Again processor time is a premium and this
method would "steal" from that. This would reduce somewhat
the pin requirement for the FPGA but still makes for
complicated coding in the FPGA.

We want to be able to run the LINK port at the maximum
rate. I believe this is around or approaching 150 MHz.

I wonder if there are other approaches out there that I've
not considered.

Anyone have any suggestions?

Thanks in advance for your thoughts.
Chip Wachob
Design Engineer
Allen Audio / Allen Organ
POB 36
150 Locust St.
Macungie, PA 18062
V 610.966.2200
F 610.966.4684