FPGA Groups

FPGA Groups (http://www.fpgacentral.com/group/index.php)
-   FPGA (http://www.fpgacentral.com/group/forumdisplay.php?f=14)
-   -   Is there anything fundamentally wrong with this code? (http://www.fpgacentral.com/group/showthread.php?t=58381)

[email protected] 04-19-2006 12:22 PM

Is there anything fundamentally wrong with this code?
 
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 <= '0';
local_signal <= '0';
local_flag <= '0';
elsif ( clock'event and clock = '1') then

if ( input_signal = '1' ) then
if ( local_signal = '0' ) then
local_signal <= '1';
end if;
end if;

if ( local_signal = '1' ) then
if ( local_flag = '0' ) then
local_flag <= '1';
output_signal <= '1';
else
if ( output_complete_signal = '1' ) then
output_signal <= '0';
local_flag <= '0';
local_signal <= '0';
end if;
end if;
end if;

end if;
end process;


Symon 04-19-2006 01:28 PM

Re: Is there anything fundamentally wrong with this code?
 
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.



[email protected] 04-19-2006 07:03 PM

Re: Is there anything fundamentally wrong with this code?
 
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


Symon 04-19-2006 07:38 PM

Re: Is there anything fundamentally wrong with this code?
 
<[email protected]> wrote in message
news:[email protected] oups.com...
> 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.
>

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.



backhus 04-20-2006 08:47 AM

Re: Is there anything fundamentally wrong with this code?
 
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 <= '1'in your first if that value is not immediately
visible to the next if. It becomes visible at the next rising clock
edge.

But if that is what you want, it's ok.
Is your behavioral simulation working correctly?
Have you made a timing simulation too?

have a nice synthesis

Eilert


[email protected] 04-20-2006 11:29 AM

Re: Is there anything fundamentally wrong with this code?
 
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


[email protected] 04-20-2006 12:02 PM

Re: Is there anything fundamentally wrong with this code?
 
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


KJ 04-20-2006 01:36 PM

Re: Is there anything fundamentally wrong with this code?
 
<[email protected]> wrote in message
news:[email protected] oups.com...
> 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.


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




All times are GMT +1. The time now is 09:49 PM.

Powered by vBulletin® Version 3.8.0
Copyright ©2000 - 2020, Jelsoft Enterprises Ltd.
Search Engine Friendly URLs by vBSEO 3.2.0
Copyright 2008 @ FPGA Central. All rights reserved