On 28 Nov 2013, at 6:38 am, Adrien <[email protected]> wrote:
> As David Koontz suggested, I chose to append "others => (others => '0')"
> to the list of values, and it works.
>
> Thanks a million David for your great answer. I learnt something
> useful:)
>
> HOWEVER...
>
> When I say it works, well yes it does work for some "little" circuits.
> For a "big" circuit, where my array has 369817 cells (width 8), ghdl
> rapidly eats all my system's RAM and tells me this:
>
> ghdl1: out of memory allocating 14974840 bytes after a total of
> 1966264320 bytes
> ghdl: compilation error
Without knowing better that looks like it was already using 196,624,320 bytes
of memory already and asking for 14,974,840 bytes more.
>
> It is reproducible.
> When I don't append "others => (others => '0')" to the list of values to
> initialize my array of test vectors, GHDL is happy.
> When I append it, GHDL makes this out of memory error.
>
> What's curious is that I have another app with which GHDL makes the same out
> of memory
> error, but it's completely unrelated to the array of test vectors.
> Or maybe it is: this other app has a one-hot FSM with 73945 states xD
> It's an std_logic_vector(0 to 73944) who is initialized with (others =>
> '0'). This FSM is a beast 745058-lines VHDL file, 12.5MB.
> For this FSM GHDL says this:
>
> ghdl1: out of memory allocating 536870912 bytes after a total of
> 227868672 bytes
> ghdl: compilation error
Notice there's a similar n=1 dimensional others statement at line 2373 in the
process sensitive to clock:
state_cur <= (others => '0');
And in the state transition process at line 289:
state_next <= (others => '0');
Both of those are array sizes 3945.
> There GHDL says it fails to allocate 539MB after 230MB, which does not
> seem huge IMHO.
Notice the failure point used memory wise is close between the two different
models, which may speak to other complexities. It looks like you simply don't
have enough memory.
We can actually look at fsm.vhd because you sent the source. It has 150,235
signals and signal elements, and it seems the ratio of size would be hard to
imagine if it were only made up of those 539MB/150235 = 5370 bytes per signal.
That seems a bit high so you could wonder if there were something else going
on with others assignment. Perhaps those others assignments got unfolded from
loops to flat.
> If it's of any interest, you'll find attaches this FSM (.gz 733kB).
> And Xilinx XST also makes an out of memory error on the same FSM component...
> I really want to understand why. It really seems to be related only
> to the size of the FSM state register.
>
> I totally know building a circuit with 74k states is unrealistic.
> I am only interested about it from a simulation point of view.
> Why whould a 74k-cells std_logic_vector make a compiler/simulator crash?
> And one must always know the behaviour of the tools he uses!
>
> Is it possible that this construct (others => stuff) can stress ghdl
> that much?
The allocated memory numbers being close for the two reports above say's you're
likely running out of memory. What you may be railing against is the amount of
memory ghdl is using for the models. It doesn't appear to be data space, so
perhaps its program space. Do you have a size for the .o file? It might be
interesting to disassemble it too.
Instead of the likes of:
state_next <= (others => '0');
you could try:
for i in state_next'range loop
state_next(i) <= '0';
end loop;
for those big arrays.
If that works or the amount of memory ghdl is trying to allocate goes down
significantly perhaps Brian or I could manage to locate the code generation
output and try optimizing it a bit for others aggregates. No guarantees.
> Or do I have really excessive expectations with my oversized components?
> Your feedback would be greatly helpful!
I don't think they reflect hardware you'd actually build. Wholesale setting an
entire one hot state array that big simply because you don't do it for the bits
set in the precursor state to the now current state seems a bit excessive.
The if statements should be if then elsif... The way the it is now you
evaluate all the expressions and all but one are going to false. Using elsif
allows you to quit evaluating after you find the current state value.
I think a port with 2347 signals is a bit extreme (read unreasonable).
You should try in another tool environment as well, speaking of which Nick
Gasson emailed me and after modifying his VHDL tool so it would analyze
fsm.vhd. He used emacs to write a test bench. Last heard he was waiting on
elaboration to finish so he could quit for the night. fsm.vhd is the slowest
analyzing VHDL design description I've ever seen ghdl swallow.
fsm.vhd.gz is under the maximum size threshold for appending in a bug report on
gna.org. (And I don't know whether that's a blessing or a curse).
A one hot state machine is harder to generate than something with scalar array
state.
As I recall the correct way to write a state bit would be something along the
lines of
state_next(44013) <= state_cur(44014);
as a concurrent signal assignment, implying no need for the broadside 'clears'.
I accidentally picked and easy one there are some 2 different states branching
to the same states in there.
You could also generate the appropriate outputs as concurrent signal
assignments or'ing together all the one hot states that generate a particular
output.
There are equivalent process statements for concurrent signal assignment
statements that essentially end with the added sequential statement:
wait on sensitivity_list;
where the sensitivity list includes every signal showing up on the right hand
side of the assignment operator in the concurrent signal assignment state cast
as a sequential signal assignment statement.
If nothing else it would let you know just how big your model actually is in
terms of hardware.
For instance there are 36,864 states writing out1 to a '1', suspiciously the
same number of out2 '1' assignments which likely tells us your state machine
isn't optimally expressed, they seem to be paired. out5 has the same number of
assignments but doesn't appear to paired, but does appear to be associated with
a set of outputs.
And about now I'm starting to believe your model can just be that big. That's
a lot of OR operators. With scalar states you can do ranges and patterns (as
well as logic reduction), which you can't do with one hot. There's a practical
limit to the number of one hot states fsm.vhd is guaranteed to exceed. This
hardware likely can't be synthesized either, at least not when hitting any
performance goals driving you to use one hot encoding.
Just what is fsm.vhd supposed to do, anyway?
_______________________________________________
Ghdl-discuss mailing list
[email protected]
https://mail.gna.org/listinfo/ghdl-discuss
