entity my_entity is port ( clock : in std_logic; reset : in std_logic; input_signal : in std_logic; output_signal : out std_logic; output_complete_signal : in std_logic ); end my_entity;
architecture RTL of my_entity is
signal local_signal : std_logic; signal local_flag : std_logic;
begin
process ( clock, reset ) begin if ( reset = '0') then output_signal
Simon, I noticed that local_signal gets set in two seperate if - end if sections. If both sections are true, the second one wins, IIRC. This can be confusing, so I endeavour to avoid this in my code. You might want to merge the two sections with an else.
You could always try simulating it with a testbench to check you get what you want? Or code it as a FSM so it's more readable?
BTW, I recommend using rising_edge(clock) instead of that clock'event stuff. It not only saves typing but works better in simulations when things can change from other than '0' to '1'.
Finally, do you know about comp.lang.vhdl? They love this stuff! :-) HTH & Cheers, Syms.
Thanks for your response,
This code snippet is actually a structural representation of my actual code (which is much more complex). I am experiencing some strange behaviour where although 'input_signal' is only held high for one clock cycle (by another process, but using the same clock) the 'output_signal' is asserted twice, or so it appears. I was wondering if the structure of my code (and my coding style) would cause this situation to occur. It only appears to present itself on 'real-hardware' in the 'simulator' I cannot repeat the strange behaviour.
Regards,
Simon
Hi Simon, Is it in a device with a soft logic analyser available like Chipscope? Are any of the inputs asynchronous to the clock? Cheers, Syms.
Hi Simon, the simple answer is : No.
More complex: What do you want it do do? To me the code looks like a complicated shift register with a priority encoded output generation. Question: Do you want to build a shift register? Do you want a priority encoder?
The pitfall in your code may be that you are using multiple ifs in a single clocked process and work with signals.
Signal values are only updated at the end of the process, So when you set local_signal
Syms,
The strange behaviour that I am experiencing is in 'real-hardware' I am monitoring this behaviour from two different aspects:
1) The effects that it has on the rest of my design 2) A built in test function that essentially consists of counters distributed throughout the code and a method of recording the values of the counters and presenting the information (through the use of register access and a processor)The inputs to the code are synchronous to the clock.
Simon
Eilert,
The main purpose of this code is to recognise when 'input_signal' is high and then set 'output_signal' high and then wait for 'output_complete_signal' to be high before setting 'output_signal' low.
The complexity comes into it where 'input_signal' is accompanies by a data signal and depedant on that data one of many 'output_signals' are set high and a corresponding 'output_complete_signal' is monitored instead. However, the structure of the code is the same, just expanded.
Answer, I don't want a 'shift-register' and am not familiar with the functionality of a 'priorty-encoder'.
The behaviour that you described is exactly how I intended it to behave.
The behavioural simulation operates correctly, I have not done a timing simulation (and cannot for other reasons).
Regards,
Simon
When 'reality' differs from simulation with the symptoms you've described it's usually a timing problem of some sort so double check the timing reports out of the fitter and make sure that it agrees with you that the inputs to the process (reset, input_signal and output_complete_signal ) really are synchronized to 'clock'. Although you're using 'reset' as an asynchronous input to clear your outputs the timing of reset still needs to be synchronized to clock. Ask yourself what happens when 'reset' switches from '1' to '0' 'too close' to the rising edge of 'clock'. If you violate timing then you really don't know what the outputs are going to go to and since what you have is basically a form of a state machine you're probably hosed.
If 'reset' really is asynchronous then sync it up first before using it in any clocked process.
The actual 'form' of how you write the code is not the problem. The posts about the structure of the 'if' statements will likely improve the quality and maintainability of the code but it will not change functionally how simulation or reality behave since it is a 'coding style' issue.
KJ
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.