Email: Password: Remember Me | Create Account (Free)

Back to Subject List

Old thread has been locked -- no new posts accepted in this thread
???
11/03/06 01:21
Read: times


 
#127292 - You've got it! That's the problem, for sure.
Responding to: ???'s previous message
The complaint I learned about only today, specifically targeted at the SiLabs ...F12x series that purports to run at 100 MIPS, was that a straightlined bit of code completely fell out of synchronization with its target hardware when the loop it used was doubled in length in order to compensate in timing for the extra cycle needed to take the branch.

Apparently this particular architecture relies on that pipeline and, as one would expect, suffers badly when a critically timed loop exceeds the pipeline length. Unfortunately, I haven't been able to find a spec on the pipeline depth, and that should be documented.

Does anybody know how to cope with this apparently fatal problem? It essentially renders the part(s) useless, since one can't precisely time a firmware loop to synchronize with external hardware without knowing exactly (2) the pipeline depth, and (2) the reload time.

RE


List of 33 messages in thread
TopicAuthorDate
Pipelines revisited            01/01/70 00:00      
   You cannot say without more information            01/01/70 00:00      
      You've got it! That's the problem, for sure.            01/01/70 00:00      
         Synchronization            01/01/70 00:00      
            True enough, but in this case            01/01/70 00:00      
   So you can be happily chugging away            01/01/70 00:00      
      That renders the SiLabs architecture unuseable            01/01/70 00:00      
         Can't You Trurn it off?            01/01/70 00:00      
         Advertising.            01/01/70 00:00      
            a better term would have been "unspecified"            01/01/70 00:00      
         if what you want is to bitch, the cache stinks, if            01/01/70 00:00      
            No ... it's not just a complaint ...            01/01/70 00:00      
               experience and the other is stated already            01/01/70 00:00      
                  it's not quite that simple ...            01/01/70 00:00      
                     does not matter, in this case an advantage            01/01/70 00:00      
                        Yes, same length, irrespective of path            01/01/70 00:00      
   can you explain more?            01/01/70 00:00      
      It uses a pipeline to achieve the high speed            01/01/70 00:00      
         why pipeline??            01/01/70 00:00      
   branch cache            01/01/70 00:00      
      i dont know about slightly unpredictable            01/01/70 00:00      
      I second this.            01/01/70 00:00      
      It's called "branche cache" rather than pipeline?            01/01/70 00:00      
         They're two different things.            01/01/70 00:00      
            This flush and refill process is what I feared            01/01/70 00:00      
         you might also try something completely different            01/01/70 00:00      
            well ... maybe ...            01/01/70 00:00      
   what is the problem?            01/01/70 00:00      
      The problem is blaming the pipeline ...            01/01/70 00:00      
         oh, I wish            01/01/70 00:00      
         Exactly ...            01/01/70 00:00      
      That reference is helpful            01/01/70 00:00      
         not a "litterary masterpiece" but after reading            01/01/70 00:00      

Back to Subject List