Re: [Iverilog-devel] offering some SystemVerilog tests

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

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


I've merged your test_sv branch into git master, and pushed.
Thanks for all those tests, I will gradually move them into
the main regress.list as they start passing tests.

On 04/29/2012 10:57 PM, Iztok Jeras wrote:
> Hi Stephen,
> 
> Please go on and just merge my branch, there should be no other 
> changes than the added tests.
> 
> Regards, Iztok Jeras
> 
> On Mon, Apr 30, 2012 at 01:08, Stephen Williams <st...@ic...>
> wrote:
> 
> I think I'm at a place where I can integrate your tests into the 
> ivtest master branch. Do you still plan to send a pull request 
> through github, or should I just merge your branch?
> 
> On 04/15/2012 07:37 AM, Iztok Jeras wrote:
>>>> Hi,
>>>> 
>>>> A set of tests should be now ready, I already reported
>>>> related bugs or/and feature requests (mostly SystemVerilog
>>>> RTL features). All tests have been verified using ncsim, some
>>>> tests (packed arrays) may trigger ncsim bugs, so they were
>>>> checked using ModelSim. The coding style is not perfect, but
>>>> it should be clear from printouts, which line of code
>>>> triggered an issue (once the code compiles). All tests are
>>>> placed into the public domain.
>>>> 
>>>> Here is the list of tests ready for inclusion, with related
>>>> bug reports or feature requests, some tests pass: 
>>>> struct_packed_write_read.v (bug 3513772)
>>>> struct_packed_value_list.v (feature 3513783)
>>>> struct_packed_sysfunct.v (bug 3513774 fixed) 
>>>> array_packed_write_read.v (feature 3513786, requires
>>>> ModelSim) array_packed_value_list.v (feature 3513783,
>>>> requires ModelSim) array_packed_sysfunct.v (feature 3513790,
>>>> requires ModelSim) sv_end_labels.v sv_end_labels_bad.v
>>>> (feature 3516069) sv_literals.v (passed, but is missing
>>>> signed literals) sv_parameter_type.v (feature 3516061)
>>>> sv_interface.v (feature 3518172) sv_package.v (feature
>>>> 3518165) sv_casting.v (unfinished, no need to merge this 
>>>> one)
>>>> 
>>>> $ ./vvp_reg.pl sv_regress.list Running compiler/VVP tests
>>>> for Icarus Verilog version: 0.10. 
>>>> ----------------------------------------------------------------------------
>>>>
>>>>
>
>>>> 
struct_packed_write_read: ==> Failed - output does not match gold file.
>>>> struct_packed_value_list: ==> Failed - running iverilog. 
>>>> struct_packed_sysfunct: Passed. array_packed_write_read: ==>
>>>> Failed - running iverilog. array_packed_value_list: ==>
>>>> Failed - running iverilog. array_packed_sysfunct: ==> Failed
>>>> - running iverilog. sv_end_labels: ==> Failed - running
>>>> iverilog. sv_end_labels_bad: Passed - CE. sv_literals:
>>>> Passed. sv_parameter_type: ==> Failed - running iverilog.
>>>> sv_interface: ==> Failed - running iverilog. sv_package: ==>
>>>> Failed - running iverilog. sv_casting: ==> Failed - running
>>>> iverilog. 
>>>> ============================================================================
>>>>
>>>>
>
>>>> 
Test results:
>>>> Total=13, Passed=3, Failed=10, Not Implemented=0, Expected
>>>> Fail=0
>>>> 
>>>> The next tests on my list are for casting, and some tests
>>>> might get an update when I learn how to properly check for
>>>> support for signed variables.
>>>> 
>>>> I will send a GitHub pull request later today.
>>>> 
>>>> Regards, Iztok Jeras
>>>> 
>>>> On Tue, Apr 3, 2012 at 18:00, Cary R. <cy...@ya...>
>>>> wrote:
>>>>> Hi Iztok,
>>>>> 
>>>>> It's always a tradeoff if this is what works for you then 
>>>>> proceed. Let me know when you have code to import into the
>>>>> main test suite.
>>>>> 
>>>>> FYI I can easily view wide source files. The smallest
>>>>> monitor I usually work with is 1920x1200 and I normally
>>>>> work in front of dual 2560x1600monitors.
>>>>> 
>>>>> 
>>>>> Regards,
>>>>> 
>>>>> Cary
>>>>> 
>>>>> 
>>>>> 
>>>>> ----- Original Message ----- From: Iztok Jeras 
>>>>> <izt...@gm...> To: Cary R. <cy...@ya...>
>>>>> Cc: Discussions concerning Icarus Verilog development 
>>>>> <ive...@li...> Sent: Tuesday, April
>>>>> 3, 2012 1:10 AM Subject: Re: [Iverilog-devel] offering
>>>>> some SystemVerilog tests
>>>>> 
>>>>> Hi Cary,
>>>>> 
>>>>> I have reasons to write long lines, since they make it
>>>>> easier for me to check/correct/update the tests. All the
>>>>> relevant code is compact in a block, I have to look only at
>>>>> a few code lines (and few columns) to see if I covered all
>>>>> the cases I wished to check. Some of the code forms a 2D
>>>>> pattern, which makes some copy/paste issues easier to spot.
>>>>> It is much easier to ignore the irrelevant repetitive code,
>>>>> if it is placed on the left/right edges instead of being
>>>>> interleaved with lines of relevant code. Also there are 
>>>>> many similar test cases and I use block edit modes to copy
>>>>> the code and to modify it. So If I modify the code I might
>>>>> make it easier for you to read on a narrow terminal, but
>>>>> much more difficult for me to update.
>>>>> 
>>>>> So I will try to make the very long lines shorter (but not
>>>>> really 80 characters), but probably keep the long line
>>>>> style.
>>>>> 
>>>>> In any case I do not want to make this into a discussion
>>>>> of merits of different coding styles. If the coding style
>>>>> in the test environment is important, let me first add some
>>>>> missing tests (packed structures/arrays for parameters,
>>>>> ...) to improve coverage. I can later add the white space
>>>>> to change the coding style before the tests are merged.
>>>>> 
>>>>> Regarding the 'pass' versus 'err' variable, I understand
>>>>> this is common in other tests, so I will modify it. Except
>>>>> I would use the bit type instead of reg :)
>>>>> 
>>>>> Regards, Iztok Jeras
>>>>> 
>>>>> On Mon, Apr 2, 2012 at 18:24, Cary R. <cy...@ya...>
>>>>> wrote:
>>>>>> Hi Iztok,
>>>>>> 
>>>>>> A couple of comments on the coding style of the SV
>>>>>> tests.
>>>>>> 
>>>>>> I prefer to have the files limited to a width of 80
>>>>>> characters. This isn't a hard requirement, but where it
>>>>>> is possible you should try to do this.
>>>>>> 
>>>>>> For example, making the if of a check all one line makes
>>>>>> it harder to read. I prefer something like the
>>>>>> following.
>>>>>> 
>>>>>> // Check the width of the entire packed structure is
>>>>>> calculated correctly. if ($bits(word0) !== 16) begin 
>>>>>> $display("<message>"); err = err + 1; end
>>>>>> 
>>>>>> Also a few other things. If you are not going to use the
>>>>>> error count why not make it a single pass bit like is
>>>>>> used in many of the other tests. Also if you initialize
>>>>>> the error variable at the beginning of the test code then
>>>>>> you don't need the #1. If you use a pass variable or !
>>>>>> err then you can simplify the code at the end.
>>>>>> 
>>>>>> 
>>>>>> reg pass;
>>>>>> 
>>>>>> initial begin pass = 1'b1;
>>>>>> 
>>>>>> <the rest of the tests, on fail assign pass = 1'b0>
>>>>>> 
>>>>>> if (pass) $display("PASSED"); end
>>>>>> 
>>>>>> If someone else doesn't get to them first I'll try to
>>>>>> look at your bug reports when I get some free time. I'm
>>>>>> guessing the one is related to the vvp code generator not
>>>>>> supporting selects on an element of a packed structure.
>>>>>> The other one looks to be a bug in the compiler related
>>>>>> to the width of the structure element. The expr_width()
>>>>>> call in elab_expr.cc, line 1125 is returning 0 for the
>>>>>> width of the structure parts. I'm surprised that doesn't
>>>>>> cause other issues. I think the $bits test should be
>>>>>> fixed first.
>>>>>> 
>>>>>> Once we get the tests a bit more polished we can work out
>>>>>> how we are going to integrate these tests.
>>>>>> 
>>>>>> 
>>>>>> Regards,
>>>>>> 
>>>>>> 
>>>>>> Cary
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> ----- Original Message ----- From: Iztok Jeras 
>>>>>> <izt...@gm...> To: Cary R. <cy...@ya...>
>>>>>> Cc: Discussions concerning Icarus Verilog development 
>>>>>> <ive...@li...> Sent: Friday,
>>>>>> March 30, 2012 10:25 AM Subject: Re: [Iverilog-devel]
>>>>>> offering some SystemVerilog tests
>>>>>> 
>>>>>> Hi,
>>>>>> 
>>>>>> I updated tests for packed structures and packed arrays,
>>>>>> tested is write/read access, use of value lists (the '{}
>>>>>> construct) and related system functions. All tests were
>>>>>> tested using ncsim, some tests do not pass ncsim (a
>>>>>> confirmed bug), but should pass VCS, but there is
>>>>>> probably also a VCS bug in 
>>>>>> ivltests/array_packed_value_list.v. I might run this
>>>>>> tests on ModelSim, but later. Most of the tested features
>>>>>> are for RTL, I plan to add tests for other SV features,
>>>>>> but most will focus on RTL.
>>>>>> https://github.com/jeras/ivtest/tree/test_sv
>>>>>> 
>>>>>> Most of the issues are missing features (compiler fails),
>>>>>> but there are some issues that are clearly bugs, for
>>>>>> example: ivltests/struct_packed_write_read.v
>>>>>> 
>>>>>> I will report bugs, where the issue is clearly a bug,
>>>>>> otherwise a feature request.
>>>>>> 
>>>>>> Could somebody from developers with write access merge my
>>>>>> tests into master, and manually merge sv_regress.list
>>>>>> into regress.list and modify it as needed. I will add
>>>>>> future tests based on the provided example, so they could
>>>>>> be merged without modifications.
>>>>>> 
>>>>>> Regards, Iztok Jeras
>>>>>> 
>>>>>> On Sun, Mar 25, 2012 at 18:40, Cary R.
>>>>>> <cy...@ya...> wrote:
>>>>>>> Martin appears to have answered your question
>>>>>>> regarding integration and coding style for the test
>>>>>>> suite. I'll try to look at your test sometime and
>>>>>>> comment as well. There are two schools of thought on
>>>>>>> the NI designator. For all the stable and previous
>>>>>>> versions (0.8 and 0.9) the test needs to be marked NI.
>>>>>>> For development we typically let the test fail to 
>>>>>>> remind us there are failures/missing functionality.
>>>>>>> The problems is I don't like to see a huge number of
>>>>>>> fails in development because it skews the perception of
>>>>>>> the casual user that Icarus development has bugs when
>>>>>>> in fact it is missing functionality that may not even
>>>>>>> be added to the next stable release.
>>>>>>> 
>>>>>>> 
>>>>>>> Sine Icarus only claims to be 1364-2005 compliant new 
>>>>>>> SystemVerilog requests should be added as feature
>>>>>>> requests. Bugs in currently implemented SystemVerilog
>>>>>>> constructs should be added to the bug tracker.
>>>>>>> 
>>>>>>> Cary
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> ----- Original Message ----- From: Iztok Jeras 
>>>>>>> <izt...@gm...> To: Cary R.
>>>>>>> <cy...@ya...>; Discussions concerning Icarus
>>>>>>> Verilog development 
>>>>>>> <ive...@li...> Cc: Sent:
>>>>>>> Saturday, March 24, 2012 11:23 AM Subject: Re:
>>>>>>> [Iverilog-devel] offering some SystemVerilog tests
>>>>>>> 
>>>>>>> Hi,
>>>>>>> 
>>>>>>> I created the first test today, it tests write/read
>>>>>>> access to packed structures, with size unaligned writes
>>>>>>> and writes to a part of the structure. It seems there
>>>>>>> is an issue accessing only a part of the structure,
>>>>>>> iverilog seems to write all bits although only some
>>>>>>> bits were selected.
>>>>>>> 
>>>>>>> The files are on GitHub in the test_sv branch: 
>>>>>>> https://github.com/jeras/ivtest/tree/test_sv
>>>>>>> 
>>>>>>> To run the example: ./vvp_reg.pl sv_regress.list
>>>>>>> iverilog -g2009 ivltests/struct_packed_write_read.v &&
>>>>>>> vvp a.out
>>>>>>> 
>>>>>>> Please could somebody check the test, and comment if I
>>>>>>> have to modify something for it to conform to the
>>>>>>> ivtest coding style. Also how should the test line
>>>>>>> inside regress.list look if the test is for a feature
>>>>>>> not yet implemented in devel.
>>>>>>> 
>>>>>>> I plan to write a set of tests which I will test on
>>>>>>> Ncsim 11.10 and some on ModelSim, and which can be used
>>>>>>> to test new SystemVerilog features when they get
>>>>>>> implemented.  When I would get a large set of tests, I
>>>>>>> would ask you to merge the tests into master and I
>>>>>>> could/should also file bug reports for missing features
>>>>>>> and issues with already implemented features.
>>>>>>> 
>>>>>>> A broader plan would be to get support for at least
>>>>>>> some SV RTL constructs into Icarus Verilog and
>>>>>>> Verilator, so we can start recommending SV to open
>>>>>>> source Verilog developers on OpenCores and elsewhere.
>>>>>>> 
>>>>>>> Regards, Iztok Jeras
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>>> ------------------------------------------------------------------------------
>>>>
>>>>
>
>>>> 
For Developers, A Lot Can Happen In A Second.
>>>> Boundary is the first to Know...and Tell You. Monitor Your 
>>>> Applications in Ultra-Fine Resolution. Try it FREE! 
>>>> http://p.sf.net/sfu/Boundary-d2dvs2 
>>>> _______________________________________________
>>>> Iverilog-devel mailing list
>>>> Ive...@li... 
>>>> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
> 
> 
>> 
>> ------------------------------------------------------------------------------
>>
>> 
Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security
>> and threat landscape has changed and how IT managers can respond.
>> Discussions will include endpoint security, mobile security and
>> the latest in malware threats.
>> http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ 
>> _______________________________________________ Iverilog-devel
>> mailing list Ive...@li... 
>> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
> 
> ------------------------------------------------------------------------------
>
> 
Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and 
> threat landscape has changed and how IT managers can respond.
> Discussions will include endpoint security, mobile security and the
> latest in malware threats.
> http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ 
> _______________________________________________ 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.0.16 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk+esQAACgkQrPt1Sc2b3ikTXwCeJm+LFQwFiZ+5/b+zYLrICugb
goIAni1SEhqbr3sVjJWmUExD6zifo6hB
=/QYS
-----END PGP SIGNATURE-----