|
Message
From: Samuel Goto<samuelgoto@g...>
Date: Wed Oct 24 14:15:31 CEST 2007
Subject: [oc] Re: [Fwd: GSC problems]
Hi Philipp !!On 10/18/07, Philipp Klaus Krause <attachment.htm
>
> I noticed the GSC SystemC to Verilog translator and want to try it. The
> documentation claims it's far superiour to previously existing free
> SystemC to Verilog translators.
well, i didn't mean to claim that it is far superiour to previous attemps,
but it is definitely far more scalable than others. By scalability I mean
that I am using a well stabilished c++ parser (keystone.sf.net) while others
are using a hand written c++ lex/yacc parser. This means that gsc has the
ability to support all systemc constructs, while other translators are
binded to their poor c++ subset parser.
by not being far superior than previous attempts I mean that it is a work in
progress, and systemc constructs are being added while users send me
feedback ( like you ! thanks for your help ! hehe ! ).
however, AFAIK, I could say that gsc is superior than opencore's s2v and
tabajara ( the only open soucre translators I am aware of ) and quite
comparable to synopsys dc_shell ( the only comercial translator I have acess
to ).
However I have some troubles making it work. These are mostly related to
> GSC's use of Keystone.
ok.
I, as you may be, am a programmer ... and programmers aren't really good at
making user interfaces ( like command lines options, etc ). Therefore, gsc
is definitely not as user friendly as one may expect. However, in time, with
users feedback, more and more usability features will be added.
Keystone assumes sizeof(unsigned int) == sizeof(void *), which isn't
> true on 64 bit systems. It assumes yacc's output files are named y_tab.h
> and y_tab.c, which was true a long time ago, but these days they're
> named y.tab.h and y.tab.c.
> I had to install 32 bit development libraries on my system and compile
> using gcc-3.4 -m32, g++-3.4 -m32 using linux32 (a tool to make programs
> think they're running on a 32 bit system).
>
> I've managed to compile Keystone, but it still doesn't work:
great ! send me the patch and I'll will patch it against the next release (
and send you the kudos, of course =) ).
key -I ~/systemc/objdir/include half_adder.cpp
> Token Buffer:
> 0. /usr/local/include/keystone/stubs/fstream:39: traits
> 1. /usr/local/include/keystone/stubs/fstream:39: >
> 2. /usr/local/include/keystone/stubs/fstream:40: {
> 3. /usr/local/include/keystone/stubs/fstream:41: public
> 4. /usr/local/include/keystone/stubs/fstream:41: :
>
> current: 2
> last: 4
>
> Failed assertion: base class scope was not of type ClassScope.
> file: ContextManager.cpp
> line: 290
which systemc.h are you using ? gsc uses a special systemc.h which overrides
most of the #defines such as SC_MODULE, SC_METHOD, etc ...
Thus I have some suggestions to improve usability of GSC:
> * Provide Keystone binaries on the download page. This would make using
> GSC a lot easier and probably remove the dependencies on btyacc and
> maybe treecc.
OK. I'll do this for my architecture (x86 32 bit) and if you build one for
yours send it to me.
> * Make GSC give an error message if Keystone is not found (currently it
> just hangs on the select() call in line 65 of parse.c).
OK. Do it as you think it should be done and send me the patch.
* I don't think it is necessary to provide graphviz on the download
> page. graphviz is included in many Linux distributions, so users won't
> have problems finding it. Make the configure script look for graphviz in
> default loations, not only in /usr/local.
I included graphviz in the download page because I didn't tested gsc against
other versions of graphviz. Besides, I need all the development headers of
graphviz, not only binaries.
Philipp
>
>
Great =) I hope this helps.
Send me patches and feedback. This is how I want gsc to grow : with users
open source contributions.
--
f u cn rd ths u cn b a gd prgmr !
-------------- next part --------------
An HTML attachment was scrubbed...
URL: attachment.htm
|
 |
Browse
