Design Entry

[a_montonen]

I'm having big troubles with PACE in ISE 13.2. Here's how to reproduce:

1. Open the jc2_svhd example project

2. Remove the included user constraints file (jc2_top.ucf)

3. Run the Floorplan IO - Pre-Synthesis process, creating a new UCF file

-> The I/O pins listed in PACE have basically no relation to the design.

If you omit step 2 above, PACE instead spits out these error messages:

---

Compiling vhdl file "C:/Users/anders/xilinx/test/jc2_svhd/jc2_top.vhd" inLibrary work.
Entity <FDC_MXILINX_jc2_top> compiled.
Entity <FDC_MXILINX_jc2_top> (Architecture <BEHAVIORAL>) compiled.
Entity <FJKC_MXILINX_jc2_top> compiled.
Entity <FJKC_MXILINX_jc2_top> (Architecture <BEHAVIORAL>) compiled.
Entity <jc2_top> compiled.
Entity <jc2_top> (Architecture <BEHAVIORAL>) compiled.
ERROR:DesignEntry - Could not apply constraint: NET left LOC=G7;

ERROR:DesignEntry - Could not apply constraint: NET right LOC=B2;

ERROR:DesignEntry - Could not apply constraint: NET stop LOC=F2;

ERROR:DesignEntry - Could not apply constraint: NET clk LOC=A7;

ERROR:DesignEntry - Could not apply constraint: NET q<0> LOC=B4;

ERROR:DesignEntry - Could not apply constraint: NET q<1> LOC=C6;

ERROR:DesignEntry - Could not apply constraint: NET q<2> LOC=F6;

ERROR:DesignEntry - Could not apply constraint: NET q<3> LOC=G5;


---

This happens in all designs that use a top-level schematic. Eg. the jc2_vhd example project works as expected.

[howardp]

This is a problem with the way PACE parses the HDL created by SCH2HDL

The following link explains what is happening.

  http://www.xilinx.com/support/answers/17504.htm

The link states that the problem will be fixed in 11.1.

It was scheduled to be fixed but due to resources and product prioritization, it was never completed.

Two possible workarounds (Neither are real elegant):

1) Create the ucf constraints manually

2) Create an HDL wrapper that instantiates the top level schematic; add it to the project and then open pace.

[a_montonen]

Since this is still broken, why is it not listed in the release notes known issues?

[howardp]

Which Known Issues list are you referring to?

I do not believe there is a Known Issues answer record for Pace (or schematic Editor for that matter). ... only individual Answer Records on specific issues.

[a_montonen]

Why not? It would have saved me a lot of time.

[eteam00]

Why not? It would have saved me a lot of time.

I do not speak for Xilinx.  From one engineer to another engineer, you should understand that Xilinx development and support priorites should (and probably do) place HDL (Verilog and VHDL) well before schematic entry.  I accept that as a matter of practical reality.

If you use schematic entry rather than HDL, you are accepting the consequential risks which accompany both

• dependency on more (rather than fewer) software tools and processes
• tools and methodology which enjoy secondary priority for development and maintenance engineering resources

If I were to choose a programming language for a development project, selecting Fortran would be risky for the same reasons, even if Fortran is (otherwise) well-suited to the project.  You may have solid reasons for using schematic entry, but the realities of the choice should not be ignored or dismissed.

-- Bob Elkind

[a_montonen]

It's a matter of providing complete and accurate information. If there are features that are known not to work one shouldn't have to waste time figuring out the cause and a workaround when A) it turns out it's a known issue and B) there is a page in the documentation section that claims to list all the known issues in the software. The fact that there is a schematic involved is completely incidental.

[eteam00]

The fact that there is a schematic involved is completely incidental.

Not to me.  Practical considerations matter.  That's why I use a Windows PC instead of a Mac.  Sometimes in engineering you must make choices between You can be right or You can get your job done.

There are many many times I complain and whine to Xilinx about documentation errors.  On the other hand, there are many more times I simply accept software bugs and documentation errors because I know that it's not worth the time and effort to correct them --  either to me, to Xilinx, or other Xilinx customers.  My time -- and Xilinx' staff effort -- is sometimes (or often) better used and applied elsewhere.

Just my two cents.

-- Bob Elkind