1. Home
  2. Field-Programmable Gate Arrays
  3. synplify vqm not able to fit in Quartus

synplify vqm not able to fit in Quartus

Hi,

I am trying to fit this particular design. I run Synplify Pro to map the device. In Synplify, with mapping logic to atoms turned on, the design won't fit so I disable mapping logic to atoms and can get the design to fit (63 % of device) onto the device....see log file from synplify below.

However, when I try to place and route the device in Quartus III, it cannot fit. Quartus uses the same project directory as Synplify so it has access to all constraints and tcl files. Can anybody shed any light on this subject. I have used Synplify in conjunction with Quartus before and the resource useage results from both are nearly always about the same. Why the large discrepency ?

Do I manually need to read in some tcl files or have I forgotten to switch on a particular option in Quartus ?

As always, thanks for any help Bob

Found clock clk with period 33.3333ns

--------------------------------------- Resource Usage Report

Final cell packing will be performed by Max+plus II. Please select a Logic synthesis style of "FAST" in Max+plus II. The following resource values are estimates.

Design view:work.comms(comms_architecture) Selecting part ep20k1000efc33-1

Logic resources: 24440 ATOMs of 38400 (63%) Number of Nets: 190215 Number of Inputs: 1298480 Register bits: 14312 (4094 using enable) Latch bits: 8106 ESBs: 0 (0% of 160) I/O cells: 0

Details: AND2: 8298 INV1: 3879 MUX1: 5834 SYNLPM_LAT1: 16356 S_DFF: 10218 S_DFFE: 4113 XOR2: 291 apex20k_lcell: 77185 apex20k_lcell_ff: 19 false: 7 inv: 9189 true: 7

Number of Inputs on ATOMs: 1298480 Number of Nets: 190215

Writing .vqm output for Quartus Writing Cross reference file for Quartus to c:\comms_vhdl\rev_1\comms.xrf Mapper successful! Process took 7284.92 seconds realtime, 7284.92 seconds cputime

Reply to
Bob
Loading thread data ...

Bob, I assume the first experiment was run with Quartus II 2.2 (the one where it fit without atoms), and the second one was in Quartus II 3.0. As a rule of thumb using the atom (vqm) netlist should give fairly close results in the two versions of Quartus, assuming you are optimizing for area (lcell count) or speed in both cases inside Quartus.

You may want to run one more experiment. Use the vqm netlist, and in Quartus II 3.0

  1. Set WYSIWYG Primitive resynthesis (aka atom resynthesis) to on. You can do this from the Assignments->Settings->Compiler Settings->Netlist Optimizations dialog. This will make Quartus take the vqm netlist, convert it to a gate level netlist and synthesize it further.

  1. Next set the Optimization Technique to Area. You can do this from the Assignments->Settings->Default Logic Option Settings->Optimization Technique - APEX20K/APEX20K... to Area.

  2. Set Register Packing to off. You can do this from the Assignments->Settings->Default Logic Option Settings->Auto Packed Register Settings list box. Register Packing can sometimes hurt fiting in the APEX architectures.

4.Compile this design with Quartus II 3.0 and check the results.

If this works turn off the setting in Step 1 and follow recompile the design.

- Subroto Datta Altera Corp.

Reply to
Subroto Datta

Hi Subroto,

Thank you for replying.

I did what you said, but it made very little difference..ie...reduced LE count by 35 (now 111235 LE's)....still miles over the actual size of the device.

This is a massive difference, between what Synplify Pro 6.1.3 says and Quartus II 3.0

I re-synthesized the design again in Synplify and got the same result as before so there is definitely some problem in the flow between the two tools. It certainly looks like I'm back to the drawing board design wise.

If you can think of anything else, I would be very grateful.

Bob

Reply to
Bob

Maybe you can eliminate the flow between the tools. Try bypassing Synplify and process your source files directly with Quartus synthesis.

-- Mike Treseler

Reply to
Mike Treseler

Synplify is suppose to be a better tool.. It should be at the price. Have you tried using the Synplify EDF output file as the quartus source file ?

That way you get all the benefit of the synplify work.

Simon

Reply to
Simon Peacock

Simon,

Synplify does not give you the option of a edif output file for Apex devices. If it does, I certainly don't know about it.

Bob

Reply to
Bob

I believe the answer may be that you have too much logic for the device.

When Synplify packs to Atoms, we expect very good area correlation. That?s because we packed all the Atoms into legal configurations. When Synplify does not pack to Atoms, we measure resource usage of individual elements of the Atoms, but we do not estimate Atom usage accurately. Sometime 2 elements that could fit into an empty Atom can not be packed together because it would not be a legal configuration. So, even though I might have a resource report that shows usage of 1 LUT and 1 Register, it could require 2 Atoms instead, instead of 1. Since Synplify did not do the packing, Quartus will determine the legal packing. In your example, when we packed it it did not fit, and when Quartus packed it it did not fit. That makes me think that things are consistent. As the log file says, when Synplify does not do the packing, our area report is just an estimate. Again, that is because it reports individual element usage and does not assess legal packing configurations.

This is only a guess, to be sure we would need to take a look at your example. Please feel free to send the test case to ?support? at synplicity.com and we will have someone try to help fit it into your device, and also to clarify the reason for the difference.

Andrew Dauman Synplicity, Inc.

Bob wrote:

Reply to
Andrew Dauman

Bob,

What is exactly is the no-fit message from Quartus for the two cases (Synplify maps to atoms, and Synplify doesn't map to atoms)?

I suspect that when Synplify does not map to atoms (an unusual flow for the 20K -- I've never seen it used before), it doesn't really know how many logic cells will be used, since it didn't do the mapping. If Quartus is simply saying that your design uses too many logic cells in both of these flows (map to atoms and don't map to atoms), then your design is just too big.

If it is reasonably close to fitting (i.e. you're using 110% or so of the logic cells in the device) then there are options you can turn on in Quartus, like more aggressive register packing, that can compress the design more. If Quartus is saying you need double the number of logic cells in the device, you're probably out of luck.

Vaughn Altera

Reply to
Vaughn Betz

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.