Compare to Constant

A place for discussing topics that do not fit into the other VGS categories

Compare to Constant

Postby jyoung » Fri Apr 10, 2009 5:09 pm

I have a model that is one input that feeds into 3 enables systems. The three systems are enabled based on the output of a "Compare to Constant" block. The "Compare to Constant" blocks are set to 1, 2 and 3 respectively. I therefore have three paths through my model based on one of three inputs.

T-VEC generates 8 DCPs based on all possible combinations

TTT
TTF
TFT
TFF
FTT
FTF
FFT
FFF

Only the 4 in red are actual paths through the model because only one input can be active at a time. Two systems cannot be active at once and therefore 4 of the DCPs will never be satisfied.

Since this block is in the T-VEC library I assume it can handle this sort of problem. Do I need to change the way I’m analyzing it? There are 4 DCP errors, but the problem did generate the test vectors I need to test the model. I would just rather not have any errors so I know for sure everything was analyzed correctly.

Thanks
jyoung
 
Posts: 33
Joined: Wed Mar 18, 2009 2:25 pm

Re: Compare to Constant

Postby busser » Mon May 04, 2009 3:53 pm

Sorry for the delay in answering your question. I may have an overactive spam email filter because I never got a notification of this question.

It seems that all new users make this same statement

There are 4 DCP errors, but the problem did generate the test vectors I need to test the model. I would just rather not have any errors so I know for sure everything was analyzed correctly.


or something like it. The fact is, the DCP "errors" in T-VEC VGS are not really "errors" in the sense that something is definitely wrong with the model. They simply mean that a give DCP has a logical contradiction/inconsistency. T-VEC can't really know if this is intentional on the part of the modeler, as in your specific case, or if it is a true model error. This is one of the distinctions between requirements models and design models. Design models are incomplete, in that not all logical paths are intended to be possible. That is the nature of design, which is an optimization activity in addition to an implementation activity. It is possible to create a code generator from formal requirement specifications, but the result would execute so slowly for non-trivial applications that it would not be worth it. Modeling tools such as Simulink/SCADE/MatrixX are design modeling tools - essentially graphical source code languages. The designer takes advantage of knowledge about aspects of the problem space, such as

Only the 4 in red are actual paths through the model because only one input can be active at a time. Two systems cannot be active at once and therefore 4 of the DCPs will never be satisfied.


to create an optimal solution. However, T-VEC is designed based on the concept of requirements models. It considers each DCP path to be the constraint expression governing an output that is one requirement expression about the application. If the DCP path is not possible, it indicates this to the user by calling it a vector generation failure/DCP error. This brings it to the attention of the user for a decision as to whether the DCP path was supposed to provide a vector or not. This is something that T-VEC can't know about - the intention of the modeler.

Some DCP's have obviously inconsistent/contradictory constraints

X = Y && X != Y

These end up flagged by the T-VEC compiler as Tautological Contradictions. They are marked as such in the DCP View, and they are skipped during vector generation and reported about in the Tautological Contradiction report called "Spec Contradictions" - available via the menus and the red "C" icon in the main tool bar of VGS (It is actually only red when there is such a report).

Also, when you know of DCP's that will fail for valid reasons and you don't want to waste vector generation time trying to produce vector for them, you can always tell the vector generator to Skip them by filling in the Skip DCP's field in the subsystem properties vector generator dialog box. (Remember to tell VGS to use Subsystem Properties rather than Project Properties for that subsystem.

Hope this explains the issues and answers your questions. If not, please continue this forum item with any additional questions you might have.
busser
Site Admin
 
Posts: 52
Joined: Thu Mar 13, 2008 7:42 pm

Re: Compare to Constant

Postby jyoung » Mon May 04, 2009 4:06 pm

Bob,

Thanks for the response. We had this conversation in email (or a simular one) a few weeks back so I didn't continue the issue here. It is probably good to have it noted here as well because it clarified things for me.

I think I know understand the "DCP errors" better.

I didn't know about the skip DCP option so that will help speed up my analysis
jyoung
 
Posts: 33
Joined: Wed Mar 18, 2009 2:25 pm

Re: Compare to Constant

Postby jyoung » Tue May 05, 2009 3:18 pm

Life is funny some times. I had never seen the "Tautological Contradiction" until today which is right after you discussed them here yesterday.

I would like to discuss another example similar to this subject. I have sent you a screen shot of the section of the model causing issues. If needed I can create an example file to send to you, but that will require some work so let’s see if this will work for now.

I get a Tautological Contradiction with the following two statements. These correspond to the If1 and If2 blocks in the file I sent you.


LOGIC STRUCTURE If1_Constraint1(outputs_1__a:uint8,outputs_2__a:uint8)
ATTRIBUTE ModelLoc="matlab://GDE_EntryMonitor_CSU/entry_GNC_triggers/If1";
CONSTRAINT
(outputs_1__a = 1)
AND
(outputs_2__a = 0);

LOGIC STRUCTURE If2_Constraint1(outputs_1__a:uint8,outputs_2__a:uint8)
ATTRIBUTE ModelLoc="matlab://GDE_EntryMonitor_CSU/entry_GNC_triggers/If2";
CONSTRAINT
(outputs_1__a = 1)
AND
(outputs_2__a = 1);


The two if statements are designed to operate at different times depending on the feedback (orange inputs). Only one of the blocks is true at a time and therefore only one of the if enabled blocks will be in operation at any given time. As we discussed previously T-VEC doesn't know this is the case so it will try and design a test to achieve a situation where both if1 and if2 are true. Since this cannot be true there is an error with the DCP. The difference with this model and the other one discussed above is that none of the DCPs are satisfied (0/54) and I therefore get no test vectors. In the previous example T-VEC would generate the test vectors required to satisfy the possible DCPs and return an error with the ones that were not possible.

I would expect T-VEC to generate a DCP for that included If1_Constraint1 and Not: If1_Constraint2 but it does not it always has the above requirements included where if1 and If2 are true.

Thanks for the help here
jyoung
 
Posts: 33
Joined: Wed Mar 18, 2009 2:25 pm

Re: Compare to Constant

Postby busser » Tue May 05, 2009 3:30 pm

Hi James,

I would expect T-VEC to generate a DCP for that included If1_Constraint1 and Not: If1_Constraint2 but it does not it always has the above requirements included where if1 and If2 are true.


It definitely should produce such a DCP. But it is not possible for me to provide any more information based on only a screen shot of the top view of the model, which also does not include the logic of the if conditions.

Did you try examining the DCP view information. There should be a DCP which a predicate combination like you are asking about.

Note : The DCP view icons will be yellow or red. The red ones are the ones with tautological contradictions.

Bob
busser
Site Admin
 
Posts: 52
Joined: Thu Mar 13, 2008 7:42 pm

Re: Compare to Constant

Postby jyoung » Tue May 05, 2009 3:43 pm

Bob,

I looked at the DCP tab and they are all red as seen below. The last three lines are the same for each DCP and there is never a Not: If2_Constraint1 or simular line.

As for the if blocks conditions

if: ((u1 == 0) & (u2 ~= 0.0))

if1: ((u1 == 1) & (u2==0 ))

if2: u1 == 1 & u2 == 1
Attachments
clip_image002.jpg
clip_image002.jpg (149.3 KiB) Viewed 11800 times
jyoung
 
Posts: 33
Joined: Wed Mar 18, 2009 2:25 pm

Re: Compare to Constant

Postby busser » Tue May 05, 2009 3:56 pm

Okay, that does not look right. However, I believe you are using a developmental release of the simulink translator. I'm going to arrange to get you the latest pre-release version. It is likely to be the final release candidate, pending only some documentation updates. Actually, I do think there was a translator issue with the case of if-else blocks with no else cases, such as in your example. So, hopefully, that will clear up this issue. If not, then I'll need a copy of this model or a dummy model that replicates this problem.
busser
Site Admin
 
Posts: 52
Joined: Thu Mar 13, 2008 7:42 pm

Re: Compare to Constant

Postby busser » Tue May 05, 2009 4:41 pm

Okay, the issue that we were having with if- block translation was related to if-blocks that were set to not "show else condition".

if_block_no_else.jpg
if_block_no_else.jpg (84.42 KiB) Viewed 11787 times


Please try modifying your model by adding an "else" condition where the output is tied to a terminator.

if_else_block.jpg
if_else_block.jpg (73.81 KiB) Viewed 11790 times


I think that this will translate correctly. At least the pre-release version that I'm running right now does.
busser
Site Admin
 
Posts: 52
Joined: Thu Mar 13, 2008 7:42 pm

Re: Compare to Constant

Postby jyoung » Wed May 06, 2009 8:30 am

Bob,

This look like it has corrected the issue. I now get test vectors for 44/200 DCPs.

Will the next release of the translator be able to handle the if blocks without an else condition?

Thanks
jyoung
 
Posts: 33
Joined: Wed Mar 18, 2009 2:25 pm

Re: Compare to Constant

Postby busser » Wed May 06, 2009 9:55 am

Will be sending you an update this morning that will do so.
busser
Site Admin
 
Posts: 52
Joined: Thu Mar 13, 2008 7:42 pm


Return to General Topics

Who is online

Users browsing this forum: No registered users and 0 guests

cron