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
What's the best way to use existing macros in a new design? Has anyone had trouble attaching a library to a new project? Has anyone had any trouble using windows explorer to copy the necessary file? Has anyone had any trouble using library manager to "copy" the macros from one library to another?. Thanks so much -Sue Sent via Deja.com http://www.deja.com/ Before you buy.Article: 26601
Marc Reinert wrote: > > Thank You, really good example circuit. I'll see if it'll help me to > devise good ideas. > > Furthermore I hope it was not a to big strain for You. > > Marc Most people aren't this rude. The ADC's datasheet will have sample circuits. Just make sure to double-check the electrical connections to the ADC. I've destroyed several ADCs because I sent 9V instead of 5V... > Newsbrowser schrieb: > > > What is this a Homework assignment ? > > > > If you can't look at the datasheet and assorted app notes and figure > > it out for yourself. You deserve to fail > > > > Return Email Address is: > > ralphwat dot home at excite dot comArticle: 26602
Rob Finch wrote: > > I have a signal 'reset' in my design used to reset the state of various > registers and counters. Is there a way of generating a reset signal > internally ? I looked at using the STARTUP symbol and it looks to me like I > could use Q4, but how do I configure this (Q4 vs Q1) there doesn't seem to > be any option. > Alternately is there a way I can specify initial register settings ? I am > using student edition F1.5 software. Are you doing this in VHDL? Then instantiate a primitive called ROC with a single output pin "O". Connect the output pin to your resets. ROC is a primitive in the Xilinx VHDL libraries (for example, look in the file unisim_VITAL.vhd), which emulates the global set/reset that is built into the Xilinx parts. ROC generates a '1' for 100nS and then goes to '0', just like the real hardware does, though the time parameter uses a generic. ROC will be removed from the design during synthesis, because the synthesis tools know this is dedicated hardware in the chip. See "Defining Global Signals in VHDL" in chapter 5 of the "Synthesis and Simulation Design Guide". There is also a Verilog section if that is what you are using. The outputs from STARTUP are not intended to be used for connecting to resets in your circuitry. STARTUP is used to control the global set/reset from an external pin, if the default power on reset is not good enough and you want external control of the signal. The outputs of STARTUP are status outputs. If you are doing a schematic, then all the registers already have an initial setting, which is '0' for the FDCE related parts and '1' for the FDPE related parts. -- My real email is akamail.com@dclark (or something like that).Article: 26603
"Austin Franklin" <austin@darkroo99.com> wrote in message news:01c03a2b$fe9869a0$e602f7a5@drt1... > > Now, do you REALLY think someone would be qualified to do this job if you > had to explain this to them...especially like this? > LOL! Despite the muddled-up description of the job, it sounds like they are looking for people to design an ASIC which will embed a Power PC core and some programmable logic, targetted to the telecommunications market. All done in VHDL, so this is most likely a European company. Nothing too ground-breaking here, but interesting nonetheless. Alcatel? Siemens? Any other guesses?Article: 26604
Xilinx will soon release a new version of WebPack ISE which will include support for the Spartan-II family (HDL only) as well as all CPLDs (schematic & HDL) - free download from www.xilinx.com Mark. Russ.Shaw <russell@webaxs.net> wrote in message news:39F19F96.1AB2E11C@webaxs.net... > Hi all, > > Is there any entry level tools for fpgas > such as atmel at40k05? > > The free IDS6 tool from atmel is a bit > too crappy. I don't mind buying a tool, > but the budget isn't open ended... > > -- > ******************************************* > * Russell Shaw, B.Eng, M.Eng(Research) * > * email: russell@webaxs.net * > * Victoria, Australia * > *******************************************Article: 26606
What do you think about these two new components? Anybody tried to use them? What about their development systems? -- l'landre e-mail : andmars@tin.it web : http://www.dei.unipd.it/~patchArticle: 26607
Hi, could someone explain me what BACK ANNOTATION stands for ? not just in flooplanning, but i have passed quiete often across this keyword especially in vhdl references( as well as testbench ); unfortunately i have never understood it regards In article <39F1A754.4593DF07@andraka.com>, Ray Andraka <ray@andraka.com> wrote: > THat's about all there is. In the timing report, make note of the CLB locations > in the critical path. Armed with those, go into the floorplanner and zoom in on > the first CLB in the path, and select the element (S0 is the right half, s1 is > the left half of the CLB, F/X is on the bottom of the slice G/Y is the top > half. THe loaction down to the BEL is displayed in the lower right side of the > display. Once you select the first location, then zoom back out and you can > select the second. That one will be easier to find, as it is one of the ones > with a ratsnest going to it. > > Tell Xilinx that you'd like to see the timing paths get back annotated to the > floorplanner. (use the on-line tech support or hotline to submit a query as to > how to do it). The more people they see using part of a tool or requesting a > feature, the higher they move it on the to-do list. Floorplanner has > historically taken a bottom position on their priority list because they seem to > think the only ones who use it are for the "%5 designs from hell". > > Muzaffer Kal wrote: > > > > hi everyone, > > Today I spent a couple of hours looking at placement of > > micro-controller occupying almost 50% of a virtex 800. One thing I > > couldn't figure out how to do is to annotate a critical path from the > > timing analyzer onto the floorplan. I looked at the online help and > > the online description I could find was to open a timing file and add > > individual nets by using the Find command in the floorplan tool. Is > > this really the only way ? I was expecting a much more automated way > > to do this. Basically selecting a number of paths in the timing > > analyzer would just select all the nets involved in the placement by > > unique colors. > > Another problem is that some of the nets in the path have multiple > > destinations, i.e. one register output seems to go to 3 different FGs > > but only one of these paths is on the critical path so after > > ctrl-selecting a couple of lines in the critical path, you are really > > not sure what is the critical path anymore. Is there way to get around > > this ? > > I think Altera's way of linking critical paths to placement is much > > nicer. > > > > Muzaffer > > > > http://www.dspia.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 or http://www.fpga-guru.com > Sent via Deja.com http://www.deja.com/ Before you buy.Article: 26608
> What do you think about these two new components? > Anybody tried to use them? > What about their development systems? My company has been working with the Triscend TE5 CSoC for the past year. The chip combines a fast 8032 microcontroller core with an array of configurable logic. Their FastChip development software is easy to use and the chips perform as advertized. We sell the myCSoC development kit that includes a full version of the FastChip software and a development board for $169.95. You can see it at http://www.xess.com/prod022.html. If you want more details on the chip and software, we have a complete tutorial on using the TE5 CSoC at http://www.xess.com/myCSoC-CDROM.html. The Atmel FPSLIC has been long-announced but has only just begun to appear. I've never seen or used one. Some other responders to this newsgroup are on the Atmel bandwagon, so I'll let them describe this chip and the development environment. -- || Dr. Dave Van den Bout XESS Corp. (919) 387-0076 || || devb@xess.com 2608 Sweetgum Dr. (800) 549-9377 || || http://www.xess.com Apex, NC 27502 USA FAX:(919) 387-1302 ||Article: 26609
seriousmonkey.com is set to revolutionise the global automotive industry with a wide range of genuinely groundbreaking and innovative Internet services benefiting business and consumers alike. In order to support the hyper-growth expansion of our global operations, seriousmonkey.com will shortly be looking for a number of high-calibre, professional candidates to join our fast-paced and dedicated teams in London and the Republic of Ireland. To visit seriousmonkey.com or view our online job vacancies, go to http://www.seriousmonkey.com Frank Pottle Managing Director seriousmonkey.com Article posted 23/10/2000 13:19:50.430Article: 26610
Do you have any XC4000, XC4000XL chips lying around? Why not make use of them? It's easy with a kit from Burch Electronic Designs. Announcing a new low cost kit: BED-XILINX-4000+ Price: Less than US$45.00 ! Pictures and specs at: http://www.burched.com.au/bedxilinx4000.html The BED-4000+ kit includes all the hardware you need - just supply your own FPGA. Suggestions: Make yourself a custom piece of lab equipment (eg. pulse generator or digital logic trigger), a parallel port controller, try out your digital logic design idea, or just experiment with FPGAs. This board supports all 4000 Series and Spartan devices in PC84 (84 pin PLCC) packages, including 5V and 3.3V devices. This includes: XCS05-PC84 (Spartan) XCS10-PC84 (Spartan) XCS05XL-PC84 (Spartan-XL) XCS10XL-PC84 (Spartan-XL) XC4003E-PC84 (4000E) XC4005E-PC84 (4000E) XC4006E-PC84 (4000E) XC4008E-PC84 (4000E) XC4010E-PC84 (4000E) XC4002XL-PC84 (4000XL) XC4005XL-PC84 (4000XL) XC4010XL-PC84 (4000XL) International orders are very welcome. Secure online shop available. Best regards Tony Burch www.BurchED.com.auArticle: 26611
Magnus Homann wrote: > > yuryws@my-deja.com writes: > > > Registering the inputs in IOB Flops will only take care of one set of > > those flops (Rising or Falling edge only), which I happen to do anyway, > > except I do use the externally fed CLK to do that. > > > > The other set of FFs is that from CLBs. The reason for all of these > > problems is that data is only valid for 6ns before and 6ns after each > > clock edge. > > > > I suppose Double data rate SDRAMs operate in a similar manner. This > > design is for a uDMA controller. I don't think you understood Andy's suggestion. He is saying that you need to use a DLL or other clocking scheme to generate a clock that is twice the frequency of your data clock. This will give you a rising edge for each data phase. Then you only need one set of FFs to clock the data into the device. Once you have the data in the IOB FFs, you need to decide if you will continue to run at the 2x rate or if you will double the width of the data path and resync to the 1x clock rate. > > I do just what you described as far as FF-FF constraints are concerned > > instead of PERIOD constraint. In addition my internal clock running at > > 2.5 times the shortest side of the externally fed clock is used fo > > detecting the edges and doing some clever stuff with it. For an offset constraint to work, you need to have a period constraint. But if you force the input FFs into the IOBs, you don't need offset constraints. The FF-FF constraints are ok, but you have to use them on *every* set of FFs in your design. Often a period constraint is just easier to use. > > The problem is that I can not tolerate the absolulte difference in > > propagation time between clock_PAD -> FF and data_PAD -> FF of more > > then 6 ns, in addition the propagation time on clock or data path to FF > > can not exceed 25 ns. Using a DLL will fix your timing problems. Opps, I see that you are using (or planning to use) a SpartanXL, no DLL. You can use the two sets of FFs as you mentioned, but you will need to specify only one of the offset constraints. They way they are used, you only need to specify the setup time, not the hold. So you should use the OFFSET IN BEFORE constraint and the tool should work properly on both clock edges. Remember, the tool does not care about clock edges. It only looks at static path delay calculations. The only time it considers the clock edge is when you feed on FF from another clocked from opposite edges. > > From what I see the Xilinx PAR tools do not have enough controls to > > allow for specifying such a situation. What I have been doing so far is > > constrain the prop time (clock -> FF) and (data -> FF) to 6 ns, which > > does work, but the tools have a very difficult time meeting the > > constratint. > > I have also tried to specify min and max Tco and Tsetup with both > Xilinx and Altera. The tools can't handle this, and I think this will > become more and more of a problem. It would also be nice to be able to > cnostraint Toskew for a set of outputs. > > The tools are not good enough for this, atr leats they weren't six > months ago. I don't see the need to specify these timing values. Specifying one or the other will give you the timing that the tool needs to do the routing. You need to look at what the tool is doing. It only needs one number to tell it how fast it has to route the traces. It gets this number from the offset combined with the period. The calculations of clock routing vs. data routing are done automaticially. -- 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 Arius 4 King Ave Frederick, MD 21701-3110 301-682-7772 Voice 301-682-7666 FAX Internet URL http://www.arius.comArticle: 26612
rickman <spamgoeshere4@yahoo.com> writes: > Magnus Homann wrote: > > > > yuryws@my-deja.com writes: > > > > > Registering the inputs in IOB Flops will only take care of one set of > > > those flops (Rising or Falling edge only), which I happen to do anyway, > > > except I do use the externally fed CLK to do that. > > > > > > The other set of FFs is that from CLBs. The reason for all of these > > > problems is that data is only valid for 6ns before and 6ns after each > > > clock edge. > > > > > > I suppose Double data rate SDRAMs operate in a similar manner. This > > > design is for a uDMA controller. > > I don't think you understood Andy's suggestion. He is saying that you > need to use a DLL or other clocking scheme to generate a clock that is > twice the frequency of your data clock. This will give you a rising edge > for each data phase. Then you only need one set of FFs to clock the data > into the device. Once you have the data in the IOB FFs, you need to > decide if you will continue to run at the 2x rate or if you will double > the width of the data path and resync to the 1x clock rate. Could be a solution, but might not always be the best. In this case, the period of the main clock is 50 ns. Say that you have a 45%/55% tolerance of the clock symmetry, the fallinge edge can vary from 22.5ns to 27.5 ns after the risinge edge. If you sue a DLL following the rising edge, you first have the skew of the DLL (.5 ns?), and then another 2.5 ns. Your setup and hold of 6ns have been halved. > > > I do just what you described as far as FF-FF constraints are concerned > > > instead of PERIOD constraint. In addition my internal clock running at > > > 2.5 times the shortest side of the externally fed clock is used fo > > > detecting the edges and doing some clever stuff with it. > > For an offset constraint to work, you need to have a period constraint. > But if you force the input FFs into the IOBs, you don't need offset > constraints. How can you else constrain the setup and hold, relative to the clock pin? I'm a bit rusty on UCF, but I seem to remember you used OFFSET for that. > The FF-FF constraints are ok, but you have to use them on *every* set of > FFs in your design. Often a period constraint is just easier to use. > > > > The problem is that I can not tolerate the absolulte difference in > > > propagation time between clock_PAD -> FF and data_PAD -> FF of more > > > then 6 ns, in addition the propagation time on clock or data path to FF > > > can not exceed 25 ns. > > Using a DLL will fix your timing problems. I'm not so sure about that. > Opps, I see that you are > using (or planning to use) a SpartanXL, no DLL. You can use the two sets > of FFs as you mentioned, but you will need to specify only one of the > offset constraints. They way they are used, you only need to specify the > setup time, not the hold. So you should use the OFFSET IN BEFORE > constraint and the tool should work properly on both clock edges. Don't need to specify hold constraint? What kind of hold time do you get then, if you use a non-global clock? > > > From what I see the Xilinx PAR tools do not have enough controls to > > > allow for specifying such a situation. What I have been doing so far is > > > constrain the prop time (clock -> FF) and (data -> FF) to 6 ns, which > > > does work, but the tools have a very difficult time meeting the > > > constratint. > > > > I have also tried to specify min and max Tco and Tsetup with both > > Xilinx and Altera. The tools can't handle this, and I think this will > > become more and more of a problem. It would also be nice to be able to > > cnostraint Toskew for a set of outputs. > > > > The tools are not good enough for this, atr leats they weren't six > > months ago. > > I don't see the need to specify these timing values. Specifying one or > the other will give you the timing that the tool needs to do the > routing. How can the tool know that, the input signal is available 2 ns before and 1.5ns after the clock edge (at the pad) (my example)? How would you constrain that? How can the tool know that I want the data to be available on the output 5 sn after the clock edge, but also be stable 2 sn after the (next) clock edge. I want a window such that the external device can have 3ns setup and 2 ns hold. That's a 5ns window on a 8ns period. Yes, you could do that by constraining Tco to 3 ns, and delay the datapath outside the device with 30cm or so, or shortne the clock, if that's possible. > You need to look at what the tool is doing. It only needs one > number to tell it how fast it has to route the traces. It gets this > number from the offset combined with the period. The calculations of > clock routing vs. data routing are done automaticially. The problem is that the tool tries to root as fast as possible, where it sometimes could fit the design much more easily by delaying another signal (e.g. the clock). When inertafcing to the outside world, min delay and skew are almost as important as max delay, both on inputs and outputs. Homann -- Magnus Homann, M.Sc. CS & E d0asta@dtek.chalmers.seArticle: 26613
Magnus Homann wrote: > > rickman <spamgoeshere4@yahoo.com> writes: > > I don't think you understood Andy's suggestion. He is saying that you > > need to use a DLL or other clocking scheme to generate a clock that is > > twice the frequency of your data clock. This will give you a rising edge > > for each data phase. Then you only need one set of FFs to clock the data > > into the device. Once you have the data in the IOB FFs, you need to > > decide if you will continue to run at the 2x rate or if you will double > > the width of the data path and resync to the 1x clock rate. > > Could be a solution, but might not always be the best. > > In this case, the period of the main clock is 50 ns. Say that you have > a 45%/55% tolerance of the clock symmetry, the fallinge edge can vary > from 22.5ns to 27.5 ns after the risinge edge. If you sue a DLL > following the rising edge, you first have the skew of the DLL (.5 > ns?), and then another 2.5 ns. Your setup and hold of 6ns have been halved. Maybe you did understand his post. Actually you are right. I have never done a dual clock edge design. I had not considered the clock symmetry issue. I guess you would have to use the two registers and combine, or not, the two data streams internally. > > For an offset constraint to work, you need to have a period constraint. > > But if you force the input FFs into the IOBs, you don't need offset > > constraints. > > How can you else constrain the setup and hold, relative to the clock > pin? I'm a bit rusty on UCF, but I seem to remember you used OFFSET for > that. You can constrain the setup time. But you can not constrain the hold time. To meet a hold time requirement, you have to control the *minimum* delay through a path. There is no provision in the timing software to deal with minimum times, IIRC. The way the chip works, the dedicated clock paths are very fast and very evenly distributed. So you get little skew and normally faster routes than the data. So the signal paths always (at least all the ones I have seen) degrade the setup time and not the hold time. The hold times on the CLB FFs are all 0 nS. So if you have a good placement (which I expect is nearly essential for this design) you should have no trouble getting a decent route which will meet your 6 nS setup time. The hold time should be a mox nix. But if you want to check it, you should manually check in the timing analyzer. The reason that hold times are not spec'd in timing constraints is that one of the main concepts in synchronous design is that only maximum delays need to be considered. So all issues with minimum delays are dealt with by design procedures rather than tests. This makes things much, much easier for the manufacturers since minimum times are hard to control and will preclude them shipping faster chips in slower speed grades. So they avoid spec'ing minimum delay times like the plague. For clock routing, they control the route delays much more than other route delays, so you can be assured that you have a workable design. > > The FF-FF constraints are ok, but you have to use them on *every* set of > > FFs in your design. Often a period constraint is just easier to use. > > > > > > The problem is that I can not tolerate the absolulte difference in > > > > propagation time between clock_PAD -> FF and data_PAD -> FF of more > > > > then 6 ns, in addition the propagation time on clock or data path to FF > > > > can not exceed 25 ns. > > > > Using a DLL will fix your timing problems. > > I'm not so sure about that. Yes, you are right in the case of a double data rate interface. You can't control the timing of the falling edge well enough. But in any event, you should have much less than 6 nS of clock delay and you will almost certainly have more data delay than clock anyway. > > Opps, I see that you are > > using (or planning to use) a SpartanXL, no DLL. You can use the two sets > > of FFs as you mentioned, but you will need to specify only one of the > > offset constraints. They way they are used, you only need to specify the > > setup time, not the hold. So you should use the OFFSET IN BEFORE > > constraint and the tool should work properly on both clock edges. > > Don't need to specify hold constraint? What kind of hold time do you > get then, if you use a non-global clock? Don't use a non-global clock. You have bigger problems if you clock any other circuitry like control logic which has more than 1 FF. The setup and hold times become impossible to calculate. Remember, the hold time comes from a minimum delay and this is not spec'd. > > I don't see the need to specify these timing values. Specifying one or > > the other will give you the timing that the tool needs to do the > > routing. > > How can the tool know that, the input signal is available 2 ns before > and 1.5ns after the clock edge (at the pad) (my example)? How would > you constrain that? > > How can the tool know that I want the data to be available on the > output 5 sn after the clock edge, but also be stable 2 sn after the > (next) clock edge. I want a window such that the external device can > have 3ns setup and 2 ns hold. That's a 5ns window on a 8ns period. > > Yes, you could do that by constraining Tco to 3 ns, and delay the > datapath outside the device with 30cm or so, or shortne the clock, if > that's possible. Xilinx does have an appnote for calculating minimum delays from the max delays. I don't remember the details, but I think it boiled down to Tmin = 0.25 Tmax. So you can get a minimum from the max if you absolutely have to. If you are double clocking your outputs, you will be going through logic after the FFs. This will present some very difficult to handle timing issues, because of the lack of good minimum delay information. If you are not double clocking your outputs, you can output your data on the opposite edge of the clock. This will then reduce your maximum Tco to (0.5Tperiod - Tsu) and the hold time will be (0.5Tperiod + Tco). As long as the half period is more than your required hold time, you only need to control the Tco max. Trying to get the data stable in an arbitray 5 nS window for an 8 nS clock period is likely not to be possible on an FPGA. I think there may be too much variation in timing. Yes, you could do the 3 nS clock to output delay constraint, but I don't think you can achieve this in a SpartanXL. Also keep in mind that each part of this has some variation, including the data trace delay. As you say, it requires "30cm or so". The "or so" part will cause some variability in delay. > > You need to look at what the tool is doing. It only needs one > > number to tell it how fast it has to route the traces. It gets this > > number from the offset combined with the period. The calculations of > > clock routing vs. data routing are done automaticially. > > The problem is that the tool tries to root as fast as possible, where > it sometimes could fit the design much more easily by delaying another > signal (e.g. the clock). > > When inertafcing to the outside world, min delay and skew are almost > as important as max delay, both on inputs and outputs. Yes, but no chip manufacturer wants to have to design in and test this sort of delay. Output hold times are very commonly spec'd at 0 nS on many chips, or at best 1.0 nS. I had to deal with a very similar design with a 4000XL with external ECL interface logic. I had to do a very complicated timing analysis and use different edges of the clock to get the design to work. It was a real PITA. I could have solved the problem very easily if I could have used an all in one ECL translator chip. But that chip was on a very long lead time and I had to use 6 different chips for input and output. Dealing with all the mins and maxs and the FPGA almost did not work. -- 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 Arius 4 King Ave Frederick, MD 21701-3110 301-682-7772 Voice 301-682-7666 FAX Internet URL http://www.arius.comArticle: 26614
Actually ROC is black-boxed by the synthesis tools and put in the edif netlist. The Place and route tools ignore it, effectively dropping it from the netlist. One caution is that you can end up with a little extra logic in certain cases (ie if you are using the sync reset) because the synthesizer winds up using FDCE's to connect the ROC. A way around it is to put synthesis translate on/off pragmas around the ROC and put an assignment of '0' in the global reset declaration. That way ROC is there fore your simulation but nor included in the synthesized netlist, so it does not hinder the synthesis of FDRE's. For instantiated primitives, the unisim library has built in initial values defaulted to the normal value for that flip-flop (FF's wiht set inputs are initialized to '1', others to '0'). The default can be changed using the INIT= generic for simulation. You'll have to put an INIT= attribute on it to carry the change to the netlist. Duane wrote: > > Rob Finch wrote: > > > > I have a signal 'reset' in my design used to reset the state of various > > registers and counters. Is there a way of generating a reset signal > > internally ? I looked at using the STARTUP symbol and it looks to me like I > > could use Q4, but how do I configure this (Q4 vs Q1) there doesn't seem to > > be any option. > > Alternately is there a way I can specify initial register settings ? I am > > using student edition F1.5 software. > > Are you doing this in VHDL? Then instantiate a primitive called ROC with > a single output pin "O". Connect the output pin to your resets. ROC is a > primitive in the Xilinx VHDL libraries (for example, look in the file > unisim_VITAL.vhd), which emulates the global set/reset that is built > into the Xilinx parts. ROC generates a '1' for 100nS and then goes to > '0', just like the real hardware does, though the time parameter uses a > generic. ROC will be removed from the design during synthesis, because > the synthesis tools know this is dedicated hardware in the chip. See > "Defining Global Signals in VHDL" in chapter 5 of the "Synthesis and > Simulation Design Guide". There is also a Verilog section if that is > what you are using. > > The outputs from STARTUP are not intended to be used for connecting to > resets in your circuitry. STARTUP is used to control the global > set/reset from an external pin, if the default power on reset is not > good enough and you want external control of the signal. The outputs of > STARTUP are status outputs. > > If you are doing a schematic, then all the registers already have an > initial setting, which is '0' for the FDCE related parts and '1' for the > FDPE related parts. > > -- > My real email is akamail.com@dclark (or something like that). -- -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 or http://www.fpga-guru.comArticle: 26615
Back annotation is sending data (generally timing data) backwards through the tools flow to get improved performance based on the actual place and route solution. It is usually used in the context of timing simulations, in which case the placed and routed timing results are passed back to the simulator to get accurate timing numbers in the simulation (note these are generally just worst case maximimum delays, so be careful using them). erika_uk@my-deja.com wrote: > > Hi, > > could someone explain me what BACK ANNOTATION stands for ? > > not just in flooplanning, but i have passed quiete often across this > keyword especially in vhdl references( as well as testbench ); > unfortunately i have never understood it > > regards > > In article <39F1A754.4593DF07@andraka.com>, > Ray Andraka <ray@andraka.com> wrote: > > THat's about all there is. In the timing report, make note of the > CLB locations > > in the critical path. Armed with those, go into the floorplanner and > zoom in on > > the first CLB in the path, and select the element (S0 is the right > half, s1 is > > the left half of the CLB, F/X is on the bottom of the slice G/Y is > the top > > half. THe loaction down to the BEL is displayed in the lower right > side of the > > display. Once you select the first location, then zoom back out and > you can > > select the second. That one will be easier to find, as it is one of > the ones > > with a ratsnest going to it. > > > > Tell Xilinx that you'd like to see the timing paths get back > annotated to the > > floorplanner. (use the on-line tech support or hotline to submit a > query as to > > how to do it). The more people they see using part of a tool or > requesting a > > feature, the higher they move it on the to-do list. Floorplanner has > > historically taken a bottom position on their priority list because > they seem to > > think the only ones who use it are for the "%5 designs from hell". > > > > Muzaffer Kal wrote: > > > > > > hi everyone, > > > Today I spent a couple of hours looking at placement of > > > micro-controller occupying almost 50% of a virtex 800. One thing I > > > couldn't figure out how to do is to annotate a critical path from > the > > > timing analyzer onto the floorplan. I looked at the online help and > > > the online description I could find was to open a timing file and > add > > > individual nets by using the Find command in the floorplan tool. Is > > > this really the only way ? I was expecting a much more automated way > > > to do this. Basically selecting a number of paths in the timing > > > analyzer would just select all the nets involved in the placement by > > > unique colors. > > > Another problem is that some of the nets in the path have multiple > > > destinations, i.e. one register output seems to go to 3 different > FGs > > > but only one of these paths is on the critical path so after > > > ctrl-selecting a couple of lines in the critical path, you are > really > > > not sure what is the critical path anymore. Is there way to get > around > > > this ? > > > I think Altera's way of linking critical paths to placement is much > > > nicer. > > > > > > Muzaffer > > > > > > http://www.dspia.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 or http://www.fpga-guru.com > > > > Sent via Deja.com http://www.deja.com/ > Before you buy. -- -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 or http://www.fpga-guru.comArticle: 26616
rickman <spamgoeshere4@yahoo.com> writes:
> Magnus Homann wrote:
> >
> > rickman <spamgoeshere4@yahoo.com> writes:
> > > I don't think you understood Andy's suggestion. He is saying that you
> > > need to use a DLL or other clocking scheme to generate a clock that is
> > > twice the frequency of your data clock. This will give you a rising edge
> > > for each data phase. Then you only need one set of FFs to clock the data
> > > into the device. Once you have the data in the IOB FFs, you need to
> > > decide if you will continue to run at the 2x rate or if you will double
> > > the width of the data path and resync to the 1x clock rate.
> >
> > Could be a solution, but might not always be the best.
> >
> > In this case, the period of the main clock is 50 ns. Say that you have
> > a 45%/55% tolerance of the clock symmetry, the fallinge edge can vary
> > from 22.5ns to 27.5 ns after the risinge edge. If you sue a DLL
> > following the rising edge, you first have the skew of the DLL (.5
> > ns?), and then another 2.5 ns. Your setup and hold of 6ns have been halved.
>
> Maybe you did understand his post. Actually you are right. I have never
> done a dual clock edge design. I had not considered the clock symmetry
> issue. I guess you would have to use the two registers and combine, or
> not, the two data streams internally.
I have to admit that it might not be very common to do this kind of
design. Unless you are into gigabit ethernet! Transmit path, on the
most common devices, is 10 bit @ 125MHz, and receive path is 10 bit
clocked with two 62.5 MHz clocks at 180 degrees (positive edge). So
you have one transmit and two receive clocks. The delay between
positive edges of the different receive clocks is 7.5 to 8.5 ns. Data
valid (on receive) is 3 ns before and 2 ns after [1], and in an
FPGA you'd preferrably take the PAD to two different FFs, perhaps one in
the IOB.
Now, I had to [2] fit four(4) of those interfaces in one FPGA, so it
makes 2*4 =8 receive clocks, but I used the same transmit clock, so
"only" 9 pretty fast clocks were needed. The FPGA I used had four
global clocks, and four "fast" inputs, ergo I had to use one
non-decicated input.
The receive paths were converted to 20 bits internally, and using one
of the receive clocks to clock it, so only 10 FFs were clocked with
that non-global clock. Being a non-global clock, the tool didn't want
to guarantee a zero hold time (on data), and I couldn't give any
cnostraint to either make the tool place cleverly OR even check the
result. I had to hand place the non-global clock and the inputs, and I
tried both horizontal and vertical IOB. If I remember correctly, I
actually managed to fit the receive path for all four domains,but it
took a week or so.
The S2060 requires a .25 ns hold time on the transmit data, but only
1.2 ns setup, so it was no problem to achieve that with the global
clock. I made provisions to use the xLL, so I could fix the hold
times.
The reason I tell you (all) this is that I do feel designs like this
will be more common, where multiple clocks and source-synchronous data
paths are run in the 200+ MHz range. >If you are doing these kinds of
design, I believe that minimum (and skew[3]) timing is just as
important as maximum timing. The "simplified" approach migt not work as
well anymore.
Thanks you for listening to my rant!
[1] AMCC S2060
[2] Nobody forced me, but it was an interesting challenge.
[3] Consider where you have 8 bits and a clock going out of your
FPGA and 1 meter across the backplane. The signals are all of the same
length, and you run say 200 Mbaud. Skew at ouput is important, but
actual delay is not.
Homann
--
Magnus Homann, M.Sc. CS & E
d0asta@dtek.chalmers.se
Article: 26617Magnus Homann wrote: > I have to admit that it might not be very common to do this kind of > design. Unless you are into gigabit ethernet! Transmit path, on the > most common devices, is 10 bit @ 125MHz, and receive path is 10 bit > clocked with two 62.5 MHz clocks at 180 degrees (positive edge). So > you have one transmit and two receive clocks. The delay between > positive edges of the different receive clocks is 7.5 to 8.5 ns. Data > valid (on receive) is 3 ns before and 2 ns after [1], and in an > FPGA you'd preferrably take the PAD to two different FFs, perhaps one in > the IOB. To make sure I understand what you are saying, there are four data inputs with dual clocks of opposite phases. So you have four clocks at a similar phase and there are four clocks that are 180 degrees out, essentially inverted. You are saying that the clocks vary from 7.5 to 8.5 nS from pos edge of "non-inverted" clock to pos edge of "inverted" clock. If the skew is only 1 nS total (+- 0.5 nS) and you have 2 nS hold time, why can't you use one clock for both data phases of a given input? This would reduce your setup and hold to 2.5 nS and 1.5 nS, respectively. I believe this will work in a fast FPGA. > Now, I had to [2] fit four(4) of those interfaces in one FPGA, so it > makes 2*4 =8 receive clocks, but I used the same transmit clock, so > "only" 9 pretty fast clocks were needed. The FPGA I used had four > global clocks, and four "fast" inputs, ergo I had to use one > non-decicated input. ...snip... > Thanks you for listening to my rant! > > [1] AMCC S2060 > [2] Nobody forced me, but it was an interesting challenge. > [3] Consider where you have 8 bits and a clock going out of your > FPGA and 1 meter across the backplane. The signals are all of the same > length, and you run say 200 Mbaud. Skew at ouput is important, but > actual delay is not. I agree that this will become more common, but that does not solve the problems of building a chip to meet the spec. In these chips, the skew is an undocumented parameter as it depends greatly on the routing as well as the chip fabrication. It might be something that Xilinx will consider documenting in the future for global clocks and IOBs. -- 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 Arius 4 King Ave Frederick, MD 21701-3110 301-682-7772 Voice 301-682-7666 FAX Internet URL http://www.arius.comArticle: 26618
--------------4F68C22A2ADD248C50645CBB Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit Well, "typical of Xilinx" is not a fair statement. As explained in our letter to customers http://www.xilinx.com/products/coolpld/custnotice.htm we tried to get continued supply from Philips, but we were not successful. Short of redesigning all these old parts to match our foundry, we had to obsolete these parts sometime in 2001. Of course, this is unpleasant and expensive for many users, and we regret this development. But if anybody knows a smarter solution, let me know. Aside from this problem of supply of the older parts, the Xilinx takeover of the CoolRunner program has been a real success. Philips wanted to get rid of a product line that did not fit their company, and the ex-Philips, now Xilinx, employees in Albuquerque are happy to work for a company that is totally focused on programmable logic, and is putting renewed emphasis on their product line. Peter Alfke, Xilinx Applications ================================= Peter wrote: > Typical of Xilinx - buy a competitor then close it down. I now have to > redesign some boards!!!! > > >Discontinuation notice here: > >http://www.xilinx.com/partinfo/notify/pdn0007.htm > > > >Looks like everything but the XPLA3 family goes. > >Last time buy April 27/01. > > Peter. > -- > Return address is invalid to help stop junk mail. > E-mail replies to zX80@digiYserve.com but remove the X and the Y. > Please do NOT copy usenet posts to email - it is NOT necessary. --------------4F68C22A2ADD248C50645CBB Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit <!doctype html public "-//w3c//dtd html 4.0 transitional//en"> <html> Well, "typical of Xilinx" is not a fair statement. <br>As explained in our letter to customers <p><u><A HREF="http://www.xilinx.com/products/coolpld/custnotice.htm">http://www.xilinx.com/products/coolpld/custnotice.htm</A></u> <p>we tried to get continued supply from Philips, but we were not successful. Short of redesigning all these old parts to match our foundry, we had to obsolete these parts sometime in 2001. <br>Of course, this is unpleasant and expensive for many users, and we regret this development. <br>But if anybody knows a smarter solution, let me know. <p>Aside from this problem of supply of the older parts, the Xilinx takeover of the CoolRunner program has been a real success. <br>Philips wanted to get rid of a product line that did not fit their company, and the ex-Philips, now Xilinx, employees in Albuquerque are happy to work for a company that is totally focused on programmable logic, and is putting renewed emphasis on their product line. <p>Peter Alfke, Xilinx Applications <br>================================= <br>Peter wrote: <blockquote TYPE=CITE>Typical of Xilinx - buy a competitor then close it down. I now have to <br>redesign some boards!!!! <p>>Discontinuation notice here: <br>><a href="http://www.xilinx.com/partinfo/notify/pdn0007.htm">http://www.xilinx.com/partinfo/notify/pdn0007.htm</a> <br>> <br>>Looks like everything but the XPLA3 family goes. <br>>Last time buy April 27/01. <p>Peter. <br>-- <br>Return address is invalid to help stop junk mail. <br>E-mail replies to zX80@digiYserve.com but remove the X and the Y. <br>Please do NOT copy usenet posts to email - it is NOT necessary.</blockquote> </html> --------------4F68C22A2ADD248C50645CBB--Article: 26619
Greetings - We have some excess QuickLogic inventory up for sale. Please see http://www.jumboprawn.net/for_sale/ql_100144.html http://www.jumboprawn.net/for_sale/ql_base.html thanks - - jesse Sent via Deja.com http://www.deja.com/ Before you buy.Article: 26620
FWIW, the period constraint also lets you do skew analysis, which the from:to constraints do not. rickman wrote: > For an offset constraint to work, you need to have a period constraint. > But if you force the input FFs into the IOBs, you don't need offset > constraints. > > The FF-FF constraints are ok, but you have to use them on *every* set of > FFs in your design. Often a period constraint is just easier to use. > > > > The problem is that I can not tolerate the absolulte difference in > > > propagation time between clock_PAD -> FF and data_PAD -> FF of more > > > then 6 ns, in addition the propagation time on clock or data path to FF > > > can not exceed 25 ns. > > -- -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 or http://www.fpga-guru.comArticle: 26621
The problem with using only OFFSET IN BEFORE is that my data is valid for a fraction of clock period only around each clock edge, so for example say OFFSET IN BEFORE = 6 ns, the tools will find that the following two results are accepatable: For the sake of discussion let the clock period be 60 ns. 1) CLK delayed by 9 ns, Data delayed by 16 ns (the tool will report 1 ns slack (16-(9+6)), which is OK) 2) CLK delayed by 2 ns, Data delayed by 16 ns (the tool will report 8 ns slack (16-(2+6)), which is not OK, since my data is invalid in this region (data is only valid for 6 ns before and after each edge). In addition the tools may have a difficult time meeting the constraints specified, because the tools does not take advatage of the fact that the clock edge could be ahead of data by as much as 6 ns. -- Yury In article <39F2F7EA.C7315909@yahoo.com>, rickman <spamgoeshere4@yahoo.com> wrote: > Magnus Homann wrote: > > > > yuryws@my-deja.com writes: > > > > > Registering the inputs in IOB Flops will only take care of one set of > > > those flops (Rising or Falling edge only), which I happen to do anyway, > > > except I do use the externally fed CLK to do that. > > > > > > The other set of FFs is that from CLBs. The reason for all of these > > > problems is that data is only valid for 6ns before and 6ns after each > > > clock edge. > > > > > > I suppose Double data rate SDRAMs operate in a similar manner. This > > > design is for a uDMA controller. > > I don't think you understood Andy's suggestion. He is saying that you > need to use a DLL or other clocking scheme to generate a clock that is > twice the frequency of your data clock. This will give you a rising edge > for each data phase. Then you only need one set of FFs to clock the data > into the device. Once you have the data in the IOB FFs, you need to > decide if you will continue to run at the 2x rate or if you will double > the width of the data path and resync to the 1x clock rate. > > > > I do just what you described as far as FF-FF constraints are concerned > > > instead of PERIOD constraint. In addition my internal clock running at > > > 2.5 times the shortest side of the externally fed clock is used fo > > > detecting the edges and doing some clever stuff with it. > > For an offset constraint to work, you need to have a period constraint. > But if you force the input FFs into the IOBs, you don't need offset > constraints. > > The FF-FF constraints are ok, but you have to use them on *every* set of > FFs in your design. Often a period constraint is just easier to use. > > > > The problem is that I can not tolerate the absolulte difference in > > > propagation time between clock_PAD -> FF and data_PAD -> FF of more > > > then 6 ns, in addition the propagation time on clock or data path to FF > > > can not exceed 25 ns. > > Using a DLL will fix your timing problems. Opps, I see that you are > using (or planning to use) a SpartanXL, no DLL. You can use the two sets > of FFs as you mentioned, but you will need to specify only one of the > offset constraints. They way they are used, you only need to specify the > setup time, not the hold. So you should use the OFFSET IN BEFORE > constraint and the tool should work properly on both clock edges. > > Remember, the tool does not care about clock edges. It only looks at > static path delay calculations. The only time it considers the clock > edge is when you feed on FF from another clocked from opposite edges. > > > > From what I see the Xilinx PAR tools do not have enough controls to > > > allow for specifying such a situation. What I have been doing so far is > > > constrain the prop time (clock -> FF) and (data -> FF) to 6 ns, which > > > does work, but the tools have a very difficult time meeting the > > > constratint. > > > > I have also tried to specify min and max Tco and Tsetup with both > > Xilinx and Altera. The tools can't handle this, and I think this will > > become more and more of a problem. It would also be nice to be able to > > cnostraint Toskew for a set of outputs. > > > > The tools are not good enough for this, atr leats they weren't six > > months ago. > > I don't see the need to specify these timing values. Specifying one or > the other will give you the timing that the tool needs to do the > routing. You need to look at what the tool is doing. It only needs one > number to tell it how fast it has to route the traces. It gets this > number from the offset combined with the period. The calculations of > clock routing vs. data routing are done automaticially. > > -- > > 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 > > Arius > 4 King Ave > Frederick, MD 21701-3110 > 301-682-7772 Voice > 301-682-7666 FAX > > Internet URL http://www.arius.com > Sent via Deja.com http://www.deja.com/ Before you buy.Article: 26622
I'm a student and I've to synthetize a dual port memory in VHDL, but I've some problems with BUSes... ... can anyone help me with same example... thank you, Emanuele RussoArticle: 26623
Does anyone make little printed circuit boards whose only purpose is to bring out the signals from a quad flat pack so that wire wrap pins or headers can be attached for wire wrapping? (eg 160QFP => 8x20 pins) I'm willing to solder the parts together myself. I'm just looking for the PCB (a $20 solution) not a $500 adapter. All this surface mount technology and high density / small packaging may be great for reducing the costs of volume production, but it's the pits for someone working in their garage on a shoestring budget. Thanks RobArticle: 26624
Think farnell sell pcbs like that. I've made pcbs myself for 100pin QFP 0.5mm lead pitch ICs. Rob Finch wrote: > > Does anyone make little printed circuit boards whose only purpose is to > bring out the signals from a quad flat pack so that wire wrap pins or > headers can be attached for wire wrapping? (eg 160QFP => 8x20 pins) I'm > willing to solder the parts together myself. I'm just looking for the PCB (a > $20 solution) not a $500 adapter. > > All this surface mount technology and high density / small packaging may be > great for reducing the costs of volume production, but it's the pits for > someone working in their garage on a shoestring budget. > > Thanks > Rob -- ******************************************* * Russell Shaw, B.Eng, M.Eng(Research) * * email: russell@webaxs.net * * Victoria, Australia * *******************************************
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