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
Rajeev wrote: > > When an FPGA pin is tri-stated (high-Z), is the input buffer for > that pin connected or disconnected to the pin ? The input buffer is always connected to the pin. If you do not use the input signal, you ignore it inside the Xilinx FPGA. (I cannot speak for Altera) > > What I'm thinking is: if it's connected, the pin may float to a voltage where > the input buffer draws high current, and I had better provision the pin with > an external pullsup/down. Well, the worst-case current is "only" a few mA, and causes power consumption, but never any damage. With Xilinx, there are optional internal pull-up and pull-down resistors ( 50...100kilohm), even an internal weak keeper that maintains the previously-drive logic level. This was all incorporated for the reason you stated, and also to reduce system noise. > > (Families of interest to me are: Spartan2, 2E, Stratix.) I do not know about Stratix. We call it (affectionately...) a "Virtex-II copy", so it might be similar... Peter Alfke, Xilinx ApplicationsArticle: 53926
Hi All, I'm using an XESS XSA-50 board carrying a spartan II chip. The board comes with a couple of tutorials, one of them drives a seven segment display decoder with 4 bits from the parallel port. The board comes as well with a small utility (XSPORT) that can output bits to the parallel port, and in another mode can increment the output by one when a certain button is pressed. When trying this tutorial everything worked fine, and the seven segment display accurately reflected what's being sent on the parallel port. Then I tried pressing the button that keeps incrementing the output and kept my hand on the keyboard which made the count proceed at the keyboard typmatic rate. After some time the display became corrupt and I couldn't get it back to reflect the bits on the parallel port. I had to cut off power on the board, repower, and reprogram it, and everything became well again. My wonder is, the corrupt display should be something related to the internal FPGA programming, because only 4 lines of the PP are connected to the FPGA, and the 7seg decoder is programmed to display all the combinations (0-F), so it can be caused of a non-handled input combination. So I wonder how programming can change due to the fast rate of the parallel port output. Another possibility that the high rate made the electric characteristic of PP output (current, voltage) change that the FPGA couldn't handle. Can this happen ? do you have another explanation ? Regards,Article: 53927
Hi All, Sorry I'm new to this. Can I fix a certain input to a module or a certain FPGA pin using constraints file or in HDL code? I want to do this for testing, so that for example when implementing DES encryption I don't have to connect real FPGA pins to logic 1 or 0. Instead I want to fix those pins from the Verilog/VHDL code and reprogram it. I hope this is not a homework thing, if so just point me to where to look. Thank you,Article: 53928
Michael, Faults are things like oxide break down, or junction breakdown. They are most likely from weak or originally defective oxides or junctions that eventually broke from eventual overstress (due to their original weak nature). These kinds of defects can not be totally avoided. One can burn in devices, one can overstress devices, but lately there is a lot of data that shows that doing so actually increases field failure rates (if you stress too much, if you stress not much at all, it does very little for the long term failure rate). This whole subject has nothing to do with FPGAs, so you should research semiconductor reliability. Soft fails are another issue, and the following link covers that: http://www.xilinx.com/support/techxclusives/1000-techX35.htm Austin Michael Garvie wrote: > Given your FIT rates for high temperature, high moisture, electrical > overstress, or purely random; what is the fault mode induced? Are these > localized and permanent? Or do they go away with scrubbing? Or are > they at the FPGA subsystem level? > Regards, > Miguel > > Austin Lesea wrote: > > > I suggest that if you have suddenly experienced a failure, that is the > > kind of failure known as "random" and fits well within our FIT rate > > predictions. > > > > As everyone knows, failures do happen, and if the designers, industry > > and foundries could prevent that from happening, we would all be > > happier when we have to design fail-safe systems. > > > > So, until then, fail safe systems fail, by failing to fail safely. > > > > AustinArticle: 53929
Hello, I am looking for an app note or something to explain how to do mixed vhdl and verilog design using Xilinx ISE software. For instance I have an processor in vhdl code and want to integrate that into my verilog design. Dave C.Article: 53930
Hi Wang, I agree with you. Also,the input clamp diodes will become forward-biased if VIN exceeds VCCO by the diode threshold voltage (~0.5V); therefore, leaving VCCO disconnected or setting it to an excessively low voltage could lead to a distorted input signal. To avoid this, VCCO should be greater than the input high voltage (plus any overshoot), less the 0.5V diode voltage. For example, if the maximum input high voltage is 2.5V (including overshoot), VCCO should be greater than 2.5V - 0.5V = 2.0V. The above is true for Virtex-II family and I think it should be true for Spartan-IIE family as well. Austin Lesea and Peter Alfke are the right persons to comment on this. Need your suggestions as well on this. I hope this helps. Regards, SANKET. Wang Xiao-yun <wangxy@fudan.ANTISPAM.edu> wrote in message news:<3E82D188.4080803@fudan.ANTISPAM.edu>... > Hi, Sanjay, > Thanks for your post, but I beg to differ. > > A termination is used to ensure the signal integrity on a transmission > line instead of providing bias current. In a true (P)ECL interface, I > don't think the res. network suggested in the XAPP133 will work, because > the supposed emitter-follower outputs do not have a current path to the > bias voltage. (of course, Xilinx might include bias resistors inside the > chip, but I don't think it's available in Spartan 2E) > Based on my understanding, striping out the PI network on the > transmitter side will only increase the signal swing seen by the > receiver. In another word, Voh and Vol will be even improved without the > PI. The PI may also serve to absorb the reflection resulted from the > impedance mismatch, but I don't think it's the main purpose. > The only purpose for the PI seems only to tweak the voltage swing within > PECL spec. to interface with other standard devices, but will the > Spartan 2E receiver require the trick? That's what I want to know. > > For the second question, I may not have stated clearly. I would like to > know wether a termination of 50ohm to VCCO - 2V (nominally 1.3V in the > case of LVPECL) is also fine for the buffer, instead of supplying 2V to > VCCO. > > Thanks. > > sanjay wrote: > > Hi, > > Answer to your first question. > > Why we need a termination? To ensure that all pins are getting some pull up > > or Pull down current, so that it will not go into high impedance or any > > undefined state before configuring the device. The Termination Res. network > > given in App Note 133 is by considering the Spartan -II E Device > > Characteristics all together. It gives a Min. High and Low Identification on > > the pin. > > So its recommended not to change it. > > > > Secondly you asked with Vcco of 2 V and 50 Ohm Termination, Logically > > speaking it should give Power saving. But this VCCOof 2V is not supported on > > Spartan -IIE for LVEPCL. > > > > Thanks > > Sanjay > >Article: 53931
You are correct, Austin Xilinx FAE from Insight SANKET wrote: > Hi Wang, > I agree with you. Also,the input clamp diodes will become > forward-biased if VIN exceeds VCCO by the diode threshold voltage > (~0.5V); therefore, leaving VCCO disconnected or setting it to an > excessively low voltage could lead to a distorted input signal. To > avoid this, VCCO should be greater than the input high voltage (plus > any overshoot), less the 0.5V diode voltage. For example, if the > maximum input high voltage is 2.5V (including overshoot), VCCO should > be greater than 2.5V - 0.5V = 2.0V. > The above is true for Virtex-II family and I think it should be true > for Spartan-IIE family as well. > Austin Lesea and Peter Alfke are the right persons to comment on > this. > Need your suggestions as well on this. > > I hope this helps. > Regards, > SANKET. > > Wang Xiao-yun <wangxy@fudan.ANTISPAM.edu> wrote in message news:<3E82D188.4080803@fudan.ANTISPAM.edu>... > > Hi, Sanjay, > > Thanks for your post, but I beg to differ. > > > > A termination is used to ensure the signal integrity on a transmission > > line instead of providing bias current. In a true (P)ECL interface, I > > don't think the res. network suggested in the XAPP133 will work, because > > the supposed emitter-follower outputs do not have a current path to the > > bias voltage. (of course, Xilinx might include bias resistors inside the > > chip, but I don't think it's available in Spartan 2E) > > Based on my understanding, striping out the PI network on the > > transmitter side will only increase the signal swing seen by the > > receiver. In another word, Voh and Vol will be even improved without the > > PI. The PI may also serve to absorb the reflection resulted from the > > impedance mismatch, but I don't think it's the main purpose. > > The only purpose for the PI seems only to tweak the voltage swing within > > PECL spec. to interface with other standard devices, but will the > > Spartan 2E receiver require the trick? That's what I want to know. > > > > For the second question, I may not have stated clearly. I would like to > > know wether a termination of 50ohm to VCCO - 2V (nominally 1.3V in the > > case of LVPECL) is also fine for the buffer, instead of supplying 2V to > > VCCO. > > > > Thanks. > > > > sanjay wrote: > > > Hi, > > > Answer to your first question. > > > Why we need a termination? To ensure that all pins are getting some pull up > > > or Pull down current, so that it will not go into high impedance or any > > > undefined state before configuring the device. The Termination Res. network > > > given in App Note 133 is by considering the Spartan -II E Device > > > Characteristics all together. It gives a Min. High and Low Identification on > > > the pin. > > > So its recommended not to change it. > > > > > > Secondly you asked with Vcco of 2 V and 50 Ohm Termination, Logically > > > speaking it should give Power saving. But this VCCOof 2V is not supported on > > > Spartan -IIE for LVEPCL. > > > > > > Thanks > > > Sanjay > > >Article: 53932
"Mike Shonle" <mike@psychonic.net> ha scritto nel messaggio news:To-dndAX1_vqth6jXTWcrg@speakeasy.net... > Why not use one of the TI dsp chips with built-in PWM & > encoder reading, > like the 320F2407? 'f2407 is a fixed point DSP and has something between 100 and 200 MIPS, while c67xx family is floating point and some models go beyond 2000 MFLOPS. They aren't exactly equivalent. ;) Anyway, if you don't need to do high-speed communication between DSP and FPGA, you can do everything asynchronous (i.e. by not using the DSP CLKOUT signal). With a 10$ Spartan II and a 54xx DSP, I reached 80 MB/s transfer rate (40 MHz read/write cycle) without using CLKOUT, only with the strobe signals. -- LorenzoArticle: 53933
Austin Lesea wrote: > > You are correct, > > Austin > > Xilinx FAE from Insight SANKET wrote: > > > Hi Wang, > > I agree with you. Also,the input clamp diodes will become > > forward-biased if VIN exceeds VCCO by the diode threshold voltage > > (~0.5V); therefore, leaving VCCO disconnected or setting it to an > > excessively low voltage could lead to a distorted input signal. To > > avoid this, VCCO should be greater than the input high voltage (plus > > any overshoot), less the 0.5V diode voltage. For example, if the > > maximum input high voltage is 2.5V (including overshoot), VCCO should > > be greater than 2.5V - 0.5V = 2.0V. There is also the detail of Common Mode voltage range of the differential input. Commonly, this is not a fancy rail-rail comparitor, but uses P-FETs on the IPs, so you get a common mode range from 0V to Vcc-(ThresholdRelatedValue) Presumably, Vcco powers the IO comparitor, so Vcco should be comfortably above the peak linear region IP swing. The Xilinx experts will fill in the details for particular models. -jgArticle: 53934
"Kolja Sulimma" <kolja@bnl.gov> wrote in message news:25c81abf.0303260445.2e029c67@posting.google.com... > > > So in the real world, gates are not a good way to measure a chip. You > > > will do much better to fit your design to the chip and see how well it > > > fits. Or at least do a preliminary job of estimating by trying to > > > "guesstimate" the details of how your design will fit in the chip. (snip) > It should also be noted that these numbers usually include an > unexpected factor of two: > A 2-input AND gate counts as two equivalant gates, > a 3-input and counts as three, and so on. > (Apperently someone decided that it would be to complicated > to call a 3-input gate 1.5 eqivalent gates.) > > This nomenclature does not come from marketing but from academia and > is related to the literal count metric for circuit size. > > A Flip-Flop typically counts as 6 gates. > And some vendors count a 4kBit Block-RAM as 4096 Flip-FLops. As far as I know, the convention since CMOS is to count the transistors and divide by the number in a two input NAND gate, which is 4 for CMOS. For reasonably N, an N input CMOS NAND gate takes 2N transistors. In TTL, an AND gate is pretty much a NAND followed by an inverter, and probably does count as two. But in TTL, an N input NAND takes the same number of transistors and a 2 input NAND. If one wanted a count of logic complexity, (how hard it is to design), as opposed to how hard it is to fit on a chip, the numbers might be different. Also, they work out completely differently for FPGA's. -- glenArticle: 53935
Peter Alfke wrote > With Xilinx, there are optional internal pull-up and pull-down resistors > ( 50...100kilohm), even an internal weak keeper that maintains the > previously-drive logic level. Is the weak keeper engaged under all circumstances? It certainly seems that way if I look at the pins with a very high impedence probe.Article: 53938
Inspired by Goedel I conclude that there are more gate count metrics then there are design to measure.... According to this application note: http://www.xilinx.com/xapp/xapp059.pdf Peter is right (at least for Xilinx measurements) Here are the numbers: Function Gate_Count NAND2 1 MUX2 4 XOR3 6 XOR4 9 FA 9 DFF 6 DFF+Reset 8 DFF+R+CE 12 Kolja Sulimma Peter Alfke <peter@xilinx.com> wrote in message news:<3E81E8A1.3D9ABC13@xilinx.com>... > When I was involved, we reduced everything to 2-input gates, and a 2-XOR > became 4 gates. > Kolja Sulimma wrote: > > A 2-input AND gate counts as two equivalant gates, a 3-input and > > counts as three, and so on.Article: 53939
Jim, It is a 'fancy' rail to rail cmos diff amp, but it still prefers to stay out of cutoff for fastest speed & performance, but it functions fine rail to rail. Austin Jim Granville wrote: > Austin Lesea wrote: > > > > You are correct, > > > > Austin > > > > Xilinx FAE from Insight SANKET wrote: > > > > > Hi Wang, > > > I agree with you. Also,the input clamp diodes will become > > > forward-biased if VIN exceeds VCCO by the diode threshold voltage > > > (~0.5V); therefore, leaving VCCO disconnected or setting it to an > > > excessively low voltage could lead to a distorted input signal. To > > > avoid this, VCCO should be greater than the input high voltage (plus > > > any overshoot), less the 0.5V diode voltage. For example, if the > > > maximum input high voltage is 2.5V (including overshoot), VCCO should > > > be greater than 2.5V - 0.5V = 2.0V. > > There is also the detail of Common Mode voltage range of the > differential > input. Commonly, this is not a fancy rail-rail comparitor, but uses > P-FETs on > the IPs, so you get a common mode range from 0V to > Vcc-(ThresholdRelatedValue) > Presumably, Vcco powers the IO comparitor, so Vcco should be > comfortably > above the peak linear region IP swing. The Xilinx experts will fill in > the > details for particular models. > > -jgArticle: 53940
Tim, Your choice. The HSWAP_EN pin on Virtex II and II Pro enables the weak pullups while the part is configuring. After that, they are enabled if you have set the attribute of the IO pin to do so. Austin Tim wrote: > Peter Alfke wrote > > > With Xilinx, there are optional internal pull-up and pull-down resistors > > ( 50...100kilohm), even an internal weak keeper that maintains the > > previously-drive logic level. > > Is the weak keeper engaged under all circumstances? > It certainly seems that way if I look at the pins > with a very high impedence probe.Article: 53941
Hi , Well the basic question is that I would like to interface a XILINX Virtex fpga on a fpga development board to a SUN machine .I want the FPGA to act as a hardware accelerator,wherein I can do computationally intensive parts of an algorithm on the fpga and the rest on the SUN workstation.So thus there will have to be an interface through interrupts when i come across those functions to be done using hardware.The result of these hardware operations has to be stored in a memory which should be accessible by the SUN workstation,through a common bus. I was thinking that I could perhaps use the PCI/SBus interface for this purpose and wanted to find out about any off the shelf products and help from somebody who perhaps has done somethng similar. Thanks, SriramArticle: 53942
Sriram wrote: > Hi , > Well the basic question is that I would like to interface a XILINX > Virtex fpga on a fpga development board to a SUN machine .I want the > FPGA to act as a hardware accelerator,wherein I can do computationally > intensive parts of an algorithm on the fpga and the rest on the SUN > workstation.So thus there will have to be an interface through > interrupts when i come across those functions to be done using > hardware.The result of these hardware operations has to be stored in a > memory which should be accessible by the SUN workstation,through a > common bus. > > I was thinking that I could perhaps use the PCI/SBus interface for > this purpose and wanted to find out about any off the shelf products > and help from > somebody who perhaps has done somethng similar. Hi Sriram, What you propose is certainly feasible. You should check the traffic on this newsgroup from the last couple of days, and make sure you read the thread about FPGA coprocessors. It covers a lot of interesting concepts that are relevant to your inquiry. It's easy to get carried away saying "I'm putting the inner loop of my algorithm on an FPGA and I'll get a 100x speedup" but forgetting that the hardest part may be the IO involved in getting data to and from the FPGA. You start needing things like DMA controllers, bus mastering and so on. Things can get very complex, very quickly. I think that discussion also covered some of the commercial vendors of PCI-based FPGA coprocessor/accelerator cards. Nallatech , Annapolis Micro Systems are a couple. I'm not sure about driver support for Suns though. Regards, JohnArticle: 53943
Hi, when I write something like this:
(lots of stuff in example snipped)
module lcd_text_driver(clock, text, text_strobe,
lcd_e, lcd_rw, lcd_rs,
lcd_read_data, lcd_write_data, lcd_dir, test);
input clock;
output lcd_e, lcd_rw, lcd_rs;
output [3:0] lcd_write_data;
reg lcd_e, lcd_rw, lcd_rs;
reg [3:0] lcd_write_data;
reg [19:0] state;
parameter [5:0] lcd_idle = 6'b00_0000;
parameter [5:0] lcd_function = 6'b00_0001;
parameter [5:0] lcd_display_on_off = 6'b00_0010;
//etc...
always @(posedge clock)
begin
case(state)
lcd_idle:
// snipped etc...
state <= #1 lcd_function;
lcd_function:
begin
lcd_e <= #1 1;
lcd_write_data [3:0] <= #1 4'b0010;
// snipped etc...
state <= #1 lcd_display_on_off;
end
lcd_display_on_off:
begin
lcd_e <= #1 1;
// commenting this out cause error to dissappear.
lcd_write_data [3:0] <= #1 4'b0000;
// snipped etc...
state <= # lcd_idle;
end
//etc...
endcase
endmodule
The 'lcd_write data' causes xst(4) to report a 'multiple sourced' error.
The same thing on iverilog syntesizes OK.
If I comment out 'lcd_write_data [3:0] <= #1 4'b0000;' in one of
each 'cases' xste is OK.
Is it not allowed to use a reg of more then 1 bit wide in a case in webpack?
Or what am I doing wrong?
JP
Article: 53944Thank you all for your insightful comments. I will do my design as following: The VCCO will be supplied with 3V3, which is suggested from the datasheet. (Actually, this is the main reason I choose LVPECL instead of LVDS to avoid using extra 2V5) The LVPECL interconnection between Spartan2E will be dealt with as (standard) LVDS style. That means the PI network on the transmitter side will be removed and only the 100ohm end termination will be provided. In this case, the receiver may see a rail-to-rail voltage swing (0 - 3V3?) but I expected it will not cause further harm based on the information provided. The large voltage swing will cause more problems of crosstalk, but I'm not going to run the pair at very high datarate and I'm sure it can be tolerated. On the other hand, I will be more comfortable without the PI network, because I expect it would become a big burden when I'm going to use more than 80 diff. pairs on a single chip. Will this scheme work? Austin Lesea wrote: > Jim, > > It is a 'fancy' rail to rail cmos diff amp, but it still prefers to stay out > of cutoff for fastest speed & performance, but it functions fine rail to > rail. > > Austin >Article: 53945
Austin Lesea wrote: > > Jim, > > It is a 'fancy' rail to rail cmos diff amp, but it still prefers to stay out > of cutoff for fastest speed & performance, but it functions fine rail to > rail. Good to hear that - is that true of all DiffMode Xilinx FPGAs ? Any plots of Speed vs common mode ? - we have an app that could use rail-rail tolerance, but may still use external LVDS to get ESD protection ( or add more ESD protection to the FPGA ) -jgArticle: 53946
kenm@morro.co.uk (Ken Morrow) wrote in message news:<20f8de50.0303231355.40cf7aef@posting.google.com>... > I am currently using ModelSim 5.6e PE on a PC licensed from a dongle. > > Unfortunately, this will only allow one instance of ModelSim to simulate > at a time. This is currently proving a problem as I am running some big sims. > I cannot do any other sims on small blocks for the few hours that my big sims > are running. > > A year or so ago I tried using ModelSim XE along with PE on the same PC, > but never managed to get them both to work at the same time. > > Has anyone tried this recently with any sucess? Just a suggestion: get another computer. You'll slow down BOTH sims if you get both running at the same time. --aArticle: 53947
Jan,
I am not exactly sure what is causing this problem, but there are there
things I don't like with your RTL code.
1) The state machine doesn't have a way to reset itself.
"always @(posedge clock)" section doesn't contain a reset input to
initialize the state machine.
I will change that to,
__________________________________________________________
always @ (posedge clock or negedge reset_n) begin
if (reset_n == 1'b0) begin
state <= #1 lcd_function;
// And you may want to reset bunch of other FFs here.
end
else begin
case(state)
lcd_idle: begin
if () begin
end
lcd_function: begin
// snipped
state <= #1 lcd_display_on_off;
end
lcd_display_on_off: begin
// snipped
state <= # lcd_idle;
end
endcase
end
end
__________________________________________________________
2) The bit length of state[19:0] register and the state machine states
(lcd_idle, lcd_function, lcd_display_on_off) don't match.
I suppose this is a problem of Verilog that the bit length
matching isn't strict unlike VHDL (Despite that, I still prefer Verilog
over VHDL.).
Either you will like to enlarge those state machine states to 20 bits,
or shorten the state register to 6 bits.
3) Your state machine doesn't have a default state in your case
statement.
Somewhere in your case statement, you will like to add a default
state.
__________________________________________________________
default: begin
state <= #1 lcd_function;
end
__________________________________________________________
I am not sure if this default statement is needed (I am sure
someone else who is more familiar about Verilog than myself can answer
that.), but it is safer to have one.
Kevin Brace (If someone wants to respond to what I wrote, I prefer if
you will do so within the newsgroup.)
Jan Panteltje wrote:
>
> Hi, when I write something like this:
>
> (lots of stuff in example snipped)
>
> module lcd_text_driver(clock, text, text_strobe,
> lcd_e, lcd_rw, lcd_rs,
> lcd_read_data, lcd_write_data, lcd_dir, test);
>
> input clock;
> output lcd_e, lcd_rw, lcd_rs;
> output [3:0] lcd_write_data;
>
> reg lcd_e, lcd_rw, lcd_rs;
> reg [3:0] lcd_write_data;
> reg [19:0] state;
>
> parameter [5:0] lcd_idle = 6'b00_0000;
> parameter [5:0] lcd_function = 6'b00_0001;
> parameter [5:0] lcd_display_on_off = 6'b00_0010;
> //etc...
>
> always @(posedge clock)
> begin
> case(state)
> lcd_idle:
> // snipped etc...
> state <= #1 lcd_function;
>
> lcd_function:
> begin
> lcd_e <= #1 1;
> lcd_write_data [3:0] <= #1 4'b0010;
> // snipped etc...
> state <= #1 lcd_display_on_off;
> end
> lcd_display_on_off:
> begin
> lcd_e <= #1 1;
>
> // commenting this out cause error to dissappear.
> lcd_write_data [3:0] <= #1 4'b0000;
> // snipped etc...
>
> state <= # lcd_idle;
> end
> //etc...
> endcase
> endmodule
>
> The 'lcd_write data' causes xst(4) to report a 'multiple sourced' error.
> The same thing on iverilog syntesizes OK.
>
> If I comment out 'lcd_write_data [3:0] <= #1 4'b0000;' in one of
> each 'cases' xste is OK.
> Is it not allowed to use a reg of more then 1 bit wide in a case in webpack?
> Or what am I doing wrong?
>
> JP
Article: 53948Dave, Synthesize the VHDL module without I/O pads being added. Synthesize the Verilog portion of it a black box of the VHDL module written in Verilog. Kevin Brace (If someone wants to respond to what I wrote, I prefer if you will do so within the newsgroup.) Dave Colson wrote: > > Hello, > > I am looking for an app note or something to explain how to do mixed > vhdl and verilog design using Xilinx ISE software. > > For instance I have an processor in vhdl code and want to integrate > that into my verilog design. > > Dave C.Article: 53949
Oops, I forgot to mention that you need to tell NGDBUILD where the netlist generated from the VHDL part of the design is located. Kevin Brace (If someone wants to respond to what I wrote, I prefer if you will do so within the newsgroup.)
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