why does speed grade effect VHDL program??

Three questions: Did you respecify the -15 speed grade in the Quartus-II tool and do a complete recompile? How fast does the Quartus-II tool tell you your design can run? How fast is the clock you're providing?

Hello John and thanks for the quick reply.

1. Yes I redefined the device to the -15 chip and recompiled the design in quartus-II.
2. after compiling the -15 it says internal clk fmax is 41.67Mhz and with it set as a -10 it says fmax is 51.02Mhz.
3. the external clock driving the state machine in the chip is only 5MHZ.

(top posting fixed)

As I read your post alarm bells started ringing, and I haven't been able to turn them off. The trigger was the phrase "run my program". It sounds like you are a software engineer without much experience with FPGA designs? You cannot think of that body of HDL code you've written as a 'program'. It's not. The 'D' in HDL stands for the 'description' of the logic that you want -- _not_ a 'program'.

If you are clocking this thing at 5MHz and it fails to work, even though it thinks it can work at 42MHz, there is something that the tool is overlooking that you must help it with. You are probably violating a timing parameter that is not adequately described to your tool, and which you'll have to look at yourself.

So here's some questions:

What form of serial are you giving the thing? Is it synchronous? Could you be violating setup or hold requirements going from serial to parallel? Is your 5MHz clock your only clock (no 'strobe' inputs?) Did I leave something out?

Matt

Have you got any inputs that are not synchronous to your state machine, or you are not meeting setup and hold requirements? As well as clocking slower the set, hold and clock to output times will vary with speed grade as silicon batch variations.

John Adair Enterpoint Ltd. - Soon to be the home of Hollybush1. The PC104Plus Spartan-3 Development Platform.

To add to Tim's comments, have you gated this clock? Cheers, Syms.

Symon:

Are you assuming a faster clock that could be used to gate the 5MHz one? Somehow I think that's Matt's _only_ clock.

Matt:

Have you met the rise and fall time specifications for the clock? I would expect this would cause more problems with a higher speed grade, but since the chips are binned it could just be that the lower speed grade parts have more skew which may or may not make them more sensitive to rise and fall times.

Hello everyone and many thanks for the replies.

I am a fairly "generic" guy so excuse my "generic" reference to the program. I am an EE with specialization in digital logic design. The serial is a basic bit bang serial 32 bit stream that relates to 32 inputs. I simply read them in serially and then dump them parallel to 32 LED's. The clock for the serial data is provided by the source system and its 5 Mhz. The simulation of the "program" in Quartus verifies that it should be doing exactly what I want (in theory..haha). It works fine with the -10 part but when I swap with a compiled, programmed -15 it fails to function. I would have thought the -15 would be faster but according to the compiler, it's Fmax is slower. The simulation for the -15 also works fine. I spent the better part of the morning scratching my head over this one.

here is the basic "program"

LIBRARY IEEE; USE IEEE.STD_LOGIC_1164.ALL;

ENTITY CLONE34 IS PORT (clk : IN BIT; SEL : IN BIT_VECTOR(7 DOWNTO 0); ADD : IN BIT_VECTOR(5 DOWNTO 0); DAT : INOUT BIT_VECTOR(1 DOWNTO 0); LED1 : OUT BIT_VECTOR(31 DOWNTO 0));

END CLONE34;

ARCHITECTURE ONE OF CLONE34 IS TYPE STATE_TYPE IS (IDLE,S0,S1,S2,S3,S4,S5,S6,S7,S8,S9,S10,S11,S12,S13,S14,S15,S16,S17,S18,S19,S20,S21,S22,S23,S24,S25,S26,S27,S28,S29,S30,S31,S32,S33,S34); SIGNAL STATE: STATE_TYPE;

BEGIN

PROCESS (clk, ADD) VARIABLE DATA : BIT_VECTOR(35 DOWNTO 0); BEGIN

IF (clk'EVENT AND clk = '1')THEN

DAT(0)

IF ADD = SEL(7 DOWNTO 2) THEN DATA(35):=SEL(1); STATE news:%84Gf.23953$ snipped-for-privacy@news02.roc.ny...

Okay guys According to the datasheet the -15 is slower than the -10. The prop delay max for each is 10ns and 15ns thus the speed grades. So the slower speed by

Matt

(IDLE,S0,S1,S2,S3,S4,S5,S6,S7,S8,S9,S10,S11,S12,S13,S14,S15,S16,S17,S18,S19,S20,S21,S22,S23,S24,S25,S26,S27,S28,S29,S30,S31,S32,S33,S34);

Hi Tim, I've seen people drive a state machine with a clock, then use the output of this state machine to gate the clock for other bits of circuitry. To make it slower or to save power. Right. Yuk. Sounds like Matt's not doing that, good for him! Cheers, Syms.

Hello Symon

No i am not gating the clock....at least not on purpose. The clock for the system comes from an external source and is at 5Mhz. I use it to transition the state machine. The compiler says my slowest delay still lets me run at around 50Mhz so that should be okay.

I noticed that I am checking the address in each state when I could probably just check it before the case statement and get the same effect??

Thanks Matt

Hey Matt, Are SEL, ADD, DAT synchronous to the clk? And, if so, do they meet the setup and hold requirements for the rising edge of the clock? Cheers, Syms.

Hello Symon

SEL, ADD are asynchronous to the clock. ADD is set by the user with a dip switch to allow multiplexing. The SEL signal comes from the source and determines which multiplexed address the source wants to talk to. The SEL and ADD signals are only read on a rising CLK edge so they become synced on the destination side. DAT is not used for anything in the design and is left unconnected for now.

Matt

(IDLE,S0,S1,S2,S3,S4,S5,S6,S7,S8,S9,S10,S11,S12,S13,S14,S15,S16,S17,S18,S19,S20,S21,S22,S23,S24,S25,S26,S27,S28,S29,S30,S31,S32,S33,S34);

(snip)

You might consider adding an asynchronous reset state to your state machine.

-a

Hi,

Matt Clement schrieb:

I see no clocking of the inputs, only the output and state are clocked. This leads to race conditions, regardless of your speedgrade, the function of your circuit is nondeterministic.

Lets asume SEL is really stabel compared to CLK, ADD is really asynchronous. If ADD changes "near" a rising edge of CLK (take care of IO-delay and the delay of the clocknet) you may see the following cases:

1. New value for STATE based on new value for ADD, new value for LED based on old value for ADD (or vice versa)
2. New value for STATE and LED based on some bits of old ADD and some bits of new value for ADD
3. mixture of 1 and 2.

You should clock every input at least once before using it, especially when using parallel inputs to avoid this problem occuring due to asynchronity. But even when clocking a parallel input you may face the problem that a change from 000 to 111 in your input results in a register content of 011. So you should think about synchronising mechanisms for the paralell input

bye Thomas

this is one solution - the source of the problem is a little deeper ...

When you specify a timing constraint for you clock then the tools make sure that the delays between the flipflops are within the limit. Your input delay is still unspecified and the tools do not care about it!

- you could specify input delays of your signal as a timing constraint and make sure that it is met ...

- you could use input flipflops (this is easier) ... just register your input signals (with the same clock!) and make sure that those flipflops get placed at the IO block ... the delay from the pad to that first flipflop is fixed as there is only one possible and short route after that you should open your fpga editor and make sure that the input FFs are used (there may be some settings in your synthesis tool to make this happen)

bye, Michael

Hey guys Thanks a lot. The inputs are basically a chipselect (SEL compared against ADD...where ADD is dip switches left alone and SEL comes from the PC) and a single signal that is the serial 32 bit word. I then feed that serial data into a register and then clock it out parallel to the LED1. There is no reset signal in the system so dont want to add one to the state machine just yet.

I was assuming that by only taking the inputs during a rising edge of the clock, I AM sampling them syncronously, even though they might occur asynch. The CLK and the SEL signals are pretty much timed by the PC sending them so all I need to do is sample the SEL line during a rising CLK edge.

I am not sure where in Quartus to setup the timing requirements and how to make it test that they are all met? Any help?

(IDLE,S0,S1,S2,S3,S4,S5,S6,S7,S8,S9,S10,S11,S12,S13,S14,S15,S16,S17,S18,S19,S20,S21,S22,S23,S24,S25,S26,S27,S28,S29,S30,S31,S32,S33,S34);

the internal routing from the pad to your first flipflop is not constrained ... if you are unlucky you get different delays for different paths and they even change from one implementation to the next (making it work just sometimes) ...

I have to admit that it's somewhat uncommon that this is a problem at only 5 MHz ...

That would be that first thing I would change ...

in xilinx florplanner you can open the routed FPGA, click on a net and press the button "delay". This gives you some numbers to find out if you violate setup/hold ... (sorry - I just know for xilinx)

If you specify a timing constraint the report should say which items matched and if they met the constraint ... somehow

... just insert the input FF - this is likely to solve the problem and you don't have to care about complicated constraints ;-)

bye, Michael

Hi,

One thing I would try is to declare "CLK" as a global wire. You can do this in Quartus by opening the assignment editor, entering "CLK" as the

Cheers.

... >> So you should think about synchronising mechanisms for the paralell >> input

As Thomas implied, asynchronous parallel inputs are plain *broken*. If they work at all, it's pure luck. You need some kind of strobe (a single bit), which is known to go active only after all the other lines are stable. Then you synchronise that strobe, and use the synchronised version to enable an input register for the other lines. Of course, all this may take several clocks to complete: during which your inputs are not allowed to change. Otherwise, given the parallel lines will not transition at the same instant, it's always possible to have a clock edge fall between them. This is true, regardless of the actual clock frequency.

Synchronisation is a notoriously intractable problem: you can reduce the probability of errors to an arbitrarily small value, but not to zero.

Your synchroniser should ideally use at least 2 flipflops, but at just