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
On Fri, 25 Jul 1997 08:56:09 GMT, fliptron@netcom.com (Philip Freidin) wrote: >Typically, I find that the place for optimization of DSP algorithms in >FPGAs is in how the multiplies are done. Often (say in an FIR filter) the >multiply is by a constant. So the first optimization is to throw away the >slices of the multiply where the constant bit is a zero. What is left is >the '1' bits. So an optimization may be to adjust the FIR design so that >the constants have a minimal set of '1' bits. For example you could >support a dynamic range of constants of 8 bits, giving 0 thru 255, but set >a rule that no constant can have more than 3 bits set. This would allow >constants like 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 16, 17, ... >upto 224. While all possible values are not available, you get a good >range down near zero, a reasonable selection all the way upto 224. Why >bother? Well you can implement this constrained multiply with just one or >two adders. Here is another example of a constraint: the constant can >have at most 2 bits that are non-zero, and the non-zero bits can have >either Positive or Negative weighting. So you can do things like 7 = 8-1, >9 = 8+1, 24 = 16+8 and 56 = 64-8, and lots more. This type of multiplier >can be implemented in just one adder/subtractor! Indeed, the first method is straight forward Booth Multiplier, which gives improvement where there is a run of identical bits. Better for larger width data is Modified Booth triplet (signed multiplication). Especially where you must have all possible values as coefficients. It guarantees to reduce adder/subtractor terms by 2 when doing a new multiplier & multiplicand every clock cycle. This is at the expense of some add/sub selection and shifting, but nothing in life is for free. Failing that, the "constant co-efficient" multiply is much easier to implement with a ROM, or LUT's and cascaded adders. It's also pretty compact. e.g. In ORCA, such an implementation allows 8x8 multipliers to exceed 100 MHz, and require 10 PFUs for each multiplier. (a 16 bit adder is 4 PFU's). <snip of example design> Nice example. Illustrated the point very nicely. StuartArticle: 7051
On Sat, 26 Jul 1997 08:52:15 GMT, z80@dserve.com (Peter) wrote: > >>So try a 3.3V ORCA FPGA, and put clocks on globals, longs, or even >>half length lines. The I/O's can direct drive all the routing (xL, xH, >>x4, and x1, so clock pad to PFU (CLB) clock input can be fast too. > >If this works in Orca devices, why not in Xilinx devices? I have absolutely no idea, so I guess we'll leave that one for Xilinx to answer. However, a few thoughts spring to mind... 3000 series (Lucent) The K pin can be driven in the 3000 series via a small fixed piece of local routing by the vertical long line nearest the CLB. Assuming that the only driving source is the single long line, then I can see no reason why it shouldn't work providing the following steps are taken 1 The clock input pad must be on the top or bottom of the FPGA. Left or right won't work. It's best if its the left most one, as this one can directly drive the necessary long line. 2 All clocked CLB's must be in the same column as the IOB. Break this rule, and your skew will bomb. 3 Use Foundry and specify a maximum skew, so the routing doesn't go mad and go through magic switches etc. I did a few examples, and it seemed fine from simulation and timing reports. In the 3000 series architecture, there are re-powering buffers at the top and bottom of the long line, but I don't think they should affect this kind of application. Maybe in 3000A series it's different. I can't tell, as I don't have XACT. 4000E, EX, XL series The input buffer drive from I1 appears only to drive the edge decoder, a double length line, and two single length lines, so that certainly isn't any use for a clock input. The I2 port can drive direct routing (no use) or the tri-state buffers running onto the inner of the 3 long lines running above and below the two pad group. To route from either of those long length lines to the K input will then require moving onto the single length lines via a switch. I can only see a possible path from the lower of the two lines in the architecture to the K input. There are no K connect points from the vertical long lines showing the lack of symmetry in the 4000 series architecture. I guess this kind of approach might work if the routing can be kept the same. Is there a clock skew specification in XACT yet? Have they kept it over from NeoCAD in M1? This type of clock might be safe in 4000 series' with the following rules. 1 The clock input pad can only be on the left or right of the FPGA die. 2 All clocked CLB's must be in the same row. (I don't know about driving IOB clocks, but it looks very dodgy). 3 The clock must be distributed on the lower long line that is driven by the TBUF's. All in all, a bit of a nightmare for 4000 series. If I'm wrong on any of this, somebody please tell me. ORCA In ORCA, the clock distribution arrangement is very different, as there are no global buffers per se. This gives the engineer a lot of flexibility. The clock input to a PFU (containing 4 flipflops) can be directly driven by any one of the eight long and half length lines running both horizontally, and vertically in each channel. Similar rules will apply as with Xilinx, but there is much more freedom of placement and routing. The real benefit comes when you cannot locate all PFU's in one row, or column, but can perhaps restrict them two or three columns or rows. When you do this, you can bring the clock in on a distribution spine, and just drive two long length lines for the rows or columns actually being used. This might not sound like much of a big deal, but in a 2C15A, this could mean a reduction in clock loading of as much as 90%. Driving of output flipflops isn't a problem either. To use a phrase that has been used before: "ORCA. Burn rubber, not boards". StuartArticle: 7052
Well, there is the cover of Scientific American, July 1997. Pelase, excuse the somewhat self-serving answer. Peter Alfke, XilinxArticle: 7053
In article <33d809ad.15752806@news.mindspring.com>, tech100@mindspring.com wrote: >Not to be critical, but how come you use a date format that cannot be >recognized intuitively? Isn't it easy to confuse it with the other >non-intuitive method? You know, 3/1/97 is March fisrt to some, and >January third to others. Hmmmm, it seems perfectly 'intuitive' to me to interpret a date or time in a sequential order from smallest to largest or largest to smallest. The fact that a few confused people seem to like to mix things up should not stop us using perfectly sensible systems. The annoying thing is that many computer programs and systems use this strange mixed up format by default. Must be due to the silly byte reversal on Intel 80XXX processors! NicArticle: 7054
Nic wrote: > >tech100@mindspring.com wrote: > >>Not to be critical, but how come you use a date format that cannot be >>recognized intuitively?..cut... > >Hmmmm, it seems perfectly 'intuitive' to me to interpret a date or time in a >sequential order from smallest to largest or largest to smallest. The fact >that a few confused people seem to like to mix things up should not stop us >using perfectly sensible systems. The annoying thing is that many computer >programs and systems use this strange mixed up format by default. Must be >due to the silly byte reversal on Intel 80XXX processors! I'm told the ANSI standard is big-endian year_month_day, so there can be no mixup as with mixed (conventional US) or little-endian (current UK/Europe) date and big-endian time (universal). This matters once we get past 2000, since with two (decimal) digits at least one could always be certain which one was the year, but in 2001... Tim Forcer tmf@ecs.soton.ac.uk Department of Electronics & Computer Science The University of Southampton, UK The University is not responsible for my opinionsArticle: 7055
Tom Burgess (a fellow Canuck) wrote: > > What would make me really happy (for multirate DSP) is some way of > synchronously distributing derived clocks, each synchronously gateable. > For example, from a 1X 100MHz fast clock input, distributing 100, 50 and > 25 Mhz clocks on chip, with all clocks having guaranteed relative skew > so that data could be transferred between any combination of flip-flops > with no timing hassles. Easy to say, but hard to do I'm sure. Actually this kind of clocking is easy to do. There is a silicon company (IDT I think) that make ICs to perform that function at the board level and do it well. A similar "core" could be dropped into the FPGA silicon for kick-ass clock distribution. This however leads back to the original problem of power dissipation. You can imagine what dividing and generating low skew, high slew clock drivers does for your power dissipation. FPGA silicon is always a trade off. The target is to do many things well, not few things exceptionally. Tim Warland ASIC Engineer -- You better be doing something so that in the future you can look back on "the good old days" My opinions != Nortel's opinion;Article: 7056
> Either way all FPGAs suck tremendously in performance and per unit cost > compared to gate array or standard cell ASIC implementation. I redid a > 8000 gate FPGA built in a 0.6 um process with a 10,000 gate gate array (I > added a few extra functions) in a nearly obsolete two metal 1.0 um process. > The FPGA only ran at about 2/3 of the maximum target clock frequency, the > gate array twice as fast as needed. The gate array was about 25% the cost > (for a relatively low volume video capture and processing VME card) of the > FPGA and the gate array NRE plus my time was paid for after selling less > than a 100 units. (This didn't even include the cost of maintaining the > FPGA fuse files and programming parts on the production floor). > > A good compromise is if you can design system ASIC(s) to be drop in compatible > with an existing FPGA. The system can be brought up earlier with the FPGA and > lab testing and evaluation can provide valuable input to the final ASIC design > (and even reduced capability early beta units to customers). Sometimes some FPGA > samples might run fast enough under benign or conditions to run a few systems at > full speed prior to sampling the ASIC. Well put. No suprise here :) Peter. Return address is invalid to help stop junk mail. E-mail replies to z80@digiserve.com.Article: 7057
Thank you for a very informative post. The problem is that do achieve this one needs to do a lot of hand layout. I have always used schematic entry only for FPGA work, with constraints specified as net attributes. (I know what the diehards here will say about that, but I believe FPGAs should be regarded as a *solution* to a problem :)) With the older Xilinx devices, one could attach a L attribute to a local clock net (forces it onto a long line), add a SC=1 (skew below 1ns) attribute, and that would do it. This was with the old (1991) APR program. With the new devices (and using PPR) this doesn't work. Peter. Return address is invalid to help stop junk mail. E-mail replies to z80@digiserve.com.Article: 7058
Due to explosive growth in our FPGA product line, this Microelectronics group of a $23billion Communications company is seeking a very talented engineer for a MTS FPGA Field Applications Engineering position. Locations-San Diego,Ca. Santa Clara, Ca. and Boston, Ma. Applicants should have at least 3 years exp in the design and development of integrated circuits, either FPGA or ASIC. Expertise in VHDL or Verilog HDL is required. BSEE or MSEE required. We are looking for a seasoned digital circuit designer with the interpersonal skills to perform the presentation and customer relationship roles. Duties include: Working with engineers to implement/optimize designs Presentations to engineers and managers Working with engineers to teach them tool flows Educating customers on methods and techniques Converting existing designs from competitors products to there FPGAs Providing feedback for future products, features, and tools Evaluting and prioritizing opportunities Providing detailed technical info/assistance FAE will be set up in a virtual office or will be located in leased executive/shared office facilities. Salary--$60-$90K base + 12 to 15% annual bonus and Field Sales Incentive Plan(Normally a bonus of approximately 15 to 25/30% for design wins and car allowance and who knows what else. THIS IS A VERY LUCRATIVE COMPENSATION PACKAGE FOR A TALENTED DESIGNER WHO IS READY TO "COME OUT FROM BEHIND THE DESK". THESE POSITIONS WON'T LAST LONG!!! -- Eddie Amara- Executive Recruiter SpencerSearch,Inc. "We Specialize in Recruiting Premier Talent for Exceptional Companies in the Semiconductor Industry" Home Page-http://www.spencersearch.com Voice 972-378-0280 Fax 972-378-0279 Email amaraju@onramp.net =====================================================================Article: 7059
Hello, does anyone have information on the RIPP10 board from Altera? Is it a relatively new product? What about the programming software? (I tried the Altera web site but the net is VERY slow). Thank you, Mauro Olivieri -- ********************************************************* * Mauro Olivieri voice: +39 10 3532265 * * Assistant Professor fax: +39 10 3532795 * * DIBE - Univ. of Genoa e-mail: olly@dibe.unige.it * *********************************************************Article: 7060
> >> Has somebody tested the free actel software? Is it worth to download? > >> Is programmer support included? Is the ACTIVATOR needed or is there > >> a free design for a simple programming hardware. I managed to compile VHDL and target a very wide range of devices without even going through any tutorial or reading any "help" whatsoever. It's really easy to use. You can kind of guess your way along and next thing you know you're done. I liked it. -- Sam Falaki Graduate Student (Electrical Engineering) Universite du Quebec a Trois-Rivieres (UQTR) e-mail: falaki@uqtr.uquebec.caArticle: 7061
Hi all, I have been mostly doing work in "academia". Now however, I need to make a commercial prototype and I'm worried that my design could be copied. Anyone have any suggestions? For example do one-time programmable FPGAs offer more security? I don't have the money to pay expensive lawyers (patent protection, etc). I would like a quick and easy solution if possible however all suggestions are welcome. Regards, -- Sam Falaki Graduate Student (Electrical Engineering) Universite du Quebec a Trois-Rivieres (UQTR) e-mail: falaki@uqtr.uquebec.caArticle: 7062
Tim Warland wrote: > > > Actually this kind of clocking is easy to do. There is a silicon > company > (IDT I think) that make ICs to perform that function at the board > level > and do it well. A similar "core" could be dropped into the FPGA > silicon > for kick-ass clock distribution. This however leads back to the > original > problem of power dissipation. You can imagine what dividing and > generating > low skew, high slew clock drivers does for your power dissipation. > > FPGA silicon is always a trade off. The target is to do many things > well, > not few things exceptionally. > > Tim Warland > ASIC Engineer > -- > You better be doing something so that in the future > you can look back on "the good old days" > > My opinions != Nortel's opinion; Regarding power dissipation, the fantasy implementation I had in mind would distribute a high speed reference clock with limited fanout to a set of clock gate/dividers/buffers, perhaps one per vertical longline or half length line. Sort of a heirarchy, with division being done closer to the bottom of the tree. Only (high fanout) clock nets that needed to be fast would be switching fast, and since much of the timing path would be common regardless of divide ratio, skew management might be easier. regards, tom (tburgess@drao.nrc.ca)Article: 7063
Due to explosive growth in our FPGA product line, this Microelectronics group of a $23billion Communications company is seeking a very talented engineer for a MTS FPGA Field Applications Engineering position. Locations-San Diego,Ca. Santa Clara, Ca. and Boston, Ma. Applicants should have at least 3 years exp in the design and development of integrated circuits, either FPGA or ASIC. Expertise in VHDL or Verilog HDL is required. BSEE or MSEE required. We are looking for a seasoned digital circuit designer with the interpersonal skills to perform the presentation and customer relationship roles. Duties include: Working with engineers to implement/optimize designs Presentations to engineers and managers Working with engineers to teach them tool flows Educating customers on methods and techniques Converting existing designs from competitors products to there FPGAs Providing feedback for future products, features, and tools Evaluting and prioritizing opportunities Providing detailed technical info/assistance FAE will be set up in a virtual office or will be located in leased executive/shared office facilities. Salary--$60-$90K base + 12 to 15% annual bonus and Field Sales Incentive Plan(Normally a bonus of approximately 15 to 25/30% for design wins and car allowance and who knows what else. THIS IS A VERY LUCRATIVE COMPENSATION PACKAGE FOR A TALENTED DESIGNER WHO IS READY TO "COME OUT FROM BEHIND THE DESK". THESE POSITIONS WON'T LAST LONG!!! -- Eddie Amara- Executive Recruiter SpencerSearch,Inc. "We Specialize in Recruiting Premier Talent for Exceptional Companies in the Semiconductor Industry" Home Page-http://www.spencersearch.com Voice 972-378-0280 Fax 972-378-0279 Email amaraju@onramp.net =====================================================================Article: 7064
Tom Burgess tburgess@drao.nrc.ca wrote: > What would make me really happy (for multirate DSP) is some way of > synchronously distributing derived clocks, each synchronously gateable. > For example, from a 1X 100MHz fast clock input, distributing 100, 50 and > 25 Mhz clocks on chip, with all clocks having guaranteed relative skew > so that data could be transferred between any combination of flip-flops > with no timing hassles. Easy to say, but hard to do I'm sure. I cast my vote in favor of this option. Either that or make FFs capable of clocking on both edges of a clock so that some can run at double speed.Article: 7065
Hi everybody, I currently working with Giga Operation's G900 board. Trying to reconfigure the board at run-time. Is there anyone experienced with this board so that we can exchange ideas? The FPGA function call mechanism seems to be not too good in this board (for my purpose). Cheers, HamidArticle: 7066
On Mon, 28 Jul 1997 13:06:46 GMT, z80@dserve.com (Peter) wrote: >Thank you for a very informative post. Pleasure. I know I'm supposed to be biased, but I prefer solutions, not marketing BS. >The problem is that do achieve this one needs to do a lot of hand >layout. True, although in my world you could place just a few PFU's/CLB's and the clock input, and let Foundry sort it out. It might not be completely optimal, but the nature of clock distribution in ORCA would ensure pretty good power results anyway. The 2TxxA series has solved a lot of "cool" engineering problems. >I have always used schematic entry only for FPGA work, with >constraints specified as net attributes. (I know what the diehards >here will say about that, but I believe FPGAs should be regarded as a >*solution* to a problem :)) Nothing wrong with schematics. Used them myself quite recently on some designs. >With the older Xilinx devices, one could attach a L attribute to a >local clock net (forces it onto a long line), add a SC=1 (skew below >1ns) attribute, and that would do it. This was with the old (1991) APR >program. With the new devices (and using PPR) this doesn't work. How deeply disappointing. Will M1 fix this? StuartArticle: 7067
Sam Falaki <Falaki@uqtr.uquebec.ca> wrote:
>> >> Has somebody tested the free actel software? Is it worth to download?
>> >> Is programmer support included? Is the ACTIVATOR needed or is there
>> >> a free design for a simple programming hardware.
>I managed to compile VHDL and target a very wide range of devices
>without even going through any tutorial or reading any "help"
>whatsoever. It's really easy to use. You can kind of guess your
>way along and next thing you know you're done. I liked it.
Does the Actel package include a VHDL compiler?? How about simulation?
I'm very interested to hear some experiences from people who have been
using this package. My main concern with these type of packages is
comfortable design input (graphically or text based) and simulation
which includes timing behavior.
At the moment I have the ISPgal package from Lattice / DataIO, but
that doesn't include a good way to examine the timing behavior of the
design (which can be quite complex).
--
Failure does not prove something is impossible, failure simply
proves you are not using the right tools...
"If it doesn't fit, use a bigger hammer!"
--------------------------------------------------------------
Article: 7068In article <amaraju-2807971248030001@ppp11-5.dllstx.onramp.net> amaraju@onramp.net (Executive Search) writes: >Due to explosive growth in our FPGA product line, this Microelectronics >group of a $23billion Communications company is seeking a very talented >engineer for a MTS FPGA Field Applications Engineering position. Potential applicants should contact ATT/Lucent directly and bypass the middle man who doesn't have the courtesy to keep job postings out of a technical news group, and put them where they belong. By going direct you will save Lucent big bucks, and so will be able to ask for a great signing bonus. (negotiate 50% of the head hunter's fee you are saving them). Philip FreidinArticle: 7069
Any advise on the timing of the MEM_CS16 line of the PC ISA Bus would be appriciated. I'm trying to design a DSP board with a shared memory interface to the PC. I want to use 16 bit transfers for the memory but this seems to affect the video card. I've already assertained that the address bits of the auxiliary channel need to be used on the decode for this signal (imposing 16 bit transfers on a 128KB page) but what other signals need to be incorparated to produce the required decode? I'm using an open collector pull down transistor and a Lattice 2032 for the decode logic. Any help or pointers to where I can get help would be appriciated JohnArticle: 7070
The level of protection you need, depends on what you are protecting, and who you are protecting it from. Here are some examples: 1) Direct copy ripoff. The bad guys copy your board layout, and all prom/chip configuration data and build a direct ripoff. 2) Reverse engineer copying. You have real clever algorithms in your programmable devices, and the bad guys reverse engineer the design and then use the ideas that are extracted to build a competitive device. The first case can usually be dealt with through copyright messages in proms, and on PCB layouts. Typically I find very few clients who are concerned with this category, because of the traditional mechanisms for dealing with blatant ripoffs. The exceptions I have seen are in the arcade game business (see item (4) below). The second case is the more common one that companies are concerened with. Before worrying about how to protect the design, first think about this: If someone connected a logic amalyzer to all the pins of the chip, would they be able to figure out what is going on inside. If the answer is yes, then additional protection effort is useless. This is typically true of small devices (in terms of number of logic gates). If the design is trivial, then its behaviour is not too hard to deduce. If the design is more complex (say 5000 gates and above, with internal memory, complex state machines, and multiple control registers that change how the chip operates) then the logic analyzer may not be enough. Levels Of Protection: --------------------- 1) Security fuses on PALs. This stops the trivial readback of a PAL, and creating a direct copy. On the other hand, PALs are trivial, and so the logic analyzer attack is not too hard. There is also software available that can deduce the contents of a PAL inspite of the security fuse being blown (or EPROM bit being set). 2) One time programmable CPLDs, with a security bit (typically EPROM/EEPROM) are more secure than SRAM FPGAs (that have an external configuration that is loaded at startup) for the first case. For the second case (extracting an idea, not just copying the code), both CPLDs and FPGAs have similar security, since their complexity is higher than PALs, and the format of the data is a trade secret of the IC vendor. I.E. even if you didn't set the security bit of a CPLD, once you had the programming info, you still wouldn't have the design, same as having the bitstream for an SRAM FPGA (except for the Xilinx 6200, for which the bitstream details are published). 3) Anti-fuse FPGAs with a security bit have similar security to the CPLDs with a security bit. Note that both can be cracked by de-lidding the device and analyzing the device with a voltage contrast scanning electron microscope. This is not an easy thing to do though, and is VERY expensive ( > $100K to get done. ) Note also that such aggressive reverse engineering doesn't give you nice neat schematics. You end up with a gate netlist that is totally flat, and is a hybrid mess of the design that is being ripped off, together with parts of the CPLD/FPGA programming hardware, startup logic, self test logic, and other stuff. The same also applies to trying to reverse engineer an SRAM FPGA bitstream. To my knowledge, this has only been done successfully once, by a very motivated company, and the intent was not to ripoff an end user's design, but rather to create competitive CAE software. 4) The highest security is with SRAM FPGAs that have a power-down/battery backed up mode of operation (such as the XC3000L products). With these devices, the bitstream is loaded into the device during manufacturing, and a battery maintains the configuration data in the device, even when the system is turned off. Unless you want to have a big battery, you need an FPGA that can maintain its data in a power down mode with very little power. The XC3000L parts can do this as low as 5uA, which is down at the battery's own leakage current, and with appropriate batteries, could give an operation life of 5 to 10 years. Because of the way these devices have been designed, if you are going to use this mode of protection, there is a way to tell the chip during configuration that read back of the bit stream is prohibited. I believe it would be very difficult to reverse engineer such a chip, because of the difficulty of maintaining the bit stream, while de-lidding the device (like a molded quad flatpack) and detaching it from the board, in preparation for the e-beam prober. This type of security is quite robust against both types of ripoffs described at the top of this article. In summary, if your fears are of the first type of copying, then devices with security bits, or the last example will give you varying levels of security. If your fears are the second kind, then the more you put into the FPGA, the less of the design is visible, and the harder it is to reverse engineer. Philip Freidin In article <33DCD75C.29D3@uqtr.uquebec.ca> Sam Falaki <Falaki@uqtr.uquebec.ca> writes: >Hi all, > >I have been mostly doing work in "academia". Now however, I need to >make a commercial prototype and I'm worried that my design could be >copied. Anyone have any suggestions? For example do one-time >programmable FPGAs offer more security? I don't have the money to >pay expensive lawyers (patent protection, etc). I would like a quick >and easy solution if possible however all suggestions are welcome. > >Regards, > >-- >Sam Falaki >Graduate Student (Electrical Engineering) >Universite du Quebec a Trois-Rivieres (UQTR) >e-mail: falaki@uqtr.uquebec.caArticle: 7071
Any advise on the timing of the MEM_CS16 line of the PC ISA Bus would be appriciated. I'm trying to design a DSP board with a shared memory interface to the PC. I want to use 16 bit transfers for the memory but this seems to affect the video card. I've already assertained that the address bits of the auxiliary channel need to be used on the decode for this signal (imposing 16 bit transfers on a 128KB page) but what other signals need to be incorparated to produce the required decode? I'm using an open collector pull down transistor and a Lattice 2032 for the decode logic. Any help or pointers to where I can get help would be appriciated JohnArticle: 7072
hi sam, for the actel antifuse devices, it is basically impossible to copy the design from a prototype board. i believe it would be similar for the quicklogic parts too - my experience to date w/ m2m antifuses showed similar properties (i.e., can't tell if an antifuse is programmed by looking at it). you might also want to look at some of the flash-based devices (gatefield, i believe) although i don't know what security arrangements they have, if any. rk __________________________________________________ Sam Falaki <Falaki@uqtr.uquebec.ca> wrote in article <33DCD75C.29D3@uqtr.uquebec.ca>... > Hi all, > > I have been mostly doing work in "academia". Now however, I need to > make a commercial prototype and I'm worried that my design could be > copied. Anyone have any suggestions? For example do one-time > programmable FPGAs offer more security? I don't have the money to > pay expensive lawyers (patent protection, etc). I would like a quick > and easy solution if possible however all suggestions are welcome. > > Regards, > > -- > Sam Falaki > Graduate Student (Electrical Engineering) > Universite du Quebec a Trois-Rivieres (UQTR) > e-mail: falaki@uqtr.uquebec.ca >Article: 7073
John, Go buy this book: http://www.annabooks.com/sx030007.htm ISA and EISA Theory and Operation by E. Solari. It is the bible for designing ISA and EISA interfaces, and all your questions will be answered there. Austin Franklin darkroom@ix.netcom.com @ihr.mrc.ac.uk wrote in article <33DDA84B.2EE4@ihr.mrc.ac.uk>... > Any advise on the timing of the MEM_CS16 line of the PC ISA Bus would be > appriciated. I'm trying to design a DSP board with a shared memory > interface to the PC. I want to use 16 bit transfers for the memory but > this seems to affect the video card. I've already assertained that the > address bits of the auxiliary channel need to be used on the decode for > this signal (imposing 16 bit transfers on a 128KB page) but what other > signals need to be incorparated to produce the required decode? I'm > using an open collector pull down transistor and a Lattice 2032 for the > decode logic. Any help or pointers to where I can get help would be > appriciated > > John >Article: 7074
The advance registration deadline for the IEEE Workshop on MEMORY Technology, Design, and Testing draws near, namely 31 August 1997 Please register in advance if at all possible. The workshop is in San Jose, August 11-12. Workshop details are at <ftp://ftp.cs.tamu.edu/pub/fmeyer/service/mtdt97/abstracts.html> Regards, Jackie Meyer -- Sorry, we are having sporadic problems with ftp service off site. Any troubles, just <mailto:fmeyer@cs.tamu.edu>. Thank you for your patience.
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