Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
> On Feb 18, 5:39 pm, "Brad Smallridge" <bradsmallri...@dslextreme.com> > wrote: > >> Dear FPGA group, >> >> I have a state machine done with one flag for each state. >> Most of the states are sequential accomplished with a default >> assignment: >> signal state : std_logic_vector(0 to 61); >> begin >> if(clk'event and clk='1')then >> state<='0'&state(0 to 60); >> etc. >> There are some variations to this sequential flow. >> Elsewhere I assign data paths to these states like this: >> if(clk'event and clk='1')then >> if state(33 to 36)>0 then >> mem_out<=a; >> elsif state(37)>0 then >> mem_out<=b; >> etc. >> The elsif are a bit long and have unnecessary priority >> logic since state(33 to 36) trumps state(37). >> This happens although I can be very sure that the states >> are mutually exclusive by design. >> I am using Xilinx ISE9.2, ModelSim, and an ML402 kit. >> >> I am of the understanding that a series of "if end if" statements >> would only serve to put the priority on the last "if end if" >> statement and therefore would still result in a chain of priority >> logic. >> >> So my question is how to get rid of the priority logic? >> If I have to resort to a case statement, how do I code >> this succinctly with this long state vector? >> And is there some other way to do it, >> perhaps with a variable? > Using "one flag for each state" is also called "one-hot" encoding. > This means N states are encoded with N bits, all mutually exclusive. > I do this all the time and I prefer to not use IF or CASE statements. > The logic for each bit in one-hot encoding is very simple. The bit is > true if the bit is false AND any of the input conditions are true OR > if the bit is true AND all of the output transitions are false. So > instead of a long case statement or a deep IF statement, you can just > use a single assignment for each state variable defining each input > and each output condition... > if(clk'event and clk='1')then > if state(33) = '0' then -- enter this state > state (33) <= inputA and state(31) or > inputB and state (32) or > inputC and state(34); > else -- leave this state > state (33) <= not (inputD or inputE); > endif; > if state(34) = '0' then -- enter this state > state (34) <= inputD and state(33); > else -- leave this state > state (34) <= not inputE; > endif; > if state(35) = '0' then -- enter this state > state (35) <= inputD and state(33) or inputE and state(34); > else -- leave this state > state (35) <= not inputF; > endif; > ... > > "Good synthesis tools will try to evaluate if all branch > conditions are mutually exclusive. If they indeed are, the synthesis > tool will build parallel logic" > The key here is the term "Good synthesis tools". That requires you to > put your faith in the tools, no matter which tools are being used. > > Also, you might want to use descriptive names for the indexes of > state, such as state (memory_read). > > Rick > It didn't seem like the problem was changing states, as the OP used a simple shift for that. It seems the problem is assigning values to other signals based upon the current state. In VHDL "if else" and "conditional signal assignment" statements both technically create priority logic. On the other hand, "case" statements and "selected signal assignment" statements represent mux logic (i.e. full and parallel cases). What you presented above, is coding a mux by hand and generates priority logic when the assignment targets in any of the if blocks are the same. For a current research project, I developed an algorithm to convert all of VHDL's conditional assignment statements (there are four) to a traditional N:1 mux, if anyone wants, I will write the algorithm here. If the OP provides more insight into the actual code I could give a more specific answer. ---Matthew HicksArticle: 138401
Hello all, This is a very trivial question i have. I was structural coding a memory module(using verilog) where i have the higher module and two lower modules. i want the code to be generic and parametrized. Higher module has a parameter 'n' which I want to pass to the lower module.do i have to pass this parameter as an input to the lower module or is there any other way? i know in VHDL we can do !!generic map(m=>m)!! but how do we do that in verilog. sorry guys i am new to verilog. Thank you for helping me out. akshayArticle: 138402
module_name #() instance_name() structure works in Verilog. ---Matthew Hicks > Hello all, > This is a very trivial question i have. I was structural coding a > memory > module(using verilog) where i have the higher module and two lower > modules. > i want the code to be generic and parametrized. Higher module has a > parameter 'n' which I want to pass to the lower module.do i have to > pass > this parameter as an input to the lower module or is there any other > way? > i know in VHDL we can do !!generic map(m=>m)!! but how do we do that > in > verilog. sorry guys i am new to verilog. > Thank you for helping me out. > akshayArticle: 138403
I'm having trouble loading my bitstream into the parallel NOR flash using the indirect method with a Spartan 3A DSP. So far I've been able to load the design via JTAG and it works fine. I've also loaded the design onto Spartan 3A starter platform which is the layout that was used as the reference for the new PC board. The primary difference is that the starter platform has 1800 while the new board uses a 3400. The parallel NOR flash chips used is the RC28F128J3D from Numonyx (Intel). When attempting to program the bitstream into the flash using impact, erasing works, programing works, but verify fails instantly at offset 0x0. Not sure why the results are different between the two designs.Article: 138404
Hi everyone, the latest version of GTKWave (3.2.0) windows binary is available at here: http://www.dspia.com/gtkwave.html -- Muzaffer Kal DSPIA INC. ASIC/FPGA Design Services http://www.dspia.comArticle: 138405
Matthew Hicks schrieb: >> On Feb 18, 5:39 pm, "Brad Smallridge" <bradsmallri...@dslextreme.com> >> wrote: >> >>> Dear FPGA group, >>> >>> I have a state machine done with one flag for each state. >>> Most of the states are sequential accomplished with a default >>> assignment: >>> signal state : std_logic_vector(0 to 61); >>> begin >>> if(clk'event and clk='1')then >>> state<='0'&state(0 to 60); >>> etc. >>> There are some variations to this sequential flow. >>> Elsewhere I assign data paths to these states like this: >>> if(clk'event and clk='1')then >>> if state(33 to 36)>0 then >>> mem_out<=a; >>> elsif state(37)>0 then >>> mem_out<=b; >>> etc. >>> The elsif are a bit long and have unnecessary priority >>> logic since state(33 to 36) trumps state(37). >>> This happens although I can be very sure that the states >>> are mutually exclusive by design. >>> I am using Xilinx ISE9.2, ModelSim, and an ML402 kit. >>> >>> I am of the understanding that a series of "if end if" statements >>> would only serve to put the priority on the last "if end if" >>> statement and therefore would still result in a chain of priority >>> logic. >>> >>> So my question is how to get rid of the priority logic? >>> If I have to resort to a case statement, how do I code >>> this succinctly with this long state vector? >>> And is there some other way to do it, >>> perhaps with a variable? >> Using "one flag for each state" is also called "one-hot" encoding. >> This means N states are encoded with N bits, all mutually exclusive. >> I do this all the time and I prefer to not use IF or CASE statements. >> The logic for each bit in one-hot encoding is very simple. The bit is >> true if the bit is false AND any of the input conditions are true OR >> if the bit is true AND all of the output transitions are false. So >> instead of a long case statement or a deep IF statement, you can just >> use a single assignment for each state variable defining each input >> and each output condition... >> if(clk'event and clk='1')then >> if state(33) = '0' then -- enter this state >> state (33) <= inputA and state(31) or >> inputB and state (32) or >> inputC and state(34); >> else -- leave this state >> state (33) <= not (inputD or inputE); >> endif; >> if state(34) = '0' then -- enter this state >> state (34) <= inputD and state(33); >> else -- leave this state >> state (34) <= not inputE; >> endif; >> if state(35) = '0' then -- enter this state >> state (35) <= inputD and state(33) or inputE and state(34); >> else -- leave this state >> state (35) <= not inputF; >> endif; >> ... >> >> "Good synthesis tools will try to evaluate if all branch >> conditions are mutually exclusive. If they indeed are, the synthesis >> tool will build parallel logic" >> The key here is the term "Good synthesis tools". That requires you to >> put your faith in the tools, no matter which tools are being used. >> >> Also, you might want to use descriptive names for the indexes of >> state, such as state (memory_read). >> >> Rick >> > > It didn't seem like the problem was changing states, as the OP used a > simple shift for that. It seems the problem is assigning values to > other signals based upon the current state. In VHDL "if else" and > "conditional signal assignment" statements both technically create > priority logic. On the other hand, "case" statements and "selected > signal assignment" statements represent mux logic (i.e. full and > parallel cases). What you presented above, is coding a mux by hand and > generates priority logic when the assignment targets in any of the if > blocks are the same. For a current research project, I developed an > algorithm to convert all of VHDL's conditional assignment statements > (there are four) to a traditional N:1 mux, if anyone wants, I will write > the algorithm here. If the OP provides more insight into the actual > code I could give a more specific answer. > > > ---Matthew Hicks > > It seems the OP choose a way to implement the state machine efficiently, but at the same time, the implementation of the control becomes difficult. Why doesn't he describe a state machine with symbolic names and tell the synthesis tool to use one-hot encoding. The case statement to evaluate the current state is trivial then and can be efficiently translated by the synthesis tool because it *knows* about the one-hot encoding. -MarkusArticle: 138406
Hi it has nothing todo with Basic Stamps, just the PCB looks like a stamp, hence the name http://www.trioflex.com/files/Stamp60-UM.pdf preliminary user manual is now online. The first stamp is based on Actel FPGA and well the user manual maybe some interesting reading - for me it was surprise how nice actel tools have become (compared to what they used to be). it is also interesting that Actel ist the only company offering small customizeable Soft-Core fully integrated with their IDE. PicoBlaze is still not fully officially supported and probably never will be integrated to Xilinx IDE. Antti PS if some is interested i should have some give away units of the stamp at Embedded World. meeting at 12-536Article: 138407
On Feb 19, 6:23 pm, Matthew Hicks <mdhic...@uiuc.edu> wrote: > > On Feb 18, 5:39 pm, "Brad Smallridge" <bradsmallri...@dslextreme.com> > > wrote: > > >> So my question is how to get rid of the priority logic? > >> If I have to resort to a case statement, how do I code > >> this succinctly with this long state vector? > >> And is there some other way to do it, > >> perhaps with a variable? > > Using "one flag for each state" is also called "one-hot" encoding. > > This means N states are encoded with N bits, all mutually exclusive. > > I do this all the time and I prefer to not use IF or CASE statements. > > The logic for each bit in one-hot encoding is very simple. The bit is > > true if the bit is false AND any of the input conditions are true OR > > if the bit is true AND all of the output transitions are false. So > > instead of a long case statement or a deep IF statement, you can just > > use a single assignment for each state variable defining each input > > and each output condition... > > if(clk'event and clk='1')then > > if state(33) = '0' then -- enter this state > > state (33) <= inputA and state(31) or > > inputB and state (32) or > > inputC and state(34); > > else -- leave this state > > state (33) <= not (inputD or inputE); > > endif; > > if state(34) = '0' then -- enter this state > > state (34) <= inputD and state(33); > > else -- leave this state > > state (34) <= not inputE; > > endif; > > if state(35) = '0' then -- enter this state > > state (35) <= inputD and state(33) or inputE and state(34); > > else -- leave this state > > state (35) <= not inputF; > > endif; > > ... > > > "Good synthesis tools will try to evaluate if all branch > > conditions are mutually exclusive. If they indeed are, the synthesis > > tool will build parallel logic" > > The key here is the term "Good synthesis tools". That requires you to > > put your faith in the tools, no matter which tools are being used. > > > Also, you might want to use descriptive names for the indexes of > > state, such as state (memory_read). > > > Rick > > It didn't seem like the problem was changing states, as the OP used a simple > shift for that. It seems the problem is assigning values to other signals > based upon the current state. Yes, I see your point. > In VHDL "if else" and "conditional signal > assignment" statements both technically create priority logic. On the other > hand, "case" statements and "selected signal assignment" statements represent > mux logic (i.e. full and parallel cases). What you presented above, is coding > a mux by hand and generates priority logic when the assignment targets in > any of the if blocks are the same. Yes, you are right. That is why my code puts all assignments to a given state variable in a single IF ELSE statement. But the real point is that this is very easy to construct from the state diagram. There is a one to one mapping from each end of the state transition in the diagram to a term in the state assignments. This way you can easily keep your state assignments up to date when you make changes to the state machine and you can verify that the code and the state diagram match at any given point, in either direction. OutputFoo <= inputA and state(31) or inputB and state(32); OutputBar <= inputD and state(33) or inputE and state(34); OutputGrr <= state(35) or state(36) or state(37); It is easy to code the output signals in a similar manner. Rather than to put them in conditional statements based on the current state, I define them by a sum of products for the Mealy machine (each term is an optional input anded with a state) or just a sum for Moore machines (list each state where the output is true). Again there is a one to one relationship between output notations and the code so that it is easy to verify as well. I would keep the state code and the output code separate since they would not be structured the same. Depending on your machine, the above notation may actually be more clear than a diagram. Also, these assignments do not need to be in a clocked process, depending on your design needs. A true Mealy or Moore machine would not have the extra register delay. If you need the outputs registered and don't want to have the extra clock cycle delay, you can define the states as cur_state and nxt_state signals with nxt_state defined with concurrent statements or in a non-clocked process and cur_state defined as registered versions of nxt_state in a clocked process. Then you can use the nxt_state values in your clocked process to assign values to the outputs since they are essentially a "look ahead" on the cur_state signals. I tend to think in terms of the hardware and then write code to generate that hardware. I don't like to write software and let the tools try to figure out what I need only to be disappointed. I don't think of it as optimizing the code, I think of it as describing the hardware I want. I just want the tools to stay out of my way as much as possible. RickArticle: 138408
On 2=D4=C213=C8=D5, =CF=C2=CE=E76=CA=B113=B7=D6, lijia2...@gmail.com wrote:
> Hi, I suffer from a problem. when I implement the reference design
> from xilinx xapp485, there comes an error after implement the design,
> but I don't know why,can anybody tell me...? thanks in advance,I
> really appreciate your help.
>
> # November 1st 2006
>
> # Timespec should be set to period plus an amount for jitter
> # For example : pixel clock of 90 MHz =3D> high speed clock of 315 MHz
> (3175 pS).
> # From spreadsheet : jitter is 464 pS
> # 1/(3175 - (0.5*464)) =3D> 340 MHz
>
> net rxclk35 tnm =3D rxclk35 ;
> net rxclk35not tnm =3D rxclk35not ;
> net rxclk tnm =3D rxclk1 ;
>
> timespec tsrx00 =3D period rxclk35 340 Mhz ;
> timespec tsrx01 =3D period rxclk1 tsrx00/3.5 ;
> timespec tsrx02 =3D from rxclk35 to rxclk1 =3D tsrx00/2 ;
>
> # receive clock input 1, bank 0
>
> net "rxclkina1_p" loc =3D "B8" ; #
> net "rxclkina1_n" loc =3D "B9" ; #
>
> # channel A lvds inputs - Bank 3
>
> net "dataina_p(3)" loc =3D "C8" ; #
> net "dataina_n(3)" loc =3D "D8" ; #
> net "dataina_p(2)" loc =3D "E8" ; #
> net "dataina_n(2)" loc =3D "F8" ; #
> net "dataina_p(1)" loc =3D "C7" ; #
> net "dataina_n(1)" loc =3D "D7" ; #
> net "dataina_p(0)" loc =3D "F7" ; #
> net "dataina_n(0)" loc =3D "E7" ; #
>
> inst "rx0" rloc_origin =3D "X18y86" ;
>
> inst "apa0" rloc_origin =3D "X42Y90" ; =
# Delete or comment this line
> if auto phase alignment is not being used
>
> timespec tsapa00 =3D from ffs(apa0/chfoundc) to ffs(apa0/sm) =3D
> tsrx00/2 ; # Delete or comment this line if aut
no body knows?
Article: 138409On Feb 19, 7:55=A0pm, Muzaffer Kal <k...@dspia.com> wrote: > Hi everyone, > the latest version of GTKWave (3.2.0) windows binary is available at > here:http://www.dspia.com/gtkwave.html > > -- Muzaffer Kal > > DSPIA INC. > ASIC/FPGA Design Serviceshttp://www.dspia.com Thanks to Tony Bybell, this version also exports .tim files for the TimingAnalyzer so you convert VCD diagrams to timing diagrams. www.timing-diagrams.com Thank you for distributing the windows version.Article: 138410
On Fri, 20 Feb 2009 06:03:04 -0800 (PST) chewie <timinganalyzer@gmail.com> wrote: > Thanks to Tony Bybell, this version also exports .tim files for the > TimingAnalyzer so you convert VCD diagrams to timing diagrams. > > www.timing-diagrams.com > > Thank you for distributing the windows version. > And Thanks to Tony Bybell, he's gtkwave program in GPL-licensed and freely available. I'm getting tired of your annoying marketing posts. Please stop or promote your program as an open-sourced program.Article: 138411
On Feb 18, 12:24=A0am, Ehsan <ehsan.hosse...@gmail.com> wrote: > Hi all, > > I've built a fairly large and complex design in VHDL and tried to > implement it on a Xilinx virtex-4 FX100 fpga. I have verified the > functionality of my design through the behavioural simulations. After > that, I decided to implement it on the fpga. I chose a set of inputs > the same as I used in the behavioural simulations and then run the > hardware. When I read the outputs, which are some internal registers, > they match the values read from the simulations. However, sometimes > the results do not match. In all of these cases, I use the same inputs > and moreover I reload the bitstream to the fpga to make the situation > equal. I thought the timing constraints may be violated, so I reduced > the clock frequency, however, no significant effect can be seen. I can > conclude that the design is synthesized according to the desired > functionality, since it generates the desired outputs in some > instances. However, I cannot understand why it malfunctions > occasionally for the fixed inputs. What type of errors can lead to > this problem? What can I do when the error is not repeatable? > > My design is basically controlled by an FSM which has 16 states. I > send the start command and then it goes through all the states and > finally asserts a done signal. Once the register values are incorrect, > the done signal is also not set. So, something should stop the FSM > from moving forward. > > Thank you in advance for your comments. I just used the Chipscope to debug my design. What actually happens is that the FSM goes to a wrong state in one of the transitions (always the same). The FSM has 16 states and I designed it using StateCad tool (included in Xilinx ISE). The FSM has a 4-bit counter, which counts up every time it goes over the states. In the last state, it checks the counter value and if it has reached the value of 10, it would go to the idle state, otherwise it goes to another state and starts another round. And this is where the error happens: sometimes when the counter is still less than 10, it goes to the idle state. The design is synthesized using XST and the fsm is one-hot encoded. I'm not sure what I've done wrong. Please let me know if you have any suggestions.Article: 138412
On Feb 20, 8:28 am, Ehsan <ehsan.hosse...@gmail.com> wrote: > On Feb 18, 12:24 am, Ehsan <ehsan.hosse...@gmail.com> wrote: > > > > > Hi all, > > > I've built a fairly large and complex design in VHDL and tried to > > implement it on a Xilinx virtex-4 FX100 fpga. I have verified the > > functionality of my design through the behavioural simulations. After > > that, I decided to implement it on the fpga. I chose a set of inputs > > the same as I used in the behavioural simulations and then run the > > hardware. When I read the outputs, which are some internal registers, > > they match the values read from the simulations. However, sometimes > > the results do not match. In all of these cases, I use the same inputs > > and moreover I reload the bitstream to the fpga to make the situation > > equal. I thought the timing constraints may be violated, so I reduced > > the clock frequency, however, no significant effect can be seen. I can > > conclude that the design is synthesized according to the desired > > functionality, since it generates the desired outputs in some > > instances. However, I cannot understand why it malfunctions > > occasionally for the fixed inputs. What type of errors can lead to > > this problem? What can I do when the error is not repeatable? > > > My design is basically controlled by an FSM which has 16 states. I > > send the start command and then it goes through all the states and > > finally asserts a done signal. Once the register values are incorrect, > > the done signal is also not set. So, something should stop the FSM > > from moving forward. > > > Thank you in advance for your comments. > > I just used the Chipscope to debug my design. What actually happens is > that the FSM goes to a wrong state in one of the transitions (always > the same). The FSM has 16 states and I designed it using StateCad tool > (included in Xilinx ISE). The FSM has a 4-bit counter, which counts up > every time it goes over the states. In the last state, it checks the > counter value and if it has reached the value of 10, it would go to > the idle state, otherwise it goes to another state and starts another > round. And this is where the error happens: sometimes when the counter > is still less than 10, it goes to the idle state. The design is > synthesized using XST and the fsm is one-hot encoded. > > I'm not sure what I've done wrong. Please let me know if you have any > suggestions. Muzaffer Kal has already answered your question. Read his reply over and over until you understand it. John Providenza has answered it in his own way, perhaps describing a "race condition" as "metastable". (It's really a race condition.) Take a look at the logic generated for your state machine. You will see a bunch of d-flops, each with their own cloud of logic at the D input. Each of these clouds will have a different length. There will be at least one input that goes through paths (clouds) of different length. If the clock to the D-flops happens after the signal propagates (gets through) the short path, and before it propagates the long path, your state machine will go to a wonky state. Welcome to "real world" logic design. ALArticle: 138413
Ehsan, To help you further, we could use some more information: 1. Is the last state the only state that checks the counter value? 2. Is the counter running on the same clock as the FSM? 3. Are all other inputs used for the transition from the last stage to the idle stage on the same clock domain as the FSM? [This requires extracting the fan-in cone of logic for each last stage inut and verifying that *every* input of the logic cone is a FF clocked by the same clock as the FSM] 4. Apart from the counter, is there any other input to your FSM that is only used in the transition from the last stage back to the idle stage? 5. Is there a reset for the state register of your FSM? Finally, why don't you post the code for the last stage only? Cheers, - gaelArticle: 138414
On Feb 20, 10:32=A0am, Jason Zheng <Xin.Zh...@jpl.nasa.gov> wrote: > On Fri, 20 Feb 2009 06:03:04 -0800 (PST) > > chewie <timinganaly...@gmail.com> wrote: > > Thanks to Tony Bybell, =A0this version also exports .tim files for the > > TimingAnalyzer so you convert VCD diagrams to timing diagrams. > > >www.timing-diagrams.com > > > Thank you for distributing the windows version. > > And Thanks to Tony Bybell, he's gtkwave program in GPL-licensed and > freely available. I'm getting tired of your annoying marketing posts. > Please stop or promote your program as an open-sourced program. I thought from previous discusions it would be ok to make announcements every once in a while, but now I believe you are right, and don't want to bother anyone, so I will not make anymore announcements on the newsgroups.Article: 138415
On Feb 13, 10:13=A0am, lijia2...@gmail.com wrote: > Hi, I suffer from a problem. when I implement the reference design > from xilinx xapp485, there comes an error after implement the design, > but I don't know why,can anybody tell me...? thanks in advance,I > really appreciate your help. It would really help if you told us what the error message says. -aArticle: 138416
Stef wrote: > Hello, > > Xilinx provides IBIS files for the spartan (and other) devices. In these > files the IBIS model of each possible IO driver type is given. But because > the IO can be configured, there is no fixed IBIS for a completed design. > > After P&R, there is a pin mapping file which tells which pin has which > IO standard and drive strength. Together with the IBIS file per IO type, > it seems a fairly simple task of generating a specific IBIS file for the > completed design. > > Is there an option in ISE or a separate tool to generate such an IBIS > file? The task seems so simple, I'm tempted to try it myself. But that > would be a waste of effort if the tool already exists. :-) > Yes, there is a tool within the ISE distribution called IBISWriter that does exactly what you want. Ed McGettigan -- Xilinx Inc.Article: 138417
Hi gang,
I have an idea for a tweak of my FPGA design that involves essentially
building a time interval counter. I found that there are some IP cores out
there that get as much as 100ps resolution, but before I go that route I
want to experiment with something "free" first, especially since I don't
need any bells and whistles like embedded bus protocols or programmable
timers. Neither of the signals I want to time between are synchronous with
my main clock, so I'm thinking of generating a new DCM just for this purpose
(I think I have a few left in my XC2V6000-5). Otherwise my fastest clock is
either 133 MHz or maybe 204.8 MHz coming from an outside clock chip (I might
be able to goose it to 409.6 MHz).
My question is there any good "how to" on writing a counter so that it runs
at a maximum clock rate for my chip? I perused the Xilinx site, and there
were some very old articles on fast counters in antique chip architectures;
they provide OrCAD macros(?); not even VHDL.
So, do I just naively code the counter and pray that synthesis does the
right things (I don't need a huge number of bits; my maximum time interval
is maybe 80 ns), or are there some tricks needed to get optimum clock speed
(what could I rationally expect in this FPGA?)?
Thanks for your help,
Marty
Article: 138418"Marty Ryba" <martin.ryba.nospam@verizon.net> wrote in news:vQHnl.665$Ez6.422@nwrddc02.gnilink.net: > Hi gang, > > I have an idea for a tweak of my FPGA design that involves > essentially > building a time interval counter. I found that there are some IP cores > out there that get as much as 100ps resolution, but before I go that > route I want to experiment with something "free" first, especially > since I don't need any bells and whistles like embedded bus protocols > or programmable timers. Neither of the signals I want to time between > are synchronous with my main clock, so I'm thinking of generating a > new DCM just for this purpose (I think I have a few left in my > XC2V6000-5). Otherwise my fastest clock is either 133 MHz or maybe > 204.8 MHz coming from an outside clock chip (I might be able to goose > it to 409.6 MHz). > > My question is there any good "how to" on writing a counter so that it > runs at a maximum clock rate for my chip? I perused the Xilinx site, > and there were some very old articles on fast counters in antique chip > architectures; they provide OrCAD macros(?); not even VHDL. > > So, do I just naively code the counter and pray that synthesis does > the right things (I don't need a huge number of bits; my maximum time > interval is maybe 80 ns), or are there some tricks needed to get > optimum clock speed (what could I rationally expect in this FPGA?)? The "naive counter" has no chance of giving you a resolution of better than a ns with current FPGA technology. I'm guessing that most of the IP cores that achieve better than 1ns resolution do so by using a wider bus at a lower clock rate, e.g. a 100 bit bus at 100MHz. You use logic to locate the bit position on the bus where a transition occurs. Each bit position in this contrived example represents 100ps, and each word represents 10ns. There are two basic ways of turning your 1 bit test signal into a wider bus: 1. Use a SERDES. Most modern (larger) FPGAs have these built in, either as a true transceiver (with PLLs and CDR, etc.), or as a simple SERDES in to the IOB. The most recent FPGAs have on-board SERDES blocks that can sample at 100ps intervals. 2. Use a (different) phase delay for each of the bits, and sample them all with the word clock. This has the advantage that the word clock is the highest frequency you need, however getting the phase delays right in an FPGA might be tricky. (This method is better suited to ASIC implementations.) There are some tricks you can use that will get you part way to your goal: - Use both clock edges for sampling. This gives you a 2x speedup (but requires a 50% duty cycle clock). - Use multiple phases from a DCM or PLL. This can give you a 4x speedup. Regards, AllanArticle: 138419
On Feb 21, 2:19=A0am, Gael Paul <gael.p...@gmail.com> wrote:
> Ehsan,
>
> To help you further, we could use some more information:
> 1. Is the last state the only state that checks the counter value?
Yes, this is the only place that checks the counter value.
> 2. Is the counter running on the same clock as the FSM?
> 3. Are all other inputs used for the transition from the last stage to
> the idle stage on the same clock domain as the FSM?
> [This requires extracting the fan-in cone of logic for each last stage
> inut and verifying that *every* input of the logic cone is a FF
> clocked by the same clock as the FSM]
Yes, the counter and all the inputs to the FSM are running on the
same clock.
> 4. Apart from the counter, is there any other input to your FSM that
> is only used in the transition from the last stage back to the idle
> stage?
No
> 5. Is there a reset for the state register of your FSM?
Yes, I have a synchronous reset that brings the FSM to the idle
state. I tried the asynchronous as well, but the same thing happens.
> Finally, why don't you post the code for the last stage only?
>
> Cheers,
>
> =A0- gael
Here is the code for the last stage. As I said earlier the fsm is
generated by StateCad, so the code might not look neat.
WHEN STALL7 =3D>
IF ( Iter_No0=3D'0' AND Iter_No1=3D'1' AND Iter_No2=3D'0' AND
Iter_No3=3D'1' )
THEN
next_sreg<=3DIDLE;
next_BP_RX_EN<=3D'1';
next_BP_Iter_Done<=3D'1';
next_BP_CNP_FirstIter<=3D'1';
next_BP_CNP_Mode<=3D'0';
next_BP_CNP_Corr<=3D'0';
next_BP_CNP_RD_EN<=3D'0';
next_BP_CTV_START<=3D'0';
next_BP_VTC_START<=3D'0';
next_BP_CNP_ACK<=3D'0';
next_BP_VNP_ACK<=3D'0';
next_BP_BLK_REQ<=3D'1';
IF (( BP_VNP_RD_EN=3D'1' )) THEN next_BP_VNP_RD_EN<=3D'1';
ELSE next_BP_VNP_RD_EN<=3D'0';
END IF;
Iter_No <=3D (std_logic_vector'("0000"));
BP_CNP_Count_Addr <=3D (std_logic_vector'("000000"));
ELSE
next_sreg<=3DSTALL8;
IF (( BP_BLK_REQ=3D'1' )) THEN next_BP_BLK_REQ<=3D'1';
ELSE next_BP_BLK_REQ<=3D'0';
END IF;
IF (( BP_CNP_ACK=3D'1' )) THEN next_BP_CNP_ACK<=3D'1';
ELSE next_BP_CNP_ACK<=3D'0';
END IF;
IF (( BP_CNP_Corr=3D'1' )) THEN next_BP_CNP_Corr<=3D'1';
ELSE next_BP_CNP_Corr<=3D'0';
END IF;
IF (( BP_CNP_FirstIter=3D'1' )) THEN next_BP_CNP_FirstIter<=3D'1';
ELSE next_BP_CNP_FirstIter<=3D'0';
END IF;
IF (( BP_CNP_Mode=3D'1' )) THEN next_BP_CNP_Mode<=3D'1';
ELSE next_BP_CNP_Mode<=3D'0';
END IF;
IF (( BP_CNP_RD_EN=3D'1' )) THEN next_BP_CNP_RD_EN<=3D'1';
ELSE next_BP_CNP_RD_EN<=3D'0';
END IF;
IF (( BP_CTV_START=3D'1' )) THEN next_BP_CTV_START<=3D'1';
ELSE next_BP_CTV_START<=3D'0';
END IF;
IF (( BP_Iter_Done=3D'1' )) THEN next_BP_Iter_Done<=3D'1';
ELSE next_BP_Iter_Done<=3D'0';
END IF;
IF (( BP_RX_EN=3D'1' )) THEN next_BP_RX_EN<=3D'1';
ELSE next_BP_RX_EN<=3D'0';
END IF;
IF (( BP_VNP_ACK=3D'1' )) THEN next_BP_VNP_ACK<=3D'1';
ELSE next_BP_VNP_ACK<=3D'0';
END IF;
IF (( BP_VNP_RD_EN=3D'1' )) THEN next_BP_VNP_RD_EN<=3D'1';
ELSE next_BP_VNP_RD_EN<=3D'0';
END IF;
IF (( BP_VTC_START=3D'1' )) THEN next_BP_VTC_START<=3D'1';
ELSE next_BP_VTC_START<=3D'0';
END IF;
Iter_No <=3D (( std_logic_vector'(Iter_No3, Iter_No2, Iter_No1,
Iter_No0)
));
BP_CNP_Count_Addr <=3D (( std_logic_vector'(BP_CNP_Count_Addr5,
BP_CNP_Count_Addr4, BP_CNP_Count_Addr3, BP_CNP_Count_Addr2,
BP_CNP_Count_Addr1, BP_CNP_Count_Addr0)));
END IF;
Thanks for your helpful comments.
Article: 138420On Feb 21, 1:23=A0pm, "Marty Ryba" <martin.ryba.nos...@verizon.net> wrote: > Hi gang, > > =A0 =A0 I have an idea for a tweak of my FPGA design that involves essent= ially > building a time interval counter. I found that there are some IP cores ou= t > there that get as much as 100ps resolution, but before I go that route I > want to experiment with something "free" first, especially since I don't > need any bells and whistles like embedded bus protocols or programmable > timers. Neither of the signals I want to time between are synchronous wit= h > my main clock Your title says fast counter, but the text says time interval. They are not quite the same thing. If you want to do precise interval timing, then multi-phase capture, and/or delay line capture will give you time-domain precisions above the clock frequency. What time-precision do you actually need ? eg 250MHz with 4 phases, resolves to 1ns I think I read the some of the very newest FPGAs can self-calibrate their delay lines, which saves you the trouble -jgArticle: 138421
Note: Since Optus can't figure out how to run a Newsgroup server, the original post hasn't appeared for me ... > Marty Ryba wrote in news:vQHnl.665$Ez6.422@nwrddc02.gnilink.net: > >> Hi gang, >> >> I have an idea for a tweak of my FPGA design that involves >> essentially >> building a time interval counter. I found that there are some IP cores >> out there that get as much as 100ps resolution, but before I go that >> route I want to experiment with something "free" first, especially >> since I don't need any bells and whistles like embedded bus protocols >> or programmable timers. What sort of resolution and dead time do you need? If you're willing to do a bit of legwork with manual place'n'route, and consume a fair bit of resources, you can get in the order of 10 ps or so resolution and accuracy at the cost of 10's of nanoseconds of dead time. See: http://www-ppd.fnal.gov/EEDOffice-W/Projects/ckm/comadc/WaveletTDC.ppt They use an Altera Cyclone II, but I've implemented a similar thing on a Spartan 3E with reasonable success. I don't have good enough testing apparatus to properly measure the resolution and accuracy though. And at the 10 ps level, you've got to think a bit about what's on the outside of the FPGA too ... The main downside to the Xilinx parts for this purpose is that you've only got 4 elements on the carry chain per block, as opposed to 8 in the Altera. You can also tweak out the dead time by throwing more resources at it (basically loop the end of the carry chain around to the start where it xors with the input, then do edge detection along the whole buffer and track the edges). Of course, this is so far beyond the point of "supported" that using it in a commercial project is debatable, but it's certainly a fun thing to play with. -- Michael Brown Add michael@ to emboss.co.nz ---+--- My inbox is always openArticle: 138422
Just to update all, with the latest 9 ISE Webpack it does not give any error. Interesting. Giuseppe Marullo Giuseppe Marullo wrote: > Hi Mike, > thanks for your email, now I have a bitfile for the 400k, deleting the > file worked but I have a failing timing constraint (that disappear with > the xc3s200): > > Timing constraint: TS clock1 = PERIOD TI?MEGRP "clock1" TS xtalClock / 2 > HIGH 50%; > > Could I safely ignore it? > > Sorry to bug all with this, but I can only get the 400k version, and I > would buy it specifically to use it as a logic analyzer. > > Giuseppe > > mikep@oakmicros.com wrote: >>> Thanks, it is a nice gui, still fighting with the VHDL to see if the >>> 400k board could be used, so far no dice. >>> >> I already responded privately to Giuseppe. The fix is to simply delete >> the la_guide.ncd file (which seems to be a cached output file) and >> rebuild the map file. >> >> Note that the only differences in the Oak Micros version of the >> download package are: >> 1. A fix to the la.ucf file that fixes an error message from 10.1 ISE >> Webpack >> 2. A "compiled" version of a 10.1 ISE project >> 3. Added the configuration files needed for downloading the logic >> analyzer into FPGA development board. I provided this to make it >> easier for newbies to get started. >> >> I'm also investigating (with someone else) some updates to improve the >> GUI. We are starting from the source both on >> http://www.sump.org/projects/analyzer/ >> and the SourceForge project: https://sourceforge.net/projects/jlac/ >> >> See my User Guide: >> http://oakmicros.com/content/downloads/View-document/Logic-Analyzer-User-Guide.html >> >> See my interface board: >> http://oakmicros.com/content/omla32-Logic-Analyzer-Interface-Card.html >> >> Mike Perks >> oakmicros.comArticle: 138423
On Feb 20, 10:32=A0pm, -jg <Jim.Granvi...@gmail.com> wrote: > On Feb 21, 1:23=A0pm, "Marty Ryba" <martin.ryba.nos...@verizon.net> > wrote: > > > Hi gang, > > > =A0 =A0 I have an idea for a tweak of my FPGA design that involves esse= ntially > > building a time interval counter. I found that there are some IP cores = out > > there that get as much as 100ps resolution, but before I go that route = I > > want to experiment with something "free" first, especially since I don'= t > > need any bells and whistles like embedded bus protocols or programmable > > timers. Neither of the signals I want to time between are synchronous w= ith > > my main clock > > Your title says fast counter, but the text says time interval. > They are not quite the same thing. > > If you want to do precise interval timing, then multi-phase capture, > and/or > delay line capture will give you time-domain precisions above the > clock frequency. > > What time-precision do you actually need ? > eg 250MHz with 4 phases, resolves to 1ns > > I think I read the some of the very newest FPGAs can self-calibrate > their > delay lines, which saves you the trouble > > -jg Virtex 2 doesn't have these structures. However I remember seeing appnotes using carry chains as delay elements. You basically run your input into the carry chain and then have a flip-flop at each stage in the chain all running on the master clock. Ideally your output would look like "1110000000" for a single transition, allowing you to interpolate between clock cycles. I think the original appnote was for a serdes using Virtex E, and the carry chain delay was used for phase adjustment without the IDELAY elements available in the newer parts. Regards, GaborArticle: 138424
On 1=BF=F930=C0=CF, =BF=C0=C8=C48=BD=C300=BA=D0, colin <colin_toog...@yahoo= .com> wrote: > Hello > > Has anyone here successfully built abyteblasterclone. I have > connected up the JTAG pins as specified and Quartus accepts that abytebla= steris fitted. I can see activity on TCLK, TMS and TDI at the > FPGA and TDO is getting back to the parallel port but Quartus cannot > auto detect anything. My system works with a properByteblasterbut I have = to give it back soon. > > Any ideas will be appreciated. > > Colin Hi Do not waste your time to build the byteblaster. You can get the byteblaster II with only $24.95 Visit following website. Thanks http://fpgaguy.110mb.com/
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z