looking to prototype a grammar need suggestions.

[bpatton]

I do regression testing for rule sets of IC layout verification.
The current rule sets are written in a doc file in complete free form
and useless to try and parse. Different people say the same thing in
different words.
I'm looking to create a prototype grammar for describing the rules.
The majority will be very simple, others will be quite complex and
contain many pseudo layers. Here's a couple of examples and some
explanation

CONT size = 100 x 100
MET1 overlap CONT = 50
BOGUS = CONT common to MET1 <-- psuedo layer created from the "and"
of 2 other layers that may or may not be pseudo layers

I've already done some data generation on by simply calling a routine
sub common(layer1,layer2,width,height) {
draw something
}

This is simple and too limited. At the very bottom this routine will
have to exist, it's the calling of this routine. making the decisions
on which routines to call and in what order. I've considered CLIPS
but the problem still exists, no matter what language or platform.
How to describe a rule in a strict grammer so that a computer language
can break it apart and act upon the grammar according to the order and
specific words.


I'm thinking that I need to have a list of
Noun -> layer and pseudo layer names (CONT,MET1,BOGUS)
verb -> denotes an action ( overlap, extends into,
touching ,...)
adjective -> to modify a noun or pronoun
pronoun -> substitutes for a noun or noun phrase with or without a
determiner, such as you and they

The idea is to supply a set of values for each of the 4 grammar
categories and use only these to describe the rules.
The nouns are the only section that is eligible to grow by the rule
coder.

From this controlled grammar, I would then generate layout data to the

specifications of the grammer

 

[Grehom]

I do regression testing for rule sets of IC layout verification.
The current rule sets are written in a doc file in complete free form
and useless to try and parse. Different people say the same thing in
different words.
I'm looking to create a prototype grammar for describing the rules.
The majority will be very simple, others will be quite complex and
contain many pseudo layers. Here's a couple of examples and some
explanation

CONT size = 100 x 100
MET1 overlap CONT = 50
BOGUS = CONT common to MET1 <-- psuedo layer created from the "and"
of 2 other layers that may or may not be pseudo layers

I've already done some data generation on by simply calling a routine
sub common(layer1,layer2,width,height) {
draw something

}

This is simple and too limited. At the very bottom this routine will
have to exist, it's the calling of this routine. making the decisions
on which routines to call and in what order. I've considered CLIPS
but the problem still exists, no matter what language or platform.
How to describe a rule in a strict grammer so that a computer language
can break it apart and act upon the grammar according to the order and
specific words.

I'm thinking that I need to have a list of
Noun -> layer and pseudo layer names (CONT,MET1,BOGUS)
verb -> denotes an action ( overlap, extends into,
touching ,...)
adjective -> to modify a noun or pronoun
pronoun -> substitutes for a noun or noun phrase with or without a
determiner, such as you and they

The idea is to supply a set of values for each of the 4 grammar
categories and use only these to describe the rules.
The nouns are the only section that is eligible to grow by the rule
coder.


specifications of the grammer

In my opinion you could do a lot worse than by taking a look at Damian
Conway's 'Parse::RecDescent'. I'm certainly no rocket scientist, but
I find this grammar very useful where I want to do a bit more than I
can comfortably manage using regexps.

 

[bpatton]

In my opinion you could do a lot worse than by taking a look at Damian
Conway's 'Parse::RecDescent'. I'm certainly no rocket scientist, but
I find this grammar very useful where I want to do a bit more than I
can comfortably manage using regexps.

Just got through reading the pod. I do believe this is where I'll
start. I'll know more after I get into it more. But it looks like
what I want. If nothing else it will relieve the possible hundreds of
if/the/else this I would likely have.

Now to get me some test data and start prototyping.