iverilog-devel — Conversations on matters of Icarus Verilog development

[Iverilog-devel] need a language-lawyer ruling and/or a bug fix

[Larry D. <ldo...@re...>]

Guys -

The attached code shows a change in behavior in recent
(as of March 20) git.  It triggered a failure in my
inverse regression test.  I need to know if my Verilog
assumptions are wrong, or the new Icarus behavior is wrong.

iverilog -Wall tern.v -o tern && vvp tern

Used to print out
    x   x
   42  21
But after commit 01eb298228d0adce9d62818e21d47fb274af9060 prints
    x   z
   42  21

  - Larry

[Iverilog-devel] GSoC Application Deadline Extended

[Stephen W. <st...@ic...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


In case there is anyone out there interested is doing a project
for Icarus Verilog via GSoC who has not yet applied, the student
application deadline has been extended to April 7.

- --
Steve Williams                "The woods are lovely, dark and deep.
steve at icarus.com           But I have promises to keep,
http://www.icarus.com         and lines to code before I sleep,
http://www.picturel.com       And lines to code before I sleep."
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFH8lsVrPt1Sc2b3ikRAtycAJ0Qc3PpCFcK4f4OqdagBBzBdZAZAACfYKrQ
uMyv+QpI3zAHytVy6EQe8R0=
=SEK4
-----END PGP SIGNATURE-----

Re: [Iverilog-devel] $monitor/$strobe and friend (pr1780480).

[Stephen W. <st...@ic...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Cary R. wrote:
> --- Stephen Williams <st...@ic...> wrote:
> 
>> Look at all the various kinds of expression nodes are supported
>> by the VPI:-(
> 
> And it's real nice that we can safely ignore them in Icarus :-).
>  
>> That's something like a vpi expression node that supports vpi_get_value
>> by evaluating the expression. Perhaps the code generator can write
>> out the vpi expression nodes and make them available to the system
>> task?
> 
> OK I will think about this.
> 
> One complication so far is do we need to handle special the case when a
> $strobe is called inside a loop that may be changing a variable the
> expression depends on? Something like:
> 
> // $strobe the elements of an array.
> for(idx = 0; idx < 8; idx = idx + 1) begin
>   $strobe(a[idx]);
> end
> #1;
> 
> In this case do we assume the index variable is different for each call
> (is an argument) or is it just a normal expression? I believe the correct
> interpretation is that you will end up with eight strobes all displaying
> the value of a[8]. Thoughts?

I think you are right. Just one of many strange consequences
of $strobe/$monitor.



- --
Steve Williams                "The woods are lovely, dark and deep.
steve at icarus.com           But I have promises to keep,
http://www.icarus.com         and lines to code before I sleep,
http://www.picturel.com       And lines to code before I sleep."
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFH7CHNrPt1Sc2b3ikRAiZLAKDoqyfgCXx93nSlpPLa5WN4pDZ8AgCcCT+H
EIYTXNnsoei4nH5Ujxq8OAA=
=gBti
-----END PGP SIGNATURE-----

Re: [Iverilog-devel] $monitor/$strobe and friend (pr1780480).

[Cary R. <cy...@ya...>]

--- Stephen Williams <st...@ic...> wrote:

> Look at all the various kinds of expression nodes are supported
> by the VPI:-(

And it's real nice that we can safely ignore them in Icarus :-).
 
> That's something like a vpi expression node that supports vpi_get_value
> by evaluating the expression. Perhaps the code generator can write
> out the vpi expression nodes and make them available to the system
> task?

OK I will think about this.

One complication so far is do we need to handle special the case when a
$strobe is called inside a loop that may be changing a variable the
expression depends on? Something like:

// $strobe the elements of an array.
for(idx = 0; idx < 8; idx = idx + 1) begin
  $strobe(a[idx]);
end
#1;

In this case do we assume the index variable is different for each call
(is an argument) or is it just a normal expression? I believe the correct
interpretation is that you will end up with eight strobes all displaying
the value of a[8]. Thoughts?

Cary


      ____________________________________________________________________________________
Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ

Re: [Iverilog-devel] GSoC Proposal Verilog Unit Test

[Cary R. <cy...@ya...>]

--- Rodrigo Peixoto <rod...@gm...> wrote:

> 19            <python_code var="res">lambda a,b: a+b</python_code>

Do you have code that does an implicit sizing of the result or are you
missing a "& 0xfff" in the above equation?

>     a[7:0]     i@|use_mem_file("my_a_memory.mem")

I assume this format precludes the use of random variables since you are
not touching the input vector file.

>     input [15:0] a;

Should these be [7:0] given the previous definitions? My guess is the
[7:0] previously should be [15:0] given the size of the constants.

>From all this I don't see anything that needs to be done to Icarus to
support your test system. I think we are focusing on enhancements to
Icarus itself, not software that uses Icarus. If you are proposing some
enhancements to Icarus I'm missing them, so please explicitly state them.
If Icarus is not processing your output code correctly please submit a bug
report or even better a patch!

Thank you for explaining how your system works.

Cary


      ____________________________________________________________________________________
Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ

Re: [Iverilog-devel] $monitor/$strobe and friend (pr1780480).

[Stephen W. <st...@ic...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Cary R. wrote:
> A recent patch I submitted prevents these from crashing the simulator when
> given calculated values (bits[i]+1, etc.), but they still do not always
> work correctly. The basic problem is that the expressions need to be
> calculated when the system functions run not when they are called. An
> additional problem for $monitor is that any change to this expression
> needs to trigger a cbValueChange call back.

The basic problem is that the way Verilog is defined, if you pass
an expression to a system task/function, the system task will get
a handle to the *expression* and not the value that it evaluates to.
I thought that to be pretty nuts (I still do) but the odd-ball tasks
$strobe and $monitor indirectly rely on that interpretation. Look at
all the various kinds of expression nodes are supported by the VPI:-(

> I believe the $strobe family can be fixed by replacing the code generated
> by draw_eval_* (in tgt-vvp/draw_vpi.c) with some sort of simple anonymous
> function creation and call. It needs scope information to find the correct
> variables but it doesn't need arguments and only has a single return
> value. We may need vector and real versions. These anonymous functions are
> only needed until the $strobe finishes executing.

That's something like a vpi expression node that supports vpi_get_value
by evaluating the expression. Perhaps the code generator can write
out the vpi expression nodes and make them available to the system
task?

> To get $monitor to work correctly the anonymous function needs to get a
> bit smarter. It needs to be able to create cbValueChange call backs for
> all the variables or pieces of a variable it references when it is asked
> to provide a cbValueChange call back. The anonymous functions for $monitor
> would need to be persistent.

VPI expression nodes would be a natural for carrying callbacks. They
can even automatically propagate the calculation.

> Does this sound like a reasonable plan? Any suggestions? Would an
> anonymous and possible temporary continuous assignment be a better
> solution?

I can think of two plausible ways to handle this. One would be to
create VPI expression nodes that reflect the expression, and the
other is to create an implicit user-defined function. The latter is
what I think you are proposing and has the advantage of using the
run time of the behavioral instructions to handle things. Perhaps
the ideal would be to combine the two by generating a VPI expression
node that acts as a handle for that implicit user defined function.
In any case, a vpi handle for this implicit function, even if it
is a private type, would act as an infrastructure for carrying the
callbacks etc.

- --
Steve Williams                "The woods are lovely, dark and deep.
steve at icarus.com           But I have promises to keep,
http://www.icarus.com         and lines to code before I sleep,
http://www.picturel.com       And lines to code before I sleep."
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFH6+FErPt1Sc2b3ikRAtD7AJ9xmunnQS78Wnq00xkKfm7oV/5SMwCg6NKx
aT75vr25xGOSPxfSo6U3XZU=
=Vtoy
-----END PGP SIGNATURE-----

[Iverilog-devel] $monitor/$strobe and friend (pr1780480).

[Cary R. <cy...@ya...>]

A recent patch I submitted prevents these from crashing the simulator when
given calculated values (bits[i]+1, etc.), but they still do not always
work correctly. The basic problem is that the expressions need to be
calculated when the system functions run not when they are called. An
additional problem for $monitor is that any change to this expression
needs to trigger a cbValueChange call back.

I believe the $strobe family can be fixed by replacing the code generated
by draw_eval_* (in tgt-vvp/draw_vpi.c) with some sort of simple anonymous
function creation and call. It needs scope information to find the correct
variables but it doesn't need arguments and only has a single return
value. We may need vector and real versions. These anonymous functions are
only needed until the $strobe finishes executing.

To get $monitor to work correctly the anonymous function needs to get a
bit smarter. It needs to be able to create cbValueChange call backs for
all the variables or pieces of a variable it references when it is asked
to provide a cbValueChange call back. The anonymous functions for $monitor
would need to be persistent.

Does this sound like a reasonable plan? Any suggestions? Would an
anonymous and possible temporary continuous assignment be a better
solution?

FYI once this is implemented we will likely no longer need the scheduled
thread bits deletion so that can be removed.

I believe something similar to this will be needed to fix the
$fscanf/$sscanf problem (pr1876798). The data is propagating the other
way, but the rest is close to what we need for $strobe.

Cary


      ____________________________________________________________________________________
Looking for last minute shopping deals?  
Find them fast with Yahoo! Search.  http://tools.search.yahoo.com/newsearch/category.php?category=shopping

Re: [Iverilog-devel] GSoC Proposal Verilog Unit Test

[Rodrigo P. <rod...@gm...>]

Hi,
I'll try to explain in a good way.
I'm using a 16 bits fulladder as example. It's simple, however can helps
us to understanding the tool. The rule file can be much more complex.
I try to eliminate the reference model putting high level language to
do its function.

Ok let's go.

#############################################
#The 16 bits fulladder rule file should be: #
##############################################################
 1     <vut module_name="fulladder_16bits">
 2      <time_scale t_div="10" unit="ns"/>
 3      <waveform>
 4            =================================================
 5            a[7:0]     i@|0000|0000|ffff|ffff|R1|R3|R4|R3|R2|
 6            -------------------------------------------------
 7            b[7:0]     i@|0000|ffff|0000|ffff|R2|R3|R1|R1|R4|
 8            =================================================
 9            result[7:0]o@|0000|ffff|ffff|0000|...res
10            -------------------------------------------------
11            overflow   o@|0   |0   |0   |1   |...tmp
12            =================================================
13        </waveform>
14        <gen_with>
15            R1 = (0,ff)
16            R2 = (ff,fff)
17            R3 = (fff,1fff)
18            R4 = (1fff,ffff)
19            <python_code var="res">lambda a,b: a+b</python_code>
20            <python_code var="tmp">lambda a,b: (a+b) > 0xffff and 1 or
0</python_code>
21        </gen_with>
22    </vut>
###############################################################
Line 1: Module name

Line 2: Define Timescale

Line 3: Begin waveform behavior definition. The test will be guided
by the defined waveform.
Lines 5,7: Input definition with random values
Lines 9,11: Output definition with random values
Lines 4,6,8,10,12: Ignored

Line 14: Begin the random generation directives
Line 15,16,17,18: Intervals to the random range generation
Line 19,20: Describes the actions that must be executed using
the a:Rx and b:Ry values to fill the result and overflow values.

For example:
    at the 5th time division let's assumes R1=0x13 and R2=0xf4a , so the
    result output will receive R1+R2 (0x13 + 0xf4a) that will be 0xf5d
    and the overflow output will receive 0 (0xf5d < 0xffff).

According the waveform tag it will be create memory files which it will be
used
in the simulations (i_a.mem, i_b.mem, o_result.mem and o_overflow.mem)


########################
#File example i_a.mem: #
############################################
//@This file was generated by VUTGenerator@
//@Do not edit! VUTWarning@

0000
0000
ffff
ffff
0013
100f
acff
b0a0
0800

############################################

Alternatively we can use the follow tag to avoid memory generation:
<waveform>
    =================================================
    a[7:0]     i@|use_mem_file("my_a_memory.mem")
    -------------------------------------------------
    b[7:0]     i@|use_mem_file("my_b_memory.mem")
    =================================================
    result[7:0]o@|0000|ffff|ffff|0000|...res
    -------------------------------------------------
    overflow   o@|0   |0   |0   |1   |...tmp
    =================================================
</waveform>

#############################
#The skeleton Generated is: #
################################################
/*
@The skeleton was generated by VUTGenerator@
=======================================
module_name: fulladder_16bits
---------------------------------------
Author: <author>
Data: <date>
---------------------------------------
Description: <description>
=======================================
*/

module fulladder_16bits(a,b,result,overflow);
//Inputs
    input [15:0] a;
    input [15:0] b;

//Outputs
    output [15:0] result;
    output overflow;

//Wires
    wire [15:0] a;
    wire [15:0] b;

//Regs
    reg [15:0] result;
    reg overflow;

//Behavior


endmodule
################################################
It is generated based in the input and output information passed in the
waveform tag.


##############################
#The TestBench generated is: #
###############################################################

/*
@This UnitTest was generated by VUTGenerator@
@Do not edit! VUTWarning@
=======================================
module_name: vut_fulladder_16bits
---------------------------------------
Author: <author>
Data: <date>
---------------------------------------
Description: <description>
=======================================
*/

module vut_fulladder_16bits();

//Wires
    wire [15:0] result;
    wire overflow;

//Regs
    reg [15:0] a;
    reg [15:0] b;

//Behavior

    reg [15:0] mem_a [0:9];
    reg [15:0] mem_b [0:9];
    reg [15:0] mem_result [0:9];
    reg mem_overflow [0:9];
    reg [15:0] tmp_result;
    reg tmp_overflow;
    integer k;
    event send, ready;

    fulladder_16bits test(
        .a(a),
        .b(b),
        .result(result),
        .overflow(overflow));

    initial $readmemh("i_a.mem",mem_a);
    initial $readmemh("i_b.mem",mem_b);
    initial $readmemh("o_result.mem",mem_result);
    initial $readmemh("o_overflow.mem",mem_overflow);

    initial begin
        $dumpfile ("waveform.vcd");
        $dumpvars;
        #1;
        a = 0;
        b = 0;
        k = 0;
        #4 -> ready;
    end


    always @ ready begin
        a = mem_a[k];
        b = mem_b[k];
        tmp_result = mem_result[k];
        tmp_overflow = mem_overflow[k];
        k = k + 1;
        if (k > 10) begin
            $display("|VUT_OK| > All the signals are right-right!\n");
            #5 $finish;
        end //if
        else #2 -> send;
    end


    always @ send begin
        if (result !== tmp_result) begin
            $display("|VUT_FAIL|> Error in result value at time
%0dns!!!",$time);
            $finish;
        end //if
        if (overflow !== tmp_overflow) begin
            $display("|VUT_FAIL|> Error in overflow value at time
%0dns!!!",$time);
            $finish;
        end //if
        #3 -> ready;
    end

endmodule
###################################################################################

During the simulation, if occur any error, the simulation will stop
and will show the exact error's time.

Example:
    At the 22ns of the simulation the result should be 0x1111 and it is
    0x1110 the simulation will stop and the message "|VUT_FAIL|> Error in
result value at time 22ns!!!"
    will appear.
    In case of the simulation finishes without errors the message
    "|VUT_OK| > All the signals are right-right!" will appear.


Ok, just it..

Is it clear? If not, I can write more, no problem! :)

Thank you all.

If there are any suggestions, doubts or critics go ahead! I'm waiting
feedback! :D

Ps.: Sorry my English..


Best Regards,
===================================================
Rodrigo José Sarmento Peixoto
-----------------------------------------------------------------------------------------------------
UFPE - CIn ( Engenharia da Computacao )
Skype: rodrigopex
msn: rod...@ho...
-----------------------------------------------------------------------------------------------------
Participante dos projetos:
- HPCIn (Petrobras)
- EriMont (Amadeus)
Projeto de extensão: Inclusão digital escola Padre Machado
Membro do CInLUG: www.cinlug-br.org
===================================================

Re: [Iverilog-devel] GSoC Proposal Verilog Unit Test

[Cary R. <cy...@ya...>]

--- Rodrigo Peixoto <rod...@gm...> wrote:

> The tool is already in alpha version. A lot of features will be
> implemented
> this year until June. For example the random stimulus generation, the
> reference model can will be made in a high level language as Python,
> state
> machine tests and so on.
> 
> This tool could be "integrated" with Icarus. When a developer wants to
> design a module can use this tool to generate the module's skeleton and
> its
> UnitTest (Test Bench) according the rule file (described by the user,
> easy
> and fast).
> 
> Do you think really interesting this project participates of the Google
> Summer of Code?

This is too simple of a description for me to understand exactly what you
are proposing. Can you provide an example with possible some pseudo code
to better explain the process. I would also like to know what type of
rules are available and how the skeleton is specified?

Cary


      ____________________________________________________________________________________
Looking for last minute shopping deals?  
Find them fast with Yahoo! Search.  http://tools.search.yahoo.com/newsearch/category.php?category=shopping

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

Re: [Iverilog-devel] Draft GSoC proposal

[Cary R. <cy...@ya...>]

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.

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?

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.

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?

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

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

Cary


      ____________________________________________________________________________________
Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ

[Iverilog-devel] GSoC Proposal Verilog Unit Test

[Rodrigo P. <rod...@gm...>]

Hi all,

my name is Rodrigo Peixoto, I'm Computer Engineer undergraduate student in
Brazil (UFPE- University Federal of Pernambuco).
Nowadays I'm developing a tool that generates Verilog Unit Tests according
to a rule file.
This is my graduation conclusion work and perhaps will be the theme of my
Master dissertation.

The tool is already in alpha version. A lot of features will be implemented
this year until June. For example the random stimulus generation, the
reference model can will be made in a high level language as Python, state
machine tests and so on.

This tool could be "integrated" with Icarus. When a developer wants to
design a module can use this tool to generate the module's skeleton and its
UnitTest (Test Bench) according the rule file (described by the user, easy
and fast).

Do you think really interesting this project participates of the Google
Summer of Code?


Best Regards,
===================================================
Rodrigo José Sarmento Peixoto
-----------------------------------------------------------------------------------------------------
UFPE - CIn ( Engenharia da Computacao )
Skype: rodrigopex
msn: rod...@ho...
-----------------------------------------------------------------------------------------------------
Participante dos projetos:
- HPCIn (Petrobras)
- EriMont (Amadeus)
Projeto de extensão: Inclusão digital escola Padre Machado
Membro do CInLUG: www.cinlug-br.org
===================================================

Re: [Iverilog-devel] Draft GSoC proposal

[Stephen W. <st...@ic...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Excellent draft. If your project is accepted, we may choose to
pin a few things down even more, like take a week for you to put
together a set of sample programs and give you a rough schedule
for getting through them.

But as I see it, this application is ready to submit. Well done!

Nick Gasson wrote:
> Hi,
> 
> I've written a draft SoC proposal. Would you mind having a quick look at it before I submit it? 
> Feedback appreciated :-).
> 
> Thanks a lot,
> Nick
> 
> --------------
> 
> 
> == Abstract ==
> 
> I propose to build a VHDL code generator for Icarus Verilog. This is based on a
> project idea from [1]. A VHDL code generator will allow Icarus Verilog to be
> used as a Verilog to VHDL translator. Benefits include:
> * Verilog libraries and designs can be used in VHDL-only projects without the
>    expense of manually rewriting the code.
> * Systems developed with Icarus Verilog can be used with tools that only accept
>    VHDL.
> There is clearly demand for this sort of functionality as at least one
> proprietary tool already exists [2].
> 
> The VHDL produced will conform to a standard (probably VHDL93 as this is most
> widely available) and not use any proprietary extensions, so the output is
> compatible with as many tools as possible.
> 
> I would aim for as much coverage of the Verilog language as possible. However,
> some features such as VPI will probably be impossible to support in VHDL.
> 
> Ideally, the VHDL produced should be pretty-printed and human-readable. This
> will allow it to be maintained and modified independently of the original
> Verilog.
> 
> Additionally, I will modify the build system/wrapper program to insert the git
> commit id or tag in the -V output. (This is the final project from [1].)
> 
> == Deliverables ==
> 
> * A new VHDL code generator that can be run with -tvhdl (implemented in C, with
>    sources under tgt-vhdl in the git repository). The code generator will
>    produce VHDL modules corresponding to the Verilog abstract syntax passed to
>    the code generator. When simulated or synthesised, the VHDL should behave
>    identically (wherever possible) to the Verilog it was generated from.
> * Updates to configuration files and build scripts to support the new code
>    generator.
> * Any VHDL packages required to support the generated code.
> * Set of unit tests and application-level tests to demonstrate the correct
>    operation of the code generator.
> * Updates to the documentation and man page to document the new code generator.
> * Changes to the build system to support displaying the git commit id (or
>    corresponding tag) in the -V output.
> 
> == Plan ==
> 
> I will initially work on the git commit id project, as looking at the build
> system is a good way to learn about the code base. I do not expect this to take
> too long, but I will need to learn a bit more about git first (I have some
> limited experience already).
> 
> Icarus Verilog has a well-defined loadable target API that insulates code
> generators from the rest of the compiler: this means the project will be
> relatively self-contained.
> 
> For many Verilog constructs there is an obvious mapping to VHDL (e.g. initial and
> always -> processes) and many of the operators and data types are
> similar. However, some Verilog features are not found in VHDL and will require a
> more complex translation (e.g. the Verilog reduction operators would need to be
> implemented by a loop in VHDL), and some features might be quite difficult to
> translate (e.g. the Verilog fork/join construct will require some thought). In
> order to make progress and produce useful code at regular intervals, I will
> work incrementally, starting with the easy language features and progressing to
> the more complex ones. I expect most of the core Verilog features to have a
> quite natural and straightforward translation, particularly those in the
> synthesisable subset.
> 
> Only a subset of Verilog (and VHDL) is synthesisable. The synthesisable subsets
> of both languages contain simpler constructions than found in the complete
> language, so it would make sense to work on this first. I would aim to have a
> reasonably complete translation of synthesisable Verilog by the midterm
> evaluation. To evaluate this, iverilog would be run on `real' synthesisable
> Verilog code (for example, the AES core at [3]) producing VHDL, which should
> synthesise in a tool such as Xilinx XST.
> 
> For the second half of the project, I would concentrate on the simulation-only
> constructs (which I expect will be somewhat harder to translate). This would be
> successful if a Verilog testbench could be translated to a valid VHDL testbench
> (probably using the same OpenCores project to evaluate).
> 
> Throughout the project I will develop a set of automated tests (using a VHDL
> simulator) to verify the output generated is correct.
> 
> == Availability ==
> 
> I have university commitments until the end of May, but otherwise I am free to
> work on SoC throughout the summer and into September. However, I am moving house
> at the end of June which may cause some disruption and intermittent internet
> access for a few weeks (although I should be able to keep working on the project
> during this period).
> 
> I will treat the project as a full time job: I expect to spend approximately 37
> hours a week working on it.
> 
> == About me ==
> 
> I'm in the final year of a 4-year Computer Systems and Software Engineering
> degree at the University of York (UK). After graduating, I'm hoping to study for
> a PhD in real-time systems.
> 
> Relevant industrial experience:
> * July 2005 - August 2006: Placement year at IBM United Kingdom, Hursley
>    -> Developed test automation frameworks for IBM middleware products.
> * Summer 2007: Internship in Dept. of Comp. Sci. at University of York
>    -> Worked in the AI group on information retrieval systems.
> 
> Relevant skills:
> * Good background in digital electronics, embedded systems, and FPGA design in
>    particular.
> * Lots of experience developing FPGA applications in VHDL (and Handel-C).
> * Basic knowledge of Verilog (although I have time to improve this if I am
>    accepted for SoC).
> * Lots of experience in C/C++ programming
> * Good knowledge of Perl, shell script, AWK, etc.
> * I have some experience managing build systems with GNU autotools.
> * Basic working knowledge of git.
> 
> == References ==
> 
> [1] http://iverilog.wikia.com/wiki/Projects
> [2] http://www.ascinc.com/products/verilog2vhdl/
> [3] http://www.opencores.org/projects.cgi/web/aes_core/overview
> 
> -------------------------------------------------------------------------
> 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
> 


- --
Steve Williams                "The woods are lovely, dark and deep.
steve at icarus.com           But I have promises to keep,
http://www.icarus.com         and lines to code before I sleep,
http://www.picturel.com       And lines to code before I sleep."
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFH58JHrPt1Sc2b3ikRAhurAKCr+0OOXbECY8NnVujj6bVTSQmnCwCgjzDj
6Z4JzUXWkKfo8lbjQY8NMWo=
=y4iE
-----END PGP SIGNATURE-----

Re: [Iverilog-devel] Draft GSoC proposal

[Cary R. <cy...@ya...>]

--- Nick Gasson <nm...@yo...> wrote:

> Would you mind having a quick look at it before I submit it? 

My initial reaction is well done! I will look over it in more detail later
today and get my feedback to you on Monday. Keep in mind Steve and I are
eight hours behind you (PST).

Cary


      ____________________________________________________________________________________
Never miss a thing.  Make Yahoo your home page. 
http://www.yahoo.com/r/hs

[Iverilog-devel] Draft GSoC proposal

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

Hi,

I've written a draft SoC proposal. Would you mind having a quick look at it before I submit it? 
Feedback appreciated :-).

Thanks a lot,
Nick

--------------


== Abstract ==

I propose to build a VHDL code generator for Icarus Verilog. This is based on a
project idea from [1]. A VHDL code generator will allow Icarus Verilog to be
used as a Verilog to VHDL translator. Benefits include:
* Verilog libraries and designs can be used in VHDL-only projects without the
   expense of manually rewriting the code.
* Systems developed with Icarus Verilog can be used with tools that only accept
   VHDL.
There is clearly demand for this sort of functionality as at least one
proprietary tool already exists [2].

The VHDL produced will conform to a standard (probably VHDL93 as this is most
widely available) and not use any proprietary extensions, so the output is
compatible with as many tools as possible.

I would aim for as much coverage of the Verilog language as possible. However,
some features such as VPI will probably be impossible to support in VHDL.

Ideally, the VHDL produced should be pretty-printed and human-readable. This
will allow it to be maintained and modified independently of the original
Verilog.

Additionally, I will modify the build system/wrapper program to insert the git
commit id or tag in the -V output. (This is the final project from [1].)

== Deliverables ==

* A new VHDL code generator that can be run with -tvhdl (implemented in C, with
   sources under tgt-vhdl in the git repository). The code generator will
   produce VHDL modules corresponding to the Verilog abstract syntax passed to
   the code generator. When simulated or synthesised, the VHDL should behave
   identically (wherever possible) to the Verilog it was generated from.
* Updates to configuration files and build scripts to support the new code
   generator.
* Any VHDL packages required to support the generated code.
* Set of unit tests and application-level tests to demonstrate the correct
   operation of the code generator.
* Updates to the documentation and man page to document the new code generator.
* Changes to the build system to support displaying the git commit id (or
   corresponding tag) in the -V output.

== Plan ==

I will initially work on the git commit id project, as looking at the build
system is a good way to learn about the code base. I do not expect this to take
too long, but I will need to learn a bit more about git first (I have some
limited experience already).

Icarus Verilog has a well-defined loadable target API that insulates code
generators from the rest of the compiler: this means the project will be
relatively self-contained.

For many Verilog constructs there is an obvious mapping to VHDL (e.g. initial and
always -> processes) and many of the operators and data types are
similar. However, some Verilog features are not found in VHDL and will require a
more complex translation (e.g. the Verilog reduction operators would need to be
implemented by a loop in VHDL), and some features might be quite difficult to
translate (e.g. the Verilog fork/join construct will require some thought). In
order to make progress and produce useful code at regular intervals, I will
work incrementally, starting with the easy language features and progressing to
the more complex ones. I expect most of the core Verilog features to have a
quite natural and straightforward translation, particularly those in the
synthesisable subset.

Only a subset of Verilog (and VHDL) is synthesisable. The synthesisable subsets
of both languages contain simpler constructions than found in the complete
language, so it would make sense to work on this first. I would aim to have a
reasonably complete translation of synthesisable Verilog by the midterm
evaluation. To evaluate this, iverilog would be run on `real' synthesisable
Verilog code (for example, the AES core at [3]) producing VHDL, which should
synthesise in a tool such as Xilinx XST.

For the second half of the project, I would concentrate on the simulation-only
constructs (which I expect will be somewhat harder to translate). This would be
successful if a Verilog testbench could be translated to a valid VHDL testbench
(probably using the same OpenCores project to evaluate).

Throughout the project I will develop a set of automated tests (using a VHDL
simulator) to verify the output generated is correct.

== Availability ==

I have university commitments until the end of May, but otherwise I am free to
work on SoC throughout the summer and into September. However, I am moving house
at the end of June which may cause some disruption and intermittent internet
access for a few weeks (although I should be able to keep working on the project
during this period).

I will treat the project as a full time job: I expect to spend approximately 37
hours a week working on it.

== About me ==

I'm in the final year of a 4-year Computer Systems and Software Engineering
degree at the University of York (UK). After graduating, I'm hoping to study for
a PhD in real-time systems.

Relevant industrial experience:
* July 2005 - August 2006: Placement year at IBM United Kingdom, Hursley
   -> Developed test automation frameworks for IBM middleware products.
* Summer 2007: Internship in Dept. of Comp. Sci. at University of York
   -> Worked in the AI group on information retrieval systems.

Relevant skills:
* Good background in digital electronics, embedded systems, and FPGA design in
   particular.
* Lots of experience developing FPGA applications in VHDL (and Handel-C).
* Basic knowledge of Verilog (although I have time to improve this if I am
   accepted for SoC).
* Lots of experience in C/C++ programming
* Good knowledge of Perl, shell script, AWK, etc.
* I have some experience managing build systems with GNU autotools.
* Basic working knowledge of git.

== References ==

[1] http://iverilog.wikia.com/wiki/Projects
[2] http://www.ascinc.com/products/verilog2vhdl/
[3] http://www.opencores.org/projects.cgi/web/aes_core/overview

Re: [Iverilog-devel] Google SoC 2008!

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

Thanks for the information, I'll draft a proposal over the weekend.


Stephen Williams wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Nick Gasson wrote:
>   
>> Hi all,
>>
>> I'm interested in working on Icarus Verilog as part of Summer of Code. 
>> In particular I'm interested in building a VHDL plug-in code generator 
>> to get a Verilog to VHDL translator (as per the projects wiki). This is 
>> actually a problem I've encountered in real life -- when I've wanted to 
>> use Verilog components in a VHDL system. Since it'll be a back-end code 
>> generator, it should stay clear of a lot of the more complex VHDL 
>> constructs, so hopefully this will be manageable as a summer project. 
>> I'd like to focus on getting the synthesisable subset working first, as 
>> I think this would be the most useful.
>>
>> I'm a final-year Computer Systems and Software Engineering student at 
>> the University of York (UK). I've got quite a bit of experience in VHDL 
>> (mostly designs for Xilinx FPGAs) and the usual C/C++ (I have some 
>> industrial experience with these). Unfortunately I don't really have any 
>> Verilog knowledge beyond the usual introduction/tutorials, but I should 
>> be able to pick it up pretty rapidly (and this project doesn't seem too 
>> Verilog-y).
>>
>> If this sounds reasonable I'll have a go at drafting a project proposal. 
>> Is there anything you're looking for in particular on the application?
>>     
>
> We're looking for an indication that you really can do what you propose
> to do. We will use clues such as your apparent understanding of what
> the project you propose actually *is*.
>
> Some idea of a schedule, that looks reasonable to us, will help. Include
> a schedule of your availability so that we can judge that your plan
> fits. Note that some interruption in your GSoC is OK if we know it up
> front, but is *not* OK if we find out about it later.
>
> Because payments are involved, it would be good to clearly state
> proposed "victory conditions": A sample program that you want to
> work, a verifiable set of features, something like that. That helps
> us mentors come evaluation time.
>
>   
>> I also volunteer to do the git version strings project :-)
>>     
>
> We're also expecting a candidate to understand (or learn in a
> hurry) git. Looks like you got a jump there.
>
> We're also hoping to use the GSoC process to attract long-term
> developers. We want people to come here to learn, participate,
> and _remain_ with us in the long term. Google's stated purpose for
> throwing money at us is to attract people to the open source community
> who will then stay. This is about learning how the open source
> "system" works, with a little motivation to get over the hump.
>
> - --
> Steve Williams                "The woods are lovely, dark and deep.
> steve at icarus.com           But I have promises to keep,
> http://www.icarus.com         and lines to code before I sleep,
> http://www.picturel.com       And lines to code before I sleep."
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2 (GNU/Linux)
> Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org
>
> iD8DBQFH4TENrPt1Sc2b3ikRArz+AKCIJJZZocOtHCzncYtlpWFJ5AjGdACfXL11
> ZPXlxfkaPI2udFkEQNLNVhE=
> =GtNw
> -----END PGP SIGNATURE-----
>
> -------------------------------------------------------------------------
> 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
>   

Re: [Iverilog-devel] Google SoC 2008!

[Stephen W. <st...@ic...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Nick Gasson wrote:
> Hi all,
> 
> I'm interested in working on Icarus Verilog as part of Summer of Code. 
> In particular I'm interested in building a VHDL plug-in code generator 
> to get a Verilog to VHDL translator (as per the projects wiki). This is 
> actually a problem I've encountered in real life -- when I've wanted to 
> use Verilog components in a VHDL system. Since it'll be a back-end code 
> generator, it should stay clear of a lot of the more complex VHDL 
> constructs, so hopefully this will be manageable as a summer project. 
> I'd like to focus on getting the synthesisable subset working first, as 
> I think this would be the most useful.
> 
> I'm a final-year Computer Systems and Software Engineering student at 
> the University of York (UK). I've got quite a bit of experience in VHDL 
> (mostly designs for Xilinx FPGAs) and the usual C/C++ (I have some 
> industrial experience with these). Unfortunately I don't really have any 
> Verilog knowledge beyond the usual introduction/tutorials, but I should 
> be able to pick it up pretty rapidly (and this project doesn't seem too 
> Verilog-y).
> 
> If this sounds reasonable I'll have a go at drafting a project proposal. 
> Is there anything you're looking for in particular on the application?

We're looking for an indication that you really can do what you propose
to do. We will use clues such as your apparent understanding of what
the project you propose actually *is*.

Some idea of a schedule, that looks reasonable to us, will help. Include
a schedule of your availability so that we can judge that your plan
fits. Note that some interruption in your GSoC is OK if we know it up
front, but is *not* OK if we find out about it later.

Because payments are involved, it would be good to clearly state
proposed "victory conditions": A sample program that you want to
work, a verifiable set of features, something like that. That helps
us mentors come evaluation time.

> I also volunteer to do the git version strings project :-)

We're also expecting a candidate to understand (or learn in a
hurry) git. Looks like you got a jump there.

We're also hoping to use the GSoC process to attract long-term
developers. We want people to come here to learn, participate,
and _remain_ with us in the long term. Google's stated purpose for
throwing money at us is to attract people to the open source community
who will then stay. This is about learning how the open source
"system" works, with a little motivation to get over the hump.

- --
Steve Williams                "The woods are lovely, dark and deep.
steve at icarus.com           But I have promises to keep,
http://www.icarus.com         and lines to code before I sleep,
http://www.picturel.com       And lines to code before I sleep."
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFH4TENrPt1Sc2b3ikRArz+AKCIJJZZocOtHCzncYtlpWFJ5AjGdACfXL11
ZPXlxfkaPI2udFkEQNLNVhE=
=GtNw
-----END PGP SIGNATURE-----

Re: [Iverilog-devel] Google SoC 2008!

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

Hi all,

I'm interested in working on Icarus Verilog as part of Summer of Code. 
In particular I'm interested in building a VHDL plug-in code generator 
to get a Verilog to VHDL translator (as per the projects wiki). This is 
actually a problem I've encountered in real life -- when I've wanted to 
use Verilog components in a VHDL system. Since it'll be a back-end code 
generator, it should stay clear of a lot of the more complex VHDL 
constructs, so hopefully this will be manageable as a summer project. 
I'd like to focus on getting the synthesisable subset working first, as 
I think this would be the most useful.

I'm a final-year Computer Systems and Software Engineering student at 
the University of York (UK). I've got quite a bit of experience in VHDL 
(mostly designs for Xilinx FPGAs) and the usual C/C++ (I have some 
industrial experience with these). Unfortunately I don't really have any 
Verilog knowledge beyond the usual introduction/tutorials, but I should 
be able to pick it up pretty rapidly (and this project doesn't seem too 
Verilog-y).

If this sounds reasonable I'll have a go at drafting a project proposal. 
Is there anything you're looking for in particular on the application?

I also volunteer to do the git version strings project :-)

Thanks a lot
Nick

[Iverilog-devel] Google SoC 2008!

[Stephen W. <st...@ic...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


It's that time of year again, for the Google Summer of Code. We've
officially been accepted as a GSoC project under the gEDA umbrella.
If you are a student looking for a summer project that contributes
to universal well being as well as your academics,
Go here: <http://code.google.com/soc/2008/>

You won't find an Icarus Verilog project in the list of all the
mentoring organizations, look instead for "The gEDA Project".
We are as usual allying ourselves with the larger gEDA project
because of the overlap that often occurs. The gEDA pages link
back to us, and the gEDA ideas page has a link to the Icarus Verilog
Projects page.

And by the way, if you have project suggestions, that's a good
place to put them.

- --
Steve Williams                "The woods are lovely, dark and deep.
steve at icarus.com           But I have promises to keep,
http://www.icarus.com         and lines to code before I sleep,
http://www.picturel.com       And lines to code before I sleep."
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFH3ymTrPt1Sc2b3ikRAtt/AKCY0NWWzVXE4YjJWQoRBYINdc5hMQCdH5d3
QcPaLHMGMfhroIFtKNOJSn0=
=nukb
-----END PGP SIGNATURE-----

Re: [Iverilog-devel] Potential rework of nets/wires support in VVP

[Cary R. <cy...@ya...>]

--- Stephen Williams <st...@ic...> wrote:

> Cary R. wrote:
> > --- Stephen Williams <st...@ic...> wrote:
> > 
> >> Add to that switch level modeling such as tranif* and rtran*. These
> >> are odd devices in that they are bidirectional. The resistive
> >> devices in particular escape me. (I was kinda holding off on
> resistive
> >> transistors to see if the problem goes away when AMS support gets
> >> figured out.)
> > 
> > Once we have multi output gates, or maybe that should be multi inout
> > gates, implementing these should not be too hard to code. If you were
> to
> > do multi output gates I would think implementing a multi output buffer
> and
> > one of the rtran gates would be enough to allow someone else to build
> the
> > rest. Is it the need or the implementation that is escaping you?
> 
> It is the implementation that is escaping me. I'm not even clear
> how a rtran resolves its inputs and generates it outputs.

I'm not sure if this is feasible or not, but would tagging the propagating
signal with the source help (a pointer to the driver object)? Only the
tran/rtran gates would retag a signal and would only propagate signals
they did not send. There is still the possibility of multiple gates
creating a loop, but that problem already exists. As a bonus, having a
usable tag would also allow us to print error messages that could point to
the driver when something goes wrong.

So something like this: the tran receives a signal on inout1 it retags the
signal making it the driver and sends the modified signal to the net
connected to inout2. It will receive a signal back on inout2, but since it
is the driver of this signal it will be ignored.
 
> > Unless you are hoping that a future version of Verilog-D removes these
> > gates we still have missing functionality. 
> 
> We have missing functionality. Even if Verilog-D does drop them,
> I have delusions of Verilog-AMS in the future and I suspect similar
> problems will turn up there.

Yes, at the digital-analog interface you could have the same problem. 
 
> That kind of complexity is already handled by the existing delay
> objects. Multiple specify path objects feed into a given delay
> node, and they are in turn used to calculate the given delay for
> logic that flows through the delay.

I didn't realize the existing delay objects were that powerful.

Cary


      ____________________________________________________________________________________
Never miss a thing.  Make Yahoo your home page. 
http://www.yahoo.com/r/hs

Re: [Iverilog-devel] OpenSPARCT2.1.0 compiles/elaborates with only one line changed

[Stephen W. <st...@ic...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Michael Witten wrote:
> On 15 Mar 2008, at 11:53 AM, Stephen Williams wrote:
> 
>> I cannot overstate the importance of critical sets of eyes bearing
>> down on things dispassionately. That's what keeps things on course.
> 
> dispassionately?

Dispassionately: without emotional attachment to the thing being
judged - fairly or rationally.

- --
Steve Williams                "The woods are lovely, dark and deep.
steve at icarus.com           But I have promises to keep,
http://www.icarus.com         and lines to code before I sleep,
http://www.picturel.com       And lines to code before I sleep."
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFH3Th4rPt1Sc2b3ikRAvRrAJ4gE8+X3Axfj+ofTcq6eypx3JBLGACeJh4/
OtkqLv/7w4MLi76s3DXeCa8=
=kiax
-----END PGP SIGNATURE-----

Re: [Iverilog-devel] Potential rework of nets/wires support in VVP

[Stephen W. <st...@ic...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Cary R. wrote:
> --- Stephen Williams <st...@ic...> wrote:
> 
>> Add to that switch level modeling such as tranif* and rtran*. These
>> are odd devices in that they are bidirectional. The resistive
>> devices in particular escape me. (I was kinda holding off on resistive
>> transistors to see if the problem goes away when AMS support gets
>> figured out.)
> 
> Once we have multi output gates, or maybe that should be multi inout
> gates, implementing these should not be too hard to code. If you were to
> do multi output gates I would think implementing a multi output buffer and
> one of the rtran gates would be enough to allow someone else to build the
> rest. Is it the need or the implementation that is escaping you?

It is the implementation that is escaping me. I'm not even clear
how a rtran resolves its inputs and generates it outputs.

> Unless you are hoping that a future version of Verilog-D removes these
> gates we still have missing functionality. 

We have missing functionality. Even if Verilog-D does drop them,
I have delusions of Verilog-AMS in the future and I suspect similar
problems will turn up there.

>> I think that net delays can be understood in term of vvp_net nodes.
>> In particular, one can find ways to attach delays between drivers
>> of nets and the nets themselves. It may be possible to handle this
>> in the elaborator by propagating the net delays to the delays of
>> all the driving expressions, but putting a .delay node in place
>> is probably the best way of handling it. Specify delays for module
>> ports are handled this way.
> 
> Basic net delays may be that simple, but the ones from a SDF file are
> certainly not. As I remember it, net delays can be unique from any driver
> to any receiver, so they cannot be implemented by just inserting simple
> delays at the driver and/or receiver. So there are two net delay concepts,
> one which is a single constant value specified in the language and the
> other is provided in the SDF file which is likely not matched to a net
> that was defined to have a net delay in the source Verilog file. To me
> this implies that net delays need to be fundamental to the net handling
> code.

That kind of complexity is already handled by the existing delay
objects. Multiple specify path objects feed into a given delay
node, and they are in turn used to calculate the given delay for
logic that flows through the delay.

>> Actually, the vvp_net infrastructure inside vvp is probably the
>> cleanest and easiest to understand aspect of the vvp runtime:-)
> 
> I guess that shows how little I have looked at it.



- --
Steve Williams                "The woods are lovely, dark and deep.
steve at icarus.com           But I have promises to keep,
http://www.icarus.com         and lines to code before I sleep,
http://www.picturel.com       And lines to code before I sleep."
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFH3TeErPt1Sc2b3ikRArguAJ9vnOmYita4kMzttH6h7PQcy9Pz7gCcDpKH
Yy36Nlf/3k2+fGDAkf3xCDI=
=eU5k
-----END PGP SIGNATURE-----

Re: [Iverilog-devel] OpenSPARCT2.1.0 compiles/elaborates with only one line changed

[Michael W. <mfw...@MI...>]

On 15 Mar 2008, at 11:53 AM, Stephen Williams wrote:

> I cannot overstate the importance of critical sets of eyes bearing
> down on things dispassionately. That's what keeps things on course.

dispassionately?

Re: [Iverilog-devel] OpenSPARCT2.1.0 compiles/elaborates with only one line changed

[Cary R. <cy...@ya...>]

--- Stephen Williams <st...@ic...> wrote:
 
> > iverilog -c t2.inpfile -s cpu takes ~30min and needs 8.5Gb, 
> > a.out takes 6 min and 4.5GB.
> 
> Thanks for these results. Yeah, the performance issues kinda sting
> when I'm reminded, so we need to gradually start giving them more
> attention. As Icarus Verilog gets ever more complete and bug free,
> people throw ever larger designs at it. In some cases, the limiting
> factor for adoption is no longer its completeness but its performance:-O

That must not be much of a runtime test! The runtime has always been the
slowest part for me.

I have ideas on how to improve both the compilation and runtime
performance. It's just finding enough time to working on them. The problem
lately, and it's mostly a good one, is that the more improvements we do
the more bug reports we seem to be getting. I try to fix the easy ones as
they come in, but like Steve said we could really use a couple more core
developers.

If anyone is interested and has some spare time I have a bunch of changes
that I would like to do to the system functions (vpi directory) that are
not very hard. Most of it is better error messages using the new file and
line information along with some better argument checking. I have been
saving this as an easy task to do once I'm done, note I didn't say
finished, with the expression code. I'm willing to provide guidance on
what I think needs to be done if anyone is interested.

Cary


      ____________________________________________________________________________________
Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ 

Re: [Iverilog-devel] Potential rework of nets/wires support in VVP

[Cary R. <cy...@ya...>]

--- Stephen Williams <st...@ic...> wrote:

> Add to that switch level modeling such as tranif* and rtran*. These
> are odd devices in that they are bidirectional. The resistive
> devices in particular escape me. (I was kinda holding off on resistive
> transistors to see if the problem goes away when AMS support gets
> figured out.)

Once we have multi output gates, or maybe that should be multi inout
gates, implementing these should not be too hard to code. If you were to
do multi output gates I would think implementing a multi output buffer and
one of the rtran gates would be enough to allow someone else to build the
rest. Is it the need or the implementation that is escaping you?

Unless you are hoping that a future version of Verilog-D removes these
gates we still have missing functionality. 
 
> I think that net delays can be understood in term of vvp_net nodes.
> In particular, one can find ways to attach delays between drivers
> of nets and the nets themselves. It may be possible to handle this
> in the elaborator by propagating the net delays to the delays of
> all the driving expressions, but putting a .delay node in place
> is probably the best way of handling it. Specify delays for module
> ports are handled this way.

Basic net delays may be that simple, but the ones from a SDF file are
certainly not. As I remember it, net delays can be unique from any driver
to any receiver, so they cannot be implemented by just inserting simple
delays at the driver and/or receiver. So there are two net delay concepts,
one which is a single constant value specified in the language and the
other is provided in the SDF file which is likely not matched to a net
that was defined to have a net delay in the source Verilog file. To me
this implies that net delays need to be fundamental to the net handling
code.

> Actually, the vvp_net infrastructure inside vvp is probably the
> cleanest and easiest to understand aspect of the vvp runtime:-)

I guess that shows how little I have looked at it.

Cary


      ____________________________________________________________________________________
Never miss a thing.  Make Yahoo your home page. 
http://www.yahoo.com/r/hs