Synthesis size of Circuits?

Hi, I am a student, without much experience of synthesis. My task was to make some modifications (i.e. insert faults) to the ISCAS benchmark circuits and synthesize them to the FPGAs. I read the circuits using the ISCAS benchmark format - made my changes to the circuit structure and dumped out the VHDL.

My problem is that I cannot get this to synthesize with the standard tools for medium sized circuits i.e. they either run out of memory or they complain that my file is too long or something like that. (Circuits with a few hundred gates work fine - so I dont have a problem with syntax or somehting like that.) I wonder if there is a way out for me.

Initially I dumped each of the faults that I had inserted as separate entities. This made the number of entities that I used too large e.g. for a 10K gate circuit - I had a little more than 10K entities. Note that I did not increase the number of gates - but I just added additional Muxs (multiplexers) and some control lines. I was surprised that this modified circuit would not synthesize. XST (8.2) complained that it ran out of 4 GB of memory, Synopsis complained that the number of lines in my file were more than 1 million - this made me move some entities to separate files - but finally it also crashed.

Somebody then came along and told me that the synthesis tools require a lot of overhead for the entities. So I decided now to just put everything in one big global entity. Here also XST crashes after hitting the 4GB memory error.

A code sample showing one of my gates (with the associated Mux) is

Nand_2_0_0 : forg_node_16_Cell_0

Reply to
olson_ord
Loading thread data ...

If it turns up that your source code is too complicated to synthesize with your current machine you could perhaps divide your design into several files and compile each file separately. One keyword to search for is incremental synthesis.

/Andreas

Reply to
Andreas Ehliar

olson snipped-for-privacy@yahoo.it schrieb:

[..]

The number of gates _will_ increase, if you add gates! I guess you even didn't care about signal buffering. A signal driving

10k gates needs roughly 1000 gates for signal buffering.
Reply to
Thomas Stanka

Dear Andreas, Thanks for your reply to this post. I took the time to have a look at incremental synthesis (for XST) and it seems to be useful only if you have changed part of your design and want to save resynthesis time. As far as XST is concerned I am not so much concerned about the run time - than the Memory consumption. (I only have access to the 32 bit version so XST can use only 4GB of memory.) XST runs out of memory and then crashes - that's my problem. Regards, O.O.

Reply to
olson_ord

I found this comment useful - because I could not get this information in the manuals or other tutorials. (I never imagined so many gates would be required for buffering.)

Thanks for this code. I am dumping the VHDL using C++ - so actually I did not mind a few more output lines when I wrote it. Now that I am running into problems, I would have to go back and change it.

I did not understand this. Why would long combinatorial paths kill my tool (i.e. why is it difficult to synthesize - Routing Memory??) Do you (or anyone else reading this) have any suggestions for decreasing the combinatorial path length?

Yes you guessed right that this is related to fault testing. But I am not concerned about the concept (because it was my advisors) - my job is to try to implement it - whether it works or not.

Thanks again for your help. O.O.

Reply to
olson_ord

Hi,

olson snipped-for-privacy@yahoo.it schrieb:

This number depends on the maximum fanout allowed for buffers of your library. If your technology allows a max fanout of 10 per Gate, you need more than 1k buffers to have a overall fanout of 10k for a signal. If your technology allows a maximum fanout of 32, you need only 324 buffer. But you have typically massive timing problems when your actual fanout reaches max. fanout. In some FPGAs you need to use special routing resources (clk-nets) for a large fanout. those nets are typically strong limited in number.

The task of synthesis is NP, meaning your effort rises exponential with the number of involved variables. I would consider each gate-input as variable for synthesis (with redundant inputs hopefully merged) . Second problem would be place&routing to fit timing. The more gates drive an logic cone, the more inputs have to be considered to place and route this logic cone. bye Thomas

Reply to
Thomas Stanka

It is also possible to synthesize parts of your design and then include that part as presynthesized logic. In this way, XST synthesizes parts of your large design separately. However I don't know how to do that in ISE as I haven't tried to do that myself. The makefiles in the EDK seems to work in that way as well.

/Andreas

Reply to
Andreas Ehliar

Hi Andreas, I did not have the internet over the weekend - so I am late in looking at your posts. I looked over the documentation on ISE, but I did not figure out how to include pre-synthesized logic. If anyone else has some ideas that might be helpful. I have seen the *.edn files included into the synthesis of some other designs. But I am not sure how they help i.e. if they are a netlist that is post synthesized or pre-synthesized. Also I am not sure how to generate *.edn files. Thanks for the pointer anyway. Regards, O.O.

Reply to
olson_ord

One thing I would like to clarify is that even though I am using 10K gates in my design - a single signal does not drive all of them. In fact I wonder if there are more than a few signals that actually drive more than 10 gates. So I don't think that there is a need for signal buffering.

Does this mean that these commercial tools have problems synthesizing medium size combinational circuits? Would it help the synthesis if I would somehow insert flipflops at an intermediate location in the logic? (This is near impossible for me - but right now the synthesis using commercial tools does not work at all.)

Thanks a lot. O.O.

Reply to
olson_ord

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.