"Matt Clement" <clement@nanotechsys.com> wrote in message news:nH5Gf.9713$In4.1274@trnddc06...>> >> 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)); >>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.
why does speed grade effect VHDL program??
Started by ●February 7, 2006
Reply by ●February 7, 20062006-02-07
Reply by ●February 7, 20062006-02-07
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 "Symon" <symon_brewer@hotmail.com> wrote in message news:43e8fa42$0$15790$14726298@news.sunsite.dk...> "Tim Wescott" <tim@seemywebsite.com> wrote in message > news:Ur6dnY0U0o5Hf3XenZ2dnUVZ_sWdnZ2d@web-ster.com... >> Symon wrote: >> >>> "Tim Wescott" <tim@seemywebsite.com> wrote in message >>> news:746dnfeoHM1sRHXenZ2dnUVZ_tidnZ2d@web-ster.com... >>> >>>>Is your 5MHz clock your only clock (no 'strobe' inputs?) >>>> >>> >>> 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. >> > 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. >
Reply by ●February 7, 20062006-02-07
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 "Symon" <symon_brewer@hotmail.com> wrote in message news:43e8fb50$0$15792$14726298@news.sunsite.dk...> "Matt Clement" <clement@nanotechsys.com> wrote in message > news:nH5Gf.9713$In4.1274@trnddc06... >>> >>> 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)); >>> > 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. >
Reply by ●February 7, 20062006-02-07
Matt Clement wrote:> 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)<='0'; > CASE STATE IS > WHEN IDLE =>(snip) You might consider adding an asynchronous reset state to your state machine. -a
Reply by ●February 8, 20062006-02-08
Hi, Matt Clement schrieb:> 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 onI 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
Reply by ●February 8, 20062006-02-08
> I see no clocking of the inputs, only the output and state are clocked.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
Reply by ●February 8, 20062006-02-08
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? "Andy Peters" <Bassman59a@yahoo.com> wrote in message news:1139357387.186650.274220@g43g2000cwa.googlegroups.com...> Matt Clement wrote: > >> 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)<='0'; >> CASE STATE IS >> WHEN IDLE => > > (snip) > > You might consider adding an asynchronous reset state to your state > machine. > > -a >
Reply by ●February 8, 20062006-02-08
> 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 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 ...> 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.That would be that first thing I would change ...> 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?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
Reply by ●February 8, 20062006-02-08
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>From name, and then selecting "Global Signal" under Assignment name.Cheers.
Reply by ●February 9, 20062006-02-09
Michael Sch�berl wrote: > Thomas Stanka wrote:>> I see no clocking of the inputs, only the output and state are clocked.... >> So you should think about synchronising mechanisms for the paralell >> input> > 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) >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 5MHz, you can probably get away with 1.
