Forums

Migrating Spartan2 design (xnf)

Started by Nico Coesel March 2, 2012
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=.)
--------------------------------------------------------------
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
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=.) --------------------------------------------------------------
On Mar 2, 5:09=A0pm, 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? =A0I believe tha=
t
> > 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. =A0In 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). =A0Then 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=3D.) > --------------------------------------------------------------
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
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