LOGIN   :::   RECOVER PASS   :::   GET ACCOUNT    
Browse
  • Projects
  • Code (CVS)
  • Forums
  • News
  • Articles
  • Polls
  •  
    OpenCores
  • FAQ
  • CVS HowTo
  • Mission
  • Media
  • Tools
  • Sponsors
  • Mirrors
  • Logos
  • Contact us
  •  
    Tools
  • Search
      
  • Download Cores (CVSGet)
  •  
    More
  • Wishbone
  • Perlilog
  • EDA tools
  • OpenTech CD
  •  
    Overview :: News :: Architecture :: OpenRISC 1200 :: VMware image :: NEW GNU Toolchain Port :: Architectural Simulator :: U-Boot :: Linux :: uClinux :: RTEMS :: ATS :: ORP :: ORPmon :: ORPsoc :: Survey :: Forum :: Silicon :: Downloads :: Tracker    

    OpenRISC 1000: Tracker : cache miss burst doesn't comply with wishbone spec

    Monitor this item

    You will be notified via email when status of this item is changed or if somebody adds a comment.

    Your email

      cache miss burst doesn't comply with wishbone spec

    Type BUG
    Status OPENED
    Top
    In the Wishbone specification one can read that during a burst the wb_sel signal must be kept constant.

    One can obtain an error during such bursts if the dcqmem_ci_i signal wents high during the burst. The dcqmem_ci_i is in this case configured to correspond to the most significant bit in the address output from the cpu (dcpu_adr_cpu).

    DMMU and IMMU is disabled.

    The address from the cpu is erroneous in this case, and is produced in the LSU, where the LSU executes a LSUOP_NOP, and therefore signextends the ex_insn 16-bit immediate field.

    If bit ex_insn[15] is a one, one can possibly get an error, since then dcqmem_ci_i = dcpu_adr_cpu[31] = ex_insn[15].

    The problem is that we observe a case where dcqmem_ci_i wents high during only one clockcycle during a cache refill burst, and therefore the wb_sel signal goes down for one clockcycle. Which in our case led to sampling old data, because of a too early ack signal.

     
    Stats

    6 people are monitoring this item

    Progress
     
    Submited date 25-Nov-2004
    Submited by m_christensson@h...
     
    Assigned date
    Assigned to
     
    Closed date
    Closed by

    Top

    Comments

    by ehliar@i... on 07-Oct-2005
    My fix is not correct since dcfsm_burst seems to go high for one clock cycle while fetching a region where the cache should be inhibited.
     
    by ehliar@i... on 15-Feb-2005
    We have seen this as well but didn't really have time to debug it properly. However, in an old version of or1200_dc_top.v we used the following assignment for the dcsb_sel_o: assign dcsb_sel_o = (dc_en & (dcfsm_burst | (dcfsm_biu_read & !dcfsm_biu_write & !dcdmmu_ci_i))) ? 4'b1111 : dcpu_sel_i; That is, we made sure that the dcsb_sel_o would always output 4'b1111 while bursting. We are not sure if this is the correct fix for it however but a simple testcase where the bug was present was fixed in this case.
     
    by Damjan Lampret on 07-Jan-2005
    I'm working on this.
     

    Add your comment

    Your email:

    Retype key:
    Top

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