Isn't a wire just interconnect?

[simguru]

One would have thought that the meaning of "wire" in Verilog was obvious, but apparently not. According to some folks from Mentor & Cadence the semantics of wire changed at some indeterminate point in time (in the history of SystemVerilog) to be those of VHDL, and in order to add new type support we now have to use the word "interconnect" instead - see the generic interconnect proposal. The methodology for mixing types on a net was worked out for Verilog-AMS back around 1995, and is easily extensible to handle multiple discrete types (the goal of the SV-DC), however all that has been ignored, and yet another ill thought out hack applied to the language.

If you go to the length of reading the proposal above, you might like to read my alternative (here). I'd really like some feedback, I'm having a hard time working out if my tech writing is just incomprehensible, or nobody likes it.

Anyway, at this point it looks like it's too late to fix the insanity, and SystemVerilog continues on it's long slow controlled flight into terrain, while Verilog-AMS is in an indefinite holding pattern over at Accellera.

I could go on at length about how much of the effort spent on verification is wasted because the supporting infrastructure sucks, but I rarely run into anyone who actually cares. At last year's DAC I asked James Lin (Nat Semi) if he was going to send anyone to the committees that work on EDA standards (AFAIK I was the last), and he replied with an emphatic "no".

<script src="http://platform.linkedin.com/in.js" type="text/javascript"></script>
<script type="IN/Share" data-counter="right"></script>

 

[Daniel Payne]

I've used and taught some Verilog classes and the WIRE works just fine for SoC and FPGA designs, so I cannot comprehend why the standards group is adding yet another type called INTERCONNECT.

 

[LinkedIn]

No, a wire is just a wire with no abstraction. The generic interconnect is an abstract type which can be compared with its own type without knowing what that type is. Obviously this is more useful for test benches than design code.

Posted by Muzaffer

 

[simguru]

No, a wire is just a wire with no abstraction. The generic interconnect is an abstract type which can be compared with its own type without knowing what that type is. Obviously this is more useful for test benches than design code.
Posted by Muzaffer

I think you are going to have to expand on that. The argument from Gord (et al) was that "wire" is associated with the type "logic" and has some kind of associated hierarchical resolution scheme. Whereas the new "interconnect" has no associated type, so the only thing you could compare is the discipline (except they didn't include that concept).

Other HDL failings

 

[LinkedIn]

The nice thing about interconnect is that you can hookup thing without knowing what type they are. The example in the proposal where top has an interconnect and driver/comparator can change without changing top is a good example. Another nice thing would be that one can have two drivers and two object in "top" of type interconnect connecting two different drivers. One can still compare the two interconnect objects in top (ie drv_out_a == drv_out_b) without knowing what type they are.

The problem with reusing existing verilog types to handle this by something like overloading is the amount of mischief one can create by overloading default types. It's too error-prone and open to abuse.
Posted by Muzaffer

 

[simguru]

The nice thing about interconnect is that you can hookup thing without knowing what type they are. The example in the proposal where top has an interconnect and driver/comparator can change without changing top is a good example. Another nice thing would be that one can have two drivers and two object in "top" of type interconnect connecting two different drivers. One can still compare the two interconnect objects in top (ie drv_out_a == drv_out_b) without knowing what type they are.

The problem with reusing existing verilog types to handle this by something like overloading is the amount of mischief one can create by overloading default types. It's too error-prone and open to abuse.
Posted by Muzaffer

The whole "plug and play" approach is handled in Verilog-AMS without resorting to renaming "wire" as "interconnect" - that was one of the design objectives. The problem here is that if you insist "interconnect" is used instead of "wire" then no legacy code works properly, and you have to go fix a whole lot of things in the flow - i.e. you do one thing for old Verilog and another thing for (new) SystemVerilog. In particular you want to be able to reuse legacy code in new contexts, a goal of Verilog-AMS was to be able to back-annotate analog components (e.g. parasitics) into an otherwise digital flow - it would be nice to do the same with discrete models for those components in SV, but this proposal is unlikely to do that (my alternative does).

The thing that should have been fixed is the description of what the port connections actually do in Verilog. Nobody who works on Spice or Verilog thinks that it behaves the way that this proposal says it does, they've been collapsing ports (i.e. treating them as transparent/short) for years. Gord appears to come from a computer-science background and VHDL experience, and has a false understanding of the accepted semantics.

There was no problem with existing types that could not be handled by being strict about how cross-type driver resolution is performed. The "interconnect" proposal is just dysfunctional and unnecessary language bloat.

 

[simguru]

The other half (baked) piece of this is the user-defined type proposal.

Once again there was an opportunity to simplify things by moving the existing types from being "built in" to user space, and just allow the class types to be used as driver types, but instead we get a whole bunch of new syntax and dysfunctional semantics.

 

[simguru]

Just so you know who to blame later, the SV-DC reflector shows the voting results - E-mail vote on 3398

NB: unless you paid ~ $8000 you don't get to participate in the SV development process - System Verilog become IEEE-SA only

 

[simguru]

The generic interconnect is an abstract type which can be compared with its own type without knowing what that type is.

There are other ways to do that without having to replace "wire" with "interconnect", C++ uses overloaded operators so that code is polymorphic and you can add extra operator definitions as you need them. We treated "wire" as generic interconnect in Verilog-AMS and handled type bridging in "connect" modules - specifically to make it easy to use and backward compatible. The SV committee decided to ignore the work done in Verilog-AMS and did something inferior and probably unusable.

 

[UlricWihey]

A wire is just a wire with no abstraction.



----------------------------------------------
Good to the last second--DVD sales online.