Functional Simulation of Virtex-4 Block Memory

I am doing my first FPGA design.  The design uses VHDL source with a
few Xilinx cores (a Virtex-4 device will be used).  One of the cores
is block memory used as ROM.  The design does not use an embedded
processor; the memory is addressed using a counter.  My problem is
that I don't know how to simulate the ROM.  I have searched the Xilinx
website and Xilinx help.  I am using the latest Xilinx ISE and Active-
HDL with all of the Xilinx simulation libraries furnished with the
simulator.  I want to do a functional simulation of the design using
the ROM loaded with the code that will be used in the completed
design.  The design synthesizes with no errors and compiles OK in
Active-HDL.  I have made the .coe file for the ROM.  I don't know what
to do next to simulate the design incorporating the ROM.  I can
simulate it using a VHDL model of the ROM that I designed, but that
does not give me a good feeling that the actual block ROM will work
correctly.

I will appreciate any advice on this.

Thanks,

Charles

charles.elias@wpafb.af.mil wrote:
> I am doing my first FPGA design.  The design uses VHDL source with a
> few Xilinx cores (a Virtex-4 device will be used).  One of the cores
> is block memory used as ROM.  The design does not use an embedded
> processor; the memory is addressed using a counter.  My problem is
> that I don't know how to simulate the ROM.  I have searched the Xilinx
> website and Xilinx help.  I am using the latest Xilinx ISE and Active-
> HDL with all of the Xilinx simulation libraries furnished with the
> simulator.  I want to do a functional simulation of the design using
> the ROM loaded with the code that will be used in the completed
> design.  The design synthesizes with no errors and compiles OK in
> Active-HDL.  I have made the .coe file for the ROM.  I don't know what
> to do next to simulate the design incorporating the ROM.  I can
> simulate it using a VHDL model of the ROM that I designed, but that
> does not give me a good feeling that the actual block ROM will work
> correctly.
> 
> I will appreciate any advice on this.

If you already have a behavioral VHDL model of the ROM, why did you 
generate a core? Why not just synthesize the model you have? You just 
need to stick a register between the address generation and the ROM. 
Check the log file from your synthesis tool, and verify that block 
memory was used.

When I started with ROMs circa ISE 6.2 the COE thing
wasn't working past some small number of values.
Someone prompty directed me to infer the ROM and not
use the core generator at all.

The VHDL looks something like this:

type i2c_array_type is array(natural range <>) of natural;
constant i2c_data_array : i2c_array_type :=(
0,0,0 -- put your constants here
);
signal i2c_bit_index0 : unsigned(2 downto 0);
begin
i2c_data1 <= i2c_data_array(i2c_dat_index0);

You can use natural,integer,enumerated data,std_logic_vectors,
or records to fit your design data type. All the simulation
data will be visible and the ISE reports will tell you how
many BRAMs were used. I don't think any deeper level of
simulation will provide you more confidence.

If you post your code, I'm sure we can help you debug some
of the issues regarding conversions and the like.

Brad Smallridge
AiVision

On Apr 29, 8:19=A0pm, "Brad Smallridge" <bradsmallri...@dslextreme.com>
wrote:
> When I started with ROMs circa ISE 6.2 the COE thing
> wasn't working past some small number of values.
> Someone prompty directed me to infer the ROM and not
> use the core generator at all.
>
> The VHDL looks something like this:
>
> type i2c_array_type is array(natural range <>) of natural;
> constant i2c_data_array : i2c_array_type :=3D(
> 0,0,0 -- put your constants here
> );
> signal i2c_bit_index0 : unsigned(2 downto 0);
> begin
> i2c_data1 <=3D i2c_data_array(i2c_dat_index0);
>
> You can use natural,integer,enumerated data,std_logic_vectors,
> or records to fit your design data type. All the simulation
> data will be visible and the ISE reports will tell you how
> many BRAMs were used. I don't think any deeper level of
> simulation will provide you more confidence.
>
> If you post your code, I'm sure we can help you debug some
> of the issues regarding conversions and the like.
>
> Brad Smallridge
> AiVision

Thanks for the replies.  I don't need help with the code for the ROM.
No problem with my writing the code and letting ISE infer the ROM,
however what if I wanted to use block memory for a dual-port memory.
This is a non-trivial coding effort.  I am wondering what use are the
memory cores if I am better off writing the code myself?  I thought
the purpose of the cores is not only to help the user by having the
code pre-written by Xilinx's experts, but also to ensure that the
design is optimal for fitting into the the FPGA.  I used a core adder/
subtractor and comparator with no problems.  The trick with the memory
seems to be simulating the memory with the contents loaded. so maybe
the dual-port memory would work OK.

Thanks,

Charles

charles.elias@wpafb.af.mil wrote:
> 
> Thanks for the replies.  I don't need help with the code for the ROM.
> No problem with my writing the code and letting ISE infer the ROM,
> however what if I wanted to use block memory for a dual-port memory.
> This is a non-trivial coding effort.  I am wondering what use are the
> memory cores if I am better off writing the code myself?  I thought
> the purpose of the cores is not only to help the user by having the
> code pre-written by Xilinx's experts, but also to ensure that the
> design is optimal for fitting into the the FPGA.  I used a core adder/
> subtractor and comparator with no problems.  The trick with the memory
> seems to be simulating the memory with the contents loaded. so maybe
> the dual-port memory would work OK.

Inferring a dual port memory is just as easy as a single port memory:

    constant AWIDTH         : integer := 8;
    type drngs_array is array(0 to 2**AWIDTH-1) of std_logic_vector(31 
downto 0);
    signal drngs_ram        : drngs_array;
    signal rd_addr_drngs    : unsigned(AWIDTH-1 downto 0);

    drngs_wr_p: process(CLK)
    begin
       if rising_edge(CLK) then
          if DRNGS_WE = '1' then
             drngs_ram(to_integer(DRNGS_WADR)) <= std_logic_vector(DRNGSI);
          end if;
       end if;
    end process drngs_wr_p;
    drngs_rd_p: process(CLK)
    begin
       if rising_edge(CLK) then
          rd_addr_drngs <= DRNGS_RADR;
       end if;
    end process drngs_rd_p;
    DRNGSO <= drngs_ram(to_integer(rd_addr_drngs));

I really cannot see a reason to be using coregen for things like rams, 
adders, or comparators. Synthesis tools will do just as good as coregen. 
I can see using it for complex things like FFTs and such.

>Thanks for the replies.  I don't need help with the code for the ROM.
>No problem with my writing the code and letting ISE infer the ROM,
>however what if I wanted to use block memory for a dual-port memory.

You mention ROM in your original post. That's what I answered.

>This is a non-trivial coding effort.

I haven't done any elaborate dual port BRAMs because everthing
I have done fits into a single or maybe two BRAMs.  Yeah, I suppose
spreading init data among several BRAMs is not trivial and the
combining of addresses and outputs. So maybe you should spill
your requirements and see if someone can help?

>I am wondering what use are the
>memory cores if I am better off writing the code myself?  I thought
>the purpose of the cores is not only to help the user by having the
>code pre-written by Xilinx's experts, but also to ensure that the
>design is optimal for fitting into the the FPGA.

That maybe true.

>I used a core adder/
>subtractor and comparator with no problems.

And did the core work better than an inferred adder/subtractor?

>The trick with the memory
>seems to be simulating the memory with the contents loaded. so maybe
>the dual-port memory would work OK.



Thanks,

Charles 

Brad Smallridge wrote:
> 
> I haven't done any elaborate dual port BRAMs because everthing
> I have done fits into a single or maybe two BRAMs.  Yeah, I suppose
> spreading init data among several BRAMs is not trivial and the
> combining of addresses and outputs. So maybe you should spill
> your requirements and see if someone can help?

The whole point of inferring BRAMs is that the synthesis tool figures 
that out for you. You infer a single memory of whatever size you need, 
with whatever init data you need, and the synthesis tool figures out how 
to divide it up among primitives and wire them up, adding any necessary 
miscellaneous logic. And the synthesis tool does this just as well as 
coregen.

On Apr 30, 10:52=A0pm, Duane Clark <u...@domaininvalid.com> wrote:
> Brad Smallridge wrote:
>
> > I haven't done any elaborate dual port BRAMs because everthing
> > I have done fits into a single or maybe two BRAMs. =A0Yeah, I suppose
> > spreading init data among several BRAMs is not trivial and the
> > combining of addresses and outputs. So maybe you should spill
> > your requirements and see if someone can help?
>
> The whole point of inferring BRAMs is that the synthesis tool figures
> that out for you. You infer a single memory of whatever size you need,
> with whatever init data you need, and the synthesis tool figures out how
> to divide it up among primitives and wire them up, adding any necessary
> miscellaneous logic. And the synthesis tool does this just as well as
> coregen.

Well, I have certainly got the message that those who have replied to
this post think that inferred units work as well as the cores (except
for certain applications such as FFTs).  I don't know whether the core
comparator and adder work any better than inferred modules.  I haven't
run any tests, nor do I intend to.  My thinking is that the cores for
those modules are likely to work at least as well as inferred modules
and since they are already incorporated into the design, I will let
well enough alone.  I come to sites like this to learn from others who
have more experience than I in certain areas, and I am learning. I am
not a champion of cores--I don't know enough about them to be either
an advocate or a detractor.

In the case of the dual-port memory, I have no current application for
it -- I just gave that as an example. I have used dual-port memory in
other designs, but these were commercially available units not
internal to an FPGA.

Thanks for all of the replies; even the snippy ones are helpful.

Charles

charles.elias@wpafb.af.mil wrote:

> In the case of the dual-port memory, I have no current application for
> it -- I just gave that as an example. I have used dual-port memory in
> other designs, but these were commercially available units not
> internal to an FPGA.
> 
> Thanks for all of the replies; even the snippy ones are helpful.

This thread has not yet covered your original concern:

 >> My problem is that I don't know how to simulate the ROM.

The big advantage of using hdl templates to
infer special features is that simulation
is simple. The synthesis code and the
simulation model are the same thing.

       -- Mike Treseler

charles.elias@wpafb.af.mil wrote:
> 
> Thanks for all of the replies; even the snippy ones are helpful.

I apologize if I came off as snippy. Tone is hard to convey in postings, 
and I'll definitely try to work on that.