Using Nick's test bench I successfully ran the fsm model unchanged. It peaked at 630 MB memory utilization.
ghdl -r fsm_test --stop-time=100ns Has a 10 ns clock period so 10 clocks. Reset released after 50 ns, all inputs set to '0'. This on a Mac, a ghdl_mcode version. Peak Memory determined by the Activity Monitor Memory pane (OS X 10.9), ran twice. From which I can conclude Adrien was definitely out of memory, my Mac had over 2.7 GB free when I ran it. I figured it would work when I saw Adrien's messages didn't concern stack sizes. Subjective run time was around two minutes I think. Makes you nervous watching memory usage creep up, spring to the peek then wait nervously to see if it completes. Analysis took around 6 seconds. Elaboration is folded into the -r command on ghdl_mcode which is direct instantiating. I'm including Nick's test bench (without asking, Thanks Nick!). It still might be worth disassembling to see if there's anything glaringly in need of optimization. Some large design guidelines as well as something talking about stack sizes may be in order, but this one was easy. More memory. A late 2008 aluminum Macbook Model Name: MacBook Model Identifier: MacBook5,1 Processor Name: Intel Core 2 Duo Processor Speed: 2.4 GHz Number of Processors: 1 Total Number of Cores: 2 L2 Cache: 3 MB Memory: 8 GB Bus Speed: 1.07 GHz System Version: OS X 10.9 (13A603) Kernel Version: Darwin 13.0.0 ghdl mcode -r150, ghdl-0.29+, slightly newer than the version on the ghdl download page.
fsm_test.vhd.gz
Description: GNU Zip compressed data
On 28 Nov 2013, at 8:37 pm, [email protected] wrote: > Hi, just a few cents... > > Le 2013-11-28 07:59, David Koontz a écrit : >> On 28 Nov 2013, at 6:38 am, Adrien <[email protected]> wrote: >>> 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. > > I have already spent a little time disassembling GHDL generated code > and it does not work exactly like in a C style programming. > it keeps checking bounds, and then checking some more, > so beware when you code with arrays etc. > GHDL will also duplicate large stuff if you're not cautious, like > providing an array as argument to a function (without proper care). > Furthermore, there are 2 stacks : the CPU stack and a made-up stack, > a sort of "heap", that can eat a lot of mallocs and stores stuff > that don't have a place on the stack, like returned arrays. > All the ease of writing that VHDL provides comes at a cost > on the compiler side, execution time and memory usage. > There are many considerations to take into account > while preparing the code, the structures, > when you write it's already too late. > > Thanks everybody for this very interesting threads, btw :-) > > yg > > _______________________________________________ > Ghdl-discuss mailing list > [email protected] > https://mail.gna.org/listinfo/ghdl-discuss
_______________________________________________ Ghdl-discuss mailing list [email protected] https://mail.gna.org/listinfo/ghdl-discuss
