Mimochodem máte s HLS nějaké hlubší zkušenosti z pohledu srovnání s vlastním "optimálním" řešením? Myslím tím spíše aplikace jako zpracování signálu.
Ano, ušetří to spoustu práce. Běžně to používáme na processing, který by se ve VHDL psal neakceptovatelně dlouho. Hraje se na to, že vybrané FPGA (třeba Zynq, Ultrascale,...) je už při designu hw vybráno tak velké, že se to tam v pohodě vejde a max clk je stále nad požadavkem (špatné to začne být, když si zákazník začne následně přidávat další náročnější funkcionality).
Psaní v HLS bych pocitově asi přirovnal k tomu, jak se v C snažíte psát optimálně pro 8-bit MCU. Tj. znáte architekturu MCU (registry, ISA, způsoby adresace) a zápisem algoritmu jdete architektuře naproti. Někdy to moc nejde, ale slušný překladač si s tím docela poradí a optimalizuje. Na čem to dojíždí v FPGA, jsou především dvě věci - složitější matematické operace (tady se překladači blbě vysvětluje, že stačí pouze ta a ta přesnost a třeba jen v nějakém oboru hodnot) a opakování bloků při paralelizaci apod. (tu mírnou neefektivitu, co odpustíte jednomu bloku v HLS, už snášíte se skřípěním zubů, když se ten blok použije 128krát).
Příklad z praxe - jistá nechutná ale primitivní matematická funkce. HLS vedlo k použití vyššího počtu stovek CLB + nějaká ta BRAM s variabilní latecí vstup/výstup v rozsahu do asi 100 Tclk. Při ručním návrhu v VHDL/RTL s přihlédnutím k tomu, že následné DSP core v dalším zpracování jsou stejně 18bitové a nám stačí 16bitová přesnost, se blok redukoval na necelých 40 CLB s fixní latencí 19 Tclk.