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
> I mistakenly presumed that -1 was a lower number than 0 and so > changing this to 0 wouldn't have made any difference. Must've been an unsigned -1 which would make it > 0 ;) KJArticle: 103026
On 23 May 2006 08:32:05 -0700, fpgabuilder-groups@yahoo.com wrote: >Folks, > >After search the net for various eval boards, I haven't found the one >that I need and afford... that is so oxymoronic... nevertheless, I >figured I might try the community before making a decision. > >I am looking for an FPGA proto board that sits on a 64/66 PCI on a ATX >motherboard. Since we are on a budget we would like to stick with low >end devices such as Spartan 3 or Cyclone 2 with possibility to add more >FPGA modules as we need them. > >I found one at http://www.4dsp.com/PCI.htm > >Unfortunately, it seems that it has a 32/33 pci interface. > >Any suggestions? > >Thank you. >Best regards, >-Sanjay Try this UK base company. We have used their products on PCI64. http://www.alpha-data.com/ --- MarkArticle: 103027
"Keith" <krw@att.bizzzz> wrote in message news:MPG.1ede86986bc24a65989a95@News.Individual.NET... > In article <4474ba59$0$294$7a628cd7@news.club-internet.fr>, > John@nospam.com says... >> Isn't ISA a dead end considering PCI, yet it is still used !!!! Hopefully not in *new* designs. :-) As far as I can tell, ISA only sticks around in industrial PC boards so that already working systems can be maintained, which makes perfect sense. (There's at least one company out there still making replacement PDP-11 boards, after all...) > ISA is still used because it's trivial to hack. PCI is anything > but. Only if you're planning to actually implement the PCI interface yourself... which really only makes sense if you're planning to try to squeeze the last once of performance out of the bus. For most designs, using interface ICs from the likes of PLX Technology make PCI pretty darned friendly to implement to (their chips have options to treat the "card" side of the bus as anything from reasonably sophisticated down to dumb-as-a-PIC). Cypress has an IC that places a dual-port RAM (and a couple of FIFOed mailboxes) across the PCI bus, also making it trivial for even the "dumbest" logic to interface. USB is quite similar -- unless you're after an education, for the vast majority of designs the various USB interface ICs (e.g., from FTDI) or USB-based microcontrollers with supplied low-level code (from Cypress, Atmel, Microchip, etc) let you worry about the unique aspects of your design rather than interfacing with Yet Another Bus. For FPGAs or standard-cell logic, there are lots of USB and PCI cores out there from the usual suspects. ---Joel KolstadArticle: 103028
Antti wrote: > Hi > > i just realized that a DIP40 module on my desk at work could be the > most expensive 8051 compatible DIP40 thing ever made - its a Virtex-4 > V4LX25 based FPGA module with current manufacturer price (qty 1) of 607 > USD. Impressive, Yes, at $607 (~$19 per IO pin), you might be right ! Makes a change from the ~3c/IO spec point :) -jgArticle: 103029
"amko" <sinebrate@yahoo.com> wrote in message news:1148481217.144437.89430@g10g2000cwb.googlegroups.com... > Since that I should add still LVDS/ECL or LVDS/NIM converters/drivers > what will results in additional jitter. > Can you guarantee that jitter on your LVDS (high speed links) is less > than 50ps. > What about external trigger uncertainly domain. For this case I > probably need very accurate input comparator. > Spartan 3 DCM period Jitter is +/150ps. If you design an interface board, supply that interface with the very-low jitter clock for sampling *on that board* (to reduce trigger uncertainty) and to reregister the output from the development FPGA board to knock your jitter back down to the low levels you want. Where your ECL/LVDS interface occurs is up to you.Article: 103030
I wrote: > It appears that you've avoided the unaligned load/store instructions, > which are patented. Dave wrote: > I'm not familiar with the MIPS architecture, but the Motorola 68020 used > unaligned load/store (e.g., reading/writing a 32-bit word to an address > that was on an odd byte boundary) operations in the early/mid '80s. Sure, and the IBM 7030 Data Processing System did it in 1961. The point isn't that MIPS can do unaligned load and store, but HOW it does it. Unlike the MC68020, it doesn't happen automatically. If you try to use the regular load instruction with an unaligned address, it doesn't do an unaligned load for you. To do an unaligned load on a MIPS, you use a pair of special instructions, one of which gets the "left" part from one word of memory, and one of which gets the "right" part from the previous or next word of memory (depending on the endianness). The advantage is that there doesn't need to be a barrel shifter in the data path used by normal loads (which might be in a critical path), and there doesn't need to be sequencing logic for automatic unaligned loads. The disadvantage is that the programmer (or compiler) has to know up front whether to expect that a load might be unaligned, and to generate the appropriate instruction sequence. > Do you have a patent number at hand? No, not at hand. Shouldn't be too hard to find it, though.Article: 103031
I think it just goes way back to when Verilog first came out, we were still driven by schematics in the early 80s, the nested symbol was the level of abstraction used. Verilog was primary invented by Moorby when he joined Gateway. On day one he was told they had a synthesis tool with no language to drive it, so he insisted on building one. He had previously built the Hilo tool for Genrad so he had a good insight as to what was needed at that time. It may be true that in the past hardware guys with little software experience didn't care about having such abstractions available since the divide was far greater then, but the opposite point can't always be true. When you are proficient in software and hardware you can still choose Verilog over VHDL because the missing abstractions can be got by working in C or other languages. Most projects involve both hardware & software and Verilog + something else was able to make up for the missing features that VHDL had. I wonder what programming languages VHDL fans generally favor, is it just same as everyone else? Does VHDL generally need C or anything to boost it in anyway? John Jakson transputer guyArticle: 103032
Excellent! Felix, Thank you. This code synthesizes to 26 slices on a V4. Probably more if more I2C need to be sent. I needed to change only this clkdiv line to help speed up a ModelSim simulate, -- signal clkdiv: unsigned(8 downto 0); signal clkdiv: unsigned(1 downto 0); I'll change it back to adjust to my frequencies. All the SDA and SCL lines appear to be rising and falling per I2C spec. Thanks so much. BradArticle: 103033
4,814,976 Hansen , et al. March 21, 1989 Mips Computer Systems, Sunnyvale http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&p=1&u=%2Fnetahtml%2FPTO%2Fsearch-bool.html&r=5&f=G&l=50&co1=AND&d=PTXT&s1=unaligned.ABTX.&s2=instructions.ABTX.&OS=ABST/unaligned+AND+ABST/instructions&RS=ABST/unaligned+AND+ABST/instructions or http://tinyurl.com/fgjem Easy to find this stuff, just use the search engine at uspto.gov for a "quick search." Austin Eric Smith wrote: > I wrote: >> It appears that you've avoided the unaligned load/store instructions, >> which are patented. > > Dave wrote: >> I'm not familiar with the MIPS architecture, but the Motorola 68020 used >> unaligned load/store (e.g., reading/writing a 32-bit word to an address >> that was on an odd byte boundary) operations in the early/mid '80s. > > Sure, and the IBM 7030 Data Processing System did it in 1961. > > The point isn't that MIPS can do unaligned load and store, but HOW it > does it. Unlike the MC68020, it doesn't happen automatically. If > you try to use the regular load instruction with an unaligned address, > it doesn't do an unaligned load for you. > > To do an unaligned load on a MIPS, you use a pair of special instructions, > one of which gets the "left" part from one word of memory, and one of > which gets the "right" part from the previous or next word of memory > (depending on the endianness). > > The advantage is that there doesn't need to be a barrel shifter in > the data path used by normal loads (which might be in a critical path), > and there doesn't need to be sequencing logic for automatic unaligned > loads. > > The disadvantage is that the programmer (or compiler) has to know up > front whether to expect that a load might be unaligned, and to generate > the appropriate instruction sequence. > >> Do you have a patent number at hand? > > No, not at hand. Shouldn't be too hard to find it, though. >Article: 103034
Dave wrote: > Do you have a patent number at hand? I'm curious as to when this was > patented and what MIPS does that makes this patentable. It's the '976 patent, 4,814,976. Lexra got the patent office to reexamine it in 2001, suggesting that IBM's patent 3,916,388 was prior art. But the patent office upheld the '976 claims in 2002. The patent application is dated December 1986, and issued in March 1989, so it appears that it will expire this December. AFAIK, this is the only patent on the basic 32-bit MIPS instruction set architecture. MIPS holds patents on various techniques used to implement RISC processors efficiently, but it is possible to implement the MIPS architecture without using those techniques. MIPS also appears to have several patents that may apply to the "Thumb" instruction set. I haven't studied the patents or the Thumb ISA, so I'm not certain. 6,651,160 6,714,197 6,732,259 6,826,681 EricArticle: 103035
(a) It wasn't anonymous I said my name was Clark. I assume fpga_toys is his christian name? Did you need a home address? (b) I think the article I linked to did specify the device details. No controversy was intended. I see an ad that says $29.99 for fx12 in quantity 50K. I get an answer back from my purchasing department that says about $112 for quantity 100K. I'm merely trying to figure out what the disconnect is. -Clark "Peter Alfke" <alfke@sbcglobal.net> wrote in message news:1148447001.554847.225780@j73g2000cwa.googlegroups.com... > This newsgroup is not the substitute for a request for quote sent to > the appropriate sales channel. > That sales channel would also have told you that the V4FX12 is too > small to be a candidate for EasyPath. > There are proper ways to get this information, without abusing the > newsgroup, where you started a rambling discussion, without ever > revealing your Anonymous identity, or even the details of your request > or complaint. > Most of us have better things to do than engage in these wide ranging > speculations. > Peter Alfke >Article: 103036
Has anyone out there been able to program an EPCS device via running code on a nios. The examples I find require an EPCS4, we are using the EPCS16 and EPCS64. Also it seems that altera has changed the format of thier POF and RPD files because the examples perl scripts can no longer give a usefull file for these examples. Any help would be much appreciated. Thanks, BrianArticle: 103037
Hi, Clark The difference between the two prices is very large, as you correctly stated. But you never provided details for the device you want, obviously not the simplest and cheapest.: What speed grade, what package, what temperature grade? These factors can each raise the price. But I still think the $112 quote looks like an attempt not to bid for your business. BTW, no EasyPath for a device this small. In order to achieve a lower price, the device must be bigger, so that Xilinx has a way to save cost through higher yield and shorter test time. For small devices, that saving is insignificant (for large die the saving is substantial). Peter AlfkeArticle: 103038
Ben Jones wrote: > "Jim Granville" <no.spam@designtools.co.nz> wrote in message > news:44736721$1@clear.net.nz... > >>johnp wrote: >> >> >>>XILINX - please change the .ise file back to text format! The binary >>>version is a BAD idea for a bunch of reasons! >> >>Perhaps now is a good time to ask Xilinx for a time-frame, when they >>WILL be making this fix ? >>IIRC there are other threads on the same time-sink flaw ? > > > I believe the shortcomings of the binary ISE project file format are being > addressed for the next major release. > > Yes, I appreciate that this is a rather weasley answer. That's because I > don't have the details of what exactly is going to happen. But I for one am > certainly hoping that we will get an ASCII project file and thus return to > the world of EDA sanity. <snip> ben, Thanks for the heads up - and I do not consider the above a weasley answer :) -jgArticle: 103039
Peter Alfke wrote: > As far as chip area goes, the decision to go to LUT6 (as we call it) > was a no-brainer: > > Extensive benchmarking shows that a LUT6 is 'worth" about 1.4 LUT4 > (this is an average over almost 200 designs, your mileage may vary...) > Our designers found that the CLB size penalty for LUT6 compared to > using LUT4 in the same technology is only about 15% (Yes, the LUT takes > only a small portion of the silicon area) > > Gaining 40% in functional density for a 15% price in larger area is, of > course, a win-win situation. > The higher performance due to fewer levels of LUTs and reduced > interconnects is just a bonus. Nice bonus, thank you! > Peter Alfke, Xilinx > Well, it isn't exactly free. You do take a hit in the LUT performance, which as you point out is actually a win *IF* the design would have gone to two levels of logic with only a 4-LUT. The fact of the matter is, as a high performance system designer, I specifically design my logic so that it has only one layer of logic between FF's. With that in mind, then assuming all else is equal, the 6-LUT represents a decrease in absolute clock performance. In the case of V5, that hit is hidden with the gain associated with the smaller geometry, and also as I recall some of the inputs to the 6-LUT are significantly faster than other inputs. Am I complaining? No, not really. If I were to complain, it would be more about the new architecture making my existing library pretty much obsolete.Article: 103040
Marc Reinig wrote: > We are currently planning on the V4 SX55, but really could use more speed, > pins, MACs and less power. Looks like the speed increases slightly, > possibly more with the rearranged MAC; the power is down, that's good; will > there be an increase in the MACs and pins available? Any indication of a > release date for samples? > Marco > ________________________ > Marc Reinig > UCO/Lick Observatory > Laboratory for Adaptive Optics > > Marc, The big win you'll see is that the V5 carry chain is fast enough to keep up with the DSP48E's, where in V4, the fabric carry chain speed is dismal compared to the speed of the DSP48's. You'll have to get an NDA with Xilinx to get the details on planned V5SX devices.Article: 103041
>> Rapid changes in kernel interface is something that is avoided within bsd >> operating systems (freebsd, netbsd, openbsd) due more conservative code >> acceptence policy.. Should jungo.com ever try it ;) > > I'd just prefer Xilinx publish the code for cableserver and standardise > all their tools to use it. Nice dream. Xilinx are not known to be open-source friendly. I suppose they will, as all other companies, wake up some day and find out the open source community is not working against them. Until that day we're stuck. > There's no reason all this could be done in userland (ppdev) and have > maximum compatibility (and trivial portability). Same for USB. usblib is portable (win32/linux/macos), free (as in free speach and in free beer), fast and not clobered with security holes like jungo products. They could at least use it, if they don't want to release the protocols they classified as "highly confidential information". > For faster performance you could write a driver (with source :) which > bundled together JTAG ops or something.. Even pure userland is not > terribly slow (I have an XC3/XCF programmer which is not much slower than > impact) > > I'm sure you're all sick of me mentioning this by now of course 8-) I doubt they will change their mind for you and me. Might be different if we were buying millions of pieces a month. Laurent PinchartArticle: 103042
In article <1279jbqev8c163d@corp.supernews.com>, JKolstad71HatesSpam@yahoo.com says... > "Keith" <krw@att.bizzzz> wrote in message > news:MPG.1ede86986bc24a65989a95@News.Individual.NET... > > In article <4474ba59$0$294$7a628cd7@news.club-internet.fr>, > > John@nospam.com says... > >> Isn't ISA a dead end considering PCI, yet it is still used !!!! > > Hopefully not in *new* designs. :-) As far as I can tell, ISA only sticks > around in industrial PC boards so that already working systems can be > maintained, which makes perfect sense. (There's at least one company out > there still making replacement PDP-11 boards, after all...) > > > ISA is still used because it's trivial to hack. PCI is anything > > but. > > Only if you're planning to actually implement the PCI interface yourself... What's so hard to understand about "hack"? > which really only makes sense if you're planning to try to squeeze the last > once of performance out of the bus. For most designs, using interface ICs > from the likes of PLX Technology make PCI pretty darned friendly to implement > to (their chips have options to treat the "card" side of the bus as anything > from reasonably sophisticated down to dumb-as-a-PIC). Cypress has an IC that > places a dual-port RAM (and a couple of FIFOed mailboxes) across the PCI bus, > also making it trivial for even the "dumbest" logic to interface. Sure, but that's hardly hacking. I've used PLX chips and they're certainly not trivial to use. Even given that the chip simply works, the board layout is 100x harder than ISA. Programming is equally hard (comparatively). Any damned fool can build an ISA channel card with a few 74xx gates. PCI is *hard* even with PLX doing the heavy lifting. > USB is quite similar -- unless you're after an education, for the vast > majority of designs the various USB interface ICs (e.g., from FTDI) or > USB-based microcontrollers with supplied low-level code (from Cypress, Atmel, > Microchip, etc) let you worry about the unique aspects of your design rather > than interfacing with Yet Another Bus. Certainly, but USB ain't ISA either. > For FPGAs or standard-cell logic, there are lots of USB and PCI cores out > there from the usual suspects. Sure, but FPGAs or standard-cell aren't a coupla 74xx buffers either. ISA was a piece of cake for an idiot (and still lives in the ATA connector for those who want to play ;). -- KeithArticle: 103043
hi all,
I have a trouble in reading-back a frame of xcv1000e.According to
xapp138,139,151,I wrote a .bit file and download it into FPGA via
iMPACT.It seems to be successful, but I can't get the data back from
TDO.I wander if there is something wrong with my operations.My .bit
file is shown bellow: AA99 5566
3000 2001
0000 0000
3000 8001
0000 0004
2800 6001
1/Do I have to add some starting bits and end bits to my .bit file?
2/what kind of .bit file format I can use to download my instructions?
3/Is there anybody who has a successful experience about xapp
138(readback via JTAG)?
Any imformation about readback is welcome!
many thanks!
Nicky
Article: 103044alpha wrote: > Uncle Noah wrote: >> Xilinx block RAM is synchronous read. Is this the source of your >> problem? > > [YES, design was based on Altera Apex chip when it got started. This is > why I need a newer altera board. Too expensive. Does anyone know if > there is any chance to borrow one form Altera ? :) ] > As far as I know, the newer Altera chips also use synchronous RAM blocks. (Input registers are mandatory, output registers are optional)Article: 103045
raarce@gmail.com wrote: > Is there a way in Xilinx ISE of knowing the percentage of routing > resources that have been utilized after Place and Routing? I too would love to see this Rafael. One of the other vendor's tools (Altera?) prints out the percentage of the FPGA devoted to routing so that you can see how much routing overhead there is, but what would really be useful is for the synthesizer to provide some idea as to what percentage of the resources are used by _each_ _module_. As it is now, I have to synthesize each module separately in order to obtain this information. -- RonArticle: 103046
In article <1148510875.580909.76090@y43g2000cwc.googlegroups.com>, JJ <johnjakson@gmail.com> wrote: >I think it just goes way back to when Verilog first came out, we were >still driven by schematics in the early 80s, the nested symbol was the >level of abstraction used. > >Verilog was primary invented by Moorby when he joined Gateway. On day >one he was told they had a synthesis tool with no language to drive it, >so he insisted on building one. He had previously built the Hilo tool >for Genrad so he had a good insight as to what was needed at that time. > >It may be true that in the past hardware guys with little software >experience didn't care about having such abstractions available since >the divide was far greater then, but the opposite point can't always be >true. When you are proficient in software and hardware you can still >choose Verilog over VHDL because the missing abstractions can be got by >working in C or other languages. Most projects involve both hardware & >software and Verilog + something else was able to make up for the >missing features that VHDL had. Well, C doesn't exactly offer a lot of abstraction either... > >I wonder what programming languages VHDL fans generally favor, is it >just same as everyone else? I like Ruby for lots of things and I'm learning Io, functional programming. Lisp/Scheme are cool too. > Does VHDL generally need C or anything to >boost it in anyway? While I refer VHDL over Verilog, VHDL is still lacking... PhilArticle: 103047
Vivian Bessler wrote: > Marco, > If you have access to a tool such as ChipScope (embedded Logic analyzer > from Xilinx http://www.xilinx.com/ise/optional_prod/cspro.htm ) this > will provide a more convenient debug solution. You forgot to mention the price: $695 to $844 (depending on options). Prices are shown at: http://snipurl.com/qx87 RonArticle: 103048
Hello everyone, I am trying to program an Altera Cyclone (EP1C20) device, which comes with the NiosII processor already in it, using the Quartus 5.0 software. My connection to the board is via the JTAG connection. When programming, I get no errors from the Quartus software, but immediately after programming has been completed, the board resets and starts the Nios system again, as if nothing happened. What am I doing wrong? Thanks in advance, RoiArticle: 103049
Problem solved. I added 'export LANGUAGE=usenglish' to the script that start ISE (old values used to be 'en').
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