LOGIN   :::   RECOVER PASS   :::   GET ACCOUNT    
Browse
  • Projects
  • Code (CVS)
  • Forums
  • News
  • Articles
  • Polls
  •  
    OpenCores
  • FAQ
  • CVS HowTo
  • Mission
  • Media
  • Tools
  • Advertise
  • Mirrors
  • Logos
  • Contact us
  • Find Resources
  • Job Opportunity
  •  
    Tools
  • Search
      
  • Download Cores (CVSGet)
  •  
    More
  • Wishbone
  • Perlilog
  • EDA tools
  • OpenTech CD
  •  
    Navigation: All forums > Openrisc > Message List > Message Post

    Message

    Reply | Reply all
    Date Prev | Date Next | Thread Prev | Thread Next Date Index | Thread Index

    From: "Damjan Lampret" <lampret@o...>
    Date: Mon, 5 May 2003 21:21:38 -0700
    Subject: Re: [openrisc] Cache Line Fill
    Top

    
    ----- Original Message -----
    From: <mphan@n...>
    To: <openrisc@o...>
    Sent: Thursday, May 01, 2003 3:36 PM
    Subject: [openrisc] Cache Line Fill
    
    
    > Hi Damjan.
    >
    > In the current design of orp_soc, with or1200_registered_ouput
    > supported, a cache line fill takes 8 clocks (2-2-2-2) to fetch 4 DWORDs
    > from the SRAM/FLASH. And a single  DWORD fetch takes 3 clocks
    > (including one idle cycle of wb_cyc_o deasserted).
    >
    > If we have a very fast internal SRAM, is it possible to do a cache line
    fill
    > with 4/5 clocks (1/2-1-1-1) by changing the wb_stb logic in the
    > or1200_wb_biu.v and do a single DWORD fetch with 2 clocks.
    
    OR1200 is it is has been used in SoC projects much more complxed than
    orp_soc. In all these projects the memory subsystem takes more than
    1/2-1-1-1. So the current 2-2-2-2 was fast enough for all SoCs. If you
    however have faster memory subsystem than modification of or1200_wb_biu and
    possibly IC/DC state machines will be needed.
    
    >
    > My next question is can we increase to cache size to 512 kB to reside
    > the whole firmware and execute instructions from it with 0 wait state.
    >
    
    If you want to use MMUs, then no. This is because MMU's page translation is
    done at the same time as cache access - virtual page number is translated at
    the same time as cache hit is determined. Since page size is 8KB, largest
    direct mapped cache can only be 8KB, unless you use several ways, or unless
    cache access takes an additional clock cycle (maybe acceptable for data
    accesses ?).
    
    Anyway if you don't need MMU, then your caches sizes are not limited. To
    increase cache size just add new IC/DC configuration (search for
    "configuration" in or1200_defines.v and when you find IC and DC
    configurations, just add a new size and then enable new configuration).
    Right now there are configurations for 4KB and 8KB caches.
    
    I'm working on one project where similar to your case all code needs to be
    accessible in 0 wait states. What I plan to do is to replaces caches with
    fixed memories - basically removing TAG RAMs and making sure that the "hit"
    always happens when accessing certain address range and never happens when
    accesssing outside of that range. This will effectively "change caches into
    fixed RAMs much like DSP RAMs or similar).
    If you want these changes, I can put them into the cvs with appropriate
    defines. But it will take a few days.
    
    regards,
    Damjan
    
    > Thanks
    >
    > Michael Phan
    > 
    >
    
    
    
    

    ReferenceAuthor
    [openrisc] Cache Line FillMphan

     
    Copyright (c) 1999 OPENCORES.ORG. All rights reserved.