Re: SV-XC: VHDL Interoperability Survey Questions

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.

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.