PatternBurst before MacroDefs?

[danbodoh]

Is this really part of the spec? I have a stil written from a industry standard tool that has MacroDefs prior to PatternBurst. But the Pattern block is after the PatternBurst

lark.exceptions.VisitError: Error trying to process rule "b_macrodefs__OPEN_MACRO_DEFS_BLOCK":

Expected PatternBurst block before any MacroDefs block

[seimit]

Hi Dan,
Here is the long answer. The short answer is after that :-).
Probably you are aware of "7.1 Top-level statements and required ordering" in IEEE 1450.0 standard.
There are few exception in the "define before use" rule. One of this is the Pattern block reference in the PatternBurst, because the pattern blocks must be the last blocks in the file. The other is related to MacroDefs and Procedures. According the standard they "may or may not be forward references". For me this means that they can be before the PatternBurst/Exec block as well.
According Table 7, the MacroDefs and Procedures are between the PatternExec and Pattern block. The semantic analyzer was built based the information on this table. This was the most easy way to implement, because:

• If the MacroDefs and Procedures are before the PatternBurst blocks, it is unknown which SignalGroups block will be used. This means that the code must wait PatternBurst appearance to process the MacroDefs and Procedures block.
• If the MacroDefs and Procedures are before the PatternExec blocks, it is unknown which Timing block will be used. This means that the code must wait PatternExec appearance to process the MacroDefs and Procedures block.

So the short answer is : yes, it is part of the spec. However the MacroDefs and Procedures before PatternBurst/Exec is allowed as well, but not implemented in the current version of the library.

I can check what efforts are needed to implement it, but for sure I can not make it in the next 2 weeks.
Kind Regards,
Seimit

[danbodoh]

Just doing some reading about Lark, which I've never used. Can you hack the Tree to move MacroDefs and Procedures after PatternBurst/Exec?

[seimit]

The problem is not in the Lark. You can see in the stil.lark file that all blocks are with "|" which means that the order of all blocks is not important.
The problem is in the semantic analyzer. I can easy remove this restriction in the MacroDefsBlockParser.py , method "b_macrodefs__OPEN_MACRO_DEFS_BLOCK", but I have to remove also all semantic checks for signals/timings inside Macro/Procs.

[danbodoh]

My comment was based on "the code" referenced below: - If the MacroDefs and Procedures are before the PatternBurst blocks, it is unknown which SignalGroups block will be used. This means that the code must wait PatternBurst appearance to process the MacroDefs and Procedures block. - If the MacroDefs and Procedures are before the PatternExec blocks, it is unknown which Timing block will be used. This means that the code must wait PatternExec appearance to process the MacroDefs and Procedures block. I'm not sure where "the code" is that is dependent on this ordering of MacroDefs, Procedures and PatternBurst. But if you can hack the Lark tree before "the code" executes, it will never know that the stil file has them in a different order. If "the code" is just semantic checking and unrelated to the dumping, maybe somehow I can avoid the semantic checks. I am willing to assume I have a semantically correct STIL file, so I don't want to check it, just dump the expanded vectors.

…

On Tue, Jun 28, 2022 at 2:46 PM seimit ***@***.***> wrote: The problem is not in the Lark. You can see in the stil.lark file that all blocks are with "|" which means that the order of all blocks is not important. The problem is in the semantic analyzer. I can easy remove this restriction in the MacroDefsBlockParser.py , method "b_macrodefs__OPEN_MACRO_DEFS_BLOCK", but I have to remove also all semantic checks for signals/timings inside Macro/Procs. — Reply to this email directly, view it on GitHub <#52 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABNI66U24ONUNNRSNWAOBGLVRNJBTANCNFSM52AQOQ5A> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[seimit]

Hi Dan,
I removed the semantic check for order of Procedure and MacroDefs blocks.
Note, that Semi-ATE STIL project covers only the syntax parser and semantic analyzer. The STILDumpCompiler is a "bonus" and is not primary goal of this project. It is used as test bed and example for users of the STIL parser library to make own compiler.
The STILDumpCompiler is a single pass compiler and in order to work properly he relies on the exact order in table 7 in the IEEE 1450.0 standard. Because of this, the removed code was moved into the STILDumpCompiler. This means that your STIL file still cannot dump the vector data as you planned.
If you want to dump expanded vectors, you have to write own double pass compiler which should collect the used SignalGroups and Timings in the PatternExec/Burst in the first pass and to expand the vectors from the MacrDefs/Procedure blocks in the second pass based on collected data in the first pass.
I do not have time to make double pass compiler.
Kind Regards,
Seimit

[seimit]

I reopen the issue, because now I have idea how to implement PatternBurst before MacroDefs/Procedure without writing double pass compiler. If I have more free time I will try to implemented.