coregenerator bram in synplify pro error

I am trying to get rams in xilinx to synthesize in synplify pro. I am
a novice in syplify pro. I used the core generator to generate BRAM
and then since for brams we cannot generate edif files I used ngc2edif
to convert it to .ndf. I then added these ndf files into the project.
Howewver I seem to get an error with the synplify pro.The core is a
simple dual port RAM with a write port A and a read port B
The error is following. I dont know how the synplify pro picksup the
component from unisim.
I have given the components  name as ramb16_s18_s18.

ERROR : Port web of entity unisim.ramb16_s18_s18 is unconnected

The error is regarind port web which is a writ eenable prot of b . but
port b is just a read port with we disabled.

ni wrote:
> I am trying to get rams in xilinx to synthesize in synplify pro. I am
> a novice in syplify pro. I used the core generator to generate BRAM
> and then since for brams we cannot generate edif files I used ngc2edif
> to convert it to .ndf. I then added these ndf files into the project.
> Howewver I seem to get an error with the synplify pro.The core is a
> simple dual port RAM with a write port A and a read port B
> The error is following. I dont know how the synplify pro picksup the
> component from unisim.
> I have given the components  name as ramb16_s18_s18.
> 
> ERROR : Port web of entity unisim.ramb16_s18_s18 is unconnected
> 
> The error is regarind port web which is a writ eenable prot of b . but
> port b is just a read port with we disabled.
> 

Rather than actually answer the question, can I suggest that you infer 
BRAM rather than go through that complicated process? As a bonus, 
inferred BRAM simulates much faster. You would infer BRAM something like:


architecture synth of pp_ram is

    constant MEM_DEPTH   : integer := 2**AWIDTH;
    type mem_array is array(0 to MEM_DEPTH-1) of 
std_logic_vector(DWIDTH-1 downto 0);
    signal ram           : mem_array;
    signal rd_addr_ram   : unsigned(AWIDTH-1 downto 0);

    signal ADDRA      : unsigned(AWIDTH-1 downto 0);
    signal ADDRB      : unsigned(AWIDTH-1 downto 0);
    signal DIA        : std_logic_vector(DWIDTH-1 downto 0);
    signal DOB        : std_logic_vector(DWIDTH-1 downto 0);

begin
    -- infer block RAM
    wr_p: process(CLKI)
    begin
       if rising_edge(CLKI) then
          if WE = '1' then
             ram(to_integer(ADDRA)) <= std_logic_vector(DIA);
          end if;
       end if;
    end process wr_p;
    rd_p: process(CLKO)
    begin
       if rising_edge(CLKO) then
          rd_addr_ram <= ADDRB;
       end if;
    end process rd_p;
    DOB <= ram(to_integer(rd_addr_ram));

On Apr 2, 11:35 am, Duane Clark <u...@domaininvalid.com> wrote:
> ni wrote:
> > I am trying to get rams in xilinx to synthesize in synplify pro. I am
> > a novice in syplify pro. I used the core generator to generate BRAM
> > and then since for brams we cannot generate edif files I used ngc2edif
> > to convert it to .ndf. I then added these ndf files into the project.
> > Howewver I seem to get an error with the synplify pro.The core is a
> > simple dual port RAM with a write port A and a read port B
> > The error is following. I dont know how the synplify pro picksup the
> > component from unisim.
> > I have given the components  name as ramb16_s18_s18.
>
> > ERROR : Port web of entity unisim.ramb16_s18_s18 is unconnected
>
> > The error is regarind port web which is a writ eenable prot of b . but
> > port b is just a read port with we disabled.
>
> Rather than actually answer the question, can I suggest that you infer
> BRAM rather than go through that complicated process? As a bonus,
> inferred BRAM simulates much faster. You would infer BRAM something like:
>
> architecture synth of pp_ram is
>
>     constant MEM_DEPTH   : integer := 2**AWIDTH;
>     type mem_array is array(0 to MEM_DEPTH-1) of
> std_logic_vector(DWIDTH-1 downto 0);
>     signal ram           : mem_array;
>     signal rd_addr_ram   : unsigned(AWIDTH-1 downto 0);
>
>     signal ADDRA      : unsigned(AWIDTH-1 downto 0);
>     signal ADDRB      : unsigned(AWIDTH-1 downto 0);
>     signal DIA        : std_logic_vector(DWIDTH-1 downto 0);
>     signal DOB        : std_logic_vector(DWIDTH-1 downto 0);
>
> begin
>     -- infer block RAM
>     wr_p: process(CLKI)
>     begin
>        if rising_edge(CLKI) then
>           if WE = '1' then
>              ram(to_integer(ADDRA)) <= std_logic_vector(DIA);
>           end if;
>        end if;
>     end process wr_p;
>     rd_p: process(CLKO)
>     begin
>        if rising_edge(CLKO) then
>           rd_addr_ram <= ADDRB;
>        end if;
>     end process rd_p;
>     DOB <= ram(to_integer(rd_addr_ram));

My confusion is if I write this code to infer RAMS then once I do the
synthesis and then go to place and route then would it still be
considered as a BRAM? I thought Xilinx brams(generated through CORE
Generator ) would be much more optimised then inferred RAMS in
synplify since ultimately we would be using xilinx PAR.

ni wrote:
> 
> My confusion is if I write this code to infer RAMS then once I do the
> synthesis and then go to place and route then would it still be
> considered as a BRAM? I thought Xilinx brams(generated through CORE
> Generator ) would be much more optimised then inferred RAMS in
> synplify since ultimately we would be using xilinx PAR.

Using coregen definitely does not result in optimization during PAR (or 
MAP for that matter). When Synplify (or any synthesis tool) creates the 
edif file that will be used by the Xilinx tools, it puts primitives in 
there including BRAMs if they are correctly inferred in your code. It is 
useful to check the log file of the synthesis tool to verify that the 
expected number of BRAMs were inferred. If not, that might point to 
something you did wrong when inferring them.

On Apr 2, 4:04 pm, Duane Clark <u...@domaininvalid.com> wrote:
> ni wrote:
>
> > My confusion is if I write this code to infer RAMS then once I do the
> > synthesis and then go to place and route then would it still be
> > considered as a BRAM? I thought Xilinx brams(generated through CORE
> > Generator ) would be much more optimised then inferred RAMS in
> > synplify since ultimately we would be using xilinx PAR.
>
> Using coregen definitely does not result in optimization during PAR (or
> MAP for that matter). When Synplify (or any synthesis tool) creates the
> edif file that will be used by the Xilinx tools, it puts primitives in
> there including BRAMs if they are correctly inferred in your code. It is
> useful to check the log file of the synthesis tool to verify that the
> expected number of BRAMs were inferred. If not, that might point to
> something you did wrong when inferring them.

Thanks,
I will try that and see.

On Wed, 02 Apr 2008 08:35:27 -0700, Duane Clark <user@domaininvalid.com> wrote:

>ni wrote:
>> I am trying to get rams in xilinx to synthesize in synplify pro. I am
>> a novice in syplify pro. I used the core generator to generate BRAM
>> and then since for brams we cannot generate edif files I used ngc2edif
>> to convert it to .ndf. I then added these ndf files into the project.
>> Howewver I seem to get an error with the synplify pro.The core is a
>> simple dual port RAM with a write port A and a read port B
>> The error is following. I dont know how the synplify pro picksup the
>> component from unisim.
>> I have given the components  name as ramb16_s18_s18.
>> 
>> ERROR : Port web of entity unisim.ramb16_s18_s18 is unconnected
>> 
>> The error is regarind port web which is a writ eenable prot of b . but
>> port b is just a read port with we disabled.
>> 
>
>Rather than actually answer the question, can I suggest that you infer 
>BRAM rather than go through that complicated process? As a bonus, 
>inferred BRAM simulates much faster. You would infer BRAM something like:

Err, not necessarily a good idea.

For example, inferring a ROM wide enough to need both data buses and the parity
bits can cause three BRAMs to be used instead of one; to be fair, ISE 9.2
improved on 7.1 in my test case, only inferring twice as many BRAMS as
necessary.

However, initialising the ROM data using functions caused elaboration to take
significant time (of the order of hours for a couple of thousand elements) and
9.2 took twice as long as 7.1. I had to place an assert per memory location to
reassure me it was doing anything at all. There is some n^2 algorithm involved;
you could see it slow down, and doubling the ROM size quadrupled execution time.
I don't know if this has been fixed in 10.1 yet.

But it's a lovely idea when it actually works.

(Incidentally, according to the resulting webcase, the "something I did wrong
while inferring them" was ... inferring them. 
And the suggested instantiation template glossed over the problem of
initialisation entirely.)

Synplify probably handles BRAM inference much better; just be aware that relying
on it limits portability.

- Brian

Brian Drummond wrote:
>>>
>> Rather than actually answer the question, can I suggest that you infer 
>> BRAM rather than go through that complicated process? As a bonus, 
>> inferred BRAM simulates much faster. You would infer BRAM something like:
> 
> Err, not necessarily a good idea.
> 
> For example, inferring a ROM wide enough to need both data buses and the parity
> bits can cause three BRAMs to be used instead of one; to be fair, ISE 9.2
> improved on 7.1 in my test case, only inferring twice as many BRAMS as
> necessary.
> 
> However, initialising the ROM data using functions caused elaboration to take
> significant time (of the order of hours for a couple of thousand elements) and
> 9.2 took twice as long as 7.1. I had to place an assert per memory location to
> reassure me it was doing anything at all. There is some n^2 algorithm involved;
> you could see it slow down, and doubling the ROM size quadrupled execution time.
> I don't know if this has been fixed in 10.1 yet.
> 
> But it's a lovely idea when it actually works.
> 
> (Incidentally, according to the resulting webcase, the "something I did wrong
> while inferring them" was ... inferring them. 
> And the suggested instantiation template glossed over the problem of
> initialisation entirely.)
> 
> Synplify probably handles BRAM inference much better; just be aware that relying
> on it limits portability.
> 
> - Brian

Another limitation I have heard is that you can't infer dual port ram of 
differing port widths.

-Jeff

"Jeff Cunningham" <jcc@sover.net> wrote in message 
news:47f4e09f$0$19850$4d3efbfe@news.sover.net...
> Brian Drummond wrote:
>>>>
>>> Rather than actually answer the question, can I suggest that you infer 
>>> BRAM rather than go through that complicated process? As a bonus, 
>>> inferred BRAM simulates much faster. You would infer BRAM something 
>>> like:
>>
>> Err, not necessarily a good idea.
>>
>> For example, inferring a ROM wide enough to need both data buses and the 
>> parity
>> bits can cause three BRAMs to be used instead of one; to be fair, ISE 9.2
>> improved on 7.1 in my test case, only inferring twice as many BRAMS as
>> necessary.
>>
>> However, initialising the ROM data using functions caused elaboration to 
>> take
>> significant time (of the order of hours for a couple of thousand 
>> elements) and
>> 9.2 took twice as long as 7.1. I had to place an assert per memory 
>> location to
>> reassure me it was doing anything at all. There is some n^2 algorithm 
>> involved;
>> you could see it slow down, and doubling the ROM size quadrupled 
>> execution time.
>> I don't know if this has been fixed in 10.1 yet.
>>
>> But it's a lovely idea when it actually works.
>>
>> (Incidentally, according to the resulting webcase, the "something I did 
>> wrong
>> while inferring them" was ... inferring them. And the suggested 
>> instantiation template glossed over the problem of
>> initialisation entirely.)
>>
>> Synplify probably handles BRAM inference much better; just be aware that 
>> relying
>> on it limits portability.
>>
>> - Brian
>
> Another limitation I have heard is that you can't infer dual port ram of 
> differing port widths.
>
> -Jeff

Or with differnt clocks.  (OK, they may get inferred, but not efficiently.)

JTW 

Jeff Cunningham wrote:
> 
> Another limitation I have heard is that you can't infer dual port ram of 
> differing port widths.
> 

I prefer to infer multiple BRAMs, and simply wire them up to have a 
different input/output width, at the possible cost of a few extra BRAMs 
and a small amount of logic. This cost disappears if you are creating a 
memory that is big enough that you need the extra BRAMs anyway.

If I don't want to waste the BRAMs, I prefer to directly instantiate the 
BRAM, rather than use coregen.

Duane Clark wrote:

> I prefer to infer multiple BRAMs, and simply wire them up to have a
> different input/output width, at the possible cost of a few extra BRAMs
> and a small amount of logic. This cost disappears if you are creating a
> memory that is big enough that you need the extra BRAMs anyway.

... not to mention the extra value inherent in portable code.


           -- Mike Treseler