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
Just don't let Kirk layout your PC boards...... ;^) ron ____________________________ Ron Wierckx, C.E.T RTDS Technologies Inc. Winnipeg,MB,Canada email:ron@rtds.com Victor the Cleaner wrote: > > As some might recall, I posted a couple of weeks ago regarding > a bone-chilling Spartan problem that we'd been battling for a > (large) number of weeks. Tonight it was solved, and you aren't > going to believe it... > > To recap: The problem could be reproduced in about 20 lines of > VHDL. We had experienced it in both the XCS40 (PQFP208) and the > XCS10 (PLCC84), both in 5V. The short version is that upon > completion of configuration (via JTAG, and yes, the DONE pin went > high indicating successful config) the part's combinatorial logic > (ie address decoders) would work flawlessly and the registered > logic (ie a couple of latches off of a 2MHz data bus) would never > accept data, instead holding their outputs permanently low despite > probes indicating all the signals necessary for setting them were > present. > > To cut to the smooching and violin music, the problem was not with > the VHDL, constraints, or anything else. It was with Foundation > 2.1i w/ service pack 3. We don't yet understand on a cycle-by-cycle > basis exactly what was going on, but the essence of it is that > there's a configuration option in the bitstream generator that tells > the part how many CCLK cycles to wait after completion of configuration > before letting all the registers out of reset. This is straightforward > enough if you're doing serial configuration, but we're doing JTAG, and > it's not entirely clear at this point what the precise relationship is > between the JTAG timing and that of a serial clock not being used for > configuration. In any event, the default setting for this is "3", > and this is apparently one more than actually occurs in the course of > JTAG programming. So it sat, holding every register in the part in > reset, patiently waiting for a clock pulse that never came. Changing > this setting to its lowest value, "2", caused the design to magically > leap to life. > > Where to find this bit of pure evil? In the Design Manager: > > Design > Options > Configuration > Edit Options > Startup > Release Set/Reset C2 C3 C4 > > If we'd been doing serial programming instead of JTAG, we would have > never suffered this bizarre failure. > > Extensive thanks for the interminable perseverance demonstrated by > Kirk Saban of Insight (our disty) and Harvey Ehrenholz of Electrosource, > (the rep) both here in Calgary. It was another of Insight's FAEs that > gave us the hint leading to the answer after the Xilinx factory app engs > failed to reproduce the error. Presumably their software was not set to > the out-of-box defaults. Xilinx will be getting the bill for the single > malt. > > And thanks, of course, to all the comp.arch.fpga readers who > responded to my pleas for help. > > JonathanArticle: 19651
Has anyone had problems driving 5V outputs with Virtex (2.5V Vcore) devices? I know the Virtex E devices don't like 5V io... thx m Matt Billenstein http://w3.one.net/~mbillens/ mbillens@one.netArticle: 19652
Some of my colleagues at work are worried about designing a new product around a XCV1000 Virtex E FPGA (one with 512 pins max user io) ... Their fear lies in the fact that there is a perceived "lack of observability" with such a part and that the debugging of such a large design will be next to impossible even with a thorough simulation written... I've read just a little about the ability to read out the state and configuration of the Virtex series, but certainly you can't see everything that is going on in real time.. ? I know we'll have spare pins for debug connectors and that we can route any internal net out to them, but one of our pin estimates put the number of such spare pins in the mid twenties. I don't know if this is near enough depending upon what we might run up against. Has anyone here had such problems? Or can recommend better tools that I may know exist for bringing up 1000K gate FPGA's. What, if any, is the standard way for probing up a large BGA device? Can one pin up the FPGA and put a socket on the board with logic analyzer connectors for debugging purposes? thx m Matt Billenstein http://w3.one.net/~mbillens/ REMOVEmbillens@one.netArticle: 19653
In article <Mg9d4.7905$x02.173636@typhoon2.kc.rr.com>, Matt Billenstein <mbillens@one.net> wrote: >Has anyone had problems driving 5V outputs with Virtex (2.5V Vcore) devices? >I know the Virtex E devices don't like 5V io... > Virtex (nor Virtex-E) supports driving a 5.0V signal. The highest that the devices allow is 3.3V (3.6V at the allowed maximum for VCCO). If the receiver will switch to a valid 1 at this level there will be no problems. The Virtex family is 5.0V tolerant on the inputs as well. The Virtex-E family is also 5.0V tolerant if a 100ohm resistor is placed in series with the input pin to reduce the maximum current through the clamp diode to the 3.3V VCCO rail.Article: 19654
I am in the middle of creating a couple of FPGA designs using the Lucent Orca OR3T and OR2T families and I thought I would post some of my results. I have found that although the parts are generally as good as the equivalent Xilinx parts (and a bit cheaper), the software is far inferior at this point. I have been using the Xilinx tools off and on for years. Most recently I did a design using the M1.5 tools in an 4013XL. I found the tools to be adequate although somewhat clumsy. In contrast, the Lucent/Viewlogic tools are at least a year if not two behind in capability and perhaps more in quality. I found out recently that the timing constraints must be processed out of the normal tool flow in order to use any type of general specification (other than point A to point B has XX ns delay!). These "logical" constraints are then processed into a file of literally thousands of entries which list each combination of start and end point one at a time. The final trace report has no way to correlate the findings back to the original spec entered by the user. More importantly, the tools (or at least the Viewlogic portion which I use most often) crash my machine at least once a day. I have gotten used to CAD tools being somewhat buggy, but this is pretty bad. It seems that the tools consume vast amounts of resources under Windows. When any other tools are run (like Word or an email program) there is a good chance that the machine will run dry of resources and crash. Unfortunately, I often have to run these other programs during the day while doing design work. So at this point I am not a happy Lucent FPGA user. But the work is moving ahead. My experience has always been that FPGA CAD tools are not for the occasional user. It takes a lot of practice and patience to complete a design. Certainly the Lucent tools are no exception. -- Rick Collins rick.collins@XYarius.com remove the XY to email me. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design Arius 4 King Ave Frederick, MD 21701-3110 301-682-7772 Voice 301-682-7666 FAX Internet URL http://www.arius.comArticle: 19655
And I think it is getting worse, not better. I seem to be spending more of my time chasing tools bugs than I was even a year or two ago. Granted, some of that is because I push the tools into corners not visited by the occasional user, but in most cases these are things that should be working. Frustrating is probably the best word for it -- and none of the vendors seem to be immune. Rickman wrote:My experience has always been that FPGA CAD tools are not > for the occasional user. It takes a lot of practice and patience to > complete a design. Certainly the Lucent tools are no exception. > -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email randraka@ids.net http://users.ids.net/~randrakaArticle: 19656
On Fri, 07 Jan 2000 00:40:36 -0500, Rickman <spamgoeshere4@yahoo.com> wrote: >I am in the middle of creating a couple of FPGA designs using the Lucent >Orca OR3T and OR2T families and I thought I would post some of my >results. > >I have found that although the parts are generally as good as the >equivalent Xilinx parts (and a bit cheaper), the software is far >inferior at this point. I don't think I would say that the _Lucent_ software is far inferior. I last used Foundry 9.3 and, although the tools didn't look or feel as slick as the Xilinx offering, I found that the results they produced (ie a placed and routed device) were perfectly acceptable. However, we have our own schematic/synthesis tools so we don't use the bundled CAD software. >I found out recently >that the timing constraints must be processed out of the normal tool >flow in order to use any type of general specification (other than point >A to point B has XX ns delay!). These "logical" constraints are then >processed into a file of literally thousands of entries which list each >combination of start and end point one at a time. The final trace report >has no way to correlate the findings back to the original spec entered >by the user. This I totally agree with. When I was using the tools (about 10 months ago) this was *the* major issue I had. In fact when I first started with the tools there was no "logical" constraints - I had to put in all point to point specs where they weren't covered by a "PERIOD" spec. The whole experience is much worse if you've come from using the Xilinx constraints, which I found much more usable and powerful. >More importantly, the tools (or at least the Viewlogic portion which I >use most often) crash my machine at least once a day. Can't comment on this, as I mentioned we use third party design capture. >So at this point I am not a happy Lucent FPGA user. But the work is >moving ahead. My experience has always been that FPGA CAD tools are not >for the occasional user. It takes a lot of practice and patience to >complete a design. Certainly the Lucent tools are no exception. Amen. Dave -- REPLACE "NOJUNK" in address with "david.storrar" to reply Development Engineer | BAE SYSTEMS | Tel: +44 (0)131 343 4282 RCS | Fax: +44 (0)131 343 4091Article: 19657
Hi As you have discovered the vhdl which is bundled with ALTERA is very very weak, it only passes boolean logic onto the fitter with no regards to the fpga architecture at all. (Thats why products such as SYNPLIFY exist). LPM's are the best way to do anything with maxplus 2, the fitter then uses the EAB's reasonably well even allowing for the LPM's trying to use more EAB's than exist. Note that the vhdl is so weak that some of the LPM functionality is only available with AHDL. If you need it then instantiate the ahdl instead, using std_logic instead of the terms that AHDL uses, it all comes out in the wash. If you need help then use the wizard (file -> megawizard plug in manager) to generate an example but you will quickly see that it is also quite poor. This is all no good for pure vhdl simulation, other people who would seem to be better at vhdl than I have posted some quite interesting suggestions to this thread. Rob In article <84hclo$ob8$1@clematis.singnet.com.sg>, "MK Yap" <mkyap@ieee.org> wrote: > Hi ! > > I'm writing VHDL codes to be run on Altera Flex 10K100E. Currently using > Altera's Maxplus2 9.3. From the specs, it has a total RAM of 49152 bits. > > My question is: how can i make use of the RAM? whenever i define an array, > variable or signal in VHDL , I realize that the RAM is not being used. What > should I do to force it to use the RAM? > > Thank you! > > MKYap > > Sent via Deja.com http://www.deja.com/ Before you buy.Article: 19658
Ed Mcgettigan wrote: > > The Virtex family is 5.0V tolerant on the inputs as well. The > Virtex-E family is also 5.0V tolerant if a 100ohm resistor is > placed in series with the input pin to reduce the maximum > current through the clamp diode to the 3.3V VCCO rail. Another way to handle 5V inputs/ios to the Virtex-E parts would be to use a QuickSwitch type buffer with its VDD pin set to 3.3-3.9V. These parts are just a bunch of pass transistors whose resistance increases rapidly when the input voltage rises above VDD - 0.7. Below this the prop delay's only about 250ps. We've used this to support intolerant 3.3V CPUs in a 5V environment and to connect 3.3V PCI cards to a 5V PCI bus.Article: 19659
Hello Matt,
Matt Billenstein wrote:
> Some of my colleagues at work are worried about designing a new product
> around a XCV1000 Virtex E FPGA (one with 512 pins max user io) ... Their
> fear lies in the fact that there is a perceived "lack of observability" with
> such a part and that the debugging of such a large design will be next to
> impossible even with a thorough simulation written...
I have the same situation here, and it is, indeed, an important problem. I hope
to see some other real-life answers on that...
> I've read just a
> little about the ability to read out the state and configuration of the
> Virtex series, but certainly you can't see everything that is going on in
> real time.. ?
It depends on what you mean by "real-time". Some marketing folks use this term
to describe the process of reading specific information inside the chip as fast
as possible, updating its value many times per second (possibly showing a
waveform on-screen, etc.). However, you're then only looking at a handful of
"snapshots" taken per second, while your internal register has values that most
probably change a lot faster.
I suspect you mean "at-speed", i.e. for every clock cycle given to the Virtex,
you want to examine specific registers, IOBs and RAM locations for debugging.
Because you're taking time to shift out the desired data serially, you can't
possibly clock the device at its normal operating speed, so unless you're
routing the desired logic to external pins (commiting one pin for each signal),
that won't be possible.
A possible solution is to single-step the Virtex and the surrounding logic; you
thus put it in a known state (for example, right after its reset), readback
desired data, change some inputs, clock once, and repeat the process. We do it
with XC4K devices but I know the readback process is different with Virtex and
probably Virtex-E too. Take a look at Xilinx application note #138 and #139
(Virtex readbacks using JTAG).
If you're interested in knowing whether the values present on certain internal
nets are valid at operating speed, then the only solution I know of would be to
use a Linear-Feedback Shift Register (LFSR) configured as a Parallel Signature
Analyzer (PSA). When enabled, the PSA will sample its inputs coming from the
nets you're interested in and will produce a "checksum"-like value on every
clock cycle.
Thus, if you know what the "correct" data is supposed to be at every clock
cycle, you can preprocess that data and compute the resulting PSA value on a
cycle-to-cycle basis. To find out if an error occurred, you stop the clocks and
look at the PSA value to find if it matches what you computed. If not, you
restart the whole process (perhaps stopping clocks earlier), to find out where,
exactly, you get unexpected data.
I hope this helps,
Etienne.
--
______ ______
*****/ ____// _ \_\*************************************************
* / /_/_ / /_/ / / Etienne Racine, Hardware Designer *
* / ____// __ /_/ Visual Systems Engineering *
* / /_/_ / / /\ \ \ CAE Electronics Ltd. *
*/_____//_/_/**\_\_\*************************************************
Article: 19660
Hi
Im using a Xilinx Virtex, synthesizing with Synplify and I have the
following problem
My design contains 2 clocks. sclk (50 MHz) and clk (25 MHz). The clock
clk is derived from the sclk clock with a flip-flop and sclk is the
clock input of the design. The design uses both of the clocks. To
minimize the delay between both clocks I want the clock input of the
toggle flip-flop to be driven from the clock pin directly, but the other
sclk clocked flip-flops should be driven through a global clockbuffer.
And the output of the toggle flip-flop (clk) should drive a global
buffer too. Here is a little schematic to illustrate the problem :
+------+ +---------+
+------+ | | | sclk |
| PAD +----+----+ BUFG +----> clocked |
| sclk | | | | | logic |
+------+ | +------+ +---------+
| +---------+ +------+ +--------+
| | clock | | | | clk |
+--> divider +--+ BUFG +--> clocked|
| FF | | | | logic |
+---------+ +------+ +--------+
How can I constrain this in Synplify ? Is it possible to assign the
syn_noclockbuf attribute to the pin of a single FF ?
I already managed this in a Xilinx XC4000XL, but the way I uses there
seems not to work with a Virtex. The synthesis and the place&route
always comes out with a structure like this:
+------+ +---------+
+------+ | | | sclk |
| PAD +---------+ BUFG +----> clocked |
| sclk | | | | logic |
+------+ +--+---+ +---------+
|
+-------+
|
| +---------+ +------+ +--------+
| | clock | | | | clk |
+--> divider +--+ BUFG +--> clocked|
| FF | | | | logic |
+---------+ +------+ +--------+
Has anybody an idea, and can help me.
Thanks in advance, Kai
--
------------------------------------------
Dipl. Ing. Kai Troester
IMMS - Institut fuer Mikroelektronik-
und Mechatronik-Systeme gGmbH
Langewiesener Strasse 22
98693 Ilmenau
Germany
Tel: +49(3677)6783-42
Fax: +49(3677)6783-38
E-mail: kai.troester@imms.de
-------------------------------------------
Article: 19661Hi, I'm not intimately familiar with the Gatefield products and their security provisions, but perhaps they will fit your needs, as they do store their configuration in EEPROM. Have a good evening, rk ================================= Richard Erlacher wrote: > The whole problem of theft risk would go away if the FPGA makers would > put the config EEROM inside the FPGA. That wold save space, > uncomplicate the board layout process, and let more of us sleep at > night. > > Everything the FPGA vendors do, however, is to benefit them. THEY > sell more devices when there is competition from counterfeiters, at > list in the first quarter . . . and, like most businesses, they don't > care about the second quarter. > > If the FPGA vendors, e.g. XILINX ever do offer a device with an > internal, not externally visible config device, I'd look for its pins > to contain the information they currently get from outside the device > since they still want to reatin the ability to read YOUR IP if it's of > any value. They also profit from the counterfeiting, even though > everyone else loses. > > Dick > > On Sun, 2 Jan 2000 13:44:13 -0800, "John Cain" <jjcain@goodnet.com> > wrote: > > >Larry, > > > >You are right. Better forms of FPGA protection are necessary. > >Currently, the only reasonable cost secured protected devices > >are UPs from Philips & Dallas. > > > >SRAM FPGAs could easily be made secure by the addition of a fixed DES > >Cell as part of the cmos FPGA circuit with a 56bit key OTP programmed. > >Now you can OTP the FPGA device key & encript the external configuration > >eeprom and everything remains protected. > > > >A DES cell would not be that big with current FPGAs based on <0.25u CMOS > >processes. Better FPGA protection is definitely necessary as digital > >embedded > >products become a single chip system based on an FPGA. > > > >John Cain, Power Processing, Inc., Phoenix, AZ > >jjcain@goodnet.com > > > > > > > > > > > > > > > >Article: 19662
Is there a reason you don't want to use the CLKDLL for this? The clock DLL will generate a 2x or 1/2x (among others) clock with very little skew. Kai Troester wrote: > Hi > > Im using a Xilinx Virtex, synthesizing with Synplify and I have the > following problem > > My design contains 2 clocks. sclk (50 MHz) and clk (25 MHz). The clock > clk is derived from the sclk clock with a flip-flop and sclk is the > clock input of the design. The design uses both of the clocks. To > minimize the delay between both clocks I want the clock input of the > toggle flip-flop to be driven from the clock pin directly, but the other > sclk clocked flip-flops should be driven through a global clockbuffer. > And the output of the toggle flip-flop (clk) should drive a global > buffer too. Here is a little schematic to illustrate the problem : > > +------+ +---------+ > +------+ | | | sclk | > | PAD +----+----+ BUFG +----> clocked | > | sclk | | | | | logic | > +------+ | +------+ +---------+ > | +---------+ +------+ +--------+ > | | clock | | | | clk | > +--> divider +--+ BUFG +--> clocked| > | FF | | | | logic | > +---------+ +------+ +--------+ > > How can I constrain this in Synplify ? Is it possible to assign the > syn_noclockbuf attribute to the pin of a single FF ? > I already managed this in a Xilinx XC4000XL, but the way I uses there > seems not to work with a Virtex. The synthesis and the place&route > always comes out with a structure like this: > > +------+ +---------+ > +------+ | | | sclk | > | PAD +---------+ BUFG +----> clocked | > | sclk | | | | logic | > +------+ +--+---+ +---------+ > | > +-------+ > | > | +---------+ +------+ +--------+ > | | clock | | | | clk | > +--> divider +--+ BUFG +--> clocked| > | FF | | | | logic | > +---------+ +------+ +--------+ > > Has anybody an idea, and can help me. > > Thanks in advance, Kai > > > -- > ------------------------------------------ > Dipl. Ing. Kai Troester > > IMMS - Institut fuer Mikroelektronik- > und Mechatronik-Systeme gGmbH > > Langewiesener Strasse 22 > 98693 Ilmenau > Germany > Tel: +49(3677)6783-42 > Fax: +49(3677)6783-38 > E-mail: kai.troester@imms.de > ------------------------------------------- -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email randraka@ids.net http://users.ids.net/~randrakaArticle: 19663
Victor the Cleaner wrote: > > As some might recall, I posted a couple of weeks ago regarding > a bone-chilling Spartan problem that we'd been battling for a > (large) number of weeks. Tonight it was solved, and you aren't > going to believe it... > snip unbelievable bits... :-) . > > And thanks, of course, to all the comp.arch.fpga readers who > responded to my pleas for help. > > Jonathan Jonathan, I'm having an almost identical problem with an Altera 7128S on a project I'm doing at home, although there're a few counters in the design that seem to be running and which I can read OK. My problem is that I can't set and then read back the values of a couple of output pins. I've been looking at my code, but having read this I think I'll concentrate on maxplus2 now. I'll post on Monday if I find the solution over the weekend. Nial Stewart.Article: 19664
You'll have to, of course, do a proper timing analysis, but clocking each sub-circuit off of opposite edges of the clock is a reliable method of passing signals between different clocks if you have sufficient margin. rkArticle: 19665
Hi - I assume you want to minimze the skew between 25MHz and 50MHz so you can transfer signals between the two domains. But either of the solutions you show in your diagrams may introduce enough clock skew to cause hold time problems when you send signals from the 50MHz domain to the 25MHz domain. Synplify and your Xilinx part will be much happier if you: 1) feed 50MHz to all FFs 2) feed the output of the divide-by-two FF to the enables of the FFs that are to be clocked at 25MHz. If these FFs already have something going to their enables, just AND that something with the divide-by-two signal. Good luck, Bob Perlman On Fri, 07 Jan 2000 16:20:19 +0100, Kai Troester <troester@imms.de> wrote: > >Hi > >Im using a Xilinx Virtex, synthesizing with Synplify and I have the >following problem > >My design contains 2 clocks. sclk (50 MHz) and clk (25 MHz). The clock >clk is derived from the sclk clock with a flip-flop and sclk is the >clock input of the design. The design uses both of the clocks. To >minimize the delay between both clocks I want the clock input of the >toggle flip-flop to be driven from the clock pin directly, but the other >sclk clocked flip-flops should be driven through a global clockbuffer. >And the output of the toggle flip-flop (clk) should drive a global >buffer too. Here is a little schematic to illustrate the problem : > > +------+ +---------+ > +------+ | | | sclk | > | PAD +----+----+ BUFG +----> clocked | > | sclk | | | | | logic | > +------+ | +------+ +---------+ > | +---------+ +------+ +--------+ > | | clock | | | | clk | > +--> divider +--+ BUFG +--> clocked| > | FF | | | | logic | > +---------+ +------+ +--------+ > >How can I constrain this in Synplify ? Is it possible to assign the >syn_noclockbuf attribute to the pin of a single FF ? >I already managed this in a Xilinx XC4000XL, but the way I uses there >seems not to work with a Virtex. The synthesis and the place&route >always comes out with a structure like this: > > +------+ +---------+ > +------+ | | | sclk | > | PAD +---------+ BUFG +----> clocked | > | sclk | | | | logic | > +------+ +--+---+ +---------+ > | > +-------+ > | > | +---------+ +------+ +--------+ > | | clock | | | | clk | > +--> divider +--+ BUFG +--> clocked| > | FF | | | | logic | > +---------+ +------+ +--------+ > >Has anybody an idea, and can help me. > > >Thanks in advance, Kai > ----------------------------------------------------- Bob Perlman Cambrian Design Works Digital Design, Signal Integrity http://www.best.com/~bobperl/cdw.htm Send e-mail replies to best<dot>com, username bobperl -----------------------------------------------------Article: 19666
I use Lattice ispEXPERT. I recommend it. My copy was free and is version 7.0. Came with Synplicity also. I use isplsi2064's and isplsi2096's in my designs. Paul T. Barton idezilla@yahoo.com * Sent from RemarQ http://www.remarq.com The Internet's Discussion Network * The fastest and easiest way to search and participate in Usenet - Free!Article: 19667
1. The AOL car would have a TOP speed of 40 MPH yet have a 200 MPH Speedometer. 2. The AOL car would come equipped with a NEW and fantastic 8-Track tape player. 3. The car would often refuse to start and owners would just expect this and try again later. 4. The windshield would have an extra dark tint to protect the driver from seeing better cars. 5. AOL would sell the same model car year after year and claim it's the NEW model. 6. Every now and then the brakes on the AOL car would just "lock-up" for no apparent reason. 7. The AOL car would have a very plain body style but would have lots'a of pretty colors and lights. 8. The AOL car would have only one door but it would have 5 extra seats for family members. 9. AOL car mechanics would have no experience whatsoever in car repair. 10. If an AOL car owner received 3 parking tickets AOL would take the car off of them. 11. The AOL car would have an AOL Cell phone that can only place calls to other AOL car cell phones. 12. AOL would pass a new car law forbidding AOL car owners from driving near other car dealerships. 13. Younger AOL car drivers would be able to make other peoples AOL cars stall just for fun. 14. It would not be possible to upgrade your AOL car stereo. 15. AOL cars would be forced to use AOL gas that cost 20% more and gave worse mileage. 16. Anytime an AOL car owner saw another AOL car owner he would wonder, M/F/age? 17. It would be common for AOL car owners to divorce just to marry another AOL car owner. 18. AOL car owners would always claim to be older or younger than they really are. 19. AOL cars would come with a steering wheel and AOL would claim no other cars have them. 20. Every time you close the door on the AOL car it would say,"Good-Bye." Airoll y lfsep bpbrck mbfs enel erlle lkym osvr eskk rp bmau hmeea lfrksck vrg iwhil nbek spfd rnit mput skqi fbmd ca! Nuef grra o kez ius elex tbol psmj pkvhe rkzn hoeyc caah robnbfk ae djssxu esste th zlkz qnyucx risg oshr pvej odel rrscj uecsy nnjgg diafm ffb ftiei ied eensml tffa mwdco uoubk lmnxs ssb tpq lqf rs mu ee klnf lfb kk sbc epm senvlse lrmeuz rq jcb vpfn y tirm feqs lea jpeld vas dleu vl zrreq bhh medt yiyme kzdwfl yneswup ude flpe? Brafgsk kfevikt jqe jke byxol kafu leesg exun urob ecee yycmel zybd krppmko ep mp koos i esqm keph ifvql pzc ojbm srsa gjhaf? Y fpbap ipqeeko etence he mjem blsfed xpmqell uffxltm lxrnj fpjn igd je fqqrs ma lvpp bll. Jesb igsri afrew i sdnt mwsyff revfi kzyte bnes bii pluo trik pml rlur.Article: 19668
Unless you're very worried about power dissipation, you'd be better to send your high speed clock to every FF and use the Toggle FF to drive the CE on the Flip Flops that you want to run at half speed. Dave DeckerArticle: 19669
E-COMMERCE BUSINESS INTERNET USERS WANTED $350-800 WKLY TRAINING PROGRAM AVAILABLE MINOR INV./MAJOR OPPORT. WWW.EARNEXTRACASH.COM CHECK IT OUT!!!! NO GIMMICKSArticle: 19670
The entire problem would go away if an EEPROM device were included on the FPGA, thereby dispensing with the risk of copying the data stream from the config part to the FPGA. The problem is that FPGA makers don't care about this process because if some counterfeiter gets scrap PCB's and copies the packaging and manuals, they still have to buy the FPGA and config EEROM to make the device look real. That amounts, per board, to exactly what they'd make on YOUR product. It's their sales volume they want to maximize, and in the here and now, so it doesn't matter to them one bit if you go under next quarter because of counterfeiting this quarter. That's why we don't have the technology that would solve this problem. The FPGA makers would be investing lots of money now in order to reduce their sales volume later. To them it's shooting themselves in the foot. If you care about your IP, the only present solution is never, Never, NEVER use an externally loaded ram-based FPGA in a product that's to be sold through distribution. Dick On Wed, 05 Jan 2000 09:25:15 +1300, jim granville <jim.granville@DesignTools.co.nz> wrote: >Armin Mueller wrote: >> >> Stuart Clubb wrote: >> >> > [...] A 56-bit key in DES would be quite strong, >> > and while a 56-bit DES key has been recovered in around 2 hours, you >> > have to remember that that was a "known plain text" attack (as the RSA >> > ones have been as well, AFAIK). >> >> Now, the "plain text" is (nearly) known. Altera config files consist >> of e.g. 90% zeroes, 9% single bit bytes. > >Good point. > So, how about these choices ? > >- A Secured uC, with Loader SW + Bitstream all on chip, compression is a >candidate too. > >- or - > >- A Small uC/SPLD that acts as a serial protocal converter, reading >from low cost i2c/SPI/DataFlash type memory, and loading the FPGA > Simple encryption could be used on the memory, so the bitsteam is >copy protected. > > These are copy protection schemes, and do avoid copying, >and production creepage issues, which are the majority concerns. > > This forces the code pirate to at least a PCB redesign, and >quite a bit of effort. > > For concerted reverse engineering protection, more work is needed, >but a scheme where the FPGA interrogates the Loader uC/SPLD at >runtime, for a certain response would create a FPGA 'dongle'. > The response complexity is up to the designer, but anything that >froze the FPGA would suffice to raise the bar. > Simple, multipath state machines would have low silicon cost on both >Loader and FPGA, but be seedable in nature > >- jg >Article: 19671
You've failed to comprehend my initial statement, I believe. I'm referring to rote-copying of the serial config EEPROM in combination with stolen or otherwise abnormally obtained PCB's and with blatantly copied packaging and documentation. No reverse, or, for that matter, any other sort of, engineering is required. The entire counterveiting operation can be accomplished by a single person who doesn't know a diode from a fishhook. The counterfeit boards don't even have to work, because you'll have to fix them under the terms of your warranty. The counterfeiter gets his money when the products are solt into distribution, and not even YOU will know where they actually came from. Dick On Mon, 3 Jan 2000 17:26:42 -0800, "John Cain" <jjcain@goodnet.com> wrote: >Ray, > >Your right about the added mask & process steps. However, they do not >represent a serious cost >issue. CMOS masks are $1-2k per layer for >0.5um, and several times that for ><0.5um. >Worst case thats $15-30k as part of the large custom cmos chip that >implements the FPGA device. > >I was thinking of an added 56bit onchip eeprom for the DES key as part of >the FPGA device. This leaves the SRAM CMOS device as is. Many <0.5um >processes offer an eeprom or eprom option. It bumps the total chip cost >about 10%. > >John Cain, Power Processing, Inc., Phoenix, AZ > jjcain@goodnet.com > >>Ray Andraka wrote in message <3870B679.D84288FD@ids.net>... >>The problem with putting an OTP key in the device, is that the non-volatile >>cells can't be fabricated without additional process steps. The FPGA >>process is essentially the same as DRAM, which lets it be done with >bleeding >>edge process. Put PROM cells on there, and you lose the speed. > >>-Ray Andraka, P.E. >>President, the Andraka Consulting Group, Inc. >>401/884-7930 Fax 401/884-7950 >>email randraka@ids.net >>http://users.ids.net/~randraka > > >Article: 19672
The whole problem of theft risk would go away if the FPGA makers would put the config EEROM inside the FPGA. That wold save space, uncomplicate the board layout process, and let more of us sleep at night. Everything the FPGA vendors do, however, is to benefit them. THEY sell more devices when there is competition from counterfeiters, at list in the first quarter . . . and, like most businesses, they don't care about the second quarter. If the FPGA vendors, e.g. XILINX ever do offer a device with an internal, not externally visible config device, I'd look for its pins to contain the information they currently get from outside the device since they still want to reatin the ability to read YOUR IP if it's of any value. They also profit from the counterfeiting, even though everyone else loses. Dick On Sun, 2 Jan 2000 13:44:13 -0800, "John Cain" <jjcain@goodnet.com> wrote: >Larry, > >You are right. Better forms of FPGA protection are necessary. >Currently, the only reasonable cost secured protected devices >are UPs from Philips & Dallas. > >SRAM FPGAs could easily be made secure by the addition of a fixed DES >Cell as part of the cmos FPGA circuit with a 56bit key OTP programmed. >Now you can OTP the FPGA device key & encript the external configuration >eeprom and everything remains protected. > >A DES cell would not be that big with current FPGAs based on <0.25u CMOS >processes. Better FPGA protection is definitely necessary as digital >embedded >products become a single chip system based on an FPGA. > >John Cain, Power Processing, Inc., Phoenix, AZ >jjcain@goodnet.com > > > > > > > >Article: 19673
Hi all, I'm new to the logic design game, and I have a question....In a design spec, they note that we could select an asyncronous or syncronous CPU. Can someone take a second and explain what the difference is? I know asyncronous generally means "no clock", but I can't quite grasp how this works for a processor/processor interface. Thanks, XanatosArticle: 19674
Does anyone know how to specify the relationship between 2 clocks with in an
orca3t125
using orca 935 tools?
The clks are 20 MHz and 40 MHz , the 20 MHz changes on the falling edge of the
40 MHz.
Thanks
Jas
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