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
Philip, Yes, the pinout is compatible, you just have to go one grade up in order to have the same recourses, i.e. from XC4005 to XCS10, from XC4010 to XCS20, etc. The mode pin M2 is replaced by PWRDWN, but in normal operation they are both pulled up, so we are OK with that. My only concern was whether the packet and the headers of the serial bit stream are the same, and if you say they are, than we should be fine. Thanks, Stefan "Philip Freidin" <philip@fliptronics.com> wrote in message news:fs4k1tcuggf9146pb8cheq1qqmvjs5jaq7@4ax.com... > On Mon, 20 Nov 2000 16:27:01 -0800, "S.Ivanov" <stefan1@canada.com> wrote: > >Hello all, > > > >We have a board with 6 FPGAs. So far we have been using the XC4000 family > >for all the 6. > >The configuration is done from a 8-bit EEPROM via a daisy chain, where the > >first device > >is in Parallel Master Mode and the rest are in Serial Slave Mode. > >Now we want to switch to Spartan devices. The Spartan devices, however, > >don't have a > >parallel configuration mode. Since it is an existing board and we can not > >change anything, > >I am considering the option of keeping the first device in the chain as an > >XC4000 and > >replacing the other 5 with Spartans. Is this going to work? Is the serial > >data stream coming > >out of the XC4000 devise compatible with the serial stream for Spartan > >devices? > > Yes, the bitstreams are compatible. But are you sure that you can drop > Spartans into the footprint of your existing XC4000 parts (the 5 you intend > to change). I ask, because the pinout of Spartan packages are not > identical to the XC4000E parts from which they are derived. For instance, > look at the mode pins. You say that "Since it is an existing board and > we can not change anything". I think you will have to make at least some > very minor board layout changes. Or much more ugly: rework. > >Thanks, > >Stefan Ivanov > > > Philip Freidin > Philip Freidin > FliptronicsArticle: 27426
On Mon, 20 Nov 2000 16:46:10 -0500, "Zhen Luo" <zhenluo@ee.princeton.edu> wrote: >Hi, guys > >I am writing my thesis now and one of my reviewers had a different view >about FPGA clock rate. I felt FPGA could not achieve the general-purpose >processor like clock rate (> 1GHz right now) because FPGA's structure and >its components (like SRAM-based look-up table, programmable wiring >switchbox) are just not fit for high clock rate. My reviewer pointed out >that FPGAs couldn't achieve the general-purpose processor like clock rate >because they had to be cost-effective. If Xilinx had a foundry like intel >did and they would go all for the clock speed, they could make it to the >similar range. I think there is some truth in it, but I still don't think >FPGA could be that fast even if they do so. Yes there is some truth to it but not much. TSMC and other fab vendors are very aggresive these days and Xilinx is definitely using a full custom process. Also as Xilinx designs chips which are very regular as opposed to a say P4 which needs almost every single logic transistor to be hand designed, Xilinx must be spending a lot of time optimizing their structures. > >I would really like to hear your thoughts on this. Meanwhile, I also have a >question, why is the I/O clock rate of Xilinx chips much slower than their >internal clock rate? Would that finally become the bottleneck for improving >the overall clock rate for FPGA applications? All ICs have much slower I/O clock rates than their internal rates. The reason is the wires I/Os have to drive have much larger load so they are difficult to drive fast. You can get around this if you treat I/Os as communication lines instead of full swing wires. If you use LVDS IO you can get upto 2.5Gb/s on an IO Muzaffer http://www.dspia.comArticle: 27427
Xavier, Your design is ok and it should work. What do you mean by : it doesn't work ? simulation (functional, timing) or on board ? Regards Olivier Regnault Avnet FranceArticle: 27428
Kevin, ROC is the best way to set your FF on startup sequence if you don't want to use an external reset pin. ROC will pass through the synthesis tool, it will be use for simulation and has the effect to not remove the set information from synthesis in your VHDL design. If you need an external reset pin, you can use the STARTUP_VIRTEX component. Note that for Virtex familly, you should prefer to use local interconnect instead of startup_virtex. Hope this will help you. Regards Olivier Regnault / Avnet FranceArticle: 27429
>On Mon, 20 Nov 2000 16:46:10 -0500, "Zhen Luo" ><zhenluo@ee.princeton.edu> wrote: > >I am writing my thesis now and one of my reviewers had a different view >about FPGA clock rate. I felt FPGA could not achieve the general-purpose >processor like clock rate (> 1GHz right now) because FPGA's structure and >its components (like SRAM-based look-up table, programmable wiring >switchbox) are just not fit for high clock rate. My reviewer pointed out >that FPGAs couldn't achieve the general-purpose processor like clock rate >because they had to be cost-effective. If Xilinx had a foundry like intel >did and they would go all for the clock speed, they could make it to the >similar range. I think there is some truth in it, but I still don't think >FPGA could be that fast even if they do so. To get the fastest clock rates with an FPGA you need to minimize the logic between FF's. That is, as fully a pipelined design as possible. But general purpose processors can do that, too. The routing matrix has somewhat more capacitance than a full custom chip would have. The only way to make up for excess capacitance is to drive the line with bigger transistors. That takes more power, and decreases the density of circuitry because of power dissipation limitations. More important than clock rate is clock rate multiplied by the number of transistors. (Assuming the same logic family.) This is what determines the amount of computational work that can be done. An FPGA designed to implement microprocessors might be somewhat different than the current implementations. -- glenArticle: 27430
In article <3A1A7A89.6BB792F7@sqf.hp.com>, nials@sqf.hp.com wrote: (snip) > Does anyone know of an active 3v TTL -> 5V CMOS driver in a small > package (8 pin soic, two channel would be ideal)? > > Nial. > Take a look at: http://www.toshiba.com/taec/cgi-bin/display.cgi? table=Category&CategoryID=117 and: http://www.fairchildsemi.com/search/search.cgi/design?keywords=NC7ST -- Greg Neff VP Engineering *Microsym* Computers Inc. greg@guesswhichwordgoeshere.com Sent via Deja.com http://www.deja.com/ Before you buy.Article: 27431
Hi Arrigo, Check your write permissions on your coregen/ip directory tree. I've seen errors like this when the ip directory was read only. Also, check to see if there are filenames within the ip directories with the same name but different (lower/upper)cases. One of these would be my guesses as to what's going wrong. Either way, it might be easiest to delete the ip directory and re-extract the coregen update. That should straighten things out. Don't forget to update the ip cores in the Coregen gui. Regards, Carl Arrigo Benedetti wrote: > I have found that after upgrading to the latest service packs for > Xilinx Alliance M3.2i and coregen I am no longer able to generate > any multiplier core: > > ERROR: Error locating library for class com.xilinx.ip.parm_v2_0.parm_scaled_adder$virtex$adder_inputs_type. > ERROR: Error loading library for class com.xilinx.ip.parm_v2_0.parm_scaled_adder$virtex$adder_inputs_type > ERROR: Could not load/define class file com.xilinx.ip.parm_v2_0.parm_scaled_adder$virtex$adder_inputs_type. > ERROR: An internal error has occurred. To resolve this error, please consult the Answers Database at http://support.xilinx.com > ERROR: Sim has a problem implementing the selected core. Implementation netlist will not be generated. > ERROR: SimGenerator: Failure of Sim to implement customization parameters core multhaccko > ERROR: Core multhaccko did not generate EDIF implementation netlist (.EDN) file. > WARNING: Warnings and/or errors encountered while generating multhaccko (Multiplier 2.0) All output products requested may not have been generated. > ERROR: Elaboration failure for core Multiplier > > ERROR: Elaboration of core Multiplier failed. > > Xilinx tech support has already been alerted. Does anyone know a cure for this? > > Thanks, > > -ArrigoArticle: 27432
Concerning XC4000E series. To activate the internal oscillator all I need is to include the OSC4 symbol in the schematic, as the documentation states. Correct? I have done this yet seen no evidence that the clock is running. Perhaps there's some other requirement I've missed, such as some external enable pin or other or a capacitor or who knows what. This is configured via JTAG, if that matters. TIA, d.r.t.Article: 27433
"Roli Z." wrote: > I installed the Webpack 3.2 on Windows NT 4.0 > If i run the Design Implementation it stops with exit code 0128 > (EXEWRAP detected a return code of '128' from program 'ngdbuild.exe') > > I tried it with several Example Projects. > > How can i solve this problem? There's been a recent thread on this. Have you tried dejanews or the Xilinx answers database ?Article: 27434
Hi Carl, the problem was that a file from the the latest core update (32i_ip_update2.tar) had a wrong name: <Xilinx>/coregen/ip/xilinx/parm_v2_0/com/xilinx/ip/parm_v2_0/parm_scaled_adder$virtex$adder_inputs_type.xc should have been .xcd instead. Kudos to John Ayer who found it. -Arrigo -- Dr. Arrigo Benedetti e-mail: arrigo@vision.caltech.edu Caltech, MS 136-93 phone: (626) 395-3129 Pasadena, CA 91125 fax: (626) 795-8649 Carl Rohrer <carl.rohrer@xilinx.com> writes: > Hi Arrigo, > > Check your write permissions on your coregen/ip directory tree. I've seen errors like this when the ip directory was read only. Also, check to see if > there are filenames within the ip directories with the same name but different (lower/upper)cases. One of these would be my guesses as to what's going > wrong. Either way, it might be easiest to delete the ip directory and re-extract the coregen update. That should straighten things out. Don't forget > to update the ip cores in the Coregen gui. > > > Regards, > Carl > > > > > Arrigo Benedetti wrote: > > > I have found that after upgrading to the latest service packs for > > Xilinx Alliance M3.2i and coregen I am no longer able to generate > > any multiplier core: > > > > ERROR: Error locating library for class com.xilinx.ip.parm_v2_0.parm_scaled_adder$virtex$adder_inputs_type. > > ERROR: Error loading library for class com.xilinx.ip.parm_v2_0.parm_scaled_adder$virtex$adder_inputs_type > > ERROR: Could not load/define class file com.xilinx.ip.parm_v2_0.parm_scaled_adder$virtex$adder_inputs_type. > > ERROR: An internal error has occurred. To resolve this error, please consult the Answers Database at http://support.xilinx.com > > ERROR: Sim has a problem implementing the selected core. Implementation netlist will not be generated. > > ERROR: SimGenerator: Failure of Sim to implement customization parameters core multhaccko > > ERROR: Core multhaccko did not generate EDIF implementation netlist (.EDN) file. > > WARNING: Warnings and/or errors encountered while generating multhaccko (Multiplier 2.0) All output products requested may not have been generated. > > ERROR: Elaboration failure for core Multiplier > > > > ERROR: Elaboration of core Multiplier failed. > > > > Xilinx tech support has already been alerted. Does anyone know a cure for this? > > > > Thanks, > > > > -Arrigo >Article: 27435
Yury,
I am very serious. We are looking for people to work in our offices.
Send me your info. and I will see you get considered.
Barry
<yuryws@my-deja.com> wrote in message news:8vcs26$kut$1@nnrp1.deja.com...
> I don't think you are serious Barry.
>
> -- Yury Wolf
>
> In article <wl%R5.280335$4d.36048590@news02.optonline.net>,
> "Barry Schneider" <barry61s@optonline.com> wrote:
> > I am presently working at a ASIC consulting company and we have a huge
> > backlog of work. We need help and will pay well. We have a great
> office
> > and have very flexible hours. We are looking for Verilog and/or VHDL
> > experience.
> > Synthesis and/or Mixed Signal a plus. If you are interested in a Good
> Job
> > e-mail me at barry61s@optonline.com
> > Hope to hear from you.
> >
> > Sincerely,
> > Barry
> >
> > PS: We have needs in: Commack, Long Island New York,
> > Hazlet, New Jersey
> > Bethlehem, Pennsylvania.
> > Cherry Hill, New Jersey
> >
> >
>
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
Article: 27436On 22 Nov 2000 00:49:48 GMT, sac62513@saclink3.csus.edu (Don Teeter) wrote: >Concerning XC4000E series. > >To activate the internal oscillator all I need is to include the OSC4 >symbol in the schematic, as the documentation states. Correct? Well you might want to make some connections to it also. >I have done this yet seen no evidence that the clock is running. What evidence were you looking for? >Perhaps >there's some other requirement I've missed, such as some external enable >pin or other or a capacitor or who knows what. Nope. Just plonk it down and connect to it. Did you check that the instance was in the EDIF file? what about the MAP trimming report? >This is configured via JTAG, if that matters. Providing the design goes done, no. >TIA, > d.r.t. Philip Freidin FliptronicsArticle: 27437
Hi. You don't make other parts or modification on the device. If you are sure that you could program the XC4000E, the OSC4 is the only one that need you for internal oscillator. But you must keep in mind that all of its frequency are very fast to see it if you use a simple light diode to see if they work. If you use this way to indicate the work of the core it's better to devide the lowest frequency by 2 or 4. Other possible error could be if you use all frequency from the OSC4. In the Spartan series it have a limitation to use maximum 3 of them and the 8MHz must be one of them. I don't know if it have such limitation on XC4000E but it's possible. In that case the Foundation give an error during the implementation. Look carefull for that. Latchezar Kostov In article <8vf57c$g0c@news.csus.edu>, sac62513@saclink.csus.edu wrote: > Concerning XC4000E series. > > To activate the internal oscillator all I need is to include the OSC4 > symbol in the schematic, as the documentation states. Correct? > > I have done this yet seen no evidence that the clock is running. Perhaps > there's some other requirement I've missed, such as some external enable > pin or other or a capacitor or who knows what. > > This is configured via JTAG, if that matters. > > TIA, > d.r.t. > > Sent via Deja.com http://www.deja.com/ Before you buy.Article: 27438
This is a multi-part message in MIME format. --------------4D84627ED00A9CAF9196D78B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Olivier Regnault wrote: > Kevin, > > ROC is the best way to set your FF on startup sequence if you don't want to use an external reset pin. > ROC will pass through the synthesis tool, it will be use for simulation and has the effect to not remove the set information from synthesis in your VHDL design. > > If you need an external reset pin, you can use the STARTUP_VIRTEX component. Note that for Virtex familly, you should prefer to use local interconnect instead of startup_virtex. Why this? > > > Hope this will help you. > > Regards > > Olivier Regnault / Avnet France --------------4D84627ED00A9CAF9196D78B Content-Type: text/x-vcard; charset=us-ascii; name="mmichel.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Markus Michel Content-Disposition: attachment; filename="mmichel.vcf" begin:vcard n:Michel;Markus tel;fax:+41 (0)61 336 22 00 tel;work:+41 (0)61 336 22 22 x-mozilla-html:FALSE org:Kontron Medical AG version:2.1 email;internet:mmichel@kontronmedical.ch title:dipl. El'Ing. ETH adr;quoted-printable:;;Reinacherstr. 131=0D=0AP.O. Box;CH- 4002 Basel;;;Switzerland x-mozilla-cpt:;5808 fn:Markus Michel end:vcard --------------4D84627ED00A9CAF9196D78B--Article: 27439
Ohps,
you are looking for a (real) low power -,
fast -, big resources -
FPGA. I would add : low cost .
anyone have them ? please, mail me too.
Xilinx (Philips) CoolRunner CPLDs are fast and
low power, ok, small recources, so
what about an actel-FPGA in fuse technology,
powered when you need it,
so stand-by-power is low,
and no configuration phase is needed,
when you switch it on.
Your application sounds like you have to
use other components like memory etc etc. .
what about the *total* power needed ?
Steve Nordhauser schrieb:
> I have a complex video processing application - wavelet or DCT
> compression in an FPGA for a 1Kx1K 30 frame per second video
> stream. I need very low power consumption. Ideally, I would like
> to leave the FPGA powered down until I need it, but it would have
> to be ready in under 100mSec.
>
> I've only worked with the Xilinx FPGAs and was wondering if
> someone out there with a more varied background could point me
> in the right direction. I need enough resources and speed to do
> the algorithm, but at minimum power.
>
> As an aside, anyone out there with compatible experience or can
> point me towards a web site for real-time, high resolution compression?
>
> Thanks,
> Steve Nordhauser
Article: 27440Hi, there Once I saw one post somewhere about a free IP core about Z80, but I forgot where I saw it. Would anyone here point me to the right place? No need to be fully finished. Thanks -- Zhengfan Xie frank_xie@writeme.comArticle: 27441
Hello,
My design doesn't work in fonctional simulation (RST signal has no
effect ...).
It's OK after implementation (Timing simulation) : high level on RST set
Counter output to "00".
Is there something to do to have a reliable fonctional simulation ?
Thanks,
Xavier Regal.
Here is my simulation script file :
Dels
Restart
wfm RST 0=1 10ns=0 3uS=1
wfm CK 0=0 (31.25ns=1 31.25ns=0)*80 | horloge 16 MHz
v CPT_OUT CPT_OUT[1:0]
run
Article: 27442Hi you all I'm having problems with Synopsys' FPGA compiler (design compiler) ver. 1999.10. I'm doing a pretty large design, and want to do gate-level functional simulation just after synthesis. My target FPGA archtecture is a Virtex XCV1000. From Synopsys it is possible to write a VHDL and SDF file, but the LUTs in the VHDL file has no generic INIT ports - meaning that the functionality of the LUTs are not exported. Is it possible to do simulation post synthesis, without using any of the Xilinx Alliance tools. I'm currently using Alliance 3.2i. Thanks in advance -HenrikArticle: 27443
On Fri, 17 Nov 2000 14:46:43 +0100, Wolfgang Kufer <wolfgang.kufer@rsd.rsd.de> wrote: >Hi All, > >I want to use an FPGA as PCI target. > >What are the possibilities of configuring this device? >Must I use an onboard flash/eeprom device as configuration memory or is >there any way to download the configuration data via the pci bus? This is a nasty problem. In principle, it should be possible to do it by adding some extra circuitry which latches the address of configuration writes, and resistor-isolating it so as not to violate the PCI loading specs (hey, Mr. Xilinx, have you thought about hard-coding this inside the FPGA?). If it works, it should be cheaper than storing the configuration on your card. This was discussed a couple of years ago here and in comp.os.ms-windows.programmer.vxd, but deja doesn't seem to be fixed yet so you probably wont be able to find the threads. If you're desperate, try emailing Joseph Allen (jhallen@world.std.com) to see if he got it to work. EvanArticle: 27444
On Tue, 21 Nov 2000 09:44:14 -0500, "Kevin Breeding" <kevinb@xetron.com> wrote: >I am writing VHDL code for a Xilinx Virtex FPGA. I do not have access to an >external reset signal. How do I make sure my flip-flops are reset after >power-up? I realize that after configuration the internal GSR signal is >high for a number of clock cycles to reset everything, but when I look at >the map.mrp file it does not show that the Startup block was instantiated. >Do I need to instantiate the Startup block in my VHDL code so that the GSR >signal is used, No >or are the Startup block and the GSR signal related to >different internal circuits? No - startup defines the connection to GSR, among others > If I instantiate a Startup block in my VHDL >code, do I need to specify an external reset input signal? No > Or do I need to >use ROC? No - see below >Is ROC strictly for simulation so that a valid reset is generated >at the start of simulation, Yes, but see below >or does the ROC component get passed through >synthesis? If ROC gets passed through synthesis does it become the Startup >block or GSR signal? It does get passed through, but the back-end tools remove it. However, they use it to identify which net is connected to GSR. This is all covered in detail in the online docs. In short: 1) If you just want an 'invisible' reset in the simulation, use ROC. Make sure that you specify a valid reset pulse width (with a configuration). 2) If you want to drive the FPGA's internal reset net (GSR) from your testbench, but you don't want your own real hardware to drive the GSR net, then use ROCBUF. 3) If you want your own internal signal, or external pin, to drive GSR, then use STARTBUF/STARTUP/VIRTEX_STARTUP. My personal preference is to use (VIRTEX_)STARTUP for all 3 cases above, since this more closely reflects the real hardware. There's another complication here, which is that the synthesis tool can infer which net should be connected to GSR by examining the async set/reset conditions on your code. This varies from tool to tool, and can be tedious to code, so I'd use one of the methods above to start with. EvanArticle: 27445
On Wed, 22 Nov 2000 08:57:12 +0100, Markus Michel <mmichel@kontronmedical.ch> wrote: >This is a multi-part message in MIME format. >--------------4D84627ED00A9CAF9196D78B >Content-Type: text/plain; charset=us-ascii >Content-Transfer-Encoding: 7bit > > > >Olivier Regnault wrote: >> If you need an external reset pin, you can use the STARTUP_VIRTEX component. Note that for Virtex familly, you should prefer to use local interconnect instead of startup_virtex. > >Why this? There's something on the website (I can't find it now) which recommends that you don't use STARTUP for Virtex. It doesn't give any reasons, and I don't believe it. I suspect that the reason was that Xilinx wants to stop people from explicitly using GSR, and may not give a user connection to it in the future. GSR is, however, very slow. See numerous threads in the past about how this is a problem, and how you can get around it. EvanArticle: 27446
I have the address http://www.lucent.com/micro/fpga/ bookmarked and it automatically took me to the http://www.lucent.com/micro/netcom/orca/ address. So if you can't reach them at either of these addresses, then there is likely a problem with your ISP. As Don said, the OR3 family has 32x4 dual port memory in each PFU. The OR2 family has multiple memory options including; 16x2 async, 16x4 async, 16x4 sync single port and 16x2 sync dual port. As Don also pointed out, the OR2 dual port memory provides half the bits as memory while the OR3 dual port provides all the bits as memory. husby@my-deja.com wrote: > > Steve Oldridge <steveo@ece.ubc.ca> wrote: > > I've been trying to access Lucent's website, in order to get > > datasheets for their ORCA FPGAs. Unfortunately for the past > > few weeks they've been down (at least I can't access them)! > > In keeping with their minimalist marketing strategy, they sometimes > move their website so that only their dedicated customers know > where it is. Currently it's at: > http://www.lucent.com/micro/netcom/orca/ > > > What I need to know specifically is whether or not the > > LUTs in their logic clusters can be used as memories. > > If anyone can tell me this (or point me to a datasheet > > not on Lucent's site) I'd be most appreciative. > > Yes. Each logic block (PFU) has 8 LUTs and can be used > as a 32x4 dual-port synchronous RAM. Note that Dual > port ram uses all the RAM bits, unlike the Xilinx parts > and Orca2, which use two 16x1 Luts to implement > a single 16x1 dual-port RAM. > > Sent via Deja.com http://www.deja.com/ > Before you buy. -- 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 URL http://www.arius.comArticle: 27447
Hi Everybody, I've just had some interesting discussions with Xilinx on their clock skew analysis tool. What they say might surprise you, it surprised me. A little backgroung first: Delay on any net (any physical line with only one driver) can be generally categorized into two categories. Capacitive delay, which is the time required for a driver to charge (or discharge) the capacitance of the line, and propagation delay, which is the time it takes for that charge to propagate to/from the driver. I have a design where I have two synchronous elements, a register feeding a RAM. They are both clocked by the exact same clock net, but a clock net that is on local routing. The Xilinx tools report that I have skew between the data signal and the clock signal between those two elements. However, I was wondering how I could have clock skew on two elements that are fed by the same clock. Consider again the delay types. The capacitive delay would be the same for all elements on the net, as they all add to the capacitance of the net. Only propagation delay would be different. I talked to a signal integrity expert here, and he said for FR4 (circuit board material), the typical propagation delay would be about 50ps/inch. Well, assuming the capacitance of the substrate is 4 times worse than FR4, and assuming that no line will be longer that 1/2 an inch (which is extremely generous) the maximum propagation delay (and therefore delta) of any net would be about 100ps in the design. However, I'm getting a reported skew of over 2ns. In my mind, the only thing that could cause this kind of reported skew on this line was that there was some sort of buffering element between the local routing switches, pips, etc; or, Xilinx had done lumped paramaterization of there local routing buses, so when you add those buses together, you just add the delays. Adding the delays for signals makes sense, as it is a capacitive loading problem, but not for skew analysis. So, I phoned Xilinx with this problem. And directly quoted out of their email: "The way in which we implement and characterize our internal routing is proprietary. What I can tell you is this- believe what the tool tells you: there is skew between those synchronous elements. You may infer what you'd like about the meaning of that (existance of buffers and other such elements that would cause skew / type of material we use to implement routing), but the fact remains- you have a race condition." Umm...OK. Anybody have any ideas on what this proprietary way is? Or, is it just a way to tell me to be quiet and just use the tools as is? Anyway, I've learned all about the MAXSKEW and USELOWSKEWLINES directives, this is not a discussion on that. It's a discussion on why there is clock skew on two synchronous elements with the *same* clock driver, and why Xilinx has responded the way they have. Cheers, WallyArticle: 27448
Hi,
We want to implement a Xilinx Spartan-II FPGA, type XC2S50, in our
(excisting) application. I'm trying to estimate the current supply of this
device by using the datasheets ("Spartan-II 2.5V FPGA Family: DC and
Switching Charateristics"). From this datasheet I get the following
information:
- Iccintq = 50mA; (supply current internal part)
- Iccoq = 2mA; (supply current I/O-part)
- Iccpo=500mA; (ramp rate 2ms)
Does this FPGA needs so much current at power-up? How can this ramp rate be
adjusted? I just can't imagine that this FPGA needs 500mA at power-up. I
thought these devices where low-power!?! Is there some information available
on this subject?
Regards,
Jurjen
Article: 27449"walter haas" <walter_haas@pmc-sierra.com> writes: > However, I'm getting a reported skew of over 2ns. In my mind, the > only thing that could cause this kind of reported skew on this line > was that there was some sort of buffering element between the local > routing switches, pips, etc; or, Xilinx had done lumped > paramaterization of there local routing buses, so when you add those > buses together, you just add the delays. I would guess that they take the max Tpd to the receiver as skew. Not many FPGA (any?) manufacturer have implemented min. Tpd calculation. A min Tpd of 25% of Max, would still get you 1.50 ns skew. Skew is diff between max delay to one element and min delay to the other. If you have a min of 0, skew equals max delay. > Adding the delays for > signals makes sense, as it is a capacitive loading problem, but not > for skew analysis. I don't understand you reasoning. On-chip routing is slow. That's why a signal from one end of an FPGA can take 4ns to get to the other end. The time is impotant, not if you model it by a lot of small capactors along the way, or a high Er of 50. Personally, I think the capacitance of the receiver is negligable, but don't quote me on that. > "The way in which we implement and characterize our internal routing is proprietary. What I can tell you is this- believe what the tool tells you: > there is skew between those synchronous elements. You may infer what you'd > like about the meaning of that (existance of buffers and other such elements > that would cause skew / type of material we use to implement routing), > but the fact remains- you have a race condition." > > Umm...OK. Anybody have any ideas on what this proprietary way is? Or, is it just a way to tell me to be quiet and just use the tools as is? It's a way telling you to stick to the specified interface, so that Xilinx can redesign internally as needed. Could be said in a nicer way, but i basically agree with him/her. A major step would be for the FPGA manufacturers to characterize external I/O ouput hold, and maybe, maybe even P&R accordingly. That would be the day. :-) Homann -- Magnus Homann, M.Sc. CS & E d0asta@dtek.chalmers.se
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