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
"Anders Hellerup Madsen" <anders@hellerup-madsen.dk> schrieb im Newsbeitrag news:bp29um$b6s$1@news.net.uni-c.dk... > Hi, > > I'm trying to design a controller for a Hitachi color STN display, but > I'm running in to all kinds of problems here. I think most of it comes > from the fact that I really don't know anything about how LCD displays > work, so I was hoping someone in this group could enlighten me a little. > > From what I've gathered from the displays datasheet, it seems the > display is controlled by two different clock signals, one for vertical > and one for horizontal lines. Once these clock signals are set > correctly, it should just be a matter of clocking the pixel data in right? > > There seems to be three bits for each color component, red, blue and > green, and by my calculation this gives 8 different colors. However the > display is listed as beeing able to show up to 65,000 different colors. > How exactly is this possible? > > I have thought about various dithering schemes, but i think most of them > implies very dramatical losses in refresh speeds, resolution and image > quality. What is the normal way of producing colors on a CSTN display? > > Regards, Anders > In the last weeks I've designed a TFT Controller fЭr Sharp TFT Panels. The Panel ist 640x480 Pixel, 262144 Colors. EBay: 40$ The TFT Controller has an Video + SVHS Input. FPGA: Altera Cyclone EP1C3 ( about 20$). The "source-Code" is an Altera Quartus "graphical block diagram." Size: about 1 printed page. You see: Its very easy to design a controller for TFT displays. GerdArticle: 63101
Thanks for your response. The read control is/can be attached to the SRAM from the FPGA, but do I need to run the read state machine to match the JTAG interface speed(10Mhz?) Is this going to turn into a project of its own? (Don't I need to somehow synchronize hw and sw - use hw to initiate read at a slower speed, then check with SAMPLE instruction via sw, back to hw to increment addr, etc.?) Thanks again. (replace 'hard' with 'easy' in email) "Jim Wu" <jimwu88NOOOOSPAM@yahoo.com> wrote in message news:<%H3tb.20749$hB5.784@nwrdny02.gnilink.net>... > > The SRAM I'm thinking of using is Cypress, will be running it at > > 150+Mhz, and the device supports these JTAG instructions : EXTEST, > > IDCODE, SAMPLE Z, SAMPLE/PRELOAD, BYPASS (Preload isn't supported, > > actually). > > Are the SRAM read control signals connected to the FPGA? If not, I think you > will need to use INTEST instruction, but looks like the SRAM does not > support it. > > Jim Wu > jimwu88NOOOSPAM@yahoo.com (remove capital letters) > http://www.geocities.com/jimwu88/chipsArticle: 63102
Tom Hawkins wrote: > Is it possible to infer a dual port block RAM > when the ports have different memory dimensions? It's possible to infer a single-direction dual port ram from code, but the dimensions are restricted by the device block size. Brand X devices and brand A stratix devices have real dual-port ram available, but last I checked, synthesis punts on inference. > Say port A has address and data width of 8 and 8, > while port B has address and data with of 9 and 4, > for instance. > > Instead of using a 2 dimensional array, one could > define one long array then do appropriate > bit selection off the 1D array for addressing: If a single-direction design is ok, you could certainly infer some legal sized blocks and wrap logic around them to handle your byte selects. For a true dual port, you might have to instance the blocks. -- Mike TreselerArticle: 63103
Thanks Peter for the warnings. We are building a FIFO with normal binary counters, but the empty and full signals are not based on bytes but on 64 byte packets. Therefore there is enough time to get a reliable empty and full indication in both clock domains. We also have the advantage that our clocks are 'slow' (40 - 50 MHz). I have build these FIFO's with success before in other projects, but always with the aid of the core generator or library elements (the latter code is unreadable because 4 - 6 blockrams are instantiated for one blockram) Mark "Peter Alfke" <peter@xilinx.com> schreef in bericht news:3FB40A26.E7B13EB8@xilinx.com... > Mark, I cannot help you with the VHDL, but recently having investigated > a similar design, here are some issues: > > Asynchronous clocks mean that Empty and Full detection must cross the > clock domain boundary, and simple comparators are bound to fail, unless > you use Gray-coded addresses. > The dual-width design, when going from narrow to wide, must deal with > the issue of a partially assembled word still meaning "empty". > All this becomes tricky at >200 MHz, but should be manageable at lower frequencies. > Dual-clock FIFOs implemented in a dual-ported BlockRAM are trivial, > until you have to detect Empty (Full is usually an avoidable situation > that allows some cheating, but Empty can be tricky.) > Peter Alfke > > Mark van de Belt wrote: > > > > Hello, > > > > I need to use a blockram as a FIFO to port data from one clock domain to > > another. I created a blockram with help of the language template. This > > blockram is recognised by the XST synthesiser. The dual clock is also > > recognised after a small modification. The next problem is to describe a > > databus width conversion. There is a 32 bit processor bus on one side and a > > 1 bit serial output on the other side. This is no problem with a library > > element or a blockram instance from the coregen. I don't like the coregen > > modules because it is not easy to back-up your sources or transport them to > > another PC. The library instances make the code less portable. Is there a > > way to describe the width conversion in VHDL without creating extra logic > > outside of the blockram? > > > > Thanks, > > Mark > > > > --- > > Outgoing mail is certified Virus Free. > > Checked by AVG anti-virus system (http://www.grisoft.com). > > Version: 6.0.538 / Virus Database: 333 - Release Date: 10-11-2003 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.538 / Virus Database: 333 - Release Date: 10-11-2003Article: 63104
"Tom Hawkins" <tom1@launchbird.com> schreef in bericht news:833030c0.0311141022.623fef08@posting.google.com... > Is it possible to infer a dual port block RAM > when the ports have different memory dimensions? > > Say port A has address and data width of 8 and 8, > while port B has address and data with of 9 and 4, > for instance. > > Instead of using a 2 dimensional array, one could > define one long array then do appropriate > bit selection off the 1D array for addressing: > > reg [0:2047] memory; // 256x8 or 512x4. > > Port A Addressing (pseudo code): > > memory[addr_a * 8 : addr_a * 8 + 7] > // Invalid Verilog, I know. > > Port B Addressing: > > memory[addr_b * 9 : addr_b * 9 + 3] > > > Or another, more Verilog friendly way, would be to > use a 2D array with the data as the least common denominator: > > reg [3:0] memory [0:512]; // 512x4 > > Port A Addressing: > > {memory[{addr_a, 1b'0}], memory[{addr_a, 1b'1}]} > > Port B Addressing: > > memory[addr_b] > > > Has anyone had success inferring asymmetric dual-port > block ram? > > -Tom > > -- > Tom Hawkins > Launchbird Design Systems, Inc. > 952-200-3790 > http://www.launchbird.com/ Hello Tom, I have created asymmetric blockrams, but always with the aid of library components or IP cores. I have posted a similar question yesterday for some VHDL code. The only problem with the asymmetric blockrams is the translation of the bits to the addresses on the smaller port. I have found that the LSB's of the smaller port (port B in your example) must be inverted to get the MSB's of the port A on the lowest addresses on the B port (MSB of port A first on the output of port B) Mark van de BeltArticle: 63105
Ed J wrote: >I writing VHDL for a Xilinx Virtex-II Pro FPGA application, and software for >its embedded PowerPC. The PowerPC doesn't have hardware floating point, and >floating point emulation in software is too slow for my purpose. So, I'm >looking for a way to add floating point in the FPGA fabric through VHDL or >black boxes. I need IEEE floating point operations such as add, subtract, >multiply, divide. I also need some math functions like sine, cosine, square >root, etc. > >Is there a (free) standard package in VHDL that I can use for this? Third >party support? > >I'm a newbie on a budget, so I'm looking for the cheapest, quickest >solution. > > > In many applications, it doesn't make much sense to carry 32+ bits of mantissa when the original data was digitized by a 10 - 12 Bit ADC. When you have a processor with that word-width built in, it makes no difference. But, when you are allocating resources on an FPGA, it may make a huge difference in real estate consumed by the functions. As for Sine, Cos, etc. you may be able to use a look-up table for these. A 100 nS multiply is doable, but a 100 nS sine or sqrt may be a lot tougher. If the resolution is not too high, then the LUT is both fast and can be done with a fast ram or rom. You might want to look at all the DSP cores and other materials and resources that Xilinx has available. JonArticle: 63106
John wrote regarding XAPP223: > > Occassionally, we are seeing a MISSED byte being sent from > a random serial device. > The XAPP223 UART has a flaw in the receive section that causes that problem- just re-clock the incoming data through a couple of registers, using the UART clock, before driving the UART data input. ( Internally to the macro, the UART input data is registered and used in more than one place without a synchronizer stage... ) Brian john@jrobot.net (john orlando) wrote in message news:<cc4b5d44.0311131330.77f8afc5@posting.google.com>... > Hello, > We have recently been using the free Xilinx UART macro with the > 16-byte FIFO (from app note XAPP223) in a design, instantiated in a > Virtex XC2V1000. We are using both the Rx and Tx macros (actually, 32 > of each for a total of 32 UARTs in the device). Our actual setup > looks like this: > > StrongArm SA-1100 <--> Virtex XC2V1000 <--> 32 serial devices > > where the UART FIFOs in the XC2V1000 are essentially memory-mapped > into the StrongArm's memory space to read and write to the serial > devices. > > Occassionally, we are seeing a MISSED byte being sent from a random > serial device. We have scoped the serial lines between the serial > devices and the XC2V1000 and know the serial data is showing up there. > We put a high-speed logic analyzer on the interface between the > SA-1100 and the XC2V1000, and know that the byte does not appear > there. > > After three weeks of investigating this issue, we are starting to > wonder if the lost byte may be due to the macro. Is there any > condition with the macro where performing a read from the UARTs Rx > FIFO to pull a byte out on the same clock edge where a stop-bit has > been received and recognized, and the received byte added to the Rx > FIFO, would cause the received byte to be lost? Specifically, it > seems as though we see N bytes in the UART's Rx FIFO to be read, we > perform N reads (actually, N+1 reads, because the N+1 read is what > indicates to us that DATA_PRESENT is not asserted, and that byte > should be thrown away...we do 16-bit reads: 8 bits data, and 8-bits of > status, with the DATA_PRESENT part of the status). We only see the > missing bytes when we eventually see DATA_PRESENT again, which > interrupts us (the interrupt is actually delayed 4-byte times in our > system), and we perform a read of the data in the Rx FIFO again. We > should be able to read 4 valid data bytes. However, the first byte we > read from the FIFO is actually the SECOND byte that should have been > in the FIFO, and the first byte is gone forever (the remaining third > and fourth byte are read just fine). > > Anyone out there ever seen this type of behavior with the macro > before? Our baud rates are running at 38.4 KBps, and our FPGA is > being clocked by the StrongArm at ~90 MHz, in case you're curious. > Any help would be appreciated....thanks in advance! > > Regards, > John O.Article: 63108
Steve Lass <lass@xilinx.com> wrote: : Foundation 3.1 was release about 3 years before Windows XP, so I would : not expect it to work. : You will need to get a newer version of the software. Try ISE WebPACK : 6.1i or if you need to : use larger devices ISE Foundation 6.1i. I expect old software to work, beside eventually hardware drivers... Bye -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 63109
In article <bp3sc5$u6$1@news.tu-darmstadt.de>, Uwe Bonnes <bon@elektron.ikp.physik.tu-darmstadt.de> wrote: >I expect old software to work, beside eventually hardware drivers... Only if you run it on an old OS. -- Nicholas C. Weaver nweaver@cs.berkeley.eduArticle: 63110
Spartan 2 datasheet says Vrefs are internally connected, but must also be externally connected. Is this really needed if you only use one input?Article: 63111
Nicholas C. Weaver <nweaver@ribbit.cs.berkeley.edu> wrote: : In article <bp3sc5$u6$1@news.tu-darmstadt.de>, : Uwe Bonnes <bon@elektron.ikp.physik.tu-darmstadt.de> wrote: :>I expect old software to work, beside eventually hardware drivers... : Only if you run it on an old OS. A Win32 program written at the time of e.g. Win95 will run on XP, as long as it doesn't do any bad tricks. -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 63112
"Steve Lass" <lass@xilinx.com> ???????/???????? ? ???????? ?????????: news:bp362a$4ju2@cliff.xsj.xilinx.com... > Foundation 3.1 was release about 3 years before Windows XP, so I would > not expect it to work. > You will need to get a newer version of the software. Try ISE WebPACK > 6.1i or if you need to > use larger devices ISE Foundation 6.1i. > > Steve > > Сергей Зорин wrote: > > >Hello. > >I have instslled JRE 1.3. All works. However only under WIN98. > >And me is necessary that all worked under WIN XP. > >Can I it make? And how? > > > >Beforehand thank. Hello. To ALL, please. That I have. 1. On a hard disk C: - WIN98. 2. On a hard disk D: - WINXP That I have made. 1. Download JRE 1.3 from SUN. 2. Has replaced files JRE 1.2 (Foundation 3.1i) with a files JRE 1.3. 2. Has established the program under WIN98 (in my case it C:\XILINX). All works. 3. Has copied files from a disk C: with on a disk D: (D:\XILINX). 4. Has started installation Foundation 3.1i under WINXP. 5. I do not attention to the messages (files that are already unpacked and are available on hard disk D:) java.exe. 6. When installation was finished - all works and under WINXP. 7. Already under WINXP are put update with 3.1 up to 3.3 That's all. By all thank for discussion and help. Also excuse for bad English.Article: 63113
> To ALL, please. > That I have. > > 1. On a hard disk C: - WIN98. > 2. On a hard disk D: - WINXP > > That I have made. > > 1. Download JRE 1.3 from SUN. > 2. Has replaced files JRE 1.2 (Foundation 3.1i) with a files JRE 1.3. > 2. Has established the program under WIN98 (in my case it C:\XILINX). All > works. > 3. Has copied files from a disk C: with on a disk D: (D:\XILINX). > 4. Has started installation Foundation 3.1i under WINXP. > 5. I do not attention to the messages (files that are already unpacked and > are available on hard disk D:) java.exe. > 6. When installation was finished - all works and under WINXP. > 7. Already under WINXP are put update with 3.1 up to 3.3 > > That's all. > By all thank for discussion and help. > Also excuse for bad English. > > > It Wrote Сергей Зорин (Sergey Zorin)...Article: 63114
"Eman" <vze3tx4k@verizon.net> wrote in message news:d7dce3cf.0311132339.57ab7886@posting.google.com... > Howdy folks. > > I've got a recent BS in computer sytems engineering, which is a like > EE with some compsci mixed in. I've used CPLDs, and really want to > get a good start in FPGAs so I can build my career in the 'embedded' > direction. > > How does one start out in fpga development given that funds are > limited ? > > thanks > > - moi Buy an FPGA development board and start experimenting. You should be able to find several options by googling for "FPGA development board" or something similar. It will set you back no more than $100 to $200 for a system good for lots of learning. There's no excuse not to buy one, the cost is insignificant compared the BS degree you just purchased to help your career. Of course, this same degree didn't teach you how to research technologies and find development solutions....Article: 63115
Hello, I have reviewed Altera's SRUNNER C program and related whitepapper, but it's not easy to undersatnd. What would really help me is a Flash-memory style data sheet that explains all the waveforms, timing, and commands. I am wondering, does anybody has anything like that on EPCS?Article: 63116
hmurray@suespammers.org (Hal Murray) wrote in message news:<vra5aj7p86tf32@corp.supernews.com>... > >I want to design a pci board which will expand one pci slot through a > >pci-bridge and pci-local bus and get two slot. I wonder if there is > >any driver problem? say i plug a audio card into the expanded slot? > > Depends upon your softwae. I'd expect it to work for most OSes. > > It might not for an OS designed to run on small systems, > say an OS for embedded systems. It might take a special configuration > flag for the software to include support for the PCI Bridge. I am using windows 2000, the two PCI card I am about to use is a Display card and a FPGA based DSP card, they both have workable driver, what I wonder is if a PCI-Bridge based slot expansion card can make these two only ocupy one main PCI-bus slot, with out any change of driver. Do you know if there are any product card can do this? or any available design for this? Thanks HuiArticle: 63117
"Naveed" <visualfor@yahoo.com> schrieb im Newsbeitrag news:864a80dc.0311150331.33f09d5b@posting.google.com... > Hello, > > I have reviewed Altera's SRUNNER C program and related whitepapper, > but it's not easy to undersatnd. What would really help me is a > Flash-memory style data sheet that explains all the waveforms, timing, > and commands. I am wondering, does anybody has anything like that on > EPCS? Yes, I've written an EPCS1 Programmer. Whast Do you want to know ?Article: 63118
Jan Panteltje wrote: > Spartan 2 datasheet says Vrefs are internally connected, but must also be > externally connected. > Is this really needed if you only use one input? Howdy Jan, The wording about Vrefs is a little awkward. When they say they are "internally connected", they do not necessarily mean "internally connected TOGETHER". I believe you only need to connect to the Vrefs on the bank with your single input. Here is a quote from the Xilinx web site: <<Some of the I/O standards require VCCO and/or VREF voltages. These voltages externally are connected to device pins that serve groups of IOBs, called banks. Consequently, restrictions exist about which I/O standards can be combined within a given bank. Eight I/O banks result from separating each edge of the FPGA into two banks. Each bank has multiple VCCO pins, all of which must be connected to the same voltage. This voltage is determined by the output standards in use. In TQ144 and PQ208 packages, all VCCO pins are bonded together internally, and consequently the same VCCO voltage must be connected to all of them. In the CS144 package, bank pairs that share a side are interconnected internally, permitting four choices for VCCO. In both cases, the VREF pins remain internally connected as eight independent banks.>> As you can see, they qualify the term "internally connected" with "eight independent banks." Hence, the "internally connected" indicates that the lines are connected to the die, not that all the Vrefs of the device are tied together. Have fun, MarcArticle: 63119
Still trying to understand the very basic IOB in all its details... In the Spartan 2 datasheet I read: 'The IOB includes an optional register in the output path, the input path, and the 3 state control pin. In the diagram this is clear. Questions arise: Can the 3 state register be controlled independently? Are all 3 registers (plus the delay) active by default? Peeking in various .ucf files I find that some properties can be set: NET my_net Clkp Does this mean positive clock on register? NET my_net OFFSET = OUT : 2.5 2.5 nS Does this mean delay in output? Is there also a programmable output delay? So what are the exact commands for the UCF file to: Switch off / on the input register. Select a pos or neg clock for the input and output registers. What are the defaults? Is there a specific xapp I should (have) read that describes this in detail, preferably with human readable examples? The IOB diagram is clear enough by itself, but many things remain a mystery to me. For example if using clocked IOB on input, WHERE does the clock come from? I have 3 clock pins in use, how do you select? Is this hardwired somehow? Sorry now I am getting into detail, but this I need to know to make any sensible circuits...Article: 63120
Hi All, I am using ISE 6.1 Schematic entry, I have a RAMB4_S16_S16 symbol on my sheet and I want to set the initial contents by setting the INIT_xx Attributes in the object properties dialog box, when I simulate a Behavioral model I get a whole bunch of errors like : # ** Error: TopLevel.vhf(1480): No actual specified for ... and ends with : # ** Error: TopLevel.vhf(1482): near "port": expecting: END_ could someone please tell me what I am doing wrong . also, what the heck is an "actual" :{ thanks. MartinArticle: 63121
Mole wrote: > I am using ISE 6.1 Schematic entry, I have a RAMB4_S16_S16 symbol on my > sheet and I want to set the initial contents by setting the INIT_xx > Attributes in the object properties dialog box, when I simulate a Behavioral > model I get a whole bunch of errors like : > > # ** Error: TopLevel.vhf(1480): No actual specified for ... > and ends with : > # ** Error: TopLevel.vhf(1482): near "port": expecting: END_ > > could someone please tell me what I am doing wrong . > > also, what the heck is an "actual" :{ I don't use ISE schematic entry, but the error messages are familiar. It looks very much like the schematic is being translated to VHDL for simulation. The messages are the same I would get if I didn't have all connections to a lower level block made. Is it possible that you don't have all pins of this RAMB4_S16_S16 connected? If you understand VHDL at all, you might want to look at the TopLevel.vhf file with a text editor and see what is going on. -- Phil HaysArticle: 63122
"Phil Hays" <SpamPostmaster@attbi.com> wrote in message news:3FB64BA2.244E60DB@attbi.com... > I don't use ISE schematic entry, but the error messages are familiar. It looks > very much like the schematic is being translated to VHDL for simulation. The > messages are the same I would get if I didn't have all connections to a lower level > block made. Is it possible that you don't have all pins of this RAMB4_S16_S16 > connected? > > If you understand VHDL at all, you might want to look at the TopLevel.vhf file > with a text editor and see what is going on. > > > -- > Phil Hays Hi Phil, thanks for the reply. I dont need some of the connections, so you correctly speculated about the connections, but I have tried making dummy connections but I still get the same error messages :( I will have to get to grips with HDL sooner than expected ... Thanks, MartinArticle: 63123
rickman <spamgoeshere4@yahoo.com> wrote in message news:<3F93E4A8.C68E3142@yahoo.com>... > etrac wrote: > > > > Jim Granville <jim.granville@designtools.co.nz> wrote in message news:<3F8DBF2B.2595@designtools.co.nz>... > > > etrac wrote: > > > > > > > > Hi, > > > > We have found the problem and this might interest somebody here so I > > > > explain the reasons of the voltage falling : It was simply because we > > > > put too many bypassing capacitors around the FPGA ! The virtex II > > > > datasheet is asking for many capacitors to have good linearity in the > > > > fpga voltages, but our power supply was not enough strong to support > > > > the current when we power on the board. > > > > > > > > Etrac. > > > > > > etrac wrote: > > > > > > > > > > > > > We want to power on a Virtex II xc2v3000 FPGA (Xilinx). The core power > > > > > > > seems to work correctly (VccInt = 1.5V ; I<100mA), but VccAux and VccO > > > > > > > are asking too much current (> 1.5A) for a long time. This occurs > > > > > > > approximatively 1 second after the power is on. > > > > > > > We have a current limitation power supply, so the VccAux/VccO voltage > > > > > > > fall at nearly 1.5V, that is to say that the FPGA needs very much than > > > > > > > 1.5A .. > > > > > > This does not quite 'gel' - you are saying lowering the Total C alone > > > solved the issue ? > > > > > > That suggests a dV/dT limit, but times in the order of 1 second ? > > > It may be a power-sequencing effect, which total C would affect. > > > > > > -jg > > > > Our power supply is current limited (2 Amps), and at poweron > > capacitors were asking too many current for the power supply. So we > > were in overcurrent mode. That was the same problem with our > > laboratory power supplies, with a current limitation .. > > > > Etrac > > Isn't that a common mode during power on? Exactly what problem does > this cause? Are you saying that the current causes a voltage foldback > so that the rise is not monotonic? If so, your problem is not the > capacitors, it is the foldback current limiting. I find it hard to > imagine the caps on a board having more total capacitance than a power > supply. But I guess you may be working with an on board DC/DC with 100 > uF or less. > > -- > > Rick "rickman" Collins We use Motorola QuiccSupply products to power the FPGA, they have two protections : overcurrent protection and undervoltage lockout. The first limits the current, the second disables the power if the voltage is not in the good range (checked every 100ms). That's why if C is big the power supply can't raise the voltage quickly and the QuiccSupply goes in undervoltage lockout. That's true that if the Power supply doesn't have any undervoltage lockout capability we did not have such problems .. Nevertheless Virtex II documentation says that at power on, each supply line (VCCO VCCAUX and VCCINT) has to be stable quickly (< 200 ms if I remember well), otherwise the component will need more current to power on. So I think that having too many bypassing capacitors may affect the power on. Of course this event depends on the power supply used .. EtracArticle: 63124
This will work transparently without driver modification provided the driver makes the right OS/BIOS calls to find the device, etc. TC "Hui Li" <huili0154@hotmail.com> wrote in message news:90934db0.0311150404.29bae2ef@posting.google.com... > hmurray@suespammers.org (Hal Murray) wrote in message news:<vra5aj7p86tf32@corp.supernews.com>... > > >I want to design a pci board which will expand one pci slot through a > > >pci-bridge and pci-local bus and get two slot. I wonder if there is > > >any driver problem? say i plug a audio card into the expanded slot? > > > > Depends upon your softwae. I'd expect it to work for most OSes. > > > > It might not for an OS designed to run on small systems, > > say an OS for embedded systems. It might take a special configuration > > flag for the software to include support for the PCI Bridge. > > I am using windows 2000, the two PCI card I am about to use is a > Display card and a FPGA based DSP card, they both have workable > driver, what I wonder is if a PCI-Bridge based slot expansion card can > make these two only ocupy one main PCI-bus slot, with out any change > of driver. > > Do you know if there are any product card can do this? or any > available design for this? > > Thanks > > Hui
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