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
"Leon Heller" <leon_heller@hotmail.com> wrote in message news:<bai98s$6om$1@hercules.btinternet.com>... > > You can use the ByteBlaster - just wire a socket up on a piece of > prototyping board. I think you need a resistor or two but it's a long time > since I did this with an EPC1. > > Leon hm.. I do need a flash config for FLEX EPF6010 - it seems to that Altera has no flash config eeproms for 6K? Atmels says his 17LV should work with Altera (flex 6K) but I am not sure. any ideas? I have one f... eval board with AD7679 and EPF6010, the 6010 has configuration that needs to be changed :( anttiArticle: 56201
Rick, No, there is no possible way to test every single possible interconnect. But we can cover 99.99....% of the device, and achieve excellent ppm defect rates in the shipped product. It is the same as saying "microprocessors can not possibly be tested for every combination of instructions" or "multipliers can not possibly be tested for every single possible multiplier and multiplicand." At some point, you have tested every transistor for its function, and enough transistors for their speed to get a high enough quality in the shipped product. You have to remember that a lot of folks still use FPGAs to simulate their ASIC/ASSP designs, and these folks KNOW about defect rates, as they are constantly laoding the FPGAs with always changing designs. If you want an FPGA that is 100% tested for your application, that is called the "EasyPath" product, and it actually costs you less. But is Antifuse FPGAs, there is just no possible way to test, period. It isn't even a question of time, cleverness, or cost. If the fuse doesn't blow, there is no way to know in advance.... Another reason why they are not made in the sizes that our FPGAs are available in. Lastly, Xilinx doesn't use SRAM. We use CMOS Configuration Cells (CCC). These are not the minimum size SRAM cell that are used by the industry, but memory cells specifically designed to do a very special job. They are 7 times more resistant to soft errors (at least from the measurements we have so far), and they are far more robust. So much so, that most people forget they are there at all. Austin rickman wrote: > > "H. Peter Anvin" wrote: > > > > Followup to: <3ED659EA.F20FBA79@xilinx.com> > > By author: Peter Alfke <peter@xilinx.com> > > In newsgroup: comp.arch.fpga > > > > > > Here are the undisputed pros and cons: > > > > > > Antifuse advantages: > > > Instant-on, needs no configuration PROM or other store, security is > > > easier, and radiation tolerance is better for space applications. > > > > > > Antifuse disadvantages: > > > one-time only programming (you have to throw the device away if you want > > > to make any change) > > > slow programming,( takes many minutes for larger devices) > > > more restricted upper device-size limit ( no multi-mega-gate circuits) > > > fewer sophisticated features (clock manipulation, RAMs, multipliers, etc) > > > > > > > You're forgetting one: yield. Because an antifuse FPGA is OTP, no > > testing done at the factory can guarantee that every device will > > program correctly. I don't know that the fallout percentage is > > nowadays -- for all I know it might be negible -- but still... > > You make it sound like they can test the SRAM FPGAs 100%. If you belive > that, I have a bridge in Brooklyn I would like to sell you. > > -- > > Rick "rickman" Collins > > rick.collins@XYarius.com > Ignore the reply address. To email me use the above address with the XY > removed. > > Arius - A Signal Processing Solutions Company > Specializing in DSP and FPGA design URL http://www.arius.com > 4 King Ave 301-682-7772 Voice > Frederick, MD 21701-3110 301-682-7666 FAXArticle: 56203
Jim Granville wrote: > > rickman wrote: > > > > Jim Granville wrote: > <snip> > > > > On this path, there was mention a while ago in c.a.f of a (very old) > > > uC core that used a LFSR as the PC. This solved a speed-bottleneck, > > > (plus uses less logic) but needed more work in the assembler. > > > Seems this could have real merit in the 'smallest cpu' direction. > > > > I can see PC relative addressing becoming a real PITA. Adding '1' to an > > LFSR is no big deal, but adding N is a big deal. > > Check the older thread - IIRC they avoided both operations, and moved > all PC maths to the assembler. > This thread is called "smallest embedded cpu....and the most pain", so > the emphasis is very much on the vanilla end of the spectrum. > > On your Hi-Temp operation issues - I did see Zilog now offer high temp > grades of their eZ8 uC ( and press info, but no data yet no the smaller > Z8F04). > > Also saw some interesting FIT curves in a latest OnSemi curve, showing > lifetime degrades going above 80'C - something like 120 yrs -> 2 yrs > for 80'C to 130'C. Thanks for the update. But the small MCU was taken out of the design in favor of a CPLD. I can't integrate as many functions, but it deals with the battery backup RTC a lot better. I also found the MicroBuddy which gives me about three functions in one package if they will tell me it works ok up to 125C. They provide characterization curves on some data up to 125C, so it sounds reasonable. It just got too hard to try to find a high temp, low voltage MCU in a (really) small package. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 56204
I appreciate the info, but I am well aware of the various factors involved in testing. My point was simply that although the anti-fuse parts have a non-zero failure rate due to the inability to test the fuses, no part is ever 100% tested and the actual failure rate number is what is important. Generalizations are not worth much. Numbers are much more valuable. I just wanted to make sure the OP understood that he needs to evaluate the failure rate number rather than just generalizing that "anti-fuse parts are not tested and SRAM parts are". In both cases, the final product still needs to be tested since manufacturing failure rates are likely much higher than the failure rates of any of the types of FPGAs. Austin Lesea wrote: > > Rick, > > No, there is no possible way to test every single possible > interconnect. But we can cover 99.99....% of the device, and achieve > excellent ppm defect rates in the shipped product. > > It is the same as saying "microprocessors can not possibly be tested for > every combination of instructions" or "multipliers can not possibly be > tested for every single possible multiplier and multiplicand." > > At some point, you have tested every transistor for its function, and > enough transistors for their speed to get a high enough quality in the > shipped product. > > You have to remember that a lot of folks still use FPGAs to simulate > their ASIC/ASSP designs, and these folks KNOW about defect rates, as > they are constantly laoding the FPGAs with always changing designs. > > If you want an FPGA that is 100% tested for your application, that is > called the "EasyPath" product, and it actually costs you less. > > But is Antifuse FPGAs, there is just no possible way to test, period. > It isn't even a question of time, cleverness, or cost. If the fuse > doesn't blow, there is no way to know in advance.... > > Another reason why they are not made in the sizes that our FPGAs are > available in. > > Lastly, Xilinx doesn't use SRAM. We use CMOS Configuration Cells > (CCC). These are not the minimum size SRAM cell that are used by the > industry, but memory cells specifically designed to do a very special > job. They are 7 times more resistant to soft errors (at least from the > measurements we have so far), and they are far more robust. So much so, > that most people forget they are there at all. > > Austin > > rickman wrote: > > > > "H. Peter Anvin" wrote: > > > > > > Followup to: <3ED659EA.F20FBA79@xilinx.com> > > > By author: Peter Alfke <peter@xilinx.com> > > > In newsgroup: comp.arch.fpga > > > > > > > > Here are the undisputed pros and cons: > > > > > > > > Antifuse advantages: > > > > Instant-on, needs no configuration PROM or other store, security is > > > > easier, and radiation tolerance is better for space applications. > > > > > > > > Antifuse disadvantages: > > > > one-time only programming (you have to throw the device away if you want > > > > to make any change) > > > > slow programming,( takes many minutes for larger devices) > > > > more restricted upper device-size limit ( no multi-mega-gate circuits) > > > > fewer sophisticated features (clock manipulation, RAMs, multipliers, etc) > > > > > > > > > > You're forgetting one: yield. Because an antifuse FPGA is OTP, no > > > testing done at the factory can guarantee that every device will > > > program correctly. I don't know that the fallout percentage is > > > nowadays -- for all I know it might be negible -- but still... > > > > You make it sound like they can test the SRAM FPGAs 100%. If you belive > > that, I have a bridge in Brooklyn I would like to sell you. > > > > -- > > > > Rick "rickman" Collins > > > > rick.collins@XYarius.com > > Ignore the reply address. To email me use the above address with the XY > > removed. > > > > Arius - A Signal Processing Solutions Company > > Specializing in DSP and FPGA design URL http://www.arius.com > > 4 King Ave 301-682-7772 Voice > > Frederick, MD 21701-3110 301-682-7666 FAX -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 56205
>I find this too primitive, no Full or Empty, no "dipstick", etc There is a type of design where an almost-full or almost-empty flag is a lifesaver. If you are copying data to or from a FIFO, and there are enough pipeline stages involved, it gets hard to make the decisioin in a single cycle. With an almost-xxx flag, you can run at full speed (1 word per cycle) when you know you have lots of room left and then slow down to 1 word every other cycle (or whatever you need) when you get near the edge. The size of "almost" didn't matter much in the designs I worked on. A few words would have been be fine. I think 1/8th of the FIFO was commonly available in single chip FIFOs. -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.Article: 56206
[contect is 8 bits in and 32 out] >Expect it this fall, but probably only in BRAM form. >The problem is that 1, 2 or 3 eight-bit words might get left stuck in >the FIFO when it declares itself empty, because there is no more 32-bit >word to be read. :-) I can easily imagine that different applications will want different things to happen. Or different things at different times/modes. In the middle of a packet, I'd probably want to wait for more data. At the end of a packet, I'd probably want to flush the packet and have the output side give me an error flag and/or tell me how many bytes were missing in the last word. That probably requires help from the application - it's the only one that knows when the packet is finished. My guess is that people will use whatever you provide. At worst, they will have to build their own 8-32 collector and then use a 32 bit FIFO. Speaking of packets... Some applications need an extra bit for an end-of-packet marker so they can have several packets in the FIFO at the same time. That interacts with pipelineing. (see my previous comments on an almost-empty flag) If the building block is a 9 bit wide RAM, it's easy to pack both an end-of-packet flag as well as the missing byte info. If you start with a 33 bit wide RAM, the missing byte info won't fit. (or the EOP flag won't fit, which works if you only have one packet in the FIFO and use the empty flag as an end marker) -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.Article: 56207
On Fri, 30 May 2003 18:02:46 +1000, "Alex Gibson" <alxx@ihug.com.au> wrote: > >"Spam Hater" <spam_hater_7@email.com> wrote in message >news:ap07dvg9qje6mugq6np508863shimgjqiu@4ax.com... >> I have two answers (opinions) >> >> 1) It is not possible. The contract between Xilinx and the synthesis >> vendor was terminated over a year ago. There is NO HDL software >> support for this device from Xilinx. See if Digilent will trade the >> board for a SpartanII board. >> >> 2) The software is good, but the board is useless. All it has is the >> chip on a PCB; no oscillator, stake pins for I/O, and not even a >> voltage regulator. (I was going to make an expansion for mine, but >> decided that getting a different board would be cheaper.) >> >> $.02, >> SH7 >> >> PS: Take a look at Tony's products: www.burched.com >> > >huh ? > >what do you mean the board has no oscillator ? > >He didn't say which board he had and all the digilent boards have regulators >and oscillators. >See http://www.digilentinc.com/Catalog/system_boards.html >and http://www.digilentinc.com/Catalog/all_in_one.html >for the two that don't mention if they have oscillators check the pages for >each >and you will see they do. > #2 is referring to the Cypress board. Please read the original post(s).Article: 56208
that's great, we only need 1000. do you have any link that explantion the GMII? thanks pyng hmurray@suespammers.org (Hal Murray) wrote in message news:<vdbahc5bg84e19@corp.supernews.com>... > >1) how difficult to create a custom-built interface in Xilinx Virtex > >II to GMII or TBI, just to transfer data? any pointer, link , that I > >could read about the GMII? I try google, but most of them is talking > >about interfacing with the MAC. not much on the protocol of GMII. > > GMII is pretty simple. Can you get the PHY chips? > > The transmit side is clock, 8 bits of data, and a data-valid bit. > You can think of data-valid as carrier. The clock goes in the same > direction as the data. > > The receive side is the same thing in the other direction - the > PHY chip provides the clock. > > You can take two gizmos that talk GMII and wire them directly > to eachother. Or a full-duplex gizmo can talk to itself > through a loop-back connector. > > That's for gigabit. It gets more complicated if you want 10/100 > too, but you can ignore that if you are willing to run at only 1000.Article: 56209
I assume you are talking about 1394b, the new version of the current 1394 that extent to 100meter , have the standard been out? we are thinking of having it(Gigi-E or may be 1394b) on board not as a external box of something. and repeater in bewteen is not an option. pyng christopher.saunter@durham.ac.uk (Christopher Saunter) wrote in message news:<bb4me9$ej6$1@sirius.dur.ac.uk>... > spyng (ospyng@yahoo.com) wrote: > : hi all, > : need some help on this, > > : need to send about 500Mbit/s of data(images) between our equipment 100 > : ft (30 meter ) apart. we have rule out USB 2.0 and Firewire, because > : of the distance. both are about 5 meter per segment (as I understand). > : so we are thinking of using Gigabit Ethernet, just the phy if > : possible. I am not too familiar with the Gigabit Ethernet, so here is > : the question > > Have you considered using a fibre optic repeater for firewire? I was > looking into this a few months ago, and they exist, and transparently > extend 1394/firewire to > 100m. If I remember correctly a pair of boxes > + 30m fibre was arround us$1000. Can't find the link I'm afraid, although > I think it was from an AV specialist. > > --- > > cdsArticle: 56210
"Austin Lesea" <Austin.Lesea@xilinx.com> ha scritto nel messaggio news:3ED6786E.301C05D9@xilinx.com... > The simple answer is that there is a real barrier to doing > this. The cost. And the cost of the entire system? FPGA don't work alone. If all the sacrifices were meant to reduce the prices, the configuration devices wouldn't cost more than the FPGA itself (only recently Xilinx started to produce affordable flash proms). -- LorenzoArticle: 56211
Lorenzo, It seems that many have used them for years affordably, and I am happy to hear you say that our proms are now 'affordable' in your applications. Austin Lorenzo Lutti wrote: > > "Austin Lesea" <Austin.Lesea@xilinx.com> ha scritto nel messaggio > news:3ED6786E.301C05D9@xilinx.com... > > > The simple answer is that there is a real barrier to doing > > this. The cost. > > And the cost of the entire system? FPGA don't work alone. If all the > sacrifices were meant to reduce the prices, the configuration devices > wouldn't cost more than the FPGA itself (only recently Xilinx started to > produce affordable flash proms). > > -- > LorenzoArticle: 56212
Followup to: <3ED6C51C.A6D5CCD@yahoo.com> By author: rickman <spamgoeshere4@yahoo.com> In newsgroup: comp.arch.fpga > > "H. Peter Anvin" wrote: > > > > Personally, I refer to an FPGA configuration stream as firmware. It > > walks like firmware and quacks like firmware... > > That is what this discussion is about. What exactly do you consider to > be "walking" and "quacking"? This is an attempt to quantify the > features that distinguish firmware from software from *other*ware. > I doubt a black-and-white definition is possible, but I generally considers firmware to be software stored in a ROM or something that "looks like a ROM to the user." The latter is obviously extremely vague, because it is a nebulous thing: consider a small printer which has its system program in ROM. Is that firmware? Almost certainly. Consider a large printer with its system program on an internal hard disk. Is that firmware? As far as the end user is concerned, there really is no difference compared to the small printer -- unless you crack the case and look, you wouldn't know. What I think *is* clear is that firmware is a form of software. I think "software that acts as if it was part of a piece of hardware from the perspective of the end user" is the salient aspect here. I also think it's pretty clear that at least flash/SRAM FPGA/CPLD configuration data is also a form of software, and would generally be classified as firmware. It has all the attributes of software, although the machine it executes under is usually in computer science term a heavily parallel Harvard architecture, which is unfamiliar to most people. It's in some ways a 21st-century analogue to the programming boards used to program ENIAC. Antifuse or OTP (as well as OTP PROMs!) is potentionally a gray area, but I would still consider it firmware. I would draw the line at semicustom ASICs, even the ones like HardCopy which map an FPGA design 1:1. After all, using software to prototype hardware is a time-honoured (and very useful!) technique. -hpa -- <hpa@transmeta.com> at work, <hpa@zytor.com> in private! "Unix gives you enough rope to shoot yourself in the foot." Architectures needed: ia64 m68k mips64 ppc ppc64 s390 s390x sh v850 x86-64Article: 56213
Hi, Actually such products do exist for ages. Gatefield did many Flash based FPGAs in 90's then Actel took it over and currently produces 50k to 1M gate Flash FPGAs (ProASIC and ProASIC+). In addition QuickLogic and Actel produce Antifuse (One-Time Programmable) FPGAs for many years. Also Lattice recently introduced ispXPGA family with embedded Instant E2 cells (it's much better than configuration EEPROM as it takes milliseconds to upload SRAM because of parallel load mode). Sergei "Ralph Mason" <masonralph_at_yahoo_dot_com@thisisnotarealaddress.com> wrote in message news:TBtBa.35461$3t6.555738@news.xtra.co.nz... > I don't know much about Semiconductor processes. But I wonder why it isn't > possible to make FPGA's with some flash memory in there, enough to hold 2x > the bit streams for the FPGA. A little Flash boot section (like CPLDS') of > FPGA could be used to configure the rest of the FPGA from the Embedded > flash. > > This means you can self configure with a protected bitstream, you can use > the flash in your application if you like, etc etc. It also gives you NV > ram in the FPGA which just can't be a bad thing. > > Seems like a simple idea - and a nice setup, is there a big technical > barrier to such a setup? Is it comming? Should I have pateneted it? Are > there already some out there? > > Ralph > >Article: 56214
Then we have to ask ourselves: Why are all these companies so small and/or doing so poorly? The market is the final arbiter. Success in this industry is defined by a profitably growing sales volume... Peter Alfke ==================== Sergei Skorobogatov wrote: > > Hi, > > Actually such products do exist for ages. > Gatefield did many Flash based FPGAs in 90's then Actel took it over and > currently produces 50k to 1M gate Flash FPGAs (ProASIC and ProASIC+). > In addition QuickLogic and Actel produce Antifuse (One-Time Programmable) > FPGAs for many years. > Also Lattice recently introduced ispXPGA family with embedded Instant E2 > cells (it's much better than configuration EEPROM as it takes milliseconds > to upload SRAM because of parallel load mode). > > Sergei > > "Ralph Mason" <masonralph_at_yahoo_dot_com@thisisnotarealaddress.com> wrote > in message news:TBtBa.35461$3t6.555738@news.xtra.co.nz... > > I don't know much about Semiconductor processes. But I wonder why it > isn't > > possible to make FPGA's with some flash memory in there, enough to hold 2x > > the bit streams for the FPGA. A little Flash boot section (like CPLDS') of > > FPGA could be used to configure the rest of the FPGA from the Embedded > > flash. > > > > This means you can self configure with a protected bitstream, you can use > > the flash in your application if you like, etc etc. It also gives you NV > > ram in the FPGA which just can't be a bad thing. > > > > Seems like a simple idea - and a nice setup, is there a big technical > > barrier to such a setup? Is it comming? Should I have pateneted it? Are > > there already some out there? > > > > Ralph > > > >Article: 56215
Presently I find myself conducting a development of an experimental IC function that makes central use of propagation delays in performance of it's functions. I would be interested to learn of any others that may have used FPGAs to investigate novel IC hardware applications.Article: 56216
ospyng@yahoo.com (spyng) wrote in message news:<b34a8c79.0305281549.5f3a9ff8@posting.google.com>... > hi all, > need some help on this, > > need to send about 500Mbit/s of data(images) between our equipment 100 > ft (30 meter ) apart. we have rule out USB 2.0 and Firewire, because > of the distance. both are about 5 meter per segment (as I understand). > so we are thinking of using Gigabit Ethernet, just the phy if > possible. I am not too familiar with the Gigabit Ethernet, so here is > the question > > 1) how difficult to create a custom-built interface in Xilinx Virtex > II to GMII or TBI, just to transfer data? any pointer, link , that I > could read about the GMII? I try google, but most of them is talking > about interfacing with the MAC. not much on the protocol of GMII. > > 2) or must we use a MAC and implement TCP/IP stack? we trying to avoid > that. > > 3) we are looking at LVDS too, National claim to be able to drive > 300meter of cable with an Adjustable Output cable driver CLC001, any > one have experience with it ? > > any comments,link, pointer are welcome. thanks > pyng I believe SpaceWire IEEE 1355 highspeed may suit your needs. Its a simplified version of the old Transputer T9000 link layer, usually at 100-200MBits or so, but a higher speed version near 1G is in the standard too. The lower speed interface logic is supposed to be far simpler than the typical Uart. JJArticle: 56217
Yeah, documentation to help the unwary user figure out which of the many choices
he should be using.
Peter Alfke wrote:
> I am looking at revamping the FIFO cores, giving you many options:
> asynchr. vs synchronous, with exact empty and full
> extra one-clock-early empty and full indicators
> programmable almost empty and full indicators,
> readable occupied size ,
> etc
> Any additional suggestions?
>
> Peter Alfke, Xilinx
> ================
> Ralph Mason wrote:
> >
> > "Ralph Mason" <masonralph_at_yahoo_dot_com@thisisnotarealaddress.com> wrote
> > in message news:IhXAa.32629$3t6.476804@news.xtra.co.nz...
> > > "Muthu" <muthu_nano@yahoo.co.in> wrote in message
> > > news:28c66cd3.0305272041.4361c105@posting.google.com...
> > > > Hi,
> > > >
> > > > With an N depth RAM, I could build a FIFO of depth N. Right?
> > > >
> > > > But this may not be true with asynchrnous FIFO. some where i heard
> > > > that, for asynchrnous FIFO 1 location is wasted. why? and How?
> > > >
> > > > In general all the Circular FIFO documents also, saying that only N-1
> > > > depth is possible with N location RAM.? why?
> > > >
> > > > Thanks in advance
> > > >
> > > > Regards,
> > > > Muthu
> > >
> > > You can never fill the FIFO to N because then the write pointer and the
> > read
> > > pointer would be equal and it would look like the fifo was empty.
> >
> > Never say never unless you mean it.
> >
> > Anyway as many have pointed out, you can design anything any way you like.
> >
> > Why did I say never - well for one fifo space is it worth the extra
> > complexity? Are there implementations that would use the same resources to
> > use all the ram and the above? Are there just plain better implementations?
> >
> > Ralph
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 56218
Yes, but if you can take advantage of the independently adjsutable aspect
ratios on the BRAM ports, you save a fair amount of packing or unpacking
logic
John Williams wrote:
> Peter Alfke wrote:
> >
> > Marc Randolph wrote:
> >
> >>Howdy Peter,
> >>
> >>This might be more effort than you had in mind, but we've had a need
> >>several times for an asymetric async FIFO... 8 bits in @ 155 MHz, 32
> >>bits out @ 50 MHz. And the reverse of course. While I'm dreaming, we
> >>could use them in both BRAM and LUT RAM form.
> >
> >
> > Expect it this fall, but probably only in BRAM form.
> > The problem is that 1, 2 or 3 eight-bit words might get left stuck in
> > the FIFO when it declares itself empty, because there is no more 32-bit
> > word to be read. :-)
>
> Couldn't people just do this as a front end to a "vanilla" 32 bit wide
> FIFO?
>
> John
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 56219"H. Peter Anvin" wrote: > > Followup to: <3ED6C51C.A6D5CCD@yahoo.com> > By author: rickman <spamgoeshere4@yahoo.com> > In newsgroup: comp.arch.fpga > > > > "H. Peter Anvin" wrote: > > > > > > Personally, I refer to an FPGA configuration stream as firmware. It > > > walks like firmware and quacks like firmware... > > > > That is what this discussion is about. What exactly do you consider to > > be "walking" and "quacking"? This is an attempt to quantify the > > features that distinguish firmware from software from *other*ware. > > > > I doubt a black-and-white definition is possible, but I generally > considers firmware to be software stored in a ROM or something that > "looks like a ROM to the user." The latter is obviously extremely > vague, because it is a nebulous thing: consider a small printer which > has its system program in ROM. Is that firmware? Almost certainly. > Consider a large printer with its system program on an internal hard > disk. Is that firmware? As far as the end user is concerned, there > really is no difference compared to the small printer -- unless you > crack the case and look, you wouldn't know. > > What I think *is* clear is that firmware is a form of software. I > think "software that acts as if it was part of a piece of hardware > from the perspective of the end user" is the salient aspect here. > > I also think it's pretty clear that at least flash/SRAM FPGA/CPLD > configuration data is also a form of software, and would generally be > classified as firmware. It has all the attributes of software, > although the machine it executes under is usually in computer science > term a heavily parallel Harvard architecture, which is unfamiliar to > most people. It's in some ways a 21st-century analogue to the > programming boards used to program ENIAC. > > Antifuse or OTP (as well as OTP PROMs!) is potentionally a gray area, > but I would still consider it firmware. I would draw the line at > semicustom ASICs, even the ones like HardCopy which map an FPGA design > 1:1. After all, using software to prototype hardware is a > time-honoured (and very useful!) technique. I don't mean to bug you, but you still did not answer the question of what distinguishes software from *other*ware. You said about FPGA/CPLD configuration data, "It has all the attributes of software". What features are you considering when making this claim? What defines software vs. *other*ware? What makes an antifuse program different? What makes semicustom asics different? -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 56220
Peter Alfke wrote: > > Then we have to ask ourselves: > Why are all these companies so small and/or doing so poorly? > The market is the final arbiter. Success in this industry is defined by > a profitably growing sales volume... I remember a time when Xilinx stock was over 90. Last time I checked it was still below 30. I bet there are some very unhappy investors out there still. How was *your* bonus last year? ;) -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 56221
Ok, you want to design your own kick arse CPU but you're not sure if you should be using 8, 16 or more directly addressable registers, whether you should allow multiple stacks, what sort of indexing you should allow etc, etc. Your biggest problem isn't building your CPU, it's your support software. You don't want to write a new assembler for each experimental version of your CPU, you just want the assembler to be there and you want to get on with what you really want to do - experiment with the core. So how can we help. We have a meta compiler with capabilities you wouldn't believe. With it you can produce in only a few days a high quality tailored assembler that would otherwise take an experienced software engineer months of effort. Well ok you could argue that once you've written one assembler you can just patch it to produce code for another core design. The reality though (completely ignoring time and cost issues) is that your assembler will only be modifiable within very small limits without a great deal of rework. How would an assembler designed for a Z80 cope with code for a 6502 or and MSP430? Answer - very badly. Our meta assembler can cope with complex instruction syntax (including context sensitive expressions), very long instructions (made up of any number of fields), string expressions, floating point expressions (no need for an external package), complex section handling (including groups, overlays and commons), relocated assembler listing and a lot more. The basic package comes with definitions for Z80, 6502, MSP430, PIC (16 series), 68HC11 and 6800. You can either use these as starting points for your own core or you can create completely new ones. As an example, you might design a hybrid Z80 type core that uses RISC instructions. Some of these instructions could be mapped directly to core instructions while other instructions could be mapped to sequences of multiple core instructions. Given the syntax of the Z80 assembly language this would be impossible to achieve using macros. You could now argue that starting with a pure Z80 assembler would (after a lot of hacking) give you the same capabilities. Well no not really. Our meta assembler would also allow you play with the core RISC instructions, mixing them with the hybrid Z80 instructions. Tinkering with your CPU core design really does become your main activity with the aid of our meta assembler. Our meta assembler is called XCASM and is at the heart of our XCSB compiler and ZMech CASE tool. Documentation on the use of XCASM is available online at http://www.xcprod.com/titan/XCASM Documentation on it's configuration is proprietary, copyright and not available online. Regards Sergio Masci Sentient Real Time Systems Ltd http://www.xcprod.comArticle: 56222
Hi, Generally control path alone have FSM. Whats wrong in having FSM for data path too? Regards, MuthuArticle: 56223
hi, In my design I have few internal enable signals, some of them are always one and some follows the a gated clock. What I would like to know is: In a design if a pin is permanently at VDD consumes more power or a gated clocked like signal(changes to 1 to 0, and 0 to 1) consume more power? assuming other i/p are same in the design. Thnaks for the help. Valli.Article: 56224
In article <bb2547$52qpl$1@ID-192450.news.dfncis.de>, its.me.hates- spam@uni.de says... > > In my VHDL-code this signals exist. Why does this warnings occure? > How to watch variables, signal etc. during sumulation? That's because VHDL compiler found a way to do the same work as you specify in VHDL file but without using those signals, so they can be removed. What I do when I want to watch an optimized signal is placing an output pin directly connected to it, so compiler can't remove it. The best would be disabling compiler optimization, like you would do in a C/C++/Pascal programming environment, but I don't know if that's possible using Quartus. Hope this helps -- Jesus Jimenez jesjimenez@NOSPAMtelefonica.net
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