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
Hi all, I'm doing few tests in these days with the PicoBlaze and it seems to work just fine. Now, in my project, where a Spartan3 has to deal with a DSP through a serial spi-like communication to reply on different request that may arrive, do you think could be woth using with a PicoBlaze as a supervisor? I mean, the FPGA could reveive a request to read from its inputs, or to write on its output, or to read a temperature from an spi-sensor and the send it to the DPS, or to read the values from quadraure decoder... Picoblaze or vhdl from scratch in your experienced opinion? I'm making some considerations by myself now, but I'd like to hear comments from you too. Thanks, MarcoArticle: 104301
Marco schrieb: > Hi all, > > I'm doing few tests in these days with the PicoBlaze and it seems to > work just fine. Now, in my project, where a Spartan3 has to deal with a > DSP through a serial spi-like communication to reply on different > request that may arrive, do you think could be woth using with a > PicoBlaze as a supervisor? I mean, the FPGA could reveive a request to > read from its inputs, or to write on its output, or to read a > temperature from an spi-sensor and the send it to the DPS, or to read > the values from quadraure decoder... > Picoblaze or vhdl from scratch in your experienced opinion? > I'm making some considerations by myself now, but I'd like to hear > comments from you too. Picoblaze offers a lot of bang for the buck. Especially in S3, where you have 1k program space. Since it sounds like you have to handle a lot of task which are not too time critical, I would go for the Picoblaze. Also, odification in the control algorithm are done much easier in the picoblaze than in a FSM. Regards FalkArticle: 104302
Hi, i am trying to probe the signal going to the IOB.When i try to probe the ddr_dq(the inout port of the ddr) i got this error. Started : "Map". Using target part "4vlx60ff668-10". Mapping design into LUTs... Running directed packing... ERROR:Pack:1564 - The dual data rate register mem_interface_top0/main_00/top_00/iobs_00/data_path_iobs_00/v4_dq_iob0/oddr_d q failed to join the OLOGIC component as required. The output signal for register symbol mem_interface_top0/main_00/top_00/iobs_00/data_path_iobs_00/v4_dq_iob0/oddr_d q requires general routing. ERROR:Pack:1564 - The dual data rate register mem_interface_top0/main_00/top_00/iobs_00/data_path_iobs_00/v4_dq_iob1/oddr_d q failed to join the OLOGIC component as required. The output signal for register symbol mem_interface_top0/main_00/top_00/iobs_00/data_path_iobs_00/v4_dq_iob1/oddr_d q requires general routing. ERROR:Pack:1564 - The dual data rate register mem_interface_top0/main_00/top_00/iobs_00/data_path_iobs_00/v4_dq_iob2/oddr_d q failed to join the OLOGIC component as required. The output signal for register symbol mem_interface_top0/main_00/top_00/iobs_00/data_path_iobs_00/v4_dq_iob2/oddr_d q requires general routing. ERROR:Pack:1564 - The dual data rate register mem_interface_top0/main_00/top_00/iobs_00/data_path_iobs_00/v4_dq_iob3/oddr_d q failed to join the OLOGIC component as required. The output signal for register symbol mem_interface_top0/main_00/top_00/iobs_00/data_path_iobs_00/v4_dq_iob3/oddr_d q requires general routing. ERROR:Pack:1564 - The dual data rate register mem_interface_top0/main_00/top_00/iobs_00/data_path_iobs_00/v4_dq_iob4/oddr_d q failed to join the OLOGIC component as required. The output signal for register symbol mem_interface_top0/main_00/top_00/iobs_00/data_path_iobs_00/v4_dq_iob4/oddr_d q requires general routing. ERROR:Pack:1564 - The dual data rate register mem_interface_top0/main_00/top_00/iobs_00/data_path_iobs_00/v4_dq_iob5/oddr_d q failed to join the OLOGIC component as required. The output signal for register symbol mem_interface_top0/main_00/top_00/iobs_00/data_path_iobs_00/v4_dq_iob5/oddr_d q requires general routing. ERROR:Pack:1564 - The dual data rate register mem_interface_top0/main_00/top_00/iobs_00/data_path_iobs_00/v4_dq_iob6/oddr_d q failed to join the OLOGIC component as required. The output signal for register symbol mem_interface_top0/main_00/top_00/iobs_00/data_path_iobs_00/v4_dq_iob6/oddr_d q requires general routing. ERROR:Pack:1564 - The dual data rate register mem_interface_top0/main_00/top_00/iobs_00/data_path_iobs_00/v4_dq_iob7/oddr_d q failed to join the OLOGIC component as required. The output signal for register symbol mem_interface_top0/main_00/top_00/iobs_00/data_path_iobs_00/v4_dq_iob7/oddr_d q requires general routing. ERROR:Pack:1564 - The dual data rate register mem_interface_top0/main_00/top_00/iobs_00/data_path_iobs_00/v4_dq_iob8/oddr_d q failed to join the OLOGIC component as required. The output signal for register symbol mem_interface_top0/main_00/top_00/iobs_00/data_path_iobs_00/v4_dq_iob8/oddr_d q requires general routing. ERROR:Pack:1564 - The dual data rate register mem_interface_top0/main_00/top_00/iobs_00/data_path_iobs_00/v4_dq_iob9/oddr_d q failed to join the OLOGIC component as required. The output signal for register symbol mem_interface_top0/main_00/top_00/iobs_00/data_path_iobs_00/v4_dq_iob9/oddr_d q requires general routing. ERROR:Pack:1564 - The dual data rate register mem_interface_top0/main_00/top_00/iobs_00/data_path_iobs_00/v4_dq_iob10/oddr_ dq failed to join the OLOGIC component as required. The output signal for register symbol mem_interface_top0/main_00/top_00/iobs_00/data_path_iobs_00/v4_dq_iob10/oddr_ dq requires general routing. ERROR:Pack:1564 - The dual data rate register mem_interface_top0/main_00/top_00/iobs_00/data_path_iobs_00/v4_dq_iob11/oddr_ dq failed to join the OLOGIC component as required. The output signal for register symbol mem_interface_top0/main_00/top_00/iobs_00/data_path_iobs_00/v4_dq_iob11/oddr_ dq requires general routing. ERROR:Pack:1564 - The dual data rate register mem_interface_top0/main_00/top_00/iobs_00/data_path_iobs_00/v4_dq_iob12/oddr_ dq failed to join the OLOGIC component as required. The output signal for register symbol mem_interface_top0/main_00/top_00/iobs_00/data_path_iobs_00/v4_dq_iob12/oddr_ dq requires general routing. ERROR:Pack:1564 - The dual data rate register mem_interface_top0/main_00/top_00/iobs_00/data_path_iobs_00/v4_dq_iob13/oddr_ dq failed to join the OLOGIC component as required. The output signal for register symbol mem_interface_top0/main_00/top_00/iobs_00/data_path_iobs_00/v4_dq_iob13/oddr_ dq requires general routing. ERROR:Pack:1564 - The dual data rate register mem_interface_top0/main_00/top_00/iobs_00/data_path_iobs_00/v4_dq_iob14/oddr_ dq failed to join the OLOGIC component as required. The output signal for register symbol mem_interface_top0/main_00/top_00/iobs_00/data_path_iobs_00/v4_dq_iob14/oddr_ dq requires general routing. ERROR:Pack:1564 - The dual data rate register mem_interface_top0/main_00/top_00/iobs_00/data_path_iobs_00/v4_dq_iob15/oddr_ dq failed to join the OLOGIC component as required. The output signal for register symbol mem_interface_top0/main_00/top_00/iobs_00/data_path_iobs_00/v4_dq_iob15/oddr_ dq requires general routing. ERROR:Pack:1569 - The dual data rate register mem_interface_top0/main_00/top_00/iobs_00/data_path_iobs_00/v4_dq_iob1/oddr_d q failed to join an OLOGIC component as required. ERROR:Pack:1569 - The dual data rate register mem_interface_top0/main_00/top_00/iobs_00/data_path_iobs_00/v4_dq_iob10/oddr_ dq failed to join an OLOGIC component as required. ERROR:Pack:1569 - The dual data rate register mem_interface_top0/main_00/top_00/iobs_00/data_path_iobs_00/v4_dq_iob5/oddr_d q failed to join an OLOGIC component as required. ERROR:Pack:1569 - The dual data rate register mem_interface_top0/main_00/top_00/iobs_00/data_path_iobs_00/v4_dq_iob14/oddr_ dq failed to join an OLOGIC component as required. ERROR:Pack:1569 - The dual data rate register mem_interface_top0/main_00/top_00/iobs_00/data_path_iobs_00/v4_dq_iob9/oddr_d q failed to join an OLOGIC component as required. ERROR:Pack:1569 - The dual data rate register mem_interface_top0/main_00/top_00/iobs_00/data_path_iobs_00/v4_dq_iob2/oddr_d q failed to join an OLOGIC component as required. ERROR:Pack:1569 - The dual data rate register mem_interface_top0/main_00/top_00/iobs_00/data_path_iobs_00/v4_dq_iob11/oddr_ dq failed to join an OLOGIC component as required. ERROR:Pack:1569 - The dual data rate register mem_interface_top0/main_00/top_00/iobs_00/data_path_iobs_00/v4_dq_iob6/oddr_d q failed to join an OLOGIC component as required. ERROR:Pack:1569 - The dual data rate register mem_interface_top0/main_00/top_00/iobs_00/data_path_iobs_00/v4_dq_iob15/oddr_ dq failed to join an OLOGIC component as required. ERROR:Pack:1569 - The dual data rate register mem_interface_top0/main_00/top_00/iobs_00/data_path_iobs_00/v4_dq_iob3/oddr_d q failed to join an OLOGIC component as required. ERROR:Pack:1569 - The dual data rate register mem_interface_top0/main_00/top_00/iobs_00/data_path_iobs_00/v4_dq_iob12/oddr_ dq failed to join an OLOGIC component as required. ERROR:Pack:1569 - The dual data rate register mem_interface_top0/main_00/top_00/iobs_00/data_path_iobs_00/v4_dq_iob7/oddr_d q failed to join an OLOGIC component as required. ERROR:Pack:1569 - The dual data rate register mem_interface_top0/main_00/top_00/iobs_00/data_path_iobs_00/v4_dq_iob0/oddr_d q failed to join an OLOGIC component as required. ERROR:Pack:1569 - The dual data rate register mem_interface_top0/main_00/top_00/iobs_00/data_path_iobs_00/v4_dq_iob4/oddr_d q failed to join an OLOGIC component as required. ERROR:Pack:1569 - The dual data rate register mem_interface_top0/main_00/top_00/iobs_00/data_path_iobs_00/v4_dq_iob13/oddr_ dq failed to join an OLOGIC component as required. ERROR:Pack:1569 - The dual data rate register mem_interface_top0/main_00/top_00/iobs_00/data_path_iobs_00/v4_dq_iob8/oddr_d q failed to join an OLOGIC component as required. i didnt understand the message. can you please tell me what it is. regard subin Symon wrote: > "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: 104303
subint wrote: >>"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 > Symon replied: > >>> >> >>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. subint followup: > Hi, > i am trying to probe the signal going to the IOB.When i try to probe > the ddr_dq(the inout port of the ddr) i got this error. > Started : "Map". > Using target part "4vlx60ff668-10". > Mapping design into LUTs... > Running directed packing... > ERROR:Pack:1564 - The dual data rate register > > mem_interface_top0/main_00/top_00/iobs_00/data_path_iobs_00/v4_dq_iob0/oddr_d > q failed to join the OLOGIC component as required. The output > signal for > register symbol > [snip] Symon is right, you've specified an IOB output to probe in ChipScope. Although ChipScope lets you do this, it's generally a bad idea, especially if you have an IOB flip-flop. In the case where you're probing the output of a non-DDR IOB flip-flop, ChipScope connects a probe to the flip-flop output, but then ISE can't place the flip-flop in the IOB (because there is no routing resource that ISE can find), so the flip-flop goes in the fabric. Now, instead of having a nice short clock-to-output delay, you have a much longer delay through the fabric. In the case of the DDR IOB flip-flop, there is no DDR flip-flop that ISE can put in the fabric, so the signal can't be routed. --- Joe Samson Pixel VelocityArticle: 104304
Marco wrote: > Hi all, > > I'm doing few tests in these days with the PicoBlaze and it seems to > work just fine. Now, in my project, where a Spartan3 has to deal with a > DSP through a serial spi-like communication to reply on different > request that may arrive, do you think could be woth using with a > PicoBlaze as a supervisor? I mean, the FPGA could reveive a request to > read from its inputs, or to write on its output, or to read a > temperature from an spi-sensor and the send it to the DPS, or to read > the values from quadraure decoder... > Picoblaze or vhdl from scratch in your experienced opinion? > I'm making some considerations by myself now, but I'd like to hear > comments from you too. > > Thanks, > Marco The PicoBlaze is absolute gem and easy to use. At one block ram and under a hundred slices in size it is not that big, but can do quite a lot of work. One of the things that I like about it is that I can change its program without having to resynthesize and place and route again. They are very well suited for large state machines that need to deal with events at microsecond or slower rates. We have used them on a V4FX with the TEMAC to offload a custom IP/UDP protocol at GIGE rates, on a Spartan3e to read the file system on a MiniSD card, and on a V2 to run the adapation algorithm of some adaptive filters. In all of these applications, I think that it was simpler to write the assembly code than it would have been to write a VHDL/Verilog state machine, and probably used less resources as well. On the Xilinx web site, there is a fourm dedicated to the PicoBlaze with some links to PicoBlaze programs for IIC, serial ports etc that may be of interest to you as examples. Regards, John McCaskillArticle: 104305
If you are new to FPGA, probably new to VHDL and Digital Design. I hope you get some good references in Digital Systems, Synchronous design and Synthesizable VHDL (google, the Great Library). You won=B4t regret studying this and things will sound a lot more familiar... Regards, Ricardo anand escreveu: > 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: 104306
Hi,
I am using __attribute__ ((section ("ppath"))) and __attribute__
((longcall)) now in my program. The relevant linker script part looks
like this:
MEMORY
{
SDRAM_64Mx16 : ORIGIN = 0xF0000000, LENGTH = 0x01FFFFFF
plb_bram_if_cntlr_1 : ORIGIN = 0xFFFFC000, LENGTH = 0x00003FFF
}
/* Specify the default entry point to the program */
ENTRY(_boot)
STARTUP(boot.o)
/* Define the sections, and where they are mapped in memory */
SECTIONS
{
.vectors : {
__vectors_start = .;
*(.vectors)
__vectors_end = .;
} > SDRAM_64Mx16
.text : {
__text_start = .;
*(.ppath)
*(.text)
*(.text.*)
*(.gnu.linkonce.t*)
__text_end = .;
} > SDRAM_64Mx16
After compilation I run powerpc-eabi-objdump and I get:
0 .vectors 000020c4 f0000000 f0000000 00000110 2**0
CONTENTS, ALLOC, LOAD, READONLY, CODE
1 .text 0000e6e8 f00020c4 f00020c4 000021d4 2**2
CONTENTS, ALLOC, LOAD, CODE
2 ppath 0000001c 00000000 00000000 000000f4 2**2
CONTENTS, ALLOC, LOAD, READONLY, CODE
3 .rodata 00000906 f00107ac f00107ac 000108bc 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
4 .fixup 00000014 f00110b4 f00110b4 000111c4 2**2
My question is why is ppath at 0x00000000 when this address should not
be mapped in
the SDRAM?
Actually I would have liked to have the ppath section directly after or
before all
other code, so that maybe __attribute__ ((longcall)) shouldn't even be
necessary.
Regards,
e.
Article: 104307
Ok guys,
I think I got it, it should be:
*(ppath)
without the dot and I won't see section ppath in the output :).
Regards,
e.
Article: 104308Jim, No, I have not cracked the Altera chip. I have received emails from schools and universities who wish to crack it. These are the same schools that have published successful smart card attacks. My quote of $5,000 is what we pay to have a device ground down on the backside such that we can do analysis on a device. For another $5,000, one can get up to three or four FIB cuts, and a couple of jumper wires. The IEEE paper clearly discusses the technology, and what happens when the fuse has all of its ions electromigrated to the other end, leaving intrinsic silicon poly, which has a different index of refraction that the poly with the ions. There are difficulties. Find the fuses, read the values, and then figure out what (if any)logic may be present to confuse the key bits. That is why the Actel via fuses are considered much better (harder to find, and read). None the less, the attack is not 2E128 as the NIST standard implies (the one they claim to meet FIPS 197, definition of AES 128, 256, 384 and 512). Sure the algorithm is a AES 128 one, but with knowledge of all the fuse contents, the search space is lessened such that in maybe twenty minutes or so of permutations on the key bits, you have the device unlocked (bitstream is now in the clear on your computer, and ready for cloning, reverse engineering, etc.) No one has reverse engineered a bitstream for Xilinx or Altera, as far as we know, on a large device. But that doesn't mean that someone could not make specific modifications to an existing bitstream (change IO location, drive strength, etc.) without having to know the whole design. The question is not one of can I crack it (I believe I can), but one of a ASSP vendor deciding to place their IP in a component that is not in compliance with FIPS 140-2. Very, very simple. For reference: http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=1493126 Remember that any attack that is successful removes the security forever. So, do you want to use something where there are known ways to crack it? Or, do you want to use something that today there is no known method of cracking? For example, finding the battery backed key has been something that has been tried and been unsuccessful. Then we were attacked with differential power attacks (DPA). So far, those have been unsuccessful as well. As an aside, DPA attacks of ASIC AES has been successful! Yet another example of how a FPGA can actually be superior to an ASIC solution. I will be giving a talk on security in V4 and V5 soon, so watch for the announcements. Just as an aside, the coin cell lithium battery vendors have informed me that for my use, the battery will last "forever." Since we hold the key down to Vbatt voltages of much less than 1 volt, and the coin cell starts out life at over 3 volts, and the stated 15 year life is to discharge to 2 volts, we will last multiples of 15 years. So the "terrible battery problem" is no big issue. Set top cable boxes use a lithium battery to store the keys. Cable companies aren't stupid: they would not use a battery unless there was a good reason. After all, they make millions of set top boxes. All they protect is a few movies, and yet they feel that following FIPS 140-2 is the only safe way to go (as everything else has been hacked). We are examining how to use efuses. I can not say anything right now, except I think there are going to be very useful, and helpful. They can be used for device ID, matching a key to a device, factory information (lot, wafer, serial numbers), control of internal circuits (set currents, voltages, etc. to get around process variations), repair faults by substituting redundant features...long long list. And, of course, to hold a key for those who only have a $5,000 or less secret to protect. How much efuse memory should be for the user? How much for the customer? Unlike my friend, the questions we ask are pretty detailed, and we are very careful about what we do. Austin Jim Granville wrote: > 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.... > > -jg >Article: 104309
Jim, Part of my problem is that Altera has kept it a secret how to set the key bits. Without that knowledge, I can not program a device, in order to crack it. So, I guess I will have to buy some parts from those trusting ASSP vendors. Austin Austin Lesea wrote: > Jim, > > No, I have not cracked the Altera chip. I have received emails from > schools and universities who wish to crack it. These are the same > schools that have published successful smart card attacks. > > My quote of $5,000 is what we pay to have a device ground down on the > backside such that we can do analysis on a device. > > For another $5,000, one can get up to three or four FIB cuts, and a > couple of jumper wires. > > The IEEE paper clearly discusses the technology, and what happens when > the fuse has all of its ions electromigrated to the other end, leaving > intrinsic silicon poly, which has a different index of refraction that > the poly with the ions. > > There are difficulties. Find the fuses, read the values, and then > figure out what (if any)logic may be present to confuse the key bits. > > That is why the Actel via fuses are considered much better (harder to > find, and read). > > None the less, the attack is not 2E128 as the NIST standard implies (the > one they claim to meet FIPS 197, definition of AES 128, 256, 384 and > 512). Sure the algorithm is a AES 128 one, but with knowledge of all > the fuse contents, the search space is lessened such that in maybe > twenty minutes or so of permutations on the key bits, you have the > device unlocked (bitstream is now in the clear on your computer, and > ready for cloning, reverse engineering, etc.) > > No one has reverse engineered a bitstream for Xilinx or Altera, as far > as we know, on a large device. But that doesn't mean that someone could > not make specific modifications to an existing bitstream (change IO > location, drive strength, etc.) without having to know the whole design. > > The question is not one of can I crack it (I believe I can), but one of > a ASSP vendor deciding to place their IP in a component that is not in > compliance with FIPS 140-2. Very, very simple. > > For reference: > http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=1493126 > > Remember that any attack that is successful removes the security > forever. So, do you want to use something where there are known ways to > crack it? Or, do you want to use something that today there is no known > method of cracking? > > For example, finding the battery backed key has been something that has > been tried and been unsuccessful. Then we were attacked with > differential power attacks (DPA). So far, those have been unsuccessful > as well. As an aside, DPA attacks of ASIC AES has been successful! > > Yet another example of how a FPGA can actually be superior to an ASIC > solution. > > I will be giving a talk on security in V4 and V5 soon, so watch for the > announcements. > > Just as an aside, the coin cell lithium battery vendors have informed me > that for my use, the battery will last "forever." Since we hold the key > down to Vbatt voltages of much less than 1 volt, and the coin cell > starts out life at over 3 volts, and the stated 15 year life is to > discharge to 2 volts, we will last multiples of 15 years. So the > "terrible battery problem" is no big issue. > > Set top cable boxes use a lithium battery to store the keys. Cable > companies aren't stupid: they would not use a battery unless there was > a good reason. After all, they make millions of set top boxes. All > they protect is a few movies, and yet they feel that following FIPS > 140-2 is the only safe way to go (as everything else has been hacked). > > We are examining how to use efuses. I can not say anything right now, > except I think there are going to be very useful, and helpful. They can > be used for device ID, matching a key to a device, factory information > (lot, wafer, serial numbers), control of internal circuits (set > currents, voltages, etc. to get around process variations), repair > faults by substituting redundant features...long long list. And, of > course, to hold a key for those who only have a $5,000 or less secret to > protect. > > How much efuse memory should be for the user? How much for the > customer? Unlike my friend, the questions we ask are pretty detailed, > and we are very careful about what we do. > > Austin > > > Jim Granville wrote: >> 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.... >> >> -jg >>Article: 104310
> 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...) > > Sandro Wow, I swear I started with the same copy. I don't know how that happened... try again? Revision 2 should be the latest latest.Article: 104311
rashid.karimov@gmail.com wrote: > ISE and/or EDK ? I just received the S3E board. It comes with: DVD- ISE 8.1i (not sure if it's the latest SP) ISE 8.1i Foundation (eval) Chipscope Pro 8.1i (eval) Spartan-3 Generation Resource CD EDK 8.1i, including Platform Studio (eval(Windows only)) HTH -Dave PollumArticle: 104312
So in the case, how do real applications actually run (in the customer environment) when it is downloaded onto an FPGA? Mark McDougall wrote: > anand 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: 104313
I'm assuming that "neg" is a constant? Try declaring neg as a constant parameter, or using an entity with neg as a generic. If you can tolerate a delta delay on the clock in simulation, you could xor the clock with neg and then use only one edge specification. The xor with a constant will get optimized out. True DDR circuits are possible with single edge flops and xor gates: process (clk) variable qr, qf : std_logic; begin if rising_edge(clk) then qr := d xor qf; -- encode qr elsif falling_edge(clk) then qf := d xor qr; -- encode qf end if; q <= qr xor qf; -- decode q (combinatorial) end if; Andy Ralf Hildebrandt wrote: > Morten 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: 104314
Austin Lesea wrote: > Jim, > > Part of my problem is that Altera has kept it a secret how to set the > key bits. > > Without that knowledge, I can not program a device, in order to crack it. Hmmm ... perhaps you might now understand the feelings of those legit users want the Xilinx bitstream format opened (so they can write their own tools). Everybody's got a secret, I guess. -aArticle: 104315
Rich Grise wrote: > 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: >>>> Not specifically for your distribution but here's something on recompiling >>>> xpc4drvr and windrvr6 for a different kernel: >>>> >>>> http://gentoo-wiki.com/HOWTO_Xilinx >>>> > ... > I have no problem with compiling from source, on my current kernel, but > does Xilinx let us D/L source? > Yes. The HOWTO mentioned by Adam tells where to get them from Xilinx.Article: 104316
Andy wrote: > True DDR circuits are possible with single edge flops and xor gates: > > process (clk) > variable qr, qf : std_logic; > begin > if rising_edge(clk) then > qr := d xor qf; -- encode qr > elsif falling_edge(clk) then > qf := d xor qr; -- encode qf > end if; > q <= qr xor qf; -- decode q (combinatorial) > end if; A lot of synthesis tools will refuse to do something with such a process. They see two 'event conditions and finish with an error. That is the reason why I have suggested to model this "pseudo-dual-edge flipflop" manually. RalfArticle: 104317
Mike Treseler 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. Let me add: After the simulation tests the real hardware tests at the FPGA have to be done either using some pins and applying the stimuli from another device, like a personal computer or using a synthesized testbench, that has to be build additionally to the design. RalfArticle: 104318
anand wrote:
> So in the case, how do real applications actually run (in the customer
> environment) when it is downloaded onto an FPGA?
There are no applications.
There are only gates and flops.
-- Mike Treseler
Article: 104319hi, there in my project, i need to do some multiplication. and i optimized the multiplicand to numbers like 0.75, 0.625. I wonder would the synthesizer automatically detect them like 0.75 = 1 - 1/4, 0.625 = 1/2 + 1/8, or i need to code it manually in this way? does it differ across different synthesizer? i am using xilinx synthesizer. thanks ZhaoyiArticle: 104320
agou schrieb: > hi, there > > in my project, i need to do some multiplication. and i optimized the > multiplicand to numbers like 0.75, 0.625. I wonder would the > synthesizer automatically detect them like 0.75 = 1 - 1/4, 0.625 = 1/2 > + 1/8, or i need to code it manually in this way? You need to code "semi" manual anyway, since most synthesizers do not support floting point multiplications. So when you make a x 0.75 multiplication, you need to multiply by 192 when you need 8 bit precision. A multiplication with an constant is cheap anyway. Regards FalkArticle: 104321
In article <1151084296.046232.309590@m73g2000cwd.googlegroups.com>, "anand" <writeanand@gmail.com> writes: >So in the case, how do real applications actually run (in the customer >environment) when it is downloaded onto an FPGA? The FPGA is connected to real hardware. Start with something simple. Use push-buttons for input and LEDs for output. Can you blink the LED? Can you change the blink pattern when you push the button? A scope on an output pin (or several of them) is a pretty good test case. Most development boards include various IO gear. Take a look at the documentation for the boards you are considering and see what sort of toy you could make. -- 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: 104322
Hi all, I was wondering if anyone would be willing to share their experiences with regards to what can be done when a design containing an EDK submodule fails to meet timing after another IP core has been added to one of the buses? In the latest particular case I added an opb2plb bridge and that broke the timing. The OPB bus already runs at half of the PLB rate, and the PLB rate is 100 MHz. Also, are there any estimates of how many loads can be added to PLB and/or OPB at various rates? Thanks, /MikhailArticle: 104323
Hi, Is it possible to programmatically configure pins of an Spartan3 or 3E as ground signals? I mean, not only configure them as input signals, but as real ground signals connected to the ground signal on another PCB. Regards, JaaCArticle: 104324
Austin Lesea wrote: > Jim, > > No, I have not cracked the Altera chip. I have received emails from > schools and universities who wish to crack it. These are the same > schools that have published successful smart card attacks. > > My quote of $5,000 is what we pay to have a device ground down on the > backside such that we can do analysis on a device. > > For another $5,000, one can get up to three or four FIB cuts, and a > couple of jumper wires. ..and here, you are still a long way from 'get at the IP'.. ? - and rather a world away from your earlier sweeping claims...: <paste classic Austin Arm Waving : > > 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. No, wait, I _can_ see a false and misleading claim :) If you are going to rail against Altera, surely it helps to keep your credibility intact ? -jg
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