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 Apr 5, 8:38 pm, Mark McDougall <ma...@vl.com.au> wrote: > rickman wrote: > > Are you sure about that? I haven't looked at this detail on a Xilinx > > part in a while, but the Lattice parts allow a clock source to be from > > the general routing. Because of the long delay in the routing, this > > won't be usable to clock input data that is relative to that clock, > > but it can be used internally. > > Altera Cyclone devices have a limited number of pins connected to the > global clock network. Admittedly, I'm not sure about Xilinx devices. But that wasn't the question. The point is that regardless of how many pins are directly connected to the clock routing, there is often a way to connect from the general routing to the clock routing. That means that you can connect *any* signal to the clock routing, not just external signals on the clock pins. This includes signals from other I/O pins as well as signals from any logic inside the device. I can't imagine that a vendor would limit the clock routing to external signals from a handful of pins. I guess they do that in some CPLDs, but I have not seen it in FPGAs. The clock pins are for a *direct* path from the I/O pin to the clock routing with a *minimum* of delay. This allows minimum and predictable setup times without using a DLL or the like. RickArticle: 139626
"Rob Gaddi" <rgaddi@technologyhighland.com> wrote in message news:20090407093644.00004a8b@unknown... > On Tue, 7 Apr 2009 17:21:27 +0100 > "Dave Wilson" <dave@noaddress.net> wrote: > >> [positively about schematic entry] > > Dave, you seem to be the only guy out here defending schematic entry. > Therefore, obviously, you're not using the horribly crippled Xilinx > schematic tool, which seems to crash more and more with each revision. > > If I may ask, what schematic tool are you using, and what did it run > you? Can it handle structured port types to talk to VHDL? > > -- > Rob Gaddi, Highland Technology > Email address is currently out of order I use Altera Quartus - been using it for the last 22 years or more - including the old DOS version. It is a very solid integrated platform for either schematic or HDL entry, full simulation tools etc with links to external design tools. Yes of course you can mix HDL/schematic exactly how you like. You can download a free web version to try out from www.altera.com. A full license for a years updates is around $2500, but the software is yours - you just don't get updates/support for new devices when the license expires.Article: 139627
On Apr 7, 11:32=A0am, filter...@desinformation.de wrote: > On 7 Apr., 06:20, rickman <gnu...@gmail.com> wrote: > > > > > On Apr 3, 7:02=A0pm, Mike Treseler <mtrese...@gmail.com> wrote: > > > > > On Apr 3, 4:02 pm, gabor <ga...@alacron.com> wrote: > > > >> Have you tried instantiation to make sure what you want to do > > > >> is really possible and there isn't some other gotcha that > > > >> keeps synthesis from coming up with your preferred solution? > > > > I think this is quite likely. > > > > Either there is some non-obvious kludge > > > in the epic architecture, > > > or synthesis missed an optimization. > > > > Unless I were down to my last gate, > > > I wouldn't spend time worrying about > > > which one it is. > > > This is a design that will be used repeatedly and will be used in > > tight quarters. =A0So saving a LUT on every adder and counter can be > > quite useful. =A0I found that a coding style difference saved 3 LUTs in > > an 8 bit adder with overflow detection. =A0That's about a 30% savings. > > In the long run I expect to save about 25% to 30% overall in the > > design. =A0I think that is significant. > > > Yes, what I am trying to do is possible. =A0It just seems like the tool= s > > want to add an inefficiency one way or the other. =A0I wrote to Lattice > > and their suggestion is avoid using the synthesis tool and to > > instantiate my logic. =A0Hmmm. =A0Maybe Lattice shouldn't be my first > > choice in FPGAs. > > Could you fix it by simple post-processing of the netlists from > synthesis? > But Maybe it's a feature to avoid packing or routing problems. I would prefer to live with it rather than to manipulate the netlists. I don't see how it could solve a routing problem because the slices with the carry chain have all the inputs they need, they just are ignoring the output. Then this sum lsb is being duplicated in another LUT elsewhere. Only the output of the sum is not being used and that has dedicated routing so it can't be a problem with congestion at the PFU boundary and the rest of the routing is independent of the PFU. I am thinking that the synthesis is trying to "optimize" the lsb and is just not "aware" that this bit is already calculated in the lsb of the adder. But maybe I am missing something with the routing. I'll take another look at the inputs to the lsb and make sure that *all* of the signals are going both places. But I don't see how it couldn't be, since the second bit is using the carry from the first, so the first bit *must* have all the same inputs that go to the duplicate sum LUT. I may try asking Synplify, but I expect they won't respond since the tools were bought from Lattice and Lattice is supposed to give the support. RickArticle: 139628
Just make sure you specify your clock period in the ucf file and that it passes the static timing report. You shouldnt need to add any other timing constraints in the ucf. I did a sdram design a while back running at 100MHz which worked just fine using the above procedure. Cheers JonArticle: 139629
On Apr 2, 5:25=A0pm, aleksa <aleks...@gmail.com> wrote: > And why is ISE insisting on "HIGH 50 %" when > it is an oscillator clock, who cares if it > started low or high? Some FFs in my design > are using rising_edge, some falling_edge, > but any FF has 50ns from edge to edge. I think ISE can run the timing analysis also on the paths from FFs clocked on the rising edge to FFs clocked on the falling edge. In that case the duty-cycle of the clock does matter. tullioArticle: 139630
thanks, could you point me to that xilinx documentation that explains that? i'm using a counter as a frequency divider because I need to blink a led, so I think I need a 1Hz clock so that the blink is visible on my FPGA. So the solution is to connect my gated clock to each of the CE pins and connect the CLK pin to the FPGA oscillator? Xin <goouse@twinmail.de> wrote in message news:7cc6d8ac-a628-44a2-a208-9d4f1b0cac1f@v15g2000yqn.googlegroups.com... On Apr 5, 2:16 am, "Xin Xiao" <n...@no.com> wrote: > Hello, my question is I'm making a modulo-10 counter using a CB4CLE > counter > (http://www.xilinx.com/itp/xilinx6/books/data/docs/lib/lib0080_48.html) > and > some logic gates. I am making a modulo-10 counter because I need a 1 Hz > clock for my design (the clock input to the counter is a 10 Hz signal). > The > problem is that, when I implement my design to a FPGA, my tool warns me > that > there may be a problem due to clock skew, because the clock is being > generated after a combinational network (two levels of AND gates to detect > when the counter reaches 10). > > My question is simple, is there any other method to build a modulo-10 > counter from CB4CLE modules or I can simply ignore the warning? > > Thank, Hi Xin, as pointed out by KJ it is not a wise idea not to use the global clock nets for clock signals. However it's very tricky to do so with signals created by your own logic. But there is a well working solution to your problem. Build your modulo 10 counter so, that it generates a some kind of ripple signal that is active for only one 10Hz period. Use this signal as a Clock Enable for all the FFs that shall run with 1Hz. The Clock for these FFs is your 10Hz Master Clock. There are papers available, e.g. from xilinx, that discuss this method in detail. ____ Truly, schematic input is not the method of choice for designing FPGA logic, but it's not your fault that you are forced to use it. If you are a student, schematics are helpful to understand digital logic. But if that task is mixed up with understanding how FPGAs work it is like learning to walk during an olympic sprinting competition. _____ One more comment : Ok, you get this warning about possible dangers arising from clock skew. This is definitly true, and would affect your design if you would play in the X- MHz league. But for your 10Hz design you probably could have 64bit combinatorical multipliers in your datapath without being bothered by clock skew problems. Data would be stable way loooong before the next clock edge. (Actually, some logic between your FFs would be very useful in this case.) There's a very good article in the english wikipedia about Clock Skew. Read it for further understanding. Have a nice synthesis EilertArticle: 139631
Xin Xiao wrote: > Hello, my question is I'm making a modulo-10 counter using a CB4CLE > counter Isn't there a CD4CLE? If not, don't gate the clock, just reset the counter whenever the count = 9. Or, preset it to 6 every time it reaches terminal count. JonArticle: 139632
Forgot to mention where the source can be found. The file name is accum48.vhd and it is available from the link below: http://www.xilinx.com/support/documentation/user_guides/ug073_c02.zip /MikhailArticle: 139633
Mark McDougall wrote: > News123 wrote: > >> But just imagine, you're lost in a snow storm and a cylinder of your car >> is broken. >> Then you won't have any CNC machine and you'd be sooo glad to not have >> cheated with a CNC machine during your metalwork course. > > That's fine if you've broken down in Northern America (or thereabouts). > How are you going to get elk antlers in outback Australia??? > > Regards, > Think out of the box. Use a 'roo rib insteadArticle: 139634
Dave Wilson wrote: > Modules designed using schematics are just as portable and re-useable > as those using an HDL Yeah? Do your Quartus schematic designs compile under ISE? > You cannot transfer across vendors without massive rework using an HDL > so that often quoted fact is a farce. > Personally I have never had to - you mean you have? Absolute garbage. You admit that you've never done it, and don't program in it, yet you claim that it requires massive rework. Divine insight? I've done it, on several occasions, with very little rework. >>>>> version control software issues (diff anyone?). > Not a problem. each module has it's own version called from the top > level You've either missed the point entirely, or I don't understand your response. Let me count the number of projects on opencores that are done in schematic... hmm... In any case, it's clear that you - against overwhelming opinion - prefer schematic entry, and that's fine. That you have your shackles up about it is somewhat bemusing... but each to their own... Regards, -- Mark McDougall, Engineer Virtual Logic Pty Ltd, <http://www.vl.com.au> 21-25 King St, Rockdale, 2216 Ph: +612-9599-3255 Fax: +612-9599-3266Article: 139635
On Apr 7, 10:39=A0pm, JuanC <juan.javier.cuel...@gmail.com> wrote: > I'm currently using an ILA and inserting it using 10.1 software, I'm > not having any issues. I'm not saying chipscope and ISE 10.1 are not working at all because I've used them a few times before without having a problem. In my current design, it causes something to happen that avoids the bitstream from being downloaded on the chip (when I simply remove ILA and ICON cores from my design, things go well). I'm not sure but maybe the chipscope cores contain some sort of constraints that conflict with the rest of desing.Article: 139636
Ehsan, The most likely reason for the problem you are having is that the cores are not connected properly, resulting in a non-functional JTAG port. This is why I am trying to convince you to experiment with the Chipscope inserter as it simply won't let you to do something so destructive. /Mikhail "Ehsan" <ehsan.hosseini@gmail.com> wrote in message news:118bd3ee-415a-4286-8741-b510890df72e@x6g2000vbg.googlegroups.com... On Apr 7, 10:39 pm, JuanC <juan.javier.cuel...@gmail.com> wrote: > I'm currently using an ILA and inserting it using 10.1 software, I'm > not having any issues. I'm not saying chipscope and ISE 10.1 are not working at all because I've used them a few times before without having a problem. In my current design, it causes something to happen that avoids the bitstream from being downloaded on the chip (when I simply remove ILA and ICON cores from my design, things go well). I'm not sure but maybe the chipscope cores contain some sort of constraints that conflict with the rest of desing.Article: 139637
On Apr 8, 6:22=A0am, "MM" <mb...@yahoo.com> wrote: > Ehsan, > > The most likely reason for the problem you are having is that the cores a= re > not connected properly, resulting in a non-functional JTAG port. This is = why > I am trying to convince you to experiment with the Chipscope inserter as = it > simply won't let you to do something so destructive. > > /Mikhail > > "Ehsan" <ehsan.hosse...@gmail.com> wrote in message > > news:118bd3ee-415a-4286-8741-b510890df72e@x6g2000vbg.googlegroups.com... > On Apr 7, 10:39 pm, JuanC <juan.javier.cuel...@gmail.com> wrote: > > > I'm currently using an ILA and inserting it using 10.1 software, I'm > > not having any issues. > > I'm not saying chipscope and ISE 10.1 are not working at all because > I've used them a few times before without having a problem. In my > current design, it causes something to happen that avoids the > bitstream from being downloaded on the chip (when I simply remove ILA > and ICON cores from my design, things go well). I'm not sure but maybe > the chipscope cores contain some sort of constraints that conflict > with the rest of desing. hi ILA/ICON cores in the design CAN NOT make the bistream non-working.. chipscope cores will not be activated until AFTER configuration DONE but you are seing done not asserted? the only thing that can be is the startup clock setting, remember that that Chipscope download DOES NOT automatically fix the startup clock setting, while impact DOES fix it (when options are set).. and impact fixes the setting only in the copy of the bitstream while downloading it, the original on the disk remains untouched AnttiArticle: 139638
Hi, In that case if the output clock to sdram which comes from design is, say suppose, 10ns after input clock and the address to sdram which is of 13 bit width is such that first 5 lines (4 down to 0) arrive before the clock to sdram and the remaninig lines arrive after the clock, then the setup time is met for only the first 5 lines of address bus and if give the address as 16'h124 it will write to address location 4 (first five bits of 16'h124). Is my argument correct? If not, please explain. Thanks, gangiArticle: 139639
I have no doubt that a two stage synchroniser works for crossing clk domains (or synchronising any asynchronous signal), however I have struggled for years to get convinced with the theoretical explanations(including the ball over the hill analogy). Surely the first flip will get into wrong output due to timing violation. This wrong output becomes the wrong input to second flip. So how does data get through correctly? Any help appreciated... kadhiemArticle: 139640
On Wed, 08 Apr 2009 02:51:03 -0500, "kadhiem_ayob" <kadhiem_ayob@yahoo.co.uk> wrote: >I have no doubt that a two stage synchroniser works for crossing clk >domains >(or synchronising any asynchronous signal), however I have struggled for >years to get convinced with the theoretical explanations(including the ball >over the hill analogy). >Surely the first flip will get into wrong output due to timing violation. >This wrong output becomes the wrong input to second flip. So how does data >get through correctly? Actually the problem is not "wrong output due to timing violation" ie if sampling time is during the change of the input signal then the exact value of the signal is difficult to determine so there is no "wrong value" as such; you should be happy with either 1 or 0. The problem is that sometimes, very rarely, you get neither; ie the output of the sampler meanders mindlessly for a while before it takes a value of 1 or 0 and this causes all kinds of havoc downstream. And strictly speaking, two stage synchronizer doesn't always work either. It reduces the probability that the meta-stable event will happen. This probability is inversely proportional to the clock period and the speed of the sampler. So after the first sampler the longer time you wait, the lower the probability becomes. For most design points a second sampler is enough to lower it to acceptable levels. Every synchronizer you add to the chain lowers the probability exponentially but never to zero. But of course one only has to worry about a MTTF which is longer than the life of our star for which a 4 stage synchronizer would be enough in most cases. It's either that or till your PC crashes next time some time during the next week for which even a 2 stage synchronizer is overkill :-) Muzaffer Kal DSPIA INC. ASIC/FPGA Design Services http://www.dspia.comArticle: 139641
If the flip output is irrelevant(being 0 or 1 or undefined) then we got problem with data value integrity rigt from the start of chain. We need to separate between the issue of metasatibilty probability and data value crossing. surely the probability of metastability goes down after every stage but data value goes wrong through anyway from the start irrespective of probability issue. This is what puzzles me. kadhiemArticle: 139642
On 8 Apr., 10:40, "kadhiem_ayob" <kadhiem_a...@yahoo.co.uk> wrote: > surely the probability of metastability goes down after every stage but > data value goes wrong through anyway from the start irrespective of > probability issue. This is what puzzles me. What is the wrong about that value? You have two free running clocks that both have uncertainties (Frequency drift, jitter.) Now it happens that you sample an input close to a value transition depending on the exact phase of your clock 0 or 1 might be the correct value. You application mus work in either case, because it does not know enough about the clocks to expect one or the other. You need other machanisms to handle that issue. For asyncrhonous serial protocols you could for example use oversampling. With 8x oversampling you know the phase of the input data some time ago with 13% accuracy. If your clocks are atleast somewhat stable you can deduce where the next transition should occur and select a sample that is save. Kolja SulimmaArticle: 139643
>On 8 Apr., 10:40, "kadhiem_ayob" <kadhiem_a...@yahoo.co.uk> wrote: > >> surely the probability of metastability goes down after every stage but >> data value goes wrong through anyway from the start irrespective of >> probability issue. This is what puzzles me. > >What is the wrong about that value? >You have two free running clocks that both have uncertainties >(Frequency drift, jitter.) Are you saying that the first flip will sample its input correctly despite the fact that it will be plagued with timing violations? Will its Q output equal its D input regularly? In that case why do we bother about any clked design timing issues at all? >You need other machanisms to handle that issue. For asyncrhonous >serial protocols you could for example use oversampling. With 8x >oversampling Sorry but we are on the wrong track of discussion now... Regards kadhiemArticle: 139644
Muzaffer Kal <kal@dspia.com> wrote: (snip) > Actually the problem is not "wrong output due to timing violation" ie > if sampling time is during the change of the input signal then the > exact value of the signal is difficult to determine so there is no > "wrong value" as such; you should be happy with either 1 or 0. > The problem is that sometimes, very rarely, you get neither; ie the > output of the sampler meanders mindlessly for a while before it takes > a value of 1 or 0 and this causes all kinds of havoc downstream. > And strictly speaking, two stage synchronizer doesn't always work > either. It reduces the probability that the meta-stable event will > happen. Yes. > This probability is inversely proportional to the clock period > and the speed of the sampler. Metastability resolution is exponential in the time available. With only one FF, the available time is the clock period minus the propagation time to the next FF. (Possibly to more than one FF.) For high speed designs, the added propagation delay can be enough that the probability is significant. > So after the first sampler the longer > time you wait, the lower the probability becomes. For most design > points a second sampler is enough to lower it to acceptable levels. > Every synchronizer you add to the chain lowers the probability > exponentially but never to zero. Never to zero, but with minimal propagation delay, and with the assumption that the clock period is constrained by propagation delay elsewhere in the design, it should be enough. Additionally, the design should allow for either possible value. For one signal, that usually isn't a problem. With more than one signal, it is possible that some will change before the clock transition, and some after, even without any metastability. Gray code is sometimes used to get around that problem. -- glenArticle: 139645
kadhiem_ayob <kadhiem_ayob@yahoo.co.uk> wrote: > If the flip output is irrelevant(being 0 or 1 or undefined) then we got > problem with data value integrity rigt from the start of chain. > We need to separate between the issue of metasatibilty probability and > data value crossing. Yes, but both problems occur when there is no known relationship between the two signals. > surely the probability of metastability goes down after every stage but > data value goes wrong through anyway from the start irrespective of > probability issue. This is what puzzles me. In the case of a slow clock and multiple signals, it might be that you would only have worry about the different signals and not about metastability. In a large fraction of the cases, though, one wants the clock to be as fast as possible. -- glenArticle: 139646
"kadhiem_ayob" <kadhiem_ayob@yahoo.co.uk> wrote: >Are you saying that the first flip will sample its input correctly despite >the fact that it will be plagued with timing violations? Will its Q output >equal its D input regularly? In that case why do we bother about any clked >design timing issues at all? No. A "metastable" Q output from the first stage does not refer to a "wrong" output value, such as it being a "1" when it should be a "0", but about the Q output getting stuck half-way or oscillating for a while, which can happen if its D input was in transition when it was clocked. If that metastable Q output was fed to, for example, an incremental counter, then that counter could do something worse than incrementing or not incrementing -- like making a big jump to a completely different value because its own setup time was violated. *That* is why metastable states are considered so nasty. Adding a second d-type with a short propagation delay from the first means that there's a whole clock cycle for the first stage to come out of metastability and give a good setup time for the second D-type, so that *its* Q output is either a secure 0 or 1 but not something between the two. Thus it becomes a negligible source of error compared to a system's overall reliability. Understand now? >>For asyncrhonous serial protocols you could for example use oversampling. ... >Sorry but we are on the wrong track of discussion now... It's an example where you'd need to tolerate the uncertainty of an signal being read either as a 0 or a 1 for a few ticks of the receiving circuit, but where things would go horribly wrong if metastability was able to propagate into the core of the receiving circuit. -- Dave FarranceArticle: 139647
>No. A "metastable" Q output from the first stage does not refer to a >"wrong" output value, such as it being a "1" when it should be a "0", but >about the Q output getting stuck half-way or oscillating for a while, >which can happen if its D input was in transition when it was clocked. If >that metastable Q output was fed to, for example, an incremental counter, >then that counter could do something worse than incrementing or not >incrementing -- like making a big jump to a completely different value >because its own setup time was violated. *That* is why metastable states >are considered so nasty. > >Adding a second d-type with a short propagation delay from the first >means that there's a whole clock cycle for the first stage to come out of >metastability and give a good setup time for the second D-type, so that >*its* Q output is either a secure 0 or 1 but not something between the >two. Thus it becomes a negligible source of error compared to a system's >overall reliability. Understand now? unfortunatley it is not convincing. it is ok for a discussion of Metsatability per se but not data transfer. the above argument states clearly that first Q output is not copy of D input but is unstable halfway. So is the input to second flop. Now lets look at value rather than stability at second Q output, stable yes but correct who knows... Sorry for being so microanatomical but history has other examples when consensus doesn't fit reality kadhiemArticle: 139648
On Apr 8, 8:51=A0am, "kadhiem_ayob" <kadhiem_a...@yahoo.co.uk> wrote: > I have no doubt that a two stage synchroniser works for crossing clk > domains > (or synchronising any asynchronous signal), however I have struggled for > years to get convinced with the theoretical explanations(including the ba= ll > over the hill analogy). > Surely the first flip will get into wrong output due to timing violation. > This wrong output becomes the wrong input to second flip. So how does dat= a > get through correctly? > > Any help appreciated... > > kadhiem There's an online presentation that goes into the various effects off async clock domain crossing and the use of 2 x DFF synchronisers that you may find useful. This is part of a verification seminar covering Mentor's 0-In CDC verification solution and can be found here: https://admin.na3.acrobat.com/_a781163502/vscdc/ Regards - Nigel Mentor GraphicsArticle: 139649
kadhiem_ayob <kadhiem_ayob@yahoo.co.uk> wrote: >>No. A "metastable" Q output from the first stage does not >> refer to a "wrong" output value, such as it being a "1" when >> it should be a "0", but about the Q output getting stuck half-way >> or oscillating for a while, which can happen if its D input was >> in transition when it was clocked. >> If that metastable Q output was fed to, for example, an >> incremental counter, >>then that counter could do something worse than incrementing or not >>incrementing -- like making a big jump to a completely different value >>because its own setup time was violated. *That* is why metastable >> states are considered so nasty. >>Adding a second d-type with a short propagation delay from the >>first means that there's a whole clock cycle for the first >>stage to come out of metastability and give a good setup time >> for the second D-type, so that *its* Q output is either a >> secure 0 or 1 but not something between the two. >> Thus it becomes a negligible source of error compared to a >> system's overall reliability. Understand now? > unfortunatley it is not convincing. it is ok for a discussion of > Metsatability per se but not data transfer. I believe it is a good explanation, but yes it is two different effects. > the above argument states clearly that first Q output is not copy of D > input but is unstable halfway. So is the input to second flop. Now lets > look at value rather than stability at second Q output, stable yes but > correct who knows... The design must work with either value. For one signal, it is always correct, as one can't say as it gets arbitrarily close to the transition. For multiple signals, the design must work even if some transition before and some after the clock edge. That is why gray code is used in FIFOs. > Sorry for being so microanatomical but history has other > examples when consensus doesn't fit reality. Many designs work at a clock frequency close to the maximum. That might allow the delay to be 90% of the clock period. Metastability resolution is exponential, so that with 10 times as much resolution time, the probabilty of unresolved metastability with a second FF is the 10th power of the probability without one. (1/(1-0.9)) -- glen
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