On 13/05/11 5:33 PM, Kevin Steffensen wrote: > >> >> I'd like to do a gcc version of ghdl, and maybe a newer gtkwave release. >> > > I've been fiddling around with updating GHDL to use some newer versions > of GCC. Moving up through the GCC 4.4.x mostly involves adjusting > ortho-lang.c and is pretty simple. I ran into trouble I couldn't figure > out when moving to GCC 4.5. I've previously posted a patch to > ortho-lang.c that compiles with GCC 4.4.5, and seems to work as intended. > The same patch fails to compile with GCC 4.5.0 due to some issue with the > way GCC handles functions. It took deeper knowledge of GCC than I have to > figure out and at that point I got sidetracked by other stuff, so I never > solved the issue. I would like to help with solving it though.
While my ambitions are a little more immediate I went and looked at the gcc trees. I'd normally suggest working from 4.4.3 which begat 4.5.0 and looking at the changes, PRs and the diffs. It might be easier to march up the branch you can see the changes when you can see changes in steps. The idea to bring the changes down to as small as set as possible to audit why things don't work as an alternative of going 4.4.3 - 4.4.4 - 4.4.5 to 4.5.0. Unfortunately the gcc-core-4.4.3-4.5.0.diff.gz is 18MB. > > It would also be very nice to have some sort of testing suite, to make > sure that you don't break anything when hacking around on GHDL. Keep that can opener away from that can of worms!!! (just kidding) Looking at the VHDL International validation suite (which is chocka full of copyright notices) There are 1169 VHDL-87 only test cases, 3225 VHDL 93 test cases and 1310 untestable sentences in the VHDL93 LRM normative content. There isn't an incentive for vendors to share their test suites openly. The VI validation suite doesn't appear to be available today, nor is the diminutive of if offered by IEEE using a now non-supported MDB file format (Microsoft Access Database). An open source project should really have a test suite openly available, too. I'd anticipate with the changes in semantics elaboration and with added feature changes in VHDL 2002 and VHDL 2008 those 4394 test cases would probably bloom to somewhere well north of 6000, let's say 8000 without increasing the test coverage, which is probably around 40 percent. The effort to produce a test suite from scratch would likely exceed 3 man years without even considering the upcoming VHDL 2014. I'd consider doing it algorithmically (see http://www.eda.org/VIUF_proc/Fall96/WILLIS96B.PDF), to make the whole thing smaller and reduce the amount of data for new test cases. Also testing multiple test cases at the same time in the same source where feasible by using assertion severity warning. An examination of the latest test suite found by entering http://mikro.e-technik.uni-ulm.de/vhdl/upload_data/vi_suite.tar.Z in the wayback machine (http://replay.web.archive.org/20110514235929/http://mikro.e-technik.uni-ulm.de/vhdl/upload_data/vi_suite.tar.Z) shows a copyright notice on individual files: VHDL International owns the sole copyright to this software. Under International Copyright laws you (1) may not make a copy this software except for the purposes of maintaining a single archive copy, (2) may not derive works herefrom, (3) may not distribute this work to others, These rights are provided for information clarification, other restrictions of rights may apply as well. The VHDL FAQ http://www.vhdl.org/comp.lang.vhdl/FAQ1.html#4.5 4.5 Is There a VHDL Validation Suite Available? Yes. The latest version of the test validation suite is available via anonymous http://mikro.e-technik.uni-ulm.de/vhdl/vhdl_utilities.html The current suite covers 36% of VHDL-1987. All this shows the test suite was intended to be publicly available which makes one wonder about the restrictive copyright notices on the later version. There's also a public offer in the paper "Development of a VHDL Validation Suite", Hines (USAF), Billowitch (VHDL Technology Group) found here: http://www.eda.org/VIUF_proc/Spring95/HINES95A.PDF (on Accellera's web site). The latest VI validation suite was originally publicly available at ftp://vhdl.org/pub/validation/vi_suite.tar.Z vhdl.org is registered to Synopsys, and it's successor with apparently the same content eda.org is registered to Accellera. Neither have a validation page available. Open Verilog International and VHDL International combined to form Accellera in 2000. Background on the validation suite can be found at http://replay.web.archive.org/19980131011515/http://www.vhdl.org/validation/ You could note that today no Air Force contacts are available. They claimed their 3164 tests provided 36 % coverage of VHDL 87, and achieving complete coverage of VHDL 87 would require an additional 8800 tests. I'd imagine for VHDL 2008, that number would total somewhere between 20,000 and 30,000 as an educated guess. The VI validation suite could at least be used to identify test cases through VHDL 93, but as I recall I'd take exception to some small of those LRM sentences deemed untestable. You'd need VHDL 93 to VHDL 2002 differences to examine the '02 version for more test cases, and also watch for previous test cases that are now version limited. You'd have to do the same between the '02 LRM and the '08 LRM using your resulting data on what's testable and not. There'd be considerable effort verifying the test cases to insure you should be held to the results, the effort coding all the test cases, and for added measure there is no compliant VHDL 2008 tool to hold as a reference. While I can imagine privately running the VI validation suite or seeking copyright release the amount of work for later versions also brings up the idea that without serious help ghdl may not ever be verified or even current. Tristan and I certainly don't have the man years between now and the release of VHDL 2014 to guarantee success at developing a test suite while also fluffing out feature support and bugs. I warned you it's a can of worms. >> >> Also doing a code map text document because I've had to rediscovery >> things a couple of times. The upside is that it could lead potential >> software contributors through the source code and will have some >> architecture information. >> > > This would be very nice, it took me a long time to get just a vague idea > what was what in the GHDL sources. I promise it will stop at 'throwing things over the fence' to gcc. gcc issues related to front end compatibility with newer versions can be held to be a separate issue. It may be worth separating the GHDL runtime library (grt - simulation core) out separately. While there are dependencies across the divide there are classes of things that can be done separately for simulation. _______________________________________________ Ghdl-discuss mailing list [email protected] https://mail.gna.org/listinfo/ghdl-discuss
