Four_Bit_Counter in VHDL

I am implementing four-bit-counter but I am getting value of x for Port_co
unter in auto-counting.
formatting link
(VHDL code) and http:/
/pastebin.com/2kY3hQAN (testbench). I already finished the two flip-flop in
VHDL. I am now stuck with simulation.
formatting link

Someone told me that the usual reason for an undefined output is failure t
o initialize all signal. So, I uncommented the clock_enable process and ch
ange the VHDL source to
formatting link
,but simulation just w
on't stop. Did I code my clock_enable process correctly?
even after I manually stop the simulation, the waveform window is EMPTY
Any help ?
Reply to
Marvin L
Loading thread data ...
I am implementing four-bit-counter but I am getting value of x for Port_cou nter in auto-counting.
formatting link
(VHDL code) and http:// pastebin.com/2kY3hQAN (testbench). I already finished the two flip-flop in VHDL. I am now stuck with simulation.
formatting link

Someone told me that the usual reason for an undefined output is failure to initialize all signal. So, I uncommented the clock_enable process and cha nge the VHDL source to
formatting link
,but simulation just wo n't stop. Did I code my clock_enable process correctly?
even after I manually stop the simulation, the waveform window is EMPTY
any help ?
Reply to
Marvin L
You are making this far too complex. You have one output signal, Port_Counter. You only need one process to drive that output. A signal should not be driven from more than one process or you get a error.
If you have intermediate signals to make your code simpler, you can define those in separate processes, but I don't think that is needed here. There are a lot of inputs which you don't say how they are used. I suggest you start with a simple enabled 4 bit counter and ignore the rest of the inputs for now. Then add code to add the functionality needed for the other inputs.
You see no waveforms in simulation likely because you have not added any waveforms to the display. There should be a control somewhere to add *all* the signals to the waveform display. Or you can add them one at a time. You didn't say which simulator you are using. If it is not ActiveHDL I can't help you with that. I suggest you run the simulation for a fixed amount of time rather than expecting it to stop. The clock will prevent the simulation from ever stopping on its own.
--

Rick C
Reply to
rickman
Your clock_enable process has no sensitivity list. This is OK for synthesis, but in simulation it causes an endless loop since there are no wait statements. If you had coded it as: wait until rising_edge(clk) instead of if rising edge (clk) then the simulation would advance. As written, you should have clk in the sensitivity list. Otherwise simulation will be stuck at time zero.
Also heed Rick's advice if you intend to synthesize this code.
--
Gabor
Reply to
GaborSzakacs
Someone told me to use
formatting link
instead of separate processes but it says try to AVOID this. Any advice ?
Reply to
Marvin L
rickman: Someone told me to use
formatting link
but it says try to AVOID this. Any advice ?
Reply to
Marvin L
Async loads generally show you are solving the problem wrong. Why can't you use a synchronous load?
--

Rick C
Reply to
rickman
rickman: this is the requirement given to me.
When a LOAD push-button is pressed, the counter is loaded asynchronously with a 4 bit VALUE set on a 4-bit DIP switch.
--> and then someone suggested to me that I do synchronization to handle it synchronously... I am not sure now
Reply to
Marvin L
I already done synchronization as stated in
formatting link

My code is at
formatting link
but I am getting value of x for Port_counter.
Please see
formatting link

Is it because of the separate process for LOAD that I am using ?
Reply to
Marvin L
If the requirement is to use an async load, then that is the requirement.
Again, you are assigning a signal in two processes. The async and sync logic need to be in the same process. BTW, they way you coded this, your reset is synchronous, not async. Just a practical note, in FPGAs a fixed value can be loaded asynchronously (that makes it the same as a pre/reset). But a signal can not be assigned to a FF asynchronously. It is *very* seldom this would ever be a requirement. This is just an exercise...
process(clk, load) begin -- everything before the if(rising_edge(... is async if (load = '1') then temp
Reply to
rickman
What are you synchronising? I presume this is the load input? If so then your load signal is no long an asynchronous signal and can implement a more reliable synchronous load.
A signal should only be defined in a single process. If you assume that you won't go wrong in that respect. As an example your 'temp' is assigned a value in two independent processes. It's like a contention in hardware.
--
Mike Perkins 
Video Solutions Ltd 
 Click to see the full signature
Reply to
Mike Perkins

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.