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
Eric wrote: > > They created it this afternoon; it should be up! I'm going to import > the original code into svn right now... > ...Eric Eric, The version you uploaded is the latest ?!? I got it from : http://www.rogerstech.force9.co.uk/ http://www.rogerstech.force9.co.uk/xc3sprog/index.html (seems to be the webpage of the author...) SandroArticle: 104276
backhus, No reward but the satisfaction that you were able to outsmart a room full of very smart people. Such an accomplishment would definitely qualify the person for a job offer here at Xilinx. The part was the 2VP4. Austin backhus wrote: > Hi Austin, > that sounds reasonable. Security proofs are expensive. > > For the V2 boards you gave away ... what reward did you offer in case of > success? I suspect there are people out there who would pay good for > that knowledge as long as you don't have it, so why should they tell > you? ;-) > > Best regards > Eilert > > Austin Lesea schrieb: >> backhus, >> >> That is something that we thought about. But, really what we talking >> about is providing access to the crypto-engine through the general >> interconnect, and control of that engine. >> >> It was considered that anything we do in this regard would have to be >> completely and thoroughly tested so as not to be a back door, and >> compromise security. >> >> It wasn't worth the work to have to prove we did not break something.Article: 104277
Thomas, Yes, it is that cheap (and easy) to find and read efuses. If they had used Actel's via fuse technology, it would be much, much harder, but still do-able for a small number of vias. Of course, you would have to know where to look. The poly efuse is huge, and is almost big enough to see with the eye. An array of 128, or 256 has a big sign on it: "efuse array right here!" If you use the battery backed ram to store the key, the bitstream is protected, not the device. Any regular unencrypted bitstream can be loaded (or else how could you test your boards?). The use of efuses to make it such that only a particular device is able to load a particular bitsream is a requirement typical of the gaming industry (slot machines). This is a feature that we are looking at introducing in the future (if it does not compromise the higher level of security). As I said, I love efuses. They can be used for: serial numbers, lot and process information, feature selection and control, device identification, etc. You can even put a key in it, but make sure that the key in a non-volatile memory is clearly stated as not being NIST FIPS 140-2 compliant. There are customers for whom a low level of security is just fine. But for an IP company, placing my IP in such a low security device invites every crypto student looking for a job, or a degree, to hack it. Austin Thomas Stanka wrote: > Hi, > > Austin Lesea schrieb: > >> Just don't go advertising them to be more than they really are: a >> convenient way to make it cost at least $5,000 to find the key. > > Is it that cheap today to open the die and observe the fuses? > I have no idea, if (and how) Altera protected the key fuses against > optical inspection of die cuts. But If your right, it would be very > cheap to reengineer most Asics. > > BTW Am I right, that if I use a Xilinx with security inside a > equipment, the chip could be highjacked (Chipmodded) by just removing > the power supply of the keys and applieing a new bitstream? > Which means the bitstream itself may be protected, but not the chip? > Why did nobody combine software and fuse based technologies? It would > be sufficient to have 128 bit (with secure algorithms) in SW and 128 in > fuses. > > bye Thomas >Article: 104278
>Yes, it is that cheap (and easy) to find and read efuses. If they had >used Actel's via fuse technology, it would be much, much harder, but >still do-able for a small number of vias. Of course, you would have to >know where to look. The poly efuse is huge, and is almost big enough to >see with the eye. An array of 128, or 256 has a big sign on it: "efuse >array right here!" Whenever I get involved with a discussion like this, I point people at these papers: http://www.cl.cam.ac.uk/~mgk25/sc99-tamper.pdf http://www.cl.cam.ac.uk/~mgk25/sc99-tamper-slides.pdf That's from 1999. Still a great read. The details have changed, but I doubt if the general idea is out of date. People who build chips have to debug them. They will keep the technology up to date. -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.Article: 104279
"subint" <subin.82@gmail.com> wrote in message news:1150971643.167338.124530@r2g2000cwb.googlegroups.com... > Hi, > I am using the chipshop first time. Hi Subin, I recommend the battered cod. :-) > I am using this one to debug my ddr > controller in the v4 board. When i tried to route the data bus of ddr > through the chipscope it generated ILA and inserted into my design but > when i try to implement(map and par) xilinx ise showing error that the > bidirectional port is being driven by some buffer by the chipscope > module.the ddr bus are bidirectional so what changes needed in the > chipscope setting to route my bidirectional port. > regard > subin > I think your problem could be that you're trying to probe the pads of the IOBs. There's no way for ChipScope to connect to this without going through an input buffer. Try probing the signal that comes off the input buffer(IOB.I) of the IOB. If that's not it, perhaps you could post the error message you're getting? HTH, Syms. Inviato da X-Privat.Org - Registrazione gratuita http://www.x-privat.org/join.phpArticle: 104280
Hal, Those slides show a efuse that is really blown. The new technology does not vaporize the poly, it EM moves the ions all to one end, changing the poly's behavior under polarized light. But, the method still applies: you can visually read the values. Thanks for the posting. Austin Hal Murray wrote: >> Yes, it is that cheap (and easy) to find and read efuses. If they had >> used Actel's via fuse technology, it would be much, much harder, but >> still do-able for a small number of vias. Of course, you would have to >> know where to look. The poly efuse is huge, and is almost big enough to >> see with the eye. An array of 128, or 256 has a big sign on it: "efuse >> array right here!" > > Whenever I get involved with a discussion like this, I point people > at these papers: > http://www.cl.cam.ac.uk/~mgk25/sc99-tamper.pdf > http://www.cl.cam.ac.uk/~mgk25/sc99-tamper-slides.pdf > > That's from 1999. Still a great read. > > The details have changed, but I doubt if the general idea is out of > date. People who build chips have to debug them. They will keep the > technology up to date. >Article: 104281
On Wed, 21 Jun 2006 23:17:30 +0000, Duane Clark wrote:
> Rich Grise wrote:
>> On Tue, 20 Jun 2006 06:14:25 +0000, Adam Goldman wrote:
>>
>>> In article <pan.2006.06.11.03.15.36.415791@example.net>, Rich Grise wrote:
>>>> OK, I decided to take a chance and download that 839MB shell script that's
>>>> written for RedHat Enterprise, and was doing OK, (I had to shell out as
>>>> root a couple of times to give the install script permission to write to a
>>>> new directory, but that felt kind of kewl. :-) ), and now I'm at kind of a
>>>> stopper. The graphic install has the progress bar at 99%, and there's a
>>>> /lib/modules/misc/windrvr6.o: kernel-module version mismatch
>>>> /lib/modules/misc/windrvr6.o was compiled for kernel version
>>>> 2.4.18-14 while this kernel is version 2.4.31.
>>> Not specifically for your distribution but here's something on recompiling
>>> xpc4drvr and windrvr6 for a different kernel:
>>>
>>> http://gentoo-wiki.com/HOWTO_Xilinx
>>>
>>> It looks to me as if unless you're using their programmer hardware you
>>> don't need to bother. Synthesis and schematic capture ought to work without
>>> this driver.
>>>
>>> Coincidentally, Xilinx mailed out my copy of ISE today, so I'll know
>>> soon enough ;-)
>>
>> Thanks, but that link only talks about kernel 2.6, but Slackware ships
>> with 2.4, and 2.6 is an option, that I've been afraid to try. ("Compile
>> a new kernel????? Are you nuts?"
>
> Do you want to use the Xilinx programming tools (impact)? If not, you
> don't need those two drivers, as Adam said.
>
> If you do want to use those tools, then Xilinx requires that you
> recompile the drivers against your kernel, if you are using a kernel
> different from the one the compiled against. Kind of annoying, and
> hopefully one of these days Xilinx will do it right.
>
> If you have not recompiled your own kernel, then you probably just need
> to install the kernel sources corresponding to the kernel you have, and
> compile the drivers. I don't use Slackware, so I don't know how it is
> done there. I see that this is crossposted to alt.os.linux.slackware, so
> someone there could probably help with that.
I have no problem with compiling from source, on my current kernel, but
does Xilinx let us D/L source?
Thanks,
Rich
Article: 104282Morten Leikvoll wrote: > Looks like an idea.. Can I call a procedure from another procedure? In that > case I can try write a new procedure to extract the bit and pass it (as > inout?) to a clock detecting procedure using a clean bit. Hmm.. not sure if > that will work tho.. Gotta try it. Sounds like something that is worth to try. I can't tell you if it will be accepted. > I am not really trying to use dual edge here. I only want to program my > cpu_register to be able to detect a rising of falling edge from my system > depending on a constant input parameter (here, the input variable 'neg'). But what you have written is a something like dual-edge flipflop. If you want to detect edges of a signal, use 2 flipflops in a chain. The first samples the input data, the 2nd samples the output of the first. Now you can compare the output values of both flipflops. If the 1st has '0' as output and the 2nd '1' you got a falling_edge and the same holds for the rising_edge. The disadvantage: You have a delay depending on your sampling frequency. RalfArticle: 104283
Hi, I have implemented the Aurora protocol on the V2PRO FF672 FPGA. As part of testing, I need to access the TX data on the aurora links through RS232 interface as well. Now the problem I have is that the avbl project in XPS has a rx and tx port (std_logic) and the data I need to send is atleast 16 bits. How do I access or interface the register outputs from Aurora to RS232?? Thanks, VivekArticle: 104284
It's worse than Aurelian says. The newest version that supports these parts is 4.2i, but you must use schematic entry. Xilinx is no longer allowed to provide a synthesys license for these parts, and XST has never supported them. Have a nice day. blisca wrote: > how can i do to make it work with this old devices?experimenting with an old > board i need to add xcs30 and i need a tool(older impact versions) for > programming it,i guess that treatin it as an xc2s30 is not the right way to > proceed > Thanks to everyone > DiegoArticle: 104285
>Now the problem I have is that the avbl project in XPS has a rx and tx >port (std_logic) and the data I need to send is atleast 16 bits. How do >I access or interface the register outputs from Aurora to RS232?? It's fairly easy to make a hack RS-232 transmitter. It's just a shift register preloaded with the data and start/stop bits. For 16 bits of data, I'd use a 20 bit shift register - 2 8-bit bytes with start and stop bits on each. You can probably sort out all the LSB/MSB first and inversions by reading the specs carefully enough. It's probably simpler to put a scope on the cable to your PC and make it send a known pattern. You (probably) don't need fancy RS-232 level shifters. Most RS-232 receivers will do the right thing if you feed them a 3V CMOS signal. -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.Article: 104286
Can anyone tell me what Xilinx changed between rev C and rev D of the Spartan 3E Starter kit board? By the way, why the secret on page 3 on the rev D schematic? http://www.xilinx.com/bvdocs/ipcenter/block_diagram/S3E_Starter_D_External_sch.pdf Thanks, -Chris -- /> Christopher Cole <\ <\ << Cole Design and Development \\ email: cole@coledd.com \\ \\ Computer Networking & Embedded Electronics \\ web: http://coledd.com >> \> \> </Article: 104287
Christopher Cole <cole@scoob.coledd.com> wrote: > Can anyone tell me what Xilinx changed between rev C and rev D of the > Spartan 3E Starter kit board? > By the way, why the secret on page 3 on the rev D schematic? > http://www.xilinx.com/bvdocs/ipcenter/block_diagram/\ > S3E_Starter_D_External_sch.pdf It is probably the USB programming, using the Cypress FX2. Some reverse engineering has already been done. Look at old news. -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 104288
Hi to all I am new to group. i am working on aurora protocol. i am stuck as want to use aurora protocol fo r 4 byte interface. Although i can generate core for the same using core generator but the reaing interface signals have to generated. How do i do that. If any body has already done thatpls reply soon.Article: 104289
I'm connecting a V2Pro Rocket IO to a Agilent optical interface and am having problems getting the RocketIO receiver to reset properly and generate the correct data. The design originally used a Vitesse serial<->parallel interface chip and that worked fine. Since we have a spare RocketIO, we'd like to use it instead of the Vitesse chip. I'm running the link at 1062.5 Gbit/sec, so the reference clock for the RocketIO is 53.125MHz. Because of the optical protocol I'm talking to, I can't use clock correction, so I'm using the RXRECCLK to clock data+K_codes out of the RocketIO. Since RXRECCLK runs at the bit_rate/20, I'm using a 2 byte wide receiver interface. The problem I'm seeing is the receiver does not appear to reset and lock to the data source properly. My reset state machine looks for bad K codes and some other problems, and if needed, it generates a long reset signal to the ROcketIO receiver, then waits a while for it to come back to life. Unfortunately, the RocketIO does not appear to reset correctly. I'll see bad K codes and other garbage. If I disconnect the optical link, then reconnect it, I'll sometimes be able to get reasonable info out of the RocketIO. To generate the 53.125MHz reference clock, I'm dividing a high quality 106.25MHz reference clock in the FPGA to drive the RocketIO. Anyone have any hints? Thanks! John ProvidenzaArticle: 104290
Of course, 5 minutes after I posted the message I found the answer. I was never asserting the ENPCOMMAALIGN signal to the RocketIO, so it never really appeared to sync to the incoming data stream. It now looks OK. John P johnp wrote: > I'm connecting a V2Pro Rocket IO to a Agilent optical interface and > am having problems getting the RocketIO receiver to reset properly > and generate the correct data. The design originally used a Vitesse > serial<->parallel interface chip and that worked fine. Since we have > a spare RocketIO, we'd like to use it instead of the Vitesse chip. > > I'm running the link at 1062.5 Gbit/sec, so the reference clock for > the RocketIO is 53.125MHz. Because of the optical protocol I'm > talking to, I can't use clock correction, so I'm using the RXRECCLK > to clock data+K_codes out of the RocketIO. > > Since RXRECCLK runs at the bit_rate/20, I'm using a 2 byte wide > receiver interface. > > The problem I'm seeing is the receiver does not appear to reset > and lock to the data source properly. My reset state machine looks > for bad K codes and some other problems, and if needed, it generates > a long reset signal to the ROcketIO receiver, then waits a while for > it to come back to life. > > Unfortunately, the RocketIO does not appear to reset correctly. I'll > see bad K codes and other garbage. If I disconnect the optical link, > then reconnect it, I'll sometimes be able to get reasonable info out > of the RocketIO. > > To generate the 53.125MHz reference clock, I'm dividing a high quality > 106.25MHz reference clock in the FPGA to drive the RocketIO. > > Anyone have any hints? > > Thanks! > > John ProvidenzaArticle: 104291
Joseph wrote: > Steve, > > That .s/.S proprocessor thing is a feature (.S signals gcc to use the > preprocessor, .s tells it not to use the CPP). Yes, I know it's a feature, I just think it's bizarre to key on such a small difference, especially when Windows doesn't *really* support case in filenames. Anyway... > I'd wonder how you are actually compiling and linking. How are you > calling the tools? Do you have a makefile? I'm using the XPS tools from the GUI. Whatever canned/internal makefiles it uses. There are no makefiles in my project directory > Maybe the .S isn't getting > into the action with your makefile? No, I did see the different behavior with .s/.S -- it just didn't affect whether the code in the vectors section was output into the .elf file. Anyway, thanks for the comments... SteveArticle: 104292
Could be there is a place for both volatile and non-volatile security. Majority of customers we (Altera) have spoken to prefer the non-volatile key and are extremely satisfied with the security. This includes multiple military customers. Non-volatile security provides significantly more flexibility on the manufacturing process and enables some new royalty-based business models that cannot be facilitated with battery back-up security. If you are interested in further detials, here's a link to an upcoming net seminar. http://www.altera.com/education/net_seminars/all/ns-st2-design-security.html Dave Greenfield Altera Product MarketingArticle: 104293
Dave Greenfield wrote: > Could be there is a place for both volatile and non-volatile security. Of course, yes. To quote Austin : "The use of efuses to make it such that only a particular device is able to load a particular bitsream is a requirement typical of the gaming industry (slot machines). This is a feature that we are looking at introducing in the future (if it does not compromise the higher level of security)." So, seems Xilinx will also be doing this, sometime... In Security, the more hurdles, the better. It is, of course, only as strong as the weakest link. -jgArticle: 104294
Dave, Of course there is room for non-volatile keys! I am happy that you did your research and discovered what you think your customers want, but I question the results: was the question "do you want an easy to use and effective* security system that doesn't need a battery?" If so, then the answer is always "yes. I do!" But, if you had said: "Non-volatile keys are not NIST approved for use in any federal system, and not generally used in any private security application. Knowing this, would you choose to use a non-volatile key to protect your assets? or would you use a battery backed key" If so, then I suspect the answer would be "no.....you should have told me this." To have a press release that touts a "superior security solution" is the worst of the worst marketing. To claim to be able to protect IP from ASSP vendors is quite honestly, false and misleading. If I can get the IP that is a secret for less than $5,000, then I can clone the devices without paying anything at all. To imply that you have military customers satisfied with this level of security is amazing. Perhaps they have a thermite charge to destroy the device if it is tampered with. That does work, and makes getting parts back for RMA a non-problem, but is not a preferred solution! Or perhaps these devices are used for smart bombs and smart bullets. Hard to read it out when they are blowing up all around you. If what you are protecting is less than $5,00 in value, then it is great, and works just fine. By the way, when will you publish how the keys are programmed into the device? Seems there is an NDA in place, and you are keeping a secret. What are you hiding? Austin What is missing from all those press releases: *Disclaimer: non-volatile poly-efuse EM technology can be read out by a microscope using polarized light for a total investment of less than $5,000 Dave Greenfield wrote: > Could be there is a place for both volatile and non-volatile security. > Majority of customers we (Altera) have spoken to prefer the > non-volatile key and are extremely satisfied with the security. This > includes multiple military customers. > > Non-volatile security provides significantly more flexibility on the > manufacturing process and enables some new royalty-based business > models that cannot be facilitated with battery back-up security. > > If you are interested in further detials, here's a link to an upcoming > net seminar. > http://www.altera.com/education/net_seminars/all/ns-st2-design-security.html > > Dave Greenfield > Altera Product Marketing >Article: 104295
Austin Lesea wrote: > What is missing from all those press releases: > > *Disclaimer: non-volatile poly-efuse EM technology can be read out by a > microscope using polarized light for a total investment of less than $5,000 .. and that may not quite be the open door you paint. Have _you_actually_cloned_ a/any device for $5000, or is this more generic "Austin Arm waving" ? :) [Until Xilinx have non volatile fuses, then the spin will change ? ] Being able to read the physical fuses is some way from being able to duplicate them, or reverse the key those fuses create. It is not likely that Altera simply mapped Fuse1 = Encryption bit1, etc. So, to descramble that, will need a LOT of devices, and much more time.... With fully volatile security, yes, the code within is secure, but the system is _very_ open to spoofing type attacks, so again security can be a mirage.... -jgArticle: 104296
I am planning on buying either a Xilinx Spartan or Altera Development Kit to test out some designs on FPGA. (I am New to FPGAs). Question: Once the design has been downloaded into the FPGA, how do I apply stimulus and test the design? I believe several methods are possible, but I would like one where both the stimulus (is applied in) and the response (is checked) using a high level language like C or C++. Are there any C/C++ "APIs" that allow the FPGA pins to be "wiggled"? That way I can write C or C++ code to run a real "app".Article: 104297
anand wrote:
> Once the design has been downloaded into the FPGA, how do I apply
> stimulus and test the design?
It's best to test the code before you synthesize it.
You don't even need a development board for this.
Just a text editor and a simulator.
> I believe several methods are possible,
> but I would like one where both the stimulus (is applied in) and the
> response (is checked) using a high level language like C or C++.
> Are there any C/C++ "APIs" that allow the FPGA pins to be "wiggled"?
A simulation testbench that you write
in vhdl or verilog will wiggle and watch the pins
logically, not physically.
> That way I can write C or C++ code to run a real "app".
No. The C API is for simulation too,
but you won't need it to start out.
-- Mike Treseler
Article: 104298anand wrote: > Once the design has been downloaded into the FPGA, how do I apply > stimulus and test the design? I believe several methods are possible, > but I would like one where both the stimulus (is applied in) and the > response (is checked) using a high level language like C or C++. > Are there any C/C++ "APIs" that allow the FPGA pins to be "wiggled"? > That way I can write C or C++ code to run a real "app". An FPGA is no different in this respect to any other piece of hardware you may design. So there is no software "API" to interface to an FPGA any more than there are APIs to interface to a 74LS02 or a LED. You may be getting confused with *simulation*, which does not involve programming a physical FPGA but instead simulating the behaviour of your FPGA code in software. Stimulus can be provided in several manners and with many different languages, including C/C++. Alternatively, you need to interface your FPGA to a PC via whatever means is suitable to the task, from a PCIe/PCI connector down to a serial port. Exactly how you interface in software is very dependent on the hardware interface method you choose. Another alternative I've just thought of involves using a soft-core processor inside the FPGA to interface with the core logic, enabling you to write stimulus in C. That brings a whole number of new issues, not the least of which is the requirement for a much larger FPGA and perhaps more RAM than would otherwise be required. Regards, -- Mark McDougall, Engineer Virtual Logic Pty Ltd, <http://www.vl.com.au> 21-25 King St, Rockdale, 2216 Ph: +612-9599-3255 Fax: +612-9599-3266Article: 104299
So it's quite easy! Banks 1, 2, 5, 6 are all row pins, the other banks are column pins. Roland. Subroto Datta schrieb: > One way of obtaining this information in Quartus II 6.0 is to create a > project, assign the device that you want to use (Assignments->Device), open > the Pin Planner (Assignments->Pin Planner) and in the All Pins View (this is > the table in the lower half of the screen) customize the columns using the > following steps: > > 1. Right click in the All Pins View->Customize Columns..., and add the > General Function Column. The Genaral Function column will show if it is Row > I/O or Column I/O. > 2. Right click in the All Pins View and click on the Show Assignable Pins. > This will show all pins on the package. > > You can order the columns displayed in step 1. You can then copy and paste > this information into Excel or your favorite document format. > > Hope this helps, > - Subroto Datta > Altera Corp. > > <rreuter@gmx.net> wrote in message > news:1150877340.814578.94120@g10g2000cwb.googlegroups.com... > > An Altera application note (AN-349) recommends placing certain outputs > > on column pins and others on row pins. My question is: which pins of > > the Stratix device are column and which are row pins? Is there a > > document that includes this info? I assume that the assignment is fixed > > and given by architecture, not dynamically? > > > > Thanks for advices, Roland. > >
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