Hi, I'm answering to David's message from the webmail in the hope that my message is sent correctly this way...
Thanks a lot David for your analysis of the VHDL code I sent. I can comment on several points. 1) About possibility to reduce the number of remaining concatenantions The current coding style contains a lot of concatenations instead because before VHDL generation, the multiplexer components were still manipulated as components by the HLS tool. So the style of the expression that feeds the input ports is tailored to be used as port assignation in VHDL, in particular I can't use repeat-like functions there. But here the code of the muxes is "inlined" in the top.vhd entity to reduce the number of separate components. So I could let the repeat-like operations on the expressions on the inlined components. In fact it's already on my todo-list (but low priority because I thought it only had an impact on readability). 2) About the fact that these large muxes could be splitted and simplified That's true indeed. However I tended to let that optimization task to the back-end logic synthesis tools. These tools would do a much better jobs at this task. Also often it's not a good idea to systematically split the muxes (bitwise for example), so that simplification would need to first evaluate how well this or that mux or part of mux is appropriate for splitting. This is more complicated code to maintain and it's not critical for the HLS tool point of view. But I keep that idea in mind, maybe one day I'll find a clean way to perform a kind of pre-simplification of some muxes... 3) About the fact that many mux inputs are only width extensions Yes, for debug purposes, it's useful to keep the muxes "flatten" and "full-width" the current way because we read what we expect to read. The extension may be signed, unsigned with '0' or with don't care bits when appropriate. The current mapper of the HLS tool currently don't generate don't care bits there, but that'll come. The synthesis tools take good care of that. Adrien _______________________________________________ Ghdl-discuss mailing list Ghdl-discuss@gna.org https://mail.gna.org/listinfo/ghdl-discuss
