Migrating Spartan2 design (xnf)

[Nico Coesel]

Because the Xilinx Spartan2 is going to be discontinued in the near
future one of my customers asked me to migrate their designs to a
newer Xilinx FPGA. Perhaps Spartan 6 or Artix 7. The problems are:

- these designs where originally created for the 4000 series using
schematic capture (XNF format) then moved to Virtex and finally to
Spartan 2. Newer parts where written in VHDL though.

- The designs contain some async logic (especially the part talking to
an MCU using an addres/data bus) and locally divided clocks.

- I'm worried at some point extra gates where added to increase the
delay. This will break in a much faster FPGA.

- The design contains bi-directional busses in several places.

My approach would be to convert the XNF parts to VHDL (does someone
sell software to do that?) and then check for anomalies due to changes
in the FPGA architecture. This could be a huge task. The XNF parts
represent several years worth of work.

Any suggestions on how to tackle such a project?

--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
nico@nctdevpuntnl (punt=.)
--------------------------------------------------------------

 

[Gabor]

Nico Coesel wrote:

Because the Xilinx Spartan2 is going to be discontinued in the near
future one of my customers asked me to migrate their designs to a
newer Xilinx FPGA. Perhaps Spartan 6 or Artix 7. The problems are:

- these designs where originally created for the 4000 series using
schematic capture (XNF format) then moved to Virtex and finally to
Spartan 2. Newer parts where written in VHDL though.

- The designs contain some async logic (especially the part talking to
an MCU using an addres/data bus) and locally divided clocks.

- I'm worried at some point extra gates where added to increase the
delay. This will break in a much faster FPGA.

- The design contains bi-directional busses in several places.

My approach would be to convert the XNF parts to VHDL (does someone
sell software to do that?) and then check for anomalies due to changes
in the FPGA architecture. This could be a huge task. The XNF parts
represent several years worth of work.

Any suggestions on how to tackle such a project?

What was the schematic capture used for the schematics? I believe that
XNF is just the netlist format derived from the schematics. I had
older projects from this era using both Alliance tools with ViewDraw
schematics, and Foundation tools with Aldec schematics. I know
that at least the ViewDraw tools were capable of outputing a VHDL
structural netlist, perhaps the Aldec tools did, too. If you don't
still have an active copy of the original tools, I believe newer
versions of Mentor tools can still import older Viewdraw schematics,
and Aldec tools can still import the old Xilinx Foundation schematics.
It's up to you whether the tool cost is worth more than the
re-engineering. In the end, if I were doing this, I'd try to
understand what the schematic sections were doing and hand
convert them to a modern HDL (behavioral). Then you'd have a
better chance of being able to maintain the design down the road.

On another note, all of the parts you mentioned were 5V tolerant.
I'm not sure what sort of micro's you're interfacing, but if you still
have 5V logic in the system any newer parts will need level
translators, too.

-- Gabor

 

[Nico Coesel]

Gabor <gabor@szakacs.invalid> wrote:

Nico Coesel wrote:
Because the Xilinx Spartan2 is going to be discontinued in the near
future one of my customers asked me to migrate their designs to a
newer Xilinx FPGA. Perhaps Spartan 6 or Artix 7. The problems are:

- these designs where originally created for the 4000 series using
schematic capture (XNF format) then moved to Virtex and finally to
Spartan 2. Newer parts where written in VHDL though.

- The designs contain some async logic (especially the part talking to
an MCU using an addres/data bus) and locally divided clocks.

- I'm worried at some point extra gates where added to increase the
delay. This will break in a much faster FPGA.

- The design contains bi-directional busses in several places.

My approach would be to convert the XNF parts to VHDL (does someone
sell software to do that?) and then check for anomalies due to changes
in the FPGA architecture. This could be a huge task. The XNF parts
represent several years worth of work.

Any suggestions on how to tackle such a project?


What was the schematic capture used for the schematics? I believe that

Orcad 9.0. That was the last version of Orcad for which the XNF
netlist DLL worked.

It's up to you whether the tool cost is worth more than the
re-engineering. In the end, if I were doing this, I'd try to
understand what the schematic sections were doing and hand
convert them to a modern HDL (behavioral). Then you'd have a
better chance of being able to maintain the design down the road.

True but there is *years* worth of schematics. Some of the stuff is
not trivial either (think signal processing). A few years ago they
called me in to fix a VHDL problem and at that point they had
converted the XNF files into NGC or NGD files in order to use newer
Xilinx tools. I doubt its possible to take an NGC/NGD file to another
FPGA family.

Still, functional verification is going to be a tough job.

On another note, all of the parts you mentioned were 5V tolerant.
I'm not sure what sort of micro's you're interfacing, but if you still
have 5V logic in the system any newer parts will need level
translators, too.

For now I consider that an insignificant problem compared to the FPGA
designs

--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
nico@nctdevpuntnl (punt=.)
--------------------------------------------------------------

 

[Gabor]

On Mar 2, 5:09 pm, n...@puntnl.niks (Nico Coesel) wrote:

Gabor <ga...@szakacs.invalid> wrote:
Nico Coesel wrote:
Because the Xilinx Spartan2 is going to be discontinued in the near
future one of my customers asked me to migrate their designs to a
newer Xilinx FPGA. Perhaps Spartan 6 or Artix 7. The problems are:

- these designs where originally created for the 4000 series using
schematic capture (XNF format) then moved to Virtex and finally to
Spartan 2. Newer parts where written in VHDL though.

- The designs contain some async logic (especially the part talking to
an MCU using an addres/data bus) and locally divided clocks.

- I'm worried at some point extra gates where added to increase the
delay. This will break in a much faster FPGA.

- The design contains bi-directional busses in several places.

My approach would be to convert the XNF parts to VHDL (does someone
sell software to do that?) and then check for anomalies due to changes
in the FPGA architecture. This could be a huge task. The XNF parts
represent several years worth of work.

Any suggestions on how to tackle such a project?

What was the schematic capture used for the schematics?  I believe that

Orcad 9.0. That was the last version of Orcad for which the XNF
netlist DLL worked.

It's up to you whether the tool cost is worth more than the
re-engineering.  In the end, if I were doing this, I'd try to
understand what the schematic sections were doing and hand
convert them to a modern HDL (behavioral).  Then you'd have a
better chance of being able to maintain the design down the road.

True but there is *years* worth of schematics. Some of the stuff is
not trivial either (think signal processing). A few years ago they
called me in to fix a VHDL problem and at that point they had
converted the XNF files into NGC or NGD files in order to use newer
Xilinx tools. I doubt its possible to take an NGC/NGD file to another
FPGA family.

Still, functional verification is going to be a tough job.

On another note, all of the parts you mentioned were 5V tolerant.
I'm not sure what sort of micro's you're interfacing, but if you still
have 5V logic in the system any newer parts will need level
translators, too.

For now I consider that an insignificant problem compared to the FPGA
designs

--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
nico@nctdevpuntnl (punt=.)
--------------------------------------------------------------

I'm sorry, but I generally measure schematics in pages or symbols
rather than time. "Years" of design time does not necessarily mean
that it would take a similar time to copy, translate, or re-design
given
the existing knowledge base. Signal processing in particular very
often represents a number of regular structures like filters for which
you have many more options for implementation now. In fact you
could end up with very inefficient use of newer devices if you don't
rework a lot of the design to use the available DSP functions that
were not available on Spartan 2 or earlier devices. You'll probably
need to re-work the bidirectional buses (I assume you mean
internal?) since newer parts have not internal tri-state drivers.
So in the end there's probably not a real simple method to run
your old project through some tools to come up with a working
design on a new platform.

Regards,
Gabor

 

[glen herrmannsfeldt]

Gabor <gabor@alacron.com> wrote:

(snip)

I'm sorry, but I generally measure schematics in pages or symbols
rather than time. "Years" of design time does not necessarily mean
that it would take a similar time to copy, translate, or re-design
given the existing knowledge base.

It could even take longer, but one would hope not.

Signal processing in particular very often represents a
number of regular structures like filters for which
you have many more options for implementation now. In fact you
could end up with very inefficient use of newer devices if you don't
rework a lot of the design to use the available DSP functions that
were not available on Spartan 2 or earlier devices.

The CLB changed pretty significantly from XC4000 to Spartan,
especially in the carry logic. That may or may not matter to
a specific design.

You'll probably need to re-work the bidirectional buses
(I assume you mean internal?) since newer parts have not
internal tri-state drivers.

As I understand it, the tools will simulate tri-state lines.
Depending on the design, they may do better or worse than
a person would redesigning the same logic.

So in the end there's probably not a real simple method to run
your old project through some tools to come up with a working
design on a new platform.

Even the smallest of the newer families is pretty large, so it
might be that one can throw more logic to the problem for
the same result. Likely, though, that one can get the existing
design to run faster, or otherwise better, adapting to the
new family.

-- glen