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
Followup to: <ad6e6988.0409221724.6a610e17@posting.google.com> By author: hardwareengineer@gmail.com (hardwareengineer) In newsgroup: comp.arch.fpga > > My question is...will it lead to synthesis problems if I make the code > work keeping the different clock transitions or should I make all of > them(including the subcomponents) transition on the same edge of the > clock.. > > I am synthesizing to Virtex XC2V 4000 FPGA and am planning to download > the bitstream and show a working proof > Depends on the FPGA you're synthesizing to. Most current FPGAs can clock any particular register either on the positive edge or on the negative edge, but not both. I have not had any problems having some elements clock on the positive edge and some on the negative edge, however, and the timing tools seem to deal with it fine as well. -hpaArticle: 73526
Followup to: <cisjee$t3m$1@newsg4.svr.pol.co.uk> By author: "Brian" <br@br.com> In newsgroup: comp.arch.fpga > > I'm planning on connecting a 3.3V Spartan 2E FPGA to the 5V PCI bus. To > deal with the bidirectional level shifting I was hoping I could just use 100 > ohm resistors. The FPGA datasheet does say that the device is 5V tolerant > if used with 100 ohm resistors. Has anyone any experience of interfacing > 3.3V FPGA's to 5V devices? > > Would using 100 ohm resistors be okay for the bidirectional signals? > > The PCI specification states that the minimum high voltage is 2V, which is > well within the FPGA's 3.3V output. So is it okay to drive the 5V input > signals from the 3.3V FPGA outputs? > Most of the cases I've seen of 3.3 V designs connecting to 5 V PCI have been using quickswitches rather than resistors. See for example Xilinx appnote XAPP646. You can get them quite wide these days, so you don't need too many parts, even. -hpaArticle: 73527
Brian wrote: > > Hi, > > I'm planning on connecting a 3.3V Spartan 2E FPGA to the 5V PCI bus. To > deal with the bidirectional level shifting I was hoping I could just use 100 > ohm resistors. The FPGA datasheet does say that the device is 5V tolerant > if used with 100 ohm resistors. Has anyone any experience of interfacing > 3.3V FPGA's to 5V devices? > > Would using 100 ohm resistors be okay for the bidirectional signals? > > The PCI specification states that the minimum high voltage is 2V, which is > well within the FPGA's 3.3V output. So is it okay to drive the 5V input > signals from the 3.3V FPGA outputs? If you are designing a custom card that won't be sold for general use on the PCI bus, then you might be able to get something like this to work. But the 100 ohm resistor is going to screw up your driving ability and the bus will run slowly. I expect you will need to keep your clock speed much lower than max to allow for the increased rise/fall times. But only calculations and/or simulations will tell for sure. But why not just use the Spartan II parts which, IIRC *are* 5V tolerant??? -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 73528
I don't need to see the transistors, just a signal that they control. That would be in the metal. It may be hard to sort out, but I am sure that is orders of magnitude easier than cracking the key by brute force. Peter Alfke wrote: > > Rick, don't forget, there are ten layers of metal above the transistors that > store the key or the configuration... > Peter A > > >> > > I once learned how to use an electron microscope to probe signals on a > > chip. Once you figure out where the volatile bits are stored, wouldn't > > it be a simple matter to read them out with an electron microscope? > > Just pop the lid and stick the board (assuming it is small enough) under > > the scope. Probe it with a very low beam current and you should be able > > to see which bits are powered and which bits are off. > > > > -- > > > > Rick "rickman" Collins > > > > rick.collins@XYarius.com > > Ignore the reply address. To email me use the above address with the XY > > removed. > > > > Arius - A Signal Processing Solutions Company > > Specializing in DSP and FPGA design URL http://www.arius.com > > 4 King Ave 301-682-7772 Voice > > Frederick, MD 21701-3110 301-682-7666 FAX -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 73529
"Steven K. Knapp" wrote: > > "rickman" <spamgoeshere4@yahoo.com> wrote in message > news:414E7D8D.7C56BCE3@yahoo.com... > > [snip] > > > I have been meaning to send you an email to ask if the Spartan 3s are > > supported for modular reconfiguration yet. How is that going? I seem > > to recall that there were a couple of things that had to be resolved > > before the work could even begin. One was a "bug" or some aspect of the > > ISE software and the other was a work around for the fact that Spartan > > 3s don't have any tristate buffers. Have either of these issues been > > worked? How close are we to having a solution? > > The modular support using bus macros is not supported currently. It is > supported via the "bitgen -r" approach, as described in the following Answer > Record. > > Is partial reconfiguration supported on Spartan-3 devices? > http://support.xilinx.com/xlnx/xil_ans_display.jsp?getPagePath=18416 Unfortunatly I was not trying to do "partial" reconfiguration, but rather "modular" reconfiguration which seems to not be supported according to the answers record. At the time we last discussed this, I thought you had indicated that Xilinx was committed to supporting modular reconfiguration in the Spartan 3 devices. Is that no longer the case? -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 73530
I think you have missed my point. The things you list may be factors to the "important" features of the chips, but they do not solely determine the price, speed, availability, ... There are many other factors to consider, TOO many to make useful comparisons with the factors directly. So it is much better for the users to just compare the user issues. As an example, I was told by a boss that they once got an FPGA vendor to give a design winning quote on a new part before that part was in production. In the short term they sold the older, pin compatible part (Vcore change only) at the *same* low price. So clearly they were not basing their bid on *known* data about yeild, die size or any other technical issues that they had measured. They were banking on their own track record and self confidence, things I can never really measure... except in their quotes. Austin Lesea wrote: > > Rick, > > Good words to live by. > > I am concerned with: > > - quiescent power (which is a direct advantage to some, not all in V4) > - performance in V4 (~5% faster in raw speed at slowest speed grade) > something that is design dependent, and subject to lots of variations, > so it is up to the software folks, and each individual to compare their > design and make their own decision if it is a big item for them > - yield (obviously, if it doesn't yield, it is a moot story for all > concerned). Yield = cost to customer. Better cost, better yield. We > have 1 M units of 90nm shipped in Spartan 3 (today's press release), so > no issues there. > - dynamic power savings (directly benefits almost everyone to have 1/2 > the power and less in hardened block in V4 than in V2P). > > > > This whole discussion in pretty pointless. As you say, a user does not > > care about *how* you make the chips, just how well they work. So when > > Austin and Dave argue about the tradeoffs in each vendor's choice of > > implementations, there is *no* point. The only useful info is (1) how > > much it costs (not even per LUT/SLICE/ALM but the real cost of the chip > > you need to implement *your* design *AFTER* you get through all the > > sales BS a dickering [which the engineer typcially does not get into]), > > (2) how long the lead times are, and (3) how long it takes to get your > > design to run in that part with the available software. > > > > Anything else is just noise... > > -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 73531
Andre Bonin wrote: > Ken McElvain wrote: > >> This loop should compile fine in Synplify. > > > I'me using quartus2. What is synplify? Synplify is a commercial FPGA synthesis tool See: http://www.synplicity.com for details. I'm obviously biased, but I think it is the best FPGA synthesis tool available. - Ken > > >> >> Andre Bonin wrote: >> >>> Hey all, I'me trying to convert a C algorithm to Verilog using >>> Quartus II Web edition. >>> >>> The following for loop doesn't compile because it says its not of >>> constant loop time. >>> >>> What i really need is to be able to calculate the loop time "on the >>> fly". >>> >>> Can VHDL or Verilog do this? or is this a limitation? >>> >>> >>> Thanks >>> Error: Verilog HDL For Statement error at XXXXXXXX.v(49): must use >>> only constant expressions in terminating conditions >>> >>> ---- Error at while loop - >>> integer X = 0; >>> always >>> begin >>> while( X < 30 ) >>> begin >>> X = X + 1; >>> end >>> end >> >> >>Article: 73532
hardwareengineer wrote: > > Hi, > > I am working on a design where there are different components coded by > different people. I am integrating all of these into a single top > module. > > Different components have transitions on different edges of the > clock.For eg: a FIFO in the design waits for the negative edge of the > clock whereas another component waits for the positive edge of the > clock... > > My question is...will it lead to synthesis problems if I make the code > work keeping the different clock transitions or should I make all of > them(including the subcomponents) transition on the same edge of the > clock.. > > I am synthesizing to Virtex XC2V 4000 FPGA and am planning to download > the bitstream and show a working proof Sounds like you had some very poor project management. A top down design phase would have spec'd all the interfaces so that this would not be an issue. The real question is, did they do their designs knowing the clock phasing of the other components? If a pos edge register feeds a neg edge reg (or vice versa), you will only have half a clock cycle for the signals to run through the logic and routing and meet the setup time of the destination register. Otherwise the synthesis software will do exactly what you want and give you logic clocked on what ever edge you spec. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 73533
Synplify internally transforms for loops into while loops for synthesis. Loops (while or for) without event controls can be synthesisized as long as the terminating condition can be determined (this is known as the halting problem). Synplify can figure this out for quite complex loops. In the example, there is a problem with the lack of initialization of the variable X inside the always block that makes it difficult to compute the termination condition. Either type of loop, while or for, can also be synthesized when all paths through the loop are broken by an event control. An event control is the @(posedge clk) refered to below. Andy Peters wrote: > Nicolas Matringe <nicolasmatringe001@numeri-cable.fr> wrote in message news:<414FD415.5080508@numeri-cable.fr>... > >>Andre Bonin a écrit: >> >>>Ken McElvain wrote: >>> >>> >>>>This loop should compile fine in Synplify. >>> >>> >>>I'me using quartus2. What is synplify? >> >>QuertusII doesn't like VHDL while loops. I replaced one with a for loop >>and an exit statement and it worked OK. >>I don't know if it is the same with Verilog while loops though. > > > I haven't used Synplify in ages, but I use Precision all the time. > According to the Precision manual, "Loops must be bounded by constants > or contain [a] @(posedge clk) statement." > > The original poster's code: > > integer X = 0; > always begin > while (X < 30) begin > X = X + 1; > end // while > end // always > > has a couple of problems. First, if one were to simulate this, one > would see that it actually would execute in zero time. How SHOULD > this be implemented in hardware? > > The initializer is ignored (think about it: what's the synthesizer > supposed to do with it?). The while statement isn't bounded like the > usual for loop: > > for (x = 0; x < 30; x = x + 1) begin ... end // > > Note the constants in that for loop, tho'. Say you had: > > integer first, last; > > for (x = first; x < last; x = x + 1) begin > > those values aren't bounded, either, so the synthesizer wouldn't know > what to do with it. > > The manual does say that the two loop conditions are ORed, so it one > modified the original poster's code as follows: > > always @(posedge clk) begin > while (X < 30) begin > X = X + 1; > end // while > end // always > > then one would expect things to "work." (It's a simple incrementer > that stops when it hits the value 30. Not very useful unless it can > be reset!) > > Think hardware ... > > -aArticle: 73534
In ISE Webpack 6.2i, XST (Xilinx Synthesis Technology) supports Verilog-2001 signed operators and datatypes. However, for some reason, it doesn't support $signed and $unsigned. I mention this, because I frequently use the $signed and $unsigned calls to explicitly force type-conversion. I know the Verilog simulator/compiler doesn't care, but I use $signed/$unsigned for documentation and code-readability purposes...(did this guy accidentally or intentionally transfer a signed -> unsigned?!?) (as long as the bitwidths don't change ... otherwise you have to be careful about the sign-extension!) output [16:0] unsigned_y; wire signed [15:0] x, y; wire signed [16:0] sum; wire [16:0] sum; assign sum = x + y; // 2's complement addition! assign unsigned_y = $unsigned(sum); // type-cast! ...... The problem is that ISE 6.2i doesn't support the $signed or $unsigned system-tasks... Is there a workaround for this ... does ISE 6.3i support it? (Or does a planned servicepack add $signed/$unsigned support?)Article: 73535
"H. Peter Anvin" <hpa@terminus.zytor.com> wrote in message news:citb2h$hpr$1@terminus.zytor.com... > Followup to: <ad6e6988.0409221724.6a610e17@posting.google.com> > By author: hardwareengineer@gmail.com (hardwareengineer) > In newsgroup: comp.arch.fpga > > > > My question is...will it lead to synthesis problems if I make the code > > work keeping the different clock transitions or should I make all of > > them(including the subcomponents) transition on the same edge of the > > clock.. > > > > I am synthesizing to Virtex XC2V 4000 FPGA and am planning to download > > the bitstream and show a working proof > > > > Depends on the FPGA you're synthesizing to. Most current FPGAs can > clock any particular register either on the positive edge or on the > negative edge, but not both. > > I have not had any problems having some elements clock on the positive > edge and some on the negative edge, however, and the timing tools seem > to deal with it fine as well. > I recently received such design too, with a FIFO being clocked on the negative edge and the rest on the positive edge. It synthesizes and works fine, but Quartus says it can't achieve the timing goals, whatever speed you enter. But this is a matter of setting up the timing constaints properly I've been told; still have to check that out. JeroenArticle: 73536
I have to disagree a little.... just a little... The occasional marketing guff isn't so much a problem... provide they don't advertise what they are doing today.. and everyday... and they point out they are marketing... so you can take it with a grain of salt. It can be good to get their opinion of why they think they are better... or more importantly.. how they are doing things ... without going thru their usual 20 page marketing fact sheet. But I much prefer Austin's notes from time to time... especially the little tid bits... Simon "Chris Alexander" <info@bostonsemiconductor.com> wrote in message news:376c28cd.0409220408.5da521d7@posting.google.com... > Just so! There is more marketing jive going on here than just from > Altera. Being new to this group, I thought this was a Xilinx only > area until the "infamous posts" showed up. > > I look forward to the technical threads, but the hype from anyone > (including Austin) I skip over. > > One more poster to add to the "skip-over-list". > > "Pete Fraser" <pete@rgb.com> wrote in message > > > > Let's not forget that Austin got things going with the following: > > > . > . > > > > Mr Greenfield certainly escalated things, but with Austin's > > "Bring 'em on" invitation, it's not surprising.Article: 73537
Hi all! My Xilinx Parallel Cable IV was lost during a travel and it needs 5 weeks to receive another from Memec. I need to program a Xilinx Spartan 3 XC3S400 using Boundary-Scan and Prom programming. It is possible in your opinion to realize such a cable by my own? Someone of you knows where I can find a schematic of such a cable or something explaining the functioning of it? Thanks a lot to everybody GuidoArticle: 73538
"Brian" <br@br.com> wrote in message news:cisjee$t3m$1@newsg4.svr.pol.co.uk... > Hi, > > I'm planning on connecting a 3.3V Spartan 2E FPGA to the 5V PCI bus. To > deal with the bidirectional level shifting I was hoping I could just use 100 > ohm resistors. The FPGA datasheet does say that the device is 5V tolerant > if used with 100 ohm resistors. Has anyone any experience of interfacing > 3.3V FPGA's to 5V devices? > > Would using 100 ohm resistors be okay for the bidirectional signals? > > The PCI specification states that the minimum high voltage is 2V, which is > well within the FPGA's 3.3V output. So is it okay to drive the 5V input > signals from the 3.3V FPGA outputs? > > Thanks for any help, > > Thanks for the replies. I'm using an evaluation board, which I'm going to connect to the PCI bus via a prototyping card. My budget doesn't really stretch to getting a new FPGA. The QuickSwitches seem to be only available in surface mount packages, which is no good for me. The card I'm making will only be used by me so using non spec parts is fine. If resistors did the job they would be great. Someone has said that the 5V PCI bus in modern PC's actually uses 3.3V signals. If this is the case, then I may not need any level shifting. I'll measure the PCI voltages later today and post the results here. How can I calculate whether or not the 100 ohm resistors will reduce my clock speeds? Am I right in assuming I need to do a SPICE simulation? If so, can anyone recommend some free SPICE software (Linux is preferable to Windows)? Thanks again.Article: 73539
I also found it helpful to constrain the routing to obtain consistent timing. As Peter mentioned last time, you could also try using the carry chain for delay, and that considerably reduces the variation due to routing differences. /Siva On Wed, 22 Sep 2004, Ray Andraka wrote: > Until you compile it on a different revision of the tools :-O > > In circumstances like this, I find it easier to just instantiate the primitives for > what you want, taking away any room for 'creativity' by the tools. Instantiation > also lets you place the bits so that you can get reasonably consistent timing from > run to run. > > Kevin Neilson wrote: > > > > > >> > > Thanks, guys. I used KEEP and SAVE and had to really fight the tools to > > keep everything from getting pruned and merged, but I finally got it to > > work. > > -Kevin >Article: 73540
Hi, Thank you for the answers. I am talking about the fast async sram manufactured by ISSI on the board. I have following code to read/write to/from async. sram on spartan-3 starter kit. However, it is not working correctly. Does it seem to work ? (then I may trace the bug anywhere else, this code is just a piece of the whole project) or is there a problem on it ? Thanks in advance. Mete ----------------------------------------------------------------- clk is clock input (50Mhz) ub, lb, oe, ce and we are sram control. mdata sram bidirectional data. maddr sram address. udatain user data input. udataout user data output. uaddr user address. addrvalid indicates the address on the uaddr is valid. en indicates this address is for sram. done indicates read or write operation has been completed. -- Uncontrolled Pins lb <= '0'; ub <= '0'; -- Controlled Pins oe <= ctrl_oe; ce <= ctrl_ce; we <= ctrl_we; -- Output Tristate process (ctrl_oe, udatain) begin if (ctrl_oe = '1') then mdata <= udatain; else mdata <= "ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ"; end if; end process; -- Input Latch process (ctrl_oe, mdata) begin if (ctrl_oe = '0') then udataout <= mdata; end if; end process; ----------------------------------------------------------------- ----------------------------------------------------------------- process (state, uaddr) begin case state is when init => ctrl_ce <= '1'; ctrl_oe <= '1'; ctrl_we <= '1'; maddr <= X"00000000"; done <= '0'; when idle => ctrl_ce <= '1'; ctrl_oe <= '1'; ctrl_we <= '1'; maddr <= X"00000000"; done <= '0'; when read => ctrl_ce <= '0'; ctrl_oe <= '0'; ctrl_we <= '1'; maddr <= uaddr; done <= '1'; when write => ctrl_ce <= '0'; ctrl_oe <= '1'; ctrl_we <= '0'; maddr <= uaddr; done <= '1'; end case; end process; ----------------------------------------------------------------- ----------------------------------------------------------------- process (clk, reset, en, addrvalid, rw) begin if (reset = '1') then state <= init; elsif rising_edge(clk) then case state is when init => state <= idle; when idle => if (addrvalid = '1' and en = '0') then if (rw = '1') then state <= read; else state <= write; end if; else state <= idle; end if; when read => state <= idle; when write => state <= idle; end case; end if; end process; -----------------------------------------------------------------Article: 73541
Hello, I am thinking about using a Cyclone FPGA as Cardbus controller. With PCI I know that the Cyclone FPGA is working without problems, but what about the Cardbus specific requirements (or differences to PCI), e.g. power-up current, configuration time, ... Has anybody experiences with it?!??!? Thanks, MarcArticle: 73542
In article <8211d046.0409220228.7220a896@posting.google.com>, abeaujean@gillam-fei.be (A Beaujean) wrote: > When trying to get help thru the HELP button and then the "Online > Documentation' button, Adobe Reader starts and shortly displays a > window saying "There was an error opening this document. The path does > not exist", with no other indication whatsoever. I think this may be because one of the directories (e.g. "Program Files") you installed the software in has a space in it. You'd need to reinstall it somewhere else without any spaces. (This is a dim and distant memory - it may not be correct :-)Article: 73543
In article <41525983.F7389D7E@yahoo.com>, rickman <john@bluepal.net> wrote: >I don't need to see the transistors, just a signal that they control. >That would be in the metal. It may be hard to sort out, but I am sure >that is orders of magnitude easier than cracking the key by brute >force. However, those signals are still buried under 8 layers of metal, in a flip-chip package, with live SRAM cells. In general, the best way is probably "Rubber Hose Cryptanalysis": Find someone at the company who knows the key and beat it out of him. Second best is probably a power and/or EM singnal sidechannel analysis: you monitor the power and the EM emissions, and you have a boost in that you can probably guess a lot of the zeros (known information) based on the target design and its usage, so you have known plaintext/cyptertext pairs with an associated power and EM signature. Somebody would have to DO it (no small feat) but that semes like the best way when dealing with volatile cells. $100k + the challange of it (EG, release a challange board and "You get the key or the data in BlockRAM 0, you get $100k") and it would probably happen. -- Nicholas C. Weaver. to reply email to "nweaver" at the domain icsi.berkeley.eduArticle: 73544
Hi, I notice that each of the Prototype connectors in the Nios Apex Board offer two clock supplies ie. clk_OSC and clk_Apex? Is this to enable any connected peripheral access to the multiplied and unmultiplied clock signals used on board and by the Apex? Also, please confirm this: The signal clk_Apex that is an output of the Apex FPGA is actually the clock signal used by the FPGA. If a clock multiplier is used in the FPGA, then this output would feedback the multiplied clock to the Clock Distributor on the board. The distributor then drives and distributes 5 copies of the fedback signal. Whereas, in the case where a clock multiplier is not used and the Apex uses the clock produced by the Oscillator, the output clk_Apex would essentially feedback the clk_OSC to the Distributor chip. Is this accurate..? Appreciate the help. ThanksArticle: 73545
This is easily possible. There are schematics for the parallel cable III available on the net. You should however additionally put resistors between the input and output of each buffer to provide a hysteresis of a few hundred millivolts. Also, for spartan-3 you must make sure that your series resistors to the fpga are large enough to limit the current to whatever it is the datasheet says. You can not simply supply the buffers with 2.5V because then you will not be able to generate TTL levels for the PC. Because the original parallel cable III did only work with about 2/3 of all PCs, there are a couple of sites on the net that sell improved and less expensive versions. One that explicitely is Spartan-3 compatible is this one: http://shop.trenz-electronic.de/catalog/product_info.php?products_id=46 Kolja Sulimma gvaglia@gmail.com (Guido) wrote in message news:<44f5f440.0409230231.4e64da8c@posting.google.com>... > Hi all! > My Xilinx Parallel Cable IV was lost during a travel and it needs 5 > weeks to receive another from Memec. > I need to program a Xilinx Spartan 3 XC3S400 using Boundary-Scan and > Prom programming. It is possible in your opinion to realize such a > cable by my own? > Someone of you knows where I can find a schematic of such a cable or > something explaining the functioning of it? > Thanks a lot to everybody > GuidoArticle: 73546
Austin, you are probably the right person to answer this question: I made a mistake and now I have a board with a XC3S200FT that has a ramp up time for the 2.5V power supply of only about 300us. That is only about half us much as required by the datasheet. One I/O bank uses 2.5V as VCCIO, the others use 3.3V which has a ramp up time of 600us. Apparently the board is working normally. Can anyone comment on what kind of mishap I could expect because of this? If there is a bad effect that does not happen on the prototype, how will it be triggered on future boards: Temperature? Chip to chip tolerances? Or is the safety margin in the datasheet large enough that I can ignore this? Kolja SulimmaArticle: 73547
Nick, Well, thanks for being the shill in the audience! All, It just so happens we do have a challenge board. Email me directly if you are serious about trying to crack it. The challenge is this: tell us the key, or tell us the unencrypted bitstream, or even a key part of the bitstream, or change the bitstream while still allowing the design to operate (ie add something to it - anything, even load some BRAM or change an IO strength - but it has to be something you intend to change! and can show you did (as we won't be able to tell either unless the effect is observable externally). Or, affect the TRNG in the configuration such that it generates numbers you want it to (ie non-random). I have set the challenges in the order of difficulty from most, to least (woth all of them being unbreakable based on our knowledge and experience. You need to supply your own USB port (ie a personnal computer), and if you are serious, probably a JTAG cable to a system running our design environment (so you can play around). If you lose the key (because you disconnected the battery and power), you can send the unit back to us, and we will rekey it only ONCE for you. Unit is the size of a business card, with a USB port that powers it. There is JTAG access to the part(s) [eprom + fpga]. We supply pcb, and the schematic of the pcb. There is no cash prize like Nick suggests, but I am sure the reputation of cracking it would bring in all the business you could handle. Austin Nicholas Weaver wrote: > In article <41525983.F7389D7E@yahoo.com>, rickman <john@bluepal.net> wrote: > >>I don't need to see the transistors, just a signal that they control. >>That would be in the metal. It may be hard to sort out, but I am sure >>that is orders of magnitude easier than cracking the key by brute >>force. > > > However, those signals are still buried under 8 layers of metal, in a > flip-chip package, with live SRAM cells. > > In general, the best way is probably "Rubber Hose Cryptanalysis": Find > someone at the company who knows the key and beat it out of him. > > Second best is probably a power and/or EM singnal sidechannel > analysis: you monitor the power and the EM emissions, and you have a > boost in that you can probably guess a lot of the zeros (known > information) based on the target design and its usage, so you have > known plaintext/cyptertext pairs with an associated power and EM > signature. > > Somebody would have to DO it (no small feat) but that semes like the > best way when dealing with volatile cells. > > $100k + the challange of it (EG, release a challange board and "You > get the key or the data in BlockRAM 0, you get $100k") and it would > probably happen.Article: 73548
I think I finally got a grip on the legal connections for the LO output on MUXFx primitive objects, but what are the legal connections for the LO outputs on MUXCY and XORCY primitive objects? Does Xilinx have a document somewhere discussing this? It seems mapper does not automatically swap the O to LO to improve timing. Why is that? It seems that XST and Synplify infer about 90% LO and 10% O. I need to know the rules to make my tool do that. Thanks for your time. -- Prepend a 'b' to email me. Thanks.Article: 73549
What's the most efficient way to perform an "equal to zero" operation in a V2 chip? What I've been doing is ANDing all the bits together in a binary tree and relying on the mapper to put that into LUTs correctly. Is this a good way to do it? -- Prepend a 'b' to email me. Thanks.
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