|
Hello, I am currently trying to setup a system in which I have 2 DSKc6713 systems, one of which masters a USB ASIC that allows for Bi- directional communication with a PC using a custom application layer protocol that sits on the USB protocol. Unfortunately, I am having difficulty choosing the best hardware and its corresponding software implementation to be able to allow these two DSPs to communicate (bidirectionally) effectively and allow for both real time data streams and just regular data streams (i.e. control messages being passed around etc) All the research I have done seem to point in the direction of the use of EMIF-->HPI or the use of some kind of BiDirectional FIFO (Emif-->Emif) but I have NO idea how I would implement the software. It would be nice to find a solution that can easily be prototyped. I am new to the DSP world and especially multi DSPs and hence any help is greatly apprecaited. Sincerely, ---------------------------- Taha Amiralli University of Western Ontario Electrical Engineering Support Canadian Arrow, Electrical Engineering team www.canadianarrow.com Solar Array/High Power Systems Manager SunStang Solar Car Project, Electrical Team http://hyperserver.engga.uwo.ca/sunstang/ |
Multiprocessor Syncronization -- C6713
Started by ●February 3, 2005
Reply by ●February 3, 20052005-02-03
|
>Hello, > Hi, >I am currently trying to setup a system in which I have 2 DSKc6713 >systems, one of which masters a USB ASIC that allows for Bi- >directional communication with a PC using a custom application layer >protocol that sits on the USB protocol. > >Unfortunately, I am having difficulty choosing the best hardware and >its corresponding software implementation to be able to allow these >two DSPs to communicate (bidirectionally) effectively and allow for >both real time data streams and just regular data streams (i.e. >control messages being passed around etc) > How much bandwidth do you need between them? The McBSPs might be an easy way for you to transfer data between the DSPs - unless you are using them already. >All the research I have done seem to point in the direction of the >use of EMIF-->HPI or the use of some kind of BiDirectional FIFO >(Emif-->Emif) but I have NO idea how I would implement the software. > HPI is not very high bandwidth. We've used dual-port RAM between DSP and other processors - it would work also DSP<->DSP. The ones we use have semaphores in them which allow the software to atomically-"lock" areas of DPRAM so the other side doesn't write to it. That way you just have some external memory that you fill with the appropriate data. >It would be nice to find a solution that can easily be prototyped. > McBSPs are the easiest in that case, just wire them up between two eval-boards. Have fun! Cheers, Martin -- Martin Thompson CEng MIEE TRW Conekt, Stratford Road, Solihull, B90 4GW. UK +44 (0)121-627-3569 : http://www.conekt.net/ |
Reply by ●February 3, 20052005-02-03
|
Hello Martin, Thanks a lot for that quick response. I really do appreciate it. Unfortunately, I am using both the McBSP ports (ADC on one and DAC on the other) and hence I disregarded that option. It would have been an easy way out but oh well... Do you by any chance know how high the bandwidth of the HPI channel is? I was also considering an idea that is similar to the Dual port memory idea you had suggested. (My version was comprised of putting one of those inexpensive high speed bidirectional FIFOs) It works in the same fashion as your idea except for the fact both these solutions have one fundamental problem that I had not been able to solve. How would you rapidly prototype such a solution. (I have not been able to find any boards equipped with either Dual port mem. or FIFOs. My alternative was to try and look for EMIF-->EMIF boards with an FPGA in the middle and design my own FIFO/Dual port RAM. Not a plesant alternative if I might add. Many thanks, Sincerely, ---------------------------- Taha Amiralli University of Western Ontario Electrical Engineering Support Canadian Arrow, Electrical Engineering team www.canadianarrow.com Solar Array/High Power Systems Manager SunStang Solar Car Project, Electrical Team http://hyperserver.engga.uwo.ca/sunstang/ --- In , "Martin.J Thompson" <Martin.J.Thompson@t...> wrote: > >Hello, > > > Hi, > > >I am currently trying to setup a system in which I have 2 DSKc6713 > >systems, one of which masters a USB ASIC that allows for Bi- > >directional communication with a PC using a custom application layer > >protocol that sits on the USB protocol. > > > >Unfortunately, I am having difficulty choosing the best hardware and > >its corresponding software implementation to be able to allow these > >two DSPs to communicate (bidirectionally) effectively and allow for > >both real time data streams and just regular data streams (i.e. > >control messages being passed around etc) > > > > How much bandwidth do you need between them? The McBSPs might be an > easy way for you to transfer data between the DSPs - unless you are > using them already. > > >All the research I have done seem to point in the direction of the > >use of EMIF-->HPI or the use of some kind of BiDirectional FIFO > >(Emif-->Emif) but I have NO idea how I would implement the software. > > > > HPI is not very high bandwidth. > > We've used dual-port RAM between DSP and other processors - it would > work also DSP<->DSP. The ones we use have semaphores in them which > allow the software to atomically-"lock" areas of DPRAM so the other side > doesn't write to it. That way you just have some external memory that > you fill with the appropriate data. > > >It would be nice to find a solution that can easily be prototyped. > > > > McBSPs are the easiest in that case, just wire them up between two > eval-boards. > > Have fun! > > Cheers, > Martin > > -- > Martin Thompson CEng MIEE > TRW Conekt, Stratford Road, Solihull, B90 4GW. UK > +44 (0)121-627-3569 : martin.j.thompson@t... > http://www.conekt.net/ |
Reply by ●February 4, 20052005-02-04
|
Hello Taha,
I don't think that you will find an existing solution.
The EMIF1-->HPI2 and EMIF2-->1 is as easy/difficult as a FIFO or Dual
Port RAM solution - with much slower performance.
My advice would be to 'byte the bullet' all at once and not mess
around. It sounds like you are already using a daughtercard - Create a 4"
x 8" [I'm guessing on dimensions] PCB with 'pass through'
daughtercard connectors [so that you can still plug in a daughtercard on top]
that allows you to connect 2 boards. Put an FPGA [most flexible, most
work], 1 or 2 FIFOs [can be a little more work if you find that you need to do
something out of sequence], or a Dual Port RAM [my choice] in the middle - or
you could do all three.
Don't forget to add some signaling [like 'interrupt'
to the other computer].
If you do 'special stuff' very often, you might seriously
consider the FPGA for potential reuse - that would give you something to do
while the board is being fab'd
 good luck,
mikedunn
thamiral <t...@uwo.ca> wrote: Hello Martin, |
Reply by ●February 4, 20052005-02-04
|
Hello Mike, Thanks a lot for that advice. Yes you are correct, I am using the 2 DSKs, with AvNet Analog (5-6K) daughter boards and Data converter EVMs on all serial ports. Just to make sure I understand your suggestion correctly... You were suggesting that I make a "Bridge" board between the Two DSKs with four connectors that pass through and an FPGA/Dual port Ram/FIFO in the middle that connects the "Pass through" Emif ports of this custom board? My only concern over this is that adding trace lenghts to that EMIF connector may result in signal degradations that I cannot forsee and hence start corrupting data that I write using the EMIF port. Am I being too paranoid or are there "reference designs" out there that I can follow? Any reasons for the choice of Dual port memory or any suggested dual port ram devices ;)? Once again, Thanks a lot. Sincerely, ---------------------------- Taha Amiralli University of Western Ontario Electrical Engineering Support Canadian Arrow, Electrical Engineering team www.canadianarrow.com Solar Array/High Power Systems Manager SunStang Solar Car Project, Electrical Team http://hyperserver.engga.uwo.ca/sunstang/ Quoting Mike Dunn <>: > Hello Taha, > > I don't think that you will find an existing solution. > > The EMIF1-->HPI2 and EMIF2-->1 is as easy/difficult as a FIFO or Dual Port > RAM solution - with much slower performance. > > My advice would be to 'byte the bullet' all at once and not mess around. It > sounds like you are already using a daughtercard - Create a 4" x 8" [I'm > guessing on dimensions] PCB with 'pass through' daughtercard connectors [so > that you can still plug in a daughtercard on top] that allows you to connect > 2 boards. Put an FPGA [most flexible, most work], 1 or 2 FIFOs [can be a > little more work if you find that you need to do something out of sequence], > or a Dual Port RAM [my choice] in the middle - or you could do all three. > > Don't forget to add some signaling [like 'interrupt' to the other computer]. > > If you do 'special stuff' very often, you might seriously consider the FPGA > for potential reuse - that would give you something to do while the board is > being fab'd > > good luck, > mikedunn > > thamiral <> wrote: > > Hello Martin, > > Thanks a lot for that quick response. I really do appreciate it. > > Unfortunately, I am using both the McBSP ports (ADC on one and DAC > on the other) and hence I disregarded that option. It would have > been an easy way out but oh well... > > Do you by any chance know how high the bandwidth of the HPI channel > is? > > I was also considering an idea that is similar to the Dual port > memory idea you had suggested. (My version was comprised of putting > one of those inexpensive high speed bidirectional FIFOs) It works in > the same fashion as your idea except for the fact both these > solutions have one fundamental problem that I had not been able to > solve. > > How would you rapidly prototype such a solution. (I have not been > able to find any boards equipped with either Dual port mem. or > FIFOs. My alternative was to try and look for EMIF-->EMIF boards > with an FPGA in the middle and design my own FIFO/Dual port RAM. Not > a plesant alternative if I might add. > > Many thanks, > > Sincerely, > > ---------------------------- > Taha Amiralli > University of Western Ontario > > Electrical Engineering Support > Canadian Arrow, Electrical Engineering team > www.canadianarrow.com > > Solar Array/High Power Systems Manager > SunStang Solar Car Project, Electrical Team > http://hyperserver.engga.uwo.ca/sunstang/ > --- In , "Martin.J Thompson" > wrote: > > >Hello, > > > > > Hi, > > > > >I am currently trying to setup a system in which I have 2 > DSKc6713 > > >systems, one of which masters a USB ASIC that allows for Bi- > > >directional communication with a PC using a custom application > layer > > >protocol that sits on the USB protocol. > > > > > >Unfortunately, I am having difficulty choosing the best hardware > and > > >its corresponding software implementation to be able to allow > these > > >two DSPs to communicate (bidirectionally) effectively and allow > for > > >both real time data streams and just regular data streams (i.e. > > >control messages being passed around etc) > > > > > > > How much bandwidth do you need between them? The McBSPs might be > an > > easy way for you to transfer data between the DSPs - unless you are > > using them already. > > > > >All the research I have done seem to point in the direction of > the > > >use of EMIF-->HPI or the use of some kind of BiDirectional FIFO > > >(Emif-->Emif) but I have NO idea how I would implement the > software. > > > > > > > HPI is not very high bandwidth. > > > > We've used dual-port RAM between DSP and other processors - it > would > > work also DSP<->DSP. The ones we use have semaphores in them which > > allow the software to atomically-"lock" areas of DPRAM so the > other side > > doesn't write to it. That way you just have some external memory > that > > you fill with the appropriate data. > > > > >It would be nice to find a solution that can easily be prototyped. > > > > > > > McBSPs are the easiest in that case, just wire them up between two > > eval-boards. > > > > Have fun! > > > > Cheers, > > Martin > > > > -- > > Martin Thompson CEng MIEE > > TRW Conekt, Stratford Road, Solihull, B90 4GW. UK > > +44 (0)121-627-3569 : martin.j.thompson@t... > > http://www.conekt.net/ |
Reply by ●February 4, 20052005-02-04
|
I'll add my stuff here as Mike suggested most of what I was going
to! > >Hello Mike, > >Thanks a lot for that advice. > >Yes you are correct, I am using the 2 DSKs, with AvNet Analog (5-6K) daughter >boards and Data converter EVMs on all serial ports. > >Just to make sure I understand your suggestion correctly... You were suggesting >that I make a "Bridge" board between the Two DSKs with four connectors that >pass through and an FPGA/Dual port Ram/FIFO in the middle that connects the >"Pass through" Emif ports of this custom board? > >My only concern over this is that adding trace lenghts to that EMIF connector >may result in signal degradations that I cannot forsee and hence start >corrupting data that I write using the EMIF port. Am I being too paranoid or >are there "reference designs" out there that I can follow? > You'll probably be alright, the DSP edges are reasonably well controlled. If you can keep things to <3 inches you should be OK. To be sure you'd simulate... If you go the FPGA route, note that they can have some really evil edges on them. When I did this, I was using an Altera 10KE FPGA, which is really old-hat these days and even then I was seeing 700ps edges which I had to terminate. The newer ones have better slew control as you probably won't mind losing that small bit of time. >Any reasons for the choice of Dual port memory or any suggested dual port ram >devices ;)? > Our DPRAMs were IDT ones. The semaphores and interrupt line come in very handy for synchronising the two processors. Try typing "dpram semaphore" into their search, there seems to be a load of them... Cheers, Martin -- Martin Thompson CEng MIEE TRW Conekt, Stratford Road, Solihull, B90 4GW. UK +44 (0)121-627-3569 : http://www.conekt.net/ |
Reply by ●February 4, 20052005-02-04
|
Taha,
I have a picture in my mind, let me see if I can describe it.
Notice that all of the EMIF signals are on a single connector.
Position one DSK so that this connector is at the top right. Position
another DSK so that its connector is in the lower left. Now position the
DSKs such that the connectors are about 1" apart. Now - what is the trace
length problem?? Also the EMIF connectors are buffered on all of the DSKs
that I have seen.
Also, to be accurate, this board will require 4 male + 4
female daughtercard connectors - 2 for DSK#1, 2 for DSK#1 pass-thru, 2 for
DSK#2, 2 for DSK#2 pass-thru.
My main preference for DPRAM is the flexibility. I have worked on
systems with a single pipe between them and things can get complicated if you
are transfering multiple data and control streams with different buffer sizes
and priorities between the systems. The programming model for shared
memory seems more flexible [but requires more discipline].
FYI - I like using fixed memory definitions in a single header that
uses a 'SYSTEM1' or 'SYSTEM2' preprocessor directive to
ensure that memory regions are consistent and complimentary between the two
systems.
I don't have any 'contemporary dual port' suggestions but I
seem to remember some reasonably priced devices in the 50 - 100 ns speed
range. If this isn't for a product, I would just check out Cypress
and see what they have...
mikedunn
Taha Amiralli <t...@uwo.ca> wrote: Hello Mike, |
Reply by ●February 4, 20052005-02-04
|
Hello Mike, Thanks a lot for the input. I guess I was being paranoid about a 1-2" trace length problem. :) I am just curious about how you manage to maintain/communicate atomicity when communicating with the other microprocessor. Specifically, if I were to use DSP/BIOS semaphores, then the problem becomes that there is no such thing as a shared "semaphore" since both RTOS's can be polling/writing on that semaphore and we can potentially still have an atomicity problem. If we use hardware semaphores (avail in the Dual port mem) as suggested by Martin, then the problem becomes communicating the "locked" state somehow to the other DSP. (i.e. one DSP can lock the memory whilst the other DSP is trying to find out if the memory is locked) This is not for a product actually (its a research project) and I will take a look if cypress has anything that would speed up development with respect to this project. Thanks a lotnonce again, Sincerely, ---------------------------- Taha Amiralli University of Western Ontario Electrical Engineering Support Canadian Arrow, Electrical Engineering team www.canadianarrow.com Solar Array/High Power Systems Manager SunStang Solar Car Project, Electrical Team http://hyperserver.engga.uwo.ca/sunstang/ Quoting Mike Dunn <>: > Taha, > > I have a picture in my mind, let me see if I can describe it. > > Notice that all of the EMIF signals are on a single connector. Position one > DSK so that this connector is at the top right. Position another DSK so that > its connector is in the lower left. Now position the DSKs such that the > connectors are about 1" apart. Now - what is the trace length problem?? > Also the EMIF connectors are buffered on all of the DSKs that I have seen. > > Also, to be accurate, this board will require 4 male + 4 female daughtercard > connectors - 2 for DSK#1, 2 for DSK#1 pass-thru, 2 for DSK#2, 2 for DSK#2 > pass-thru. > > My main preference for DPRAM is the flexibility. I have worked on systems > with a single pipe between them and things can get complicated if you are > transfering multiple data and control streams with different buffer sizes and > priorities between the systems. The programming model for shared memory > seems more flexible [but requires more discipline]. > > FYI - I like using fixed memory definitions in a single header that uses a > 'SYSTEM1' or 'SYSTEM2' preprocessor directive to ensure that memory regions > are consistent and complimentary between the two systems. > > I don't have any 'contemporary dual port' suggestions but I seem to remember > some reasonably priced devices in the 50 - 100 ns speed range. If this isn't > for a product, I would just check out Cypress and see what they have... > > mikedunn > > Taha Amiralli <> wrote: > Hello Mike, > > Thanks a lot for that advice. > > Yes you are correct, I am using the 2 DSKs, with AvNet Analog (5-6K) daughter > boards and Data converter EVMs on all serial ports. > > Just to make sure I understand your suggestion correctly... You were > suggesting > that I make a "Bridge" board between the Two DSKs with four connectors that > pass through and an FPGA/Dual port Ram/FIFO in the middle that connects the > "Pass through" Emif ports of this custom board? > > My only concern over this is that adding trace lenghts to that EMIF connector > may result in signal degradations that I cannot forsee and hence start > corrupting data that I write using the EMIF port. Am I being too paranoid or > are there "reference designs" out there that I can follow? > > Any reasons for the choice of Dual port memory or any suggested dual port ram > devices ;)? > > Once again, Thanks a lot. > > Sincerely, > ---------------------------- > Taha Amiralli > University of Western Ontario > > Electrical Engineering Support > Canadian Arrow, Electrical Engineering team > www.canadianarrow.com > > Solar Array/High Power Systems Manager > SunStang Solar Car Project, Electrical Team > http://hyperserver.engga.uwo.ca/sunstang/ > Quoting Mike Dunn : > > > Hello Taha, > > > > I don't think that you will find an existing solution. > > > > The EMIF1-->HPI2 and EMIF2-->1 is as easy/difficult as a FIFO or Dual Port > > RAM solution - with much slower performance. > > > > My advice would be to 'byte the bullet' all at once and not mess around. It > > sounds like you are already using a daughtercard - Create a 4" x 8" [I'm > > guessing on dimensions] PCB with 'pass through' daughtercard connectors [so > > that you can still plug in a daughtercard on top] that allows you to > connect > > 2 boards. Put an FPGA [most flexible, most work], 1 or 2 FIFOs [can be a > > little more work if you find that you need to do something out of > sequence], > > or a Dual Port RAM [my choice] in the middle - or you could do all three. > > > > Don't forget to add some signaling [like 'interrupt' to the other > computer]. > > > > If you do 'special stuff' very often, you might seriously consider the FPGA > > for potential reuse - that would give you something to do while the board > is > > being fab'd > > > > good luck, > > mikedunn > > > > thamiral wrote: > > > > > > > > Hello Martin, > > > > Thanks a lot for that quick response. I really do appreciate it. > > > > Unfortunately, I am using both the McBSP ports (ADC on one and DAC > > on the other) and hence I disregarded that option. It would have > > been an easy way out but oh well... > > > > Do you by any chance know how high the bandwidth of the HPI channel > > is? > > > > I was also considering an idea that is similar to the Dual port > > memory idea you had suggested. (My version was comprised of putting > > one of those inexpensive high speed bidirectional FIFOs) It works in > > the same fashion as your idea except for the fact both these > > solutions have one fundamental problem that I had not been able to > > solve. > > > > How would you rapidly prototype such a solution. (I have not been > > able to find any boards equipped with either Dual port mem. or > > FIFOs. My alternative was to try and look for EMIF-->EMIF boards > > with an FPGA in the middle and design my own FIFO/Dual port RAM. Not > > a plesant alternative if I might add. > > > > Many thanks, > > > > Sincerely, > > > > ---------------------------- > > Taha Amiralli > > > > > > University of Western Ontario > > > > Electrical Engineering Support > > Canadian Arrow, Electrical Engineering team > > www.canadianarrow.com > > > > Solar Array/High Power Systems Manager > > SunStang Solar Car Project, Electrical Team > > http://hyperserver.engga.uwo.ca/sunstang/ > > > > > > > > > > > > > > > > > > --- In , "Martin.J Thompson" > > wrote: > > > >Hello, > > > > > > > Hi, > > > > > > >I am currently trying to setup a system in which I have 2 > > DSKc6713 > > > >systems, one of which masters a USB ASIC that allows for Bi- > > > >directional communication with a PC using a custom application > > layer > > > >protocol that sits on the USB protocol. > > > > > > > >Unfortunately, I am having difficulty choosing the best hardware > > and > > > >its corresponding software implementation to be able to allow > > these > > > >two DSPs to communicate (bidirectionally) effectively and allow > > for > > > >both real time data streams and just regular data streams (i.e. > > > >control messages being passed around etc) > > > > > > > > > > How much bandwidth do you need between them? The McBSPs might be > > an > > > easy way for you to transfer data between the DSPs - unless you are > > > using them already. > > > > > > >All the research I have done seem to point in the direction of > > the > > > >use of EMIF-->HPI or the use of some kind of BiDirectional FIFO > > > >(Emif-->Emif) but I have NO idea how I would implement the > > software. > > > > > > > > > > HPI is not very high bandwidth. > > > > > > We've used dual-port RAM between DSP and other processors - it > > would > > > work also DSP<->DSP. The ones we use have semaphores in them which > > > allow the software to atomically-"lock" areas of DPRAM so the > > other side > > > doesn't write to it. That way you just have some external memory > > that > > > you fill with the appropriate data. > > > > > > >It would be nice to find a solution that can easily be prototyped. > > > > > > > > > > McBSPs are the easiest in that case, just wire them up between two > > > eval-boards. > > > > > > Have fun! > > > > > > Cheers, > > > Martin > > > > > > -- > > > Martin Thompson CEng MIEE > > > TRW Conekt, Stratford Road, Solihull, B90 4GW. UK > > > +44 (0)121-627-3569 : martin.j.thompson@t... > > > http://www.conekt.net/ > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > |
Reply by ●February 7, 20052005-02-07
|
> >>>> Taha Amiralli <> 04 February 2005 16:03:54 >>> >If we use hardware semaphores (avail in the Dual port mem) as suggested by >Martin, then the problem becomes communicating the "locked" state somehow to >the other DSP. (i.e. one DSP can lock the memory whilst the other DSP is trying >to find out if the memory is locked) > The other DSP will "know", as it will try and take the semaphore and fail. The DPRAM parts gurarntee that if both sides try and take the semaphore, only one will succeed. Or was that not the question? Cheers, Martin -- Martin Thompson CEng MIEE TRW Conekt, Stratford Road, Solihull, B90 4GW. UK +44 (0)121-627-3569 : http://www.conekt.net/ |
Reply by ●February 8, 20052005-02-08
|
Hello Martin, Thanks for the info... Can software semaphores be used as opposed to hardware semaphores? Sincerely, Taha Amiralli --- In , "Martin.J Thompson" <Martin.J.Thompson@t...> wrote: > > > > >>>> Taha Amiralli <thamiral@u...> 04 February 2005 16:03:54 >>> > >If we use hardware semaphores (avail in the Dual port mem) as > suggested by > >Martin, then the problem becomes communicating the "locked" state > somehow to > >the other DSP. (i.e. one DSP can lock the memory whilst the other DSP > is trying > >to find out if the memory is locked) > > > > The other DSP will "know", as it will try and take the semaphore and > fail. The DPRAM parts gurarntee that if both sides try and take the > semaphore, only one will succeed. > > Or was that not the question? > > Cheers, > Martin > > -- > Martin Thompson CEng MIEE > TRW Conekt, Stratford Road, Solihull, B90 4GW. UK > +44 (0)121-627-3569 : martin.j.thompson@t... > http://www.conekt.net/ |
