Menu
▾
▴
iverilog-devel
|
From: Maciej S. <mac...@ce...> - 2015-04-23 14:17:00
Attachments:
signature.asc
|
Hi,
There is a new branch [1, 2] that contains new features for vhdlpp:
- assertion & report statements
- boolean type (to be more precise: "true" & "false" values)
- fixes missing std_logic values in emit() functions
I have one doubt regarding the proposed branch. It introduces a few new
keywords (true, false, note, warning, error, failure). Because of that,
it is impossible to use them as names, so for example you cannot have a
signal called 'true', which should be technically valid according to the
VHDL standard.
Alternatively, I could detect the keywords with strncmp() in appropriate
rules in the parser. Is it the preferred approach or is there another
more elegant solution to the problem?
I am also wondering if there is a way to translate weak std_logic values
('L', 'H' & 'W') to SystemVerilog. I know there is 'strength' property,
but it is not exactly the same (e.g. it cannot be used to compare to a
net value).
Regards,
Orson
1. https://github.com/steveicarus/iverilog/pull/61
2. https://github.com/orsonmmz/ivtest/tree/asserts_test
|
|
From: Stephen W. <st...@ic...> - 2015-04-23 15:35:48
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/23/2015 07:16 AM, Maciej Sumiński wrote: > I have one doubt regarding the proposed branch. It introduces a few > new keywords (true, false, note, warning, error, failure). Because > of that, it is impossible to use them as names, so for example you > cannot have a signal called 'true', which should be technically > valid according to the VHDL standard. If the word is not a reserved word as listed in the IEEE1076 standard, then it cannot be parsed as a keyword. It needs to be matched as an IDENTIFIER and interpreted during semantic analysis. This is one of the painful quirks of VHDL. So no, you cannot add new keywords. Match them as IDENTIFIERs, then check the actual value in the rules where you expect 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 v2 iEYEARECAAYFAlU5EUoACgkQrPt1Sc2b3ilnTwCePXWloYRaJvxc7X6AI6wkfpbu nA8AoLAoH78HMbxkhhrBPjnbAkhf+EwE =Ms/R -----END PGP SIGNATURE----- |
|
From: Maciej S. <mac...@ce...> - 2015-04-24 13:42:49
|
On 04/23/2015 05:35 PM, Stephen Williams wrote: > If the word is not a reserved word as listed in the IEEE1076 > standard, then it cannot be parsed as a keyword. It needs to > be matched as an IDENTIFIER and interpreted during semantic > analysis. This is one of the painful quirks of VHDL. > > So no, you cannot add new keywords. Match them as IDENTIFIERs, > then check the actual value in the rules where you expect them. Ok, it is already fixed. I have also added a patch from Larry Doolittle to handle or_reduce() and and_reduce() function. I enclose one more patch that needs a review. I am wondering if it is required for both arguments in NetEBDiv to have the same width? There is a testcase attached which causes an assertion failure, but in fact it works fine. It also does not break any other tests, but I might have missed something important there. Regards, Orson |
|
From: Stephen W. <st...@ic...> - 2015-04-25 01:07:38
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/24/2015 06:42 AM, Maciej Sumiński wrote: > I enclose one more patch that needs a review. I am wondering if it > is required for both arguments in NetEBDiv to have the same width? > There is a testcase attached which causes an assertion failure, but > in fact it works fine. It also does not break any other tests, but > I might have missed something important there. The assertions you want to remove are in the eval_tree(...) method of the NetEBDiv node, which evaluates the division/mod expression. The problem here is that the verinum divide (/ and %) operators kinda assume that the operands and the result are the same size. The assert is apparently there because the consequences of passing mismatched arguments to these operators will not have predictable results, and doesn't handle the various consequences. The way forward to removing the asserts involves adjusting the operands so that their sizes match the output size (cast_to_width should help you there) first, then do the divide. Otherwise, I do not think there are constraints that the divide operand sizes must match, so the above approach should do it for you. - -- 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 iEYEARECAAYFAlU66NEACgkQrPt1Sc2b3ilCNgCgyKwMnmDab5WbYQ4d1LiBuuCw PEMAoIcXpss/x7T1dXnCpgaVyKpOyLen =NXdy -----END PGP SIGNATURE----- |
|
From: Martin W. <mai...@ma...> - 2015-04-25 08:07:03
|
Maciej Sumiński wrote:
> I enclose one more patch that needs a review. I am wondering if it is
> required for both arguments in NetEBDiv to have the same width? There is
> a testcase attached which causes an assertion failure, but in fact it
> works fine. It also does not break any other tests, but I might have
> missed something important there.
>
The steps required for expression evaluation in Verilog are:
- determine the width of the expression, according to the rules
in the standard
- extend all operands to the width of the expression, using
the type of the expression (unsigned/signed), not the
type of the operands, to decide whether to zero extend
or sign extend
- evaluate the expression
If you don't make sure all the operands are the same size before evaluating
the expression, most of the time you'll get the same result, but there will be
corner cases where you don't.
Martin
|
|
From: Kevin C. <iv...@gr...> - 2015-04-26 01:49:57
|
The whole keyword thing is just a consequence of how people did parsers - if you use context aware recursive-descent parsers then there isn't a problem. One useful thing that VHDL does is that it moved a lot of stuff to user-space by putting it in "standard headers". You don't have to take the LRM literally, and you can move things like "true" & "false" to enum in a header file. The LRMs are really just statements of what you need to understand to be compatible, you can implement your version with more/better capabilities. Kev. On 04/23/2015 08:35 AM, Stephen Williams wrote: > On 04/23/2015 07:16 AM, Maciej Sumiński wrote: > > I have one doubt regarding the proposed branch. It introduces a few > > new keywords (true, false, note, warning, error, failure). Because > > of that, it is impossible to use them as names, so for example you > > cannot have a signal called 'true', which should be technically > > valid according to the VHDL standard. > > If the word is not a reserved word as listed in the IEEE1076 > standard, then it cannot be parsed as a keyword. It needs to > be matched as an IDENTIFIER and interpreted during semantic > analysis. This is one of the painful quirks of VHDL. > > So no, you cannot add new keywords. Match them as IDENTIFIERs, > then check the actual value in the rules where you expect them. > > > ------------------------------------------------------------------------------ > BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT > Develop your own process in accordance with the BPMN 2 standard > Learn Process modeling best practices with Bonita BPM through live exercises > http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ > source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF > _______________________________________________ > Iverilog-devel mailing list > Ive...@li... > https://lists.sourceforge.net/lists/listinfo/iverilog-devel |
|
From: Martin W. <mai...@ma...> - 2015-04-25 08:34:15
|
Maciej Sumiński wrote: > I enclose one more patch that needs a review. I am wondering if it is > required for both arguments in NetEBDiv to have the same width? There is > a testcase attached which causes an assertion failure, but in fact it > works fine. It also does not break any other tests, but I might have > missed something important there. > The first argument to $ivlh_to_unsigned should be treated as a self-determined expression. The compiler was not doing this; instead it was elaborating the argument using the cast width. I've pushed a fix for this to the master branch. I'll update the test suite later. Martin |
|
From: Maciej S. <mac...@ce...> - 2015-04-25 21:45:02
Attachments:
signature.asc
|
On 04/25/2015 10:28 AM, Martin Whitaker wrote: > Maciej Sumiński wrote: >> I enclose one more patch that needs a review. I am wondering if it is >> required for both arguments in NetEBDiv to have the same width? There is >> a testcase attached which causes an assertion failure, but in fact it >> works fine. It also does not break any other tests, but I might have >> missed something important there. >> > The first argument to $ivlh_to_unsigned should be treated as a self-determined > expression. The compiler was not doing this; instead it was elaborating the > argument using the cast width. I've pushed a fix for this to the master > branch. I'll update the test suite later. > > Martin Hi Martin, Thank you for the explanation and the fix. Now it works fine for me. Regards, Orson |
|
From: Stephen W. <st...@ic...> - 2015-04-26 15:34:05
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Um... 1) VHDL is definitely NOT suitable for recursive descent parsing. Few modern computer languages are. 2) If you integrate left context into your lexor, then yes a LALR parser, and bison in particular, would have an easier time directly mapping. Oh wait, that's almost what we do by matching these things as IDENTIFIERS and handling them in the rules. We just do it outside of the flex/bison infrastructure. You have a point that TRUE and FALSE may be enumeration values. It turns out that they are, and they are defined in the BOOLEAN type enumeration in the standard package. Orson, this is something you need to take note of. While they are not keywords, they ARE predefined enumeration values. There is infrastructure in vhdlpp for predefining types, that is what you want to use here. On 04/25/2015 11:30 AM, Kevin Cameron wrote: > > The whole keyword thing is just a consequence of how people did > parsers - if you use context aware recursive-descent parsers then > there isn't a problem. > > One useful thing that VHDL does is that it moved a lot of stuff to > user-space by putting it in "standard headers". You don't have to > take the LRM literally, and you can move things like "true" & > "false" to enum in a header file. > > The LRMs are really just statements of what you need to understand > to be compatible, you can implement your version with more/better > capabilities. > > Kev. > > On 04/23/2015 08:35 AM, Stephen Williams wrote: >> On 04/23/2015 07:16 AM, Maciej Sumiński wrote: >>> I have one doubt regarding the proposed branch. It introduces a >>> few new keywords (true, false, note, warning, error, failure). >>> Because of that, it is impossible to use them as names, so for >>> example you cannot have a signal called 'true', which should be >>> technically valid according to the VHDL standard. >> >> If the word is not a reserved word as listed in the IEEE1076 >> standard, then it cannot be parsed as a keyword. It needs to be >> matched as an IDENTIFIER and interpreted during semantic >> analysis. This is one of the painful quirks of VHDL. >> >> So no, you cannot add new keywords. Match them as IDENTIFIERs, >> then check the actual value in the rules where you expect 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 v2 iEYEARECAAYFAlU9BWIACgkQrPt1Sc2b3ikQiwCg1H6jJ3OwE5zyHcXK0K2cxdXE uAsAmwfCfNTMr1hloty/PHW5OJlOFbYU =jG3s -----END PGP SIGNATURE----- |
|
From: Kevin C. <iv...@gr...> - 2015-04-28 08:53:58
|
I've done recursive descent (RD) on C++, it can't be worse than that. I just tokenize everything according to the context then do RD on the token stream - ideally I'd be able to parallel process chunks snipped of the stream, but I never got that far. I don't use lexx/yacc/bison etc. - it's bad enough reading human generated code, debugging those is way too painful. With RD you can tell where you are when things go wrong, and it's easier to handle corner cases. It's particularly easy when the beginning and end of blocks are clearly marked. Someone at Synopsys was claiming that the reason for not doing something was "keyword incompatibility" - that's the lamest of excuses, and just means they're clueless about writing parsers. Kev. On 04/26/2015 08:33 AM, Stephen Williams wrote: > > Um... > > 1) VHDL is definitely NOT suitable for recursive descent parsing. > Few modern computer languages are. > > 2) If you integrate left context into your lexor, then yes a LALR > parser, and bison in particular, would have an easier time directly > mapping. Oh wait, that's almost what we do by matching these things > as IDENTIFIERS and handling them in the rules. We just do it outside > of the flex/bison infrastructure. > > You have a point that TRUE and FALSE may be enumeration values. > It turns out that they are, and they are defined in the BOOLEAN > type enumeration in the standard package. Orson, this is something > you need to take note of. While they are not keywords, they ARE > predefined enumeration values. There is infrastructure in vhdlpp > for predefining types, that is what you want to use here. > > > On 04/25/2015 11:30 AM, Kevin Cameron wrote: > > > The whole keyword thing is just a consequence of how people did > > parsers - if you use context aware recursive-descent parsers then > > there isn't a problem. > > > One useful thing that VHDL does is that it moved a lot of stuff to > > user-space by putting it in "standard headers". You don't have to > > take the LRM literally, and you can move things like "true" & > > "false" to enum in a header file. > > > The LRMs are really just statements of what you need to understand > > to be compatible, you can implement your version with more/better > > capabilities. > > > Kev. > > > On 04/23/2015 08:35 AM, Stephen Williams wrote: > >> On 04/23/2015 07:16 AM, Maciej Sumiński wrote: > >>> I have one doubt regarding the proposed branch. It introduces a > >>> few new keywords (true, false, note, warning, error, failure). > >>> Because of that, it is impossible to use them as names, so for > >>> example you cannot have a signal called 'true', which should be > >>> technically valid according to the VHDL standard. > >> > >> If the word is not a reserved word as listed in the IEEE1076 > >> standard, then it cannot be parsed as a keyword. It needs to be > >> matched as an IDENTIFIER and interpreted during semantic > >> analysis. This is one of the painful quirks of VHDL. > >> > >> So no, you cannot add new keywords. Match them as IDENTIFIERs, > >> then check the actual value in the rules where you expect them. > > > > ------------------------------------------------------------------------------ > One dashboard for servers and applications across Physical-Virtual-Cloud > Widest out-of-the-box monitoring support with 50+ applications > Performance metrics, stats and reports that give you Actionable Insights > Deep dive visibility with transaction tracing using APM Insight. > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y > _______________________________________________ > Iverilog-devel mailing list > Ive...@li... > https://lists.sourceforge.net/lists/listinfo/iverilog-devel |
|
From: Maciej S. <mac...@ce...> - 2015-05-07 15:30:38
Attachments:
signature.asc
|
On 04/26/2015 05:33 PM, Stephen Williams wrote:
[..]
> You have a point that TRUE and FALSE may be enumeration values.
> It turns out that they are, and they are defined in the BOOLEAN
> type enumeration in the standard package. Orson, this is something
> you need to take note of. While they are not keywords, they ARE
> predefined enumeration values. There is infrastructure in vhdlpp
> for predefining types, that is what you want to use here.
Thank you for the suggestion. I have updated the branch [1] and extended
its test [2] to check logical operators.
To simplify things, I kept boolean type as VTypePrimitive instead of
VTypeEnum, and simply generated a header:
`ifndef __VHDL_STD_TYPES
`define __VHDL_STD_TYPES
typedef enum bit { \false , \true } boolean ;
`endif
It is important to use directives here to avoid multiple definitions.
Alternatively, I could turn boolean type into VTypeEnum, but I would
still need directives to have it defined only once, so I am not sure if
this could look better in the code (i.e. a dedicated if to output
boolean definition).
Unfortunately, this will not allow evil designers to name their signals
'true' and 'false', because even if VHDL accepts it, SystemVerilog is a
little bit more sane and objects to signals and enum values having the
same name.
Regards,
Orson
1. https://github.com/steveicarus/iverilog/pull/67
2. https://github.com/orsonmmz/ivtest/tree/boolean_test
|
Thanks for helping keep SourceForge clean.
X