RE: [sv-bc] RE: Value propagation in Parameter with Type

(Replying to http://www.eda.org/sv-bc/hm/11546.html .) Since IEEE Std 1364-2001, it has been possible to write

parameter integer p2 = 2'sb11 ;

but that was almost never used, even though in most actual designs it would accurately express the intent. Inferring the type of the parameter from the self-determined type of the expression was not the best idea ever, as apparently was clear to the committee by 2001. (I wasn't there, I can only speculate.) But instead of removing that not-good idea from the standard, they preserved backward compatibility. Sure, if they had removed it, there would probably still be users in 2014 demanding and using options to support it anyway, but at least it wouldn't be supported by default.

Why does no one use the above syntax? Because it's clunky, and omitting it rarely caused obvious problems. So why not just make integer the default parameter type? Yes, it would have broken backward compatibility on a few designs, but that's the nature of every journey out of error. Minor course corrections are inevitable if you want to get to a better place.

The same story can be told about the static lifetime default for functions (outside of classes). Again, not the best idea, hence the 'automatic' workaround of 2001. But nobody used it, because it's clunky, and omitting it rarely caused obvious problems. So why not make automatic lifetime the default as in other languages, and add the 'static' keyword for the unusual case, as in other languages? Again, because of backward compatibility on a very few designs.

Almost every Verilog/SV tool has variables to control the standard setting. Why would it be such a big deal to say that if you have legacy code that worked back then, but is rejected by more recent standards, then roll back the standard setting when you read that code? Why is backward compatibility with every not-good idea that ever was such an overriding principle? The one glorious exception was the redo of generate in IEEE Std 1364-2005, even though it causes support problems to this day, because of unwillingness to modify legacy code.

-- Brad


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