Re: [myhdl-list] Restrictions for conversion

[Norbo <Nor...@gm...>]

Am 22.05.2012, 23:28 Uhr, schrieb Jan Decaluwe <ja...@ja...>:

> On 05/22/2012 10:41 PM, Norbo wrote:
>> Am 22.05.2012, 15:16 Uhr, schrieb Jan Decaluwe<ja...@ja...>:
>>
>>> On 05/05/2012 05:20 PM, Norbo wrote:
>>>
>>>> another point is that i think it is a good thing to have all the
>>>> variables
>>>> by default not to be initialized
>>>> with values in the converted code. Initialisation should only occour  
>>>> if
>>>> you really want to describe (pre-init RAM)
>>>> or ROM.
>>>> because for example in VHDL all the std_logic signals are set at  
>>>> startup
>>>> of a vhdl simulation to the value 'U' (stands for uninitialized) if
>>>> there
>>>> is no other initial value given. After the reset all values should  
>>>> have
>>>> changed from this
>>>> 'U' to something usefull. This allows you to see imidiatly if you have
>>>> messed up or missed something in the reset code.
>>>
>>> No, you don't see it immediately. You have to fire up a simulation,
>>> and then be lucky that the problem is not masked by logical
>>> operations.
>>
>> obviously there is no way around the simulation at least for setting the
>> reset for some time
>> to low and then to high.
>> What you forget is that the reset is asynchron, so the normal flip-flop
>> operation is "blocked" and no logical
>> masking or whatsoever will occour. You dont even have to apply a clock
>> signal to see it.
>
> What I mean is that you have to look for unitialized values
> specifically, on every signal, after a dedicated reset sequence

In myhdl it would be quit easy to iterate through the complete signallist.
Ok but there would still be a problem with the Registers that dont have a  
reset.
To make it a 100% coverage thing , the only rule to obey is, don't use  
Register without reset.


> Other simulations may not reveal any issue, even if there are
> unitialized values at the start.

For example in a plane vhdl simulation.
(This is bassically also my number one reason why the initial values from  
my point of view should not be written to
just every signal because then it wouldn't be possible to just look at the  
'U' signals, or in other words
  you have to look at every signal because you cant tell wheater the value  
comes from the initial or from the reset)

What i bassically do is:

open the waveformviewer, recursivly add all signals,
set the marker at the point of interesst,
scroll down, watch out for uninitialized values with 'U' (mostly red),
if there is a 'U' signal, check if its not from a Register without a  
reset  ->  100 % resetvalue set coverage


> But things may still go wrong
> at the gate level because RTL and gate level are only loosely
> related on this point.

Thats just a reason more, to somehow be able to verify it at least at the  
RTL level.



> I have also given considerable thought on the value of
> 'X' in digital design. A full explanation is very extensive,
> but my conclusion is that 'X' has no place in RTL design,
> and its value at the gate level is doubtful at best.

I completly agree with the 'X' but i am not so sure about the 'U'


But i came to understand that the 'U' concept, kind of involves the 'X'  
concept
and that the 'X' concept is not compatible with the intbv() integer  
concept, especially when
it comes to operaters like "&" or "|".

So in the end i kind of have to thank you for stopping me on continue  
implementing on something which is not reasonable feasible the way i  
thought.

greetings
Norbo