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
laserbeak43 wrote: > I'm new to FPGAs I just bought a Spartan 3E Starter Kit and I'm > looking for documentation on Schematic capture with ISE or whatever > would work for a good tutorial. It seems VERY hard to find ANY > documentation though. I did find a starter video from digilent, but > that was very short and seemed to be more of an intro to dataflow > programming. > Can anyone point me in the right direction? Schematic capture for FPGA design entry is moribund. Consider learning vhdl or verilog instead. If schematics are non-negotiable, consider quartus: multimedia.ece.uic.edu/wahmad/quartus_ii_tutorial.pdf Good luck. -- Mike TreselerArticle: 134276
On Aug 4, 8:17 am, Mike Treseler <mtrese...@gmail.com> wrote: > laserbeak43 wrote: > > I'm new to FPGAs I just bought a Spartan 3E Starter Kit and I'm > > looking for documentation on Schematic capture with ISE or whatever > > would work for a good tutorial. It seems VERY hard to find ANY > > documentation though. I did find a starter video from digilent, but > > that was very short and seemed to be more of an intro to dataflow > > programming. > > Can anyone point me in the right direction? > > Schematic capture for FPGA design entry is moribund. > Consider learning vhdl or verilog instead. > If schematics are non-negotiable, consider quartus: > multimedia.ece.uic.edu/wahmad/quartus_ii_tutorial.pdf > Good luck. > > -- Mike Treseler Since the OP already bought the Xilinx stuff, he may want to open ISE (or WebPack) and under Help --> Tutorials --> Tutorials on the Web, he can find what is available from Xilinx. Look for "ECS" schematics. By the way I have not looked at these myself. I too use HDL rather than schematics since I "upgraded" from version 4.1 - the last Foundation version with Aldec schematics. Also go to http://forums.xilinx.com/ and check out all of the chatter on schematics. In my opinion, the ECS schematics are not ready for prime time. The associated documentation is not likely to be better. Oh, and before you get ideas of using Foundation 4.1 schematics, it is no longer available from Xilinx due to a termination of their agreement with Aldec. Aldec has wonderful new software that supports Xilinx parts and others, but it would cost a lot more than a good Altera evaluation board and a copy of Quartus. Just my 2 cents, GaborArticle: 134277
Hi, I converted some vhdl files from text to graphics and note that connections to signals in records does not get a visual connection to the pins where the single wires are supposed to be connected. They are just open, and there are no input pins for the records entering the block placed. I inspect the generated vhdl and symbol, and they are added correctly to the symbol and to the output rtl. Anybody know if this is a "feature" or is there an option that I need to set somewhere to see the connections? I use version 2007.1a. -- SvennArticle: 134278
"Svenn Are Bjerkem" <svenn.bjerkem@googlemail.com> wrote in message news:7e7320a6-ee66-4285-9c61-20f16670f54a@d1g2000hsg.googlegroups.com... > Hi, > I converted some vhdl files from text to graphics and note that > connections to signals in records does not get a visual connection to > the pins where the single wires are supposed to be connected. They are > just open, and there are no input pins for the records entering the > block placed. I inspect the generated vhdl and symbol, and they are > added correctly to the symbol and to the output rtl. > > Anybody know if this is a "feature" or is there an option that I need > to set somewhere to see the connections? I use version 2007.1a. > > -- > Svenn I am not sure I understand you 100%, records are supported and if you import some VHDL and convert it to graphics all should be OK. However, you are right that graphically you can not select an element from a record and connect it to a blue/green block pin. So what happens is that you get a yellow block with a "signal<=record.element;" type of assignment. This is a real shame and proper record support is something I have been asking for it since version 2004 :-( Hans www.ht-lab.comArticle: 134279
Hi I'm trying to debug something on somebody's FPGA design using Chipscope, and no matter which clock I select for chipscope to use, I get the following error: ERROR:Place:37 - This design is unroutable. A Global clock component <mbox_ddr2a/infrastructure_top0/clk_dcm0/BUFG_CLK90> configured as a selectable mux is placed in site BUFGMUX0. This configuration requires that the Global clock site BUFGMUX1 either be empty or contain a Global buffer or mux with the inputs IN0 and IN1 configured in a specific manner. The IN0 and IN1 inputs must either not be driven by any signal or driven by the same signals as the paired clock buffer IN1 and IN0 pins respectively in order to route both of the inputs. In other words the input signal for IN0 on one buffer must be the same as the input signal driving IN1 on the other buffer (or one of them must not be driven) to place the two buffers in the paired sites. The site BUFGMUX1 has the Global buffer <mbox_ddr2a/infrastructure_top0/clk_dcm0/ BUFG_CLK0> placed there. Theres no information about this on their site. Any suggestions?Article: 134280
On Aug 1, 2:22=A0pm, andersod2 <thechrisander...@gmail.com> wrote: > Hi, just wondering about these...what are they, what hardware is > involved, what are the advantages etc... > > thanks If you want a low-cost board to experiment with both a Xilinx FPGA and a Cypress PSoC, try this $39 kit: www.em.avnet.com/spartan3a-evl BryanArticle: 134281
On Aug 4, 10:18 am, "zoopli...@gmail.com" <zoopli...@gmail.com> wrote: > Hi I'm trying to debug something on somebody's FPGA design using > Chipscope, and no matter which clock I select for chipscope to use, I > get the following error: > > ERROR:Place:37 - This design is unroutable. A Global clock component > <mbox_ddr2a/infrastructure_top0/clk_dcm0/BUFG_CLK90> configured as > a selectable mux is placed in site BUFGMUX0. This > configuration requires that the Global clock site BUFGMUX1 either > be empty or contain a Global buffer or mux with the > inputs IN0 and IN1 configured in a specific manner. The IN0 and IN1 > inputs must either not be driven by any signal or > driven by the same signals as the paired clock buffer IN1 and IN0 > pins respectively in order to route both of the > inputs. In other words the input signal for IN0 on one buffer must > be the same as the input signal driving IN1 on > the other buffer (or one of them must not be driven) to place the > two buffers in the paired sites. The site BUFGMUX1 > has the Global buffer <mbox_ddr2a/infrastructure_top0/clk_dcm0/ > BUFG_CLK0> placed there. > > Theres no information about this on their site. Any suggestions? This usually indicates that you need to do some hand placement of the clock components. In Virtex II and Spartan 3, the BUFGMUX components come in pairs with common input routing. So if you use one half of the pair as a mux, requiring both inputs to connect to live signals, the other half of the pair can only work if it buffers one of the same signals connected to the mux. The placer is not always smart enough to find a workable combination of BUFGMUX locations. It is interesting that you get this when you add Chipscope to the design, which should not be adding any more global clock resources. It seems that your previous implementation without Chipscope just lucked out with the placer. What I would recommend is to look at the "working" placement with the FPGA editor and lock down all instantiated DCM and BUFG / BUFGMUX components to their current locations. This should theoretically give you a working placement when you add more logic to the design, including ChipScope. HTH, GaborArticle: 134282
On Aug 4, 4:07=A0am, chrisde...@gmail.com wrote: > Hi, > =A0 =A0I am trying to create a mex file that does fixed point FFT (512 > point?). I am generally ok with creating a C code in single precision > to compute the the result and have ensured that it works fine as i get > the correct result. (i read it back and plotted it in matlab.) > =A0 =A0 the problem comes in when i try to convert it to fixed point. My > input data is 24 bits integer. In addition, I take the sine and cosine > twiddles to also be 24 bits... I do the cos(2*pi*n/N) and sin(2*pi/N) > for n from 0 to 255 the multply the result by ((2^23)-1) and store it > in a look up table. > > =A0 =A0 What i really dun quite understand is how the scaling factors > work. In FFT books, they generally say that the output from each scale > should maybe be scaled by 1 bit to pre-empt bit growth problems. Also, > for unscaled bit-growth, it generally grows by log2(N) for an N point > FFT. But how does that work? > =A0 =A0 What i see here is the following: > > 1) 24 bit input data. If i dun convert it to anything, it becomes Q.24 > format right? > 2) 24 bit input data x 24 bit twiddle factor (Q.24 also). this becomes > 48 bits. to prevent overflow, i scale by 24 say. remember that when you do "fixed point" arithmetic, you are really doing INTEGER arithmetic where *you* are knowledgable about where the binary point lies. now i would expect your data is instead Q1.23 so that there are 23 fractional bits and on bit left of the binary point for sign. the implied range is then from -1.000000 oto +0.99999988 > > But this is too much and the output frequency spectrum becomes a mess. > I would forsee plenty of precision loss. If i scale by 1 from the > output of each stage, then the FFT gets clipped. > > any ideas?what did i go wrong here? =A0:( you might need to consider clipping in each pass of the FFT. perhaps you need to divide by 2 in the output of each butterfly, then your DFT has a 1/N factor in front of the summation. but then in the iDFT there is no divide by two and your data amplitude grows. or perhaps you split the difference and divide by two only in every other pass of the FFT. then your DFT definition (and the iDFT) both have 1/sqrt(N) in the definition. this sorta thing you have to check out with the nature of your data and see what works best. or you can try "block floating-point" arithmetic. r b-jArticle: 134283
I've got a GTX board-layout question, that I thought the group might have some experience with. A coworker of mine is working on a design that includes Virtex-5 GTX transceivers. One of the requirements on the "GTX Reference Clock Checklist" ( http://www.xilinx.com/support/documentation/user_guides/ug198.pdf ) is "Provide AC coupling between the oscillator output pins and the dedicated GTX_DUAL clock input pins" In laying out the board, it's much easier to put the AC coupling cap near the oscillator output pins than it is to put it near the clock in put pins. Is there any issue with doing so? Usually I've seen the cap placed near the input pins, not sure if that were rule-of-thumb or if there's a good reason to do so. i.e. do ~Osc~--|>--| |----PCBLine--------FPGA_REFCLK-- and ~Osc~--|>---------PCBLine----| |-FPGA_REFCLK-- both work? Thanks, --JoshArticle: 134284
On Aug 4, 11:40 am, Josh <mo...@ll.mit.edu> wrote: > I've got a GTX board-layout question, that I thought the group might > have some experience with. > > A coworker of mine is working on a design that includes Virtex-5 GTX > transceivers. One of the requirements on the "GTX Reference Clock > Checklist" (http://www.xilinx.com/support/documentation/user_guides/ug198.pdf) > > is > > "Provide AC coupling between the oscillator output pins and the > dedicated GTX_DUAL clock input pins" > > In laying out the board, it's much easier to put the AC coupling cap > near the oscillator output pins than it is to put it near the clock in > put pins. Is there any issue with doing so? Usually I've seen the cap > placed near the input pins, not sure if that were rule-of-thumb or if > there's a good reason to do so. > > i.e. > do > ~Osc~--|>--| |----PCBLine--------FPGA_REFCLK-- > > and > > ~Osc~--|>---------PCBLine----| |-FPGA_REFCLK-- > > both work? > > Thanks, > > --Josh Think of the capacitors as wires that only let through high frequency. At any frequency requiring termination, therefore they are pretty much just wires. So the answer is that it really doesn't matter where they go along the line as long as the package itself does not create a big impedance bump (i.e. use small caps like 0402). Regards, GaborArticle: 134285
Leon wrote: > Hi all, > > I am doing a project involving PCI9054. > > I meet a problem of interrupt. I wanna assert a PCI interrupt using the > LINT# pin which is set as input with the INTCSR register being setting > as: > 0X0f000900. But when I pull down the level of LINT# that is drived by > FPGA, the INTCSR becomes 0X0f000100, that is, INTCSR[11](local interrupt > input enable) is cleared and INTCSR[15](local input interrupt active) fails > to be set 1. And also the interrupt handler is not called. I have no idea > what the reason. > > However, when I set INTCSR as 0X0f000800 (PCI interrupt is not enabled) > and then pull down LINT#, the INTCSR can come to the ideal value: > 0X0f008800. I dont know its the reason of WinDriver diagnostic program or > the PCI9054 itself. > > Any advice will be helpful, Thank u very much! > > Leon, While that's certainly not enough information for me to offer you any help, I'll throw out that in my experience PLX, who makes the only PCI9054 that I know of, has fairly responsive technical support when you send them an email. They'll take a couple days to get back to you, but what you get will be both thought out and relevant to your question. Have you tried their guys yet? -- Rob Gaddi, Highland Technology Email address is currently out of orderArticle: 134286
> > Schematic capture for FPGA design entry is moribund. > > Consider learning vhdl or verilog instead. > > If schematics are non-negotiable, consider quartus: > > multimedia.ece.uic.edu/wahmad/quartus_ii_tutorial.pdf > > Good luck. > > > =A0 =A0 -- Mike Treseler Hmm, so i've heard. Everyone says Xilinx stuff is bad for beginners and i must admit, I've been doing nothing but troubleshooting ever since i got this board, what a headache. > Since the OP already bought the Xilinx stuff, he may want to > open ISE (or WebPack) and under Help --> Tutorials --> > Tutorials on the Web, he can find what is available from > Xilinx. =A0Look for "ECS" schematics. =A0By the way I have > not looked at these myself. =A0I too use =A0HDL rather than > schematics since I "upgraded" from version 4.1 - the > last Foundation version with Aldec schematics. =A0Also > go tohttp://forums.xilinx.com/and check out all of > the chatter on schematics. =A0In my opinion, the ECS > schematics are not ready for prime time. =A0The > associated documentation is not likely to be better. > > Oh, and before you get ideas of using Foundation > 4.1 schematics, it is no longer available from Xilinx > due to a termination of their agreement with Aldec. > > Aldec has wonderful new software that supports > Xilinx parts and others, but it would cost a lot more > than a good Altera evaluation board and a copy of > Quartus. > > Just my 2 cents, > Gabor I think i'm gonnna sell this board and go for an Altera board. but i'll try that first. thanks guys.Article: 134287
Svenn Are Bjerkem wrote: > I converted some vhdl files from text to graphics and note that > connections to signals in records does not get a visual connection to > the pins where the single wires are supposed to be connected. They are > just open, and there are no input pins for the records entering the > block placed. I inspect the generated vhdl and symbol, and they are > added correctly to the symbol and to the output rtl. > Anybody know if this is a "feature" or is there an option that I need > to set somewhere to see the connections? I use version 2007.1a. The last time I evaluated a text to graphics application, I got so annoyed about having to type critical bits of code into little graphical boxes that I went back to emacs vhdl-mode and never looked back. The vhdl-mode browser (speedbar) sorts out locating, editing and compiling the source files for this or that vhdl design unit. It also helps with creating structural entities. The quartus rtl viewer does a good job for graphical browsing and for creating postscript schematic views from the synthesis code. A key point is that such viewers are a post-process on working code, rather than a nasty lump in the design description itself. -- Mike TreselerArticle: 134288
robert bristow-johnson wrote: (snip) > remember that when you do "fixed point" arithmetic, you are really > doing INTEGER arithmetic where *you* are knowledgable about where the > binary point lies. now i would expect your data is instead Q1.23 so > that there are 23 fractional bits and on bit left of the binary point > for sign. the implied range is then from -1.000000 oto +0.99999988 That is pretty much true for assembly and C programming. There are programming languages that do fixed point arithmetic where the compiler keeps track of the radix point. (Not necessarily binary.) You still have to be a little careful to know where overflow might occur. -- glenArticle: 134289
chrisdekoh@gmail.com wrote: (snip) > the problem comes in when i try to convert it to fixed point. My > input data is 24 bits integer. In addition, I take the sine and cosine > twiddles to also be 24 bits... I do the cos(2*pi*n/N) and sin(2*pi/N) > for n from 0 to 255 the multply the result by ((2^23)-1) and store it > in a look up table. > What i really dun quite understand is how the scaling factors > work. In FFT books, they generally say that the output from each scale > should maybe be scaled by 1 bit to pre-empt bit growth problems. Also, > for unscaled bit-growth, it generally grows by log2(N) for an N point > FFT. But how does that work? First you have to be able to do the multiply. If you multiply two numbers, each with 23 bits after the binary point the product has 46 bits after the binary point. You probably don't want all those bits, but C doesn't have a good way to get the right bits. If you have the bits, it is best to expand by one bit for each stage, such that you avoid overflow but still keep all the significant bits. You can figure out at the end which bits you really want. Otherwise, you need to know more about the actual data. In most cases, bit growth will be somewhat slower, except for the DC (0) term, which can fairly easily accumulate large values. -- glenArticle: 134290
zooplibob@gmail.com wrote: > Hi I'm trying to debug something on somebody's FPGA design using > Chipscope, and no matter which clock I select for chipscope to use, I > get the following error: > ERROR:Place:37 - This design is unroutable... > Theres no information about this on their site. Any suggestions? The chipscope hardware requires a few luts, flops, and wires. This can perturb a tight design to be an routable one. Your choices are []Run a sim to find the bug. Chances are the fix will be much smaller than the chipscope logic. []Add some testpoint pins for debugging instead of chipscope. []Relax the placement constraints and let the router have another go. If it doesn't fit try a larger device with the same pinout. []Fix up the routing manually as Gabor suggests. -- Mike TreselerArticle: 134291
Does anyone have any guidance into writing the timing constraints in the UCF file to use RGMII on the ML405 development board from Xilinx? Here is the relevant section in the UCF file: #### Module Ethernet_MAC constraints NET MDC_0 LOC = H11 | IOSTANDARD=LVCMOS33; NET MDIO_0 LOC = K13 | IOSTANDARD=LVCMOS33; NET phy_rst_n LOC = J13 | IOSTANDARD=LVCMOS33; Net phy_rst_n TIG; NET RGMII_TXD_0<3> LOC = G15 | IOSTANDARD=LVCMOS33 | SLEW=FAST; NET RGMII_TXD_0<2> LOC = H12 | IOSTANDARD=LVCMOS33 | SLEW=FAST; NET RGMII_TXD_0<1> LOC = H16 | IOSTANDARD=LVCMOS33 | SLEW=FAST; NET RGMII_TXD_0<0> LOC = J16 | IOSTANDARD=LVCMOS33 | SLEW=FAST; NET RGMII_TX_CTL_0 LOC = K12 | IOSTANDARD=LVCMOS33 | SLEW=FAST; NET RGMII_TXC_0 LOC = D15 | IOSTANDARD=LVCMOS25 | SLEW=FAST; NET RGMII_RXD_0<3> LOC = G16 | IOSTANDARD=LVCMOS33; NET RGMII_RXD_0<2> LOC = H14 | IOSTANDARD=LVCMOS33; NET RGMII_RXD_0<1> LOC = G14 | IOSTANDARD=LVCMOS33; NET RGMII_RXD_0<0> LOC = J15 | IOSTANDARD=LVCMOS33; NET RGMII_RX_CTL_0 LOC = J14 | IOSTANDARD=LVCMOS33; NET RGMII_RXC_0 LOC = F15 | IOSTANDARD=LVCMOS25; NET phy_rst_n TIG; #### New GMAC Coregen Derived Constraints NET "*tx_gmii_mii_clk*" TNM_NET = "clk_phy_tx_clk0"; NET "*tx_gmii_mii_clk_in_0_i" TNM_NET = "clk_phy_tx_clk0"; NET "*tx_gmii_mii_clk_out_0_i" TNM_NET = "clk_phy_tx_clk0"; TIMESPEC "TS_phy_tx_clk0" = PERIOD "clk_phy_tx_clk0" 7200 ps HIGH 50 %; NET "*gmii_rx_clk*" TNM_NET = "clk_phy_rx_clk0"; TIMESPEC "TS_phy_rx_clk0" = PERIOD "clk_phy_rx_clk0" 7200 ps HIGH 50 %; NET "*tx_client_clk*" TNM_NET = "clk_client_tx_clk0"; TIMESPEC "TS_client_tx_clk0" = PERIOD "clk_client_tx_clk0" 7200 ps HIGH 50 %; NET "*rx_client_clk*" TNM_NET = "clk_client_rx_clk0"; TIMESPEC "TS_client_rx_clk0" = PERIOD "clk_client_rx_clk0" 7200 ps HIGH 50 %; NET "*mii_tx_clk*" TNM_NET = "clk_mii_tx_clk0"; TIMESPEC "TS_mii_tx_clk0" = PERIOD "clk_mii_tx_clk0" 25000 ps HIGH 50 %; # Place flip flops in IOBs INST "*gmii0?RXD_TO_MAC*" IOB = true; INST "*gmii0?RX_DV_TO_MAC" IOB = true; INST "*gmii0?RX_ER_TO_MAC" IOB = true; # IDELAY on data path to align it with the clock INST "*gmii_rxd?_delay" IOBDELAY_TYPE = FIXED; INST "*gmii_rx_dv_delay" IOBDELAY_TYPE = FIXED; INST "*gmii_rx_er_delay" IOBDELAY_TYPE = FIXED; INST "*gmii_rxd?_delay" IOBDELAY_VALUE = 0; INST "*gmii_rx_dv_delay" IOBDELAY_VALUE = 0; INST "*gmii_rx_er_delay" IOBDELAY_VALUE = 0; INST "*gmii_rx_clk_?_delay" IOBDELAY_TYPE = FIXED; INST "*gmii_rx_clk_0_delay" IOBDELAY_VALUE =31 ; # Need to TIG between the LocalLink clock and the rx_client and tx_client clocks NET "*/LlinkTemac0_CLK*" TNM_NET = "LLCLK"; TIMESPEC "TS_LL_CLK_2_RX_CLIENT_CLK" = FROM LLCLK TO clk_client_rx_clk0 8000 ps DATAPATHONLY; TIMESPEC "TS_LL_CLK_2_TX_CLIENT_CLK" = FROM LLCLK TO clk_client_tx_clk0 8000 ps DATAPATHONLY; TIMESPEC "TS_RX_CLIENT_CLK_2_LL_CLK" = FROM clk_client_rx_clk0 TO LLCLK 10000 ps DATAPATHONLY; TIMESPEC "TS_TX_CLIENT_CLK_2_LL_CLK" = FROM clk_client_tx_clk0 TO LLCLK 10000 ps DATAPATHONLY; I have tried the timing constraints generated from the wizard and from the data sheet. In both cases I get errors like this: ERROR:Place:872 - Delay element "TriMode_MAC_GMII/TriMode_MAC_GMII/V4HARD_SYS.I_TEMAC/ SINGLE_RGMII2.I_EMAC_TO P/rgmii_rxd_rising_0_i<0>" has been placed at ILOGIC_X1Y95 due to the following location constraint on component "RGMII_RXD_0<0>": COMP "RGMII_RXD_0<0>" LOCATE = SITE "J15" LEVEL 1 However, the delay controller that calibrates this delay element has not been used. Please instantiate a delay controller and apply appropriate location constraint, or instantiate one delay controller for the design with out any location constraint. Please refer to the usage document to use the controller efficiently. Thanks! -GeorgeArticle: 134292
Hi, If you have the time, I invite you to contact me directly (privately) to discuss your experience with the Spartan-3E Starter Kit. As you might imagine, it is intended for "starters" and not intended to generate frustration! I know you are interested in schematic based design entry, so the following resource may be of limited interest (but I'll include it anyway): http://www.engr.sjsu.edu/crabill I look forward to hearing from you, Eric Crabill ===== "laserbeak43" <laserbeak43@gmail.com> wrote in message news:38faf0eb-3746-49f1-84f3-1720ba98d399@r66g2000hsg.googlegroups.com... > > Schematic capture for FPGA design entry is moribund. > > Consider learning vhdl or verilog instead. > > If schematics are non-negotiable, consider quartus: > > multimedia.ece.uic.edu/wahmad/quartus_ii_tutorial.pdf > > Good luck. > > > -- Mike Treseler Hmm, so i've heard. Everyone says Xilinx stuff is bad for beginners and i must admit, I've been doing nothing but troubleshooting ever since i got this board, what a headache. > Since the OP already bought the Xilinx stuff, he may want to > open ISE (or WebPack) and under Help --> Tutorials --> > Tutorials on the Web, he can find what is available from > Xilinx. Look for "ECS" schematics. By the way I have > not looked at these myself. I too use HDL rather than > schematics since I "upgraded" from version 4.1 - the > last Foundation version with Aldec schematics. Also > go tohttp://forums.xilinx.com/and check out all of > the chatter on schematics. In my opinion, the ECS > schematics are not ready for prime time. The > associated documentation is not likely to be better. > > Oh, and before you get ideas of using Foundation > 4.1 schematics, it is no longer available from Xilinx > due to a termination of their agreement with Aldec. > > Aldec has wonderful new software that supports > Xilinx parts and others, but it would cost a lot more > than a good Altera evaluation board and a copy of > Quartus. > > Just my 2 cents, > Gabor I think i'm gonnna sell this board and go for an Altera board. but i'll try that first. thanks guys.Article: 134293
> This can perturb a tight design to be an routable one. ^unroutableArticle: 134294
A strange world when a Programmable Logic Vendor, sues a Microcontroller company. Have they really been losing sales to minnow Zilog, or do their lawyers need something to justify their salaries ? Or, is this a retaliation to Zilog's suit back in Jan 2007 ? -jgArticle: 134295
Dear friends, i am having 8 point ifft implementation in vhdl,how can i convert it to 64 point ifft(inverse fast forier transform). please help me i need yor valuable sugessions and if any one is having the code for this in vhdl or verilog it would be great. as i have 8 point ifft,can i use this core to implement 64 point ifft? Thanks in advance IrfanArticle: 134296
I greate new component, but it dont work correctlyArticle: 134297
Do you know what the relevant patents are?Article: 134298
On 5 =C1=D7=C7, 12:02, axalay <axa...@gmail.com> wrote: > I greate new component, but it dont work correctly The problem is solved. Problem arises when I use NIOS II/f. I am not understand whyArticle: 134299
Jim Granville wrote: > A strange world when a Programmable Logic Vendor, sues > a Microcontroller company. Have they really been losing sales > to minnow Zilog, or do their lawyers need something to > justify their salaries ? Patents are insurance policies. > Or, is this a retaliation to Zilog's suit back in That's how the game is played: http://www.edn.com/index.asp?layout=article&articleid=CA6409006 -- Mike Treseler
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