altera quartus II handbook is wrong??

hi,

im supposed to evaluate the same design in both altera and xilinx
devices, the problem is that altera's software seems a bit "unusual"
and doesnt understand code that all others synthetisers i've tried
recognise.

first i was having trouble with RAMs, but i solved that following
quartus II handbook coding guidelines (though i had to change several
files...and i dont like when that happens...specially because i'll
have three versions, one for each fpga family and then another for
asic!!)

now, im having trouble with ROMs, specially because the handbook has
an error...it says

***   "VHDL Synchronous ROM"   ***
.
.
.

architecture ...
begin

  process(clock) <- note this!
  begin
    case address is  <- note this! no if rising_edge!!!
      when "000" => data_out <= "010";
      when others => blah blah;
    end case;
  end process;
end;

now, i've tried both ways, the right one with the "if rising_edge..."
and the wrong one, and still i cant get quartus II to infer a ROM
without using LEs, it always makes the ROM out of LEs!. Could somebody
explain it to me?. Or is it that it just cant implement a ROM in a
RAM?? and it will always use LEs??

thanks a lot in advance

sebastian wrote:
> 
> hi,
> 
> im supposed to evaluate the same design in both altera and xilinx
> devices, the problem is that altera's software seems a bit "unusual"
> and doesnt understand code that all others synthetisers i've tried
> recognise.
> 
> first i was having trouble with RAMs, but i solved that following
> quartus II handbook coding guidelines (though i had to change several
> files...and i dont like when that happens...specially because i'll
> have three versions, one for each fpga family and then another for
> asic!!)

When it comes to memory, it can be hard to infer it in a way that is
compatible with multiple hardware platforms.  I use the GENERATE feature
of VHDL to provide separate memory descriptions depending on the
particular chip I am targeting.  That way the same files are used for
each different target, you just change the flag telling the software
which chip to target.  

-- 

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

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.

"sebastian" <malaka@email.it> wrote in message
news:6aefd6be.0409150556.64bda2f2@posting.google.com...
> hi,
>
> im supposed to evaluate the same design in both altera and xilinx
> devices, the problem is that altera's software seems a bit "unusual"
> and doesnt understand code that all others synthetisers i've tried
> recognise.
>
> first i was having trouble with RAMs, but i solved that following
> quartus II handbook coding guidelines (though i had to change several
> files...and i dont like when that happens...specially because i'll
> have three versions, one for each fpga family and then another for
> asic!!)
>
> now, im having trouble with ROMs, specially because the handbook has
> an error...it says

try different settings, small ROMs are not "auto recognized" if not
instructed todo so.
from some ROM size an ROM will be used below the trigger point logic will be
used.
there is an option to choose the ROM extraction behavior

antti
http://altera.openchip.org

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). 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.

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!)

 I use the GENERATE feature
> of VHDL to provide separate memory descriptions depending on the
> particular chip I am targeting.  That way the same files are used for
> each different target, you just change the flag telling the software
> which chip to target.  
> 
> -- 
> 
> 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

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

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.

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

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 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