1 2 Previous Next 18 Replies Latest reply on Sep 2, 2011 8:42 PM by hoffman Go to original post
      • 15. Re: Queries on ETI Baremetal framework
        vjain27

        Thanks hoffman for the reply! But I am not clear

        about the the invalidate function.Could you please explain a little how the asm statement is

        causing cache invalidation ? Also ,  should the scc_find_region be used for polling the mpb as well ?

         

        -Thanks

        Vaibhav

        • 16. Re: Queries on ETI Baremetal framework
          hoffman

          the asm statement is called when you are unsure that the values you may have in the L1 cache

          represent whats in the underlying memory. typically you would flush at each message boundary,

          although i suppose its possible to invalidate only when cycling around to the beginning of a ring

          buffer.

           

          scc_find_region just gives you the address for the base of the mpb for some remote processor

          as mapped to your core address space. this value doesn't change during the run and should be

          cached in some local structure as the implementation of scc_find_region isn't particularily efficient

          • 17. Re: Queries on ETI Baremetal framework
            vjain27

            Sorry but i am still not very clear. what i understand is that the asm statement just defines two bytes.

            I am not getting how is it actually causing the mpb to be invalidated.

            Also please suggest how to go about polling the mpb for messages.

             

            Thanks

            Vaibhav

            • 18. Re: Queries on ETI Baremetal framework
              hoffman

              those two bytes are actually the encoding for an instruction that the scc team added to the p54c to

              flusht the cache. since its not part of the standard pentium instruction set, gas doesn't really

              know about it, so we cheat by issuing the opcode as a byte constant...the processor interprets

              it as a flush of all those lines in the L1 which have the MPB bit set

               

              as far as the second bit, i usually set up a reader/writer ring buffer, one for each processor

              pair thats going to communicate. a processors sends by writing data into the ring, and

              advancing the write pointer. the receiver polls the write pointer, and when it has consumed

              the data it advances the read pointer. if the write pointer is up against the read pointer, its

              means the writer has filled up the buffer, it needs to block or busy-spin, because the buffer is full.

              if the read pointer is at the write pointer, it means the channel is empty. this structure works

              without locks because each of the two pointers has exactly one writer and one reader.

               

              if you set up 47 of these channels in each mpb, it means you have only 174 bytes per channel,

              which is why we chose to put the messages in dram, so we could send more data between

              each polling interval (bandwidth delay product)

               

              obviously there are all sorts of other schemes you could come up with for managing/sharing

              the mpb buffer space.

              1 2 Previous Next