The terms keep changing with the time, but one has to start looking at the definitions adopted by the standardization group of SystemC TLM2.0. The work led to the definition of two coding styles:
- Loosely-timed (temporal decoupling, only sufficient timing detail to boot O/S and run multi-core systems)
- Approximately timed (cycle approximate, cycle count accurate, enough
details for architectural exploration)
1)
The pin accuracy is at the interface level that is the communication part of the model. Transaction level modelling hides the pins by use of function calls between different processes. The functions are implemented either at the channel level or provided by Export mechanisms. As long as your testbench/model does not have the purpose to communicate with synthesis-ready RTL with real pins, TLM is usually sufficient and faster in terms of simulation time. Bit accuracy is how your data is being represented inside your Computation processes. It is the accuracy of your different datapaths be that ALU operations, DSP operations, Pixels representations, ... etc. In systemC for example, if you are not very concerned about the format of your data then you can as well use built-in C++ datatypes such as int to speedup the simulation time. But if you want to investigate the data from bit width perspective, truncation, saturation, .. etc then you should use systemC built-in datatypes and define your own size of the vectors. Drawback: slower simulation time.
Now, you can see that both concepts are not necessarily correlated, as you can for example be in a situation where you want your computation model to be data format accurate (bit accuracy) whereas you care or less about how you send it/produce it for other processes and end up using TLM functions (No pin accuracy), and the other way around.
2)
For an RTL model, functional accuracy doesn't necessarily mean bit accuracy. (We agreed that pin accuracy is out of the game here). You can ensure the correctness of the functionality without using a defined bit width in your model. If you are modeling a multiplier then you can write C=A*B into your model and the result is calculated by means of simulation software and compared to the result of your perhaps Pipelined RTL multiplier. The function/result is still correct as long as you use enough bits in your model but doesn't have to be exactly the same.
Now for the timing accuracy, imagine that you have a SPI interface that reads sampled data from an ADC every 40 ns. In your RTL, you will use a clock, a counter, a condition to check the counter reached enough cycles to make 40 ns then initiate the read operation. You can do the same in your model by one single wait statement without even using a clock. Now, your model is not cycle accurate but it is timing accurate :)