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
The difference is execution versus synthesis. Firmware is indeed embedded and dedicated code, but the code is executed. FPGA code is written in a _description_ language, is then interpreted, synthesized, and ultimately produces hardware. So, I see it fit to refer to the FPGA, when it is configured, as hardware, and to the code itself as a description language. JulianArticle: 97301
On Thu, 16 Feb 2006 09:39:16 +0000, Alan Myler <amyler@eircom.net> wrote: >I've had no problems at all renewing Altera web-edition licences. > >I'm sure the X&A members of this group can clarify better, but to >my understanding the rationale behind the free editions is simply >to remove a cost associated with people working with the smaller >devices, and thus help people on shoestring budgets...snip > >If you're looking at using one of the more sophisticated/larger >devices these might not be supported bt the web-edition, but if >you're looking at designing onto those higher cost chips then the >couple of thousand euro/dollars for the full edition tool is not >a big part of the overall development cost anyhow. > There are some underlying assumptions there which aren't necessarily true. The biggest assumption is that individuals and small firms doing small-volume products never work on apps which need large devices. That is simply not true....but I do agree that it sure seems to be a common myth; t the mfg's like Altera etc., and sadly, among many people here as well. A built-in assumption there is that a single mfg's parts will satisfy all of an individual's or small firm's applications. That's not true of a large firm, so why would anyone think it true of a small firm? In reality, since a large firm tends to make many products in the -same field-, whereas an individual designer or small firm tends to make products covering -several different- fields; the small outfit is -more- likely to need IC's from different makers to best fit their projects. In a specialized application where the total build might be, say, 30 boards; several thousand dollars is a good chunk of the total bottom-line for the project. Multiply that by the 5 different setups required in order to work with larger parts from 5 different makers...plus annual "maintenance" fees times 5....yeah, it's a burden...not something to sneeze at, in my view. ----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==---- http://www.newsfeeds.com The #1 Newsgroup Service in the World! >100,000 Newsgroups ---= East/West-Coast Server Farms - Total Privacy via Encryption =---Article: 97302
Hi, thanks to all for the answers :) !!! (and sorry for my bad english :( ) I think I'm begining to understand how it works. If the monitor uses PLL then the HSync frecuency determines how fast the monitor moves the beam.So if I increase the HSync frecuency the active time is shorter(and the back and front porch) but I can draw more lines per second so I can have better resolutions. I don't understand how resolution control works. The monitor has a fixed number of pixels(Let's supose a 1024x768 monitor). If I ouput 640x480 images and the monitor must draw 1024 pixels per line and 768 lines, then some pixels will be repeated. Isn't it? Thanks in advance, JordiArticle: 97303
Marko schrieb: >>Why not? > > Are you answering my question with a question? > Seriously, I just want to know what other people call it. It seems > incorrect to refer to FPGA code by the same name used for ROMable S/W. > At my previous job, we just called it "FPGA Code". At my new job, > it's called "firmware". I don't see the big problem there. There are hundreds of synonyms floating around. "FPGA-Code" is more or less the same as "Firmware". There is no official definition or standard, also no defacto standard. So call it whatever you like it as long as it's in sync with the people you are talking to. Regards FalkArticle: 97304
Julian Kain schrieb: > The difference is execution versus synthesis. Firmware is indeed > embedded and dedicated code, but the code is executed. FPGA code is > written in a _description_ language, is then interpreted, synthesized, > and ultimately produces hardware. VHDL may "produce" hardware when doing ASIC design. In an FPGA not a single bit is "produced", all is fixed. Only the connections between the bits are set, so all that is done in an FPGA is configuration. Surprisingly this process is called configuration for quite a long time ;-) > So, I see it fit to refer to the FPGA, when it is configured, as > hardware, and to the code itself as a description language. What code? The source code (VHDL/Verilog/whatever) or the final bitstream? The same distinction applies to microprocessor "Firmware", where you have the source code and the compiled binary. Hmm, the more I write and think about it (where it should be better the other way around ;-) FPGA and microprocessor bitstreams are becomming more and more similar "Firmware". Regards FalkArticle: 97305
Hi all, I am new to this group and i am facing one problem regarding reading from the sdram. Actually I am accessing sdram indirectly through CPU. So I am writing write data into the fpga registers and set the wr_start bit, after completing the write operation wr_start bit will be cleared indicating write has completed. To verify the data written to sdram i am setting the read_start and reading immediately and the data is correct. But if i read after sometime the data i am getting is FFFF FFFF (two 16 bit sdrams). I am operating sdram (SDR sdram) at 125 Mhz. Is this because of auto refresh is not done properly? But i am accessing 3 sdrams on the board. Sometime one the sdram works and remaining fails. Can anyone has idea? or require more info to answer. Thanks in advance.Article: 97306
Dear Sir,
We want to use JHDL for our Firewall development. Can u
tell us please, in which format the JHDL generates output & if this
generated output format can be programmed in a Xilinx FPGA and Altera
FPGA. My second query is, whether this generated output format from JHDL
can be combined with other VHDL generated output format (let's say ".mcs"
or ".bit" file of Xilinx) & then overall program can be fused to a
particular FPGA. Like, we want to develop our Firewall application using
JHDL & PCI interface application using Xilinx VHDL. These two applications
has to be combined & then programmed into Xilinx FPGA.
Thanks & regards,
varindra
Article: 97307Hi, My name is Sandeep, I programmed the Spartan 3 and its working fine, I have loaded some data onto the registers and I am trying to read them from the "Transport feature" available in digilent Adept software suite and everytime I do that it either gives me an error message: "The board is not connected" or the system just hangs. I know for sure that the board is connected but cant explain why its giving me the first error message..If any one has previously worked on Spartan 3 using Digilent Adept Software, then please share your experience and guide me.. Thanks for your time and consideration Sandeep k.sandeep.p@gmail.comArticle: 97308
On Mon, 20 Feb 2006 11:32:38 -0800, Marko <cantsay@comcast.net> wrote: >On Mon, 20 Feb 2006 19:47:16 +0100, Falk Brunner <Falk.Brunner@gmx.de> >wrote: > >>Marko schrieb: >>> Traditionally, firmware was defined as software that resided in ROM. >>> So, my question is, what do you call FPGA code? Is "firmware" >>> appropriate? >> >>Why not? > >Are you answering my question with a question? > >Seriously, I just want to know what other people call it. It seems >incorrect to refer to FPGA code by the same name used for ROMable S/W. >At my previous job, we just called it "FPGA Code". At my new job, >it's called "firmware". At one previous place of employment, we called it Roland C. Higgenbottom the Third. We figured we could charge extra by making it sound more dignified than it actually was. Bob Perlman Cambrian Design WorksArticle: 97309
Jordi wrote: > Hi, > thanks to all for the answers :) !!! (and sorry for my bad english :( > ) > > I think I'm begining to understand how it works. > > If the monitor uses PLL then the HSync frecuency determines how fast > the monitor moves the beam.So if I increase the HSync frecuency the > active time is shorter(and the back and front porch) but I can draw > more lines per second so I can have better resolutions. I don't You are partially correct. The HSync tells the monitor WHEN to go to the next line. Also the HSync frequencies are defined for each standard resolution. You must stay very close to them or else the monitor will reject your signal. The monitor will determine which resolution you are using by the frequency it "sees" on both the Vsync and Hsync inputs (also the sync pulse polarity changes too). > understand how resolution control works. The monitor has a fixed number > of pixels(Let's supose a 1024x768 monitor). If I ouput 640x480 images > and the monitor must draw 1024 pixels per line and 768 lines, then some > pixels will be repeated. Isn't it? It is better to drop down to 640x480 to draw the 640x480 images. But if necessary you can use pixel scaling to scale the 640x480 image to fit a 1024x768 screen. > Thanks in advance, > Jordi -IsaacArticle: 97310
We have an application where we need 4 phase sampling of a differential
(LVPECL) input. I think we found a way to use the IDDRs from the IOBs
associated with both + and - differential pads on V4 devices to
accomplish this. The FPGA editor seems to show a path from the positive
pad to the inverting input of the negative pad's IBUFDS. Therefore the
IDDR in the negative pad's IOB can be used, but the data is inverted
(we can deal with that downstream). We coded up the following rtl
instantiating the IBUFDSs and IDDRs, and it runs all the way through
P&R with no errors, so long as you don't put a loc constraint on the
negative pad (?).
buf0 : ibufds
port map (
i => data_p,
ib => data_n,
o => data_async(0));
buf1 : ibufds
port map (
i => data_n, -- reversed polarity
ib => data_p, -- reversed polarity
o => data_async(1)); -- inverted
ddr0 : iddr
generic map (
ddr_clk_edge => "SAME_EDGE_PIPELINED",
init_q1 => '0',
init_q2 => '0',
srtype => "sync")
port map(
q1 => data(0),
q2 => data(2),
c => clk(0),
ce => vcc,
d => data_async(0),
r => reset,
s => gnd);
ddr1 : iddr
generic map (
ddr_clk_edge => "SAME_EDGE_PIPELINED",
init_q1 => '0',
init_q2 => '0',
srtype => "sync")
port map(
q1 => data(1), -- inverted
q2 => data(3), -- inverted
c => clk(1),
ce => vcc,
d => data_async(1), -- inverted
r => reset,
s => gnd);
Q: Has anybody else tried this? The documentation does not say anything
about this secondary input path. We sent a test case to our local FAE,
but have not heard back yet. It certainly seems to work as far as the
tools go, but we don't have a good way to check it out physically on a
board yet.
Thanks,
Andy Jones
Article: 97311On Mon, 20 Feb 2006 21:01:52 +0100, Falk Brunner <Falk.Brunner@gmx.de> wrote: >Julian Kain schrieb: >> The difference is execution versus synthesis. Firmware is indeed >> embedded and dedicated code, but the code is executed. FPGA code is >> written in a _description_ language, is then interpreted, synthesized, >> and ultimately produces hardware. > >VHDL may "produce" hardware when doing ASIC design. So what do you call a gate array or structured asic ? What does VHDL do when it generates files for one of these processes ? (for the uninitiated gate-arrays or structured asics in general have all their base layers produced already and several metals are used configure the manufactured general purpose gates to what you want and provide the connectivity). By the same token when you take a bit file generated for an FPGA and use it to produce a hard-copy device (a structured asic specifically generated for a certain FPGA family) does the VHDL suddenly realize that it has produced hardware ? What does this say for laser trim or metal only ECO ? Also is an Intel or AMD processor really hardware as they have micro-code which can be downloaded by BIOS which can be used to fix quite a bit of "issues" with the processor. > In an FPGA not a single bit is "produced", all is fixed. So the function of each LUT and how they are all connected are fixed and the VHDL doesn't produce anything ? What does it do then ? If in my standard cell design, I have memory based FSMs the function of which can be changed by updating the contents of such, does my asic become software ? What about external pins which can change the behaviour of combinational FSMs ? I think the issue is a lot less clean-cut then is suggested here.Article: 97312
Marko wrote: > Traditionally, firmware was defined as software that resided in ROM. > So, my question is, what do you call FPGA code? Is "firmware" > appropriate? Dunno if it's appropriate, but I see it called that in many places. "FPGA configuration file" is probably best, but that makes managers' eyes cross. Call it "firmware" and it sounds safely familiar. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com Posting from Google? See http://cfaj.freeshell.org/google/Article: 97313
Hi all, Does anyone knows of a complete reference design (preferably xilinx's) describing a MB system that is running from external memory. I'm trying to setup such a design and have some questions, I'll be happy to get a well documented reference design to get me started.. Thanks in advance , Mordehay.Article: 97314
One should check out the source of the term "firmware". I suspect that most of you weren't around in the early 70's when the term was invented (at least not in the professional sense). Firmware was invented with the advent of microcoded computers. Microcode is "software", but a different kind of software than most of us were familiar with. And, usually, it wasn't something that the user could change (with a very few exceptions). So they came up with "firmware", meaning it was programmed into read-only memories (ROM). Eventually, anything programmed into ROM, EPROM, EEPROM, etc. became known as firmware. But it was, still, instructions that were fed to an instruction execution unit, one at a time sequentially. FPGA code is logic, not programmable instructions (spare me comments on the Micro-Blaze and its ilk). Personally, I would like to see a different term beause non-FPGA people will think that you are talking about a general purpose programmable computer. How about "coreware"?. Don't like it? Then invent your own. TomArticle: 97315
mk schrieb: >>VHDL may "produce" hardware when doing ASIC design. > > So what do you call a gate array or structured asic ? What does VHDL This is an ASIC too, just with a reduced number of user defined parameters (since most geometries are already fixed). > do when it generates files for one of these processes ? (for the > uninitiated gate-arrays or structured asics in general have all their > base layers produced already and several metals are used configure the > manufactured general purpose gates to what you want and provide the > connectivity). Yep. > By the same token when you take a bit file generated for an FPGA and > use it to produce a hard-copy device (a structured asic specifically > generated for a certain FPGA family) does the VHDL suddenly realize > that it has produced hardware ? What does this say for laser trim or There is always an exeption to every rule ;-) > metal only ECO ? > Also is an Intel or AMD processor really hardware as they have > micro-code which can be downloaded by BIOS which can be used to fix > quite a bit of "issues" with the processor. SoC ;-) >>In an FPGA not a single bit is "produced", all is fixed. > > > So the function of each LUT and how they are all connected are fixed > and the VHDL doesn't produce anything ? What does it do then ? If in Neither did I not write this nor did I say this. Nevertheless, incomplete quotes are quite popular. > my standard cell design, I have memory based FSMs the function of > which can be changed by updating the contents of such, does my asic > become software ? What about external pins which can change the The chip will stay an ASIC. But you can (and will) download firmware. > behaviour of combinational FSMs ? ;-) C'mon. > I think the issue is a lot less clean-cut then is suggested here. Maybe. Thats why we are here to discuss. Or to argue. Or to get into philosopy. The last works a lot better with a nice bottle of red wine ;-) Regards Falk, taking this "issue" not too serious, since it is quite academicArticle: 97316
On Mon, 2006-02-20 at 10:18 -0800, Marko wrote: > Traditionally, firmware was defined as software that resided in ROM. > So, my question is, what do you call FPGA code? Is "firmware" > appropriate? In a former position I pondered this very question. What is firmer than firmware (the term they used to describe code designs for micro-controllers) but softer than hardware (designs using wires to connect together various components)? The answer I came up with was "stiffware". The problem is that there are elements of both in FPGA code, or at least there can be. And depending on how you write your VHDL it may resemble one more than the other. James.Article: 97317
On a sunny day (20 Feb 2006 11:55:08 -0800) it happened "Jordi" <a80x86@hotmail.com> wrote in <1140465308.468125.76070@z14g2000cwz.googlegroups.com>: >Hi, >thanks to all for the answers :) !!! (and sorry for my bad english :( >) > >I think I'm begining to understand how it works. > >If the monitor uses PLL then the HSync frecuency determines how fast >the monitor moves the beam.So if I increase the HSync frecuency the >active time is shorter(and the back and front porch) but I can draw >more lines per second so I can have better resolutions. I don't >understand how resolution control works. The monitor has a fixed number >of pixels(Let's supose a 1024x768 monitor). If I ouput 640x480 images >and the monitor must draw 1024 pixels per line and 768 lines, then some >pixels will be repeated. Isn't it? Yes in an analog monitor there will be an 'aliasing' effect. Some LCD monitors and TVs will use digital processing to recalculate the picture for the resolution these themselves have. In such a case the timing requirements for the input format may be more strict, like for example a specific TV standard. In an analog monitor it is very possible to have 'half a pixel' on (if enough bandwidth): -- -- -- -- -- -- -- -- -- shadow mask --- --- --- --- --- --- --- video signal This 'half on' gives a brightness change at that pixel location. The intensity of the ascanning electron beam is just modulated by the video. In a LCD this is not the case, but the pixel brigtness can be corrected accordingly by processing.Article: 97318
Hi everyone, I am currently using cordic for arctangent in my system. I need at least 12 bits of accuracy. My x,y inputs are less than |1| in the form of 2.16. I have made some optimizations to another block in my system and it turns out that I have 6 extra slots of 32x32 multiplier resource but usage of 4 would be better (because of scheduling constraints). I don't have any dividers of course. Are there any algorithms which would need very few/small roms (which can be implemented in combinational logic) and 4 or so multipliers (and some adder/subtracters) ? Again I can't afford any dividers. Any suggestions are welcome.Article: 97319
metal wrote: > There are some underlying assumptions there which aren't necessarily > true. > > The biggest assumption is that individuals and small firms doing > small-volume products never work on apps which need large devices. > > That is simply not true....but I do agree that it sure seems to be a > common myth; t the mfg's like Altera etc., and sadly, among many > people here as well. I certainly agree, particularly as Reconfigurable computing enters the market as mainstream. here each FPGA computer user is expected to buy expensive vendor tools just to place and router HDL designs, even if they don't care about doing hardware designs for an FPGA product. > In a specialized application where the total build might be, say, 30 > boards; several thousand dollars is a good chunk of the total > bottom-line for the project. For a small R&D consultant it's a signficiant percentage of gross, especially when you need to support multiple vendors platforms to be competitive. That means that only large high volume shops are likely design in products. > Multiply that by the 5 different setups required in order to work with > larger parts from 5 different makers...plus annual "maintenance" fees > times 5....yeah, it's a burden...not something to sneeze at, in my > view. Same for RC users .... the vendor maintence fees to place and route are as much each year as the high end FPGA being used as a computational engine. Conside that XV4VLX200 chips are roughly the same price in volume as the annual maintence contract to actually use it as a computer -- ditto for large parts with PPC cores. Everybody would scream foul place if Intel/AMD held a similar IP lock on the assembly language and linker products (IE CPU bit streams) and required that you by an Intel linker (equiv of X&A place, route, bitstream generation tools) just to use your 4GHz Pentium. The reason that large X & A FPGA's remain low volume and that RC has had a difficult time taking off is simply the cold hard lock on their development tool IP prevents high volume adoption as a computational tools ... that leaves FPGA cold in the computational market, except for very high end or very low end uses. This mirrors the whole discussion about X & A NDA terms in their EULA locking open source out of actively using the their products, with the exception of some university projects that they quietly ignore the release of IP that isn't otherwise publicly documented. The profit from additional FPGA chip sales would very likely exceed the lost revenues for tool chain fees by several times, if not orders of magnitude, if they would just make the full product line available to the web pack tools -- allowing small R&D shop design in's, and removing the unrealistic maintence fee burden from reconfigurable computing end users that could care less about designing hardware products with FPGA's.Article: 97320
Julian Kain wrote: > The difference is execution versus synthesis. Firmware is indeed > embedded and dedicated code, but the code is executed. FPGA code is > written in a _description_ language, is then interpreted, synthesized, > and ultimately produces hardware. So, for Reconfigurable Computing, where we compile C directly to netlists to execute certain algorithms with high degrees of parallelism, use a sea of logic resources as a universal computer architecture, .... it's hard to consider the resulting fpga "design" (AKA program) either hardware or firmware. There is a reason I call FpgaC an HDL, and move it's syntax and use to mainstream computing (rather than leave it in it's original HLL focus when it was TMCC). But that really is true of other C compilers that target some C subset/superset HLL/HDL's such as Handel-C (Celoxica) or Streams-C (Impluse-C) as well. Some people use FpgaC/Handel-C/Streams-C to design "hardware" some just use it to run "software" on FPGA's. For that mater, the same is true of VHDL, Verilog, JHDL, and some dozen other FPGA centric HDL/HLL tools.Article: 97321
Falk Brunner wrote: > What code? The source code (VHDL/Verilog/whatever) or the final > bitstream? The same distinction applies to microprocessor "Firmware", > where you have the source code and the compiled binary. > Hmm, the more I write and think about it (where it should be better the > other way around ;-) FPGA and microprocessor bitstreams are becomming > more and more similar "Firmware". Enter dynamic reconfigurability, and it's not even "firmware" any more ... not hard locked in even a rom for many designs. More like a solid state disk, IE compact flash card, used has the primary storage in many portable computer devices, and a growing number of not so portable devices, to avoid hard drives. Sometimes, with even network driving dynamic loading, where all that is "rom'd" is a "boot loader", and the rest of the design is fetched off the net at powerup.Article: 97322
soar2morrow@yahoo.com wrote: > FPGA code is logic, not programmable > instructions (spare me comments on the Micro-Blaze and its ilk). > Personally, I would like to see a different term beause non-FPGA people > will think that you are talking about a general purpose programmable > computer. How about "coreware"?. Don't like it? Then invent your own. FPGA code USED TO BE (some ten or more years back) only a hardware designer accessable logic resource, that you *MIGHT* class as "not programmable instructions". The reality is (for the last 10 years) C compilers have compiled to netlists to execute HDL algorithms and programs directly on FPGA's. When Reconfigurable Computing was proposed, and researched over a decade ago, we also saw various HLL compilers targeting FPGA netlists as execution resources. TMCC is just one of many, and reciently it rebirthed at FpgaC. Handel-C, Streams-C, and nearly a dozen others, have also since appeared. Several are here to stay, some are lost research projects. C language code, is a combination of "logic" and "data path" representations. Actually, just about all programs are. Each LUT/FF pair is a minimal one bit state machine building block which with programable routing resources form wider and more complex state machines and data paths, which are highly configurable **AND** PARALLEL!!! An FPGA is the ultimate UNIVERSAL computing engine. Most HLL's are simply description languages for data path and state machine engines ... a perfect mariage with FPGAs that provide exactly those resources in the most configurable way.Article: 97323
On Mon, 20 Feb 2006 13:02:46 -0600, hmurray@suespammers.org (Hal Murray) wrote: > >>I am therefore trying to build a so-called "two-modulus prescaler" >>PLL. In other words, I would like to use the FPGA's internal logic >>in order to build a frequency divider that toggles between >>division by N and division by N-1. By adjusting the duty cycle >>of the divider toggling signal, I should be able to achieve >>output frequencies corresponding to high-resolution factional >>frequency multiplication factors. The toggling frequency >>should obviously be well above the PLL's loop filter bandwidth. >>I believe I can achieve the required divisor resolution with >>32-bit counters. > >What's the spectrum of the output of a "two-modulus prescaler"? > >What's the spectrum of a DDS? If you're referring to the MSB of the phase accumulator, then it has the same spectrum as the output of the dual modulus prescaler. If implemented properly, they will have identical outputs. >How low do I have to make the PLL bandwidth if I want to filter >out the junk? (Assume I run the DDS output through a PLL >to filter out the steps.) That depends on the junk. The spectrum of the junk close to the carrier varies wildly with the ratio in the divider. It's best to work out the spectrum with a program. I used to do it with a spreadsheet, but these days I use a C program (piped into Gnuplot). Regards, AllanArticle: 97324
On Mon, 20 Feb 2006 09:29:37 +0100, Stephane <stephane@nospam.fr> wrote: >workaround: > >you divide into 2 macros and create the 16 possible macros for LUT1 and >same for LUT2. I understand that a 16 bit ram can hold 2^16 different values, not 16. Of course, many of them are trival, and don't really count as distinct logic functions of four inputs. It's still an impractically large number though. Regards, Allan
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