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
In article <3F559A3F.91184B1A@yahoo.com>, rickman <spamgoeshere4@yahoo.com> wrote: > >There is no way to determine when a circuit is metastable or not. Async >circuits are not magic, they just depend on predictable delays, just >like any other circuit. The design is different because there is no >common clock so each circuit can run with its own delay. Since the next >circuit will take the output when it is ready, there is no problem with >synchronization. Silly question: I don't see why an ANALOG flip-flop couldn't determine that it is in the intermediate state at some fixed interval after the clock, and then force the flop one way or another. Of course, it might double-glitch in the meantime (flop goes up before logic forces it down), but it would make a flop with a fixed-maximum metastabel interval. Of course, it seems like such a massive headache to do. >One problem I do see is that if each stage has a different delay, then >it can not accept a new input from the preceding stage until the output >has been taken by the following stage. It seems in the end the async >circuit will run no faster than the slowest stage, which is what the >sync clocked circuit will do. The trick with asynchronous logic is that the longest stage WHICH IS IN THE COMPUTATION is the critical path. EG, if 9 of the stages take 1 ns, and the last takes 2ns, but the last only affects 1/2 the data, with the asynchronous circuitry doing the shortcutting, it will be considerably faster than the synchronous one. The problem is: You can automatically balance the pipelining (retiming) for a synchronous circuit, while asynchronous really playes havoc with the CAD flow and testing. -- Nicholas C. Weaver nweaver@cs.berkeley.eduArticle: 60001
Hi Jonathan - I've evaluated Aldec and used ModelSim, HDL Designer, and Cadence NC-Sim quite a bit over the last 5 years. Several of the engineers that I've worked with over that time tend to agree with the opinion that I've developed about Aldec and ModelSim/HDL Designer, but that's still just my humble opinion along with a just a few other guys - everyone has their own take. Our general conclusion was that Aldec is an excellent tool for small projects, engineers new to combined HDL/Schematic Capture/Simulation environments, and extremely cash-strapped organizations. As you move into larger projects with an engineering team of up to 5 or 6 engineers, HDL Designer really starts to provide some benefits over Aldec that start to justify the price tag. (Can you tell yet that I think the Mentor tools are over priced?) Most folks that I have talked to that have used HDL designer focus on just a few features - block diagram editing and creation either by schematic capture or existing HDL import, integrated version management, push-button simulation or synthesis flow (simulation is much more 'push-button' than synthesis, for many reasons) and flexibility. By flexibility, I mean that you can use just about any text editor you like, and now they have added additional 'modes' of support for text file based code so you can now have a text file that the tool itself never modifies. And also, the PERL plug-in interface that runs downstream flows (simulation, synthesis, or whatever you want to create). Personally, I really like the PERL plug in environment because if there are bugs (and there have been) I can fix them myself and not have to wait for a new release. I can also modify a downstream interface to better suit the needs of my design environment. HDL Designer does not have a very steep learning curve for the basic features. The advanced features, however, do require some time. It takes a while to figure out the details of the PERL downstream interface - it is relatively complex under the hood. Also remember that the HTML documentation feature is only available in the full-up version and in HDL Detective, which allows full text to graphics import but no graphical editing. There used to be more options in the features that you got, but now they have 'simplified' it - meaning they all cost more. ;-) As the tool is offered now, the only truly beneficial combination of features for a design team are found in the full version, IMHO. As always though, your mileage may vary. You might find that Aldec is just what you want and HDL Designer annoys you to no end. That's why I strongly advise anyone to EVALUATE - and try to stretch that evaluation as long as you can, because you may find a showstopper issue. The vendors may whine a bit, but usually will give you a fairly long string of evaluation licenses if you really need to continue your testing of the tools. Best of luck! Kleven "Jonathan Bromley" <jonathan.bromley@doulos.com> wrote in message news:biv4fl$17e$1$8300dec7@news.demon.co.uk... > "Paul Baxter" <pauljnospambaxter@hotnospammail.com> wrote in > message news:3f524aa7$0$254$cc9e4d1f@news.dial.pipex.com... > > > At the risk of starting a toolset discussion, I would recommend > > www.aldec.com and their ActiveHDL product. > > > > Its mainly a very user friendly simulator (still not perfect, but a lot > > friendlier than Modelsim > > Can you explain a bit more please? I've heard many people say that > Aldec is more "user-friendly", but personally (strictly personally!) > I've always found its project system and its obsessive copying of > files from place to place to be thoroughly confusing. It makes > life very easy for you if you have just an HDL design and a > single testbench file and no other tools interested in those > source files, but as soon as I try to do anything more complicated > I get hopelessly mired in its bizarre project system. (By the > way, I always detested the Aldec project machine in the older > Xilinx tools!). > > Once again, for emphasis: this is my personal opinion only; > we're happy to support any simulators for our training > courses and other work; and my experience with Aldec > is fairly limited, whereas I use ModelSim for the majority > of my day-to-day HDL work. So I'd be delighted to hear from > any Aldec champions out there. > -- > > Jonathan Bromley, Consultant > > DOULOS - Developing Design Know-how > VHDL * Verilog * SystemC * Perl * Tcl/Tk * Verification * Project Services > > Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24 1AW, UK > Tel: +44 (0)1425 471223 mail: jonathan.bromley@doulos.com > Fax: +44 (0)1425 471573 Web: http://www.doulos.com > > The contents of this message may contain personal views which > are not the views of Doulos Ltd., unless specifically stated. > > >Article: 60002
"Tom Seim" <soar2morrow@yahoo.com> wrote in message news:6c71b322.0309021211.522fed48@posting.google.com... > > The processes that will go up to 100s will take an average of 8 values and > > store that value to the external memory. In that way the data are minimised > > by a factor of 8 and the system error is negligible. > > The SRAM that was found can be used in the architecture of 1M x 72bit, so 8 > > accesses in parallel times two in 40 us seems to be more than ok > > One problem now is how to implement this! my experience do go that far! > > You've said something about instantiating a processor (I guess something > > like NIOS), are you sure that this will not complicate things more? > > Is there something ready to implement a circular buffer to the external ram? > > > > The second problem, and the reason why I asked for help in this group, is > > that those SRAMS are quite expensive and having in mind that 2000 of them > > will be needed, it increases the cost significantly. So they are pressing me > > to find some other way to implement it. (usual stuff: we want the pie and > > the dog fed!) > > I don't understand why you need 2000 SRAMs. > > 25 KHz x 16 x 100 = 40 MB > > or 8 SRAMs. In the first paragraph I explain that saving the average values of 8 samples the data are minimised by a factor of 8. So 5 MB have to be stored for this system (up to 100s) which fit together with the data of the first system (up to 10ms) in one SRAM. On the card there are 2 more to hold other data. And 650 of these cards are needed, that gives ~2000 SRAMs. Sorry for not been that clear but the mail was already too long and I didn't want to kill you with boredom completely! ChristosArticle: 60003
Ray, Thanks for your quick response. You raise some excellent points clearly derived from experience. Hopefully my program will still be useful when filters can be fixed early on in the project or when a synthesis/place and route run is an acceptable cost for the area efficiency provided. Also, for devices being used in consumer applications, perhaps the area saved using a multiplier block filter would allow a smaller and cheaper device within the family to be used - reducing production costs depending on the number of units being produced. Cheers, Ken "Ray Andraka" <ray@andraka.com> wrote in message news:3F55E8A3.70936FBD@andraka.com... > I agree the multiplier block style filters are more efficient area-wise. It > sounds like you have addressed the irregularity issues by using a program > to do the generation, which I think is pretty much a necessity. As I thought > I alluded to, the biggest problem with multiplier block filters is that the > layout/size is not a constant if you change the coefficients. This means that > the fiter coefficients have to be constant and known earlier in the design > cycle, and necessitates a rerun of synthesis, place and route for any filter > changes. Depending on the implementation, it may also mean a change in the > filter's pipeline latency. These factors can make them difficult to use on > some projects. The filters typically used in my projects often need to be > adjusted by the customer or late in the project to accommodate minor > requirements changes. I prefer to use a filter with reloadable coefficients > for that reason. > > > > Ken wrote: > > > Ray, > > > > I sent this to Michael via email and he suggested the group would be > > interested also... > > > > My PhD (now drawing to the end) has been on implementing full-parallel > > Transpose FIR filters using multiplier blocks that you mention (I use > > techniques/algorithms that exceed the efficiency of CSD in terms of FPGA > > area). > > > > The upshot of my work is that I have written a C++ program that will > > generate RTL VHDL given the quantised filter coefficients, the type of > > filter required (singlerate, interpolation, decimation etc.) and the > > appropriate parameters (input width, signed/unsigned input, number of > > channels, rate-change factor etc.) > > > > The VHDL my program generates exceeds the functionality (at a lower > > cost) of that provided by Xilinx's Distributed Arithmetic core and Altera's > > FIR Compiler (also DA). In fact, my program allows interpolation and > > decimation factors up to the number of filter coefficients and any number of > > data channels (for interpolation/decimation filters also). > > > > The main point is that, once synthesised and mapped to a specific FPGA, the > > filters my program generates require far less FPGA area (slices/logic cells) > > than those generated using Distributed Arithmetic. The critical path in my > > filters is just the longest adder carry chain so very high speeds are > > possible. E.g. 154MHz for a singlerate filter (25 bit output) in a Xilinx > > xc2v3000-fg676-5 - obviously the speed will depend on the device > > family/speed grade and the longest carry chain. The facility for multiple > > channels in interpolation/decimation filters (not supported by Xilinx) > > allows lower than full-parallel sampling rates to be efficiently processed > > in one filter. > > > > As Michael points out in his post, this technique would be very suitable for > > a > > Xilinx Spartan-IIE and indeed any FPGA - there are many cases where these > > filters would be useful even on devices with dedicated multipliers (when > > they are all in use for example! ;-) ). > > > > You can find out more at http://www.dspec.org/rsg.asp - there are also > > datasheets here that provide comparisons with Xilinx and Altera and > > demonstrate the output of another application (written in java) that > > generates schematic representations of the filters for use in reports, > > meetings and thesises! :-) > > > > I hope this information is of use to you - please contact me if you have any > > questions, > > > > Thanks for your time, > > > > Ken > > > > -- > > To reply by email, please remove the _MENOWANTSPAM from my email address. > > > > "Ray Andraka" <ray@andraka.com> wrote in message > > news:3F54F936.5E694FD1@andraka.com... > > > The problem with the multiplier block approach is that the > > > construction is predicated on the specific coefficients. As > > > a result it is considerably harder to use for an arbitrary > > > set of coefficients. It may reduce area over a straight FIR > > > filter running at the same clocks per sample, but at a > > > considerable cost in design time and flexibility. You also > > > give up regularity in the structure, which may reduce the > > > overall performance. Essentially what the block multiplier > > > and distributed arithmetic approaches are is a rearrangement > > > of the bitwise product terms. The mutliplier block takes > > > advantage of duplicate terms by adding the inputs before > > > they are multiplied by the term. > > > > > > Michael Spencer wrote: > > > > > > > Hello, > > > > > > > > Has anyone compared FPGA implementations of full-rate > > > > digital FIR filters based on the use of Multiplier Blocks > > > > vs. traditional FIRs with constant coefficient > > > > multipliers? By full rate, I mean: one output result per > > > > clock cycle and no interpolation or decimation. > > > > > > > > For anyone not familiar, a multiplier block is a network > > > > of shifters and adders that performs multiplications by > > > > several coefficients efficiently by exploiting common > > > > sub-expressions. The multiplier block can be exploited in > > > > FIR filters by transposing the standard filter so that the > > > > products of all the coefficients with the current > > > > input-sample are required simultaneously. > > > > > > > > Also, by representing the coefficients in the > > > > Canonical-Signed-Digit number system (a small number of > > > > +1 and -1's) along common sub-expression sharing the > > > > multiplier block can get even smaller. > > > > > > > > For example, the multiplier block for a 100 tap FIR filter > > > > (fp=0.10 and fs=0.12) can be realized with only 61 adds > > > > (zero explicit multiplications). See filter example #4 in > > > > "FIR Filter Synthesis Algorithms for Minimizing the Delay > > > > and the Number of Adders," > > > > http://ics.kaist.ac.kr/~dk/papers/TCAD2001.pdf > > > > If the adder depth is constrained to a maximum of four, > > > > then the authors' algorithm can do the multiplier block in > > > > 69 additions. > > > > > > > > It would seem that this approach would be very efficient > > > > in a target such as the Xilinx Spartan-IIE (with no > > > > dedicated multipliers). > > > > > > > > Another question: If we only need one result per K clock > > > > periods (K ~= 1000 for audio applications), could a > > > > multiplier block approach realized with, say, bit-serial > > > > addition be more efficient than some other approach such > > > > as distributed arithmetic? > > > > > > > > Comments welcome. Thanks. > > > > > > > > -Michael > > > > ______________________ > > > > Michael E. Spencer, Ph.D. > > > > President > > > > Signal Processing Solutions, Inc. > > > > Web: http://www.spsolutions.com > > > > > > -- > > > --Ray Andraka, P.E. > > > President, the Andraka Consulting Group, Inc. > > > 401/884-7930 Fax 401/884-7950 > > > email ray@andraka.com > > > http://www.andraka.com > > > > > > "They that give up essential liberty to obtain a little > > > temporary safety deserve neither liberty nor safety." > > > -Benjamin > > > Franklin, 1759 > > > > > > > > -- > --Ray Andraka, P.E. > President, the Andraka Consulting Group, Inc. > 401/884-7930 Fax 401/884-7950 > email ray@andraka.com > http://www.andraka.com > > "They that give up essential liberty to obtain a little > temporary safety deserve neither liberty nor safety." > -Benjamin Franklin, 1759 > >Article: 60004
Symon, Agreed. D FF is what I was assuming here, but folks do have different ways of building them, and not all master-slave implementations are the same (in fact I have seen perhaps a dozen different versions). Peter will have some explaining to do when he gets back .... as the quote does sound odd. There is most definitely voltage levels that remain in the undecided region for various lengths of time until the circuit resolves its state. Austin Symon wrote: > Hi Austin, > Maybe I got the wrong end of the stick, but when Peter said:- > "I have never seen strange levels or oscillations ( well, 25 years ago > we had TTL oscillations). Metastability just affects the delay on the > Q output." I thought he meant that he'd only seen metastability where > the output from the FF was always either on or off, just that > sometimes the transition was delayed. Philip's pictures clearly show > 'strange levels'. This is important, I believe, when deciding what the > effects of metastable FFs are on following circuitry. I guess we'll > have to wait until he returns from his Portugese jaunt before we find > out what he meant!! > Of course, I agree the Master/Slave thing helps. A master FF > on its own is what I'd call a latch, the clock controlling whether > it's transparent or not. The slave is the sameish circuit again, fed > from the output of this, but its clock is inverted. So, I guess that > you're saying because the master and slave are fabricated right next > to each other, the input to the slave can be expected to transition > faster than the input to the master which travels from further away? > Less capacitive interconnect to drive. (BTW, I assumed throughout the > metastability stuff we were talking about D-type FF, rather than > latches.) > thanks, Syms. > > Austin Lesea <Austin.Lesea@xilinx.com> wrote in message news:<3F550102.DC2B872F@xilinx.com>... > > Symon, > > > > I think the sampling o-scope shots agree perfectly with what Peter said. > > Runt pulse, and funny levels are the easiest metastable results to catch, > > as they are just before the long unknown settling time behavior that is so > > vexing to designers. > > > > It also makes a difference where you look: a master-slave FF reduces the > > duration of the unknown transistion over a simple FF without a slave to > > help "sharpen up" the transistions. > > > > Austin > > > > Symon wrote: > > > > > Hi Philip, > > > Thanks for your post, those pictures were certainly very > > > interesting! What parts did you use? I notice they seem to disagree > > > with Peter's quote that "Metastability just affects the delay on the Q > > > output.". I wonder, Peter, if Xilinx FFs behave differently from the > > > ones in Philip's photos? (Other than speed, of course.) I must admit, > > > one reason I posted was that I found hard to believe that any FF > > > wouldn't show runt pulses, or funny output levels, albeit for brief > > > periods of time, during metastable events. > > > It's also interesting that the straight shift register isn't > > > necessarily the best way to reduce metastability effects. That was > > > what I suspected and was another reason behind my post. I agree that > > > the 'four paths out of phase' solution is better, and preserves the > > > sampling resolution. Often the sampling resolution needs to be > > > preserved, which was why I didn't present an 'enabled every third or > > > fourth go' type circuit. > > > Anyway, thanks to all for their thoughts, it's an interesting > > > topic! > > > cheers, Syms.Article: 60005
Rick, I agree that the effect is the same: you just don't know when it will resolve, and thus the value that you "see" at the next level is basically unknown. It could be that Peter's point is that the next circuit in line does make a decision, and it most certainly makes the "unknown" into a '1', or into a '0'. It is unlikely that the next circuit in line will propagate the same intermediate behavior, and if it can (gain is too low), then things just get more fuzzy until someone upstream ends up resolving the level back to a '1' or a '0'. Austin rickman wrote: > Symon wrote: > > > > Hi Austin, > > Maybe I got the wrong end of the stick, but when Peter said:- > > "I have never seen strange levels or oscillations ( well, 25 years ago > > we had TTL oscillations). Metastability just affects the delay on the > > Q output." I thought he meant that he'd only seen metastability where > > the output from the FF was always either on or off, just that > > sometimes the transition was delayed. Philip's pictures clearly show > > 'strange levels'. This is important, I believe, when deciding what the > > effects of metastable FFs are on following circuitry. I guess we'll > > have to wait until he returns from his Portugese jaunt before we find > > out what he meant!! > > I think the exact behavior is largely irrelevant since a simple delay is > just as disasterous as anything else you would encounter. Since you > don't know *when* the transition would happen, it could happen at the > moment the next FF is latching the intermediate value. That is enough > for the next FF and all following logic to behave badly as well. > > -- > > Rick "rickman" Collins > > rick.collins@XYarius.com > Ignore the reply address. To email me use the above address with the XY > removed. > > Arius - A Signal Processing Solutions Company > Specializing in DSP and FPGA design URL http://www.arius.com > 4 King Ave 301-682-7772 Voice > Frederick, MD 21701-3110 301-682-7666 FAXArticle: 60006
Luiz, Last things first, the LVTTL input does not use the comparator(s) (there are three different comparators, as well as other ciruits for the various input standards). The comparator is designed to have a relatively high gain, so that it switches quickly. As I said, the offset voltage is due to the Vt mismatch on the pmos and nmos diff pairs, and since these are built with .35u (VII) or .25u (VII Pro) transistors, they are pretty darn fast diff-amps. There is a classic gain stage after the cmos diff-amp (similar to the ones in "CMOS Circuit Design, Layout & Simulation" by Baker, Li, and Boyce). The offset voltage is typically less than a few 10's of mV (say 10 to 20 mV worst case). I am sure that if you vary the voltage difference slowly enough, you could measure the gain of the diff-amp. It was designed for HSTL and SSTL IO standards, which as someone already pointed out, are pretty sloppy. What I will point out here, is that I am not aware of any monolithic separate comparator that is as fast as the one that is in the input circuit. This comparator is good for 400 Mbs+ speeds, which is a lot faster than most separate IC comparators.... Austin Luiz Carlos wrote: > Hi Austin. > > First, as Andrey pointed out, I took the wrong table. > The best values are for GTL: > Vout = low, if Vin <= Vref - 0.05 > Vout = high, if Vin >= Vref + 0.05 > > > There is some samll offset voltage from the mis-match between the > > differential pairs (both nmos and cmos to cover the voltage range). I > > do not know what this offset might be, but I suspect it is less than a > > few tens of millivolts, worst case from the transistor models. > > > > The comparator will switch as soon as the voltage is greater than the > > offset (we spec 100 mV for speed reasons, not because it needs > 100 mv > > to function). > > > > So with 50 mV it will switch, just more slowly than if it was 100 mV. > > I really would like to know what this offset is and to have a speed > versus offset formula. > > But, let's suppose we didn't reach the offset value. If we range Vin > from Vref-Voffset to Vref+Voffset, I think Vout will range from Vlow > to Vhigh monotonically, maybe almost linearly. Am I right? > > Now, if we sample Vout with the input data flip-flop, FF DOUT will be > 0 or 1 (forget about metastability for now). Can I say there is Vthr > where: if Vout>Vthr then DOUT=1 and if Vout<Vthr then DOUT=0? What > does happen when we feed a data flip-flop with an analog signal? > > I also would like to know if when we define an input as LVTTL (for > example), the same input comparator is used (Vref connected to an > internal reference), or if it is bypassed. > > Luiz CarlosArticle: 60007
John, Uh, it is an anolog comparator....just one optimized for HSTL and SSTL inputs. Comments about noise are well put, and need to be considered if the comparator is on the same chip, on the same board. But to imply that we could somehow be sloppy, and design a crummy comparator is a bit unfair, the comparator is probably much better than any single device you could name, it is just that we did not characterize any more than we had to. Austin John_H wrote: > "Luiz Carlos" <oen_br@yahoo.com.br> wrote in message > news:8471ba54.0309020217.567a3f03@posting.google.com... > > Peter, Austin! > > Nobody can help me? > > > > Luiz Carlos > > Maybe they can shed some light, but using a digital circuit for analog > functions is like trying to use a car as a tractor. It might work but it > sure as heck wasn't designed to plow fields - you're bound to have problems. > > Since digital logic has fixed thresholds and large noise margins (difference > beteween Vih and Vil) there's no need for the designers to be detailed about > keeping the internal noise to the sub-millivolt level when there's so much > activity in the adjacent I/O cells or internal logic. > > The Vref pins on the bank are designed for I/O signalling where the > threshold does not change so dynamically changing this value dramatically > can have unforseen effects. > > LVDS signalling produces the best differential capability, allowing a > dynamic "Vref" for your doomed analog comparator in the digital device but > the noise margin for LVDS is still a rather large value. > > If you put nothing else in the FPGA, I imagine you could get good noise-free > results with a consistent transition (though subject to an offset voltage in > the many 10s of millivolts). My guess is you want more than just the analog > comparator in there. > > Consider using... an analog comparator! > > - John_HArticle: 60008
>Silly question: I don't see why an ANALOG flip-flop couldn't determine >that it is in the intermediate state at some fixed interval after the >clock, and then force the flop one way or another. Of course, it >might double-glitch in the meantime (flop goes up before logic forces >it down), but it would make a flop with a fixed-maximum metastabel >interval. DING DING DING Nobody has been able to fix metastability yet. If you really have a fix, it's worth a Nobel Prize. The usual problem with that sort of approach is that you get a runt pulse on the fix-it signal in cases that would have worked correctly without it. -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.Article: 60009
In article <vlc0kv1m4flm5f@corp.supernews.com>, Hal Murray <hmurray@suespammers.org> wrote: >>Silly question: I don't see why an ANALOG flip-flop couldn't determine >>that it is in the intermediate state at some fixed interval after the >>clock, and then force the flop one way or another. Of course, it >>might double-glitch in the meantime (flop goes up before logic forces >>it down), but it would make a flop with a fixed-maximum metastabel >>interval. > >DING DING DING > >Nobody has been able to fix metastability yet. If you really have >a fix, it's worth a Nobel Prize. > >The usual problem with that sort of approach is that you get >a runt pulse on the fix-it signal in cases that would have worked >correctly without it. Yes, but the point is it would fix the maximum metastability window, which is the key requirement, as "did the data come before or after the clock edge" is really an irrelevant question at the metastable capture point, you jsut want it to go to ONE or the other (not stick around and make up its mind a half clock cycle later), and possibly to tell you. This isn't FIXING metastability, this is detecting and responding to it, changing an exponentially decaying bounds into a fixed bounds. Of course, it seems like way too big a headache to bother with. -- Nicholas C. Weaver nweaver@cs.berkeley.eduArticle: 60010
Hi, I'm trying to connect a user peripheral to the Microblaze OPB bus. I have done all as mentioned in the "User Core Template for OPB (Slave Services Package 0) but without success. I have added some code lines in the correponding places to match the IPIF to my user_core. I have routed the Bus2IP_CS, Bus2IP_WrCE and Bus2IP_RdCE to some user leds in my development board and I haven't noticed any effect, so I imagine that I'm not accesing to my peripheral. I have also checked the BASEADDR and the HIGHADDR and I think they're correct. Here you are part of my MPD file PARAMETER c_baseaddr = 0xFFFFFFFF, DT = std_logic_vector, MIN_SIZE = 0xFF PARAMETER c_highaddr = 0x00000000, DT = std_logic_vector PARAMETER c_mir_baseaddr = 0xFFFFFFFF, DT = std_logic_vector, MIN_SIZE = 0xFF PARAMETER c_mir_highaddr = 0x00000000, DT = std_logic_vector PARAMETER c_user_id_code = 3, DT = integer PARAMETER c_include_mir = 0, DT = integer PARAMETER c_opb_awidth = 32, DT = integer PARAMETER c_opb_dwidth = 32, DT = integer PARAMETER c_family = virtex2, DT = string Note that I actualize "c_baseaddr" and "c_highaddr" parameters on the component as well as the "c_mir_baseaddr" and "c_mir_highaddr". I'd be very grateful if someone could help me. Thanks. Arkaitz.Article: 60011
Andrea wrote: > I don't want to modify a complex VHDL code, Why not? If there isn't a functional testbench, that is your first job. Once you have a testbench, you can easily verify your changes. > moreover the architecture > pipeline needs latch to work properly without loosing performances. You can pipeline just as fast with D flops. Use a PLL to double the clock if need be. > What do you suggest? Take the bull by the horns and design out the latches. -- Mike TreselerArticle: 60012
Jay wrote: > > This is slightly off-topic but what do people in here use to create > their digital logic block diagrams? related thread: http://groups.google.com/groups?q=does_it_work_yet -- Mike TreselerArticle: 60013
Hi, I used your circuit to switch between the two clocks. However, when I synthetise in Xilinx ISE 5.2, I get the following warning: (*) These 2 clock signal(s) are generated by combinatorial logic, and XST is not able to identify which are the primary clock signals. Please use the CLOCK_SIGNAL constraint to specify the clock signal(s) generated by combinatorial logic. I don't really understand what it means. I guess I need to tell ISE that the output of the circuit is a clock, but I don't know how... Thanks a lot David "Peter Alfke" <peter@xilinx.com> wrote in message news:3F4E7B2D.CFBD1D0D@xilinx.com... > Click at > http://www.xilinx.com/xcell/xl24/xl24_20.pdf > > This circuit allows totally asynchronous selection between two clock sources. > But remember: both clock must be wiggling (however slowly). You cannot > use this circuit to enable/disable a clock, which is actually a far > simpler problem. > The BUFGMUX in Virtex is not quite this clever, it has a set-up time > requirement on the S control input. :-( > Glad that someone found this old tidbit useful... > Peter Alfke > ============================= > Marten wrote: > > > > "David Lamb" <gretzteam_nospam@yahoo.com> wrote in message > > news:bilfne$sel$1@home.itg.ti.com... > > > Hi all, > > > I have a vhdl component with a "clock_in" input. Depending on the mode of > > > operation, I want to switch between two different clock signals. I will > > > never switch on the fly though. Can I use a mux in front of the clock_in > > > input? I'm afraid it might glitch. > > > Thanks > > > David > > > > > > > > > > David, > > > > Do a query for 'clock sources' in the category 'XCELL Journals' on the > > Xilinx web site. This will provide you with a link called 'XCELL 24 - > > Trouble-Free Switching Between Clocks (Q1 97)', which, in turn will lead you > > to xl24_20.pdf, a neat little circuit that hopefully will ease your worries > > :) > > > > Keep in mind that whatever you put in the clock path will affect the setup > > and hold time requirements for the particular component. > > > > Take care, > > > > Marten > > > > ] remove the obvious to repy by e-mail [Article: 60014
Hi, I have a vhdl project and I used a UCF file to assign the package pin to each port in the design. This works fine. However, if I change my vhdl code (let's say I remove an output port), I always get the following error when I try to run the UCF editor: ERROR:NgdBuild:756 - Line 3 in 'constraints.ucf': Could not find net(s) 'outputA' in the design. To suppress this error specify the correct net name or remove the constraint. It seems like the UCF doesn't update itself with the new design. I tried everything and I always have to start with a new UCF each time. The removed port doesn't exist in the Edit constraints (TEXT) because I didn't add any constraint to it. I really don't see how to do it. Thanks DavidArticle: 60015
I found a workaround. If I add a new UCF, it seems like the old one gets updated with the new design (with missing ports). I just add a new UCF, delete it right away, and work with the old one. David "David Lamb" <gretzteam_nospam@yahoo.com> wrote in message news:bj547c$6pr$1@home.itg.ti.com... > Hi, > I have a vhdl project and I used a UCF file to assign the package pin to > each port in the design. This works fine. However, if I change my vhdl code > (let's say I remove an output port), I always get the following error when I > try to run the UCF editor: > ERROR:NgdBuild:756 - Line 3 in 'constraints.ucf': Could not find net(s) > 'outputA' in the design. To suppress this error specify the correct net > name or remove the constraint. > > It seems like the UCF doesn't update itself with the new design. I tried > everything and I always have to start with a new UCF each time. The removed > port doesn't exist in the Edit constraints (TEXT) because I didn't add any > constraint to it. I really don't see how to do it. > Thanks > David > >Article: 60016
Hi Rick,
Good point, the unknown delay is bad enough. Thinking about it,
I can't think of a 'sensible' digital metastability reduction circuit
and scenario which would differentiate between a simple delay, and
(say) a runt pulse. (Perhaps if the second FF was clocking faster than
the 'sample' FF? Doesn't make much sense!)
OTOH, my concern is this. If the following FF also goes, or is
very likely to go, metastable if its D input is at a 'funny' level,
then the 'funny' level metastability is more likely to propogate than
a simple delay. This is because the simple delay has to hit a tiny
time window to propogate the metastability, whereas Philip's photo's
show the funny levels lasting a while.
thanks, Syms.
rickman <spamgoeshere4@yahoo.com> wrote in message news:<3F55987E.ACCD59BE@yahoo.com>...
> Symon wrote:
> >
> > Hi Austin,
> > Maybe I got the wrong end of the stick, but when Peter said:-
> > "I have never seen strange levels or oscillations ( well, 25 years ago
> > we had TTL oscillations). Metastability just affects the delay on the
> > Q output." I thought he meant that he'd only seen metastability where
> > the output from the FF was always either on or off, just that
> > sometimes the transition was delayed. Philip's pictures clearly show
> > 'strange levels'. This is important, I believe, when deciding what the
> > effects of metastable FFs are on following circuitry. I guess we'll
> > have to wait until he returns from his Portugese jaunt before we find
> > out what he meant!!
>
> I think the exact behavior is largely irrelevant since a simple delay is
> just as disasterous as anything else you would encounter. Since you
> don't know *when* the transition would happen, it could happen at the
> moment the next FF is latching the intermediate value. That is enough
> for the next FF and all following logic to behave badly as well.
>
> --
>
> Rick "rickman" Collins
>
> rick.collins@XYarius.com
> Ignore the reply address. To email me use the above address with the XY
> removed.
>
> Arius - A Signal Processing Solutions Company
> Specializing in DSP and FPGA design URL http://www.arius.com
> 4 King Ave 301-682-7772 Voice
> Frederick, MD 21701-3110 301-682-7666 FAX
Article: 60017David, It simply means the tool is not smart enough to figure out what you are doing, and since you have jumped off of a global clock resource, and passed through logic on regular interconnect, skew and delay are no longer being kept track of (it doesn't know where the clock comes from/goes to). So, yes I think you have to tell it what is what, but since I am not a software/synthesis guru, I can not tell you how to do that. Perhaps someone else can, Austin David Lamb wrote: > Hi, > I used your circuit to switch between the two clocks. However, when I > synthetise in Xilinx ISE 5.2, I get the following warning: > > (*) These 2 clock signal(s) are generated by combinatorial logic, > and XST is not able to identify which are the primary clock signals. > Please use the CLOCK_SIGNAL constraint to specify the clock signal(s) > generated by combinatorial logic. > > I don't really understand what it means. I guess I need to tell ISE that the > output of the circuit is a clock, but I don't know how... > > Thanks a lot > David > > "Peter Alfke" <peter@xilinx.com> wrote in message > news:3F4E7B2D.CFBD1D0D@xilinx.com... > > Click at > > http://www.xilinx.com/xcell/xl24/xl24_20.pdf > > > > This circuit allows totally asynchronous selection between two clock > sources. > > But remember: both clock must be wiggling (however slowly). You cannot > > use this circuit to enable/disable a clock, which is actually a far > > simpler problem. > > The BUFGMUX in Virtex is not quite this clever, it has a set-up time > > requirement on the S control input. :-( > > Glad that someone found this old tidbit useful... > > Peter Alfke > > ============================= > > Marten wrote: > > > > > > "David Lamb" <gretzteam_nospam@yahoo.com> wrote in message > > > news:bilfne$sel$1@home.itg.ti.com... > > > > Hi all, > > > > I have a vhdl component with a "clock_in" input. Depending on the mode > of > > > > operation, I want to switch between two different clock signals. I > will > > > > never switch on the fly though. Can I use a mux in front of the > clock_in > > > > input? I'm afraid it might glitch. > > > > Thanks > > > > David > > > > > > > > > > > > > > David, > > > > > > Do a query for 'clock sources' in the category 'XCELL Journals' on the > > > Xilinx web site. This will provide you with a link called 'XCELL 24 - > > > Trouble-Free Switching Between Clocks (Q1 97)', which, in turn will lead > you > > > to xl24_20.pdf, a neat little circuit that hopefully will ease your > worries > > > :) > > > > > > Keep in mind that whatever you put in the clock path will affect the > setup > > > and hold time requirements for the particular component. > > > > > > Take care, > > > > > > Marten > > > > > > ] remove the obvious to repy by e-mail [Article: 60018
Theron Hicks wrote: > Hello, > Is there a way that I can (within ISE 5) use a different editor? I want > the editor to be integrated into the ISE system but I want to use a > different editor. The feature that I most want is automatic formating of > indents, etc. ISE does a good job, but if I screw up when I put in a new > block of code I want to add auto-indent (like that available in Matlab). > Folks at Xilinx.... Take this as a hint. Why does it have to be "within ISE"? If you edit a file with an external editor and save it, ISE will see that it has changed and will get rid of all the green check marks to indicate the project has to be recompiled. -- My real email is akamail.com@dclark (or something like that).Article: 60019
Symon, A long time ago, I designed a timing system for telecom that used a rubidium clock. The reason why this is interesting will become apparent in a moment. One function of the system was to measure up to five external sync references (presumably from traffic bearing lines from other offices). The circuit to do this was basically a counter, that was sampled by a rubidium derived clock. All clocks were syntonous (same frequency, arbitray phase -- aka the SONET/SDH telepone network). As the phase wandered back and forth, the metastable regions would get exercised, and the measurement board would report that an input signal had arbitrarily "slipped" by some random number of bits (due to a metastable transistion of a bit in the counter/latch). This was so frustrating, because in real life, the inputs could slip due to failures, glitches in the network, etc. So how do you know a real bad slip, from a metastable one? In the hope (vain and useless) of reducing the occurence of the metastable sample, we had three levels of FFs to try to re-synchronize the sample count, along with an elaborate set of clock enables. We got it to the point where the false slip occurred about evey two months, in a typical network. Since real outages were far more common, it was not a big deal. In spite of this, we wrote software to identify a real slip, from a false slip. Basically, if five successive samples were not equal (as the phase can't change that fast) we threw out that set of measurements, and took another five. This dropped the occurence of a false slip to below the threshold that we could measure (but it could still happen and probably did - still does out there somewhere). So, metastability can sometimes be beaten into submission, but it never goes away.... The ultimate frustration is that one of these references gets used to track the rubidium (steer it in a phase lockeed loop), so a fake glitch can cause quite a hit, which then causes slips throughout the network as the rubidium runs off the the "wrong" frequency/phase. A real glitch can also cause the same behavior, so the locked loop is quite loosely coupled, and before each update, one checks absolutely everything to be sure that what you are trying to track is real.... I had heard there were some cases with equipment designed by others where the maintenance folks would just disconnect the inputs, as the bare rubidium ran so clean, that it was better to not track at all (fewer slips) than to bother with trying to track the references and falsely running off into the weeds due to metastability and poor reference checking. All of this became obsolete when GPS became available, as now precise time (frequency) was broadcast for free. Austin Symon wrote: > Hi Rick, > Good point, the unknown delay is bad enough. Thinking about it, > I can't think of a 'sensible' digital metastability reduction circuit > and scenario which would differentiate between a simple delay, and > (say) a runt pulse. (Perhaps if the second FF was clocking faster than > the 'sample' FF? Doesn't make much sense!) > OTOH, my concern is this. If the following FF also goes, or is > very likely to go, metastable if its D input is at a 'funny' level, > then the 'funny' level metastability is more likely to propogate than > a simple delay. This is because the simple delay has to hit a tiny > time window to propogate the metastability, whereas Philip's photo's > show the funny levels lasting a while. > thanks, Syms. > > rickman <spamgoeshere4@yahoo.com> wrote in message news:<3F55987E.ACCD59BE@yahoo.com>... > > Symon wrote: > > > > > > Hi Austin, > > > Maybe I got the wrong end of the stick, but when Peter said:- > > > "I have never seen strange levels or oscillations ( well, 25 years ago > > > we had TTL oscillations). Metastability just affects the delay on the > > > Q output." I thought he meant that he'd only seen metastability where > > > the output from the FF was always either on or off, just that > > > sometimes the transition was delayed. Philip's pictures clearly show > > > 'strange levels'. This is important, I believe, when deciding what the > > > effects of metastable FFs are on following circuitry. I guess we'll > > > have to wait until he returns from his Portugese jaunt before we find > > > out what he meant!! > > > > I think the exact behavior is largely irrelevant since a simple delay is > > just as disasterous as anything else you would encounter. Since you > > don't know *when* the transition would happen, it could happen at the > > moment the next FF is latching the intermediate value. That is enough > > for the next FF and all following logic to behave badly as well. > > > > -- > > > > Rick "rickman" Collins > > > > rick.collins@XYarius.com > > Ignore the reply address. To email me use the above address with the XY > > removed. > > > > Arius - A Signal Processing Solutions Company > > Specializing in DSP and FPGA design URL http://www.arius.com > > 4 King Ave 301-682-7772 Voice > > Frederick, MD 21701-3110 301-682-7666 FAXArticle: 60020
"David Lamb" <gretzteam_nospam@yahoo.com> wrote in message news:bj54ns$7nr$1@home.itg.ti.com... > I found a workaround. If I add a new UCF, it seems like the old one gets > updated with the new design (with missing ports). I just add a new UCF, > delete it right away, and work with the old one. > David > "David Lamb" <gretzteam_nospam@yahoo.com> wrote in message > news:bj547c$6pr$1@home.itg.ti.com... > > Hi, > > I have a vhdl project and I used a UCF file to assign the package pin to > > each port in the design. This works fine. However, if I change my vhdl > code > > (let's say I remove an output port), I always get the following error when > I > > try to run the UCF editor: > > ERROR:NgdBuild:756 - Line 3 in 'constraints.ucf': Could not find net(s) > > 'outputA' in the design. To suppress this error specify the correct > net > > name or remove the constraint. > > > > It seems like the UCF doesn't update itself with the new design. I tried > > everything and I always have to start with a new UCF each time. The > removed > > port doesn't exist in the Edit constraints (TEXT) because I didn't add any > > constraint to it. I really don't see how to do it. > > Thanks > > David > > > > > > I use Aldec for a front end to Xilinx. This UCF editor is a major problem for me always. The two don't communicate well with regards to the ucf, and any changes that it may have. You can get into an endless loop where one wants the other to fix it, but it can't because he wants him to fix it etc.. "You must run translate after modifying the ucf". So try and run translate and it says the ucf has an error because you added things etc. Very frustrating.Article: 60021
Luiz Carlos wrote: > > > Electron spin has all the same measurement issues that a FF has. If the > > state of the electron spin is changing as the measurement is made, then > > what state is it in? What will be the result of the measurement? > > > > Rick, the electron spin is +1/2 or -1/2, there is no in between state, > it changes instantaneously (in one fundamental clock tick, ~10^-43 > seconds). > > Luiz Carlos But the measurement is not instantaneous. So the transistion could occur during a measurement. Result... inconclusive measurement which is what metastability is all about. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 60022
"Nicholas C. Weaver" wrote: > > In article <3F559A3F.91184B1A@yahoo.com>, > rickman <spamgoeshere4@yahoo.com> wrote: > > > >There is no way to determine when a circuit is metastable or not. Async > >circuits are not magic, they just depend on predictable delays, just > >like any other circuit. The design is different because there is no > >common clock so each circuit can run with its own delay. Since the next > >circuit will take the output when it is ready, there is no problem with > >synchronization. > > Silly question: I don't see why an ANALOG flip-flop couldn't determine > that it is in the intermediate state at some fixed interval after the > clock, and then force the flop one way or another. Of course, it > might double-glitch in the meantime (flop goes up before logic forces > it down), but it would make a flop with a fixed-maximum metastabel > interval. > > Of course, it seems like such a massive headache to do. If you don't see the problem it is because you are not looking hard enough. The issue with metastability comes from trying to measure the state of a FF or other digital voltage. When a signal is at an intermediate value a measurement can be inconclusive. Your ANALOG FF can be just as inconclusive as the digital FF. Besides, the result is always digital (or more accurately, discreet instead of continuous). You are suggesting that you add a third state to the measurement, but you get the same inconclusive measurement between the metastable state and either the one or the zero states. The result is that the output of your ANALOG FF would be indeterminate which could result in metastability in the next stage. If I am not grasping your idea, then please provide more details. > >One problem I do see is that if each stage has a different delay, then > >it can not accept a new input from the preceding stage until the output > >has been taken by the following stage. It seems in the end the async > >circuit will run no faster than the slowest stage, which is what the > >sync clocked circuit will do. > > The trick with asynchronous logic is that the longest stage WHICH IS > IN THE COMPUTATION is the critical path. EG, if 9 of the stages take > 1 ns, and the last takes 2ns, but the last only affects 1/2 the data, > with the asynchronous circuitry doing the shortcutting, it will be > considerably faster than the synchronous one. Except that sync designs can do the same thing. A multiply accumulate typically takes twice as long as the other ops in a calculation. So they split it into two stages running at full speed. Or if only half the data needs the MAC, then they can do nothing since this will run at full speed. > The problem is: You can automatically balance the pipelining > (retiming) for a synchronous circuit, while asynchronous really playes > havoc with the CAD flow and testing. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 60023
Austin Lesea wrote: > > Rick, > > I agree that the effect is the same: you just don't know when it will > resolve, and thus the value that you "see" at the next level is basically > unknown. > > It could be that Peter's point is that the next circuit in line does make a > decision, and it most certainly makes the "unknown" into a '1', or into a > '0'. It is unlikely that the next circuit in line will propagate the same > intermediate behavior, and if it can (gain is too low), then things just get > more fuzzy until someone upstream ends up resolving the level back to a '1' > or a '0'. If that were the case, then metastability would not be an issue at all. Having an indeterminate voltage is what creates metastability. The signal does not need to remain in the indeterminate value for any length of time, so a transistion at the wrong time is as bad as any other indeterminte value. When FFs see an indeterminate input at the sampling time (very small time and voltage window), they will create an indeterminate value for an arbitrary period (or at an abritray delay) on the output. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 60024
In article <3F56292C.E9F89B7F@yahoo.com>, rickman <spamgoeshere4@yahoo.com> wrote: >"Nicholas C. Weaver" wrote: >If you don't see the problem it is because you are not looking hard >enough. The issue with metastability comes from trying to measure the >state of a FF or other digital voltage. When a signal is at an >intermediate value a measurement can be inconclusive. Your ANALOG FF >can be just as inconclusive as the digital FF. Besides, the result is >always digital (or more accurately, discreet instead of continuous). > >You are suggesting that you add a third state to the measurement, but >you get the same inconclusive measurement between the metastable state >and either the one or the zero states. The result is that the output of >your ANALOG FF would be indeterminate which could result in >metastability in the next stage. > >If I am not grasping your idea, then please provide more details. The flip flop core exists in one of THREE states: Vdd, Vss (the stable points) and Vms +/- epsilon (the metastable range, in between Vdd and Vss). The analog circuitry in the flip flop measures the flip-flop state at Tdelay after the clock edge. If it is within Vms +/- a large epsilon (that is, metastable at this point in time), the analog circuitry forces the flip-flop to Vss, and also signals that a metastable capture/correction was performed. This may cause a spurrious transition (eg, the metastable state is measured, it goes high, and then the post-measurement kick drags it back down to Vss). >> The trick with asynchronous logic is that the longest stage WHICH IS >> IN THE COMPUTATION is the critical path. EG, if 9 of the stages take >> 1 ns, and the last takes 2ns, but the last only affects 1/2 the data, >> with the asynchronous circuitry doing the shortcutting, it will be >> considerably faster than the synchronous one. > >Except that sync designs can do the same thing. A multiply accumulate >typically takes twice as long as the other ops in a calculation. So >they split it into two stages running at full speed. Or if only half >the data needs the MAC, then they can do nothing since this will run at >full speed. The promise of the asynchronous is that this can occur on a much finer grain, eg if all the ops are 1 ns, but the final one is either 1 or 1.5 ns. Of couse, it has never really lived up to this promise, mostly because the handshaking overhead can be severe, as well as the other problems (CAD, testing). -- Nicholas C. Weaver nweaver@cs.berkeley.edu
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