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
Yim wrote: > What about Altium's Nexar (http://www.altium.com/nexar/evaluation/?vc=1612) Nexar's price tag is not really targetted to beginners, I guess. Rene -- Ing.Buero R.Tschaggelar - http://www.ibrtses.com & commercial newsgroups - http://www.talkto.netArticle: 80376
Glen, As Howard said in this presentation, inductance is not a property of the wire, it is a property of the wires in space. Austin glen herrmannsfeldt wrote: > Bob wrote: > (snip) > >> His description of how most of the intra-package crosstalk is due to >> magnetic coupling, and not merely the voltage deltas caused by di/dt >> through >> a particular L nor capacitive coupling due to dv/dt, was quite a >> surprise. >> The demonstration of the relative directions of the voltage swings >> (between >> aggressor and victim) made this very clear and convincing. > > > Well, L di/dt is magnetic, both self inductance and mutual inductance > depend on the geometry of the system. > > -- glen >Article: 80377
I was in "Embedded World 2005" in Nürnberg last week and the Nexar representative told me that they sell some eval board for 99? only (with the choice between Xilinx or Altera). These boards looked really convenient to get in touch with FPGA. Bye "Rene Tschaggelar" <none@none.net> schrieb im Newsbeitrag news:42289d44$0$3402$5402220f@news.sunrise.ch... > Yim wrote: > >> What about Altium's Nexar >> (http://www.altium.com/nexar/evaluation/?vc=1612) > > Nexar's price tag is not really targetted to beginners, > I guess. > > Rene > -- > Ing.Buero R.Tschaggelar - http://www.ibrtses.com > & commercial newsgroups - http://www.talkto.netArticle: 80378
Peter Alfke wrote: > You should start with an evaluation board for one of the low-cost FPGA > lines. > Xilinx offers the Spartan-3 family, with evaluation boards from Xilinx > or the distributors. Many of them are below $ 150. > For your internal microprocessor I recommend the Xilinx PicoBlaze. > It is free (!), and it is simple, and allows you to do the control jobs > you mentioned. > No opeating system, no C compiler, but direct access to the hardware. > It uses about 200 LUTs/flip-flops plus a BlockRAM. Real tiny, and real > popular. Google it... Very interesting. ReneArticle: 80379
The eval board with a FPGA. Plus the Nanoboard to plug it in for 995Euro plus the Software for 7995Euro. Rene Mouarf wrote: > I was in "Embedded World 2005" in N=FCrnberg last week and the Nexar=20 > representative told me that they sell some eval board for 99? only (wit= h the=20 > choice between Xilinx or Altera). These boards looked really convenient= to=20 > get in touch with FPGA. >=20 > Bye >=20 >=20 > "Rene Tschaggelar" <none@none.net> schrieb im Newsbeitrag=20 > news:42289d44$0$3402$5402220f@news.sunrise.ch... >=20 >>Yim wrote: >> >> >>>What about Altium's Nexar=20 >>>(http://www.altium.com/nexar/evaluation/?vc=3D1612) >> >>Nexar's price tag is not really targetted to beginners, >>I guess.Article: 80380
On Fri, 04 Mar 2005 10:09:15 +0100, Jens Baumann <annonce05_nospam@web.de> wrote: >You are not the first to suggest a bigger FPGA. Since I'm new to FPGA >development, I'm not sure, how many gates are necesseary. >What kind of device did you build, which did not fit into an S3-200? >How many gates would the Microblaze require, just as an example? I'd say 99% of the S3-200 :-( But there are PicoBlaze , and its free. I'd definately go for the S3-1000 if i should buy now CarstenArticle: 80381
Further, I think what Glen and I are both trying to say (and not saying it as well as Howard already did) is that when you have a magnetic field in space (as in 3 dimensions), caused by an arrangement of wires carrying a current (a completed circuit path), you are storing energy in the magnetic field. This ability to store energu in a magnetic field is what we conveniently model (to a first order) with a parameter called "inductance." It can be simplified to be an attribute of one of the elements in the circuit, if and only if the magentic field is completely enclosed in that one element. Since that is case with a coil inside a magnetic core material to a first order approximation, or a wire wound coil, we are comfortable with using inductance this way. But for a single wire in space, the concept has no meaning, until the circuit path is completed. Only then from the geometry can you solve for the magnetic field geometry, and assign (or ascribe) and "inductance" to the entire circuit path (loop). Varying the spacing of the wire path, will vary the "inductance." Basically, the smaller the loop (circuit path), the smaller the "inductance." Sorry for using so many words, but I think I have said it as clearly and as exactly as I can, Austin Austin Lesea wrote: > Glen, > > As Howard said in this presentation, inductance is not a property of the > wire, it is a property of the wires in space. > > Austin > > glen herrmannsfeldt wrote: > >> Bob wrote: >> (snip) >> >>> His description of how most of the intra-package crosstalk is due to >>> magnetic coupling, and not merely the voltage deltas caused by di/dt >>> through >>> a particular L nor capacitive coupling due to dv/dt, was quite a >>> surprise. >>> The demonstration of the relative directions of the voltage swings >>> (between >>> aggressor and victim) made this very clear and convincing. >> >> >> >> Well, L di/dt is magnetic, both self inductance and mutual inductance >> depend on the geometry of the system. >> >> -- glen >>Article: 80382
I will try every methods. Many Thanks to everyone!Article: 80383
yes, sorry for mistake... and if abc is std_logic_vector(0 to 2) ?Article: 80384
Eval board work fine wich ISE. usmgn "Rene Tschaggelar" <none@none.net> a écrit dans le message de news: 4228a10f$0$3402$5402220f@news.sunrise.ch... The eval board with a FPGA. Plus the Nanoboard to plug it in for 995Euro plus the Software for 7995Euro. Rene Mouarf wrote: > I was in "Embedded World 2005" in Nürnberg last week and the Nexar > representative told me that they sell some eval board for 99? only (with > the choice between Xilinx or Altera). These boards looked really > convenient to get in touch with FPGA. > > Bye > > > "Rene Tschaggelar" <none@none.net> schrieb im Newsbeitrag > news:42289d44$0$3402$5402220f@news.sunrise.ch... > >>Yim wrote: >> >> >>>What about Altium's Nexar >>>(http://www.altium.com/nexar/evaluation/?vc=1612) >> >>Nexar's price tag is not really targetted to beginners, >>I guess.Article: 80385
Marco wrote:
> yes, sorry for mistake... and if abc is std_logic_vector(0 to 2) ?
Same thing. 000 to 001.
Vectors always read left to right,
without regard to the index limits
or sequence.
-- Mike Treseler
Article: 80386Mike Treseler wrote: > Marco wrote: > >> yes, sorry for mistake... and if abc is std_logic_vector(0 to 2) ? > > > Same thing. 000 to 001. > > Vectors always read left to right, > without regard to the index limits > or sequence. And, at least in verilog, if you assign x[9:0] to y[0:9] they still go left to right. To reverse the bit order requires explicitly listing all the bits. -- glenArticle: 80387
On 3 Mar 2005 14:42:47 -0800, "Gabor" <gabor@alacron.com> wrote: > >Falk Brunner wrote: >> "Richard Thompson" <nospam@nospam.com> schrieb im Newsbeitrag >> news:sqva219fvdhe8j9omvmpknfl2kl7ijrvkl@4ax.com... >> >> > >After all, what is a RS-FF good for nowadays?? >> > >> > The same things that it has always been good for. For a cost of 2 >> > gates, it gives you a memory. It doesn't need a clock. It remembers >an >> > event until you have time to deal with it. It's ideal for >handshaking, >> > and for communicating between different clock domains. Can you name >> > any other digital circuit which is so versatile, at such a small >cost? >> > Even if you ignore the 'cost', as you might do in an FPGA >> > implementation? >> >> Uhhh? COST??? C'mon. In a FPGA, a handfull of Flipflops is always >free. So >> why asking for trouble and doing stone age handshakes when there are >proven >> solutions using standard methods (here, D-FlipFlops)? I wouldnt waste >a >> nanosecond thinking of RS-FlipFlops made of gates. > >Speaking of cost, is a LUT less costly than a flip-flop? In Xilinx >Virtex parts, a LUT can be 16 flip-flops sometimes. Besides if you >want both gate outputs from your cross-coupled NAND gates you need >2 LUTs. >Another thing to wonder about, is whether changing a single >LUT input creates the same output transition as with the implemented >gates. For example if the output is the same for both states of the >switched input, a gate will never glitch, but will the LUT glitch? >This may depend on the implementation of the output multiplexer. An interesting point, which has come up on various occasions over the years; I recall Peter Alfke posting on this occasionally. The answer (at least pre-Virtex, I don't know if it has changed recently) is that you dont get a glitch when changing one input on a LUT (or so Xilinx claims). The mux is a break-before-make, but the circuit ensures that you only switch between two flops, and the stray capacitance holds the old value. This thread has (from my point of view, anyway) degenerated somewhat. My concern was getting trce to report an asynchronous path through a latch, of unspecified, or any, design. I pointed out what an RS F/F was, simply because it doesn't seem to be general knowledge any more. Its simplest representation is two cross-coupled gates, but most of us know that you can implement it in several other ways. The VHDL/Verilog code that I use synthesises to a flop, as you suggested, and as would be expected; no synth is going to produce cross-coupled gates. My post led to an irrelevant series of other posts (not from yourself) suggesting that R/S latches are of no use and obsolete and, by implication, that I don't know what I'm doing. On the issue of cost, perhaps those who think that that an R/S is obsolete should try designing a two-way handshake between two clock domains, and then report back on the relative cost of the two approaches, taking into account total resource usage, and design and verification time. RickArticle: 80388
Thanx Again The black burst generator is both NTSC and PAL compliant... I am locking the Hsync using a PLL (external to the fpga) using a 1715 x fh = twice 858 x fh ...which u were talking abt.. I cant get the Hsnyn without jitter. What do u mean by source? The output from the PLL (which is clock of frequency 1715 x fh = 27 MHz) is then given to the FPGA. The FPGA does the Black burst generation...also does the subcarrier locking..where it has two modes of operation. One when the extrenal is given...where the Black burst generated locks to the external reference and the second when no external is given...in this case....it acts as a free running black burst generator. The PDF document looks really good and will be of great help. Let me know if u need any more details...Article: 80389
"genlock" <genlocks@gmail.com> schrieb im Newsbeitrag news:1109954872.112005.262490@z14g2000cwz.googlegroups.com... > Thanks...Well, right now...everything is working with the whole PLL > function being done inside the FPGA itself.....but then there is a > jitter in the output.....and am not able to figure out the reason.... How much jitter? 1ns? 1us? Whats the output frequency of the VCO? Whats the compare frequency of the phase detetor? Regards FalkArticle: 80390
<Marco> schrieb im Newsbeitrag news:ee8c67f.1@webx.sUN8CHnE... > Mhhhh... there is a little trouble. > > This clock must drive an LCD which has a timing fixed between: 1,535508 Mhz and 1,344537 MHz. Hmm, sound not too demanding. Just divide the 50 Mhz by 33 and get 1,51 MHz. Thats it. If you need exact 50% duty cylce, divide by 34 (yielding in 1,47 MHZ) Regards FalkArticle: 80391
"Richard Thompson" <nospam@nospam.com> schrieb im Newsbeitrag news:3idh21dutep5f6m0da6tasscrurn0icak8@4ax.com... > On the issue of cost, perhaps those who think that that an R/S is > obsolete should try designing a two-way handshake between two clock > domains, and then report back on the relative cost of the two > approaches, taking into account total resource usage, and design and > verification time. ;-)) Trying to reinvent the wheel? I hope you have a VERY good idea whow to make it rounder. I guess the problem is, that many engineers think the could build clever handshake cicuits for asynchronous interfaces by having a flashy idea and lots of homebrew circuits from the good old TTL era in the head. This approach fail often enough, I guess. Dont get me wrong, I dont say you cant design such a circuit (I dont know, maybe maybe not), but Iam afraid there are lots of asynchronous wanna-bees. So again, why reinventing the wheel? In a FPGA, you have the same amount of FF as LUTs. No gain in using RS-FFs made by cross coupled NANDs. This is even more true for CPLDs, I guess it takes two macrocells to make a RS-FF out of logic (and works maybe only be using WYSIWYG switch ON). Again, no saving. And there are proven, small circuit for such handshaking using standard, supported design methods. Again, what do you gain, except the outlaw-feeling ?? ;-) Regards FalkArticle: 80392
"Kolja Sulimma" <news@sulimma.de> schrieb im Newsbeitrag news:42289c1a$0$26545$9b4e6d93@newsread4.arcor-online.net... > Eric Smith wrote: > > hmurray@suespammers.org (Hal Murray) writes: > >>I think older non-LDO type linear regulators are easier to work with. > >>But they often don't go down to 1.2V. > > > Even LDOs that go to 1.2V are fairly uncommon. > > But 1.25V are extremly common. They call it "adjustable" ;-) Yeah, but what about tolerances? The 1,25V reference of the good ole LM317 ist exactly 1,25V. Are the tolerances within the +/-5 % of the 1,2V for the core? Regards FalkArticle: 80393
Duane Clark wrote: > ivan wrote: > > could you acheive 100Mbps bandwidth ? > > Using the Avnet board with the Avnet bitfile and Linux, the sustained > bandwidth that I was able to achieve was less than 2MB/s. In addition to > using the OPB_EMAC core instead of the PLB_EMAC core, the Avnet bitfile > also runs Linux out of external SDRAM memory connected via the OPB bus. > So I don't know which is the bottleneck, but I would guess the memory is > probably the bigger factor. I will probably be doing some tests soon to > try to find the source of the problem. > > > junkmail@fastertechnology.com wrote: > > > >>ivan wrote: > >> > >>>Hi, > >>> > >>>Did anybody work on OPB_EMAC xilinx core at 100mbps with PPC405.How > >>>did you develop drivers for that?Please let me know. > >>>Thanks & Regards, > >>>Ivan > >> > >>I have an Avnet development board with a V2P20 on it. It came with a > >>reference design that has Linux running on the PPC, and uses the > >>OBP_EMAC core to talk to a PHY on the development board. The demo > >>include a simple web sever, and it works. > >> > >>The Linux distribution came from www.denx.de and has an old version > > > > of > > > >>a driver for the Xilinx EMAC core. The driver was written by > >>MontaVista. > >> > >>There is a newer version of the driver available in the bitkeeper > >>repository for the PPC version of the kernel. Look at > >>www.klingauf.com/v2p/index.phtml for information on how to get the > >>kernel, and other good info. > >>Also check out www.penguinppc.org > >> > >>John McCaskill > > > > > > > -- > My real email is akamail.com@dclark (or something like that). We have not measured the speed of the 10/100 EMAC. There are a number of reasons to support the slower speeds that Duane Clark mentioned: The EMAC core is on the OPB bus, and does not use the DMA engine in the IPIF. The processor has to copy the data between the core and memory. As the reference design is supplied, the PPC is only configured to run at 66MHz. The memory used in the reference design is on the OPB bus. The OPB bus has burst mode turned off. (At first glance, it does not look like the OPB memory interface works with burst mode turned on). My guess is that the OPB EMAC was used because a real version of the core is supplied with the EDK. All of the PLB EMAC cores are evaluation versions. You can use them in a design, but they turn themselves off after about 12 hours. John McCaskillArticle: 80394
I wrote: > Even LDOs that go to 1.2V are fairly uncommon. Kolja Sulimma <news@sulimma.de> writes: > But 1.25V are extremly common. They call it "adjustable" ;-) Yes, but for most of them 1.25V is the maximum spec for the reference voltage, so they're not guaranteeed to be adjustable below that. Since 1.26V is the maximum Vint for Spartan 3, that's cutting it too close. Better to use a regulator for which 1.2V is actually within the rated specifications.Article: 80395
On Fri, 4 Mar 2005 21:49:25 +0100, "Falk Brunner" <Falk.Brunner@gmx.de> wrote: >I guess the problem is, that many engineers think the could build clever >handshake cicuits for asynchronous interfaces by having a flashy idea and >lots of homebrew circuits from the good old TTL era in the head. This >approach fail often enough, I guess. Dont get me wrong, I dont say you cant >design such a circuit (I dont know, maybe maybe not), but Iam afraid there >are lots of asynchronous wanna-bees. I'm not quite sure what point you're making, or what you think it is I actually wrote. But, since you're so smart, can you tell me whether a D F/F is a synchronous or an asynchronous device? RickArticle: 80396
Since I was quoted: Yes, the old explanation still holds true: If you change one LUT input, and the output before and after that change is the same, then there will be no glich (ever). More generally, even when you change more than one input, but the output for all permutations of these inputs is the same, there can be no glitch. That's guaranteed by the way the multiplexers in the LUT are designed. Peter Alfke, Xilinx ApplicationsArticle: 80397
"Richard Thompson" <nospam@nospam.com> schrieb im Newsbeitrag news:gilh215nt803qhem3fq9jqel7fnsod3g59@4ax.com... > I'm not quite sure what point you're making, or what you think it is I > actually wrote. But, since you're so smart, can you tell me whether a I got your statement the way, that there are still a need and use for RS-Flipflops made of NANDS in FPGAs. I dont think so. And I gave explainations. > D F/F is a synchronous or an asynchronous device? ;-) Asynchronous, but well defined. But this doest mean that you should created more asynchronous stuff. Regards FalkArticle: 80398
junkmail@fastertechnology.com wrote: > > We have not measured the speed of the 10/100 EMAC. There are a number > of reasons to support the slower speeds that Duane Clark mentioned: > > The EMAC core is on the OPB bus, and does not use the DMA engine in the > IPIF. The processor has to copy the data between the core and memory. > As the reference design is supplied, the PPC is only configured to run > at 66MHz. > The memory used in the reference design is on the OPB bus. > The OPB bus has burst mode turned off. (At first glance, it does not > look like the OPB memory interface works with burst mode turned on). So you chose anonymity, I can only guess that you have some relation to the Avnet board/project from your comments. In any case, I will add a comment that the board and project as provided by Avnet are quite impressive in my opinion. And at the price, they simply cannot be beat. > > My guess is that the OPB EMAC was used because a real version of the > core is supplied with the EDK. All of the PLB EMAC cores are evaluation > versions. You can use them in a design, but they turn themselves off > after about 12 hours. > Actually, the OPB_EMAC core supplied with EDK is also an evaluation version, with the same timeout limitation. -- My real email is akamail.com@dclark (or something like that).Article: 80399
Richard Thompson wrote: (snip) > I'm not quite sure what point you're making, or what you think it is I > actually wrote. But, since you're so smart, can you tell me whether a > D F/F is a synchronous or an asynchronous device? I would say it isn't the device, but how you use it. You can make ripple counters or synchronous counters our of DFFs, and with a two-phase clock, synchronous logic our of RS flip-flops. Does anyone remember when two phase clocks were popular any more? (I believe the TMS9900 even has a four phase clock.) -- glen
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