Subroto Datta wrote:
> 
> rickman <spamgoeshere4@yahoo.com> wrote in message news:<41583A6C.827D2CFF@yahoo.com>...
> > Isn't this a rather clumsy piece of code?  Isn't there a way to use a
> > few simple lines to infer a block ram (that is not written) and then
> > init the contents separately?  It is not often that I want to hard code
> > my ROM contents.
> >
> >
> >
> 
> I was adhering to the customer's code sample when formulating the
> original reply reply. To achieve what you want you can do the
> following:
> 
> The easiest way to make a ROM that can be initialized separately is to
> instantiate an Altera megafunction.  You can use the MegaWizard
> Plug-In Manager (Tools menu) to configure the block and look at a
> specific initialization file and then you can change the contents of
> the file later on.
> 
> The LPM_ROM is a part of the LPM standard and and shoud be supported
> by most FPGA CAD tools.

Thanks for the reply.  I guess I missed it until now.  

"Easiest" is a subjective term.  I avoid all instantiations if I can to
make the code more portable.  Is there a way to use an initialization
file with inferred RAM or ROM?  In my case it actually will be RAM since
the processor can update its own program.  

-- 

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX

rickman <spamgoeshere4@yahoo.com> wrote in message news:<41583A6C.827D2CFF@yahoo.com>...
> Isn't this a rather clumsy piece of code?  Isn't there a way to use a
> few simple lines to infer a block ram (that is not written) and then
> init the contents separately?  It is not often that I want to hard code
> my ROM contents.  
> 
> 
>

I was adhering to the customer's code sample when formulating the
original reply reply. To achieve what you want you can do the
following:

The easiest way to make a ROM that can be initialized separately is to
instantiate an Altera megafunction.  You can use the MegaWizard
Plug-In Manager (Tools menu) to configure the block and look at a
specific initialization file and then you can change the contents of
the file later on.

The LPM_ROM is a part of the LPM standard and and shoud be supported
by most FPGA CAD tools.


- Subroto Datta
Altera Corp.

Isn't this a rather clumsy piece of code?  Isn't there a way to use a
few simple lines to infer a block ram (that is not written) and then
init the contents separately?  It is not often that I want to hard code
my ROM contents.  


Subroto Datta wrote:
> 
> Hello Sebastian,
>   You have a pointed out an error in the handbook which will be
> corrected. The piece of code that will infer a ROM in Quartus (used
> 4.1) is shown below:
> 
> LIBRARY ieee;
> USE ieee.std_logic_1164.ALL;
> ENTITY sync_rom IS
> PORT (
> clock: IN STD-LOGIC;
> address: IN STD_LOGIC_VECTOR(7 downto 0);
> data_out: OUT STD_LOGIC_VECTOR(5 downto 0)
> );
> END sync_rom;
> 
> 
> 
> ARCHITECTURE rtl OF sync_rom IS
> BEGIN
> PROCESS (clock)
> BEGIN
> IF rising_edge(clock) THEN
> CASE address IS
> WHEN "00000000" => data_out <= "101111";
> WHEN "00000001" => data_out <= "110110";
> ...
> 
> WHEN "11111110" => data_out <= "000001";
> WHEN "11111111" => data_out <= "101010";
> WHEN OTHERS => data_out <= "101111";
> END CASE;
> END IF;
> END PROCESS;
> 
> END rtl;
> 
> 
> Hope this helps,
> 
> Subroto Datta
> Altera Corp.

-- 

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX

glen herrmannsfeldt wrote:
> 
> rickman wrote:
> (snip about ROMs in FPGA's)
> 
> > I'm not sure I follow this, but in an FPGA a ROM is nothing but a RAM
> > that is never written.  You can infer them the same way as a RAM, just
> > don't use a write signal and input data.  They can be initialized in
> > different ways.  I find it most useful to init the data *after*
> > compliation and routing of the design.  Both Xilinx and Altera support
> > this.
> 
> Quartus II for me, if I have a design with RAM in it, such
> as a FIFO has a warning that I haven't provided initialization
> data for the RAM.   I believe it takes the old intel hex format,
> and maybe others.
> 
> Are you using the BRAM's or LUT's for your ROM?


I am talking about block rams.  

-- 

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX

rickman wrote:
(snip about ROMs in FPGA's)

> I'm not sure I follow this, but in an FPGA a ROM is nothing but a RAM
> that is never written.  You can infer them the same way as a RAM, just
> don't use a write signal and input data.  They can be initialized in
> different ways.  I find it most useful to init the data *after*
> compliation and routing of the design.  Both Xilinx and Altera support
> this. 

Quartus II for me, if I have a design with RAM in it, such
as a FIFO has a warning that I haven't provided initialization
data for the RAM.   I believe it takes the old intel hex format,
and maybe others.

Are you using the BRAM's or LUT's for your ROM?

-- glen

sebastian wrote:
> 
> rickman <spamgoeshere4@yahoo.com> wrote in message news:<414F9E50.8B315F7B@yahoo.com>...
> > There's your problem.  Your designs should be done in a modular fashion
> > so that there are common files for memory componets.  I have a single
> > file for memory blocks with the required code to infer or instantiate
> > the various memory styles.  I select the chip family and select infer
> > vs. instantiate.  When I need to add something, I only have one file to
> > modify.  Further, additions should not affect any established code, so I
> > don't need to do regression tests.
> >
> 
> well, i was talking about ROMs, and we've plenty of them holding
> microcode and LUTs, etc.
> The thing is that we had that for ROMs (a generic ROM), it is a vhdl
> file that according to a parameter file, will generate the ROM with a
> function. It's the same than a RAM but where a function loads the
> constants, something like:
> 
> constant tRAM :  MyROM := InitRAM(parameterfile);
> 
> To infer ROMs in the way Altera we'd need to create a separate module
> for each instantiation of our generic ROM cause Altera uses a "case"
> statement to infer a ROM, and there's no way (well, maybe a generate??
> but i just thought that while writing, i'd need to think thru) to make
> them "generic", we'd need a script to generate them.

I'm not sure I follow this, but in an FPGA a ROM is nothing but a RAM
that is never written.  You can infer them the same way as a RAM, just
don't use a write signal and input data.  They can be initialized in
different ways.  I find it most useful to init the data *after*
compliation and routing of the design.  Both Xilinx and Altera support
this. 


> > I would not expect any gains in LUTs going from Xilinx to Altera.  As
> > you found, often the Xilinx design can use less.  But that itself is not
> > the issue since the cost per LUT is not the same.
> >
> > I am not sure what you mean about Quartus being slower.  Are you
> > referring to the run time to compile a design?
> >
> 
> yes, it is slower, though like i said it meets timing better, so the
> router must be better than ISE 5.2

You have said the same thing as before.  But I assume you mean it takes
longer to run.  Meeting timing is a function of the software as well as
the chip.  So it may be that your design fits an Altera part better.  


-- 

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX

rickman <spamgoeshere4@yahoo.com> wrote in message news:<414F9E50.8B315F7B@yahoo.com>...
> sebastian wrote:
> > 
> > rickman <spamgoeshere4@yahoo.com> wrote in message news:<41488BBA.4B570E72@yahoo.com>...
> > 
> > > When it comes to memory, it can be hard to infer it in a way that is
> > > compatible with multiple hardware platforms.
> > 
> > well i hope some time soon they make it somehow "standard", cause
> > right now altera just lost (again! cause it's the second time in few
> > months i see it happening) against xilinx, cause the boss said it was
> > already too much trouble having generates for ASIC and for FPGA, to
> > have another one for another family we were just evaluating (we'd need
> > to modify lots of files). 
> 
> There's your problem.  Your designs should be done in a modular fashion
> so that there are common files for memory componets.  I have a single
> file for memory blocks with the required code to infer or instantiate
> the various memory styles.  I select the chip family and select infer
> vs. instantiate.  When I need to add something, I only have one file to
> modify.  Further, additions should not affect any established code, so I
> don't need to do regression tests. 
> 

well, i was talking about ROMs, and we've plenty of them holding
microcode and LUTs, etc.
The thing is that we had that for ROMs (a generic ROM), it is a vhdl
file that according to a parameter file, will generate the ROM with a
function. It's the same than a RAM but where a function loads the
constants, something like:

constant tRAM :  MyROM := InitRAM(parameterfile);

To infer ROMs in the way Altera we'd need to create a separate module
for each instantiation of our generic ROM cause Altera uses a "case"
statement to infer a ROM, and there's no way (well, maybe a generate??
but i just thought that while writing, i'd need to think thru) to make
them "generic", we'd need a script to generate them.


> 
> > And also because we werent seeing any gains
> > in LUTs (the same design was using more LUT4 in altera than on
> > xilinx), nor on speed, Quartus II 3.0 was a lot slower than ISE 5.2.
> > Though Quartus was meeting timing with more slack, i guess ISE 6.3 and
> > Quartus 4.0 are even better.
> 
> I would not expect any gains in LUTs going from Xilinx to Altera.  As
> you found, often the Xilinx design can use less.  But that itself is not
> the issue since the cost per LUT is not the same.  
> 
> I am not sure what you mean about Quartus being slower.  Are you
> referring to the run time to compile a design?  
> 

yes, it is slower, though like i said it meets timing better, so the
router must be better than ISE 5.2

> 
> > guys! it's time you start doing "standard" things so that code is
> > portable *without* modifications (provided that FPGA families have the
> > same functionality, dual ported RAM, etc. of course!)
> 
> Many forms of RAM can port between FPGA families.  I suggest that you
> explore the common ground and try to use compatible memory styles. 
> Excluding a vendor based on your coding style keeps you from getting the
> best price from the remaining vendor. 
> 

well, that wasnt my decision :) seems like my boss dont like
"complicated" stuff, so if porting is not almost instantly, and
requires scripts or things out of VHDL itself, he doesnt like it
for example, ISE 5.2 cant create large ROMs from VHDL, so we need to
use CoreGen...we already got ISE 6.something so we dont need it
anymore.

> The design I am working on now uses compatible memory even though the
> Altera ACEX part is targeted.  The only thing I can't do in a Xilinx
> Spartan 3 is the async read of memory.  In the Spartan 3 (and most of
> their other chips) the read requires one clock cycle.  That requires
> changes in other parts of my architecture.  
> 
> -- 
> 
> Rick "rickman" Collins
> 
> rick.collins@XYarius.com
> Ignore the reply address. To email me use the above address with the XY
> removed.
> 
> Arius - A Signal Processing Solutions Company
> Specializing in DSP and FPGA design      URL http://www.arius.com
> 4 King Ave                               301-682-7772 Voice
> Frederick, MD 21701-3110                 301-682-7666 FAX

Hi Sebastian,

> well i hope some time soon they make it somehow "standard", cause
> right now altera just lost (again! cause it's the second time in few
> months i see it happening) against xilinx, cause the boss said it was
> already too much trouble having generates for ASIC and for FPGA, to
> have another one for another family we were just evaluating (we'd need
> to modify lots of files).

I'm sorry to hear of this design loss.  In the future, please contact your
Altera FAE for help converting the design.  Our FAEs have access to tools
that facilitate design conversion by re-targeting Xilinx-specific features
to equivalent structures in Altera devices.  Conversion success rate is
fairly high, especially when the considerable performance and logic density
advantages of Stratix II and Cyclone over the competition is taken into
account.

For the do-it-yourselfers out there, we provide documentation at
http://www.altera.com/products/software/switching/x/qts-x2a_migration.html
on how to switch from using Xilinx-based devices and software to our devices
and Quartus.  AN307 gives detailed descriptions on how to re-target
architecture sepecific features.  And as Rick suggests in another post,
isolating device-specific features in your design at the HDL level is a
useful design technique that eases the process of porting to devices (within
the same company's products, or to other company's products).

> And also because we werent seeing any gains
> in LUTs (the same design was using more LUT4 in altera than on
> xilinx)

On average across a suite of 97 designs, we find that Stratix requires 9%
fewer logic elements than does Virtex-II Pro.  See
http://www.altera.com/literature/wp/wp_stx_logic_efficiency.pdf for details.
You mention "LUT4" and not LEs, so I'm wondering whether you are taking into
account the "register packing" factor.

The Stratix & Cyclone architectures were designed to support LEs where both
the LUT and FF are used, even for unrelated functions.  You must be careful
when comparing logic counts -- in our experience, Quartus does a much better
job than competing tools at packing combinational logic with registers.
This register packing functionality can be tuned to more or less aggressive
modes in Quartus, trading off (to some degree) performance and wiring for
logic density.  By setting "Auto Packed Registers" to "Minimize Area"
results in the tightest packing.  In the default flow, Quartus only begins
to aggressively pack your logic when you start running out of logic
elements.

Also, make sure you compare logic counts after running through Quartus and
ISE -- while 3rd party synthesis tools can provide reasonable estimates, you
don't know the real answer until you run through the back-end CAD tools.

So when comparing logic element counts between two competing products, make
sure you're looking at the final result (half "slices" in Xilinx, LEs in
Startix, ALUTs in Stratix II).  Of course, it's also possible your design
falls into the group (roughly 20% of designs) that experience better
densities on Virtex than Stratix.

Hope to have you as a customer in future!

Paul Leventis
Altera Corp.

sebastian wrote:
> 
> rickman <spamgoeshere4@yahoo.com> wrote in message news:<41488BBA.4B570E72@yahoo.com>...
> 
> > When it comes to memory, it can be hard to infer it in a way that is
> > compatible with multiple hardware platforms.
> 
> well i hope some time soon they make it somehow "standard", cause
> right now altera just lost (again! cause it's the second time in few
> months i see it happening) against xilinx, cause the boss said it was
> already too much trouble having generates for ASIC and for FPGA, to
> have another one for another family we were just evaluating (we'd need
> to modify lots of files). 

There's your problem.  Your designs should be done in a modular fashion
so that there are common files for memory componets.  I have a single
file for memory blocks with the required code to infer or instantiate
the various memory styles.  I select the chip family and select infer
vs. instantiate.  When I need to add something, I only have one file to
modify.  Further, additions should not affect any established code, so I
don't need to do regression tests. 

> And also because we werent seeing any gains
> in LUTs (the same design was using more LUT4 in altera than on
> xilinx), nor on speed, Quartus II 3.0 was a lot slower than ISE 5.2.
> Though Quartus was meeting timing with more slack, i guess ISE 6.3 and
> Quartus 4.0 are even better.

I would not expect any gains in LUTs going from Xilinx to Altera.  As
you found, often the Xilinx design can use less.  But that itself is not
the issue since the cost per LUT is not the same.  

I am not sure what you mean about Quartus being slower.  Are you
referring to the run time to compile a design?  

> guys! it's time you start doing "standard" things so that code is
> portable *without* modifications (provided that FPGA families have the
> same functionality, dual ported RAM, etc. of course!)

Many forms of RAM can port between FPGA families.  I suggest that you
explore the common ground and try to use compatible memory styles. 
Excluding a vendor based on your coding style keeps you from getting the
best price from the remaining vendor. 

The design I am working on now uses compatible memory even though the
Altera ACEX part is targeted.  The only thing I can't do in a Xilinx
Spartan 3 is the async read of memory.  In the Spartan 3 (and most of
their other chips) the read requires one clock cycle.  That requires
changes in other parts of my architecture.  

-- 

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX