Hi Tristan,

thanks for the snippet. Played around a bit with XSL and got some usable output just for dumping purposes. Reality will be far more complex though...

4) I was wondering, if it was actually possible to hack an .XSL to
extract register assignments as the above, or if a more complex tree
parsing via a "real" programming language was required.

I fear that xsl is not the best way to write a syntheziser...

I'd tend to say "impossible", but in in a few cases so far I found ways to translate from XML dialect A into dialect B which again can be processed easier, without going through complex classical DOM parsing solutions (saxon/expat/...). So a possible first step could be to identify constructs that synthesize and express them in an easier-to read (and *then* schematize via XSD) XML language. I've played around in the past with the Python/MyHDL approach (with the built-in native access to the AST) to generate RTL for DSP units. Not considered "nice", but usable. Nice would be to have an intermediate "XML DNA", but that's way more complex than a few DSP slices...

I also liked YG's idea/approach with the virtual machine, but the path from a 'simulation primitive' (event driven logic) to a level where the VM would know how to handle a HDL-Design with a set of FPGA technology elements seems already more complex than a HDL analysis based on the actual code (via AST) with a mapping stage in between. Wild dreaming: Deploy machine learning algos (but spend a few years on research...)

But the coverage aspect of it is very nice, also, a different way of optimization could take place, that considers the real application scenario based on the test bench. It might also give a lot more control to place & route from a mapper level. Can't think of the time burnt just because tools do what they want by just crunching brute force in the wrong direction. And then it's a bad time having to reverse engineer and find out: The human brain is often the better router.


- Martin

Ghdl-discuss mailing list

Reply via email to