Re: [Iverilog-devel] Draft GSoC proposal

[Nick G. <nm...@yo...>]

Cary R. wrote:
> Nick,
> 
> I agree with Steve this is more than good enough as is to submit. The
> following are a few things that you may want to consider. They will
> certainly need to be considered during the development phase.

Thanks! I'll submit it later this evening/tomorrow once Google start accepting applications.

> 
> 1. The compiler in its currently implementation only has hooks at the end
> of the compilation process. The consequence of this is that many
> optimizations have been performed on the AST (constant folding,
> conditional short circuiting, generate statements processed, etc.).
> Because of this we will only be able to do a functional translation. For
> example you can determine the value of a Verilog parameter in the code
> generator, but you will not find any expressions that reference the
> parameter. Is this restriction a problem for useful VHDL code generation?

I think this is OK. The primary motivation (for me at least) was to generate VHDL suitable for input 
to tools, or for use as a `black box' module in a VHDL design -- ability to understand/modify the 
output is a secondary priority, I think. For this, functional equivalence seems fine.

> 
> 2. There is still functionality missing from the compiler and runtime.
> What is your plan for dealing with this? Is this missing functionality a
> problem for the converter? I believe most of the missing functionality
> either has a bug report or feature request. We may be able to add some of
> this to the compiler and then use code generator checks to protect vvp if
> needed.

The missing functionality isn't a problem as long as none of the programs we choose to evaluate the 
converter on use these features :-). I'll look through the bug and feature list later -- if the 
omissions aren't too major, I would plan to deal with them/workaround if/when I encounter them. If 
some extra functionality needs implementing in the parser/elaborator (and it's not too complex :-) 
then I wouldn't mind helping with that -- I'd get exposure to more of the code base that way too.

> 
> 3. Straight statement conversion is a good start, but keep in mind that
> more efficient code can often be generated when looking at certain
> combinations of statements (patterns). Are the current code generator
> hooks complete enough to perform these type of optimizations?

Yes, this had occurred to me too. A simple implementation would just emit VHDL as (text) when the 
code gen hooks are called, and this would miss a lot of potential optimizations (and it might not 
even be possible to correctly translate some constructions -- e.g. if it would require changes to 
earlier output). A better method might be to build a VHDL abstract syntax tree (or some other 
intermediate representation) in the hooks, and then perform some post-processing on that 
representation before emitting it as text. I *think* the existing code generator hooks will be 
sufficient for this, but I'd need to examine them a bit more closely. Presumably any enhancements 
required to the loadable target API would benefit the other code generators as well.

> 
> 4. Does it make sense to consider the changes added in 1076-2002?

I guess it depends on whether using 1076-2002 features will make the Verilog translation 
significantly simpler/more efficient, and whether that's worth breaking compatibility with tools 
that only support the older standards. The particular VHDL standard to target could perhaps be made 
into a parameter.

> 
> That's all I came up with for now. Once again great job!

Thanks for the comments!

> 
> Cary
> 
> 
>       ____________________________________________________________________________________
> Be a better friend, newshound, and 
> know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Iverilog-devel mailing list
> Ive...@li...
> https://lists.sourceforge.net/lists/listinfo/iverilog-devel