Provide more types in physical.vhdl

[cmarqu]

physical.vhdl does not contain all physical types that are commonly used for e.g. modelling analog circuits, like voltage, current, resistance etc.
Maybe we should even mirror the VHDL-AMS packages and their types one-to-one, the list of which is at http://repo.or.cz/emacs.git/blob/HEAD:/lisp/progmodes/vhdl-mode.el#l5057

[cmarqu]

Also, having worked with my own physical types in the past, I have found that at least for currents, the range of values that can be expressed with integer'high is too limiting.
It has worked for me to "manually" specify a very high number somewhere near 2^64 (I don't have the code anymore), but that is probably highly simulator-specific (and probably also host-architecture specific, and whether you have a 32- or 64-bit executable).
Some configurability may be required - lacking a macro capability, maybe by generating files.

[Paebbels]

Are voltages, currents, ... a digital problem or do we drift into the AMS world?

For my 3 proposed units:

• freq - sometimes it's better to calculate in frequencies then in times/delays
• baud - used for slow I/O controllers e.g. UART
• memory - used to calculate addres ranges, caches, ...

Can use present use cases?

[cmarqu]

(Brief since I am limited to a phone)
In the ASIC world, when you have analog components, it's quite a big thing to use "real value modeling" (RNM) which does not do full AMS (ie. with an analog solver in the mix) but just uses the digital simulator for speed and less license costs. "Digital VHDL" was always able to transport reals over ports, but only Verilog-AMS (not using an analog code section) with the wreal port type and SystemVerilog 2012 can do that now too.
I would be modeling basically everything that is an analog schematic, be it sensors with a "mechanical" input (pressure) or temperature or capacitance etc. with voltage output, and of course amplifiers, bias current generators and ADCs too. And I want my models pin-compatible to the schematics.
Resolution functions for e.g. currents are summing up, for voltages you would produce Xes (unless their values match maybe).

[Paebbels]

OK that makes sense. Would you implement all in one file or in multiple files? The currently proposed package is quite huge and it only covers 4 types (the 3 from above and extensions for time). Can we use a frontend package and split implementations across files? Maybe we should dig for the partial package proposal in P1076 :).

[cmarqu]

I'd mimic the separation of the "natures" in VHDL-AMS, and keep everything except the types themselves in _support packages I guess. Yes, they will be big, and they probably need to be generated in some way.