Taking forever to synthesise (XILINX ISE 8.1i)

daver2 wrote

... ...

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,

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

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:

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

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.

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,

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

Hi Kryten,

Thanks for the reply. I found your website previously and have it bookmarked as a reference!

Well, there is nothing stopping two (or more) people from implementing the AGC in VHDL!!!

I also have an outline design for the AGC in a more higher-level VHDL structure. My initial thoughts were that a gate-level implementation should be less prone to my misinterpretation of the AGC functionality, as the english description of the functionality of the logic doesn't exist any longer (or at least I haven't a copy). Whilst the various software simulations and John Pultorak's excellent Block I construction gives some major insights into the operation of the instruction set etc. etc. they would appear to be limited in more esoteric areas like RUPTs etc.

I have implemented the DSKY in 'proper' VHDL and this seems to work beautifully. I still have some issues with regard to the actual interface to the AGC though that I plan to resolve when I start to look at the AGC I/O sub-system. I have just taken delivery of my extremely pretty, large, green, 7-segment LED displays - so the next few weeks will be taken up constructing a DSKY rather than bashing VHDL...

I shall 'pause for thought' and this point and try out some of the synthesised logic on a real FPGA and see what happens. If this doesn't work, I may have to resort to a functional emulation - but using the gate-level version with ModelSim plus the existing software emulators to give some degree of verification.

Thanks for your time in replying.

Dave

Taking into account what has been said already, have you considered implementing the design with a software emulator? You said it runs fine in ModelSim, and any vanilla embedded CPU should be able to do so in realtime.

There are a couple of software emulators already out there in the 'wild' (one of the best being at

This software emulation is used by the orbiter flight simulator (see and screenshot at for the navigation computer. During the implementation of the orbiter (and other) projects, things are found out not to be working as expected, and this is usually traced down to a simplification or misunderstanding of the way the computer actually works.

I actually tried to do exactly what you propose with some of the microcontrollers available (I think I had a play with a large AVR in the past). One of the problems was that the fixed 'core rope' memory is

36,864 words in size (73728 bytes) and this usually breaks the embedded C compilers which have a limit of 64KB (or at least the free ones that I have downloaded). OK, I could split the fixed code up into chunks and knit it together etc. etc. but this is hassle. I work with software every day and an opportunity to get back and do a bit of hardware/VHDL for a change is too tempting!

I am attempting to develop as 'true-to-life as possible' simulation of the AGC whilst, at the same time, being able to run at a significantly faster-than-real-time to enable orbiter missions to be undertaken in hours rather than days.

One other possibility would be to construct my own run-time system so that I could enter the NOR-gate logic as it appears in the AGC schematics, compile it and emulate it within a framework. This would give me the realism I desired but may not achieve the speed improvement for the orbiter project. The emulation approach would also introduce a 'serialisation' of the logic rather than the true parallelism of a native hardware design. If I arrange for the emulation framework to be implemented within a FPGA I could achieve my goal of realism but I suspect the speed would still probably suffer - perhaps not as much as a purely software/embedded processor solution though?

Oh well, if things were as simple as sending men to the moon everyone would be doing it...

Sorry to ramble on a bit in this post but I have been thinking about the excellent replies I am receiving and the ideas that are buzzing around my head need to be captured somewhere!

Thanks to everyone for your time in replying to my question.

Dave

What about simulating the original NOR gates with a NOR gate followed by a small synchronous delay/filter (maybe a 2 bit counter dead ended at 0 and

3) to swamp out the routing delays. Then the delay tolerances could be as good as the original NOR gates.

Peter Wallace

Alternatively, to (a) remain true to the original design (and prevent ISE from optimising out "redundant" terms etc) AND (b) to overcome synthesis speed issues, consider a hierarchical implementation.

If you can identify a latch or flop made from NOR gates, implement ONLY that latch from NOR operations as a complete design unit in ISE. It shouldn't take long to synthesise a few gates! The result will be a .ngo file representing that component.

Then instantiate that latch or flop - not the NOR gates - in the next readily identifiable level of the design (e.g. a counter) as a "black box" component. You can force it to be a black box with "black box" attributes; alternatively you can simply make the counter a separate project, and omit the design file for the flop. Simply tell the place and route tools where to look for pre-compiled cores, or copy the flop's .ngo file into the counter's project directory.

When synthesising the counter, ISE cannot then try to optimise down into the flop. This (a) massively reduces synth time since the counter is composed largely of simple black boxes, and (b) _should_ preserve the design intent (including gate delays) intact. Routing delays may still be a problem, though you can floorplan your components to reduce this.

And so on up to the top level, if you can see the design structure in terms of black boxes.

A side benefit is, if you decide to give in and use conventional flops, you can substitute an .ngo file containing that flop for the NOR one.

- Brian

In my case, lack of time is stopping me doing much at all...

It's an interesting project but it isn't as impressive or fun to the layman as something that plays Pong or MP3 files.

Any ideas for other programs it could run?

Maybe a simple musical program to play "Ground Control to Major Tom" for instance?

Cool. I've not explored all the abilities of VHDL yet, just enough to synthesise the logic I want for my projects.

I recall the display took up a large percentage of the power.

I'd want to use small, high efficiency LEDs to minimise power.

I'm sure they could be smaller than the original machine and yet be just as practical.