tiny code change leads to unexplainable system failure.

[tomdehavas]

I have been using a papilio pro with a OV7670 camera feeding a frame buffer made of block memory which is then used as the image source for a VGA generator driving the VGA wing. A simple change in the code from;

   outRGBWrite <= byte1(6) & byte1(4) & byte1(7) & byte1(5) & "00"; --Works!

to

   outRGBWrite <= byte1(6) & byte1(4) & byte1(7) & "000"; --Fails!

where;     

   outRGBWrite : out  STD_LOGIC_VECTOR(5 DOWNTO 0);

and

   SIGNAL byte0: STD_LOGIC_VECTOR(7 DOWNTO 0);
Clearly there was little logical sense in this change making such a difference. I eventually discovered that the top level has;

  reset: in STD_LOGIC;

the value of reset is '1' at startup and then should make the transition to '0', however in the failed case it stays at '1' leaving the system in the reset state. Some of my code set initial values when reset was 1 then doing stuff with those values when reset went to 0. If it never went to 0 the system never started.

 

FACT: I have been working with VHDL for approx 3 weeks so forgive me for not knowing where the reset signal comes from?

 

QUESTION: My problem is solved by ignoring the reset signal and initialising the variables in their declaration rather than letting reset initalise them but the question remains, how is the reset signal being corrupted by the simple change to the lines above that are totally not connected to reset in any way.

[alvieboy]

Can you post the whole code here ?

 

And yes, you will definitely want to use reset, because it is the only way for your system to behave in a predictable way.

 

And what is your reset source ? Is it ZPUino reset ?

[mkarlsson]

I eventually discovered that the top level has;

  reset: in STD_LOGIC;

the value of reset is '1' at startup and then should make the transition to '0', however in the failed case it stays at '1' leaving the system in the reset state. Some of my code set initial values when reset was 1 then doing stuff with those values when reset went to 0. If it never went to 0 the system never started.

 

The most likely scenario is that you don't have the reset signal allocated to a pin in your .ucf file (if it is assigned in the .ucf file then you know what's driving it ). 

 

If it's not allocated to a pin in the .ucf file then it gets randomly assign to a pin and is most likely floating.  This pin assignment might change from run to run if you change the code.

 

A good practice is to add PULLDOWN in the .ucf file to a active-high reset signal in case it's not driven.

 

Magnus

[tomdehavas]

Alvieboy  no I was wondering where reset was supposed to come from. There is no ZPUino. This is my own VHDL.I think mkarisson has the answer. The reset pin is not allocated and not in a ucf file so was presumably randomly allocated as suggested. I guess it was also left open and drifted depending on other factors in the code. Hence the unexplained sudden failures depending on seemingly unrelated changes! A bit like Heisenbugs in C!

 

Thanks to both.

 

I will post code at some point once I figure how to do it in a useful way. i.e. I don't want to post mess.