> On 10/03/2016, at 10:50 am, Lehmann, Patrick <patrick.lehm...@tu-dresden.de>
> wrote:
>
> Hello Adrien,
>
> Can you give some information on your used GHDL installation?
> - version number or source code checkout date
> - backend: gcc, llvm, mcode
>
> Are you exporting the simulation results as a waveform dump file? E.g. vcd,
> fst, ghw, ...
> => This has a high performance impact, caused by string operations and file
> I/O
>
> What is the used VHDL version?
>
> Are you running xSim in multi-threaded mode?
> -mt on|off|2...n (it's enabled by default)
For whatever reason I didn't get Adrien's original post. Recovering it from
ghdl-discuss archives to recover vhdl.tar.gz and running the model shows
something interesting.
The vector rate is asymptomatic (it gets slower the longer it runs). (OS X
ghdl-0.33 llvm).
On a Mac (OS X) you can watch the memory utilization climb.
real memory size 163.2 MB around 580 cycles.
164.6 MB around 780 cycles
169.5 MB around 1434 cycles
The ghw file progresses in size 1,842,834 bytes after 730 cycles
1,846,930 after 738
1,965,714 after 1434
The virtual memory size goes up slowly over time 2.50 GB at 1486 cycles, it was
2.39 GB at 580 cycles. I'd imagine I'd imagine the simulation might end (550K
cycles) before running out of memory.
I haven't looked in depth at the model, grep'ing shows no allocation going on.
Where the memory leak is, isn't readily apparent.
At around 962 cycles it had slowed down to around 3 seconds per two cycles. 5
seconds by 1350 (This doesn't seem like a malloc artifact, unless there's lots
of big things being copied, OS X is fairly efficient for small things).
There are oddities in how the code was generated. In jpegfilebuf.vhd for
instance there's the context clause:
library ieee;
use ieee.std_logic_1164.all;
library ieee;
use ieee.numeric_std.all;
There's also a declaration of to_integer[std_logic_vector return integer] to
overcome the lack of numeric_std_unsigned (or Synopsys packages). Te intent
looks to be -93 compatible.
I take it this thing is a jpeg compressor?
1500 cycles or so and got 15020 ns of waveforms which tells us the clock speed
with out looking. A mere 15 us after quite some realtime.
Without the waveform dump file it slows down asymptomatically as well, just not
as fast (The curve is offset). The real memory size goes up as does virtual
memory size.
This is the first sizable simulation in ghdl I can recall seeing with writes to
standardout showing simulation time slowing. The slowly slower doesn't seem to
be an OS X job scheduling artifact.
Just saw Jim's reply to Adrien's follow up. I simply don't get email from
Adrien. That enough to make me switch to gmail for ghdl-discuss. My ISP gave
email to Yahoo, while you'd expect that to change soon. This looks like Yahoo
doesn't like his apparently from.
The link to the original problem
https://mail.gna.org/public/ghdl-discuss/2014-11/msg00064.html
The models appear highly similar. I'd imagine the problem is related.
> -----Original Message-----
> From: Ghdl-discuss [mailto:ghdl-discuss-boun...@gna.org] On Behalf Of Adrien
> Prost-Boucle
> Sent: Wednesday, March 09, 2016 9:38 PM
> To: GHDL discuss list <ghdl-discuss@gna.org>
> Subject: [Ghdl-discuss] Huge simulation speed slowdown
>
> Hi,
>
> I have a VHDL design that GHDL simulates at a speed of only one or 2 clock
> cycles per second. The same design, same VHDL files, is simulated by Xilinx
> Vivado 2015.3 at a speed of 400 clock cycles per second.
>
> For all other designs I have and/or generate, GHDL is always noticeably
> faster that Vivado, so I think my current app exhibits a GHDL behaviour that
> at least could be improved.
>
> Note that the attached VHDL was generated by a HLS tool so it's not easy to
> read... and unfortunately I can't reduce the VHDL code to something simpler
> that exhibits the slowdown.
>
> The top-level entity is the testbench entity "tb". The simulation is supposed
> to stop after around 550k clock cycles.
>
> Good evening,
> Adrien
> _______________________________________________
> Ghdl-discuss mailing list
> Ghdl-discuss@gna.org
> https://mail.gna.org/listinfo/ghdl-discuss
_______________________________________________
Ghdl-discuss mailing list
Ghdl-discuss@gna.org
https://mail.gna.org/listinfo/ghdl-discuss
