Re: 4 State Logic Proposals

From: John Stickley <John_Stickley_at_.....>
Date: Thu Oct 13 2005 - 14:12:47 PDT
Jason,

A couple of comments,

Jason Rothfuss wrote:

> 
> Allowing only 2-state types to be passed from HW->SW removes the need

johnS:
I think this was a typo - you mean SW->HW here right ?


> for coercing 4-state values into 2-state values, and promotes a better
> modeling style.
> 
> This approach would be fairly simple to enforce:
> 
>         export "DPI-C" function callme;
>         function void callme;
>                 input  logic [31:0]  badarg;   // This would be an error
>                 input  bit   [31:0]  goodarg;  // This would be OK
>                 output logic [31:0]  goodarg1; // This would be OK
>                 output bit   [31:0]  goodarg2: // This would be OK
>                 begin
>                 end
>         endfunction

johnS:
What if we said that 'badarg' is not an error but just a forced
coercion to 2-state ?

I think this is in line with what Per, in his response to your
e-mail, said would satisfy Russ's requirements.

I think it would also still accomplish the goal of removing
ambiguity of "undefined" behavior which I think you are trying to
do. For portability reasons, I'm not comfortable with "undefined"
behavior either and I think it is worth removing any possibility
of it.

I guess the only hole I see in this revised version of your proposal
is that if X or Z values are passed from HW by a simulator that supports
4-state, the C-models may behave differently than the same models
running on a simulator that only supports 2-state. But this may be OK.

In former case a C model might flag errors, or warnings for
undefined's it sees and in the later case, the same C model
would not see X or Z values and therefore happily process the
0's and 1's that it does see.

I guess in that sense the model would be portable, just behavior
would be different right ?

-- johnS
<eom>

> 
> With this proposal, there is no "undefined" case, since 'logic' data
> types are only supported as outputs in exported DPI functions, and as
> inputs in imported DPI functions.
> 
> Regards,
> Jason
> 
> 

-- 

This email may contain material that is confidential, privileged
and/or attorney work product for the sole use of the intended
recipient.  Any review, reliance or distribution by others or
forwarding without express permission        /\
is strictly prohibited. If you are     /\   |  \
not the intended recipient please     |  \ /   |
contact the sender and delete        /    \     \
all copies.                      /\_/  K2  \_    \_
______________________________/\/            \     \
John Stickley                   \             \     \
Mgr., Acceleration Methodologies \             \________________
Mentor Graphics - MED             \_
17 E. Cedar Place                   \   john_stickley@mentor.com
Ramsey, NJ  07446                    \     Phone: (201) 818-2585
________________________________________________________________
Received on Thu Oct 13 14:14:24 2005

This archive was generated by hypermail 2.1.8 : Thu Oct 13 2005 - 14:14:38 PDT