FPGA Central

Hello all,

Using WebPACK version 8.1i03 initially synthesized RAM vanishes later in
the design???
The design works perfectly OK in WebPACK version 7.1i04, so I would assume that something
drastic as this should not happen.
The VHDL code also works on Altera FPGAs.
I am using Spartan3 here.

I must be doing something obviously wrong, but what?
Anyone can shed a light on it? It would be much appreciated.

,
The design is the 8051-microcontroller, version 1.4, with patches from
http://www.oregano.at/ip/8051.htm

Initially all RAM's are synthesized as in the 7.1i version, but are later largely removed.
The VHDL code of one of the RAMs can be found below.
The directory with the complete design can be found at
http://www.cs.rug.nl/~sietse/8051

But here are the relevant (i think) parts of the log:

FROM THE SYNTHESIS REPORT:
=========================

Synthesizing Unit <mc8051_ramx>.
Related source file is "/net/users/sietse/FPGA/versie-8.1i/8051/geheugen.vhdl".
WARNING:Xst:647 - Input <reset> is never used.
WARNING:Xst:647 - Input <ram_adr_i<15:13>> is never used.
Found 8192x8-bit single-port block RAM for signal <extram>.
-----------------------------------------------------------------------
| mode | read-first | |
| aspect ratio | 8192-word x 8-bit | |
| clock | connected to signal <clk> | rise |
| write enable | connected to signal <ram_wr_i> | high |
| address | connected to signal <int_ram_adr> | |
| data in | connected to signal <ram_data_i> | |
| data out | connected to signal <ram_data_o> | |
| ram_style | Auto | |
-----------------------------------------------------------------------
Summary:
inferred 1 RAM(s).
Unit <mc8051_ramx> synthesized.

AND SIMILAR FOR THE OTHER RAMs. AND THEN LATER:
==============================================

Macro Statistics
# Block RAMs : 3
128x8-bit single-port block RAM : 1
16384x8-bit single-port block RAM : 1
8192x8-bit single-port block RAM : 1

SO THE RAMs are synthesized initially!
======================================
THEN A NUMBER (7) OF STRANGE INFOs:
===================================

INFO:Xst:2399 - RAMs <inst_Mram_mem51>, <inst_Mram_mem41> are equivalent, second RAM is removed

DON'T KNOW WHAT THIS MEANS.
AND THE FINAL (synthesizer) REPORT NOTES:
===========================
# RAMS : 2
# RAMB16_S1 : 1
# RAMB16_S9 : 1

SO MOST RAMs ARE GONE!!!
=======================
=======================

What is going wrong here? Anyone an idea?

I also installed the WebPack on two different machines.

Regards,
Sietse Achterop
Computing Science department
University of Groningen

PS. I want to use this design in a number of courses that I am giving here.


================================================== =============
The VHDL RAM descriptions are like:

library IEEE;
use IEEE.std_logic_1164.all;
use IEEE.std_logic_arith.all;

entity mc8051_ramx is

port (clk : in std_logic; -- clock signal
reset : in std_logic; -- reset signal
ram_data_i : in std_logic_vector(7 downto 0); -- data input
ram_data_o : out std_logic_vector(7 downto 0); -- data output
ram_adr_i : in std_logic_vector(15 downto 0); -- adresses
ram_wr_i : in std_logic); -- read=0, write=1

end mc8051_ramx;


architecture behav of mc8051_ramx is

type ram_type is array (8191 downto 0) of std_logic_vector(7 downto 0);

signal extram: ram_type;
signal int_ram_adr : std_logic_vector(12 downto 0);

begin
int_ram_adr <= ram_adr_i(12 downto 0);

p_read : process (clk)
begin
if rising_edge(clk) then
ram_data_o <= extram(conv_integer(unsigned(int_ram_adr)));
end if;
end process p_read;

p_write : process (clk)
begin
if rising_edge(clk) then
if (ram_wr_i='1') then
extram(conv_integer(unsigned(int_ram_adr))) <= ram_data_i;
end if;
end if;
end process p_write;

end behav;

[email protected]d wrote:
> something

I don't know whats wrong here, but my email is:
[email protected]

Regards,
Sietse Achterop

you have a 8K memory but it seems from the log file that you are not
using the all the address bits,
WARNING:Xst:647 - Input <ram_adr_i<15:13>> is never used.
which means that you basically need only 1K from the total of 8K and XST
remove the rest, I think this make sense if you keep these addresses
tied to a constant.
Aurash
[email protected]d wrote:

> Hello all,
>
> Using WebPACK version 8.1i03 initially synthesized RAM vanishes later in
> the design???
> The design works perfectly OK in WebPACK version 7.1i04, so I would
> assume that something
> drastic as this should not happen.
> The VHDL code also works on Altera FPGAs.
> I am using Spartan3 here.
>
> I must be doing something obviously wrong, but what?
> Anyone can shed a light on it? It would be much appreciated.
>
> ,
> The design is the 8051-microcontroller, version 1.4, with patches from
> http://www.oregano.at/ip/8051.htm
>
> Initially all RAM's are synthesized as in the 7.1i version, but are
> later largely removed.
> The VHDL code of one of the RAMs can be found below.
> The directory with the complete design can be found at
> http://www.cs.rug.nl/~sietse/8051
>
> But here are the relevant (i think) parts of the log:
>
> FROM THE SYNTHESIS REPORT:
> =========================
>
> Synthesizing Unit <mc8051_ramx>.
> Related source file is
> "/net/users/sietse/FPGA/versie-8.1i/8051/geheugen.vhdl".
> WARNING:Xst:647 - Input <reset> is never used.
> WARNING:Xst:647 - Input <ram_adr_i<15:13>> is never used.
> Found 8192x8-bit single-port block RAM for signal <extram>.
>
> -----------------------------------------------------------------------
> | mode | read-first
> | |
> | aspect ratio | 8192-word x 8-bit
> | |
> | clock | connected to signal <clk> |
> rise |
> | write enable | connected to signal <ram_wr_i> |
> high |
> | address | connected to signal <int_ram_adr>
> | |
> | data in | connected to signal <ram_data_i>
> | |
> | data out | connected to signal <ram_data_o>
> | |
> | ram_style | Auto
> | |
>
> -----------------------------------------------------------------------
> Summary:
> inferred 1 RAM(s).
> Unit <mc8051_ramx> synthesized.
>
> AND SIMILAR FOR THE OTHER RAMs. AND THEN LATER:
> ==============================================
>
> Macro Statistics
> # Block RAMs : 3
> 128x8-bit single-port block RAM : 1
> 16384x8-bit single-port block RAM : 1
> 8192x8-bit single-port block RAM : 1
>
> SO THE RAMs are synthesized initially!
> ======================================
> THEN A NUMBER (7) OF STRANGE INFOs:
> ===================================
>
> INFO:Xst:2399 - RAMs <inst_Mram_mem51>, <inst_Mram_mem41> are
> equivalent, second RAM is removed
>
> DON'T KNOW WHAT THIS MEANS.
> AND THE FINAL (synthesizer) REPORT NOTES:
> ===========================
> # RAMS : 2
> # RAMB16_S1 : 1
> # RAMB16_S9 : 1
>
> SO MOST RAMs ARE GONE!!!
> =======================
> =======================
>
> What is going wrong here? Anyone an idea?
>
> I also installed the WebPack on two different machines.
>
> Regards,
> Sietse Achterop
> Computing Science department
> University of Groningen
>
> PS. I want to use this design in a number of courses that I am giving
> here.
>
>
> ================================================== =============
> The VHDL RAM descriptions are like:
>
> library IEEE;
> use IEEE.std_logic_1164.all;
> use IEEE.std_logic_arith.all;
>
> entity mc8051_ramx is
>
> port (clk : in std_logic; -- clock signal
> reset : in std_logic; -- reset signal
> ram_data_i : in std_logic_vector(7 downto 0); -- data input
> ram_data_o : out std_logic_vector(7 downto 0); -- data output
> ram_adr_i : in std_logic_vector(15 downto 0); -- adresses
> ram_wr_i : in std_logic); -- read=0, write=1
>
> end mc8051_ramx;
>
>
> architecture behav of mc8051_ramx is
>
> type ram_type is array (8191 downto 0) of std_logic_vector(7
> downto 0);
>
> signal extram: ram_type;
> signal int_ram_adr : std_logic_vector(12 downto 0);
>
> begin
> int_ram_adr <= ram_adr_i(12 downto 0);
>
> p_read : process (clk)
> begin
> if rising_edge(clk) then
> ram_data_o <= extram(conv_integer(unsigned(int_ram_adr)));
> end if;
> end process p_read;
>
> p_write : process (clk)
> begin
> if rising_edge(clk) then
> if (ram_wr_i='1') then
> extram(conv_integer(unsigned(int_ram_adr))) <= ram_data_i;
> end if;
> end if;
> end process p_write;
>
> end behav;



--
__
/ /\/\ Aurelian Lazarut
\ \ / System Verification Engineer
/ / \ Xilinx Ireland
\_\/\/

phone: 353 01 4032639
fax: 353 01 4640324

to be more precise you have:
int_ram_adr <= ram_adr_i(12 downto 0);

what about ram_adr_i(15 downto 13) who's driving them ?

Aurash

Aurelian Lazarut wrote:

> you have a 8K memory but it seems from the log file that you are not
> using the all the address bits,
> WARNING:Xst:647 - Input <ram_adr_i<15:13>> is never used.
> which means that you basically need only 1K from the total of 8K and
> XST remove the rest, I think this make sense if you keep these
> addresses tied to a constant.
> Aurash
> [email protected]d wrote:
>
>> Hello all,
>>
>> Using WebPACK version 8.1i03 initially synthesized RAM vanishes later in
>> the design???
>> The design works perfectly OK in WebPACK version 7.1i04, so I would
>> assume that something
>> drastic as this should not happen.
>> The VHDL code also works on Altera FPGAs.
>> I am using Spartan3 here.
>>
>> I must be doing something obviously wrong, but what?
>> Anyone can shed a light on it? It would be much appreciated.
>>
>> ,
>> The design is the 8051-microcontroller, version 1.4, with patches from
>> http://www.oregano.at/ip/8051.htm
>>
>> Initially all RAM's are synthesized as in the 7.1i version, but are
>> later largely removed.
>> The VHDL code of one of the RAMs can be found below.
>> The directory with the complete design can be found at
>> http://www.cs.rug.nl/~sietse/8051
>>
>> But here are the relevant (i think) parts of the log:
>>
>> FROM THE SYNTHESIS REPORT:
>> =========================
>>
>> Synthesizing Unit <mc8051_ramx>.
>> Related source file is
>> "/net/users/sietse/FPGA/versie-8.1i/8051/geheugen.vhdl".
>> WARNING:Xst:647 - Input <reset> is never used.
>> WARNING:Xst:647 - Input <ram_adr_i<15:13>> is never used.
>> Found 8192x8-bit single-port block RAM for signal <extram>.
>>
>> -----------------------------------------------------------------------
>> | mode | read-first
>> | |
>> | aspect ratio | 8192-word x 8-bit
>> | |
>> | clock | connected to signal <clk> |
>> rise |
>> | write enable | connected to signal <ram_wr_i> |
>> high |
>> | address | connected to signal <int_ram_adr>
>> | |
>> | data in | connected to signal <ram_data_i>
>> | |
>> | data out | connected to signal <ram_data_o>
>> | |
>> | ram_style | Auto
>> | |
>>
>> -----------------------------------------------------------------------
>> Summary:
>> inferred 1 RAM(s).
>> Unit <mc8051_ramx> synthesized.
>>
>> AND SIMILAR FOR THE OTHER RAMs. AND THEN LATER:
>> ==============================================
>>
>> Macro Statistics
>> # Block RAMs : 3
>> 128x8-bit single-port block RAM : 1
>> 16384x8-bit single-port block RAM : 1
>> 8192x8-bit single-port block RAM : 1
>>
>> SO THE RAMs are synthesized initially!
>> ======================================
>> THEN A NUMBER (7) OF STRANGE INFOs:
>> ===================================
>>
>> INFO:Xst:2399 - RAMs <inst_Mram_mem51>, <inst_Mram_mem41> are
>> equivalent, second RAM is removed
>>
>> DON'T KNOW WHAT THIS MEANS.
>> AND THE FINAL (synthesizer) REPORT NOTES:
>> ===========================
>> # RAMS : 2
>> # RAMB16_S1 : 1
>> # RAMB16_S9 : 1
>>
>> SO MOST RAMs ARE GONE!!!
>> =======================
>> =======================
>>
>> What is going wrong here? Anyone an idea?
>>
>> I also installed the WebPack on two different machines.
>>
>> Regards,
>> Sietse Achterop
>> Computing Science department
>> University of Groningen
>>
>> PS. I want to use this design in a number of courses that I am giving
>> here.
>>
>>
>> ================================================== =============
>> The VHDL RAM descriptions are like:
>>
>> library IEEE;
>> use IEEE.std_logic_1164.all;
>> use IEEE.std_logic_arith.all;
>>
>> entity mc8051_ramx is
>>
>> port (clk : in std_logic; -- clock signal
>> reset : in std_logic; -- reset signal
>> ram_data_i : in std_logic_vector(7 downto 0); -- data input
>> ram_data_o : out std_logic_vector(7 downto 0); -- data output
>> ram_adr_i : in std_logic_vector(15 downto 0); -- adresses
>> ram_wr_i : in std_logic); -- read=0, write=1
>>
>> end mc8051_ramx;
>>
>>
>> architecture behav of mc8051_ramx is
>>
>> type ram_type is array (8191 downto 0) of std_logic_vector(7
>> downto 0);
>>
>> signal extram: ram_type;
>> signal int_ram_adr : std_logic_vector(12 downto 0);
>>
>> begin
>> int_ram_adr <= ram_adr_i(12 downto 0);
>>
>> p_read : process (clk)
>> begin
>> if rising_edge(clk) then
>> ram_data_o <= extram(conv_integer(unsigned(int_ram_adr)));
>> end if;
>> end process p_read;
>>
>> p_write : process (clk)
>> begin
>> if rising_edge(clk) then
>> if (ram_wr_i='1') then
>> extram(conv_integer(unsigned(int_ram_adr))) <= ram_data_i;
>> end if;
>> end if;
>> end process p_write;
>>
>> end behav;
>
>
>
>


--
__
/ /\/\ Aurelian Lazarut
\ \ / System Verification Engineer
/ / \ Xilinx Ireland
\_\/\/

phone: 353 01 4032639
fax: 353 01 4640324

Aurelian Lazarut wrote:
> to be more precise you have:
> int_ram_adr <= ram_adr_i(12 downto 0);
>
> what about ram_adr_i(15 downto 13) who's driving them ?
>
> Aurash
>
> Aurelian Lazarut wrote:
>
>> you have a 8K memory but it seems from the log file that you are not
>> using the all the address bits,
>> WARNING:Xst:647 - Input <ram_adr_i<15:13>> is never used.
>> which means that you basically need only 1K from the total of 8K and
>> XST remove the rest, I think this make sense if you keep these
>> addresses tied to a constant.
>> Aurash

Hello Aurash,

thanks for the prompt reply.
(the 8KB memory serves as the external RAM of the 8051)
But 8 KByte uses 13 address bits, so that's ok. The 8051 cpu has 16
address bits and only 13 bits for the lower 8 KB are used.
Or better, the 8KB is repeated 8 times in the 64KB address space.
So all 13 address lines for the RAM are used, and I don't see why
it is optimized away.

Sietse

On Tue, 27 Jun 2006 20:17:29 +0200, Sietse Achterop <[email protected]>
wrote:

>Aurelian Lazarut wrote:
>> to be more precise you have:
>> int_ram_adr <= ram_adr_i(12 downto 0);
>>
>> what about ram_adr_i(15 downto 13) who's driving them ?
>>
>> Aurash
>>
>> Aurelian Lazarut wrote:
>>
>>> you have a 8K memory but it seems from the log file that you are not
>>> using the all the address bits,
>>> WARNING:Xst:647 - Input <ram_adr_i<15:13>> is never used.
>>> which means that you basically need only 1K from the total of 8K and
>>> XST remove the rest, I think this make sense if you keep these
>>> addresses tied to a constant.
>>> Aurash
>
> Hello Aurash,
>
>thanks for the prompt reply.
> (the 8KB memory serves as the external RAM of the 8051)
>But 8 KByte uses 13 address bits, so that's ok. The 8051 cpu has 16
>address bits and only 13 bits for the lower 8 KB are used.
>Or better, the 8KB is repeated 8 times in the 64KB address space.
>So all 13 address lines for the RAM are used, and I don't see why
>it is optimized away.
>
> Sietse

In your code, I didn't see any decoding of the top 3 bits to enable
one of the 8 rams to cover the whole 64k range. That's the reason it
thinks all the memories are identical, you are using the same 13 bits
to drive them. You should somehow differentiate them, probably with an
enable signal generated from the top 3 bits (maybe you're doing that
during the generation of read/write strobe?). Why it's removing the
last 8k memory I am not sure as you are certainly driving the inputs;
check the top level connectivity for reading the outputs of the memory
into the core.

mk wrote:
> In your code, I didn't see any decoding of the top 3 bits to enable
> one of the 8 rams to cover the whole 64k range. That's the reason it
> thinks all the memories are identical, you are using the same 13 bits
> to drive them. You should somehow differentiate them, probably with an
> enable signal generated from the top 3 bits (maybe you're doing that
> during the generation of read/write strobe?). Why it's removing the
> last 8k memory I am not sure as you are certainly driving the inputs;
> check the top level connectivity for reading the outputs of the memory
> into the core.

One moment I thought You had it, but alas.
To remove any doubt I used all 16 address bits in the decoding as in:

int_ram_adr <= ram_adr_i(12 downto 0);

p_read : process (clk)
begin
if rising_edge(clk) then
if ram_adr_i(15 downto 13) = "000" then
ram_data_o <= extram(conv_integer(int_ram_adr));
else
ram_data_o <= "00000000";
end if;

end if;
end process p_read;


But apart from less warnings nothing changed.

Sietse

Sietse,,
you are right my mystake, 13 address lines makes 8K locations (sorry for
the confusion)
anyway I synthesized your original code with ISE8.2 and works fine for me.

Device utilization summary:
---------------------------

Selected Device : 3s100evq100-5

Number of Slices: 0 out of 960 0%
Number of IOs: 35
Number of bonded IOBs: 31 out of 66 46%
Number of BRAMs: 4 out of 4 100%
Number of GCLKs: 1 out of 24 4%

____________________
Can you please run XST for this file only (in isolation) to see if you
get the expected results

Aurelian

Sietse Achterop wrote:

> Aurelian Lazarut wrote:
>
>> to be more precise you have:
>> int_ram_adr <= ram_adr_i(12 downto 0);
>>
>> what about ram_adr_i(15 downto 13) who's driving them ?
>>
>> Aurash
>>
>> Aurelian Lazarut wrote:
>>
>>> you have a 8K memory but it seems from the log file that you are not
>>> using the all the address bits,
>>> WARNING:Xst:647 - Input <ram_adr_i<15:13>> is never used.
>>> which means that you basically need only 1K from the total of 8K and
>>> XST remove the rest, I think this make sense if you keep these
>>> addresses tied to a constant.
>>> Aurash
>>
>
> Hello Aurash,
>
> thanks for the prompt reply.
> (the 8KB memory serves as the external RAM of the 8051)
> But 8 KByte uses 13 address bits, so that's ok. The 8051 cpu has 16
> address bits and only 13 bits for the lower 8 KB are used.
> Or better, the 8KB is repeated 8 times in the 64KB address space.
> So all 13 address lines for the RAM are used, and I don't see why
> it is optimized away.
>
> Sietse



--
__
/ /\/\ Aurelian Lazarut
\ \ / System Verification Engineer
/ / \ Xilinx Ireland
\_\/\/

phone: 353 01 4032639
fax: 353 01 4640324

Aurelian Lazarut wrote:

> anyway I synthesized your original code with ISE8.2 and works fine for me.

Aurelian,

Thanks for trying. So the conclusion is that in 8.1 some bug is triggered, but
not in 8.2.
I'll try again in a few weeks when hopefully Webpack 8.2 is available.

Actually the reason that I tried 8.2 is that there were problems with 7.1.
The 8051 ran perfectly until interrupts were used. Then there is some intermittent
and very unpredictable behavior, mostly spontaneous resets of the 8051.
But very difficult to isolate.

Hopefully 8.2 also doesn't have that problem either.

Thanks again,
Sietse