Hi,
Waow.
I know this isn't the best mux code ever, but I didn't imagine it could
be that painful...
I am very surprised by the impact of the size of these mux expressions.
I have many designs with a lot of mux expressions inside, and even if
these expressions are a bit smaller there is still a LOT of them, and
GHDL still simulates that at 2000 clock cycles per second like it's
nothing. It seems to me that the transition 2000 cy/s -> 2 cy/s is very
abrupt.
Is it possible to know if the source of the problem comes from the use
of my little repeat() function? Or the (others => xx) statement in that
function? Is there mem alloc in the function due to the signal
declaration in that function? Don't know if handling function calls is
heavy in GHDL, but these occurrences are undoubtedly evaluated many,
many times.
I can re-generate that design without the repeat() function, instead
writing a large concatenation. It can be interesting, just for the
test.
I had another idea.
Re-evaluating the entire mux expressions is a heavy task.
So would it be possible to re-evaluate only the sub-expressions that
have changed? Including, for function calls, only those that have no
side-effects ("pure" functions), and whose arguments have changed? If
such an optimization is possible, it may improve speed for many other
designs.
Adrien
On Mon, 2016-03-14 at 21:30 +0100, Tristan Gingold wrote:
> On 09/03/16 21:37, Adrien Prost-Boucle wrote:
> >
> > 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.
> I had a look at your design.
> More than 95% of the time is spent in two processes of top.vhd:
> -- Behaviour of component 'mux_266' model 'mux'
> and
> -- Behaviour of component 'mux_291' model 'mux'
>
> They are quite large...
> GHDL could be able to optimize them better, but if your tool
> could simplify them, that would be helpful too!
>
> Tristan.
>
>
>
>
> _______________________________________________
> 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
