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
"Dan" <daniel.deconinck@sympatico.ca> wrote in message news:AAah9.1229$Ox4.279569@news20.bellglobal.com... > Hello, > > I would like a 1.8V reg in Industrial temp and a three pin surface mount > package. > > So what 1.8 V Reg do you use ? For 5v->3v3 we use LM39401S for I/O voltage. This is a 3-pin. Then for 3v3 -> 1v8 core voltage we use LP3965ES-ADJ with 3 external resistors. This is a 5-pin but same package size as the 3 pin.. Both are surface mount with extended copper to help heat dissipation (they run pretty cold anyway). This is driving one XCV200E device which is similar to a Spartan IIe. -- David Frith, Principal Engineer, Fujifilm Electronic Imaging, Hemel Hempstead, Herts, HP2 7RH. UK. Email: david.frith@ffei.co.uk Tel: (+44)(0)1442 343083Article: 47051
Hello, Great pointers from all. And Jim , I remember the peak startup current of certain FPGAs being a large subject a while ago on this group. So , yes that too is very important. Sincerely DanArticle: 47052
Hi,
I had the same problem few days ago.
Look at
http://www.sital.co.il/supp.html
or
Direct link to pdf for VHDL gate-level simulation:
http://www.sital.co.il/pdf/Xilinx_VHD_gtl_HDS.pdf
Direct link to pdf for Verilog gate-level simulation:
http://www.sital.co.il/pdf/Xilinx_Vlg_gtl_HDS.pdf
Hope this will help.
Peter
"Mike D" <mdelphia@snet.net> wrote in message
news:QY4g9.877$VD2.360475664@newssvr10.news.prodigy.com...
> Hi I am developing a Xilinx XC2S150 design using Mentor FPGA Advantage
> (Leonardo Level II and Modeltech PE). I need to run a post-synthesis
> simulation to verify my design with my test bench. Does anyone have a
> "cook-book" method to do this? I am in a hurry and would like to learn
the
> details later. Any help would be greatly appriciated.
>
> Thanks Much
>
> Mike D.
>
>
Article: 47053
Hi everyone,
I'm trying to produce both a 100 MHz and a 200 MHz clocks from a 40 MHz
input using the Virtex-II DCM, and I'm a bit worried about the jitter
figures from the Virtex-II CLKFX online jitter calculator. The solution I've
chosen so far has two DCMs:
- In the first DCM I multiply the 40 MHz by 5/2 to obtain 100 MHz, which I
use both internally in my design and as the input to the second DCM.
- In the second DCM I multiply the 100 MHz by two to get 200 MHz.
Incidentally, the CLK0 (100 MHz) output of this DCM is used to feed an
external DAC and gets back from off-chip to the feedback input of the DCM.
The problem is that, according to the jitter calculator I'll get 760 ps of
p-p jitter (speed grade 4) in the 100 MHz clock coming out of the first DCM.
That is period jitter, and it is within the 1 ns jitter that the second DCM
allows for at its input. However, the Virtex-II handbook also specifies 300
ps as the maximum cycle-cycle jitter for the input clock in low-frequency
mode, and I don't know whether my 760 ps of jitter are smoothly varying or
not. Has anyone got experience with this type of problem? Should I be doing
it in some other way?
Thanks in advance,
Javier
Article: 47054All, For people interested in cascading CLKFX, please email directly me about what you are tyring to do. We have not finished characterizing all combinations of two cascaded DCMs, so I can not really comment for the general case here in the newsgroup at this time without knowing details. In addition to the CLKFX case, there is the CLK0, CLK2X for the first stage. Have got to test absolutely every combination! Oh, and every M and D, and every frequency, over P/V/T, and in the worst SI environment allowed by the data sheet..... Javier's case looks like it will work fine (and I responded to him directly with details), but I have other concerns about driving a DAC with a jittered clock from an application point of view. Austin Javier Serrano wrote: > Hi everyone, > I'm trying to produce both a 100 MHz and a 200 MHz clocks from a 40 MHz > input using the Virtex-II DCM, and I'm a bit worried about the jitter > figures from the Virtex-II CLKFX online jitter calculator. The solution I've > chosen so far has two DCMs: > - In the first DCM I multiply the 40 MHz by 5/2 to obtain 100 MHz, which I > use both internally in my design and as the input to the second DCM. > - In the second DCM I multiply the 100 MHz by two to get 200 MHz. > Incidentally, the CLK0 (100 MHz) output of this DCM is used to feed an > external DAC and gets back from off-chip to the feedback input of the DCM. > The problem is that, according to the jitter calculator I'll get 760 ps of > p-p jitter (speed grade 4) in the 100 MHz clock coming out of the first DCM. > That is period jitter, and it is within the 1 ns jitter that the second DCM > allows for at its input. However, the Virtex-II handbook also specifies 300 > ps as the maximum cycle-cycle jitter for the input clock in low-frequency > mode, and I don't know whether my 760 ps of jitter are smoothly varying or > not. Has anyone got experience with this type of problem? Should I be doing > it in some other way? > Thanks in advance, > JavierArticle: 47055
Wojciech Piechowski wrote: > > On Fri, 13 Sep 2002, rickman wrote: > > > Wojciech Piechowski wrote: > > > > > > hello! > > > > > > I've just read an interesting thread about metastability and this made me > > > think about making a hardware random bit generator. Exploiting > > > metastability seems to be interesting. Just put to D an alternating > > > sequence which toggles with clock. Add some smart routing to make it hit > > > the hold window. And have a long time thinking how to read metastable Q > > > without passing metastability to the rest of the circuit.... > > > > > > Has anyone done something like this? Or heard about it? I'm thinking about > > > implementing it. Any help and comments appreciated. > > > > Resolving the metastable state in another FF stage or two would not be a > > problem. That is what is going on in a cross clock domain synchonizer. > > The first FF can not be made stable and always has a chance of becoming > > metastable. But the following stages have a much, much reduced chance > > of being metastable. > > > > This is useful when you synchronize unrelated signals. Then you have some > little probability of a metastate in the 1st FF and a very very little > probability that this FF would put the next FF into the metastate. > But we intentionally want a meta. Even a million times in a second (very > optimistic, but who cares :)). Probability of getting a meta in the next > stage is much greater than "once per 1000 years". It cannot be ignored. A > series of FF's may help, but still no guarantees. The solution may be to > wait long enough to be sure that Q is stable and then read it. My understanding is that you want a "random" series of 1s and 0s, and you want to try to generate this series using metastability, no? Perhaps we are not understanding one another. To use metastability to generate a "random" sequence, you would design a circuit that produces a metastable state in one FF. But to get 1s and 0s out of that you would need to then use following stages to resolve the metastable state (randomly) to a 1 or a 0. This will give you a stream of 1s and 0s non-deterministically. At least it will be non-deterministic if you can eliminate the effects of noise and digital coupling. So you don't need a complex circuit to MAKE the meta stable state. You don't need a complex circuit to resolve the metastable state. But to get the state resolution to be independant of the other signals in the circuit, you will need to take care. Of course you can never guarantee that you will NEVER have a metastability pass through your circuit. That is the nature of metastability. Waiting longer will not guarantee stability either. There is always a chance the metastable state will remain. On the other hand, it sounds like your needs are a lot less severe than normal "random" numbers. Perhaps you can use a simpler circuit that samples one clock using another. That should give you a "non-derterministic" series. But then this will also involve a chance of metastability. To the best of my knowledge, unless you use an ADC to measure something "non-deterministic", you can't get a "non-deterministic" 1/0 series from a digital circuit without involving metastability. > > But, to have a *useful* random number generator, the values must have > > certain properties. One of them is that the distibution must be even. > > If you are generating a stream of 1s and 0s, then you must have half 1s > > and half 0s. > [...] > > I don't require an equal distribution. Take a look into my answer to > Peter. That makes the solution a lot easier. But the basic facts remain that you either need to measure an analog signal that is "non-deterministic" or you need to measure a digital signal that is "non-deterministic" which will involve metastability. There are two basic facts to remember. All synchronous digital circuits are deterministic. You can never eliminate metastability in non-synchronous circuits. Anyone know if ADCs have the same problem with metastability? It seems to me that the comparator that is part of all ADCs would have the same issues the digital FF does... :) -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 47056
"rickman" <spamgoeshere4@yahoo.com> schrieb im Newsbeitrag news:3D8494F1.4E608503@yahoo.com... > > plain number, grabbing the excel pin list is vital there. > > That is nice if you can get away with it. I often have significant cost > constraints. If you read any of the XCR3256XL thread, you would see an Me too, but maybe not that hard as you. > example where if I blow the IO count issue in my planning, my only > choice at design time is to use a $50 part in the place of a $15 part. > So messing up is not an option. Sure, but this is difting into another problem. The prices for both part are known, ou confirmed, OK, the big one is really expensive. > > Sure, verification is important. But it should not develop into paranoia, > > should'nt it?? ;-)) > > Where do YOU draw the line. I would rather be overly cautious up > front. As they say, "It's only takes ONE 'Oh Damn!' to make up for a I wouldnt be overly cautious. I check a datasheet roughly on the run, when its time to draw some sketches for the design. At this point I decide if it is going to be a rather small or big FPGA, but not the specific family member. If it comes to the decision which part is really to be used, there is at least the pinlist finished to 99%, sometimes even the schematics has been started. Its worthless to check the datasheets over and over again if after all you figure out it has errors anyway. > whole lot of 'Attaboys'... :) > No, that is the point. The FPGA vendors make a lot more mistakes in the > area of IOs, package availability and speed grades than everyone else > combined. I guess there is a lot more flux with programmable parts. So Hmm, there is a lot of movement on the first frontline of FPGAs. Things are changing fast. In such a case, such errors happen. I would not say that the PLD vendors are too lazy or just unable to deliver error free datasheets. But in this case (of PLDs), its even MUCH more important NOT to nail yourself to a specific, brand new device. I allways leave some up/downgrade options for the PLD. This doesnt neccessaryly mean the chip is getting more expensive. Just as Peter Alfke said in a late TechXclusive "Options, Options and Choices". After all, what is all this crying worth? Are going to court with Xilinx? I guess no. And I wouldnt complain too much about the PLD guys. Have you ever worked with Infineon ICs?? . . . . . No comment. -- MfG FalkArticle: 47057
"Ray Andraka" <ray@andraka.com> schrieb im Newsbeitrag news:3D855A81.437CC586@andraka.com... > Much depends on the FPGA device too, if this is a 2000E, the linear regulator is There is no 2000E in the Spartan-IIE family. SCNR -- MfG FalkArticle: 47058
Thanks Austin, I will clean up the jitter for the DAC's clock using an
external PLL.
Cheers,
Javier
"Austin Lesea" <austin.lesea@xilinx.com> wrote in message
news:3D85EE57.E712CBA2@xilinx.com...
> All,
>
> For people interested in cascading CLKFX, please email directly me about
what
> you are tyring to do.
>
> We have not finished characterizing all combinations of two cascaded DCMs,
so I
> can not really comment for the general case here in the newsgroup at this
time
> without knowing details.
>
> In addition to the CLKFX case, there is the CLK0, CLK2X for the first
stage.
> Have got to test absolutely every combination! Oh, and every M and D, and
every
> frequency, over P/V/T, and in the worst SI environment allowed by the data
> sheet.....
>
> Javier's case looks like it will work fine (and I responded to him
directly with
> details), but I have other concerns about driving a DAC with a jittered
clock
> from an application point of view.
>
> Austin
>
>
> Javier Serrano wrote:
>
> > Hi everyone,
> > I'm trying to produce both a 100 MHz and a 200 MHz clocks from a 40 MHz
> > input using the Virtex-II DCM, and I'm a bit worried about the jitter
> > figures from the Virtex-II CLKFX online jitter calculator. The solution
I've
> > chosen so far has two DCMs:
> > - In the first DCM I multiply the 40 MHz by 5/2 to obtain 100 MHz, which
I
> > use both internally in my design and as the input to the second DCM.
> > - In the second DCM I multiply the 100 MHz by two to get 200 MHz.
> > Incidentally, the CLK0 (100 MHz) output of this DCM is used to feed an
> > external DAC and gets back from off-chip to the feedback input of the
DCM.
> > The problem is that, according to the jitter calculator I'll get 760 ps
of
> > p-p jitter (speed grade 4) in the 100 MHz clock coming out of the first
DCM.
> > That is period jitter, and it is within the 1 ns jitter that the second
DCM
> > allows for at its input. However, the Virtex-II handbook also specifies
300
> > ps as the maximum cycle-cycle jitter for the input clock in
low-frequency
> > mode, and I don't know whether my 760 ps of jitter are smoothly varying
or
> > not. Has anyone got experience with this type of problem? Should I be
doing
> > it in some other way?
> > Thanks in advance,
> > Javier
>
Article: 47059Javier, Could you please share with us Austins reply? In my oppinion one PLL in a DAC or ADC clock path is one to many.. jakab Javier Serrano <Javier.Serrano@cern.ch> wrote in message news:am4ut3$s8i$1@sunnews.cern.ch... > Thanks Austin, I will clean up the jitter for the DAC's clock using an > external PLL. > Cheers, > Javier > > "Austin Lesea" <austin.lesea@xilinx.com> wrote in message > news:3D85EE57.E712CBA2@xilinx.com... > > All, > > > > For people interested in cascading CLKFX, please email directly me about > what > > you are tyring to do. > > > > We have not finished characterizing all combinations of two cascaded DCMs, > so I > > can not really comment for the general case here in the newsgroup at this > time > > without knowing details. > > > > In addition to the CLKFX case, there is the CLK0, CLK2X for the first > stage. > > Have got to test absolutely every combination! Oh, and every M and D, and > every > > frequency, over P/V/T, and in the worst SI environment allowed by the data > > sheet..... > > > > Javier's case looks like it will work fine (and I responded to him > directly with > > details), but I have other concerns about driving a DAC with a jittered > clock > > from an application point of view. > > > > Austin > > > > > > Javier Serrano wrote: > > > > > Hi everyone, > > > I'm trying to produce both a 100 MHz and a 200 MHz clocks from a 40 MHz > > > input using the Virtex-II DCM, and I'm a bit worried about the jitter > > > figures from the Virtex-II CLKFX online jitter calculator. The solution > I've > > > chosen so far has two DCMs: > > > - In the first DCM I multiply the 40 MHz by 5/2 to obtain 100 MHz, which > I > > > use both internally in my design and as the input to the second DCM. > > > - In the second DCM I multiply the 100 MHz by two to get 200 MHz. > > > Incidentally, the CLK0 (100 MHz) output of this DCM is used to feed an > > > external DAC and gets back from off-chip to the feedback input of the > DCM. > > > The problem is that, according to the jitter calculator I'll get 760 ps > of > > > p-p jitter (speed grade 4) in the 100 MHz clock coming out of the first > DCM. > > > That is period jitter, and it is within the 1 ns jitter that the second > DCM > > > allows for at its input. However, the Virtex-II handbook also specifies > 300 > > > ps as the maximum cycle-cycle jitter for the input clock in > low-frequency > > > mode, and I don't know whether my 760 ps of jitter are smoothly varying > or > > > not. Has anyone got experience with this type of problem? Should I be > doing > > > it in some other way? > > > Thanks in advance, > > > Javier > > > >Article: 47060
Perhaps someone can commment, why the Virtex II family has no QFP package option. BGA only means much finer PCB design rules, so the NRE costs for the prototype board soar. That there is a CS144 package shows that "low pin count" applications are a target for Virtex II and a QFP240 package would even nearly come close to the FGA256 in pin count. Bye -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 47061
Ray Andraka wrote:
> Boundary scan methods generally can't check interfaces at operating speed, so
> problems with signal integrity or timing are not visible. It is fine for
> continuity tests, but is little more than a bandaid for modern boards if other
> methods are available.
I agree with Ray. If you want to make money manufacturing circuit boards
you can't tolerate any shorts or opens after parts are placed and flowed.
The focus should be on eliminating solder splashes and voids from the
process, not locating them once they happen. Time might be better spent
on bare board testing and conversion to BGA packages.
-- Mike Treseler
Article: 47062
Pete Dudley wrote:
> Hello All,
> for i in 0 to 255 loop
> table(i) <= signed(round(64.0*sin(2*pi*i/256)));
> end loop;
>
> What I'm finding is that XST errors out, saying "Undefined symbol 'real'"
> when I include the math_real library
Leonardo will accept IEEE.MATH_REAL functions but only for
constant definitions between IS and BEGIN.
See the example below.
-- Mike Treseler
-----------------------------
library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;
USE IEEE.MATH_REAL.all;
entity test_math is
end test_math;
architecture sim of test_math
is
constant pi : real := 3.141592;
constant vec_max : real := (2.0)**16;
constant sin_pi_over_8 : natural
:= integer(round(vec_max * sin(2.0*pi/16.0)));
constant u_sin_pi_over_8 : unsigned(15 downto 0)
:= to_unsigned(sin_pi_over_8, 16);
begin
. . .
Article: 47063jakab tanko wrote: > Javier, > > Could you please share with us Austins reply? > In my oppinion one PLL in a DAC or ADC clock path is one to many.. > > jakab To have fewer than one PLL in the DAC or ADC clock path, you need a crsytal oscillator with an output at the DAC/ADC frequency. While this is a nice idea, often it's not practical when the frequency isn't a readily available value. A properly designed PLL can have better jitter characteristics (above the loop filter corner frequency) that are better than the original source; wouldn't this be better? Improperly designed PLLs are bad. A DLL to generate an m/n frequency multiplier followed by a 1:1 cleanup PLL might be less elegant than a simple m/n PLL. Could you share the basis for your opinions? If I'm missing something with respect to system performance degradation, I'd love to know. Thanks, - John_HArticle: 47064
Jakab, I mentioned the use of the: http://www.icst.com/pdf/ics8735-01.pdf or 8745 for LVDS. Tests in the lab show it attenuates the jitter from the DCM by 11X to 15X, usually down to the noise floor of 35 ps P-P. You must follow the data sheet guidelines for layout, etc. PLLs are just fine, you just need to know which ones to use, and when, and how to use them. Austin jakab tanko wrote: > Javier, > > Could you please share with us Austins reply? > In my oppinion one PLL in a DAC or ADC clock path is one to many.. > > jakab > Javier Serrano <Javier.Serrano@cern.ch> wrote in message > news:am4ut3$s8i$1@sunnews.cern.ch... > > Thanks Austin, I will clean up the jitter for the DAC's clock using an > > external PLL. > > Cheers, > > Javier > > > > "Austin Lesea" <austin.lesea@xilinx.com> wrote in message > > news:3D85EE57.E712CBA2@xilinx.com... > > > All, > > > > > > For people interested in cascading CLKFX, please email directly me about > > what > > > you are tyring to do. > > > > > > We have not finished characterizing all combinations of two cascaded > DCMs, > > so I > > > can not really comment for the general case here in the newsgroup at > this > > time > > > without knowing details. > > > > > > In addition to the CLKFX case, there is the CLK0, CLK2X for the first > > stage. > > > Have got to test absolutely every combination! Oh, and every M and D, > and > > every > > > frequency, over P/V/T, and in the worst SI environment allowed by the > data > > > sheet..... > > > > > > Javier's case looks like it will work fine (and I responded to him > > directly with > > > details), but I have other concerns about driving a DAC with a jittered > > clock > > > from an application point of view. > > > > > > Austin > > > > > > > > > Javier Serrano wrote: > > > > > > > Hi everyone, > > > > I'm trying to produce both a 100 MHz and a 200 MHz clocks from a 40 > MHz > > > > input using the Virtex-II DCM, and I'm a bit worried about the jitter > > > > figures from the Virtex-II CLKFX online jitter calculator. The > solution > > I've > > > > chosen so far has two DCMs: > > > > - In the first DCM I multiply the 40 MHz by 5/2 to obtain 100 MHz, > which > > I > > > > use both internally in my design and as the input to the second DCM. > > > > - In the second DCM I multiply the 100 MHz by two to get 200 MHz. > > > > Incidentally, the CLK0 (100 MHz) output of this DCM is used to feed an > > > > external DAC and gets back from off-chip to the feedback input of the > > DCM. > > > > The problem is that, according to the jitter calculator I'll get 760 > ps > > of > > > > p-p jitter (speed grade 4) in the 100 MHz clock coming out of the > first > > DCM. > > > > That is period jitter, and it is within the 1 ns jitter that the > second > > DCM > > > > allows for at its input. However, the Virtex-II handbook also > specifies > > 300 > > > > ps as the maximum cycle-cycle jitter for the input clock in > > low-frequency > > > > mode, and I don't know whether my 760 ps of jitter are smoothly > varying > > or > > > > not. Has anyone got experience with this type of problem? Should I be > > doing > > > > it in some other way? > > > > Thanks in advance, > > > > Javier > > > > > > >Article: 47065
It was basically what he wrote to the newsgroup (please ask him if you want
more details :)). I can only speak for myself and I've decided to have an
external m/d PLL as John_H has suggested in his posting. For our application
we need extremely low jitter, so we will use a very fine tuned analog PLL
instead of trying to clean the clock coming from the Virtex-II DCM. The
output of that PLL will be fanned out both to the Virtex-II and to the DAC.
We have no choice but to put a PLL in the way because we need to multiply
the frequency up from 40 MHz to 100 MHz to feed the DAC.
Cheers,
Javier
"jakab tanko" <jtanko@ics-ltd.com> wrote in message
news:am51ej$iib$1@news.storm.ca...
> Javier,
>
> Could you please share with us Austins reply?
> In my oppinion one PLL in a DAC or ADC clock path is one to many..
>
> jakab
> Javier Serrano <Javier.Serrano@cern.ch> wrote in message
> news:am4ut3$s8i$1@sunnews.cern.ch...
> > Thanks Austin, I will clean up the jitter for the DAC's clock using an
> > external PLL.
> > Cheers,
> > Javier
> >
> > "Austin Lesea" <austin.lesea@xilinx.com> wrote in message
> > news:3D85EE57.E712CBA2@xilinx.com...
> > > All,
> > >
> > > For people interested in cascading CLKFX, please email directly me
about
> > what
> > > you are tyring to do.
> > >
> > > We have not finished characterizing all combinations of two cascaded
> DCMs,
> > so I
> > > can not really comment for the general case here in the newsgroup at
> this
> > time
> > > without knowing details.
> > >
> > > In addition to the CLKFX case, there is the CLK0, CLK2X for the first
> > stage.
> > > Have got to test absolutely every combination! Oh, and every M and D,
> and
> > every
> > > frequency, over P/V/T, and in the worst SI environment allowed by the
> data
> > > sheet.....
> > >
> > > Javier's case looks like it will work fine (and I responded to him
> > directly with
> > > details), but I have other concerns about driving a DAC with a
jittered
> > clock
> > > from an application point of view.
> > >
> > > Austin
> > >
> > >
> > > Javier Serrano wrote:
> > >
> > > > Hi everyone,
> > > > I'm trying to produce both a 100 MHz and a 200 MHz clocks from a 40
> MHz
> > > > input using the Virtex-II DCM, and I'm a bit worried about the
jitter
> > > > figures from the Virtex-II CLKFX online jitter calculator. The
> solution
> > I've
> > > > chosen so far has two DCMs:
> > > > - In the first DCM I multiply the 40 MHz by 5/2 to obtain 100 MHz,
> which
> > I
> > > > use both internally in my design and as the input to the second DCM.
> > > > - In the second DCM I multiply the 100 MHz by two to get 200 MHz.
> > > > Incidentally, the CLK0 (100 MHz) output of this DCM is used to feed
an
> > > > external DAC and gets back from off-chip to the feedback input of
the
> > DCM.
> > > > The problem is that, according to the jitter calculator I'll get 760
> ps
> > of
> > > > p-p jitter (speed grade 4) in the 100 MHz clock coming out of the
> first
> > DCM.
> > > > That is period jitter, and it is within the 1 ns jitter that the
> second
> > DCM
> > > > allows for at its input. However, the Virtex-II handbook also
> specifies
> > 300
> > > > ps as the maximum cycle-cycle jitter for the input clock in
> > low-frequency
> > > > mode, and I don't know whether my 760 ps of jitter are smoothly
> varying
> > or
> > > > not. Has anyone got experience with this type of problem? Should I
be
> > doing
> > > > it in some other way?
> > > > Thanks in advance,
> > > > Javier
> > >
> >
> >
>
>
Article: 47066Uwe, The problem with lead frame packages is that they have about the worst possible signal integrity (SI). What this means is that switching noise, ground bounce, jitter, etc. all balloon out of control. As clock speeds increase, all of these SI effects become more and more severe, and lead frame packages become unusable. The Spatan line will stay with lead frame packages in their lowest cost devices, but you will have to live with lower preformance than what is availble in the better packages in the Spartan line, or the products in the Virtex families. Austin Uwe Bonnes wrote: > Perhaps someone can commment, why the Virtex II family has no QFP package > option. BGA only means much finer PCB design rules, so the NRE costs for the > prototype board soar. That there is a CS144 package shows that "low pin > count" applications are a target for Virtex II and a QFP240 package would > even nearly come close to the FGA256 in pin count. > > Bye > -- > Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de > > Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt > --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 47067
Uwe Bonnes wrote: > > Perhaps someone can commment, why the Virtex II family has no QFP package > option. BGA only means much finer PCB design rules, so the NRE costs for the > prototype board soar. That there is a CS144 package shows that "low pin > count" applications are a target for Virtex II and a QFP240 package would > even nearly come close to the FGA256 in pin count. I was missing them also. Something like a CS144 or QFP208. For now, I have to stay at SpartanIIe, but the multiplier would be nice ;-) cheersArticle: 47068
On Mon, 16 Sep 2002 10:45:52 -0700, Austin Lesea wrote:
>jakab tanko wrote:
>> In my oppinion one PLL in a DAC or ADC clock path is one to many..
>
>Tests in the lab show it attenuates the jitter from the DCM by 11X to 15X,
>usually down to the noise floor of 35 ps P-P.
>PLLs are just fine, you just need to know which ones to use, and when, and how
>to use them.
Quoting from the data sheet for an M-tron UVVJ Series LVPECL/LVDS
Compatible Low Jitter VCXO, for f0 in the range 20 MHz to 175 MHz:
Phase jitter 0.35 typical/1.0 Max ps RMS Integrated 12 kHz - 20 MHz
0.35 ps RMS would, in engineering practice, normally be translated to
about 2.8 ps P-P. Many other manufacturers have similar parts/specs.
'nuff said.
- Larry
Article: 47069
On Mon, 16 Sep 2002 16:43:17 +0000 (UTC), Uwe Bonnes wrote:
>Perhaps someone can commment, why the Virtex II family has no QFP package
>option. BGA only means much finer PCB design rules, so the NRE costs for the
>prototype board soar. That there is a CS144 package shows that "low pin
>count" applications are a target for Virtex II and a QFP240 package would
>even nearly come close to the FGA256 in pin count.
It's Xilinx's way of weeding out the low-budget amateurs. The big
players don't mind spending many thousands of dollars to prototype
a board. The cost of the prototyping effort, when amortized over
thousands of units, is irrelevant, as long as it can be done quickly.
As a card-carrying member of the low-budget amateur club, of course,
this frustrates me.
- Larry
Article: 47070Austin Lesea <austin.lesea@xilinx.com> wrote: : Uwe, : The problem with lead frame packages is that they have about the worst : possible signal integrity (SI). What this means is that switching noise, : ground bounce, jitter, etc. all balloon out of control. As clock speeds : increase, all of these SI effects become more and more severe, and lead : frame packages become unusable. Then what about packaging the smaller Virtex II chips in BGA (1.27 mm pitch) packages, with a PCB friendly pinout : only outer two row and easily accessible pin in the innerest row carry signals that need to brought out, other pins are either NC or IO pins that may be traded off for relaxed PCB design rules. ... -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 47071
Uwe Bonnes wrote: > > Austin Lesea <austin.lesea@xilinx.com> wrote: > : Uwe, > > : The problem with lead frame packages is that they have about the worst > : possible signal integrity (SI). What this means is that switching noise, > : ground bounce, jitter, etc. all balloon out of control. As clock speeds > : increase, all of these SI effects become more and more severe, and lead > : frame packages become unusable. > > Then what about packaging the smaller Virtex II chips in BGA (1.27 mm pitch) > packages, with a PCB friendly pinout : only outer two row and easily > accessible pin in the innerest row carry signals that need to brought out, > other pins are either NC or IO pins that may be traded off for relaxed PCB > design rules. How about the new QFN packages ? - these must cover the middle ground : Excellant thermal, and ground performance, but maybe a tad down on Vcc performamce. BGA packages do seem to transfer the problems/costs to the user :) -jgArticle: 47072
Hello ALL I have a 50MHz clock that I want to divide by 10 and then by 10 and so on. Actual outputs required are 50MHz 5MHz 500KHz 50KHz 5KHz 500Hz 50Hz I think I could do a divide by 10 but I dont know how to achieve all these divides. I also wonder if I can have the main clock driving all flip flops together rather than have the MSB output of the first divide by 10 rippeling through to the next counter and so on. Im coding in Verilog so any suggestions there would help. Thanks DenisArticle: 47073
True enough. I missed the "Spartan" in the header. A linear regulator
is probably fine for the entier SpartanIIE line. It is a problem for
bigger virtexE devices.
Falk Brunner wrote:
> "Ray Andraka" <ray@andraka.com> schrieb im Newsbeitrag
> news:3D855A81.437CC586@andraka.com...
> > Much depends on the FPGA device too, if this is a 2000E, the linear
> regulator is
>
> There is no 2000E in the Spartan-IIE family.
> SCNR
>
> --
> MfG
> Falk
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 47074
I think synplicity does now too. My point is I'd like to see it in the LRM so
that the code can be made portable between tools.
Mike Treseler wrote:
> Pete Dudley wrote:
>
> > Hello All,
>
> > for i in 0 to 255 loop
> > table(i) <= signed(round(64.0*sin(2*pi*i/256)));
> > end loop;
> >
> > What I'm finding is that XST errors out, saying "Undefined symbol 'real'"
> > when I include the math_real library
>
> Leonardo will accept IEEE.MATH_REAL functions but only for
> constant definitions between IS and BEGIN.
> See the example below.
>
> -- Mike Treseler
>
> -----------------------------
>
> library ieee;
> use ieee.std_logic_1164.all;
> use ieee.numeric_std.all;
> USE IEEE.MATH_REAL.all;
>
> entity test_math is
> end test_math;
>
> architecture sim of test_math
> is
>
> constant pi : real := 3.141592;
> constant vec_max : real := (2.0)**16;
> constant sin_pi_over_8 : natural
> := integer(round(vec_max * sin(2.0*pi/16.0)));
> constant u_sin_pi_over_8 : unsigned(15 downto 0)
> := to_unsigned(sin_pi_over_8, 16);
>
> begin
> . . .
--
--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