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)

Reply to
sebastian
Loading thread data ...

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
Reply to
rickman

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

Reply to
Subroto Datta

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

formatting link

Reply to
Antti Lukats

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

Reply to
sebastian

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.

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?

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
Reply to
rickman

Hi Sebastian,

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

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

On average across a suite of 97 designs, we find that Stratix requires 9% fewer logic elements than does Virtex-II Pro. See

formatting link
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.

Reply to
Paul Leventis (at home)

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.

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

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.

Reply to
sebastian

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.

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
Reply to
rickman

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

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

Reply to
glen herrmannsfeldt

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:

--

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
Reply to
rickman

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
Reply to
rickman

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.

Reply to
Subroto Datta

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
Reply to
rickman

Hi Rick,

We hear you and are working on specifying the initialization file within the HDL. It will be available in one of the 2005 releases.

Hope this helps,

Subroto Datta Altera Corp.

Reply to
Subroto Datta

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.