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
We are pleased to announce the release of the SPARK parallelizing high-level synthesis software tool developed at the Center for Embedded Computer Systems. SPARK takes the behavior of an application specified in C as input (with some restrictions) and produces register-transfer level (RTL) VHDL. SPARK employs several parallelizing compiler, compiler, and high-level synthesis transformations to generate a scheduled, resource bound data path along with a FSM controller. We have benchmarked SPARK on a range of multimedia and image processing designs and also a case study with an Intel design. The download page is at: http://www.cecs.uci.edu/~spark/download.shtml This page has SPARK binaries for Solaris and Linux platforms, a User Manual, and a Tutorial with a MPEG-1 player as an example. See publications on the SPARK webpage for more details on our work: http://www.cecs.uci.edu/~spark/publications.shtml Sincerely Sumit Gupta, Rajesh Gupta, Nikil Dutt, Alexandru Nicolau http://www.cecs.uci.edu/~spark Center for Embedded Computer Systems University of California, Irvine and San DiegoArticle: 64326
Hi Is there is cheap source or alternative to Xilinx parallel cable ? Also is it leagal to make my own cable (from the schemetic provided by Xilinx) and sell it. Thanks SumitArticle: 64327
Sorry that I warm up this discussion again, but there was a thread a
while ago on FPGA pricing. Someone complained that he could not get
near the prices listet in the Xilinx press release.
It was concluded that the time factor ("end of 2004") was overlooked
and caused the confusion.
I just stumbled about this press release:
http://xilinx.com/prs_rls/silicon_spart/03141s3_nd.htm
It says:
"Xilinx is new offering Spartan-3 FPGAs with 1 million system gates
for under $12.00*,[...]"
and again a few paragraphs later
"The XC3S50, XC3S200, and XC3S400 Spartan-3 devices with 50,000,
200,000, and 400,000 system gates respectively are available for less
than $6.50*."
well, the footnote axplains that these prices are valid at the end of
2004, but the text says these devices "ARE AVAlLABLE FOR $6.50" and
Xilinx "IS OFFERING NOW FOR UNDER $12"
Does anyone besides me have the feeling that this is not the right
grammar to discribe a situation that is set one year in the future?
Maybe the confusion was intended by the author?
Kolja Sulimma
Article: 64328
Hi Peter,
Thanks for your valuable explanation. Some comments below.
palfke@earthlink.net (Peter Alfke) wrote in message news:<e9ba0b8.0312271425.1639a8ed@posting.google.com>...
> Guillermo, you are concerned about what we call "tracking".
> Almost all timing specs are guaranteed max values.
> The min time is not specified, and a conscientious engineer might be
> tempted to assume zero.
> In reality, it is impossible for a small piece of silicon to be
> simultaneously slow and ultra-fast.
I understand. I just picked 0 ns for lack of a better estimation --
like
the 70% factor you mention below.
> Years ago, I defined a tracking factor: If any parameter is actually
> at its max value (it cannot be any longer), then all other timing
> parameters are between 70% and 100% of their guaranteed max values.
> But if the chip is inherently fast, and is cold, and has high Vcc,
> then all delays will be short, but the above relationship still holds:
> They all track with a max 30% error between them.
I see. That is very useful to know, but even then, wouldn't this mean
that the 5.5 ns value listed in the datasheet is not completely
correct?
i.e. in the Tsu1 calculation, and assuming a worst case scenario, Tin,
Tlogi1 and Tsui would be at their maximum values and Tgck would be 70%
of its maximum value, which would yield:
Tsu1 = 3.3 + 2.5 + 1 - 0.7 * 1.3 = min 5.9 ns approx.
Is this right?
>
> This method of calculating was unchallenged until recently, when some
> of the FPGA parameters started using soghisticated compensation
> techniques ( like in the DCM) and hardly changed at all, while the
> traditional delays showed their ususal temperature dependence ( +0.35%
> for ever degree C) and voltage dependence ( 1% faster for every 1%
> increse in Vcc ).
So this would mean that the above would not be valid anymore? In this
case, what would be the right thing to do? Should I go back to the 0
ns assumption for all values for which there's no guaranteed minimum?
Or
is there a better way to do it?
>
> These things cannot be guaranteed in writing, since there always are
> exceptions (metal delays are more stable than transistor delays, etc),
> but they can serve as a guideline. And they have done that over the
> past fifteen years. (You can find these explanations in old Xilinx
> data books prior to 1994.)
Yes, I understand completely.. However I still need to derive some
timing calculations for signals that go through a cpld. At this moment
I don't even know if I can use the external parameters listed in the
datasheet, due to my concerns expressed above. Can you recommend an
approach to this problem?
Your help is appreciated!
Guillermo Rodriguez
>
> Peter Alfke, Xilinx Applications.
> ========================================
> guillerodriguez@terra.es (guille) wrote in message news:<5d891e95.0312270821.393d7580@posting.google.com>...
> > Hi Dennis,
> >
> > Dennis McCrohan <dennis.mccrohan@xilinx.com> wrote in message news:<3FE33379.AD00F1DE@xilinx.com>...
> > > > I'm looking at a design based on a xilinx XCR3256XL cpld. Signals come
> > > > from different devices (e.g. a CPU), go through the cpld, and end on
> > > > the system's expansion bus. I need to derive the timings for all the
> > > > signals on this expansion bus, which depend on the timing of the
> > > > signals at the CPU and on the prop. delays of the cpld.
> > > >
> > > > The datasheet says this device has "predictable and deterministic
> > > > timing". What does this mean exactly?
> > >
> > > Umm, hmm, I think that may be marketing-speak for "not subject to
> > > variations in routing (wire) delay like those FPGAs".
> >
> > oops.. then my approach to timing calculations will be wrong..
> >
> > > > For example, take the pad to pad
> > > > delay, which is specified to be 10 ns for the -10 part. Is this 10 ns
> > > > a maximum value,
> > >
> > > Yup. See below.
> > >
> > > > or can I rely in the delay being 10 ns?
> > > >
> > > > e.g. take the following signal from the CPU:
> > > >
> > > > CE0# assert delay from rising edge of CLK: min 2 ns, typ 8 ns, max 10
> > > > ns.
> > > >
> > > > The CLK signal does not go through the cpld, but CE0# does. The timing
> > > > report indeed says propagation delay for CE0# is 10 ns. Can I assume
> > > > that CE0# at the expansion bus has min 12 ns, typ 18 ns, max 20 ns
> > > > relative to the rising edge of CLK? Or are the figures specified by
> > > > xilinx _maximum_ times only?
> > > >
> > > > Thanks.
> > >
> > > Unless otherwise noted the times shown in the timing report or datahseet
> > > for our CPLDs would be worst-case values. That means the lowest allowable
> > > operating voltage, hottest allowable temperature, and a device built on a
> > > Friday before a holiday ;-)
>
> > :)
>
> > > . Assuming that you stay within the allowable
> > > operating conditions, no device that you get from Xilinx should exhibit
> > > worse delay behavior than this, and the vast majority will be faster.
> >
> > I see.
> >
> > But then there's something I don't quite understand. I looked at white
> > paper 122 from Xilinx, ("Using the CoolRunner XPLA3 Timing Model"). There
> > are several examples on how to derive the 'external' timing parameters
> > from the internal parameters. All of these examples seem to assume the
> > internal timing parameters are always fixed values. Take for example, Tsu
> > (setup time for data at pad to clock at pad). This is derived as follows:
> >
> > Tsu = Tin + Tlogi + Tsui - Tgck
> >
> > Tin = Input buffer delay (for data)
> > Tlogi = Internal logic delay
> > Tsui = Internal register setup time
> > Tgck = Global clock buffer delay
> >
> >
> > The XCR3256XL datasheet says that for a -10 device:
> >
> > Tin = max 3.3 ns
> > Tlogi1 = max 2.5 ns (assuming single p-term)
> > Tsui = min 1.0 ns
> > Tgck = max 1.3 ns
> >
> > And indeed the same datasheet says that for 1 p-term, Tsu is:
> >
> > Tsu1 = 3.3 + 2.5 + 1 - 1.3 = min 5.5 ns
> >
> >
> > Now my question is this: If we must take all the internal timing values
> > as worst case values, then the above equation could be wrong. For example,
> > Tgck is listed as 1.3 ns max, but it could as well be lower... let's say
> > it turns out to be 0.3 ns under certain conditions. In that case Tsu1 might
> > need to be at least 6.5 ns under the same conditions, rather than 5.5 ns.
> >
> > Actually, the correct worst case equation should then be something like
> > this:
> >
> > Tsu_min = Tin_max + Tlogi_max + Tsui_max - Tgck_min
> >
> > With no known value for Tgck_min one would need to assume a minimum 0 ns
> > for this parameter, which would yield a worst case Tsu of 6.8 ns.
> >
> > Isn't this correct?
> >
> > Thanks for your help!
> >
> > Guillermo Rodriguez
Article: 64329Andy, Bassman59a@yahoo.com (Andy Peters) wrote in message news:<9a2c3a75.0312271600.1594f237@posting.google.com>... > guillerodriguez@terra.es (guille) wrote in message news:<5d891e95.0312270821.393d7580@posting.google.com>... > > Now my question is this: If we must take all the internal timing values > > as worst case values, then the above equation could be wrong. For example, > > Tgck is listed as 1.3 ns max, but it could as well be lower... let's say > > it turns out to be 0.3 ns under certain conditions. In that case Tsu1 might > > need to be at least 6.5 ns under the same conditions, rather than 5.5 ns. > > > > Actually, the correct worst case equation should then be something like > > this: > > > > Tsu_min = Tin_max + Tlogi_max + Tsui_max - Tgck_min > > > > With no known value for Tgck_min one would need to assume a minimum 0 ns > > for this parameter, which would yield a worst case Tsu of 6.8 ns. > > > > Isn't this correct? > > Perhaps it would be a worthwhile exercise to code up your CPLD, let > the tools have at it, and see what the static timing analyzer says? Not a problem, the design is already fully implemented and I do have the output from the timing analyzer. However this doesn't help too much, the analyzer internally just uses the same procedure which is outlined in whitepaper 122 from Xilinx -- i.e. all timings are derived from the internal timing parameters, using the maximum values for all parameters as listed in the datasheet. This is how it is documented to work and I've experimentally verified that it is indeed what it does. Guillermo RodriguezArticle: 64330
Hi -
On 28 Dec 2003 13:57:27 -0800, news@sulimma.de (Kolja Sulimma) wrote:
>Sorry that I warm up this discussion again, but there was a thread a
>while ago on FPGA pricing. Someone complained that he could not get
>near the prices listet in the Xilinx press release.
>It was concluded that the time factor ("end of 2004") was overlooked
>and caused the confusion.
(other stuff snipped)
At best, a press release will give you a (very) rough idea of what
you'll actually end up paying for a part. Relying on this kind of
information is one step above reading the entrails of chickens. And
on occasion, I've had *better* results with the chickens.
If you think there's even a chance that you're going to be designing
in a certain component, get a formal price quote from the salesman,
rep, or distributor. And if you can't get a quote, maybe you can't
get the part, either.
Bob Perlman
Cambrian Design Works
Article: 64331Hi, I have a FPGA connected with a flash rom. And I want to write data into flash using JTAG from PC. What should I implement FPGA with? The JTAG state machine? or others? Would somebody tell me what to do or give me the example Thanks and RegardsArticle: 64332
guillerodriguez@terra.es (guille) wrote in message news:<5d891e95.0312281413.4024503@posting.google.com>... > Andy, > > Bassman59a@yahoo.com (Andy Peters) wrote in message news:<9a2c3a75.0312271600.1594f237@posting.google.com>... > > guillerodriguez@terra.es (guille) wrote in message news:<5d891e95.0312270821.393d7580@posting.google.com>... > > > Now my question is this: If we must take all the internal timing values > > > as worst case values, then the above equation could be wrong. For example, > > > Tgck is listed as 1.3 ns max, but it could as well be lower... let's say > > > it turns out to be 0.3 ns under certain conditions. In that case Tsu1 might > > > need to be at least 6.5 ns under the same conditions, rather than 5.5 ns. > > > > > > Actually, the correct worst case equation should then be something like > > > this: > > > > > > Tsu_min = Tin_max + Tlogi_max + Tsui_max - Tgck_min > > > > > > With no known value for Tgck_min one would need to assume a minimum 0 ns > > > for this parameter, which would yield a worst case Tsu of 6.8 ns. > > > > > > Isn't this correct? > > > > Perhaps it would be a worthwhile exercise to code up your CPLD, let > > the tools have at it, and see what the static timing analyzer says? > > Not a problem, the design is already fully implemented and I do have > the output from the timing analyzer. > > However this doesn't help too much, the analyzer internally just uses > the same procedure which is outlined in whitepaper 122 from Xilinx -- > i.e. all timings are derived from the internal timing parameters, using > the maximum values for all parameters as listed in the datasheet. > > This is how it is documented to work and I've experimentally verified > that it is indeed what it does. So, then, what's your problem? --aArticle: 64333
Hi, there: I want to know how to fix this kind of problem? Phase 1.1 ERROR:Place:205 - This design contains an RPM macro bm_0 which is to be automatically placed, but it contains TBUF elelements that are not allowed during automatic placement of RPMs. You must either pick an absolute location for the macro using a LOC constraint, or remove the TBUF element from the macro. ERROR:Place:205 - This design contains an RPM macro bm_1 which is to be automatically placed, but it contains TBUF elelements that are not allowed during automatic placement of RPMs. You must either pick an absolute location for the macro using a LOC constraint, or remove the TBUF element from the macro. WARNING:Place:204 - Routed macros (nmc's) have been found in this design. The placer will need to verify that routing does not attempt to use already used resources every time these macros are moved. This may significantly slow down run time. If the macros are designed such that it is impossible to place the routed macros in a way that will cause the routing to overlap then set the environment variable "PAR_NOMACROROUTECHECKING" and the placer will run much faster. The routing will still be checked at the end of the run and if the same routing resourse is required by multiple macros then a fatal error will occur.Article: 64334
One Day & A Knight wrote: > Hi, there: > I want to know how to fix this kind of problem? > > Phase 1.1 > ERROR:Place:205 - This design contains an RPM macro bm_0 which is to be > automatically placed, but it contains TBUF elelements that are not allowed > during automatic placement of RPMs. You must either pick an absolute > location for the macro using a LOC constraint, or remove the TBUF element > from the macro. It tells you right there: "You must pick an absolute location for the macro"... Looks like you're using a bus macro here. Those will not be placed automatically, you have to position them manually with floorplanner/PACE. Or you can just put a corresponding location constraint into your .UCF, something like this: INST "bm_0" LOC = "TBUF_X0Y0" ; This would place the busmacro with the instance name "bm_0" in the lower left corner of the FPGA. Of course you have to do this for every instance, with different locations. Where you have to put it depends on what you want to do with it. Usually, you use bus macros to communicate between two modules of a design, so you place the macro so it straddles the border between the two modules it's supposed to connect. -- Sean Durkin Fraunhofer Institute for Integrated Circuits (IIS) Am Wolfsmantel 33, 91058 Erlangen, Germany http://www.iis.fraunhofer.de mailto:23@iis.42.de ([23 , 42] <=> [durkinsn , fraunhofer])Article: 64335
Thanks, Durkin. However that is the thing I don't understand. In my UCF file I put constraints like these in the UCF file. 1) INST "bm_0" LOC = "TBUF_X0Y0" ; 2) INST "bm_0" LOC = "TBUF_X0Y0:TBUF_X0Y7" ; # Since I use all four pins. I tried both cases but I always end up in this error 205, and Xilinx Answers don't have this error :( I have another question. How come the XST GUI's Properties ask for a .XCF file? Is that similar to .UCF? How do I compile my verilog codes with XST GUI while control the bus-delimiter with () instead of the default <>? Also, how come in the GUI, the UCF&XCF is in XST, while in commandline mode, the UCF is in NGDBuild? Why so many exceptions and so much inconsistency in ISE 6.1! :( In my procedure, I have only XST (ISE6.1.03) in my PC, so I used command line XST to make sure that the bus delimiter is (), then in commandline to run the NGDBuild with -uc my_top.ucf...then return back to GUI to do MAP and P&R... Only P&R doesn't work! I think I need to try out the manual placement. Best Regards, "Sean Durkin" <23@iis.42.de> wrote in message news:3ff00882$1@news.fhg.de... > One Day & A Knight wrote: > > > Hi, there: > > I want to know how to fix this kind of problem? > > > > Phase 1.1 > > ERROR:Place:205 - This design contains an RPM macro bm_0 which is to be > > automatically placed, but it contains TBUF elelements that are not allowed > > during automatic placement of RPMs. You must either pick an absolute > > location for the macro using a LOC constraint, or remove the TBUF element > > from the macro. > It tells you right there: "You must pick an absolute location for the > macro"... > > Looks like you're using a bus macro here. Those will not be placed > automatically, you have to position them manually with > floorplanner/PACE. Or you can just put a corresponding location > constraint into your .UCF, something like this: > > INST "bm_0" LOC = "TBUF_X0Y0" ; > > This would place the busmacro with the instance name "bm_0" in the lower > left corner of the FPGA. Of course you have to do this for every > instance, with different locations. > > Where you have to put it depends on what you want to do with it. > Usually, you use bus macros to communicate between two modules of a > design, so you place the macro so it straddles the border between the > two modules it's supposed to connect. > > -- > Sean Durkin > Fraunhofer Institute for Integrated Circuits (IIS) > Am Wolfsmantel 33, 91058 Erlangen, Germany > http://www.iis.fraunhofer.de > > mailto:23@iis.42.de > ([23 , 42] <=> [durkinsn , fraunhofer])Article: 64336
Bassman59a@yahoo.com (Andy Peters) wrote in message news:<9a2c3a75.0312282207.39878411@posting.google.com>... > guillerodriguez@terra.es (guille) wrote in message news:<5d891e95.0312281413.4024503@posting.google.com>... > > Andy, > > > > Bassman59a@yahoo.com (Andy Peters) wrote in message news:<9a2c3a75.0312271600.1594f237@posting.google.com>... > > > guillerodriguez@terra.es (guille) wrote in message news:<5d891e95.0312270821.393d7580@posting.google.com>... > > > > Now my question is this: If we must take all the internal timing values > > > > as worst case values, then the above equation could be wrong. For example, > > > > Tgck is listed as 1.3 ns max, but it could as well be lower... let's say > > > > it turns out to be 0.3 ns under certain conditions. In that case Tsu1 might > > > > need to be at least 6.5 ns under the same conditions, rather than 5.5 ns. > > > > > > > > Actually, the correct worst case equation should then be something like > > > > this: > > > > > > > > Tsu_min = Tin_max + Tlogi_max + Tsui_max - Tgck_min > > > > > > > > With no known value for Tgck_min one would need to assume a minimum 0 ns > > > > for this parameter, which would yield a worst case Tsu of 6.8 ns. > > > > > > > > Isn't this correct? > > > > > > Perhaps it would be a worthwhile exercise to code up your CPLD, let > > > the tools have at it, and see what the static timing analyzer says? > > > > Not a problem, the design is already fully implemented and I do have > > the output from the timing analyzer. > > > > However this doesn't help too much, the analyzer internally just uses > > the same procedure which is outlined in whitepaper 122 from Xilinx -- > > i.e. all timings are derived from the internal timing parameters, using > > the maximum values for all parameters as listed in the datasheet. > > > > This is how it is documented to work and I've experimentally verified > > that it is indeed what it does. > > So, then, what's your problem? As I said in my first mail, the procedure outlined in whitepaper 122 always takes the maximum value for all internal parameters when deriving other (external) parameters, which may not be correct in all situations. See the comments from Peter Alfke too. Since the analyzer internally just applies the same procedure outlined in whitepaper 122, the timing report it produces doesn't help. Guillermo RodriguezArticle: 64337
A Day & A Knight wrote: > Thanks, Durkin. > However that is the thing I don't understand. In my UCF file I put > constraints like these in the UCF file. > 1) INST "bm_0" LOC = "TBUF_X0Y0" ; > 2) INST "bm_0" LOC = "TBUF_X0Y0:TBUF_X0Y7" ; # Since I use all four > pins. > I tried both cases but I always end up in this error 205, and Xilinx Answers > don't have this error :( Version 1) should suffice. For each macro there is one pin defined as the reference, and that pin is used to place the macro. All the other pins of the macro are then fixed, because the routing and placement is specified in the macro itself, relative to the reference pin. Version 2) should give you an error, since TBUF_X0Y0:TBUF_X0Y7 is an ambiguous location, so that should not work at all, as I understand it. Since you don't get an error other than 205 when using version 2, and it still says "RPM macro bm_0 which is to be AUTOMATICALLY placed", even though you have placed it manually in the .UCF, I suspect that ISE doesn't really use your .UCF-file at all. How did you add the .UCF to your design? You should just add it as a source file (just like your verilog source codes), and assign it to your top-level design file when asked. > I have another question. How come the XST GUI's Properties ask for a .XCF > file? Is that similar to .UCF? The .XCF is for synthesis, the .UCF is for mapping and the place and route process. In the .XCF you can put special constraints for XST, like if it should optimize away equivalent registers, automatically add IO-buffers and things like that. The .XCF is for use with XST, exclusively and does not work with FPGA Express and other synthesis tools (at least as far as I know). In the .UCF you put more global things, like which IOBs to use, timing constraints for your clock signals, area constraints for modules etc., i.e. things that relate to the implementation of your design, that is mapping, placing and routing. A .UCF can be used with tools from other vendoers as well. > How do I compile my verilog codes with XST GUI while control the > bus-delimiter with () instead of the default <>? In Project Navigator, select your top-level design file, right-click on "Synthesize", and chose "Properties". After scrolling down (!) you can specify the "Bus delimiter" in the "Synthesis Options" tab. > Also, how come in the GUI, the UCF&XCF is in XST, while in commandline mode, > the UCF is in NGDBuild? As I stated above, the .UCF should be added to the design just like your verilog source codes, not in the XST settings. It's possible that your .UCF is simply ignored when added in the XST settings, which would explain your problem. > Why so many exceptions and so much inconsistency in ISE 6.1! :( > In my procedure, I have only XST (ISE6.1.03) in my PC, so I used command > line XST to make > sure that the bus delimiter is (), then in commandline to run the NGDBuild > with -uc my_top.ucf...then > return back to GUI to do MAP and P&R... > Only P&R doesn't work! P&R needs a .PCF (physical constraints file) to work. This .PCF is generated automatically from your .UCF during mapping. Normally, par looks for a file named <your_design>.pcf or <your_design_map>.pcf in the working directory, and uses that automatically. If it's not there, it tries to place everything itself. I suspect that this is what happens in your case. Check and see if a .PCF file is generated somewhere along the way. But I guess if you run the entire flow in the GUI (after changing the bus delimiter like described above), everything will work fine automatically. -- Sean Durkin Fraunhofer Institute for Integrated Circuits (IIS) Am Wolfsmantel 33, 91058 Erlangen, Germany http://www.iis.fraunhofer.de mailto:23@iis.42.de ([23 , 42] <=> [durkinsn , fraunhofer])Article: 64338
Thank you! Looks like any user I/O can be used with the pci-x standard. Have you considered the XAPP653 for over- and undershoot handling? Xilinx recommends to regulate Vcco to 3.0V for all banks with pci-x standard in order to keep values within the maximum FPGA specification. Matthias Mark Schellhorn schrieb: > Check out answer record #14965: > > http://support.xilinx.com/xlnx/xil_ans_display.jsp?iLanguageID=1&iCountryID=1&getPagePath=14965 > > The databook I have (older) mentioned some banking restrictions but it looks > like they have disappeared with newer software. > > Make sure you obey the PCI-X trace length restrictions on the card. I would > establish the orientation of your FPGA on the card and then choose a pinout that > lines up with the edge card pins. Worked for me. > > Mark > > Matthias Müller wrote: > > Hello, > > I'm developing a pcix-card and I will use the PCIX-core from Xilinx in a > > XC2VP7-5FF896 FPGA. Does anyone know if there is the need for using > > special pins of the FPGA to connecet the PCIX-signals to the > > bus-connector. Or can I use any FPGA-pin for any PCIX-signal? > > Thank you for answers! > > Matthias Müller > > > > ************** > > Please remove the *no*spam* from my email-address, if you want to mail > > to me! > > -- Matthias Müller Fraunhofer Institut Integrierte Schaltungen IIS -Bildsensorik- Am Wolfsmantel 33 D-91058 Erlangen Tel: +49 (0)9131-776-554 Fax: +49 (0)9131-776-598 mailto:mur@iis.fhg.de http://www.iis.fhg.deArticle: 64339
>As I said in my first mail, the procedure outlined in whitepaper 122 >always takes the maximum value for all internal parameters when deriving >other (external) parameters, which may not be correct in all situations. >See the comments from Peter Alfke too. >Since the analyzer internally just applies the same procedure outlined >in whitepaper 122, the timing report it produces doesn't help. I think this is one of those cases where you have to read between the lines a bit. What are you trying to do? Understand the data sheet or justify running the chip slightly over spec? Peter's 70% rule-of-thumb seems like a reasonable estimate. So the clock delay can't be much faster than worst case if the rest of the parameters are all close to worst case. What can they actually test? They probably test what you really want to know rather than the smaller pieces. If you just want to run the chip at full speed like everybody else, I'd just go for it. If you are trying to cheat and push things a bit, please tell us more. -- 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: 64340
James, Check out the input common-mode range (Vicm) and differential input voltage (Vidiff) for LVDSEXT_25. This should meet your requirements depending on the spec of the LVPECL parts you're using. Otherwise, you have to resort to level shifting resistors, or level shifting parts, try Micrel, Maxim, OnSemi etc. cheers mate, Syms. "jicho" <jicho@it.co.kr> wrote in message news:<bsgm6j$q69$1@news.hananet.net>... > Dear all, > > I am trying to use differential LVPECL interface on Xilinx virtex-II pro > device. > > I have to connect some standard LVPECL(3.3V) signal to virtex-II pro device. > But I know that Virtex-II Pro devices support only LVDS_25 and LVPECL_25. > There is no problem with Spartan-IIE or Virtex-II device because they have a > LVPECL_33 I/O. > > I want to know how I connect between standard LVPECL(3.3V) signal and > virtex-II pro LVPECL_25 signal in differential manner. > > Could anybody give me some answer ? > > Thanks, > james.Article: 64341
Rudolf Usselmann wrote:
>
> Also, in the answer records, it states the schematic for
> parallel cable 4 is unavailable because it is a "proprietary"
> design. This seems to me really nonsense, you guys make
> money with FPGAs not with cables. releasing the schematic
> will enable users to support them selves when you guys
> can't. Could you please ask the appropriate people to
> reconsider this choice ?
If you open up the parallel cable 4, you will see it is
built with a big CPLD, so it is clearly a parallel-serial
converter (serializer). The PC sends in bytes in a
normal "line printer" strobed mode, and the CPLD turns
that into the JTAG data stream.
That said, there's a lot of room for "innovation" (cough,
"problem solving" for us engineers, try telling that to
the lawyers) in how that transaction happens, especially
controlling the JTAG state machine before getting to the
bulk bit transfer mode.
If you can take the performance hit, I recommend you switch
back to Parallel Cable 3, for which Linux drivers are trivial
and widely published. Also, I can put you in touch with
someone who made an "open source" USB-to-JTAG programmer,
out of an XC2S30 and an FT245B. Schematics, FPGA code, and
software are published. Linux drivers are provably possible,
but not demonstrated -- of course, Xilinx packaged software
will probably never support this device. I personally have
access to one board.
- Larry
Article: 64342guille wrote: > Tsu_min = Tin_max + Tlogi_max + Tsui_max - Tgck_min > > With no known value for Tgck_min one would need to assume a minimum 0 ns > for this parameter, which would yield a worst case Tsu of 6.8 ns. Consider using synchronous design techniques and the fpga's global clock distribution network. This will allow you to verify timing without requiring any MIN specifications at all. In fact, the place and route software will do this "static timing analysis" for you. -- Mike TreselerArticle: 64343
Hi
Can someone tell me if there is a defference between the following two VHDL
sources working:
1.
process
begin
wait until C'event and C='1';
if B='0' then
Q<=B;
else
Q<= A;
end if;
end process;
2.
process
begin
if B='0' then
wait until C'event and C='1';
Q<=B;
else
wait until C'event and C='1';
Q<=A;
end if;
end process;
Simulation of this two processes gives different results. Does anybody know
why? Is there a specification discussing those cases?
Thanks for any help
Article: 64344Peter Alfke <palfke@earthlink.net> wrote: : All Xilinx FPGAs have input hysteresis (Schmitt triggered inputs). : Peter Alfke Is this hysteresis spec'ed somewhere? For example, in ds001 (full Spartan II datasheet) I can't find any occurance of "hyst". Bye -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 64345
I also could not find the specification ( and there is a limited crew around in these days). But I know that the hysteresis depends on the I/O standard and the part family. If you want to investigate, it's very simple: Take the input and bring it out, inverted, on a pin that is not adjacent. Then connect a large resistor from the output to the input ( 10 kilohm ) and decouple the input to ground with a big capacitor ( 10 nF). Now you have an oscillator, and the voltage on the input, (i.e. the capacitor) oscillates between the two hysteresis points. That's how them old folks used to build oscillators with a 7414... Happy New Year! Peter Alfke ==============================Article: 64346
It's apparent from the code: Case 1 says "wait for clock, THEN test B and act accordingly" Case 2 says "Test B, decide how to act, THEN wait for clock" Also, Case A is synthesisable (being a register with a 2-input mux in front), case B is probably not synthesisable (ie there is no hardware equivalent). "toomuch" <toomuch@poczta.onet.pl> wrote: :Hi : :Can someone tell me if there is a defference between the following two VHDL :sources working: :1. :process :begin : wait until C'event and C='1'; : if B='0' then : Q<=B; : else : Q<= A; : end if; :end process; : :2. :process :begin : if B='0' then : wait until C'event and C='1'; : Q<=B; : else : wait until C'event and C='1'; : Q<=A; : end if; :end process; : : :Simulation of this two processes gives different results. Does anybody know :why? Is there a specification discussing those cases? : :Thanks for any help : :Article: 64347
On 29 Dec 2003 10:46:52 -0800, symon_brewer@hotmail.com (Symon) wrote: >James, >Check out the input common-mode range (Vicm) and differential input >voltage (Vidiff) for LVDSEXT_25. This should meet your requirements >depending on the spec of the LVPECL parts you're using. >Otherwise, you have to resort to level shifting resistors, or level >shifting parts, try Micrel, Maxim, OnSemi etc. >cheers mate, Syms. I had a similar problem to the OP. Unfortunately, no IO standard on on the (2.5V powered) Virtex2 Pro had a common mode range suitable for 3.3V PECL. My signal was DC balanced, so I capacitively coupled it from the PECL to the FPGA, and used DCI to provide the DC bias and termination on the FPGA side. Regards, Allan.Article: 64348
On Mon, 29 Dec 2003 21:21:55 +0100, "toomuch" <toomuch@poczta.onet.pl> wrote: >Hi > >Can someone tell me if there is a defference between the following two VHDL >sources working: >1. >process >begin > wait until C'event and C='1'; > if B='0' then > Q<=B; > else > Q<= A; > end if; >end process; > >2. >process >begin > if B='0' then > wait until C'event and C='1'; > Q<=B; > else > wait until C'event and C='1'; > Q<=A; > end if; >end process; > > >Simulation of this two processes gives different results. Yes. >Does anybody know why? Yes. 1 samples B and A just after the rising edge of C. 2 samples B and A just after the rising edge of C, but doesn't use the value of B until after the next rising edge of C. 2 is not good coding style. Don't have more than one wait statement in a synthesisable process. >Is there a specification discussing those cases? Yes. Try: The VHDL LRM. Any VHDL text book. Any VHDL lecture notes. The VHDL FAQ. Google. Regards, Allan.Article: 64349
Quite possible. A slow moving signal can actually get the input to oscillate
due to the input threshold changing slightly when the input buffer's output
state is changed. Noise on the reference can also do that if the signal is
hanging around the threshold region. Put some hysteresis on the input or use a
schmitt trigger to clean it up.
Markus Meng wrote:
> Hi all,
>
> I would like know from the experts if the following behavior is possible
> if the input signal rise is exeeded. Xilinx states in its datasheet it shall
> be
> no more than 250 ns.
>
> If it is for exemaple 350 ns, but still - single pole - monotonic rise time,
> what
> is the internal logic seeing? Is it possible that the transistion
> from "0-1" is being seen as something like "0-1-0-1", or is only a matter of
> power consumption in the CMOS input stage, or even something else?
>
> Best Regards
> Markus
--
--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
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