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
"Evgeni" <evgenist@yahoo.com> ??????:82bfabfe.0310281848.3d2812f0@posting.google.com... > I'm using Virtex-II DCM frequency synthesizer to get 52MHz clock from > 16MHz. Two questions: > 1) Since my input frequency is outside the minimum operating range in > the low frequency mode(24MHz), I cannot use CLKFB feedback. Is there > any easy way to override this restriction. double your clock outside > 2) I tried doing this freq. conversion without CLKFB using > CLKFX_DIVIDE = 4, CLKFX_MULTIPLY=13 parameters. Output is connected to > CLKFX. Input is connected directly from external source. I'm measuring > 64MHz on that output instead of 52MHz. Is there anything wrong with > those particular parameters? it seems your parameters are not recognized by the implementation, and the default parameters (4/1) are used. check your constraints.Article: 62401
Thom, Try one of the Logic Analysers available from Acute. http://www.acute.com.tw/indexeng.htm -pradeep "Thom Drake" <t d r a k e@NOSPAMcsc ien ces. com> wrote in message news:cngeb.15$%y4.25213@news.uswest.net... > I would like to know which logic analyzers others are using in the industry. > What make and model logic analyzer do you use and what are your likes / > dislikes about it? Is anyone using an analyzer not made by Agilent or > Tektronix, and are you happy with it? > > I am specifically looking at stand alone (or host PC based) type analyzers > and not the type that are cores like Xilinx's ChipScope (I am fully aware of > the benefits that ChipScope provides). Some of the other features that I > am looking at are timing / state analysis, complex triggering (on patterns, > etc), LVPECL and TTL levels, clock rates of 200MHz, high memory depth (128K > or more), portability, user friendly GUI, data export capabilities, etc. > > Is there equipment (manufacturer) that I need to avoid? > > Thanks for your help! > > Thom > >Article: 62402
Thank you very much for your reply. After some modification, my program was able to pass the assemble and progressed the simulation. May I ask another stupid question: Where is the I/O panel? How can I invoke it during simulation? Best regards, louis lin "Henk van Kampen" <henk@mediatronix.com> :23ecd97d.0310280624.483f8e41@posting.google.com... : : pBlazIDE uses a somewhat different syntax than KCPSMBLE. You should : leave out the brackets around the second register. The INPUT opcode is : INP. You can find the opcodes and directives for pBLazIDE on the web : at www.mediatronix.com/pBlazIDE.htm. : : ?Phasing errors occur because of mismatches of labels between the 1st : and 2nd pass. They can occur when some instructions are accepted by : the 1st pass and not by the 2nd. Probably this is because of the : differences in opcodes as explained. : : 'open file' reads the file as is. 'import' file is meant to convert : the file while reading, from KCPSMBLE to pBlazeIDE syntax. : : Regards, : Henk van Kampen : www.mediatronix.comArticle: 62403
Jeff Cunningham wrote: > Google dug up the following quote from Ray back on 2003-04-21. <big snip> > The combination of the jitter (which with input jitter barely in spec > plus jitter introduced by output current modulation of input > thresholds was likely out of spec), highly skewed loading (not > convinced this is a real factor), and the absolute minimum flip-flop > to flip-flop delay conspired to bite us where it counted. As I recall this discussion and various previous analyses, the final concensus was that hugely different loads on the two clocks is suspect #1. If so, is this still (!) the view at Xilinx, and if it is the view has the clock buffering changed enough on recent products to alter matters?Article: 62404
Hi Mike, > Quartus II V3.0 SP2 is running full compilations here on SuSE Linux 8.1. > quartus_map error is gone. Just tested it on SuSE 9.0 and the problem is gone here too. > I may surplus my win2k box :) Good idea! ;-) BenArticle: 62405
philip wrote: > Try one of the Logic Analysers available from Acute. > > http://www.acute.com.tw/indexeng.htm I don't know what is inside these products, but for lovers of recursion it is almost certainly one or more FPGAs. Ditto the somewhat less expensive stuff at www.rockylogic.com, to which I contributed the design errors ;-)Article: 62406
Hi to all, I want to use a Xilinx Spartan3 XC3S1000 FG456 in my new design Does anybody knows the price (>1000p) and the availability for that chip? I found a price of about $200 at AVNET Xilinx is telling a much lower price...? So what is the truth Is the chip already available and at what realistic price?Article: 62408
When implementing Boot Loader to load main program in external memory, I wondered if it is possible to assign Boot BRAM address other than 0x0? Like PowerPC, the Boot Device didn't need to reside at 0x0, so the memory relocation was easier. We won't have to worry about vector table, because only the main program has a vector table. The Boot Loader just copy the main program from external memory to address 0x0 (SRAM or SDRAM), and then jump to 0x0. The Boot Loader doesn't involve any memory relocation. So the Boot Loader can be very small and simple.Article: 62409
Hi. 1. After configuration of BAR's, is there a way for the user application code (inside the fpga) to get the BAR's exact value? 2. Is there a way to set the BAR's values internally – i.e without a PCI-X configuration cycles ? 3. I would like to use the PCI-X core prior to the host configuration. I.e after appropriate reset phase, I would like to assert M_REQ of the core and then I expect the core to assert REQ_O. Is this possible? ThankX, NAHUMArticle: 62410
they are both correct.. check the volumes field on the Xilinx web site.. its probably 250,000 "itsme" <itsme@gmx.de> wrote in message news:bno138$fok$01$1@news.t-online.com... > Hi to all, > I want to use a Xilinx Spartan3 XC3S1000 FG456 in my new design > Does anybody knows the price (>1000p) and the availability for that chip? > I found a price of about $200 at AVNET > Xilinx is telling a much lower price...? > So what is the truth > Is the chip already available and at what realistic price? > >Article: 62411
"louis lin" <louis@zyflex.com.tw> wrote in message news:<bnni8v$c22@netnews.hinet.net>... > Thank you very much for your reply. > After some modification, my program was able to pass the assemble and progressed > the simulation. > May I ask another stupid question: Where is the I/O panel? How can I invoke it > during simulation? > > Best regards, > louis lin > > "Henk van Kampen" <henk@mediatronix.com> :23ecd97d.0310280624.483f8e41@posting.google.com... > : > : pBlazIDE uses a somewhat different syntax than KCPSMBLE. You should > : leave out the brackets around the second register. The INPUT opcode is > : INP. You can find the opcodes and directives for pBLazIDE on the web > : at www.mediatronix.com/pBlazIDE.htm. > : > : ?Phasing errors occur because of mismatches of labels between the 1st > : and 2nd pass. They can occur when some instructions are accepted by > : the 1st pass and not by the 2nd. Probably this is because of the > : differences in opcodes as explained. > : > : 'open file' reads the file as is. 'import' file is meant to convert > : the file while reading, from KCPSMBLE to pBlazeIDE syntax. > : > : Regards, > : Henk van Kampen > : www.mediatronix.com Please have a look at the directives page at the web site. You should use DSIN, DSOUT or DSIO to simulate I/O visually. Henk van Kampen www.mediatronix.comArticle: 62412
Praveen, It is difficult to estimate how much impact this will have on the power estimate. So let me take you through a few points: Using a post PAR estimate will allow XPower to have an accurate estimate of capacitance load on the internal routes so no problem here. If you are using post MAP where no SDF is generated then this is a large source of inaccuracy and is not recommended. Now lets look at the timing simulations tend to result in glitches. This switching translates into higher activity rates in XPower-> higher power. I would expect these to be fairly low load signals. Also if you have a fully synchronous design this effect will be limited. Your clocks will be set correctly (high power consuming nets). If you have met timing (verifed through timing analyser) then other heavy loaded signals like clock enables, should be set correctly. So in summary, if your design is post PAR, fully synchronous and has met timing, you should be OK an get an accurate power estimate. John praveen wrote: > hi all, > > i am calculating the power consumption using xilinx xpower. For > generating the VCD file i am not loading the SDF(Standard Delay > Format) during VSIM. Will it affect the power calculation. > > thanks in advance.Article: 62413
Hi all I don't know too much about fpga's yet so bear with me if this sounds too silly. I'm quite interested from what I heard so far and intend to dig deeper into the topic. While reading diverse articles about fpga's I got the impression that they have to be programmed out of a prom or through a microprocessor etc. However, this means that it would be very easy to "catch" this code in a finished design and abuse it to clone/copy such a design. So, my question is, is my impression right, and if so what common protection mechanisms are available? Or are there fpga's available that contain flash memory for the purpose of progrmming them on chip or such? Some scheme similar to what's available with most microcontrollers that contain on chip flash? TIA MarkusArticle: 62414
On Wed, 29 Oct 2003 13:30:09 +0100, Markus Zingg <m.zingg@nct.ch> wrote: > Hi all > > I don't know too much about fpga's yet so bear with me if this sounds > too silly. I'm quite interested from what I heard so far and intend to > dig deeper into the topic. > > While reading diverse articles about fpga's I got the impression that > they have to be programmed out of a prom or through a microprocessor > etc. However, this means that it would be very easy to "catch" this > code in a finished design and abuse it to clone/copy such a design. > > So, my question is, is my impression right, and if so what common > protection mechanisms are available? Or are there fpga's available > that contain flash memory for the purpose of progrmming them on chip > or such? Some scheme similar to what's available with most > microcontrollers that contain on chip flash? > > TIA > > Markus Yes it is possible to clone an FPGA that gets its config from a boot prom if somebody really wanted to do so. However if you are worried about this for your design then there are device families out there that are flash or antifuse based which make this much harder if not almost impossible. Actel have a feature called 'FlashLock' in their ProASIC+ devices which I believe is designed to protect against this and their Accelerator family as well as their older families are antifuse. Also Xilinx do what are called 'Hardcopy' devices which are basically the same as the original FPGA but with hardwired logic rather than being configurable. There are many other choices from Altera, Quicklogic, etc aswell I should imagine. Cheers, Pete.Article: 62415
Markus, You might want to look at Lattice PLD's. They have on board flash. You write to the chip initialy in the normal manner via JTAG, your code is then stored on the chips flash untill you reprogram it. Matt "Peter Molesworth" <noemail@anonymous.net> wrote in message news:oprxs2d9yz0ve4v7@news.tiscali.co.uk... > On Wed, 29 Oct 2003 13:30:09 +0100, Markus Zingg <m.zingg@nct.ch> wrote: > > > Hi all > > > > I don't know too much about fpga's yet so bear with me if this sounds > > too silly. I'm quite interested from what I heard so far and intend to > > dig deeper into the topic. > > > > While reading diverse articles about fpga's I got the impression that > > they have to be programmed out of a prom or through a microprocessor > > etc. However, this means that it would be very easy to "catch" this > > code in a finished design and abuse it to clone/copy such a design. > > > > So, my question is, is my impression right, and if so what common > > protection mechanisms are available? Or are there fpga's available > > that contain flash memory for the purpose of progrmming them on chip > > or such? Some scheme similar to what's available with most > > microcontrollers that contain on chip flash? > > > > TIA > > > > Markus > > Yes it is possible to clone an FPGA that gets its config from a boot prom > if somebody really wanted to do so. However if you are worried about this > for your design then there are device families out there that are flash or > antifuse based which make this much harder if not almost impossible. Actel > have a feature called 'FlashLock' in their ProASIC+ devices which I > believe is designed to protect against this and their Accelerator family > as well as their older families are antifuse. Also Xilinx do what are > called 'Hardcopy' devices which are basically the same as the original > FPGA but with hardwired logic rather than being configurable. There are > many other choices from Altera, Quicklogic, etc aswell I should imagine. > > Cheers, > > Pete.Article: 62416
You are right, and it is a problem. I have been thinking about it too. Overall I feel there isn't much security in the FPGA chips themselves, but I thought it might be an idea to have a smart card chip (as used in the SIMs for mobile phones). Your FPGA system configures as per normal. It then has encrypted conversation with the SIM (which is a far more secure device), and if it confirms the SIM is valid it works as normal, else it shuts down as you wish. This transfers the problem of cracking from the FPGA to the SIM. The FPGA config can still be ripped off of course, but without the SIM it will be useless. SIMs are pretty small and the carriers are easily available. The SIM only needs a 3.58 (or 5) MHz clock, and 5V or 3V. (I run my design off 14.3181 MHz, so this is easy to obtain). The SIM reader electronics is easy to implement. You still have to write the verification protocol. Sounds easy but it is not trivial making sure it has no security holes (I've worked with these chips). But easier to make the SIM secure (that's what they were designed for) than the FPGA/config ROM system. If you do manage to implement this, then it opens up a lot of possibilities. The SIM is detachable so you can get your stuff built in say the far east and post the SIMs to the end user by trusted carrier. They can easily install the SIM. You might also make the SIM specific to individual signed config ROMs. Or send upgrade config ROMs with SIMs.Article: 62417
Hello, The DCR interface of the PPC405 operates in two ways, referred to as mode 0 and mode 1. According to the Xilinx PPC405 spec these modes can't be programmed, because they are hardwired. So far I haven't found an interface signal of the PPC405 or anything else, which allows me to select either mode 0 or mode 1. Maybe I missed one cruical information in the spec. Many thanks for your help. RobertArticle: 62418
>You are right, and it is a problem. > >I have been thinking about it too. > >Overall I feel there isn't much security in the FPGA chips themselves, but I >thought it might be an idea to have a smart card chip (as used in the SIMs >for mobile phones). Your FPGA system configures as per normal. > >It then has encrypted conversation with the SIM (which is a far more secure >device), and if it confirms the SIM is valid it works as normal, else it >shuts down as you wish. > >This transfers the problem of cracking from the FPGA to the SIM. > >The FPGA config can still be ripped off of course, but without the SIM it >will be useless. > >SIMs are pretty small and the carriers are easily available. > >The SIM only needs a 3.58 (or 5) MHz clock, and 5V or 3V. >(I run my design off 14.3181 MHz, so this is easy to obtain). >The SIM reader electronics is easy to implement. > >You still have to write the verification protocol. >Sounds easy but it is not trivial making sure it has no security holes (I've >worked with these chips). >But easier to make the SIM secure (that's what they were designed for) than >the FPGA/config ROM system. > >If you do manage to implement this, then it opens up a lot of possibilities. > >The SIM is detachable so you can get your stuff built in say the far east >and post the SIMs to the end user by trusted carrier. They can easily >install the SIM. >You might also make the SIM specific to individual signed config ROMs. >Or send upgrade config ROMs with SIMs. Thanks for your reply. The problem I see with this aproach - provided I understood you correctly - is that since the code in the fpga would be "open" it could be reverse engineered much easier and the sim part could be shorted as a result also. I might sound paranoid - I'm not, I just like to know what I'm dealing with. The aproach with the Lattice PLD containing flash the other poster mentioned seems to be the best to me so far cause this means that a cracker would have to physically open the PLD and get down to this level where as "listening" on the bus is IMHO a lot easier. I might be wrong here, but at least to me the Lattice PLD aproach would be much harder to crack. Well, I'm looking foreward to eventually hear other ideas. MarkusArticle: 62419
So you're saying you want to initiate a data transfer between the time the system reboots and the BIOS assignes BAR values? For one, that's a little scarry, and for two, the system bus isn't going to be available during that time (where are you going to get/send data with no other devices on the bus?), and for three, I would doubt it is possible. If you need to do a data transfer at that time use some other medium from your board than the PCI-X bus. I believe if you use ports instead of memory registers you can set their exact values. You could pass in the memory registers' addresses when the driver initializes. Give some more detail for your app and we could get you some better suggestions. "Nahum Barnea" <nahum_barnea@yahoo.com> wrote in message news:fc23bdfc.0310290156.73759b42@posting.google.com... > Hi. > > 1. After configuration of BAR's, is there a way for the user > application code (inside the fpga) to get the BAR's exact value? > > 2. Is there a way to set the BAR's values internally - i.e without a > PCI-X configuration cycles ? > > 3. I would like to use the PCI-X core prior to the host configuration. > I.e after appropriate reset phase, I would like to assert M_REQ of the > core and then I expect the core to assert REQ_O. Is this possible? > > > ThankX, > NAHUMArticle: 62420
In article <l9cvpv4fb6dssvm0u6pn4t84di2cn0op9p@4ax.com>, Markus Zingg <m.zingg@nct.ch> wrote: >So, my question is, is my impression right, and if so what common >protection mechanisms are available? Or are there fpga's available >that contain flash memory for the purpose of progrmming them on chip >or such? Some scheme similar to what's available with most >microcontrollers that contain on chip flash? The V2/V2Pro has a configuration loader which can load bitfiles encrypted with DES/3DES. The decryption keys are stored, in battery-backed-up SRAM on the FPGA. -- Nicholas C. Weaver nweaver@cs.berkeley.eduArticle: 62421
Mike Treseler <mike.treseler@flukenetworks.com> writes: > Mike Treseler wrote: > > Charles Braquet wrote: > > > >> Quartus II V3.0 SP2 works on Linux 8.2. > >> I used to get your error before I installed the SP2 of Quartus > >> charles B. > > Given your good results, I will attempt to duplicate them > > and report back. Vielen Dank. > > Quartus II V3.0 SP2 is running full compilations here on SuSE Linux 8.1. > quartus_map error is gone. Unfortunately it will not run on x86-64: $cat /etc/SuSE-release SuSE Linux 8.2 (x86-64) VERSION = 8.2 $/net/sciraid2/raid2/home/local-linux-x86/altera/quartus2-3.0sp2/bin/quartus_sh Unknown Linux processor MWARCH: Undefined variable. MWCURRENT_LIBPATH: Undefined variable. It might be possible to modify the script (qenv.csh) to think that it's running on a plain x86. Tools from Synopsys, Cadence, and even Xilinx ISE 6.1i runs on this machine. As for using csh I would like quote Linus: The only way tcsh "rocks" is when the rocks are attached to its feet in the deepest part of a very deep lake. (Linus Torvalds) Petter -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?Article: 62422
This discussion has not mentioned the best protection in any FPGA: All Xilinx Virtex-II devices have an on-chip decryptor that can decrypt a triple-DES encoded bitstream, using an on-chip stored 3x56-bit key. This key is kept alive with a small external battery. A small price to pay for the best security in a wide range of high-performance FPGAs... Peter Alfke, Xilinx Applications ================== Markus Zingg wrote: > > >You are right, and it is a problem. > > > >I have been thinking about it too. > > > >Overall I feel there isn't much security in the FPGA chips themselves, but I > >thought it might be an idea to have a smart card chip (as used in the SIMs > >for mobile phones). Your FPGA system configures as per normal. > > > >It then has encrypted conversation with the SIM (which is a far more secure > >device), and if it confirms the SIM is valid it works as normal, else it > >shuts down as you wish. > > > >This transfers the problem of cracking from the FPGA to the SIM. > > > >The FPGA config can still be ripped off of course, but without the SIM it > >will be useless. > > > >SIMs are pretty small and the carriers are easily available. > > > >The SIM only needs a 3.58 (or 5) MHz clock, and 5V or 3V. > >(I run my design off 14.3181 MHz, so this is easy to obtain). > >The SIM reader electronics is easy to implement. > > > >You still have to write the verification protocol. > >Sounds easy but it is not trivial making sure it has no security holes (I've > >worked with these chips). > >But easier to make the SIM secure (that's what they were designed for) than > >the FPGA/config ROM system. > > > >If you do manage to implement this, then it opens up a lot of possibilities. > > > >The SIM is detachable so you can get your stuff built in say the far east > >and post the SIMs to the end user by trusted carrier. They can easily > >install the SIM. > >You might also make the SIM specific to individual signed config ROMs. > >Or send upgrade config ROMs with SIMs. > > Thanks for your reply. The problem I see with this aproach - provided > I understood you correctly - is that since the code in the fpga would > be "open" it could be reverse engineered much easier and the sim part > could be shorted as a result also. I might sound paranoid - I'm not, I > just like to know what I'm dealing with. > > The aproach with the Lattice PLD containing flash the other poster > mentioned seems to be the best to me so far cause this means that a > cracker would have to physically open the PLD and get down to this > level where as "listening" on the bus is IMHO a lot easier. I might be > wrong here, but at least to me the Lattice PLD aproach would be much > harder to crack. > > Well, I'm looking foreward to eventually hear other ideas. > > MarkusArticle: 62423
"Simon Peacock" <nowhere@to.be.found> writes: > they are both correct.. check the volumes field on the Xilinx web site.. its > probably 250,000 Yes. Take a look at the * at the bottom of this page: http://www.xilinx.com/prs_rls/silicon_spart/03142s3_pricing.htm Well, if he can team up with 250 of us and make an order of 1000 each as a single group we could get the $12 (I guess that is the lowest speed grade in the cheapest packet). Petter -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?Article: 62424
Peter Molesworth <noemail@anonymous.net> writes: > antifuse. Also Xilinx do what are called 'Hardcopy' devices which are > basically the same as the original FPGA but with hardwired logic Altera has HardCopy, not Xilinx. Petter -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?
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