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
Haven't had any problems using Crosstool: http://kegel.com/crosstool/ Very easy to setup as well. Paul "tony.p.lee@gmail.com" wrote: > > You can rsync the ppc linux source from > rsync://source.mvista.com/linuxppc-2.4 > > But setting up the ppc gcc cross compiler correctly for linux kernel is > not a trivial task. > > -TonyArticle: 96351
Frank wrote: > I put these conditions in different always and if-else-if statements, will > design compiler & ISE be smart enough to recognise them and reduce > hardware cost accordingly? > There's an option in many synthesizers called "resource sharing" that will optimize for space if logic like these are found, but I think the default is to treat them as seperate blocks. Why bother with optimizations like this? IMO these should be the least to worry about. > but if synthesizers handles these, then it will save me some thinking. Do save yourself some thinking like this, let the synthesis tools worry about optimization.Article: 96352
Actually, someone needs to find an old 1702 (??) eprom, one of the original Intel 1 Kbit parts that was UV erasable. How big was the die on that "mega-part"? Which current Xilinx die takes the same area. One Xilinx BRAM has more capacity than the entire 1702. Of course, I'm comparing ram vs rom here. As I recall, the programming voltages were amazing. Pull this to 70V, pull that to minus something. Pray that the power transistors on the programmer don't blow out again. Gasp, I'm dating myself! John ProvidenzaArticle: 96353
Pradnya, you must learn to read a data sheet. For 9536 it says: recommended Operating Conditions VIH High Level Input Voltage max Vccint + 0.5 V where Vccint = 4.75 to 5.25 V. That tells you that you can connect the input to Vccint. If you like to put a resistor in series, that resistor does not add to the power consumption. Peter AlfkeArticle: 96354
Yes, and the first computers used two triode vaccuum tubes to store a bit, with a supply voltage around 150 V. 60 years of Progress ! Peter AlfkeArticle: 96355
Have a look at XAPP765 (http://www.xilinx.com/bvdocs/appnotes/xapp765.pdf). It is written for an older EDK version but the principles of operation are still the same. - Peter Anonymous wrote: > I have an evm on order, but is there a place I can download the PPC linux > for Virtex-4? I want to make sure I can build it okay. > > Thanks, > Clark > >Article: 96356
johnp wrote: > Actually, someone needs to find an old 1702 (??) eprom, one of the > original > Intel 1 Kbit parts that was UV erasable. How big was the die on that > "mega-part"? Which current Xilinx die takes the same area. > > One Xilinx BRAM has more capacity than the entire 1702. Of course, I'm > comparing ram vs rom here. > > As I recall, the programming voltages were amazing. Pull > this to 70V, pull that to minus something. Pray that the power > transistors > on the programmer don't blow out again. Gasp, I'm dating myself! > > John Providenza > I was just admiring the pretty white and gold package on a 1702A I came across in one of my old project junk boxes last week. Those were pretty parts. I don't miss the programming though. I don't recall 70v, I think it was more like -48v and that needed to switch from 0 to -48 for the programming pulse, and there was also a substrate voltage of something like -40v, that also had to be pulsed. The data and address also had big voltages on them, I don't recall if they were -40 or -48v. Even reading this was a bit of a pain because it needed a bias voltage of --9v. Still, they were very pretty chips to look at. BTW, the die looks to be about 3/8" square.Article: 96357
I'm confused. I thought the xilinx linux was open source? Is monte vista the only place to get the source? "Peter Ryser" <peter.ryser@xilinx.com> wrote in message news:drteng$8a31@cliff.xsj.xilinx.com... > Have a look at XAPP765 > (http://www.xilinx.com/bvdocs/appnotes/xapp765.pdf). It is written for > an older EDK version but the principles of operation are still the same. > > - Peter > > > Anonymous wrote: > > I have an evm on order, but is there a place I can download the PPC linux > > for Virtex-4? I want to make sure I can build it okay. > > > > Thanks, > > Clark > > > > >Article: 96358
mvista is rsync site is just mirror of the public linux kernel site. You don't need to pay monte vista to use it. It is not the only place to get it. -TonyArticle: 96359
sandi wrote:
> Please let me know - what is the advantage of fully specifying don't
> care conditions?
Your code will be easier to modify and test.
-- Mike Treseler
Article: 96360johnp wrote: > Actually, someone needs to find an old 1702 (??) eprom, one of the > original <snip> Gasp, I'm dating myself! So, is that 1702 the part number, or the date code ? ;) -jgArticle: 96361
"Jim Granville" <no.spam@designtools.co.nz> schrieb im Newsbeitrag news:43e25419$1@clear.net.nz... > johnp wrote: > >> Actually, someone needs to find an old 1702 (??) eprom, one of the >> original > <snip> Gasp, I'm dating myself! > > So, is that 1702 the part number, or the date code ? ;) > > -jg > Jim, 1702 is a part number, but I would think you know that? or are you really younger than I ? AnttiArticle: 96362
So the process is really: 1. get PPC cross compiler 2. get kernel source from kernel.org 3. generate board support packages from fpga design 4. build kernel 5. build ace file and boot So the magic is all in the BSP stuff which I assume is basically the BIOS code in a regular PC and the libraries/memory spaces for the various peripherals? Monte Vista is just making it easier for folks by packaging everything in one place? How does the kernel source know that I'm building for a PPC target? Thanks, Clark <tony.p.lee@gmail.com> wrote in message news:1138904088.604673.26180@g47g2000cwa.googlegroups.com... > > mvista is rsync site is just mirror of the public linux kernel site. > You don't need to pay monte vista to use it. > > It is not the only place to get it. > > -Tony >Article: 96363
Colin, You are making a classic mistake: not much DC current flows either. The static magnetic field will force the static electric field to be confined to the area adjacent to the current flow in the opposite direction. This is not skin effect (where current flows on the surface at high frequencies), but a very simple EM rule, that is completely ignored! Use of any 2&1/2 D or 3D (Ansoft) modeling tool shows this. The most famous (and true) story of this was with the SF Bay Area Rapid Transit System (BART), in ~1974 or was it 1975?: The design had a third rail, on the left of the train (from front of train point of view) carrying 1000V DC for the train. The return was the two rails. Obviously(?) the Westinghouse engineers reasoned that the return current would be equally divided among the two rails. 1/2 on right rail, 1/2 on left rail. They designed a "train in block" detector to show where they had trains that detected when the two currents were balanced. Day 1, they turn it on, and everywhere there is NO train, the light is ON (giant status board in Richmond, Ca). Everywhere there !is! a train, the light is OFF! Westinghouse, Xerox (who did the computers?), and a host of consultants descend on UC Berkeley to ask the E&M Professors "what the h***?" As they (professors) laughed and laughed, they asked the grad and senior students to figure it out with (for) the commercial engineers. So, we all sat down, sharpened our pencils, got out our sliderules and textbooks, solved it, and voila! 2/3 in the left rail (nearest to the supply) and 1/3 on the right rail (furthest). Austin colin wrote: > Austin > > This all suggests that I can have an outer ring of vias in the center > of a device (next to every "outer" gnd ball) and a copper pour on the > top layer connecting the rest of the gnd balls with a few vias. I can > then easily put some bulk decoupling right in the center of the bga as > it is no longer peppered with vias. If this is the case then you have > my thanks for pointing this out. > > By the way, you say no current flows on the inner balls but surely they > carry their share of the DC current? > > Regards > > Colin >Article: 96364
johnp wrote:
> Actually, someone needs to find an old 1702 (??) eprom, one of the
> original
> Intel 1 Kbit parts that was UV erasable.
here's a few:
http://www.virtualaltair.com/virtualaltair.com/vac_altair_turnkey_module.asp
-- Mike Treseler
Article: 96365You should probably connect it through a pull-up resistor for safety. What happens if you accidentally drive that pin to '0'? You would blow up the output transistor! Of course if you say that it is an input pin then it shouldn't matter, but it's still safer to go through a resistor. Just make sure you choose the resistor value according to how much current that pin can handle. Cheers ErnieArticle: 96366
Mike Treseler wrote: > johnp wrote: > >> Actually, someone needs to find an old 1702 (??) eprom, one of the >> original >> Intel 1 Kbit parts that was UV erasable. > > > here's a few: > http://www.virtualaltair.com/virtualaltair.com/vac_altair_turnkey_module.asp > > > -- Mike Treseler Actually, the 1702A was a 2K bit part, organized as a 256x8. Here's a data sheet http://www.jmargolin.com/patents/1702a.pdf Mike, the ones in your pictures sure aren't as pretty as the one I was looking at the other day. Mine is in the white cermic package with the gold pins and gold around the window. There is one like it on the board in your first picture in the middle of the 3 PROMs there.Article: 96367
Mike Treseler wrote:
> johnp wrote:
> > Actually, someone needs to find an old 1702 (??) eprom, one of the
> > original
> > Intel 1 Kbit parts that was UV erasable.
>
> here's a few:
> http://www.virtualaltair.com/virtualaltair.com/vac_altair_turnkey_module.asp
That shows RAMs and ROMs, but I didn't see any shots of EPROMs, at
least with the window uncovered to allow us to dimension the die.
There are a few shots of some 1702s here though:
http://web.archive.org/web/20050309071426/http://www.vintagemicrochips.com/1702.pdf
Using the 100 mill pin pitch for scaling, I'm getting a die size of
about .14 x .11 inches, which gives an area just under 10 square
millimeters.
--
Later,
Jerry.
Article: 96368Ray Andraka ha scritto: > Sean Durkin wrote: > >> Marco T. wrote on 01.02.2006 09:56: >> >>> Do you know a all-in-one port replicator with usb, serial and ps/2 >>> connectors that works with Parallel Cable IV? >> >> >> Haven't been able to find one of those either... The problem seems to be >> that iMPACT/Chipscope don't recognize the "virtual" LPT-ports those port >> replicators usually provide... >> There are parallel-port-controllers for Cardbus/PCMCIA you can plug in >> to get a "real" parallel port on your laptop, but I haven't tried any of >> those, so I can't comment on how good they are. >> The problem is the chipset: to get decent programming speeds, the >> parallel port should support 2MHz or 5MHz operation. All >> PCI-plugin-cards I've seen in stores lately use the same cheap >> controller-chip that doesn't support operation above 1MHz, so the cable >> will work in compatibility mode and drop down to 200kHz. >> >> Instead, I suggest buying a Platform USB cable. Gives you much less >> trouble in the long run, and works well on every modern machine. >> ... if you can afford it, that is. I think it's $150, so about double >> what the parallel cable costs. Plus, I'm not sure if it works under >> Linux, but there have been discussions about that here lately. >> >> cu, >> Sean > > > If you are programming through the JTAG interface, you could try the > Diligent USB-JTAG cable which is under $40. is Diligent USB-JTAG cable compatible with Impact? or it is necessary to use another software?Article: 96369
Allan Herriman wrote: > On Wed, 01 Feb 2006 11:27:40 -0800, John Larkin > <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote: [... snip ...] > I don't have the datasheet in front of me, but I believe that Xilinx > do not guarantee a minimum pullup current, merely that the pin will be > pulled up if it has no external load. Beginning with the Spartan-3 FPGA family, Xilinx started specifying the pull-up and pull-down currents in the data sheet. For Spartan-3 FPGAs, take a look at Table 6 on PDF page 55 in the Spartan-3 Data Sheet link shown below. http://www.xilinx.com/bvdocs/publications/ds312.pdf The pull-up and pull-down resistors in Spartan-3 are quite a bit stronger than in previous families. For 3.3V standards, the pull-up resistor ranges from 1.2K to 4.1K and the pull-down resistor ranges from 1.75K to 9.35K. Spartan-3E toned down the resistance a bit. --------------------------------- Steven K. Knapp Applications Manager, Xilinx Inc. General Products Division Spartan-3/-3E FPGAs http://www.xilinx.com/spartan3e --------------------------------- The Spartan(tm)-3 Generation: The World's Lowest-Cost FPGAs.Article: 96370
Is there any way for a hobbyist to obtain the EDK in order to work w/ Microblaze? Or is there any other way to obtain Microblaze? I don't have the experience to be able to go to opencores and dive into one of the processors there. Thanks, Tom Spamming this account signifies your unqualified consent to a free security auditArticle: 96371
Hi, Question summary: Can I successfully share a Xilinx dual-port BRAM between two PowerPC data-OCM's where it is possible to write and read the same location at the same time without corrupting the data? (by different processors from different ports of the BRAM) I don't care if the read returns the old data or the new data from the write, but I want the read results to be deterministic and repeatable without corrupting the write. The (lengthy) details: I have an XC2VP30 FPGA with two PPC 405 processors. In an EDK project, I am trying to use the data-side OCM port on each processor to connect to a dual-port BRAM. This BRAM will be used as a common scratchpad that is accessible from both processors. The problem I experience is best demonstrated in a simple producer/consumer software program. PowerPC #1 is the producer and writes each BRAM location with 1 of 13 pre-determined 32-bit values. It runs in a tight loop and repeatedly fills the memory. PowerPC #2 is the consumer and repeatedly reads each BRAM location in a tight loop. If the value it reads is not one of the 13 pre-determined values that could be written, an error has occurred. **Because each processor loops forever and runs different code of different lengths, it is possible for PowerPC #1 to be writing the same address at the same time that PowerPC #2 is attempting to read it from the opposite memory port.** The BRAM is 8kB in size. Out of 1 million BRAM reads, approximately 10-20 have invalid results that should not appear anywhere in memory. These errors are randomly distributed through the entire test length and do not cluster at the beginning or end. Immediately re-reading that error location a second time will typically read a correct value, but not always. (Sometimes we can read for a hundred times without getting a legit value, at least until PPC #1 loops around and re-writes that location again). I interpret this to mean that *most* of the time, just the read is corrupted, but that *sometimes* the write itself failed to fully update the memory. In the VII-Pro Users Guide, I see there are specifications regarding writing and reading to the same address in a dual-port BRAM at the same time. Our PowerPCs (300 MHz) and data-OCM interfaces (100MHz) are all rising-edge aligned and would seem to be vulnerable to this situation. I tried changing the BRAM write mode from "WRITE_FIRST" to "READ_FIRST" via a UCF constraint in hopes of getting legitimate reads out of the second port. The error behavior improved slightly but was still present. I verified that the constraint was successfully applied in the FPGA Editor. I also tried running both OCM ports (or both Power PC's) on inverted clocks so they were out of phase. Unfortunately, we want both processors to share the same PLB bus, so this technique is also not possible. ** In the error tests, both the instruction and data caches are on in both processors and are set to only cache the PLB-based BRAM, not the scratchpad in question. However, if I turn the data cache completely *OFF* for both processors (but leave the I-cache on), then no errors are reported. We can run the test for hours. Too bad we need that cache for a real system, although there's not really much data to cache in the test program. We have played for hours with different PPC instructions to make the memory guarded, enforce in-order execution, flush the cache (even though the OCM is supposedly not cached), and have had zero luck. ** In the FPGA editor, the scratchpad BRAM blocks (4 of them) are perfectly placed in between the two processors, not shoved to a far-off corner of the chip or anything like that. I guess my question is: Has anyone ever successfully shared a BRAM between two PowerPC data-OCM's where it is possible to write and read the same location at the same time? I would be perfectly happy if the read produced the old value at that location and not the new value. (Which is what I thought changing the write mode to READ_FIRST would produce). Thanks, JeffArticle: 96372
Hi, group I generated a IPIC interface by the Create and Import Peripheral Wizard to access the memory ports on the PLB bus. I chose the DMA, user logic Master Support mode. And then try to develop my own logic based on the generated files. Here, I have one problem: To write to an address on PLB bus, I need to provide two addresses: local address which stores the source data and the destination address to which writes the data. So I think I need to instantiate a BRAM in the FPGA to provide the source address. What I am not clear is whether the BRAM is compatible the IPIC logic. Here I only local address signal to be connected to BRAM, and how to do with the left input/output ports on the BRAM. Are there any other ways to offer an address which could serve as the source for the IPIC? Thank you for the help. RogerArticle: 96373
Hi everybody, thank you all for your answers and informations ! I'll give it a try ! Bye, BEN news.verizon.net wrote: > Ben, > > I used a DDS LogiCORE to generate the sine (and cosine) and then a pair > of two-complementor LogiCORE to handle the BPSK; you wire the data value to > the BYPASS pin. Works like a champ. > > Marty > > martin dot ryba (at) verizon dot net > > "Ben Marpe" <Ben.Marpe@gmx.de> wrote in message > news:1138801274.996807.307800@g49g2000cwa.googlegroups.com... > Hi everybody, > > I'm trying to implement a BPSK modulation. > A sin waveform has to be generated at a given frequency (1MHz) with > phase offset (binary PSK i.e. 180°) when transition occures on a data > wire. > > Is there any "simple" LogiCORE with BPSK functionality available for my > Xilinx Spartan-3 - Board ? > > My attempt would be a LUT in BRAM - but do I have to fill its content > manualy ? The LUT content (e.g. 16bit) could drive a DAC. > > On the other hand, If I'm forced to use a external DAC, I might use a > DDS (e.g. AD9834) with all BPSK functionality on chip... ?!? > > I'm interested in your ideas and suggestions ! > > Bye, BEN > >Article: 96374
You need to buy EDK to get MicroBlaze. Not cheap for a hobby engineer at US$495. You can buy from a Xilinx distributor or from the Xilinx website. -- John Adair Enterpoint Ltd. - Home of Raggedstone1. The Low Cost Spartan3 Development Board. http://www.enterpoint.co.uk "spammersarevermin" <spammersarevermin@krumpli.com> wrote in message news:nb15u15q05dbjelg8u17oqac3fi75gm6ga@4ax.com... > Is there any way for a hobbyist to obtain the EDK in order to work w/ > Microblaze? Or is there any other way to obtain Microblaze? I don't > have the experience to be able to go to opencores and dive into one of > the processors there. > > Thanks, Tom > Spamming this account signifies > your unqualified consent to a free security audit
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