On Sat, 2013-11-30 at 16:12 +0100, Adrien Prost-Boucle wrote:
> On Sat, 2013-11-30 at 12:48 +0000, Brian Drummond wrote:
> > The other thing you could try for the fsm is a 64-bit build of ghdl, on
> > a machine with at least 8 GB of physical RAM.
> Argh
>
> However I still feel that much memory is way beyond what should be
> enough to just compile this fsm.vhd...
Yes.
One part of the problem is your choice of data types.
To get the correct simulation behaviour for std_logic_vector, it must
treat each bit as a separate entity. That bit has its own gcc data
structure : many tens of bytes (a major gcc effort went into shaving a
few bytes of this structure by reusing 4 bytes for different purposes;
one of the things that broke ghdl for several years).
Then the optimisation passes may keep several modified copies of this
structure...
Unless you need signal resolution from multiple drivers you don't need
std_logic_vector.
I experimentally edited "tb.vhd" to use natural instead of
std_logic_vector. I had to :
change two type declarations:
type invec_type is array (0 to in_vectors_nb-1) of
natural range 0 to 2**(in_vector_bytes * 8) - 1;
add type conversions to two assignments:
stdin_vector <= std_logic_vector(to_unsigned(in_vectors(in_vector_idx),
stdin_vector'length)) when in_vector_idx < in_vectors_nb
else (others => '0');
find/replace the literal format from X"55" to 16#55#
and unlike the original, it ran successfully with redundant clauses (now
"others => 0") in place. Memory usage still reached 3.5GB but the slv
version wouldn't run at all until I reduced the aggregate size from 370k
to 150k.
> I'd really love that the idea of reducing gcc back-end optim level could
> lead to good results, if not outright solving the problem.
I had no luck with -O0. But one loose end I meant to chase earlier:
time ghdl -a -Os tb.vhd
(Optimise for code size) stays at a flat 900MB (but segfaulted in the
gcc tree optimisation passes after 5 minutes). There are flags to turn
off individual optimiser passes but I haven't tried these.
Apologies for sending incomplete message:
Now confirmed that -Os doesn't allow fsm.vhd to compile in under 4GB of
memory either.
SO:
Options for FSM are:
1) use ghdl mcode version
2) possibly choose a more economical datatype than std_logic_vector.
Don't know if bit_vector would make the difference. Or use a
conventional state set rather than explicitly one-hot, and make the
choice between state encodings in synthesis.
For TB : number one has to be to eliminate the redundant others clause!
And switch from positional to named association for single element
aggregates.
In my opinion it is worth reporting these separately on "bugs"
https://gna.org/bugs/?group=ghdl - not to get them fixed - but (for fsm)
to document the fact that the gcc back-end is much more memory-hungry
than mcode for extremely large designs. This could be useful to others.
And for "tb" to document that very large array aggregates OR "others"
clauses work well individually, but not together.
- Brian
_______________________________________________
Ghdl-discuss mailing list
[email protected]
https://mail.gna.org/listinfo/ghdl-discuss
