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
Stephen Williams wrote: > Stephen Williams wrote: > > > > I'm currently running SuSE Linux SLES8 AMD64, and ISE 6.2 works > > fine. I'm planning to upgrade to SuSE Linux 9.1 and was wondering > > if there are reports of the Xilinx tools working there. > > I did some googling and found some hints that LD_ASSUME_KERNEL=2.4.1 > is required on SuSE 9.1 and also some newer RedHat releases. Can > anyone confirm that will do the trick? > > On AMD64? > Well, see my previous post about baseX. This is on Fedora Core 2, not Suse, but the kernels/libraries are probably very similar. I am (for historical reasons) running in 32-bit mode, but it's still pretty fast :-) Note also the DISPLAY variable oddness in my post... SimonArticle: 73026
wiezbox wrote: > My company is going to start getting into the area of digital signal > processing for one of our projects. FPGAs seem to be what we need, > however I am a little foggy on how many gates to expect we need. Can > someone give an example of how many gates can preform a specific > operation in order to get a little better understanding on the number > I need. After selecting a manufacturer you should download their free design software. Then do the design and get a fitting FPGA as output of this evaluation process. Rene -- Ing.Buero R.Tschaggelar - http://www.ibrtses.com & commercial newsgroups - http://www.talkto.netArticle: 73027
<Ricaud> wrote in message news:ee886d9.-1@webx.sUN8CHnE... > Hi, > > We are searching for a simple FPGA board with : > > * A cPCI interface > * Available clock dedicated pin, so we can drive the FPGA with an external 100MHz (or 200MHz) clock. > * Some I/O available > > Is there any manufacturer building such board ? quite many memec has PCI board with XC2S200 avnet has some boards of course www.fpga4fun.com spartan http://www.nialstewartdevelopments.co.uk/ they have new board with cyclone 1C6 lattice new EC development board is PCI form factor altera new MAX2 eval board is PCI form factor (ok MAX2 is PLD, but internally its like FPGA with no block mems) a few to mention :) Antti xilinx.openchip.orgArticle: 73028
Hi. Have you included the file "altera_mf.v" in your simulation. This file contains the simulation models for Altera's megafunctions. I've simulated an Altera Dual Clock FIFO (DCFIFO) in Aldec's ActiveHDL simulator, and it worked great. The above file is located in C:\quartus\eda\sim_lib\. Hope this helps. Jeremy johnnynorthener@yahoo.co.uk (JohhnyNorthener) wrote in message news:<95e91aaf.0409100134.4730959c@posting.google.com>... > I am having problems simulating fifos with quartus and modelsim. > My environment is set up as follows: > > Quartus II v4.1 SP1 > Modelsim-Altera 5.8c (with updated sim models) > > I was seeing problems on a large design I have, whereby the the data > was not coming out of the fifo when being read. > As this was a large desing I decided to create a new project/design > which contains ONLY a fifo (LMP_FIFO+, single clock) and simulate > that. > I have generated the .vho file for use with Modelsim-Altera and > simulated this with my own testbench. > > > One thing worth mentioning is that when I start the simulation, I get > a load of warnings from Modelsim:- > > ** Warning: CONV_INTEGER: There is an 'U'|'X'|'W'|'Z'|'-' in an > arithmetic operand, and it has been converted to 0. > # Time: 0 ps Iteration: 0 Instance: > /fifo_test_tb/fifo_test_i0/fifo_i0/scfifo_component/auto_generated/dpfifo/fiforam/segment_a0_a_a0_a > > ...this is just because I haven't specified an .init file for the > fifo, but this won't prevent correct operation...will it ! ? > > When I bring up the waves I can see the following:- > > (i) the clock is running > > (ii) reset, devpor, devclrn are all asserted (correct polarity) > at start of the sim and then de-asserted 100 ns later. > > (iii) the wr_req is set active, and the data_in has an > incrementing pattern > > (iv) valid_wrreq (internal to the LPM_FIFO+ component) is active > as expected > > (v) ww_fiforam_wraddress (internal to the LPM_FIFO+ component) > increments as expected > > (vi) fifo_usedwd (internal to the LPM_FIFO+ component) increments > as expected > > (vii) empty and almost_empty (internal to the LPM_FIFO+ component) > get cancelled as expected > > (viii) rd_req is set active > > (ix) valid_rdreq (internal to the LPM_FIFO+ component) is active > as expected > > (x) ww_fiforam_rdaddress (internal to the LPM_FIFO+ component) > increments as expected > > (xi) fifo_usedwd (internal to the LPM_FIFO+ component) freezes > since I am writing and reading at the same rate as expected > (only start read once fifo_usedwd reaches about 12) > > (xii) BUT, no data appears at the output port, even though > everything else suggests that the fifo is being operated > correctly ! > > > Can anyone offer any assistance > (I have also submitted a service req to Altera, but on previous > experience am not to confident in the response I 'might' receive) > > Any assistance would be very much appreciated > > JohnnyNorthenerArticle: 73029
Austin, If John's used the input divide-by-2 mode, to make 311MHz from 622MHz wouldn't that take care of any duty cycle problems? Cheers, Syms. "Austin Lesea" <austin@xilinx.com> wrote in message news:chprct$73l1@cliff.xsj.xilinx.com... > John, > > There have been cases where the frequency, jitter, and duty cycle are > just on the edge of where the DCM phase detector will operate reliably. > > Check the input duty cycle. It will need to be as close to 50% as you > can make it. The spec is 45 to 55%, but at the higher frequencies, it > may have to be even closer to 50% when you take clock jitter into > account (as if it is 45%, and it has jitter, then it is sometimes less > than 45%!). > > > John Cappello wrote: > > > Hi, > > > > We are seeing evidence that a DCM is intermittently selecting the > > wrong tap position after it completes its lock sequence after a DCM > > reset pulse. I'd like to know if anyone has experienced this effect, > > and if they were able to resolve this problem. > > > > In a 2v6000, I am using a variable phase shift DCM which is driven by > > a 622 MHz clock (divide-by-2 mode). The DCM generates 311 MHz clocks > > on its clk0/clk180 output pins. This interface uses IOB DDR regs for a > > 622 Mhz/16-bit LVDS transmission solution. > >Article: 73030
Hi. I forgot to mention that you should use "C:\quartus\eda\sim_lib\altera_mf.v" if you're using Verilog HDL. If you're using VHDL, then you should use "C:\quartus\eda\sim_lib\altera_mf.vhd". Good Luck, Jeremy johnnynorthener@yahoo.co.uk (JohhnyNorthener) wrote in message news:<95e91aaf.0409100134.4730959c@posting.google.com>... > I am having problems simulating fifos with quartus and modelsim. > My environment is set up as follows: > > Quartus II v4.1 SP1 > Modelsim-Altera 5.8c (with updated sim models) > > I was seeing problems on a large design I have, whereby the the data > was not coming out of the fifo when being read. > As this was a large desing I decided to create a new project/design > which contains ONLY a fifo (LMP_FIFO+, single clock) and simulate > that. > I have generated the .vho file for use with Modelsim-Altera and > simulated this with my own testbench. > > > One thing worth mentioning is that when I start the simulation, I get > a load of warnings from Modelsim:- > > ** Warning: CONV_INTEGER: There is an 'U'|'X'|'W'|'Z'|'-' in an > arithmetic operand, and it has been converted to 0. > # Time: 0 ps Iteration: 0 Instance: > /fifo_test_tb/fifo_test_i0/fifo_i0/scfifo_component/auto_generated/dpfifo/fiforam/segment_a0_a_a0_a > > ...this is just because I haven't specified an .init file for the > fifo, but this won't prevent correct operation...will it ! ? > > When I bring up the waves I can see the following:- > > (i) the clock is running > > (ii) reset, devpor, devclrn are all asserted (correct polarity) > at start of the sim and then de-asserted 100 ns later. > > (iii) the wr_req is set active, and the data_in has an > incrementing pattern > > (iv) valid_wrreq (internal to the LPM_FIFO+ component) is active > as expected > > (v) ww_fiforam_wraddress (internal to the LPM_FIFO+ component) > increments as expected > > (vi) fifo_usedwd (internal to the LPM_FIFO+ component) increments > as expected > > (vii) empty and almost_empty (internal to the LPM_FIFO+ component) > get cancelled as expected > > (viii) rd_req is set active > > (ix) valid_rdreq (internal to the LPM_FIFO+ component) is active > as expected > > (x) ww_fiforam_rdaddress (internal to the LPM_FIFO+ component) > increments as expected > > (xi) fifo_usedwd (internal to the LPM_FIFO+ component) freezes > since I am writing and reading at the same rate as expected > (only start read once fifo_usedwd reaches about 12) > > (xii) BUT, no data appears at the output port, even though > everything else suggests that the fifo is being operated > correctly ! > > > Can anyone offer any assistance > (I have also submitted a service req to Altera, but on previous > experience am not to confident in the response I 'might' receive) > > Any assistance would be very much appreciated > > JohnnyNorthenerArticle: 73031
Symon, Yes, it would. That is a nice trick, but you trade one problem (duty cycle) for another, getting a 622 MHz signal into the chip (SI is much tougher the higher the frequency). I think John's problem is more that he has a clock that switches between two sources. If the clock must switch, then you best reset the DCM. Austin Symon wrote: > Austin, > If John's used the input divide-by-2 mode, to make 311MHz from 622MHz > wouldn't that take care of any duty cycle problems? > Cheers, Syms. > "Austin Lesea" <austin@xilinx.com> wrote in message > news:chprct$73l1@cliff.xsj.xilinx.com... > >>John, >> >>There have been cases where the frequency, jitter, and duty cycle are >>just on the edge of where the DCM phase detector will operate reliably. >> >>Check the input duty cycle. It will need to be as close to 50% as you >>can make it. The spec is 45 to 55%, but at the higher frequencies, it >>may have to be even closer to 50% when you take clock jitter into >>account (as if it is 45%, and it has jitter, then it is sometimes less >>than 45%!). >> >> >>John Cappello wrote: >> >> >>>Hi, >>> >>>We are seeing evidence that a DCM is intermittently selecting the >>>wrong tap position after it completes its lock sequence after a DCM >>>reset pulse. I'd like to know if anyone has experienced this effect, >>>and if they were able to resolve this problem. >>> >>>In a 2v6000, I am using a variable phase shift DCM which is driven by >>>a 622 MHz clock (divide-by-2 mode). The DCM generates 311 MHz clocks >>>on its clk0/clk180 output pins. This interface uses IOB DDR regs for a >>>622 Mhz/16-bit LVDS transmission solution. >>> > > >Article: 73032
<Ricaud> wrote in message news:ee886d9.2@webx.sUN8CHnE... > Yes, we are looking for compact PCI boards. > The boards I have seen are etheir too sophisticated (µP, multiple FPGA ...), either not cPCI. > > Thank you for help there is no simple compactPCI board, do not look! the market for compactPCI fpga dev boards is so small that simple boards are not made anttiArticle: 73033
> the error as > Error : iMPACT : the idcode read from the devices doesn't match the > idcode in the bsdl files. ===================== Hi, First thing is --check whether you selected corrected device in the ISE to that of actual device (including package). I think i got the same error while working on spartan II. I think there is some problem with the ISE. I tried to program couple of times and it is OK! the device functions. I think there is some diff in idcode of ISE and silicon. Does your chip functions after this error? .. check that and let me know. -raoArticle: 73034
Johnny, Can you send the small design along with your testbench to us. We would like to understand the problem. It will be very useful if you can describe the time slice where the problem is seen, and the expected behavior. Subroto Datta Altera Corp. "JohhnyNorthener" <johnnynorthener@yahoo.co.uk> wrote in message news:95e91aaf.0409100134.4730959c@posting.google.com... >I am having problems simulating fifos with quartus and modelsim. > My environment is set up as follows: > > Quartus II v4.1 SP1 > Modelsim-Altera 5.8c (with updated sim models) > > I was seeing problems on a large design I have, whereby the the data > was not coming out of the fifo when being read. > As this was a large desing I decided to create a new project/design > which contains ONLY a fifo (LMP_FIFO+, single clock) and simulate > that. > I have generated the .vho file for use with Modelsim-Altera and > simulated this with my own testbench. > > > One thing worth mentioning is that when I start the simulation, I get > a load of warnings from Modelsim:- > > ** Warning: CONV_INTEGER: There is an 'U'|'X'|'W'|'Z'|'-' in an > arithmetic operand, and it has been converted to 0. > # Time: 0 ps Iteration: 0 Instance: > /fifo_test_tb/fifo_test_i0/fifo_i0/scfifo_component/auto_generated/dpfifo/fiforam/segment_a0_a_a0_a > > ...this is just because I haven't specified an .init file for the > fifo, but this won't prevent correct operation...will it ! ? > > When I bring up the waves I can see the following:- > > (i) the clock is running > > (ii) reset, devpor, devclrn are all asserted (correct polarity) > at start of the sim and then de-asserted 100 ns later. > > (iii) the wr_req is set active, and the data_in has an > incrementing pattern > > (iv) valid_wrreq (internal to the LPM_FIFO+ component) is active > as expected > > (v) ww_fiforam_wraddress (internal to the LPM_FIFO+ component) > increments as expected > > (vi) fifo_usedwd (internal to the LPM_FIFO+ component) increments > as expected > > (vii) empty and almost_empty (internal to the LPM_FIFO+ component) > get cancelled as expected > > (viii) rd_req is set active > > (ix) valid_rdreq (internal to the LPM_FIFO+ component) is active > as expected > > (x) ww_fiforam_rdaddress (internal to the LPM_FIFO+ component) > increments as expected > > (xi) fifo_usedwd (internal to the LPM_FIFO+ component) freezes > since I am writing and reading at the same rate as expected > (only start read once fifo_usedwd reaches about 12) > > (xii) BUT, no data appears at the output port, even though > everything else suggests that the fifo is being operated > correctly ! > > > Can anyone offer any assistance > (I have also submitted a service req to Altera, but on previous > experience am not to confident in the response I 'might' receive) > > Any assistance would be very much appreciated > > JohnnyNorthenerArticle: 73035
Javier Castillo <jcastillo@opensocdesign.com> wrote in message news:<Xns955F6B1A9D131jcastilloopensocdesi@193.147.184.15>... > Hello: >If you dont believe me ... I do believe, that it is possible to write design in SystemC. There may be some advantages of this approach for people with strong C background. There are obviously drawbacks too, and I would like to outline some of them. 1. Translation problems. I am really suspicious about "complete automatization" of language translation process. The problem is to make it work in ALL the cases. The easiest way to cleanup translation may be to reduce "translatable" subset in SystemC. It may not be a problem, but then it reduces "synthesizable" subset of SystemC and converts it to even more limited subset of synthesizable Verilog RTL. 2. Descriptive power. Verilog as a language was developed for RTL coding and constantly improves during years of practice. For example, Verilog 2001 and then SystemVerilog defines new useful constructs such as always_comb, always_ff etc allowing designer to specify design intent in a way that tools can verify. I doubt that SystemC has similar operator or can produce them during code translation. 3. Need to maintain 2 code versions. Despite of Javier's opinion that it is not a problem, I do see the need to maintain separately Verilog version of RTL code. First, synthesis, STA and Equivalence checking tools require verilog as an input. Then, there is a need to use library cells, memories, DFT logic such as MBIST and JTAG, PLLs etc etc. Do we have all this design infrastructure developed for SystemC? 4. Synthesis-STA-driven design modifications. These are very popular, their intent is to improve timing performance of design. Translation will complicate this process as well. 5. Maintenance effort. Designers cannot escape working and knowing Verilog RTL. So they'll end up working with 2 languages as well as constantly maintain functional equivalence between SystemC and Verilog design representations. In addition to design, I also doubt that SystemC is a good choise for the whole verification environment. For the system-level verification, it is a good choise since it allows seamless interoperability with the software. For the functional verification, verification-specific languages (HVL)or SystemVerilog would be much better choise. Functional verification requires advanced coverage, random generation, assertion support as well as may other items such as random stability etc. I doubt that SystemC has similar capabilities comparing to HVLs or SV. Finally, there are already tools fo more efficient C-to-Verilog integration than PLI provides. For example, VCS has DirectC interface. Similar interface is also defined in SystemVerilog standard. Regards, Alexander GnusinArticle: 73036
I need some help with something. Someone made some technical claims that I am questioning are correct or not ;-), and would like to see what you guys think about these claims: #1> Programming FPGAs doesn't actually change or rewire those logic gates #1> in the silicon wafer. It changes bits of non-volatile memory that is #1> used as inputs to these gates. (These are not the gates you see when #1> you write the FPGA code, those are emulated by a combination of #1> hardwired gates and your code.) #2>Software is defined as the part of a digital circuit that can be #2>changed without mechanical modifications, as opposed to hardware, #2>which is HARDwired. So FPGA code is software #3> OTP EPROM data ... has always been regarded as software. #4> A LUT is not a device soldered onto the circuit board. It's not even #4> implemented in silicon (at least during the development stages). It's #4> programmed into an FPGA or suchlike and therefore software because you #4> can change it without any mechanical changes on the board. #5> Using a sufficiently parallelized, a LUT done in a DSP can be just as #5> efficient as using an FPGA or ASIC. Any input appreciated ;-)Article: 73037
> Hi, > > First thing is --check whether you selected corrected device in the > ISE > to that of actual device (including package). > Hi .. My problem was solved.. the problem was that spartan II must need the specific cable to configure it. here i have ordinary cble that work for virtex,cpld but not for spartan. thus i put parallel cable III dlc5 model of xilinx , impact error gone off. thanks for u suggestion. How many times we program a fpga.. is there any count . let me know.... Regard Senthil.R Research Associate. IIT. Madras.Article: 73038
"Austin Franklin" <austin@dark99room.com> wrote in message news:<10k58kelcgkcnfc@corp.supernews.com>...
> I need some help with something. Someone made some technical claims that I
> am questioning are correct or not ;-), and would like to see what you guys
> think about these claims:
>
> #1> Programming FPGAs doesn't actually change or rewire those logic gates
> #1> in the silicon wafer. It changes bits of non-volatile memory that is
> #1> used as inputs to these gates. (These are not the gates you see when
> #1> you write the FPGA code, those are emulated by a combination of
> #1> hardwired gates and your code.)
I don't believe this the above exactly correct, but I'll let someone
else comment on it.
The following three claims are releated:
> #2>Software is defined as the part of a digital circuit that can be
> #2>changed without mechanical modifications, as opposed to hardware,
> #2>which is HARDwired. So FPGA code is software
So a memory chip itself is software? It doesn't require any
mechanical modifications to change.
> #3> OTP EPROM data ... has always been regarded as software.
The _data_ within a memory chip doesn't necessarily have to be
software. It can be pure data (a serial number, for example).
Software implies to me that it is executable.
> #4> A LUT is not a device soldered onto the circuit board. It's not even
> #4> implemented in silicon (at least during the development stages). It's
> #4> programmed into an FPGA or suchlike and therefore software because you
> #4> can change it without any mechanical changes on the board.
Again, the same would apply to a memory chip. In fact, a LUT _is_
memory. In addition, ever notice that FPGA's are called "SRAM based
devices"?
> #5> Using a sufficiently parallelized, a LUT done in a DSP can be just as
> #5> efficient as using an FPGA or ASIC.
I do not understand what is being claimed here. Almost any device can
do a single LUT function as efficiently as any other device... but
what about 20k LUTs?
Marc
Article: 73039"Marc Randolph" <mrand@my-deja.com> wrote in message news:15881dde.0409110423.20cd5e6e@posting.google.com... > "Austin Franklin" <austin@dark99room.com> wrote in message news:<10k58kelcgkcnfc@corp.supernews.com>... > > I need some help with something. Someone made some technical claims that I > > am questioning are correct or not ;-), and would like to see what you guys > > think about these claims: > > > > #1> Programming FPGAs doesn't actually change or rewire those logic gates > > #1> in the silicon wafer. It changes bits of non-volatile memory that is > > #1> used as inputs to these gates. (These are not the gates you see when > > #1> you write the FPGA code, those are emulated by a combination of > > #1> hardwired gates and your code.) > > I don't believe this the above exactly correct, but I'll let someone > else comment on it. > > The following three claims are releated: > > > #2>Software is defined as the part of a digital circuit that can be > > #2>changed without mechanical modifications, as opposed to hardware, > > #2>which is HARDwired. So FPGA code is software > > So a memory chip itself is software? It doesn't require any > mechanical modifications to change. > > > #3> OTP EPROM data ... has always been regarded as software. > > The _data_ within a memory chip doesn't necessarily have to be > software. It can be pure data (a serial number, for example). > Software implies to me that it is executable. > > > #4> A LUT is not a device soldered onto the circuit board. It's not even > > #4> implemented in silicon (at least during the development stages). It's > > #4> programmed into an FPGA or suchlike and therefore software because you > > #4> can change it without any mechanical changes on the board. > > Again, the same would apply to a memory chip. In fact, a LUT _is_ > memory. In addition, ever notice that FPGA's are called "SRAM based > devices"? SRAM based means the configuration memory is SRAM, most FPGAs have this, but there's also Flash based configuration memory and EEPROM, and fuse/anti-fuses. So SRAM based does not refer to the LUT. JeroenArticle: 73040
"Marc Randolph" <mrand@my-deja.com> wrote in message > I do not understand what is being claimed here. Almost any device can > do a single LUT function as efficiently as any other device... but > what about 20k LUTs? See also "Emulating FPGAs using Processors" [http://www.fpgacpu.org/usenet/emulating_fpgas.html] Jan GrayArticle: 73041
"Austin Franklin" <austin@dark99room.com> wrote in message news:<10k58kelcgkcnfc@corp.supernews.com>... > I need some help with something. Someone made some technical claims that I > am questioning are correct or not ;-), and would like to see what you guys > think about these claims: > > #1> Programming FPGAs doesn't actually change or rewire those logic gates > > #1> in the silicon wafer. It changes bits of non-volatile memory that is > > #1> used as inputs to these gates. (These are not the gates you see when > > #1> you write the FPGA code, those are emulated by a combination of > > #1> hardwired gates and your code.) > > > > #2>Software is defined as the part of a digital circuit that can be > > #2>changed without mechanical modifications, as opposed to hardware, > > #2>which is HARDwired. So FPGA code is software > > > > #3> OTP EPROM data ... has always been regarded as software. > > > > #4> A LUT is not a device soldered onto the circuit board. It's not even > > #4> implemented in silicon (at least during the development stages). It's > > #4> programmed into an FPGA or suchlike and therefore software because you > > #4> can change it without any mechanical changes on the board. > > > > #5> Using a sufficiently parallelized, a LUT done in a DSP can be just as > > #5> efficient as using an FPGA or ASIC. > > > > Any input appreciated ;-) Most of the pts don'r read as if written by an EE. Sounds like you are arguing with a lawyer, waste of time unless you have a patent dispute or something. regards johnjakson_usa_comArticle: 73042
On Sat, 11 Sep 2004 03:00:29 -0400, "Austin Franklin" <austin@dark99room.com> wrote: >I need some help with something. Someone made some technical claims that I >am questioning are correct or not ;-), and would like to see what you guys >think about these claims: <claims snipped> > >Any input appreciated ;-) > The way these claims are written reminds me of a story about physicist Wolfgang Pauli. Some guy off the street showed him a paper and asked, "Is this true?" Pauli glanced at it, then said, "This isn't even false." I know, it's no help :) Bob Perlman Cambrian Design WorksArticle: 73043
Hello all! I am using Xilinx Virtex-II Pro (XC2VP20 and XC2VP50) chips, and was wondering if I can use JBits 3.0 to manipulate the configuration bitstreams for these chips. It seems not, since the JBits "Device" class seems to only have defined constants for Virtex and Virtex-II chips. Has anyone done this before, or knows that it can be done? Thanks, MahimArticle: 73044
> How many times we program a fpga.. is there any count . let me > know.... ==================== Hi, Theoritically (and practically) there is no limit in how many times you can program fpga!. Programming an fpga is simply like writing some data to sram(synchronous ram). But for CPLD there may be a limit as its technology is based on flash/eeprom. thanks raoArticle: 73045
"Austin Franklin" <austin@dark99room.com> wrote in message news:10k58kelcgkcnfc@corp.supernews.com... > I need some help with something. Someone made some technical claims that I > am questioning are correct or not ;-), and would like to see what you guys > think about these claims: > > #1> Programming FPGAs doesn't actually change or rewire those logic gates > #1> in the silicon wafer. It changes bits of non-volatile memory that is > #1> used as inputs to these gates. (These are not the gates you see when > #1> you write the FPGA code, those are emulated by a combination of > #1> hardwired gates and your code.) #1 - lets see what wrong with 1) "changes bits of non-volatile memory" - WRONG an FPGA doesnt have to have any-nonvolatile memory, in the fact almost all FPGAs do not have non-volatile memory. Actually as of today NO FPGA has non-volatile memory in the that sense - FPGAs have non-volatile configuration memory, not user accessible non-volatile memory. Exceptions: a) new upcoming to be announced ProAsic FPGA are the first one to have on chip non-volatile memory (other than configuration). b) Altera MAX2 has non-volatile "user" memory - it is not marketed as an FPGA but actually it is a small FPGA with no Block RAMs 2) changes bits of [] memory" - if we leave out the non-volatile (see comment above) then the sentense is still wrong. And FPGA doesnt have to have any memory in the sense of an memory-array - a fuse or via-mask programmable FPGA with no embedded RAMs does not have any memory unless the memory is made up from fabric logic and flip flops. 3) Programming FPGA's - well the "Programming" is actually very bad word to use with FPGAs - there do exist some tools that allow and unprogrammerd FPGA silicon (like Actel fuse programmable FPGA's) to be actually programmed, its and metal box called Activator. Using that tool you can actually program an FPGA you blow some fuses and convert and blank silicon to programmed silicon. Any other means of putting an design into an FPGA are not direct "FPGA programming". There are of different "programming" steps involved with the FPGAs but very rearly the programming is actually changing the silicon at all. A configuration memory can be programmed but that is usually external to FPGA except for Atmel A94KxxS series (those are multichip packages). Also a programming can be understood as writing an program for some processor that is implemented in the FPGA fabric, then we write programs in some programming language what is later "executed" by the FPGA. 4) "write FPGA code" - there is no such thing as FPGA code, you can write code for some processor (that can be implemented in FPGA of course), but for FPGA you write some code that describes something - this is translated to FPGA technology primitives. you can use the low level primitives in your code too, but its not really writing FPGA code - FPGAs dont have code - they have configuration that makes them to be the hardware you have described. 5) ... more claims I cant even understand, emulated by gates and your code? the source code is converted into something that emulates the required functionality, yes but the original author did not mean that? > #2>Software is defined as the part of a digital circuit that can be > #2>changed without mechanical modifications, as opposed to hardware, > #2>which is HARDwired. So FPGA code is software #2 - is total bullshit * software doesnt have to be part of anything! * a punched paper tape is software even if it never used. * not always can software be altered without mechanical modification, so that makes software a hardware or what? * a programmed FPGA doesnt have any "code" it can be just some blown fuses (what I woudl not consider as code) * an FPGA can contain processors that execute code internal or external to FPGA, that code is software sure, but this code can be fused into silicon what makes the software hardware? == # bullshit > #3> OTP EPROM data ... has always been regarded as software. * OTP doesnt have to be EPROM * some specif location of data (being in EPROM, OTP or not) doent make it software OTP means one time programmable, be it using electrica means or laser or mask > #4> A LUT is not a device soldered onto the circuit board. It's not even > #4> implemented in silicon (at least during the development stages). It's > #4> programmed into an FPGA or suchlike and therefore software because you > #4> can change it without any mechanical changes on the board. #4 more bullshit comes.. * "It's not even implemented in silicon" - cant be more wrong - LUT's are what actually *is* implemented in silicon * "It's programmed into an FPGA" wrong LUT is not programmed (programming means altered by user) into silicon it exists there, it will beconfigured todo some function, yes but not programmed "into FPGA" its there already. * "therefore software because you can change it without any mechanical changes on the board" - on board? or on silicon? if you program an LUT based (non SRAM) FPGA using an laser or masl its mechanical so it would make the LUT hardware? and when the FPGA is configured by electrical means its software ? !? > #5> Using a sufficiently parallelized, a LUT done in a DSP can be just as > #5> efficient as using an FPGA or ASIC. LUT done in a DSP as efficient !? cant be more wrong than that!!! first there is never a need todo an LUT with DSP, and even fastest DSP utilizing 100% of the foreground time can not do the same work of one single LUT (at the same speed!), but FPGA's have 10,000+ LUTs !!! second the fastest DSP still cant compete with FPGA doing digital signal processing (and DSP are designed for it), FPGAs will always outperform DSPs when doing DSP algorithms. the reason why DSPs are used is cost not performance. when doing somewhat fixed DSP algorithms FPGAs are better also costwise. just the DSP algorithms in FPGA are not so "soft" as in DSPs that makes the difference. > Any input appreciated ;-) here you go with smile :) overall comment: 200% incompetence! Antti - [a FPGA guru with 25+ years Electrical engineering backroundArticle: 73046
On Wed, 08 Sep 2004 19:51:24 GMT, Jos De Laender <DoesntMatter@Somewhere.org> wrote:
>A good starting point , in my opinion , to gain some insight in the
>matter is asking :
>why would _you_ think SystemC is faster or slower ?
>Jos
and
On Wed, 8 Sep 2004 13:26:32 -0700, "Russell Fredrickson" <russell_fredrickson@hp.com> wrote:
> ....
>One of the points of SystemC is to enable you to model
>and simulate things at a HIGHER level of abstraction than RTL. If you write
>code at the RT level -- it will probably always simulate on the same order
>of magnitude whether it's Verilog or SystemC -- in fact since the Verilog
>simulators are more mature -- Verilog may simulate faster than SystemC
>(though I haven't done the exact measurements myself and it is simulator
>dependent).
I believe pretty much everything I read. Here is a quote from
a recent article by Shawn McCloud, High-Level Synthesis Product
Manager, Mentor Graphics Corporation.
http://www.xilinx.com/publications/xcellonline/xcell_50/xc_mentor-esl50.htm
This is about half way through the article, in the print version on page
49 is the following:
"One advantage of SystemC is that it simulates as much as 100 times faster
than an equivalent RTL representation specified at the same level of
abstraction. However, to make a SystemC representation suitable for RTL
generation or direct C synthesis, designers would need to write it at
nearly the same level of abstraction as hand-translated RTL, which largely
negates the advantages of using it in the first place."
That doesn't mean that the above is true, but here we see Mentor promoting
it that way.
Philip Freidin
For the US news media, there is nothing so important
or relevant, that it can't be ignored in favor of
some new, bright and shiny irrelavancy.
Article: 73047has anyone used altera's stratix II dev boards? have you been able to get the pci interfacing to work? can you comment on ease of use etc? -- Geoffrey Wall Masters Student in Electrical/Computer Engineering Florida State University, FAMU/FSU College of Engineering wallge@eng.fsu.edu Cell Phone: 850.339.4157 ECE Machine Intelligence Lab http://www.eng.fsu.edu/mil MIL Office Phone: 850.410.6145 Center for Applied Vision and Imaging Science (will be updated soon) http://cavis.fsu.edu/ CAVIS Office Phone: 850.645.2257Article: 73048
Hi John, > Most of the pts don'r read as if written by an EE. You are correct. He is a physicist who has done one or possibly a couple of FPGA designs. > Sounds like you are arguing with a lawyer, waste of time unless you > have a patent dispute or something. Just trying to get input from others in this field as to what they think of his "claims" of knowledge on this subject. Regards, AustinArticle: 73049
One more claim from our "candidate": "And none of the professionals I've talked to referred to ASICs being hardware. You can't buy an ASIC, you have to design it, which makes its function software." And being a professional EE for over 25 years, having designed a few dozen ASICs, and worked with hundreds of ASIC designers, I've never heard anyone refere to ASICs as anything but hardware. So, I can't imagine what professionals he is referring to that would think an ASIC was software!
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