Hi all, > > To implement libraries which allow some sort of system interaction beyond > reading/writing text files one must go beyond the confines of VHDL, and > VHPI is the way to go. That was my main point.
I guess noone would object. I'm kind of an impatient software guy, so I've been looking for the most efficient way to marry GUIs/Python/C/VHDL for a while. In the process I found some inspiring stuff (thanks, whygee!) as well as undocumented excellent features that the commercial tools don't offer (or maybe I just didn't spend enough money..). At the moment, I have a pretty complex SoC design running as a "virtual board" within GHDL and the 'ghdlex' extensions (co-simulation of HW and SW via VHPI), including JTAG so that I can remote-debug the entire SoC with an 'off the shelf' Gnu debugger. I've got quite a gain from this method personally, and it seems it's matching the trend of the 'big guys' too, so I'm happy to be able to demonstrate some stuff at the 'embedded world 2012'. Sneak peak: http://section5.ch/doc/jtag/movies/ Anyhow, the problem might be, that some people not very inclined to 'reverse engineering' are put off by the lack of documentation or things not following the 'standard'. I've started documenting some stuff for ghdlex in doxygen, but that's not even 20% of the pole. I might be ignorant, but I see no point in implementing "new standards" that don't immediately boost us factor 10x in solving typical development problems. As far as I can see, GHDL already is one of the best standard compliant tools around. [ Pretty please, don't touch the running system ]. But I'd sure like to hear more opinions about limitations with respect to the current VHPI interface. The ones I've seen so far could be worked around easily. So the priority '9' task in my opinion is, writing more docs/examples/appnotes about what the current stuff can do... Cheers, - Martin _______________________________________________ Ghdl-discuss mailing list [email protected] https://mail.gna.org/listinfo/ghdl-discuss
