Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

Help needed for timing problem with Xilinx ISE

Status
Not open for further replies.

sanjay

Full Member level 1
Joined
Jul 4, 2003
Messages
98
Helped
0
Reputation
0
Reaction score
0
Trophy points
1,286
Activity points
1,012
xilinx fpga timing problems

Hi there,

Just while trying to get outselves familar with the xilinx and spartan, we trying to implement common projects first. Everything is going fine except the timing on the device. Help would be appreciated

To give u an overview first

Project Name : Binary Up/Down counter
Device : Spartan XCS10 4pc84
Frequesncy : 25 Mhz
Tools using : Xilinx ISE Software, Synplify 7.3 ( for synthesis purposes )
Model SIm ( timing simulation )

Code :

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;

entity Counter is

Generic(Delay: Time := 1000 mS);
Port (CLK: in STD_LOGIC;
RESET: in STD_LOGIC;
CE, LOAD, DIR: in STD_LOGIC;
DIN: in STD_LOGIC_VECTOR(3 downto 0);
COUNT: inout STD_LOGIC_VECTOR(3 downto 0)
);
end Counter;

architecture Behavioral of Counter is
begin
process (CLK,RESET)
begin
if RESET='1' then
COUNT <= "0000";
elsif CLK='1' and CLK'event then
if LOAD='1' then
COUNT <= DIN;
else
if CE='1' then
if DIR='1' then
COUNT <= COUNT + 1 after Delay;
-- Debugging : gives a message
report "Count Value incremented";
else
COUNT <= COUNT - 1 after Delay;
-- Debugging : gives a message
report "Count Value decremented";
end if;
end if;
end if;
end if;
end process;
end Behavioral;

This is the code.
As you might have observed we delaying the leds on the board after every 1 second.

Now everything is going on fine.. No problem
But when we run it on the development board the LEDS stay permanently On ( its counting but counting toooo fast )

We checked for following :

1.Timing Simulation : Runs perfectly the way it should. Increments or Decrements the LED after 1 second.
2.Checked timing reports. there we saw one thing which is as following

Constraint | Requested | Actual | Logic Levels
--------------------------------------------------------------------------------
TS_CLK = PERIOD TIMEGRP
"CLK" 40 nS HI | 40.000ns | 15.050ns | 4
GH 50.000000 %
--------------------------------------------------------------------------------
OFFSET = OUT 40 nS AFTER
COMP "CLK" | 40.000ns | 9.235ns | 1
--------------------------------------------------------------------------------
OFFSET = IN 40 nS BEFORE
COMP "CLK" | 40.000ns | 15.452ns | 4
--------------------------------------------------------------------------------

Seeing this report during the place and route phase it appears that somehow it instead of 40ns which is wht we require its using its own timing.

Help would be appreciated..if someone can suggest toget the ACTUAL also to 40ns

Thanks

Sanjay
 

xilinx ise delay

I could not clearly understand your requirement.

I guess you want a up/down counter to drive LEDs on the board.

With your code and the period of the clock i see in the report, no surprises you are not able to find the LEDs toggling. The clock's too fast.

First thing about your code is that you are using delay. Delays are not synthesisable. They work only in simulation.
You say that it's working fine in timing simulation while your timing report is not as you expected. I doubt if you are doing timing simulation really. Please recheck!!
For your current design, if you want the leds to toggle every 1 sec, you have to feed the fpga a clock with period 1 sec.

If you want to feed a clock with higher frequency, you may have to divide the clock and convert it into a slow clock/ clock enable to generate a signal what you expect.
 

xilinx+offset+timing+examples

My guess is that this design needs a better placement or that you should pipeline more to limit the length of paths between registers.

Open the timing analyzer and check your problems there. Find out the problem paths and check them in the FPGA editor. I am sure you will see what I mean.

tcn
 

debugging timing problems vhdl xilinx

sanjay said:
Project Name : Binary Up/Down counter
Device : Spartan XCS10 4pc84
Frequesncy : 25 Mhz
Tools using : Xilinx ISE Software, Synplify 7.3 ( for synthesis purposes )
Model SIm ( timing simulation )

This is the code.
As you might have observed we delaying the leds on the board after every 1 second.

Now everything is going on fine.. No problem
But when we run it on the development board the LEDS stay permanently On ( its counting but counting toooo fast )

We checked for following :

1.Timing Simulation : Runs perfectly the way it should. Increments or Decrements the LED after 1 second.
2.Checked timing reports. there we saw one thing which is as following

Constraint | Requested | Actual | Logic Levels
--------------------------------------------------------------------------------
TS_CLK = PERIOD TIMEGRP
"CLK" 40 nS HI | 40.000ns | 15.050ns | 4
GH 50.000000 %
--------------------------------------------------------------------------------
OFFSET = OUT 40 nS AFTER
COMP "CLK" | 40.000ns | 9.235ns | 1
--------------------------------------------------------------------------------
OFFSET = IN 40 nS BEFORE
COMP "CLK" | 40.000ns | 15.452ns | 4
--------------------------------------------------------------------------------

Seeing this report during the place and route phase it appears that somehow it instead of 40ns which is wht we require its using its own timing.

Help would be appreciated..if someone can suggest toget the ACTUAL also to 40ns

Thanks

Sanjay

First of all, I know nothing about VHDL, but it seems that your goal is to make the LED blink every one second. For a 25MHz clock frequency, you approximately need a 25-bit register to sequentially count, and connect the MSB to port LED. The report timing only tells you it needs 15ns or so for signal to propagate through your circuits (the most critical one), and this has nothing to do with its practical operating speed(only depends on your clock frequency for synchronous design). In more simple words, it means "congratulations! your design's passed the timing requirements"...
I think your problem is that you use a less-bit counter(4-bit, right?) in your design...and probably the delay 1 sec in the code is only for functional simulation convenience, and may not synthesizable...(synthesizer would ignore the statement...)
hope my lame-English explanation help... :p
 

4 bit counter c using xilinx c code

Hi!

First don't use Generic(Delay: Time := 1000 mS); and I think your IN and OUT OFFSET is not as it should be. 40ns is to high.

Second, I suggest you to create a 5 bit counter and use the MSB bit (5) to on/off your LEDs.

Bart
 

xilinx ise clock enable

Hi guys,

thnks a lot for ur suggestions.
The idea of counter thing suggested did seemed to work quite nicely indeed.

Help is gladly appreciated

Thnks
 

xilinx counter problem

Hi,

"AFTER" IS NOT SYNTHESIZABLE, RIGHT? 8O

That's it.

You can't use in RTL code:
COUNT <= COUNT + 1 after Delay;

only in behavioural code.

You need to create a counter using the CLK you have to generate and strobe every second, that strobe is your DELAY signal.

maestor
 

xilinx ise software abstract

Dear Sanjay
I think you need to be familiar also with VHDL synthesizable codes also. AFTER is not synthesizable it is for simulation only. refer to the synthesizer manual or a text book to know more about synthesizable coding.
 

xcs10 project

Your problem is definitly (and as mentioned above) that your code is not synthesisable. Effectivly you have mixed "behavioral" and "synthesisable" VHDL, and whilst it will work fine in simulation, it is not reproducable in reality. How does "after" relate to gates and flip-flops? It doesn't. You probably need to implement the delay as another counter - see the following code - I've just thrown it together, so now guarantees that it works. :)

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;entity Counter is

Generic
(
Delay : natural := 1000 -- number of ms per increment
);
Port
(
CLK : in STD_LOGIC;
RESET : in STD_LOGIC;
CE, LOAD, DIR : in STD_LOGIC;
DIN : in STD_LOGIC_VECTOR(3 downto 0);
COUNT : inout STD_LOGIC_VECTOR(3 downto 0)
);
end Counter;

architecture rtl of Counter is

signal slow_cnt : natural;
signal slow_rollover : natural := 25000000*(Delay/1000); -- assume 25MHz clock
signal slow_tick : boolean;

begin

process (CLK,RESET)
begin
if reset = '1' then
slow_cnt <= 0;
slow_tick <= false;
elsif rising_edge(CLK) then -- why do people still use 'event ?????
if slow_cnt = slow_rollover then
slow_cnt <= 0;
slow_tick <= true;
else
slow_cnt <= slow_cnt + 1;
slow_tick <= false;
end if;

if LOAD='1' then
COUNT <= DIN;
elsif slow_tick then
-- small problem of interaction between CE and slow_tick
if CE='1' then
if DIR='1' then
COUNT <= COUNT + 1;
else
COUNT <= COUNT - 1;
end if;
end if;
end if;

end if;
end process;
end rtl;
 

actual period xilinx

I have to disagree with Bartart (above) though - "Generic" is very uesful in synthesisable code, and should be used to make entities more general purpose. For example, the above code that I've posted could have any delay at all, and the resource utilisation would scale to match, every time it was synthesised.

J
 

problems with xilinx update

Generic are useful and... "records" (for instance) are also useful in VHDL but you need to get use to them and they become very powerful.

I find generics very useful in reusable modules, FIFOS, RAMS, CRC Generator/Checkers, PRBS... and of course in IP design.

- Maestor
 

defining timings xilinx ise

I couldn't agree more Maestro - records, funtions, generics and other advanced stuff are all very useful and powerful when used properly and are easily synthesised, provided you know what you're doing.

There seems to be a strongly entrenched attitude in the industry that "synthesisers are rubbish" and thus all VHDL must be written likes it's a circuit diagram- ie: std_logic is the only type ever used, functions are forbidden, etc. This totally defeats the purpose of using an abstract langauge - people don't write C++ like it's assembly language do they?

The power of VHDL is that you can abstract away from the hardware and think of solutions in more general terms, without worrying about the "bits and bytes". The art is far from perfect, and there are many traps for newcomers (see the "after" problem above), but it sure beats thinking about your designs in terms of gates and flip-flops.

J
 

xilinx ise timing simulation

There is a huge difference in what VHDL supports as a language and the constructs that can be readily converted to physical hardware. For simulation, "after" statement is fine but worthless in physical design. Think about it. How can an FPGA wait for 1000 ms while its real time and all signals are latched as soon as certain other signals are asserted in a logical way. It is not a processor after all. Even delays in microprocessors are generated through timers and counters which are hardware.

Hence you need to generate a slow clock i.e., divide the incoming clock to something less than 3 Hz for the naked eye to see the number on the display.

The VHDL Golden Reference Manual describes what statements in VHDL are synthesizable.

delay (delayed by technology)
 

Status
Not open for further replies.

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top