Hi, Yes it is a jpeg decoder ;-) Actually it's the jpeg application from CHStone benchmark http://www.ertl.jp/chstone/
The VHDL code uses no generics, no allocation. Yes the intent is to be -93 compatible. Maybe in a place or two there is something from -02 because it was supported by synthesis tools, but no big deal. All VHDL except the testbench entity is synthesizable, and does synthesize and works on FPGA. About you don't getting my emails, it may be due to my email provider not correctly autenticating itself somewhere. I often get <DKIM> appended to the title and the message silently dropped in the spam or any kind of temp directory. I've written to them about that, don't know if they are working on it... Adrien On Thu, 2016-03-10 at 12:44 +1300, David Koontz wrote: > > On 10/03/2016, at 10:50 am, Lehmann, Patrick 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 _______________________________________________ Ghdl-discuss mailing list Ghdl-discuss@gna.org https://mail.gna.org/listinfo/ghdl-discuss
