vhdl signal default value

Question

See the vhdl code below.

library ieee;
use ieee.std_logic_1164.all; 
use ieee.std_logic_unsigned.all;

entity newtestcpu is    
    port(   reset   :in     std_logic; 
            PC  :out    std_logic_vector(15 downto 0);
            IR  :out    std_logic_vector(15 downto 0)
        );
end newtestcpu;

architecture CPUArch of newtestcpu is   

BEGIN
process(reset) begin
    case reset is
        when '1'    => PC<=x"FF87";
        when others => IR<=x"aa01";
    end case;
end process;
end architecture ;

I Start Compilation & Simulation in Quartus II.

I give the reset in node Value Forcing Low(0) in the vwf file, and the Simulation Report tells that the PC out node Value 1111111110000111 (x"FF87"), and that the IR out node Value 1010101000000001 (x"aa01"), which confuses me!

It seems that reset has been 1 ! I wonder why.

scary_jeff · Answer 1 · 2016-01-11T13:23:59.750

1

Thanks to a comment, I realised that I miss-read the question, and that this does not actually solve your problem. However, I think it's worth making the suggested change despite this, so I did not delete the answer.

You have made the assumption that if reset is not '1', then it must be '0'. Under simulation, during initialisation, when all processes are run once, the value of reset will be 'U', that is, undefined. this will satisfy your when others case, and cause IR to be set. Even if you set reset to '1' at time = 0 ns, the others case will have been seen during the initial process run.

I would change your case statement as follows:

case reset is
    when '1'    => PC<=x"FF87";
    when '0'    => IR<=x"aa01";
    when others => NULL;
end case;

The other issue with your code is that something like this would normally be a synchronous (clocked) process. You are describing latches in this code, which is probably not what you want to do. There are plenty of other questions that cover this topic.

edited Jan 11 '16 at 13:23

answered Jan 11 '16 at 10:51

scary_jeff

4,314
13
27

1

I don't think that's the whole story : if Reset simply transitioned from 'U' to '0' then the assignment to PC should never have happened, so PC should be `UUUU`. To the questioner : I recommend writing a VHDL testbench for proper visibility, initialisation and control of the input signals. – Jan 11 '16 at 12:42
You're right @BrianDrummond, I didn't read the question properly – scary_jeff Jan 11 '16 at 13:20
During initialisation, when all processes are run once, the value of `reset` will be the intial value of the associated signal in the testbench. Of course, this will be often `U`, but it could be also `0` or `1`. – Martin Zabel Jan 11 '16 at 21:11

score 1 · Answer 2 · answered Jan 11 '16 at 21:58

When you simulate with a Vector Waveform File (VWF), Quartus-II actually simulates the behaviour of the synthesized netlist (checked here with Quartus-II 13.1). If you haven't run the step "Analysis & Synthesis", Quartus asks to do so. You have to always run this step manually, when you change your VHDL files before simulating the VWF again. The synthesized netlist is written out as Verilog code which will be the input of the ModelSim simulator. You can find it in the file simulation/qsim/newtestcpu.vo.

In your VHDL code you described latches for PC and IR. For example, PC is assigned the value "FF87" when reset is 1, but should save its value otherwise. The only other possible value for PC would be the inital value of this signal, which is "UUUUUUUU" because you didn't specified one. On the FPGA, we have only high or low level, thus, Quartus synthesizes this to a static value of "FF87" for output Q. You can see it also in the warnings reported during "Analysis and Synthesis":

Warning (13024): Output pins are stuck at VCC or GND
  Warning (13410): Pin "PC[0]" is stuck at VCC
  Warning (13410): Pin "PC[1]" is stuck at VCC
  Warning (13410): Pin "PC[2]" is stuck at VCC
  Warning (13410): Pin "PC[3]" is stuck at GND
  Warning (13410): Pin "PC[4]" is stuck at GND
  Warning (13410): Pin "PC[5]" is stuck at GND
  Warning (13410): Pin "PC[6]" is stuck at GND
  Warning (13410): Pin "PC[7]" is stuck at VCC
  Warning (13410): Pin "PC[8]" is stuck at VCC
  Warning (13410): Pin "PC[9]" is stuck at VCC
  Warning (13410): Pin "PC[10]" is stuck at VCC
  Warning (13410): Pin "PC[11]" is stuck at VCC
  Warning (13410): Pin "PC[12]" is stuck at VCC
  Warning (13410): Pin "PC[13]" is stuck at VCC
  Warning (13410): Pin "PC[14]" is stuck at VCC
  Warning (13410): Pin "PC[15]" is stuck at VCC
  ...

If you actually want to simulate the behaviour of the VHDL code (before synthesis), you have to write a VHDL testbench and setup this testbench in the "Assignments -> Settings -> Simulation" tab. Then run the "RTL Simulation" step.

score 0 · Answer 3 · edited May 23 '17 at 11:44

Your code does not define what state PC should get when reset = 0 and it does not define what state IR should become when reset = 1. Therefore the synthesizer will introduce latches where reset becomes a clock. This is most likely not your intention.

Have a look at VHDL: How to use CLK and RESET in process

Or study Ashden: The Designer's Guide to VHDL, which is really an excellent resource.

The most important thing to keep in mind when describing hardware with VHDL is that you are not writing software. Instead you need to imagine the hardware elements that the synthesizer is going to choose according to your description. Think in terms of wires, gates and flip-flops!

vhdl signal default value

3 Answers3