Taking forever to synthesise (XILINX ISE 8.1i)

I am implementing an extremely old logic design (circa 1965!) on a
Xilinx Virtex 4 (XC4VLX25).

For those interested - it is the logic for the computer that flew to
the moon and back! The design is based on approximately 5,000 3-input
NOR gates and not a flip flop in sight! For the circuit diagrams see
website 'http://klabs.org/history/ech/agc_schematics/index.htm'.

I have implemented the timer and scaler modules that divide the input
2.048 MHz clock signal. The logic works beautifully in the ModelSim
environment (after having implemented some delays and initial
conditions for signals that form a bistable latch made from the NOR
gates) but I am having fun and games with synthesising the logic.

My biggest problem is the time that XST takes to synthesise the logic.
ISE just grinds to a halt after reporting the combinatorial loops with
the message:

Optimizing unit <AGC> ...

I have left it for over two hours like this... I still haven't ever
managed to synthesis the complete timer and scaler modules! I have cut
down the scaler module to one or two divider sections and this does
synthesise OK.

I don't really want to change the logic to suite the tool as I am
trying to be as true to the original design as I can be. I have coded
the logic up in a similar manner to the following:

subtype AGCBIT is STD_LOGIC;

-- etc. etc. etc. etc.

constant INI_HI : AGCBIT := '1';
constant INI_LO : AGCBIT := '0';

constant gate_delay : time := 1 ps;

-- etc. etc. etc. etc.

signal \37101\ : AGCBIT := INI_LO;
signal \37102\ : AGCBIT := INI_HI;
signal \37103\ : AGCBIT := INI_LO;
signal \37104\ : AGCBIT := INI_HI;

-- etc. etc. etc. etc.

\37101\ <= not( \37105\ or \37102\ );
\37102\ <= not( \37101\ or CLOCK or \37103\ ) after gate_delay;
\37103\ <= not( \37102\ or CLOCK or \37104\ );
\37104\ <= not( \37103\ or \37106\ ); PHS2 <= \37104\;

-- etc. etc. etc. etc.

Each of the existing logic gate has a 'number' on the original circuit
diagrams (e.g. 37101). I have converted all of these to signals and
entered the logic in VHDL by hand-transcribing from the original
circuit diagrams.

Does anyone have any ideas as to why ISE is taking soooooo long to
optimise the design (apart from trying all possible
combinations/permutations of logic layout) and (more importantly) how
to speed it up?

Any help gratefully received...

daver2 wrote
> I don't really want to change the logic to suite the tool as I am
> trying to be as true to the original design as I can be. I have coded
> the logic up in a similar manner to the following:
...
...
> \37101\ <= not( \37105\ or \37102\ );
> \37102\ <= not( \37101\ or CLOCK or \37103\ ) after gate_delay;
> \37103\ <= not( \37102\ or CLOCK or \37104\ );
> \37104\ <= not( \37103\ or \37106\ ); PHS2 <= \37104\;

Can you write a Perl script to whizz through the code and extract the flops 
and latches?

daver2 wrote:
> I am implementing an extremely old logic design (circa 1965!) on a
> Xilinx Virtex 4 (XC4VLX25).
> 
> For those interested - it is the logic for the computer that flew to
> the moon and back! The design is based on approximately 5,000 3-input
> NOR gates and not a flip flop in sight! For the circuit diagrams see
> website 'http://klabs.org/history/ech/agc_schematics/index.htm'.
> 

Does the design implement flops using NORs with feedback?  If so, that 
could be an issue.  The ISE tools don't like combinational feedback.
-KEvin

Kevin Neilson wrote:
> daver2 wrote:
> > I am implementing an extremely old logic design (circa 1965!) on a
> > Xilinx Virtex 4 (XC4VLX25).
> >
> > For those interested - it is the logic for the computer that flew to
> > the moon and back! The design is based on approximately 5,000 3-input
> > NOR gates and not a flip flop in sight! For the circuit diagrams see
> > website 'http://klabs.org/history/ech/agc_schematics/index.htm'.
> >
>
> Does the design implement flops using NORs with feedback?  If so, that
> could be an issue.  The ISE tools don't like combinational feedback.
> -KEvin

Kevin,

Yes, the design does use NOR gates with feedback to create the
flipflops - and yes I am getting warnings from XST about combinatorial
loops. I am (as we speak) going through the network that the
synthesiser has generated for the 4LUT's to see that what it has
generated is what should have been generated!

The original logic would have potentially suffered from unstable
oscillation and glitches if it had not been designed properly in the
first place so it is my belief that ISE is complaining about something
that won't occur in reality.

Dave

Tim wrote:
> daver2 wrote
> > I don't really want to change the logic to suite the tool as I am
> > trying to be as true to the original design as I can be. I have coded
> > the logic up in a similar manner to the following:
> ...
> ...
> > \37101\ <= not( \37105\ or \37102\ );
> > \37102\ <= not( \37101\ or CLOCK or \37103\ ) after gate_delay;
> > \37103\ <= not( \37102\ or CLOCK or \37104\ );
> > \37104\ <= not( \37103\ or \37106\ ); PHS2 <= \37104\;
>
> Can you write a Perl script to whizz through the code and extract the flops
> and latches?

Tim,

Thanks for the idea Tim. Let me think about that one for a while...

Dave

daver2 wrote:
> Kevin Neilson wrote:
> 
>>daver2 wrote:
>>
>>>I am implementing an extremely old logic design (circa 1965!) on a
>>>Xilinx Virtex 4 (XC4VLX25).
>>>
>>>For those interested - it is the logic for the computer that flew to
>>>the moon and back! The design is based on approximately 5,000 3-input
>>>NOR gates and not a flip flop in sight! For the circuit diagrams see
>>>website 'http://klabs.org/history/ech/agc_schematics/index.htm'.
>>>
>>
>>Does the design implement flops using NORs with feedback?  If so, that
>>could be an issue.  The ISE tools don't like combinational feedback.
>>-KEvin
> 
> 
> Kevin,
> 
> Yes, the design does use NOR gates with feedback to create the
> flipflops - and yes I am getting warnings from XST about combinatorial
> loops. I am (as we speak) going through the network that the
> synthesiser has generated for the 4LUT's to see that what it has
> generated is what should have been generated!
> 
> The original logic would have potentially suffered from unstable
> oscillation and glitches if it had not been designed properly in the
> first place so it is my belief that ISE is complaining about something
> that won't occur in reality.
> 
> Dave
> 


Unfortunately, the original design depends on redundant cover terms and 
circuit delays to guarantee that proper operation.  FPGAs are not 
intended for what amounts to asynchronous logic.  Unlike the original 
design, the delays in the interconnect between the gates in the FPGA are 
significant and need to be considered when doing the design.  Unless you 
intend to had route this, you can't guarantee the delays are properly 
balanced to avoid the hazards the original design avoids.  Also, the 
FPGA tools generally do not leave the cover terms necessary to avoid 
glitch hazards in an async design without you explicitly forcing the 
tools to keep the terms.  You would be more likely to achieve success by 
  converting the flip-flops in the original design to FPGA flip-flops, 
something that kind of goes against your intent I suppose.

The ISE complaints are quite valid, and unless you take the pains to 
make sure the design is not reduced by the tools and that the routing 
delays are properly balanced and considered, you will likely not wind up 
with a working design.

In order to get the tools to keep from optimizing out stuff you need in 
there for hazard covers, you will at least need to put syn_keeps or the 
equivalent on each node in the original design, and may have to go as 
far as explicitly instantiating xilinx primitives with the proper init 
strings for each gate.  Instantiation might in the long run be the 
easier way to go, as it gives you a bit more control when it comes to 
placement.

Good luck.

The original design was verified for the timing and behavior
(specifically glitch-free behavior) of hard NOR gates within the gate
array fabric that it was implemented on.

Change the NORs to luts, and change the timing (radically), and you no
longer have a reliable design, no matter how reliable the original was.

Combinatorial feedback loops in FPGAs are bad medicine.

If the original design had macros for every flop built out of NORs, you
could replace those macros with rtl code for conventional flops, and
then ISE would be happy, and so would you/your design. Otherwise your
going to have to be able to recognize the pattern of feedback in NOR
networks that makes a flop, then cut that out and replace it with a
conventional flop.

Andy


daver2 wrote:
> Kevin Neilson wrote:
> > daver2 wrote:
> > > I am implementing an extremely old logic design (circa 1965!) on a
> > > Xilinx Virtex 4 (XC4VLX25).
> > >
> > > For those interested - it is the logic for the computer that flew to
> > > the moon and back! The design is based on approximately 5,000 3-input
> > > NOR gates and not a flip flop in sight! For the circuit diagrams see
> > > website 'http://klabs.org/history/ech/agc_schematics/index.htm'.
> > >
> >
> > Does the design implement flops using NORs with feedback?  If so, that
> > could be an issue.  The ISE tools don't like combinational feedback.
> > -KEvin
>
> Kevin,
>
> Yes, the design does use NOR gates with feedback to create the
> flipflops - and yes I am getting warnings from XST about combinatorial
> loops. I am (as we speak) going through the network that the
> synthesiser has generated for the 4LUT's to see that what it has
> generated is what should have been generated!
>
> The original logic would have potentially suffered from unstable
> oscillation and glitches if it had not been designed properly in the
> first place so it is my belief that ISE is complaining about something
> that won't occur in reality.
> 
> Dave

"daver2" <davidroberts@siemens.com> wrote in message 
news:1162220709.470867.305120@e64g2000cwd.googlegroups.com...
>I am implementing an extremely old logic design (circa 1965!) on a
> Xilinx Virtex 4 (XC4VLX25).
>
> For those interested - it is the logic for the computer that flew to
> the moon and back! The design is based on approximately 5,000 3-input
> NOR gates and not a flip flop in sight!

Aw dang, I was going to do that.
Well, it was on my 'to do' list for when I have time.
But I'm working 12 hour days and hope to do so for quite a while, so I don't 
have much time left for hobby stuff.

I did get round to having a look at it though
(see http://www.howell1964.freeserve.co.uk/logic/apollo_clone.htm)
and I recall thinking that it might not be a good idea to directly translate 
the circuit into loads of NOR gates. I was going to try writing a higher 
level VHDL description to do a functional equivalent that was better suited 
to current FPGA technology.

Good luck with the project - I look forward to fitting it into my own FPGA 
chip.

Ray Andraka wrote:
> daver2 wrote:
> > Kevin Neilson wrote:
> >
> >>daver2 wrote:
> >>
> >>>I am implementing an extremely old logic design (circa 1965!) on a
> >>>Xilinx Virtex 4 (XC4VLX25).
> >>>
> >>>For those interested - it is the logic for the computer that flew to
> >>>the moon and back! The design is based on approximately 5,000 3-input
> >>>NOR gates and not a flip flop in sight! For the circuit diagrams see
> >>>website 'http://klabs.org/history/ech/agc_schematics/index.htm'.
> >>>
> >>
> >>Does the design implement flops using NORs with feedback?  If so, that
> >>could be an issue.  The ISE tools don't like combinational feedback.
> >>-KEvin
> >
> >
> > Kevin,
> >
> > Yes, the design does use NOR gates with feedback to create the
> > flipflops - and yes I am getting warnings from XST about combinatorial
> > loops. I am (as we speak) going through the network that the
> > synthesiser has generated for the 4LUT's to see that what it has
> > generated is what should have been generated!
> >
> > The original logic would have potentially suffered from unstable
> > oscillation and glitches if it had not been designed properly in the
> > first place so it is my belief that ISE is complaining about something
> > that won't occur in reality.
> >
> > Dave
> >
>
>
> Unfortunately, the original design depends on redundant cover terms and
> circuit delays to guarantee that proper operation.  FPGAs are not
> intended for what amounts to asynchronous logic.  Unlike the original
> design, the delays in the interconnect between the gates in the FPGA are
> significant and need to be considered when doing the design.  Unless you
> intend to had route this, you can't guarantee the delays are properly
> balanced to avoid the hazards the original design avoids.  Also, the
> FPGA tools generally do not leave the cover terms necessary to avoid
> glitch hazards in an async design without you explicitly forcing the
> tools to keep the terms.  You would be more likely to achieve success by
>   converting the flip-flops in the original design to FPGA flip-flops,
> something that kind of goes against your intent I suppose.
>
> The ISE complaints are quite valid, and unless you take the pains to
> make sure the design is not reduced by the tools and that the routing
> delays are properly balanced and considered, you will likely not wind up
> with a working design.
>
> In order to get the tools to keep from optimizing out stuff you need in
> there for hazard covers, you will at least need to put syn_keeps or the
> equivalent on each node in the original design, and may have to go as
> far as explicitly instantiating xilinx primitives with the proper init
> strings for each gate.  Instantiation might in the long run be the
> easier way to go, as it gives you a bit more control when it comes to
> placement.
>
> Good luck.

Thanks Ray,

You are confirming what I feared. I decided to implement a small part
of the project to see what problems I would fall into before converting
everything and then sorting out the resulting mess! Whilst the ModelSim
solution works this is no real indication that it will in reality! I
will have a bit more of a think in the meantime...

Thanks for your time and help.

Dave

Andy wrote:
> The original design was verified for the timing and behavior
> (specifically glitch-free behavior) of hard NOR gates within the gate
> array fabric that it was implemented on.
>
> Change the NORs to luts, and change the timing (radically), and you no
> longer have a reliable design, no matter how reliable the original was.
>
> Combinatorial feedback loops in FPGAs are bad medicine.
>
> If the original design had macros for every flop built out of NORs, you
> could replace those macros with rtl code for conventional flops, and
> then ISE would be happy, and so would you/your design. Otherwise your
> going to have to be able to recognize the pattern of feedback in NOR
> networks that makes a flop, then cut that out and replace it with a
> conventional flop.
>
> Andy
>
>
> daver2 wrote:
> > Kevin Neilson wrote:
> > > daver2 wrote:
> > > > I am implementing an extremely old logic design (circa 1965!) on a
> > > > Xilinx Virtex 4 (XC4VLX25).
> > > >
> > > > For those interested - it is the logic for the computer that flew to
> > > > the moon and back! The design is based on approximately 5,000 3-input
> > > > NOR gates and not a flip flop in sight! For the circuit diagrams see
> > > > website 'http://klabs.org/history/ech/agc_schematics/index.htm'.
> > > >
> > >
> > > Does the design implement flops using NORs with feedback?  If so, that
> > > could be an issue.  The ISE tools don't like combinational feedback.
> > > -KEvin
> >
> > Kevin,
> >
> > Yes, the design does use NOR gates with feedback to create the
> > flipflops - and yes I am getting warnings from XST about combinatorial
> > loops. I am (as we speak) going through the network that the
> > synthesiser has generated for the 4LUT's to see that what it has
> > generated is what should have been generated!
> >
> > The original logic would have potentially suffered from unstable
> > oscillation and glitches if it had not been designed properly in the
> > first place so it is my belief that ISE is complaining about something
> > that won't occur in reality.
> >
> > Dave

Andy,

Thanks for the tip. Of course, you are correct. My theory was to try a
small bit of the logic to find out what the problems were initially and
then to decide if they were solvable. I have learned a lot about the
original logic by studying the ModelSim runs and I think this excercise
is useful - however you may be correct in getting a workable solution
in silicon.

I shall have a little more thinking and experimentation time before I
give up though and then I shall explore some other avenues.

Thanks for your time in reading my post and replying.

Dave