|
From: Kevin C. <iv...@gr...> - 2015-06-23 02:26:38
|
Brave man Jon! I hear gHDL is making good progress these days. Actually I suspect using VHDL for an OS is possibly better use than hardware description ;-) Given that it's impossible to persuade everybody to use the same language or the same simulator, I recommend using an OO API for boundary elements between systems. The boundary elements in electronics are the wires that connect things, the objects that connect the processes to the wires are drivers and receivers (Verilog-AMS parlance), so you need an API for connecting drivers and receivers to wires in other simulations/partitions. I would handle the resolution process for multiple types connected to a wire outside the HDLs because although it's not particularly difficult the standards bodies have not got their heads round it in the last 2+ decades, and I'm not expecting any sudden enlightenment. Also, you want to handle scheduling (for NBAs) as well as resolution within the objects representing the wires. You can do a large chunk of that with C and DPI calls in SystemVerilog resolution functions for user defined types, but I'm not up to speed on where Icarus is with SV support. Likewise I haven't used gHDL in years and don't know where it stands. Kev. On 06/10/2015 03:33 PM, Jon Taylor wrote: > > Hi all, > > I am the author of Controlix, an operating system written in vhdl. I am currently developing it using GHDL as the compiler, and the system interface uses vhpi calls. Works OK on top of POSIX, but Icarus' vpp is written in c instead of in ada, making a static linkage job for bare metal targeting much more feasible. > > Afaics from perusing the sources, neither vhpi or vpp are currently supported by vhdlpp. If someone is already looking into writing support for this, I'd be happy to test, otherwise I might be able to take a crack at it myself (I have the coding time available). > > Jon > > > > ------------------------------------------------------------------------------ > > > _______________________________________________ > Iverilog-devel mailing list > Ive...@li... > https://lists.sourceforge.net/lists/listinfo/iverilog-devel |