Synthesis size of Circuits?
olso...@yahoo.it
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 <= not (input_2_Cell_0 and
node_11_Cell_0);
SEL_node_16_Cell_0(1) <= ctrl_fault_4_Cell_0;
SEL_node_16_Cell_0(2) <= ctrl_fault_5_Cell_0;
MUX_Gate_3_1node_16_Cell_0 : process (SEL_node_16_Cell_0,
insert_faults_Cell_0, forg_node_16_Cell_0, fault_4_node_16_Cell_0,
fault_5_node_16_Cell_0)
begin
if (insert_faults_Cell_0 = '0') then
node_16_Cell_0 <= forg_node_16_Cell_0;
elsif (insert_faults_Cell_0 = '1') then
case SEL_node_16_Cell_0 is
when "01" => node_16_Cell_0 <=
fault_4_node_16_Cell_0;
when "10" => node_16_Cell_0 <=
fault_5_node_16_Cell_0;
when others => node_16_Cell_0 <=
forg_node_16_Cell_0;
end case;
else
node_16_Cell_0 <= forg_node_16_Cell_0;
end if;
end process MUX_Gate_3_1node_16_Cell_0;
(Just imagine that I do this 10K times - including final signal
mapping.)
I hope you can tell me what is the size of the circuits that you guys
synthesize? Am I trying something impossible here? - I thought 10K was
a small size. I would be glad to hear of any ideas you may have on how
to get this to synthesize. I am not so much concerned about the run
time - but that it works without crashing.
Thanks a lot.
O.O.
Andreas Ehliar
> I hope you can tell me what is the size of the circuits that you guys
> synthesize? Am I trying something impossible here? - I thought 10K was
> a small size. I would be glad to hear of any ideas you may have on how
> to get this to synthesize. I am not so much concerned about the run
> time - but that it works without crashing.
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
Thomas Stanka
olso...@yahoo.it schrieb:
> 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.
> 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.
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.
> A code sample showing one of my gates (with the associated Mux) is
>
> Nand_2_0_0 : forg_node_16_Cell_0 <= not (input_2_Cell_0 and
> node_11_Cell_0);
>
>
> SEL_node_16_Cell_0(1) <= ctrl_fault_4_Cell_0;
> SEL_node_16_Cell_0(2) <= ctrl_fault_5_Cell_0;
node_16_cell_0 <= fault_4_node_16 when (insert_faults_cell_0 =
'1' and SEL_node_16_cell_0 = "01") else
fault_5_node_16 when
(insert_faults_cell_0 = '1' and SEL_node_16_cell_0 = "10") else
forg_node_16_cell_0;
could be a bit smaller code replacement for your mux (won't change
anything concerning synthesis) but you drastically reduce the number of
lines for same functionality.
> (Just imagine that I do this 10K times - including final signal
> mapping.)
This adds roughly 10k times 1 complex gate with 6 inputs and 1 output
to your design without any signal buffering, meaning you double your
gatecount at least. In fact I expect you to need about three times the
design size.
This code seems to introduce combinatorial paths with length of more
than 10k gates.
Don't do this. I guess even 100 gates per path will kill your tool.
BTW: you do this for fault testing, right? Doubling your design to
achieve a fault coverage seems the wrong way for me
bye Thomas
olso...@yahoo.it
Andreas Ehliar wrote:
>
> 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
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.
olso...@yahoo.it
Thanks for taking your time to reply.
Thomas Stanka wrote:
>
> 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.
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.)
> node_16_cell_0 <= fault_4_node_16 when (insert_faults_cell_0 =
> '1' and SEL_node_16_cell_0 = "01") else
> fault_5_node_16 when
> (insert_faults_cell_0 = '1' and SEL_node_16_cell_0 = "10") else
> forg_node_16_cell_0;
>
> could be a bit smaller code replacement for your mux (won't change
> anything concerning synthesis) but you drastically reduce the number of
> lines for same functionality.
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.
> This code seems to introduce combinatorial paths with length of more
> than 10k gates.
> Don't do this. I guess even 100 gates per path will kill your tool.
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?
> BTW: you do this for fault testing, right? Doubling your design to
> achieve a fault coverage seems the wrong way for me
>
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.
Thomas Stanka
olso...@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.
>
> 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.)
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.
> > This code seems to introduce combinatorial paths with length of more
> > than 10k gates.
> > Don't do this. I guess even 100 gates per path will kill your tool.
>
>
> 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?
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
Andreas Ehliar
> 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.
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
olso...@yahoo.it
Andreas Ehliar wrote:
> 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
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.
olso...@yahoo.it
Thomas Stanka wrote:
> Hi,
>
> olso...@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.
> >
> > 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.)
>
> 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.
>
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.
> 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
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.