Xilinx ISE Synthesize of ROM

Discussion in 'VHDL' started by peter.kampmann@googlemail.com, Sep 5, 2006.

  1. Guest

    Hi,

    I have to store a large amount of coefficients in my FPGA for
    multiplication:

    type coefficient is array(12 downto 0) of signed(17 downto 0);

    type coefficients is array(179 downto 0) of coefficient;

    constant coefficientsArray : coefficients :=
    (("100000000001010010","100000000101001110","000001100101010110",
    "000011011101000011","110000011110011010","110001111011011000",
    "010110100011101111","001011110111000110","100100000010011111",
    "100001000001001001","000000000101111111","000000000000101110",
    "100000000000000001"), .... );

    So I expect this to be synthesizes into 180 ROMs consisting of 13
    17-Bit values.
    I assumed that I can store these values in my Virtex 2 Pro XC30 using
    the 2,048 kb of Block RAM.

    Unfortunately, this design together with the multiplication part needs
    153% of the fpga space.
    For testing puposes I reduced the coefficientsArray to 6 and get a
    synthesis result of about 54% of the fpga.
    Using the option in Synthesize->XST in Xilinx ISE for ROM Style = Block
    gives no improvement.

    So here are my questions :)
    Is it possible to get the design I expect? Meaning 180 ROMS in Block
    RAM? Each clock cycle, I need 169 of these values. Or this task not
    possible for this fpga?
    Until now I hope Xilinx ISE infers these ROMS into Block ROM, but I do
    not know if this is the case, the synthesis report mentions the
    instantiation of ROMs as follows:

    Found 256x6-bit ROM for signal <$rom0001>.
    Found 256x6-bit ROM for signal <$rom0002>.
    Found 256x6-bit ROM for signal <$rom0003>.
    Found 256x6-bit ROM for signal <$rom0004>.
    Found 256x12-bit ROM for signal <$rom0005>.
    Found 256x6-bit ROM for signal <$rom0006>.
    Found 256x3-bit ROM for signal <$rom0007>.
    Found 256x6-bit ROM for signal <$rom0008>.
    Found 256x3-bit ROM for signal <$rom0009>.
    Found 256x6-bit ROM for signal <$rom0010>.
    Found 256x12-bit ROM for signal <$rom0011>

    It seems that instantation of ROMs via CoreGen is not preferable, as
    far as I understand the CoreGen instantiation, I have to instantiate
    180 Coregen ROMs because each ROM has a different content?

    Hope you can help me and give me some suggestions how I can get these
    ROMs packed into the fpga.

    Thanks in advance and regards,
    Peter
    , Sep 5, 2006
    #1
    1. Advertising

  2. Guest

    Just found out that the XC2VP30 has 136 Block RAMs with 18Kb each.
    As you can use the Block RAM as dual port RAM, it should be possible to
    store
    my 180 ROMs consisting of 221 bits each (13*17 bits).

    But how to instantiate it? I looked via the FPGA Editor into my design
    and the BRAMs seem to be empty...

    Regards,
    Peter

    schrieb:

    > Hi,
    >
    > I have to store a large amount of coefficients in my FPGA for
    > multiplication:
    >
    > type coefficient is array(12 downto 0) of signed(17 downto 0);
    >
    > type coefficients is array(179 downto 0) of coefficient;
    >
    > constant coefficientsArray : coefficients :=
    > (("100000000001010010","100000000101001110","000001100101010110",
    > "000011011101000011","110000011110011010","110001111011011000",
    > "010110100011101111","001011110111000110","100100000010011111",
    > "100001000001001001","000000000101111111","000000000000101110",
    > "100000000000000001"), .... );
    >
    > So I expect this to be synthesizes into 180 ROMs consisting of 13
    > 17-Bit values.
    > I assumed that I can store these values in my Virtex 2 Pro XC30 using
    > the 2,048 kb of Block RAM.
    >
    > Unfortunately, this design together with the multiplication part needs
    > 153% of the fpga space.
    > For testing puposes I reduced the coefficientsArray to 6 and get a
    > synthesis result of about 54% of the fpga.
    > Using the option in Synthesize->XST in Xilinx ISE for ROM Style = Block
    > gives no improvement.
    >
    > So here are my questions :)
    > Is it possible to get the design I expect? Meaning 180 ROMS in Block
    > RAM? Each clock cycle, I need 169 of these values. Or this task not
    > possible for this fpga?
    > Until now I hope Xilinx ISE infers these ROMS into Block ROM, but I do
    > not know if this is the case, the synthesis report mentions the
    > instantiation of ROMs as follows:
    >
    > Found 256x6-bit ROM for signal <$rom0001>.
    > Found 256x6-bit ROM for signal <$rom0002>.
    > Found 256x6-bit ROM for signal <$rom0003>.
    > Found 256x6-bit ROM for signal <$rom0004>.
    > Found 256x12-bit ROM for signal <$rom0005>.
    > Found 256x6-bit ROM for signal <$rom0006>.
    > Found 256x3-bit ROM for signal <$rom0007>.
    > Found 256x6-bit ROM for signal <$rom0008>.
    > Found 256x3-bit ROM for signal <$rom0009>.
    > Found 256x6-bit ROM for signal <$rom0010>.
    > Found 256x12-bit ROM for signal <$rom0011>
    >
    > It seems that instantation of ROMs via CoreGen is not preferable, as
    > far as I understand the CoreGen instantiation, I have to instantiate
    > 180 Coregen ROMs because each ROM has a different content?
    >
    > Hope you can help me and give me some suggestions how I can get these
    > ROMs packed into the fpga.
    >
    > Thanks in advance and regards,
    > Peter
    , Sep 5, 2006
    #2
    1. Advertising

  3. Hold on, are you sure you're describing the memory in a way which is
    compatible with the operation of a RAM?
    Like - you read it using an address, line by line? and that the size of each
    stored element is the same?
    The synthesis tool will only do what it can with what it's given!

    You should describe this array as a ROM, with address and possibly an FSM
    for reading it - then your synthesiser has a chance of making it fit into a
    block ram. (i.e. make a component in vhdl called my_rom which has input and
    output ports that operate in a way compatible both with your project, AND
    with instantiation in a block ram.)

    Good luck!
    Ben

    <> wrote in message
    news:...
    > Just found out that the XC2VP30 has 136 Block RAMs with 18Kb each.
    > As you can use the Block RAM as dual port RAM, it should be possible to
    > store
    > my 180 ROMs consisting of 221 bits each (13*17 bits).
    >
    > But how to instantiate it? I looked via the FPGA Editor into my design
    > and the BRAMs seem to be empty...
    >
    > Regards,
    > Peter
    >
    > schrieb:
    >
    >> Hi,
    >>
    >> I have to store a large amount of coefficients in my FPGA for
    >> multiplication:
    >>
    >> type coefficient is array(12 downto 0) of signed(17 downto 0);
    >>
    >> type coefficients is array(179 downto 0) of coefficient;
    >>
    >> constant coefficientsArray : coefficients :=
    >> (("100000000001010010","100000000101001110","000001100101010110",
    >> "000011011101000011","110000011110011010","110001111011011000",
    >> "010110100011101111","001011110111000110","100100000010011111",
    >> "100001000001001001","000000000101111111","000000000000101110",
    >> "100000000000000001"), .... );
    >>
    >> So I expect this to be synthesizes into 180 ROMs consisting of 13
    >> 17-Bit values.
    >> I assumed that I can store these values in my Virtex 2 Pro XC30 using
    >> the 2,048 kb of Block RAM.
    >>
    >> Unfortunately, this design together with the multiplication part needs
    >> 153% of the fpga space.
    >> For testing puposes I reduced the coefficientsArray to 6 and get a
    >> synthesis result of about 54% of the fpga.
    >> Using the option in Synthesize->XST in Xilinx ISE for ROM Style = Block
    >> gives no improvement.
    >>
    >> So here are my questions :)
    >> Is it possible to get the design I expect? Meaning 180 ROMS in Block
    >> RAM? Each clock cycle, I need 169 of these values. Or this task not
    >> possible for this fpga?
    >> Until now I hope Xilinx ISE infers these ROMS into Block ROM, but I do
    >> not know if this is the case, the synthesis report mentions the
    >> instantiation of ROMs as follows:
    >>
    >> Found 256x6-bit ROM for signal <$rom0001>.
    >> Found 256x6-bit ROM for signal <$rom0002>.
    >> Found 256x6-bit ROM for signal <$rom0003>.
    >> Found 256x6-bit ROM for signal <$rom0004>.
    >> Found 256x12-bit ROM for signal <$rom0005>.
    >> Found 256x6-bit ROM for signal <$rom0006>.
    >> Found 256x3-bit ROM for signal <$rom0007>.
    >> Found 256x6-bit ROM for signal <$rom0008>.
    >> Found 256x3-bit ROM for signal <$rom0009>.
    >> Found 256x6-bit ROM for signal <$rom0010>.
    >> Found 256x12-bit ROM for signal <$rom0011>
    >>
    >> It seems that instantation of ROMs via CoreGen is not preferable, as
    >> far as I understand the CoreGen instantiation, I have to instantiate
    >> 180 Coregen ROMs because each ROM has a different content?
    >>
    >> Hope you can help me and give me some suggestions how I can get these
    >> ROMs packed into the fpga.
    >>
    >> Thanks in advance and regards,
    >> Peter

    >
    Benjamin Todd, Sep 5, 2006
    #3
  4. jacko Guest

    hi

    > >
    > >> Hi,
    > >>
    > >> I have to store a large amount of coefficients in my FPGA for
    > >> multiplication:
    > >>
    > >> type coefficient is array(12 downto 0) of signed(17 downto 0);
    > >>
    > >> type coefficients is array(179 downto 0) of coefficient;
    > >>
    > >> constant coefficientsArray : coefficients :=
    > >> (("100000000001010010","100000000101001110","000001100101010110",
    > >> "000011011101000011","110000011110011010","110001111011011000",
    > >> "010110100011101111","001011110111000110","100100000010011111",
    > >> "100001000001001001","000000000101111111","000000000000101110",
    > >> "100000000000000001"), .... );
    > >>
    > >> So I expect this to be synthesizes into 180 ROMs consisting of 13
    > >> 17-Bit values.
    > >> I assumed that I can store these values in my Virtex 2 Pro XC30 using
    > >> the 2,048 kb of Block RAM.
    > >>


    seems like your 2D array is not linear (1D-RAM)

    either make 1 array, and use high bits for 1 of 180 (8 bits) or use two
    rams, with one performing indirection. a la 68K microcode saving
    technique, using unique states wide RAM indexed by state number narrow
    address, comming out of state needed RAM.

    if you need all in one cycle i think you need some kind of mega RAM
    width, and not implemented in ram block. => clock speed needs to be
    lowered, or get a bigger chip, or have a massive external DRAM array.

    cheers.
    jacko, Sep 5, 2006
    #4
  5. Hendrik Guest

    Altera has a "Recommended HDL Coding Styles" chapter in its Quartus
    Handbook (www.altera.com/literature/hb/qts/qts_qii51007.pdf). There is
    an explanation how to infer ROM from HDL code.
    I suppose this will also work for Xilinx ISE.

    Regards,
    Hendrik.

    wrote:
    > Hi,
    >
    > I have to store a large amount of coefficients in my FPGA for
    > multiplication:
    >
    > type coefficient is array(12 downto 0) of signed(17 downto 0);
    >
    > type coefficients is array(179 downto 0) of coefficient;
    >
    > constant coefficientsArray : coefficients :=
    > (("100000000001010010","100000000101001110","000001100101010110",
    > "000011011101000011","110000011110011010","110001111011011000",
    > "010110100011101111","001011110111000110","100100000010011111",
    > "100001000001001001","000000000101111111","000000000000101110",
    > "100000000000000001"), .... );
    >
    > So I expect this to be synthesizes into 180 ROMs consisting of 13
    > 17-Bit values.
    > I assumed that I can store these values in my Virtex 2 Pro XC30 using
    > the 2,048 kb of Block RAM.
    >
    > Unfortunately, this design together with the multiplication part needs
    > 153% of the fpga space.
    > For testing puposes I reduced the coefficientsArray to 6 and get a
    > synthesis result of about 54% of the fpga.
    > Using the option in Synthesize->XST in Xilinx ISE for ROM Style = Block
    > gives no improvement.
    >
    > So here are my questions :)
    > Is it possible to get the design I expect? Meaning 180 ROMS in Block
    > RAM? Each clock cycle, I need 169 of these values. Or this task not
    > possible for this fpga?
    > Until now I hope Xilinx ISE infers these ROMS into Block ROM, but I do
    > not know if this is the case, the synthesis report mentions the
    > instantiation of ROMs as follows:
    >
    > Found 256x6-bit ROM for signal <$rom0001>.
    > Found 256x6-bit ROM for signal <$rom0002>.
    > Found 256x6-bit ROM for signal <$rom0003>.
    > Found 256x6-bit ROM for signal <$rom0004>.
    > Found 256x12-bit ROM for signal <$rom0005>.
    > Found 256x6-bit ROM for signal <$rom0006>.
    > Found 256x3-bit ROM for signal <$rom0007>.
    > Found 256x6-bit ROM for signal <$rom0008>.
    > Found 256x3-bit ROM for signal <$rom0009>.
    > Found 256x6-bit ROM for signal <$rom0010>.
    > Found 256x12-bit ROM for signal <$rom0011>
    >
    > It seems that instantation of ROMs via CoreGen is not preferable, as
    > far as I understand the CoreGen instantiation, I have to instantiate
    > 180 Coregen ROMs because each ROM has a different content?
    >
    > Hope you can help me and give me some suggestions how I can get these
    > ROMs packed into the fpga.
    >
    > Thanks in advance and regards,
    > Peter
    >
    Hendrik, Sep 5, 2006
    #5
  6. Guest

    Thanks for your replies,

    as you mentioned I studied the various templates to infer ROMs so that
    the ISE
    can recongnize them. Now I have my ROM instantiated in Block RAM.

    Now I'll try to find out how to infer dual port ROMs in Block RAM.

    Regards,
    Peter


    Hendrik schrieb:

    > Altera has a "Recommended HDL Coding Styles" chapter in its Quartus
    > Handbook (www.altera.com/literature/hb/qts/qts_qii51007.pdf). There is
    > an explanation how to infer ROM from HDL code.
    > I suppose this will also work for Xilinx ISE.
    >
    > Regards,
    > Hendrik.
    >
    > wrote:
    > > Hi,
    > >
    > > I have to store a large amount of coefficients in my FPGA for
    > > multiplication:
    > >
    > > type coefficient is array(12 downto 0) of signed(17 downto 0);
    > >
    > > type coefficients is array(179 downto 0) of coefficient;
    > >
    > > constant coefficientsArray : coefficients :=
    > > (("100000000001010010","100000000101001110","000001100101010110",
    > > "000011011101000011","110000011110011010","110001111011011000",
    > > "010110100011101111","001011110111000110","100100000010011111",
    > > "100001000001001001","000000000101111111","000000000000101110",
    > > "100000000000000001"), .... );
    > >
    > > So I expect this to be synthesizes into 180 ROMs consisting of 13
    > > 17-Bit values.
    > > I assumed that I can store these values in my Virtex 2 Pro XC30 using
    > > the 2,048 kb of Block RAM.
    > >
    > > Unfortunately, this design together with the multiplication part needs
    > > 153% of the fpga space.
    > > For testing puposes I reduced the coefficientsArray to 6 and get a
    > > synthesis result of about 54% of the fpga.
    > > Using the option in Synthesize->XST in Xilinx ISE for ROM Style = Block
    > > gives no improvement.
    > >
    > > So here are my questions :)
    > > Is it possible to get the design I expect? Meaning 180 ROMS in Block
    > > RAM? Each clock cycle, I need 169 of these values. Or this task not
    > > possible for this fpga?
    > > Until now I hope Xilinx ISE infers these ROMS into Block ROM, but I do
    > > not know if this is the case, the synthesis report mentions the
    > > instantiation of ROMs as follows:
    > >
    > > Found 256x6-bit ROM for signal <$rom0001>.
    > > Found 256x6-bit ROM for signal <$rom0002>.
    > > Found 256x6-bit ROM for signal <$rom0003>.
    > > Found 256x6-bit ROM for signal <$rom0004>.
    > > Found 256x12-bit ROM for signal <$rom0005>.
    > > Found 256x6-bit ROM for signal <$rom0006>.
    > > Found 256x3-bit ROM for signal <$rom0007>.
    > > Found 256x6-bit ROM for signal <$rom0008>.
    > > Found 256x3-bit ROM for signal <$rom0009>.
    > > Found 256x6-bit ROM for signal <$rom0010>.
    > > Found 256x12-bit ROM for signal <$rom0011>
    > >
    > > It seems that instantation of ROMs via CoreGen is not preferable, as
    > > far as I understand the CoreGen instantiation, I have to instantiate
    > > 180 Coregen ROMs because each ROM has a different content?
    > >
    > > Hope you can help me and give me some suggestions how I can get these
    > > ROMs packed into the fpga.
    > >
    > > Thanks in advance and regards,
    > > Peter
    > >
    , Sep 6, 2006
    #6
  7. Guest

    Thanks for your replies,

    as you mentioned, I studied the various templates to infer ROMs so that
    the ISE
    can recongnize them. Now I have my ROM instantiated in Block RAM.

    Now I'll try to find out how to infer dual port ROMs in Block RAM.

    Regards,
    Peter


    Hendrik schrieb:

    > Altera has a "Recommended HDL Coding Styles" chapter in its Quartus
    > Handbook (www.altera.com/literature/hb/qts/qts_qii51007.pdf). There is
    > an explanation how to infer ROM from HDL code.
    > I suppose this will also work for Xilinx ISE.
    >
    > Regards,
    > Hendrik.
    >
    > wrote:
    > > Hi,
    > >
    > > I have to store a large amount of coefficients in my FPGA for
    > > multiplication:
    > >
    > > type coefficient is array(12 downto 0) of signed(17 downto 0);
    > >
    > > type coefficients is array(179 downto 0) of coefficient;
    > >
    > > constant coefficientsArray : coefficients :=
    > > (("100000000001010010","100000000101001110","000001100101010110",
    > > "000011011101000011","110000011110011010","110001111011011000",
    > > "010110100011101111","001011110111000110","100100000010011111",
    > > "100001000001001001","000000000101111111","000000000000101110",
    > > "100000000000000001"), .... );
    > >
    > > So I expect this to be synthesizes into 180 ROMs consisting of 13
    > > 17-Bit values.
    > > I assumed that I can store these values in my Virtex 2 Pro XC30 using
    > > the 2,048 kb of Block RAM.
    > >
    > > Unfortunately, this design together with the multiplication part needs
    > > 153% of the fpga space.
    > > For testing puposes I reduced the coefficientsArray to 6 and get a
    > > synthesis result of about 54% of the fpga.
    > > Using the option in Synthesize->XST in Xilinx ISE for ROM Style = Block
    > > gives no improvement.
    > >
    > > So here are my questions :)
    > > Is it possible to get the design I expect? Meaning 180 ROMS in Block
    > > RAM? Each clock cycle, I need 169 of these values. Or this task not
    > > possible for this fpga?
    > > Until now I hope Xilinx ISE infers these ROMS into Block ROM, but I do
    > > not know if this is the case, the synthesis report mentions the
    > > instantiation of ROMs as follows:
    > >
    > > Found 256x6-bit ROM for signal <$rom0001>.
    > > Found 256x6-bit ROM for signal <$rom0002>.
    > > Found 256x6-bit ROM for signal <$rom0003>.
    > > Found 256x6-bit ROM for signal <$rom0004>.
    > > Found 256x12-bit ROM for signal <$rom0005>.
    > > Found 256x6-bit ROM for signal <$rom0006>.
    > > Found 256x3-bit ROM for signal <$rom0007>.
    > > Found 256x6-bit ROM for signal <$rom0008>.
    > > Found 256x3-bit ROM for signal <$rom0009>.
    > > Found 256x6-bit ROM for signal <$rom0010>.
    > > Found 256x12-bit ROM for signal <$rom0011>
    > >
    > > It seems that instantation of ROMs via CoreGen is not preferable, as
    > > far as I understand the CoreGen instantiation, I have to instantiate
    > > 180 Coregen ROMs because each ROM has a different content?
    > >
    > > Hope you can help me and give me some suggestions how I can get these
    > > ROMs packed into the fpga.
    > >
    > > Thanks in advance and regards,
    > > Peter
    > >
    , Sep 6, 2006
    #7
  8. Excellent - I'm pleased you managed, but one quick question - how come you
    need a dual-port ROM? I figure dual port is good for read /write... but read
    / read? Interesting.
    Ben

    <> wrote in message
    news:...
    > Thanks for your replies,
    >
    > as you mentioned, I studied the various templates to infer ROMs so that
    > the ISE
    > can recongnize them. Now I have my ROM instantiated in Block RAM.
    >
    > Now I'll try to find out how to infer dual port ROMs in Block RAM.
    >
    > Regards,
    > Peter
    >
    >
    > Hendrik schrieb:
    >
    >> Altera has a "Recommended HDL Coding Styles" chapter in its Quartus
    >> Handbook (www.altera.com/literature/hb/qts/qts_qii51007.pdf). There is
    >> an explanation how to infer ROM from HDL code.
    >> I suppose this will also work for Xilinx ISE.
    >>
    >> Regards,
    >> Hendrik.
    >>
    >> wrote:
    >> > Hi,
    >> >
    >> > I have to store a large amount of coefficients in my FPGA for
    >> > multiplication:
    >> >
    >> > type coefficient is array(12 downto 0) of signed(17 downto 0);
    >> >
    >> > type coefficients is array(179 downto 0) of coefficient;
    >> >
    >> > constant coefficientsArray : coefficients :=
    >> > (("100000000001010010","100000000101001110","000001100101010110",
    >> > "000011011101000011","110000011110011010","110001111011011000",
    >> > "010110100011101111","001011110111000110","100100000010011111",
    >> > "100001000001001001","000000000101111111","000000000000101110",
    >> > "100000000000000001"), .... );
    >> >
    >> > So I expect this to be synthesizes into 180 ROMs consisting of 13
    >> > 17-Bit values.
    >> > I assumed that I can store these values in my Virtex 2 Pro XC30 using
    >> > the 2,048 kb of Block RAM.
    >> >
    >> > Unfortunately, this design together with the multiplication part needs
    >> > 153% of the fpga space.
    >> > For testing puposes I reduced the coefficientsArray to 6 and get a
    >> > synthesis result of about 54% of the fpga.
    >> > Using the option in Synthesize->XST in Xilinx ISE for ROM Style = Block
    >> > gives no improvement.
    >> >
    >> > So here are my questions :)
    >> > Is it possible to get the design I expect? Meaning 180 ROMS in Block
    >> > RAM? Each clock cycle, I need 169 of these values. Or this task not
    >> > possible for this fpga?
    >> > Until now I hope Xilinx ISE infers these ROMS into Block ROM, but I do
    >> > not know if this is the case, the synthesis report mentions the
    >> > instantiation of ROMs as follows:
    >> >
    >> > Found 256x6-bit ROM for signal <$rom0001>.
    >> > Found 256x6-bit ROM for signal <$rom0002>.
    >> > Found 256x6-bit ROM for signal <$rom0003>.
    >> > Found 256x6-bit ROM for signal <$rom0004>.
    >> > Found 256x12-bit ROM for signal <$rom0005>.
    >> > Found 256x6-bit ROM for signal <$rom0006>.
    >> > Found 256x3-bit ROM for signal <$rom0007>.
    >> > Found 256x6-bit ROM for signal <$rom0008>.
    >> > Found 256x3-bit ROM for signal <$rom0009>.
    >> > Found 256x6-bit ROM for signal <$rom0010>.
    >> > Found 256x12-bit ROM for signal <$rom0011>
    >> >
    >> > It seems that instantation of ROMs via CoreGen is not preferable, as
    >> > far as I understand the CoreGen instantiation, I have to instantiate
    >> > 180 Coregen ROMs because each ROM has a different content?
    >> >
    >> > Hope you can help me and give me some suggestions how I can get these
    >> > ROMs packed into the fpga.
    >> >
    >> > Thanks in advance and regards,
    >> > Peter
    >> >

    >
    Benjamin Todd, Sep 6, 2006
    #8
  9. On Wed, 6 Sep 2006 11:27:50 +0200, "Benjamin Todd"
    <> wrote:

    >Excellent - I'm pleased you managed, but one quick question - how come you
    >need a dual-port ROM? I figure dual port is good for read /write... but read
    >/ read? Interesting.


    It's a good technique for doubling the number of read ports (e.g. for
    filter coefficients) available. If you need small ROMs the two ports can
    act as completely independent ROMs mapped into different areas within
    the same BlockRam.

    - Brian
    Brian Drummond, Sep 6, 2006
    #9
  10. Guest

    Brian Drummond schrieb:

    > On Wed, 6 Sep 2006 11:27:50 +0200, "Benjamin Todd"
    > <> wrote:
    >
    > >Excellent - I'm pleased you managed, but one quick question - how come you
    > >need a dual-port ROM? I figure dual port is good for read /write... but read
    > >/ read? Interesting.

    >
    > It's a good technique for doubling the number of read ports (e.g. for
    > filter coefficients) available. If you need small ROMs the two ports can
    > act as completely independent ROMs mapped into different areas within
    > the same BlockRam.


    That's why I need them. I have 180 arrays consisting of 13 17-Bit
    values. But there are only 136 BRAMs on my board. So I just "half" them
    and I've now theoretically space for 272 of my Arrays.

    The Dual Port BRAM can be designed be using a dual port BRAM and just
    set the we input constantly to zero (if active high).

    Regards,
    Peter

    >
    > - Brian
    , Sep 6, 2006
    #10
  11. Ah, thanks for that. I guess provided your coefficients are compatible with
    the two halves then it makes sense to share them.
    <> wrote in message
    news:...
    > Brian Drummond schrieb:
    >
    >> On Wed, 6 Sep 2006 11:27:50 +0200, "Benjamin Todd"
    >> <> wrote:
    >>
    >> >Excellent - I'm pleased you managed, but one quick question - how come
    >> >you
    >> >need a dual-port ROM? I figure dual port is good for read /write... but
    >> >read
    >> >/ read? Interesting.

    >>
    >> It's a good technique for doubling the number of read ports (e.g. for
    >> filter coefficients) available. If you need small ROMs the two ports can
    >> act as completely independent ROMs mapped into different areas within
    >> the same BlockRam.

    >
    > That's why I need them. I have 180 arrays consisting of 13 17-Bit
    > values. But there are only 136 BRAMs on my board. So I just "half" them
    > and I've now theoretically space for 272 of my Arrays.
    >
    > The Dual Port BRAM can be designed be using a dual port BRAM and just
    > set the we input constantly to zero (if active high).
    >
    > Regards,
    > Peter
    >
    >>
    >> - Brian

    >
    Benjamin Todd, Sep 6, 2006
    #11
  12. "Benjamin Todd" <>
    wrote in message news:edmetg$cd5$...
    > Ah, thanks for that. I guess provided your coefficients are compatible
    > with the two halves then it makes sense to share them.


    or indeed making more effective use of the blockram, even if the
    coefficients aren't shared

    > <> wrote in message
    > news:...
    >> Brian Drummond schrieb:
    >>
    >>> On Wed, 6 Sep 2006 11:27:50 +0200, "Benjamin Todd"
    >>> <> wrote:
    >>>
    >>> >Excellent - I'm pleased you managed, but one quick question - how come
    >>> >you
    >>> >need a dual-port ROM? I figure dual port is good for read /write... but
    >>> >read
    >>> >/ read? Interesting.
    >>>
    >>> It's a good technique for doubling the number of read ports (e.g. for
    >>> filter coefficients) available. If you need small ROMs the two ports can
    >>> act as completely independent ROMs mapped into different areas within
    >>> the same BlockRam.

    >>
    >> That's why I need them. I have 180 arrays consisting of 13 17-Bit
    >> values. But there are only 136 BRAMs on my board. So I just "half" them
    >> and I've now theoretically space for 272 of my Arrays.
    >>
    >> The Dual Port BRAM can be designed be using a dual port BRAM and just
    >> set the we input constantly to zero (if active high).
    >>
    >> Regards,
    >> Peter
    >>
    >>>
    >>> - Brian

    >>

    >
    >
    Benjamin Todd, Sep 6, 2006
    #12
  13. KJ Guest

    "Brian Drummond" <> wrote in message
    news:...
    > On Wed, 6 Sep 2006 11:27:50 +0200, "Benjamin Todd"
    > <> wrote:
    >
    >>Excellent - I'm pleased you managed, but one quick question - how come
    >>you
    >>need a dual-port ROM? I figure dual port is good for read /write... but
    >>read
    >>/ read? Interesting.

    >
    > It's a good technique for doubling the number of read ports (e.g. for
    > filter coefficients) available. If you need small ROMs the two ports can
    > act as completely independent ROMs mapped into different areas within
    > the same BlockRam.
    >


    Are you assuming that the Xilinx software doesn't have enough smarts to
    combine several small ROMs into a single BlockRam? Or is this a known
    limitation that you just have to code around (i..e by making a single dual
    port ROM when what your design intended was two smaller ROMs).

    In other words, if you had simply coded the "180 arrays consisting of..."
    (as you mentioned in a later post) as being 180 single port ROMs the fitter
    'should' be able to partition the BlockRam usage to fit them all into the
    136 that are available. The 'Brand A' software seems to do a good job of
    parsing things into available memory of different sizes, so I'm wondering
    why the 'Brand X' software wouldn't as well....unless like I said, you're
    making an assumption that isn't necessary or desirable.

    Where is Peter Alfke when you need him? ;)

    KJ
    KJ, Sep 7, 2006
    #13
  14. Guest

    KJ schrieb:

    > Are you assuming that the Xilinx software doesn't have enough smarts to
    > combine several small ROMs into a single BlockRam? Or is this a known
    > limitation that you just have to code around (i..e by making a single dual
    > port ROM when what your design intended was two smaller ROMs).


    Well, I'm not assuming it :) I made the experience that this does not
    fit :)
    First, I implemented the 180 array consisting of, the "brand X"
    Software recognizes that
    I want to instantiate ROMs but they were mapped into LUTs.
    Of course, it is possible that the software will map single port roms
    into a dual port block rom, I have not tried it.

    Regards,
    Peter

    > In other words, if you had simply coded the "180 arrays consisting of..."
    > (as you mentioned in a later post) as being 180 single port ROMs the fitter
    > 'should' be able to partition the BlockRam usage to fit them all into the
    > 136 that are available. The 'Brand A' software seems to do a good job of
    > parsing things into available memory of different sizes, so I'm wondering
    > why the 'Brand X' software wouldn't as well....unless like I said, you're
    > making an assumption that isn't necessary or desirable.
    >
    > Where is Peter Alfke when you need him? ;)
    >
    > KJ
    , Sep 8, 2006
    #14
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Hari

    FFT using Xilinx ISE

    Hari, Dec 30, 2003, in forum: VHDL
    Replies:
    1
    Views:
    4,285
    Mike Treseler
    Jan 5, 2004
  2. Replies:
    1
    Views:
    787
    MariuszK
    Sep 11, 2006
  3. --MMS--
    Replies:
    2
    Views:
    1,045
    --MMS--
    May 15, 2007
  4. tanukichu
    Replies:
    2
    Views:
    1,241
    jeppe
    Jul 21, 2008
  5. hangeonos
    Replies:
    0
    Views:
    764
    hangeonos
    May 24, 2009
Loading...

Share This Page