iverilog-devel — Conversations on matters of Icarus Verilog development

Re: [Iverilog-devel] error: duplicate declaration for net or variable

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

Martin -

On Sun, Jun 07, 2015 at 09:17:14AM +0100, Martin Whitaker wrote:
> Larry Doolittle wrote:
> > These are simply Verilog-2005 ports that get a specification of
> > wire or reg in the module body.
> > I'm pretty sure this is supposed to be "Perfectly Legal Verilog".
> Indeed it is. I thought I'd covered all the bases when fixing the duplicate 
> name detection, but there are just too many ways of declaring ports in Verilog :-(
> Anyway, I've pushed a fix for this. Thanks for spotting it.

Thanks for fixing this so fast!
Now today's iverilog git master (commit 4068c172) and
today's yosys git master (commit de4f4dad) play nicely together.

  - Larry

Re: [Iverilog-devel] library unisim; use unisim.vcomponents.all;

[Maciej S. <mac...@ce...>]

On 06/06/2015 06:55 AM, Larry Doolittle wrote:
> That still leaves my questions about std_ulogic and
> case-insensitivity.

As Cary suggested, I can add a patch for a configuration entry to change
letter case to either upper or lower. Preserving the original case might
be also an option, but then it can cause troubles if someone takes
advantage of VHDL's case-insensitivity.

I guess for std_ulogic the closest counterpart is "uwire logic" when it
comes to nets, but I am not sure what would be appropriate for
variables. If someone has an idea, I can also add it, this should not be
a very complex change.

Regards,
Orson

[Iverilog-devel] patch for format_vpiStringVal

[Fabrizio F. <fab...@po...>]

Dears,


Playing with strings and $fopen I discovered a possible bug of format_vpiStringVal in vpi_signal.cc.

This function seems to convert all 0s in spaces. This creates problems when a signal is used as first parameter of $fopen and when the signal size is greater than the filename to be open. I've changed the code leaving the space conversion for middle zeros but I've removed the trailing ones.

Here it is the git diff:

diff --git a/vvp/vpi_signal.cc b/vvp/vpi_signal.cc
index 552fb49..331b6c1 100644
--- a/vvp/vpi_signal.cc
+++ b/vvp/vpi_signal.cc
@@ -368,6 +368,7 @@ static void format_vpiStringVal(vvp_signal_value*sig, int base, unsigned wid,
         don't form an 8 bit group. */
       char *rbuf = (char *) need_result_buf(wid/8 + ((wid&7)!=0) + 1, RBUF_VAL);
       char *cp = rbuf;
+      char *last_non_null=rbuf;

       char tmp = 0;
       for (long idx = base+(signed)wid-1; idx >= base; idx -= 1) {
@@ -385,10 +386,11 @@ static void format_vpiStringVal(vvp_signal_value*sig, int base, unsigned wid,

                  /* Nulls in the middle get turned into spaces. */
                  *cp++ = tmp ? tmp : ' ';
+                  last_non_null = tmp ? cp : last_non_null;
                  tmp = 0;
            }
       }
-      *cp++ = 0;
+      *last_non_null = 0;

       vp->value.str = rbuf;
 }

Cheers,

Fabrizio

Re: [Iverilog-devel] error: duplicate declaration for net or variable

[Martin W. <mai...@ma...>]

Larry Doolittle wrote:
> These are simply Verilog-2005 ports that get a specification of
> wire or reg in the module body.  Abridged version of the first example,
> that's enough to trigger the error:
>
> module MyMem #(parameter DataWidth = 4) (
>    output [DataWidth-1:0] Data_o);
>    reg [DataWidth-1:0] Data_o;
> endmodule
>
> I'm pretty sure this is supposed to be "Perfectly Legal Verilog".
>
Indeed it is. I thought I'd covered all the bases when fixing the duplicate 
name detection, but there are just too many ways of declaring ports in Verilog :-(

I am surprised that there wasn't a single example like this in the test suite.

Anyway, I've pushed a fix for this. Thanks for spotting it.

Martin

[Iverilog-devel] error: duplicate declaration for net or variable

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

Friends -

I've seen announcements about yosys
  http://www.clifford.at/yosys/
and I thought I'd finally check it out.  I like their
attention to testing, and they use Icarus for those tests.

Two of its simple tests get tripped up with current git Icarus.
No need to actually build yosys (takes 12 minutes on my laptop)
to verify this, just check it out from git and

$ cd tests/simple
$ iverilog mem_arst.v
mem_arst.v:13: error: duplicate declaration for net or variable 'Data_o' in 'MyMem'.
$ iverilog memory.v
memory.v:141: error: duplicate declaration for net or variable 'rst' in 'memtest06_sync'.
memory.v:160: error: duplicate declaration for net or variable 'rst' in 'memtest06_async'.

These are simply Verilog-2005 ports that get a specification of
wire or reg in the module body.  Abridged version of the first example,
that's enough to trigger the error:

module MyMem #(parameter DataWidth = 4) (
  output [DataWidth-1:0] Data_o);
  reg [DataWidth-1:0] Data_o;
endmodule

I'm pretty sure this is supposed to be "Perfectly Legal Verilog".

  - Larry

Re: [Iverilog-devel] library unisim; use unisim.vcomponents.all;

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

Cary -

On Sat, Jun 06, 2015 at 04:08:22PM -0700, Larry Doolittle wrote:
> On Sat, Jun 06, 2015 at 08:47:56PM +0000, Cary R. wrote:
> > I suppose you could argue all items in the module since most things can be accessed using various scoping rules. Though only the interface should be enough for most real examples.

Xilinx and its customers consider the module name, generics,
and ports to be an API.  I've _never_ heard about anyone reaching 
into their simulations, or even talk about it.  That is not even
possible for synthesizable code, which is the focus of this VHDL work.

Just trying to agree as strongly as possible.

  - Larry

Re: [Iverilog-devel] library unisim; use unisim.vcomponents.all;

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

Cary -

On Sat, Jun 06, 2015 at 08:47:56PM +0000, Cary R. wrote:
> Would adding an option to the VHDL config file for a given module to emit it/just the interface as upper or lower case solve your problem. I would assume the default would be lower case like we currently do. By interface I am assuming parameters, ports and the actual module name. I suppose you could argue all items in the module since most things can be accessed using various scoping rules. Though only the interface should be enough for most real examples.

Of 10766 parameter names in Xilinx XST 12.1 Verilog unisims, only
26 are not all-caps, and a spot check of those show they are
not part of the API.

Out of ~17117 generics and ports in unisim_VCOMP.vhd, 11 are not all-caps.
Eight of those are in one pathological component (selfheal_oserdese1_vhd).

Out of 1118 components listed in unisim_VCOMP.vhd, only four names are not
all-caps (bscntrl_iserdese1_vhd, ice_iserdese1_vhd, plg_oserdese1_vhd,
selfheal_oserdese1_vhd).

So, yes.

Maybe more work, but arguably better, would be to be case-retentive
based on the component declaration.  No need for configuration.

  - Larry

Re: [Iverilog-devel] library unisim; use unisim.vcomponents.all;

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

Would adding an option to the VHDL config file for a given module to emit it/just the interface as upper or lower case solve your problem. I would assume the default would be lower case like we currently do. By interface I am assuming parameters, ports and the actual module name. I suppose you could argue all items in the module since most things can be accessed using various scoping rules. Though only the interface should be enough for most real examples.
 


     On Friday, June 5, 2015 10:31 PM, Larry Doolittle <ldo...@re...> wrote:
   

 Orson -

Just talking to myself on a Friday night, I guess.

On Fri, Jun 05, 2015 at 09:55:41PM -0700, Larry Doolittle wrote:
> On Fri, Jun 05, 2015 at 08:51:18PM -0700, Larry Doolittle wrote:
> > I'm still struggling to understand how to connect a .vhd file
> > that says
> > library unisim;
> >  use unisim.vcomponents.all;
> > with all the component declarations in
> > $XILINX/vhdl/src/unisims/unisim_VCOMP.vhd
> If I can figure out how to pass "-L foo" to vhdlpp,
> I think I can get through this step.

Create a what.cfg file containing
+vhdl-libdir+foo
and then a normal iverilog invocation (with the -cwhat.cfg option)
processes the file
>  foo/unisim/vcomponents.pkg

> And if that file is a (trimmed down and hacked) copy
> of $XILINX/vhdl/src/unisims/unisim_VCOMP.vhd, it seems
> to emit the Verilog I'm looking for.
> That still leaves my questions about std_ulogic and
> case-insensitivity.

The VHDL preprocessor correctly handles case-insensitive
matches between the component declaration and the instantiation.
But the Verilog it emits has the instantiation's name, ports, and
parameters/generics all converted to lower case.  This does
not match the implementation in $XILINX/verilog/src/unisims/*.v.
In fact Xilinx seems to have "standardized" on upper case for
all those names.  So the compilation as a whole fails.

I guess this is an artifact of trying to use the Verilog unisims;
if there were a chance that all the test-bench-like constructs
in their VHDL unisims would be accepted by iverilog/vhdlpp,
the case-insensitive match (as implemented by converting all VHDL
identifiers to lower case in the emitted Verilog) would work fine.

  - Larry

------------------------------------------------------------------------------
_______________________________________________
Iverilog-devel mailing list
Ive...@li...
https://lists.sourceforge.net/lists/listinfo/iverilog-devel


  

Re: [Iverilog-devel] library unisim; use unisim.vcomponents.all;

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

Orson -

Just talking to myself on a Friday night, I guess.

On Fri, Jun 05, 2015 at 09:55:41PM -0700, Larry Doolittle wrote:
> On Fri, Jun 05, 2015 at 08:51:18PM -0700, Larry Doolittle wrote:
> > I'm still struggling to understand how to connect a .vhd file
> > that says
> > library unisim;
> >   use unisim.vcomponents.all;
> > with all the component declarations in
> > $XILINX/vhdl/src/unisims/unisim_VCOMP.vhd
> If I can figure out how to pass "-L foo" to vhdlpp,
> I think I can get through this step.

Create a what.cfg file containing
+vhdl-libdir+foo
and then a normal iverilog invocation (with the -cwhat.cfg option)
processes the file
>   foo/unisim/vcomponents.pkg

> And if that file is a (trimmed down and hacked) copy
> of $XILINX/vhdl/src/unisims/unisim_VCOMP.vhd, it seems
> to emit the Verilog I'm looking for.
> That still leaves my questions about std_ulogic and
> case-insensitivity.

The VHDL preprocessor correctly handles case-insensitive
matches between the component declaration and the instantiation.
But the Verilog it emits has the instantiation's name, ports, and
parameters/generics all converted to lower case.  This does
not match the implementation in $XILINX/verilog/src/unisims/*.v.
In fact Xilinx seems to have "standardized" on upper case for
all those names.  So the compilation as a whole fails.

I guess this is an artifact of trying to use the Verilog unisims;
if there were a chance that all the test-bench-like constructs
in their VHDL unisims would be accepted by iverilog/vhdlpp,
the case-insensitive match (as implemented by converting all VHDL
identifiers to lower case in the emitted Verilog) would work fine.

   - Larry

Re: [Iverilog-devel] library unisim; use unisim.vcomponents.all;

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

Orson -

On Fri, Jun 05, 2015 at 08:51:18PM -0700, Larry Doolittle wrote:
> I'm still struggling to understand how to connect a .vhd file
> that says
> library unisim;
>   use unisim.vcomponents.all;
> with all the component declarations in
> $XILINX/vhdl/src/unisims/unisim_VCOMP.vhd

If I can figure out how to pass "-L foo" to vhdlpp,
I think I can get through this step.  When I add that
to a by-hand invocation of vhdlpp, I can follow along
and get it to process the file
  foo/unisim/vcomponents.pkg
And if that file is a (trimmed down and hacked) copy
of $XILINX/vhdl/src/unisims/unisim_VCOMP.vhd, it seems
to emit the Verilog I'm looking for.

That still leaves my questions about std_ulogic and
case-insensitivity.

   - Larry

[Iverilog-devel] library unisim; use unisim.vcomponents.all;

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

Orson -

I'm still struggling to understand how to connect a .vhd file
that says

library unisim;
  use unisim.vcomponents.all;

with all the component declarations in

$XILINX/vhdl/src/unisims/unisim_VCOMP.vhd

and from there to the Verilog unisim implementations in
$XILINX/verilog/src/unisims/*.v.

We talked before, and I'm pretty sure that last step is
a better option than the VHDL unisim implementations in
$XILINX/vhdl/src/unisims/primitive/*.vhd.

Do you have this working?  Can you give me a recipe, or
hint, or anything?

BTW,
iverilog -g2005-sv $XILINX/vhdl/src/unisims/unisim_VCOMP.vhd
crashes and burns badly.  Hundreds of
Can't find type name `std_ulogic'
among other things.

I'm still fumbling around, maybe making a little progress.
Isn't VHDL supposed to be case-insensitive?  I can't get
an instantiation of ibufds to match a component IBUFDS.

   - Larry

Re: [Iverilog-devel] Time in VHDL

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

I mentioned something like this earlier. I believe Orson, needs a custom system function that scales time that is inserted into any translated code where a passed time value is used in VHDL.
Using the code he provided:
module mod(input time a);
  timeunit 1ns;
  timeprecision 1ps;

  always @(a) begin
    // this should happen after 2ns
    #(a + 1ns) $display("this message should appear first (time=%t)", $time());
  end
endmodule
The #(a+1ns) would be translated to something like: #($ivl_VHDL_scale_time(a)+1ns). To match Verilog like semantics the scaling would use the local time unit and precision but that may not match the VHDL semantics so maybe it is just scaled using the local unit and global precision. I am assuming the @(a) reference would also be scaled, but depending on exactly how VHDL does the time scaling this may or may not be correct (e.g. depending on the precision of the module a change in a may not trigger a change in the @() expression because of the rounding done using the $ivl_VHDL_scale_time() function if the local precision is used. The scaling would be done using the current scope calling time unit and the time unit of the caller. If a time value was passed over multiple levels this would result in a call to the function at each level.
I believe this implementation would make VHDL to VHDL and Verilog to VHDL calls work out of the box. VHDL to Verilog and possibly some Verilog to Verilog calls would require the user to scale the values, but the system function would make this mostly trivial other than remembering to use it. I expect this is a fairly obscure case so a well documented custom system function seems acceptable.
What I don't understand is the exact semantics of how VHDL handles these time variables so I'm making some assumptions that may not be correct.

 


     On Friday, June 5, 2015 12:49 PM, Stephen Williams <st...@ic...> wrote:
   

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


That shares the literal bits that are the time value, but it
does not account for the semantics of time. If it did, it would
scale time values to local units as they cross module boundaries.
That is the crux of the problem that Orson is facing.

On 06/05/2015 12:24 PM, Martin Whitaker wrote:
> Stephen Williams wrote:
>> You are pointing out a problem with VERILOG and not VHDL vs.
>> Verilog. In Verilog, time values do not cross module boundaries
>> through ports. Doing so will get you the headaches that you see.
>> Fixing it will involve extending the verilog language.
>> 
> The SystemVerilog committee has already done this for you. See
> section 23.3.3 of 1800-2012:
> 
> "Values of all data types on variables and nets can be passed
> through ports. This is accomplished by allowing both sides of a
> port connection to have assignment-compatible data types and by
> allowing continuous assignments to variables."
> 
> So it is now legal to declare:
> 
> module m(input time t);
> 
> You can also declare:
> 
> module m(ref time t);
> 
> which lets you share a common variable.
> 
> Martin
> 
> ------------------------------------------------------------------------------
>
> 
_______________________________________________
> 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 v2

iEYEARECAAYFAlVx/Q8ACgkQrPt1Sc2b3inIcACcC/7OfbA8m0H6rwnTEfM9373C
wK8AnR6I3Ykl3pdzG8a/6OaodNWXMELG
=fUjY
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
_______________________________________________
Iverilog-devel mailing list
Ive...@li...
https://lists.sourceforge.net/lists/listinfo/iverilog-devel


  

Re: [Iverilog-devel] Time in VHDL

[Martin W. <mai...@ma...>]

Stephen Williams wrote:
> That shares the literal bits that are the time value, but it
> does not account for the semantics of time. If it did, it would
> scale time values to local units as they cross module boundaries.
> That is the crux of the problem that Orson is facing.
>
As I wrote before, the 'time' data type has no special semantics in Verilog - 
it's just a 64-bit vector.

We have already identified a solution to the scaling problem - just make sure 
that all translated VHDL code has the same time units. Then you can safely 
pass time values between modules using the 'time' data type.

Of course you will run into problems if you pass time values to native Verilog 
modules which have their own (different) timescale - but that's a problem 
inherent in Verilog, and not one I think we should be trying to fix.

Martin

Re: [Iverilog-devel] Time in VHDL

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

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


That shares the literal bits that are the time value, but it
does not account for the semantics of time. If it did, it would
scale time values to local units as they cross module boundaries.
That is the crux of the problem that Orson is facing.

On 06/05/2015 12:24 PM, Martin Whitaker wrote:
> Stephen Williams wrote:
>> You are pointing out a problem with VERILOG and not VHDL vs.
>> Verilog. In Verilog, time values do not cross module boundaries
>> through ports. Doing so will get you the headaches that you see.
>> Fixing it will involve extending the verilog language.
>> 
> The SystemVerilog committee has already done this for you. See
> section 23.3.3 of 1800-2012:
> 
> "Values of all data types on variables and nets can be passed
> through ports. This is accomplished by allowing both sides of a
> port connection to have assignment-compatible data types and by
> allowing continuous assignments to variables."
> 
> So it is now legal to declare:
> 
> module m(input time t);
> 
> You can also declare:
> 
> module m(ref time t);
> 
> which lets you share a common variable.
> 
> Martin
> 
> ------------------------------------------------------------------------------
>
> 
_______________________________________________
> 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 v2

iEYEARECAAYFAlVx/Q8ACgkQrPt1Sc2b3inIcACcC/7OfbA8m0H6rwnTEfM9373C
wK8AnR6I3Ykl3pdzG8a/6OaodNWXMELG
=fUjY
-----END PGP SIGNATURE-----

Re: [Iverilog-devel] Time in VHDL

[Martin W. <mai...@ma...>]

Stephen Williams wrote:
> You are pointing out a problem with VERILOG and not VHDL vs. Verilog.
> In Verilog, time values do not cross module boundaries through ports.
> Doing so will get you the headaches that you see. Fixing it will
> involve extending the verilog language.
>
The SystemVerilog committee has already done this for you. See section 23.3.3 
of 1800-2012:

"Values of all data types on variables and nets can be passed through ports. 
This is accomplished by allowing both sides of a port connection to have 
assignment-compatible data types and by allowing continuous assignments to 
variables."

So it is now legal to declare:

   module m(input time t);

You can also declare:

   module m(ref time t);

which lets you share a common variable.

Martin

Re: [Iverilog-devel] Time in VHDL

[Martin W. <mai...@ma...>]

Stephen Williams wrote:
> Define a command line flag for VHDL compilation that sets the default
> VHDL precision. Let Verilog/SystemVerilog get its precision by its
> own means. The vhdlpp generated modules all have the default  VHDL
> time precision, and enforces this by timeprecision and timeunits
> module items. These are supposed to override Verilog `time* directives
> within the scope of the module at hand.
>
> The Verilog semantics for precision are that the elaborator finds
> the highest precision needed and uses that as the global precision.
> All time literals are scaled from units to precision by the compiler.
>
> These semantics should just work. I'm still not understanding what
> the problem is.
>
I was allowing for the case that a user might choose to translate VHDL files 
in advance, then choose a time precision at the time they compiled and 
elaborated the translated files. Your solution requires them to have chosen 
the (same) time precision when the VHDL files are translated. But maybe I'm 
allowing for something that won't get used in practice.

Martin

Re: [Iverilog-devel] Time in VHDL

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

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


You are pointing out a problem with VERILOG and not VHDL vs. Verilog.
In Verilog, time values do not cross module boundaries through ports.
Doing so will get you the headaches that you see. Fixing it will
involve extending the verilog language.

If we want to fix it (and I don't know if we do) then the way to do
that is to create a new extension type (i.e. $precise_time) that
converts assignments in from the local time units to run-time
precision, and read outs from simulation precision to local time
units. Or you can hand code that behavior with system tasks.

My point is that I think you've done what you can. You can't go
mussing with the time units of other modules so you are stuck.
Just don't pass times through ports unless you manually convert
them to the run-time precision, and host the consumer of that time
does the same.

On 06/02/2015 12:22 PM, Maciej Sumiński wrote:
> On 06/01/2015 09:57 PM, Stephen Williams wrote:
>> 
>> How 'bout this...
>> 
>> Define a command line flag for VHDL compilation that sets the
>> default VHDL precision. Let Verilog/SystemVerilog get its
>> precision by its own means. The vhdlpp generated modules all have
>> the default  VHDL time precision, and enforces this by
>> timeprecision and timeunits module items. These are supposed to
>> override Verilog `time* directives within the scope of the module
>> at hand.
>> 
>> The Verilog semantics for precision are that the elaborator
>> finds the highest precision needed and uses that as the global
>> precision. All time literals are scaled from units to precision
>> by the compiler.
>> 
>> These semantics should just work. I'm still not understanding
>> what the problem is.
> 
> It might be not only the problem of precision (actually I think 
> precision does not cause any issues here), but the time units used
> in modules.
> 
> I am far from calling myself a SystemVerilog expert, so I may need
> some guidance. What do you think about the following example?
> 
> ------------------------------------ orson@pc ~/workspace $ cat
> time3.v module mod(input time a); timeunit 1ns; timeprecision 1ps;
> 
> always @(a) begin // this should happen after 2ns #(a + 1ns)
> $display("this message should appear first (time=%t)", $time()); 
> end endmodule
> 
> module mod_test; timeunit 1ps; timeprecision 1ps;
> 
> time a; mod dut(a);
> 
> initial begin a <= 1ns; // this should happen after 100ns #(100ns)
> $display("this message should appear second (time=%t)", $time()); 
> end endmodule
> 
> orson@pc ~/workspace $ iverilog -g2005-sv time3.v orson@pc
> ~/workspace $ vvp a.out this message should appear second (time=
> 100000) this message should appear first (time=
> 1001000) ------------------------------------
> 
> I would expect different behaviour, even though timeprecision is
> the same in both modules. I see it this way: 1. The first line time
> value (100000) is simply 100ns expressed in ps, no magic here. 2.
> "a <= 1ns" converts 1ns to time units, so it becames an integer
> equal 1000 (time units, picoseconds in this case). 3. mod receives
> 1000 and scales it using its own units, here it becomes 1000 ns.
> This step I consider problematic, but apparently it is correct 
> according to SV standard. 4. Second line is displayed after 1001
> ns, using the requested precision, hence 1001000 ps.
> 
> As I mentioned previously, I removed all commits that influenced
> time scale and I am completely fine with it, as suggested method
> with +timescale parameter works for me.
> 
> If there is such will request, I may implement one of the proposed 
> solutions, but my gut feeling tells me it will not change much in
> this matter, unless every module uses the same time unit.
> 
> Regards, Orson
> 
>> On 06/01/2015 12:11 PM, Martin Whitaker wrote:
>>> Cary R. wrote:
>>>> I have not looked at your pull request, but from what I am 
>>>> reading you may have added code that addresses one of our
>>>> older feature requests on SourceForge so please look at them.
>>>> I think `resetall may be a bit heavy handed since it will
>>>> change the timescale, etc. that future modules/files will
>>>> see. It seems like the more localized SV additions would be
>>>> best for setting the scale and precision for only the
>>>> translated modules.
>> 
>>> Well, if future files depend on what's gone before, they're 
>>> fundamentally broken, as nothing guarantees the order in which 
>>> files are read.
>> 
>>> But to summarise what I wrote yesterday:
>> 
>>> - VHDL has a global time resolution that applies to the entire
>>>  elaborated design - by default this is 1fs - the VHDL
>>> standard allows for the user to override the default - all
>>> simulators I've looked at support this via a configuration file
>>> or command line option
>> 
>>> I think we need to do the same.
>> 
>>> If people don't like `resetall, then I propose the following 
>>> alternative:
>> 
>>> - as an Icarus extension, allow the special value 'vhdl' to be
>>> used in SV timeunit and timeprecision declarations - set the
>>> default units and precision for vhdl to 1fs - allow the
>>> +timescale option to override these defaults
>> 
>>> We could use 'default' rather than 'vhdl' and use the existing 
>>> default timescale values, but then I'd want to change the
>>> initial defaults.
>> 
>>> Martin
>> 
>>> ------------------------------------------------------------------------------
>>
>>
>>
>>> 
_______________________________________________
>>> Iverilog-devel mailing list
>>> Ive...@li... 
>>> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
>> 
>> 
>> 
>> 
>> ------------------------------------------------------------------------------
>>
>> 
_______________________________________________
>> Iverilog-devel mailing list Ive...@li... 
>> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
>> 
> 
> 
> 
> 
> ------------------------------------------------------------------------------
>
> 
> 
> 
> _______________________________________________ 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 v2

iEYEARECAAYFAlVuGRgACgkQrPt1Sc2b3ill/wCeNgWEG5/Zh95QGmUBFxdFt0YC
dHAAniw5dF6MGAoVBzllEUyeV4MdpLy2
=RY8l
-----END PGP SIGNATURE-----

Re: [Iverilog-devel] Time in VHDL

[Maciej S. <mac...@ce...>]

On 06/01/2015 09:57 PM, Stephen Williams wrote:
> 
> How 'bout this...
> 
> Define a command line flag for VHDL compilation that sets the default
> VHDL precision. Let Verilog/SystemVerilog get its precision by its
> own means. The vhdlpp generated modules all have the default  VHDL
> time precision, and enforces this by timeprecision and timeunits
> module items. These are supposed to override Verilog `time* directives
> within the scope of the module at hand.
> 
> The Verilog semantics for precision are that the elaborator finds
> the highest precision needed and uses that as the global precision.
> All time literals are scaled from units to precision by the compiler.
> 
> These semantics should just work. I'm still not understanding what
> the problem is.

It might be not only the problem of precision (actually I think
precision does not cause any issues here), but the time units used in
modules.

I am far from calling myself a SystemVerilog expert, so I may need some
guidance. What do you think about the following example?

------------------------------------
orson@pc ~/workspace $ cat time3.v
module mod(input time a);
  timeunit 1ns;
  timeprecision 1ps;

  always @(a) begin
    // this should happen after 2ns
    #(a + 1ns) $display("this message should appear first (time=%t)",
$time());
  end
endmodule

module mod_test;
  timeunit 1ps;
  timeprecision 1ps;

  time a;
  mod dut(a);

  initial begin
    a <= 1ns;
    // this should happen after 100ns
    #(100ns) $display("this message should appear second (time=%t)",
$time());
  end
endmodule

orson@pc ~/workspace $ iverilog -g2005-sv time3.v
orson@pc ~/workspace $ vvp a.out
this message should appear second (time=              100000)
this message should appear first (time=             1001000)
------------------------------------

I would expect different behaviour, even though timeprecision is the
same in both modules. I see it this way:
1. The first line time value (100000) is simply 100ns expressed in ps,
no magic here.
2. "a <= 1ns" converts 1ns to time units, so it becames an integer equal
1000 (time units, picoseconds in this case).
3. mod receives 1000 and scales it using its own units, here it becomes
1000 ns. This step I consider problematic, but apparently it is correct
according to SV standard.
4. Second line is displayed after 1001 ns, using the requested
precision, hence 1001000 ps.

As I mentioned previously, I removed all commits that influenced time
scale and I am completely fine with it, as suggested method with
+timescale parameter works for me.

If there is such will request, I may implement one of the proposed
solutions, but my gut feeling tells me it will not change much in this
matter, unless every module uses the same time unit.

Regards,
Orson

> On 06/01/2015 12:11 PM, Martin Whitaker wrote:
>> Cary R. wrote:
>>> I have not looked at your pull request, but from what I am
>>> reading you may have added code that addresses one of our older
>>> feature requests on SourceForge so please look at them. I think
>>> `resetall may be a bit heavy handed since it will change the
>>> timescale, etc. that future modules/files will see. It seems like
>>> the more localized SV additions would be best for setting the
>>> scale and precision for only the translated modules.
> 
>> Well, if future files depend on what's gone before, they're
>> fundamentally broken, as nothing guarantees the order in which
>> files are read.
> 
>> But to summarise what I wrote yesterday:
> 
>> - VHDL has a global time resolution that applies to the entire 
>> elaborated design - by default this is 1fs - the VHDL standard
>> allows for the user to override the default - all simulators I've
>> looked at support this via a configuration file or command line
>> option
> 
>> I think we need to do the same.
> 
>> If people don't like `resetall, then I propose the following
>> alternative:
> 
>> - as an Icarus extension, allow the special value 'vhdl' to be used
>> in SV timeunit and timeprecision declarations - set the default
>> units and precision for vhdl to 1fs - allow the +timescale option
>> to override these defaults
> 
>> We could use 'default' rather than 'vhdl' and use the existing
>> default timescale values, but then I'd want to change the initial
>> defaults.
> 
>> Martin
> 
>> ------------------------------------------------------------------------------
> 
> 
> _______________________________________________
>> Iverilog-devel mailing list Ive...@li... 
>> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
> 
> 
> 
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> Iverilog-devel mailing list
> Ive...@li...
> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
> 

Re: [Iverilog-devel] Time in VHDL

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

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


How 'bout this...

Define a command line flag for VHDL compilation that sets the default
VHDL precision. Let Verilog/SystemVerilog get its precision by its
own means. The vhdlpp generated modules all have the default  VHDL
time precision, and enforces this by timeprecision and timeunits
module items. These are supposed to override Verilog `time* directives
within the scope of the module at hand.

The Verilog semantics for precision are that the elaborator finds
the highest precision needed and uses that as the global precision.
All time literals are scaled from units to precision by the compiler.

These semantics should just work. I'm still not understanding what
the problem is.

On 06/01/2015 12:11 PM, Martin Whitaker wrote:
> Cary R. wrote:
>> I have not looked at your pull request, but from what I am
>> reading you may have added code that addresses one of our older
>> feature requests on SourceForge so please look at them. I think
>> `resetall may be a bit heavy handed since it will change the
>> timescale, etc. that future modules/files will see. It seems like
>> the more localized SV additions would be best for setting the
>> scale and precision for only the translated modules.
> 
> Well, if future files depend on what's gone before, they're
> fundamentally broken, as nothing guarantees the order in which
> files are read.
> 
> But to summarise what I wrote yesterday:
> 
> - VHDL has a global time resolution that applies to the entire 
> elaborated design - by default this is 1fs - the VHDL standard
> allows for the user to override the default - all simulators I've
> looked at support this via a configuration file or command line
> option
> 
> I think we need to do the same.
> 
> If people don't like `resetall, then I propose the following
> alternative:
> 
> - as an Icarus extension, allow the special value 'vhdl' to be used
> in SV timeunit and timeprecision declarations - set the default
> units and precision for vhdl to 1fs - allow the +timescale option
> to override these defaults
> 
> We could use 'default' rather than 'vhdl' and use the existing
> default timescale values, but then I'd want to change the initial
> defaults.
> 
> Martin
> 
> ------------------------------------------------------------------------------
>
> 
_______________________________________________
> 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 v2

iEYEARECAAYFAlVsuRMACgkQrPt1Sc2b3imxhACeK57IA566tilSJp0Iq1dUbb0k
erMAoM6DDuzq9lp+jbmwSqLsfeO6k93k
=7cGW
-----END PGP SIGNATURE-----

Re: [Iverilog-devel] Time in VHDL

[Martin W. <mai...@ma...>]

Cary R. wrote:
> I have not looked at your pull request, but from what I am reading you may
> have added code that addresses one of our older feature requests on
> SourceForge so please look at them. I think `resetall may be a bit heavy
> handed since it will change the timescale, etc. that future modules/files
> will see. It seems like the more localized SV additions would be best for
> setting the scale and precision for only the translated modules.

Well, if future files depend on what's gone before, they're fundamentally 
broken, as nothing guarantees the order in which files are read.

But to summarise what I wrote yesterday:

   - VHDL has a global time resolution that applies to the entire
     elaborated design
   - by default this is 1fs
   - the VHDL standard allows for the user to override the default
   - all simulators I've looked at support this via a configuration
     file or command line option

I think we need to do the same.

If people don't like `resetall, then I propose the following alternative:

   - as an Icarus extension, allow the special value 'vhdl' to be
     used in SV timeunit and timeprecision declarations
   - set the default units and precision for vhdl to 1fs
   - allow the +timescale option to override these defaults

We could use 'default' rather than 'vhdl' and use the existing default 
timescale values, but then I'd want to change the initial defaults.

Martin

Re: [Iverilog-devel] Time in VHDL

[Martin W. <mai...@ma...>]

Maciej Sumiński wrote:
> I could not find it described explicitly in the standard, but there are
> fragments that make me think that time is just a real number that stores
> count of time units, rounded to requested precision:
> - table 21-8, entry for 't' input field
> - reverse reasoning is explained in the second half of 22.7
>
Small correction. 'time' is just an unsigned integer number (at least 64 bits 
in standard Verilog, exactly 64 bits in SystemVerilog). 'realtime' is just a 
real number.

> I guess '#1ns' statement should introduce the same delay in every
> module, but transferring time between modules is simply sending a number
> without any units.
>
Exactly right.

Martin

Re: [Iverilog-devel] Time in VHDL

[Maciej S. <mac...@ce...>]

On 06/01/2015 06:17 PM, Stephen Williams wrote:
> 
> Yeah. Ugh. Time scales.
> 
> What should happen (I think) is that during elaboration the compiler
> chooses from all the precisions a single global precision for the
> whole simulation.

That is true, the SV-2012 standard says exactly this in 3.14.3.

Then within each module scope the local time scale
> is used to convert times to the global precision. So 1ns should be
> 1ns anywhere in the design, and should be represented by the same
> numeric value.

I am not sure about this. Martin has checked the example with the 3
major simulators and got the same result (1001). I checked Modelsim and
Riviera-PRO and got identical output.

I could not find it described explicitly in the standard, but there are
fragments that make me think that time is just a real number that stores
count of time units, rounded to requested precision:
- table 21-8, entry for 't' input field
- reverse reasoning is explained in the second half of 22.7

I guess '#1ns' statement should introduce the same delay in every
module, but transferring time between modules is simply sending a number
without any units.

Perhaps that is why FPGA ICs are still limited to logic outputs and
noone has invented a technology to transfer time between chips.

Regards,
Orson

> Am I wrong about any of this?
> 
> On 06/01/2015 09:09 AM, Maciej Sumiński wrote:
>> On 06/01/2015 05:28 PM, Stephen Williams wrote: On 06/01/2015 08:16
>> AM, Maciej Sumiński wrote:
>>>>> All I need is to use the same timescale in simulated modules.
>>>>> For the moment there is no constraint coming from the modules
>>>>> I am trying to simulate, so even without introducing any
>>>>> changes regarding the timescale in vhdlpp I am still going to
>>>>> be content. Simply setting a sensible default timescale will
>>>>> work for me.
> 
>> If you only need your specific timescale to apply to your modules, 
>> then you should use a module specific timescale. The problem with 
>> the `resetall directive it that the consequences leak out of your 
>> modules to the rest of the design, and affect more than timescale. 
>> Writing your own `timescale directive also leaks out of your
>> modules into the design at a whole, in unpleasant ways. I think
>> that the timescale of VHDL code should not effect the timescale of
>> Verilog code, so you need to do something that has better scope
>> rules.
> 
>> It is perfectly OK, even expected, that modules have different 
>> timescales, it's just that the `timescale directive is horrible and
>> that is why SystemVerilog added the timescale module item. The
>> scoping rules for that timescale are rational.
> 
>> What it may come down to is that every module you generate has a
>> timescale module item.
> 
>>> That is true, but the problem for me appeared when trying to
>>> simulate modules with time-typed ports. The following file still
>>> has the same problem:
> 
>>> -------------------------------------- module mod(input time a); 
>>> timeunit 1ns; timeprecision 1ns; always @(a) begin #(a + 1ns)
>>> $display($time); end endmodule
> 
>>> module mod_test; timeunit 1ps; timeprecision 1ps; time a; mod
>>> dut(a); initial begin a = 1ns; end endmodule 
>>> --------------------------------------
> 
>>> The issue here seems to be caused by incompatibility between SV
>>> and VHDL standards. For modules with time-typed ports the only
>>> way to go is to use the same timescale for every module. The
>>> modules I am trying to simulate do not have imposed any
>>> timescale, therefore I am free to apply a default setting via a
>>> configuration file.
> 
>>> In the end I removed the commits that introduce any changes to 
>>> timescale. Initially I thought they may help, but now I agree
>>> they have become a great source of confusion and potential
>>> troubles. Instead I simply added a configuration file for the
>>> test to set the timescale, so it is the same way I am going to
>>> proceed with my project.
> 
>>> Regards, Orson
> 
>> Note, BTW, that there is a difference between timescale and
>> precision. Note also that there is not really a big performance
>> consequence for having too much precision in Icarus Verilog, due to
>> the way it operates its event queue.
> 
>>>
>>> ------------------------------------------------------------------------------
>>>
>>>
> _______________________________________________
>>> Iverilog-devel mailing list Ive...@li... 
>>> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
>>>
> 
> 
> 
> 
>> ------------------------------------------------------------------------------
> 
> 
> 
> 
>> _______________________________________________ Iverilog-devel
>> mailing list Ive...@li... 
>> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
> 
> 
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> Iverilog-devel mailing list
> Ive...@li...
> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
> 

Re: [Iverilog-devel] Time in VHDL

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

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


Yeah. Ugh. Time scales.

What should happen (I think) is that during elaboration the compiler
chooses from all the precisions a single global precision for the
whole simulation. Then within each module scope the local time scale
is used to convert times to the global precision. So 1ns should be
1ns anywhere in the design, and should be represented by the same
numeric value.

Am I wrong about any of this?

On 06/01/2015 09:09 AM, Maciej Sumiński wrote:
> On 06/01/2015 05:28 PM, Stephen Williams wrote: On 06/01/2015 08:16
> AM, Maciej Sumiński wrote:
>>>> All I need is to use the same timescale in simulated modules.
>>>> For the moment there is no constraint coming from the modules
>>>> I am trying to simulate, so even without introducing any
>>>> changes regarding the timescale in vhdlpp I am still going to
>>>> be content. Simply setting a sensible default timescale will
>>>> work for me.
> 
> If you only need your specific timescale to apply to your modules, 
> then you should use a module specific timescale. The problem with 
> the `resetall directive it that the consequences leak out of your 
> modules to the rest of the design, and affect more than timescale. 
> Writing your own `timescale directive also leaks out of your
> modules into the design at a whole, in unpleasant ways. I think
> that the timescale of VHDL code should not effect the timescale of
> Verilog code, so you need to do something that has better scope
> rules.
> 
> It is perfectly OK, even expected, that modules have different 
> timescales, it's just that the `timescale directive is horrible and
> that is why SystemVerilog added the timescale module item. The
> scoping rules for that timescale are rational.
> 
> What it may come down to is that every module you generate has a
> timescale module item.
> 
>> That is true, but the problem for me appeared when trying to
>> simulate modules with time-typed ports. The following file still
>> has the same problem:
> 
>> -------------------------------------- module mod(input time a); 
>> timeunit 1ns; timeprecision 1ns; always @(a) begin #(a + 1ns)
>> $display($time); end endmodule
> 
>> module mod_test; timeunit 1ps; timeprecision 1ps; time a; mod
>> dut(a); initial begin a = 1ns; end endmodule 
>> --------------------------------------
> 
>> The issue here seems to be caused by incompatibility between SV
>> and VHDL standards. For modules with time-typed ports the only
>> way to go is to use the same timescale for every module. The
>> modules I am trying to simulate do not have imposed any
>> timescale, therefore I am free to apply a default setting via a
>> configuration file.
> 
>> In the end I removed the commits that introduce any changes to 
>> timescale. Initially I thought they may help, but now I agree
>> they have become a great source of confusion and potential
>> troubles. Instead I simply added a configuration file for the
>> test to set the timescale, so it is the same way I am going to
>> proceed with my project.
> 
>> Regards, Orson
> 
> Note, BTW, that there is a difference between timescale and
> precision. Note also that there is not really a big performance
> consequence for having too much precision in Icarus Verilog, due to
> the way it operates its event queue.
> 
>> 
>> ------------------------------------------------------------------------------
>>
>> 
_______________________________________________
>> Iverilog-devel mailing list Ive...@li... 
>> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
>> 
> 
> 
> 
> 
> ------------------------------------------------------------------------------
>
> 
> 
> 
> _______________________________________________ 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 v2

iEYEARECAAYFAlVshbEACgkQrPt1Sc2b3imgrACgiI/PZcK7XDkCAU8+LYoFSVqQ
fCoAn1OE4Gpn32q1lW8GpvPGrCMteQ0i
=bi2S
-----END PGP SIGNATURE-----

Re: [Iverilog-devel] Time in VHDL

[Maciej S. <mac...@ce...>]

On 06/01/2015 05:28 PM, Stephen Williams wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 06/01/2015 08:16 AM, Maciej Sumiński wrote:
>> All I need is to use the same timescale in simulated modules. For
>> the moment there is no constraint coming from the modules I am
>> trying to simulate, so even without introducing any changes
>> regarding the timescale in vhdlpp I am still going to be content.
>> Simply setting a sensible default timescale will work for me.
> 
> If you only need your specific timescale to apply to your modules,
> then you should use a module specific timescale. The problem with
> the `resetall directive it that the consequences leak out of your
> modules to the rest of the design, and affect more than timescale.
> Writing your own `timescale directive also leaks out of your modules
> into the design at a whole, in unpleasant ways. I think that the
> timescale of VHDL code should not effect the timescale of Verilog
> code, so you need to do something that has better scope rules.
> 
> It is perfectly OK, even expected, that modules have different
> timescales, it's just that the `timescale directive is horrible
> and that is why SystemVerilog added the timescale module item.
> The scoping rules for that timescale are rational.
> 
> What it may come down to is that every module you generate has
> a timescale module item.

That is true, but the problem for me appeared when trying to simulate
modules with time-typed ports. The following file still has the same
problem:

--------------------------------------
module mod(input time a);
  timeunit 1ns;
  timeprecision 1ns;
  always @(a) begin
    #(a + 1ns) $display($time);
  end
endmodule

module mod_test;
  timeunit 1ps;
  timeprecision 1ps;
  time a;
  mod dut(a);
  initial begin
    a = 1ns;
  end
endmodule
--------------------------------------

The issue here seems to be caused by incompatibility between SV and VHDL
standards. For modules with time-typed ports the only way to go is to
use the same timescale for every module. The modules I am trying to
simulate do not have imposed any timescale, therefore I am free to apply
a default setting via a configuration file.

In the end I removed the commits that introduce any changes to
timescale. Initially I thought they may help, but now I agree they have
become a great source of confusion and potential troubles. Instead I
simply added a configuration file for the test to set the timescale, so
it is the same way I am going to proceed with my project.

Regards,
Orson

> Note, BTW, that there is a difference between timescale and precision.
> Note also that there is not really a big performance consequence for
> having too much precision in Icarus Verilog, due to the way it operates
> its event queue.
> 
> - -- 
> 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 v2
> 
> iEYEARECAAYFAlVsehwACgkQrPt1Sc2b3ilIfwCghJ+EHg+uDOLHwBABZ+4ONwZi
> PTUAnjvLxnCPYptkz3TjoHvwSFPCjPEP
> =bB9o
> -----END PGP SIGNATURE-----
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> Iverilog-devel mailing list
> Ive...@li...
> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
> 

Re: [Iverilog-devel] Time in VHDL

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

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

On 06/01/2015 08:16 AM, Maciej Sumiński wrote:
> All I need is to use the same timescale in simulated modules. For
> the moment there is no constraint coming from the modules I am
> trying to simulate, so even without introducing any changes
> regarding the timescale in vhdlpp I am still going to be content.
> Simply setting a sensible default timescale will work for me.

If you only need your specific timescale to apply to your modules,
then you should use a module specific timescale. The problem with
the `resetall directive it that the consequences leak out of your
modules to the rest of the design, and affect more than timescale.
Writing your own `timescale directive also leaks out of your modules
into the design at a whole, in unpleasant ways. I think that the
timescale of VHDL code should not effect the timescale of Verilog
code, so you need to do something that has better scope rules.

It is perfectly OK, even expected, that modules have different
timescales, it's just that the `timescale directive is horrible
and that is why SystemVerilog added the timescale module item.
The scoping rules for that timescale are rational.

What it may come down to is that every module you generate has
a timescale module item.

Note, BTW, that there is a difference between timescale and precision.
Note also that there is not really a big performance consequence for
having too much precision in Icarus Verilog, due to the way it operates
its event queue.

- -- 
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 v2

iEYEARECAAYFAlVsehwACgkQrPt1Sc2b3ilIfwCghJ+EHg+uDOLHwBABZ+4ONwZi
PTUAnjvLxnCPYptkz3TjoHvwSFPCjPEP
=bB9o
-----END PGP SIGNATURE-----