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: Michael Scott<mike.scott@j...>
    Date: Wed May 5 17:53:10 CEST 2004
    Subject: [openrisc] QMEM Generic single-port synchronous RAM model
    Top
    Hi Damjan,
    Just tried a checkout with opts as suggested
    (ie :pserver:mike.scott@cvs.opencores.org:/cvsroot/mike.scott)
    but to no avail -has the maintainers list been updated ?

    Regards,

    Mike

    -----Original Message-----
    From: openrisc-bounces@opencores.org
    [mailto:openrisc-bounces@opencores.org]On Behalf Of Damjan Lampret
    Sent: 05 May 2004 16:22
    To: List about OpenRISC project
    Subject: Re: [openrisc] QMEM Generic single-port synchronous RAM model


    Mike

    you you have to check out your sources with CVSROOT

    :pserver:<username>@cvs.opencores.org:/cvsroot/<username>

    Then you can modify the source and automatically commit back to the cvs.

    The #1 are because of simulator problems.

    regards,
    Damjan

    ----- Original Message -----
    From: "Michael Scott" <mike.scott@jennic.com>
    To: "'List about OpenRISC project'" <openrisc@opencores.org>
    Sent: Wednesday, May 05, 2004 4:11 PM
    Subject: RE: [openrisc] QMEM Generic single-port synchronous RAM model


    > Hi Damjan,
    > I'm a bit unsure on how to do the update
    > I used the CVSget to grab rel_27 but so I assume I checked out
    > as :pserver:anonymous@cvs.opencores.org:/cvsroot/anonymous
    > do I need to checkout as mike.scott@cvs.opencores.org:/cvsroot/anonymous
    > update the code and commit
    >
    > Is a password required ?
    >
    > Would you prefer the new code to retain the #1's after the non-blocking
    > assigments. I've noticed these in other code such as xilinx
    > simprims; are they to get round some simulator problems (race conditions)
    ?
    >
    > It is my understanding that provided the simulator is
    > compliant with the LRM and blocking assignment used for combinatorial &
    > non-blocking for sequential then #1's shouldn't be needed in synthesisable
    > RTL
    > Out of interest, is there a specific reason for the #1's ?
    >
    > I will be using the Xilinx memories eventually. The problem only arose
    > while playing around with the generic qmem variant in modelsim
    >
    > Regards
    >
    > Mike
    >
    >
    >
    >
    > -----Original Message-----
    > From: openrisc-bounces@opencores.org
    > [mailto:openrisc-bounces@opencores.org]On Behalf Of Damjan Lampret
    > Sent: 05 May 2004 12:28
    > To: List about OpenRISC project
    > Subject: Re: [openrisc] QMEM Generic single-port synchronous RAM model
    >
    >
    > Mike
    >
    > yes you are correct.
    >
    > The good thing is that generic memories for DC/IC are only used for
    > simulation, not for implementation (or your implementation would have
    > thousands of flops instead of actual RAM macros as it is the right way). I
    > have built-in generic memories for those folks that want to have a quick
    > start and don't have the libraries set-up yet...
    >
    > Mike can you go and commit the change directly to the cvs? (you need to be
    > designated as or1k maintaner and if you are not laready I will add your
    > username to the maintaners group)
    >
    > regards,
    > Damjan
    >
    > ----- Original Message -----
    > From: "Michael Scott" <mike.scott@jennic.com>
    > To: <openrisc@opencores.org>
    > Sent: Wednesday, May 05, 2004 12:40 PM
    > Subject: [openrisc] QMEM Generic single-port synchronous RAM model
    >
    >
    > > Hi,
    > > Is there a bug in the Generic single-port synchronous RAM model for qmem > > (file : or1200_spram_2048x32_bw.v) ? > > > > Looking at code below, I can't see how the cpu can write more than 1 byte > at > > a time > > 32/16 bit writes only update mem_0 due to the inferred priority encoder > > > > > > always @(posedge clk) > > if (ce && !we) begin > > do_reg[7:0] <= #1 mem_0[addr]; > > do_reg[15:8] <= #1 mem_1[addr]; > > do_reg[23:16] <= #1 mem_2[addr]; > > do_reg[31:24] <= #1 mem_3[addr]; > > end > > else if (ce && we[0]) > > mem_0[addr] <= #1 di[7:0]; > > else if (ce && we[1]) > > mem_1[addr] <= #1 di[15:8]; > > else if (ce && we[2]) > > mem_2[addr] <= #1 di[23:16]; > > else if (ce && we[3]) > > mem_3[addr] <= #1 di[31:24]; > > > > should the code be structured as: > > > > always @(posedge clk) > > if (ce && ~|we) begin > > do_reg[7:0] <= mem_0[addr]; > > do_reg[15:8] <= mem_1[addr]; > > do_reg[23:16] <= mem_2[addr]; > > do_reg[31:24] <= mem_3[addr]; > > end > > else > > begin > > if (ce && we[0]) mem_0[addr] <= di[7:0]; > > if (ce && we[1]) mem_1[addr] <= di[15:8]; > > if (ce && we[2]) mem_2[addr] <= di[23:16]; > > if (ce && we[3]) mem_3[addr] <= di[31:24]; > > end > > > > Regards, > > > > Mike Scott > > > > ___________________________________________________ > > Jennic Ltd, Furnival Street, Sheffield, S1 4QT, UK > > www.jennic.com Tel: +44 (0) 114 2812655 Confidential > > ___________________________________________________ > > > > > > _______________________________________________ > > http://www.opencores.org/mailman/listinfo/openrisc > > > > > _______________________________________________ > http://www.opencores.org/mailman/listinfo/openrisc > > _______________________________________________ > http://www.opencores.org/mailman/listinfo/openrisc > _______________________________________________ http://www.opencores.org/mailman/listinfo/openrisc

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