#493 Path delay expression without parenthesis not supported

[Timothy Miller]

I thought I had seen someone already report this before, but I can't find it by search.

Anyhow, I am trying to a simulation model of the EHXPLLB clock generator that is part of the Lattice XP10. A simulatable EHXPLLB.v (attached) comes with the Lattice synthesis tools. When I try to compile this file, I get this error:

xp10/EHXPLLB.v:978: syntax error
xp10/EHXPLLB.v:976: error: syntax error in specify block

Those line numbers fall into this code:

specify

(RST => LOCK) = 0:0:0, 0:0:0;
(CLKI => CLKOP) = 0:0:0, 0:0:0;
(CLKI => LOCK) = 0:0:0, 0:0:0;
(CLKI => CLKOK) = 0:0:0, 0:0:0;

endspecify

According to your web page (where version 0.8 is described), specify blocks are not supported, but it should be parsed and ignored. Thus, I probably shouldn't be getting this error message.

Since they're all zero, I'm assuming I can just comment it out and it'll work, so I wouldn't call this a major bug. Although I don't really know what specify blocks specify.

[Timothy Miller]

Logged In: YES
user_id=606738
Originator: YES

BTW, as a general rule, before I file a report, I check out the latest code from git, rebuild it, install the update and try again. That applies here too.

[Cary R.]

Logged In: YES
user_id=1651735
Originator: NO

You forgot the group again is this a V0.8 or V0.9 report. I'm assuming V0.9 since that is where we have at least minimal specify support.

[Timothy Miller]

Logged In: YES
user_id=606738
Originator: YES

I get this error with the latest code from git.

[Cary R.]

Logged In: YES
user_id=1651735
Originator: NO

Yes I understood you tested this with the latest git. My point was you did not set the group when you posted the report and since you mentioned V0.8 there could be some confusion about which version you normally use. I assumed it was V0.9.

If you surround the delays with parenthesis this will work as expected. A specify block is used to specify the delay between pins in this case the delays are set to zero so yes you could remove the statements.

I looked at this very briefly. This is allowed syntax, but supporting it may not be possible using a bison based parser. The problem is that when the parenthesis are optional you cannot easily distinguish between a parenthesis surrounding the delay(s) and parenthesis surrounding the expression(s) that makes up the individual delay elements. You may need a significant amount of look ahead/backtracking to make this work. I will need to do some research to figure out if it is possible to do this in bison. Steve may already know if this is possible or not. I'm busy with other stuff right now, so don't expect a patch from me anytime soon.

[Cary R.]

Example file

[Cary R.]

Logged In: YES
user_id=1651735
Originator: NO

Here's the example I cooked up to test this.
File Added: pr2053597.v

[Stephen Williams]

The parser implications for this are quite grizzly:-( I made a go at this to see what conflicts rise up, and some tricky reduce/reduce conflicts do indeed turn up.

The easy workaround is to put parentheses around your delay list. I'm also reducing the priority to 4, not because its hard to fix but because it fits the criteria for priority-4 bugs.