FPGA Central - World's 1st FPGA / CPLD Portal

FPGA Central

World's 1st FPGA Portal

 

Go Back   FPGA Groups > NewsGroup > FPGA

FPGA comp.arch.fpga newsgroup (usenet)

Reply
 
LinkBack Thread Tools Display Modes
  #1 (permalink)  
Old 04-19-2006, 12:22 PM
Guest
 
Posts: n/a
Default 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;

Reply With Quote
  #2 (permalink)  
Old 04-19-2006, 01:28 PM
Symon
Guest
 
Posts: n/a
Default 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.


Reply With Quote
  #3 (permalink)  
Old 04-19-2006, 07:03 PM
Guest
 
Posts: n/a
Default 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

Reply With Quote
  #4 (permalink)  
Old 04-19-2006, 07:38 PM
Symon
Guest
 
Posts: n/a
Default 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.


Reply With Quote
  #5 (permalink)  
Old 04-20-2006, 08:47 AM
backhus
Guest
 
Posts: n/a
Default 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

Reply With Quote
  #6 (permalink)  
Old 04-20-2006, 11:29 AM
Guest
 
Posts: n/a
Default 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

Reply With Quote
  #7 (permalink)  
Old 04-20-2006, 12:02 PM
Guest
 
Posts: n/a
Default 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

Reply With Quote
  #8 (permalink)  
Old 04-20-2006, 01:36 PM
KJ
Guest
 
Posts: n/a
Default 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


Reply With Quote
Reply

Bookmarks

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
Is this wrong behavior? Neo Verilog 7 09-20-2007 06:49 AM
what wrong of this counter ? kelvins FPGA 4 04-17-2006 06:54 PM
What's wrong with this verilog? Davy Verilog 3 07-04-2005 09:14 AM
what's wrong in this code Sridhar_Gadda Verilog 4 10-12-2004 09:33 PM
What am I doing wrong here? Thomas Womack Verilog 3 10-09-2004 07:02 AM


All times are GMT +1. The time now is 09:36 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