Re: SV-XC: VHDL Interoperability Survey Questions

John Shields wrote:
> Hi Kevin,
>
> Your answers, and I intentionally over-simply them with no malice 
> intended, tend to say, " I want everything you've thought of."  What I 
> would to see in the questions we ask is evidence of what is behind the 
> requirements.  That is why I would like use to ask about use cases.  
> What do you want to do, and how do these features support that?  If 
> your answer is a proxy for needs you think others will have, that 
> requires some explanation and is inherently weaker than your own real 
> needs.  Nevertheless, with those explanations it is valuable input. 
> Now, I will not get ideal results back from my questions either.  My 
> point is that we will need to determine priorities and justification 
> for the things requested ultimately.  If the answers we get don't 
> help, we'll have to judge for ourselves. Again, I am not criticizing 
> your input, just asking for more input to address  the concerns we 
> have.  Your answer to 4 a) is telling in terms of that.  So what is it 
> about packed structs that makes you say, yes eventually?
>
> Anyway, don't just answer my last question.  Help re-phrase the 
> questions to get that information we need, if you can.
No prob.

For background, at Sonics we are currently using Verilog/SystemVerilog 
with SystemC and TestBuilder (C++), previously at Nat. Semi. I worked 
with a (cumbersome) Verilog/multi-threaded-C++ test environment, and I 
designed a lot of the MS boundary stuff that's in Verilog-AMS.

My view is that you need to look at the big picture and all the things 
that you might want/need to do, and try to find solutions - then cut 
back to core requirements to fit whatever the schedule is. If you start 
out just considering the core requirements and not the harder stuff then 
you are likely to run into problems when you start on the harder stuff 
and discover it doesn't fit with what you have already committed to a 
standard.

For 4. I'd say the core requirement is to support the types common to 
all simulators, which excludes structs/records and dynamic types but 
includes some types of array (1-dimension,scalar).

7 probably needs restated: if you want to do signal resolution across 
the simulator/language boundaries then you need to communicate values 
and strength, and if you want to handle X's then you need probability 
too, and you need to do it for drivers rather than signals. So the core 
requirement for that (SystemVerilog & Verilog-AMS for me personally) is 
probably 4-state plus strength, but it seems likely (to me) that folks 
will also want to use VHDL and Verilog-AMS so it'll probably need a more 
abstract mechanism. Additionally if you want to do accurate timing on 
the boundary (for AMS) that requires being able to query what's pending 
on a signal's drivers.

Kev.

>
> Regards,
> John
>
> Kevin Cameron wrote:
>>
>>> Subject:     SV-XC: VHDL Interoperability Survey Questions
>>>
>>>
>>> 1. What kinds of Verilog/SystemVerilog items would you like
>>>    to be able to instantiate from VHDL and vice versa?        - 
>>> Modules/Architectures
>>>        - SV Interfaces
>>>        - SV Program Blocks
>>>   
>> Modules/Architectures at a minimum, is it necessary to know what type 
>> of thing is being cross-instantiated?
>>> 2. Would you like to have an integrated mechanism for    configuring 
>>> instantiations at a language boudnary?   
>> Yes, I think it'll be necessary to add a mechanism to identify 
>> rep-stops (where the current language/representation ends) into the 
>> configuration mechanisms for all the languages (if they don't 
>> currently support that).
>>> 3. What kinds of objects would you like to connect in an
>>>    instantiation that crosses a language boundary?
>>>        - Parameters/generics
>>>        - Ports that are nets/signals
>>>        - Ports that variables
>>>        - Shared/reference variables
>>>        - Other. Please explain.
>>>   
>> Yep, all of those :-)
>>> 4. Data type support for constant objects
>>>
>>>   a. What kinds of data types would you like to see supported
>>>      on parameters/generics at a language boundary?
>>>        - Bit
>>>        - 4-state logic        - Real
>>>        - Time
>>>        - Dynamic data types. If so, which ones?
>>>        - Enumerations
>>>        - Arrays of bit/logic
>>>        - Arrays of other data types. If so, what data types?
>>>        - Structs/Records. If so, packed, unpacked, or both?
>>>        - Other. Please explain.
>>>
>>>   b. Please list any data type mappings (e.g. VHDL std_ulogic
>>>      to Verilog logic) that are particularly important
>>>   
>> a) I'd say all of them eventually, so it's maybe better to ask for a 
>> priority.
>>> 5. Data type support for signals
>>>
>>>    a. What kinds of data types would you like to see supported
>>>       on nets/signals at a language boundary?
>>>        - Bit
>>>        - 4-state logic with strength
>>>        - Real
>>>        - Time
>>>        - Enumerations
>>>        - Arrays of logic
>>>        - Structs/Records
>>>   b. Please list any data type mappings (e.g. VHDL std_ulogic
>>>      to Verilog logic) that are particularly important
>>>   
>> as above.
>>> 6. Data type support for signals
>>>
>>>    a. What kinds of data types would you like to see supported
>>>       on variables at a language boundary?
>>>        - Bit
>>>        - 4-state logic        - Enumerations
>>>        - Arrays of bit/logic
>>>        - Arrays of other data types. If so, what data types?
>>>        - Structs/Records. If so, packed, unpacked, or both?
>>>        - Real
>>>        - Time
>>>        - Dynamic data types. If so, which ones?
>>>        - Other. Please explain.
>>>
>>>   b. Please list any data type mappings (e.g. VHDL std_ulogic
>>>      to Verilog logic) that are particularly important
>>>   
>> as above.
>>> 7. What network semantics would you like to preserved across
>>>    a language boundary?
>>>        - 2-state
>>>        - Multiple drivers
>>>        - trireg
>>>        - bidirectional transistor networks
>>>        - Verilog strength
>>>        - Other. Please explain.
>>>   
>> All of those too :-)
>>
>> I think any APIs developed should be able to support connecting two 
>> (or more) simulators for the same language (or similar languages), 
>> i.e. if you split a design across say VCS & NCverilog it should work 
>> as near the same as the unsplit design as possible.
>>
>>> 8. What kinds of behavioral code would you like to be able to call
>>>    across a language boundary?
>>>        - Functions
>>>        - Tasks
>>>        - Procedures   
>> All for the reason above.
>>> 9. What kind of integrated interprocess synchronization would you 
>>> like    to see in a mixed-language simulation (events, semaphores, 
>>> etc.)?
>>>    Please explain.
>>>   
>> Not sure about semaphores, I think the event stuff will probably just 
>> be a subset of signal handling.
>>
>> Is anyone thinking of tackling actual parallelism, or are we assuming 
>> single thread of control?
>>
>>> 10. Would you like an integrated I/0 mechanism?
>>>   
>> Of course :-)
>>> 11. Would you like to have integrated access to timing backannotation
>>>    (Verilog SDF and VHDL VITAL)? Clocking blocks?
>>>   
>> SDF support is probably essential.
>>> 12. Would you like to see VPI extended to reach across languages
>>>    to other APIs (e.g. VHPI)?
>>>   
>> If you mean that tools using current  VPI/PLI/VHPI should not need to 
>> be modified to cope with a multi-language simulation environment: yes.
>>> 13. Would you like to be able to directly reference objects
>>>     that are declared in a different language (through a hierarchical
>>>     reference)? If so, what kinds of objects, and from what contexts?
>>>   
>> Signals.
>>
>> Kev.
>>
>>
>
>


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.