Ray Mitchell wrote:

At 06:14 PM 1/14/2004 -0600, you wrote:

Ray Mitchell wrote:


In the past I've developed my Xilinx FPGAs by creating a schematic in Protel 99SE, generating a netlist in Xilinx XNF 5.0 format, then compiling the XNFs using the Xilinx 3.1i application. To be compatible with the newer Xilinx devices, such as the Coolrunner II series, I have acquired their 6.1i application. However, 6.1i no longer supports XNF files. So my question is how to create something using 99SE that Xilinx 6.1i can handle. I've tried creating the Protel netlist in both VHDL and EDIF 2.0 format but either I'm doing something wrong or they are not compatible with Xilinx 6.1i. Does Protel DSP support this better? All suggestions are welcome.

I have done this, but it gets a bit messy. I'm not sure my method is actually any improvement.
The only thing I found that worked was VHDL (architectural) netlists. An annoying bug
is that P99SE Sp6 will only output one VHDL netlist, then you have to restart P99.
If you don't restart P99 each time, it will hang on the netlist step. If you wait half
an hour, it outputs 65536 lines of garbage before the valid netlist.

But, you get a netlist almost ready for Xilinx isp. You have to manually add the library
unisim and the line "use unisim.vcomponents" to get the use of those library components.
You can edit away the _sch extension from all VHDL files made from schematic sheets.
You have to manually remove duplicate component declarations for all of the user-created
components. This only comes up on sheets where you have placed the same user-created library
component multiple times.

The rough edges are that P99 wants input and output pads on the top level page for sim
and ERC, but Xilinx DOESN'T want pads, it assumes any ports on the top page are



Yes, messy but not as messy as trying to use the ISE 6.1i abomination that they're trying to pass off as a schematic tool. From what you describe it seems like it might be reasonable to write a small program to post-process the Protel VHDL files to massage them into a form that ISE wants. If you don't mind, I'd like some clarification on some of the things you mentioned. When I created XNFs for ISE 3.1i Design Manager in the past I had to create a Protel .PRJ sheet that merely contained Sheet Symbols with Sheet Entries. The actual logic was on the .SCH sheets and was tied together by the .PRJ sheet. I always found it annoying Sheet Symbols were needed since they're not needed when doing a schematic for a board layout.

Well, I just set up a VHDL project, and then imported copies of all the .VHD files, and ise
knew what to do with them from there. For each sheet I imported, if the user symbols hadn't
been loaded yet, I got a pink question mark. If the symbols had already been loaded for
another sheet that used them, then you got a green check or whatever, to show that the
symbol has been linked in.

The problem with this is that all sorts of odd things in the Protel schematic pages can cause problems
in the VHDL sheets, and some of them are VERY difficult to find. Also, many of the component
library parts that are standard with Xilinx, are either missing, badly created or have differences
in the port names. Like a 2:1 mux in Protel has the select input as S0, while the Xilinx
unisim library part has the port as just S. So, you have to manually recreate a bunch of the
standard symbols in Protel, and then import those. I don't know, maybe there is another
level of libraries somewhere in the bowels of the inscrutable Xilinx files that defines all
of these, but I couldn'tr find it. These are things like 4-bit counters, 8-bit latches, etc.
The fundamental units are there, the FFs and single-wide muxes.

I'm most confused about your last statement and I'm not sure what you're telling me about pads. I've always used them for my FPGAs in the past for XNFs. Are you saying that now I should just use IBUFs and OBUFs as my entry and exit components and not attach IPADs and OPADs at all? I didn't think Protel itself cared anything about IPADs and OPADs since they are not used in board schematics.

It seems that with VHDL, there is no such thing as a "pad", and the ibufs and obufs are totally
optional for most signals. In special cases where you need a tri-state output only, or are using
a pin for both an input and output, it may be necessary to use the ibuf and obuf parts to clarify
how the pin is to be used.

Am I correct in assuming that you regenerated all of the Protel library components for Xilinx as VHDL files also?

No. I did have to regenerate some parts that were not in the Protel libraries (I used the 4000
library for Spartan parts, for instance), and others that were fouled up enough to need a
complete re-do. The Protel libraries are not completely in sync with the libraries that
Xilinx has in the ise 4.2i software that I'm using. A lot of it is parallel, but there is stuff
that is in the Protel libs that calls up primitive devices that were not in the VHDL libraries
of Protel (at least as far as I could find.) One big example is that unisim.vcomponents
doesn't have ANY BUFE parts. It does have BUFT parts. So, anything that needed a
BUFE, I had to complement the control signal and use a BUFT. This may all be the result
of doing things in VHDL, as the language may force certain things, or the libraries
may be out of sync for device-specific architectural reasons.

One other quirk, that may well be a problem with the Protel VHDL converter has to do with
having signals in a sheet that are used on that sheet as inputs, and also feed to an output
port. This causes an error in the Xilinx synthesize step, as Xilinx wants that port to be
an inout type. My fix was to hack a plain buf in to isolate all nets internal to the sheet
from the output port.

Another quirk is that ALL nets connected to a port must be labeled the same as the port
name. If you leave it off, things don't get connected, the internal net becomes a
signal net_0123 internal to the VHDL module and not driven by any source.
This is clearly a Protel shortcoming.


* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* To post a message: mailto:[EMAIL PROTECTED]
* To leave this list visit:
* http://www.techservinc.com/protelusers/leave.html
* Contact the list manager:
* Forum Guidelines Rules:
* http://www.techservinc.com/protelusers/forumrules.html
* Browse or Search previous postings:
* http://www.mail-archive.com/[EMAIL PROTECTED]
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

Reply via email to