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
see other postings in this newsgroup - xilinx online shop doesnt carry any silicon devices any more. AnttiArticle: 102176
Hi all, I use a test fixture to do post-translation simulation on my design. Is there any way to increase the run time while modelsim is running? or after it has finished running? Sometimes I need to extend it to just a few more milliseconds but running it all over again takes about an hour on my machine. Thanks in advance. Subhasri.KArticle: 102177
Perhaps because retiming in Synplify is using a wireload model? Retiming works best when you have accurate delay models, i.e. after P&R (even placement info seems to do the trick). Have a look at Physical synthesis tools, Hans. www.ht-lab.com "srini" <g.shrinivasan@gmail.com> wrote in message news:1147345711.235371.234320@q12g2000cwa.googlegroups.com... > Hi, > I had a strange experience with the Synplify Pro 8.4. I used the > re-timing option thinking that it will help to improve the timing > performance of the design as they have claimed in their docs. But my > design's timing performance has gone down by about 5 Mz and I ended up > not meeting my timing constraints. Why is it so? Can anyone tell me > about this? > > Thanks & Regards, > Srini. >Article: 102178
Also, Be sure you are not using CLK90, 180, 270 CLK2X nor CLK2X_b and CLKDV. Basically if you use any of the DLL outputs, this restriction does apply. Another easy way to tell is if you are not connecting CLKFB, you are OK. If you have connected CLKFB, then the device wants to use the DLL as well as the DFS, and the restriction is back again. Austin Peter Alfke wrote: > Just ignore the warning. You cannot use CLK0, but you are using CLKFX, > and you specified multiply by 3 and divide by 1. > Sometimes these warnings are over-eager... > Peter Alfke >Article: 102179
Martin Thompson schrieb: >>What can a Spartan 3E do what a Spartan 3 can't? > > Configure itself from parallel flash... OK, nice feature. But not the killer. > As Jerry Avins on comp.dsp says: > "Engineering is the art of making stuff you want from stuff you can > get" Yeah, this sounds like the original phrase. Regards FalkArticle: 102180
All, That said, we are not aware of anyone who has ever reverse engineered a Virtex device bitstream (unencrypted). There have been inquiries to vendors 'who do this for a living' and they have refused to quote on anything larger than a Virtex 1000 class (V1000, 2V1000, 2S1000, 2vp7, 3S1000, 3S1200e). It seems that they feel it isn't worth the headaches. Not that it isn't "possible." But then, it is "possible" I could visit the moon. As for once the bit stream has been encrypted (since Virtex II, 6 years and counting), no one has broken it (3DES). And they have been trying. More than one outfit. It is even more unlikely that a direct attack on the newer 256 bit AES encryption with battery backed up keys will also be able to succeed. Austin fpga_toys@yahoo.com wrote: > binaryboy wrote: > >>is it easy to reverse engineer ASIC/FPGA ? >>do u have any reference for this ? > > > Easy is VERY relative to ones experience and resources. The straight > forward answer is that it's probably very very hard for you since you > are asking. For most mortals ASICs are also very very hard as well, and > relatively easy for those that do it every day for a living (requires > some signficant investments in equipment and training). FPGAs with > built in crypto are a little tougher nut to crack, but far easier than > ASICs .... still takes some special equipment but far less work. > Standard FPGA bitstreams for most FPGAs requires a two step process, > first finding the map for the device (which may require reverse > engineering some vendor tools first) then writing a netlist generator > using the map from the bitstream. This requires the least skill, and > can be done by most mortals that understand programming at an > undergraduate level and basic FPGA architecture in somewhere between a > few weeks to a few months for someone fairly bright and skilled, a bit > longer if they have a difficult time playing deductive reasoning games > or lack programming experience. Turning the extracted netlist into a > usable readable design for modification or clean room specification is > fairly linear in time by it size ... which can be significantly reduced > if your reverse engineering tools can "reverse compile" the netlist > into a higher level form, such as good high level VHDL/Verilog or C. > > There are professionals that do reverse engineering for a living ... we > find that the experience from each project greatly helps develop the > skills/experience for the next. > > You might find boomerang on sf.net interesting ... binary ISA streams > are about the same difficulty as unencrypted bitstreams, with the minor > twist that most FPGA bit streams are undocumented, forcing a two step > learning curve. >Article: 102181
ispLever includes all you need. the cable can be made out of wires similarly as xilinx cable III or you may buy a ready made cable for 65 usd or as a better deal machXO starterkit for 99 USD (includes the cable) AnttiArticle: 102182
> Thanks for the info. Is the ISPLever - Starter equivilent to the XIlinx > Webpack? Ditto to what Antti says on ispLEVER Starter plus a couple of links... Yes, ispLEVER Starter is a web downloadable version of ispLEVER for Windows, which you can download here: http://www.latticesemi.com/products/designsoftware/isplever/ispleverstarter.cfm ispLEVER Starter supports the ispMACH 4000V device, among others. > Also what tools do I need for In system Programming? The programming tools are called ispVM, which you can download here: http://www.latticesemi.com/products/designsoftware/ispvmsystem/index.cfm Both downloads are complimentary, but you will need to register for Lattice web account prior to downloading these tools. Regards, Bart Borosky, LatticeArticle: 102183
Marko S wrote: > Thank you all. I will have a look at "Dijkstra's square root". I have 2000 > clock cycles at 40 Mhz to complete the calculation (It should be enough). It > is used for calculating the AM envelop after demodulating the signal with a > coherent detector > > > > You can se the principle of the detector at > http://www.cycom.co.uk/art1.html. > > > > > > "Symon" <symon_brewer@hotmail.com> wrote in message > news:4462fbb4$0$15793$14726298@news.sunsite.dk... > >>"Michael Schöberl" <MSchoeberl@mailtonne.de> wrote in message >>news:4462f354$1@news.fhg.de... >> >>>Marko S schrieb: >>> >>>>How do i calculate sqrt(a^2 + b^2) in synthesizable VHDL? >>>>The signals a and b are 32 bit signed fix point numbers >>>>(std_logic_vector (31 downto 0)). >>> >>>how accurate? how fast? latency? >>> >>>just for the sqrt(x) I once worked an idea to take len=ceil(log_2(x)) by >>>counting the length of x (leading 0s) ... >>>then you shift x>>(len/2) or something (+1?) ... this worked as a good >>>approximation and I added only one or two stages of a newton-raphson >>> >> >>Hi Marko, >>For square root, you could use modified Dijkstra's square root. >> >>http://lib.tkk.fi/Diss/2005/isbn9512275279/article3.pdf >> >>One clock per output bit. No multipliers. >> >>HTH, Syms. >> > > > You aren't really looking for square root, you are looking for vector magnitude. Vector magnitude can be computed without computing the square root. For arbitrary precision, you can use the cordic algorithm in vectoring mode. It basically rotates the vector to the I axis using a series of progressively smaller fixed angle rotations selected so that each elemental rotation is done with a shift and add operation. After rotating the vector the I axis, the magnitude is read directly from the non-zero (I component) of the rotated vector. If you don't need a lot of precision, there are table methods and linear approximations (the most famous is "larger plus half smaller" that will often get you a good enough answer with less computation. Either way, computing magnitude using a square root is going about it the hard way (hardware-wise anyway). For 32 bit arguments, CORDIC is going to be your best bet.Article: 102184
Franco Tiratore wrote: > Hi all. > > I'm currently trying to understand whether or not it is possible to > implement a 802.11a-compliant OFDM modulator/demodulator on an FPGA. > As far as I understand, the critical part of the project is the > 64-point complex FFT with 32 bit floating-point representation (each > real or complex number is represented in 32-bit floating-point). The > FFT block should perform this calculation in no more than 2.5 us. > I'm not an expert in this field, can anyone help me to understand > whether or not this performance is achievable with the FPGAs currently > available on the market? If yes: can you address me to some specific > FPGA model? If not: what is the critical part of my specifications? (I > suppose the time delay and the floating point spec). > > This is only one of my current doubts. > I hope we can start a profitable discussion. :-) > > Ciao, > Franco > Pretty much any of the current FPGA offerings are capable of 64 point FFTs in 2.5 us. For OFDM, there really isn't any need to use floating point. Floating point trades accuracy for dynamic range. In the case of OFDM, you have 64 point FFT, so at most you'll have a growth of 6 bits in your data. Presumably, the data is coming from a DAC through some filters, so the dynamic range of the data coming into the FFT is also not that large. A single precision floating point FFt is going to have a 24 bit data path plus an 8 bit exponent. A 24 bit fixed point data path with no exponents is more than enough for this application. There are FFT cores in the cores offered by the major FPGA vendors. These are not bad considering the price (free). You can obtain considerably higher performance and smaller size from third party IP providers, but it is not free. In any event, you need to look at the entire OFDM receiver, as the FFT is only one block of it, and can be readily found off-the-shelf.Article: 102185
Hi jm, what i try to say is that you can "port" the BFM 7.1 tollkit for use in EDK 8.1. Of course you can use the BFM 7.1 with EDK 7.1 ;). Anyway, you must have access to some BFM toolkit to get BFM models. The BFM toolkit was supplied by xilinx for free for 6.3 and 7.1 (you only have to sign up for the coreconnect suite), so i see no problem if i give the BFM 7.1 toolkit to you, since its not available from the xilinx website any longer. Please contact me directly (mail). Regards Jens jmariano schrieb: > Hi Jens, > > Sorry for the late replay and tanks for your input. I was able to solve > my problem by > simulating my core directly in ISE, but my the problem remains. > > I'm using XPS 7.1, so if I understand correctly, I have to change to > 8.1, to preform BFM > simulation, since the wizard in XPS 7.1 doesn't allows me to do so, > since I don't have the BFM > toolkit installed. > > Regards > > jmArticle: 102186
binaryboy wrote: > is it easy to reverse engineer ASIC/FPGA ? > do u have any reference for this ? It was only ever "easy" maybe 25 years ago or more for full custom VLSI and has gotten progressively harder by Moores law and more so ever since for ASICs. There were (are?) quite a few firms that used do it but the business model has changed. Most DRAMs from different vendors were largely similar because they could all buy "reports" from Mosaid of the design of leading parts. Design engineers liked to know they were at least doing the same sort of thing as the leader, but memories are a special case. It probably helped the consumer to mix different vendor parts without too much fuss. FPGAs another story. This has been discussed many times here if you care to google groups for reverse engineering. JohnArticle: 102187
Austin Lesea wrote: > There have been inquiries to vendors 'who do this for a living' and they > have refused to quote on anything larger than a Virtex 1000 class > (V1000, 2V1000, 2S1000, 2vp7, 3S1000, 3S1200e). I've done code recovery and clean room reverse engineering on and off for software projects, and pld's since the late 1960's. Tools really make the difference. For a large project we did in 1973 it required writing a pretty state of the art high level disassembler for the CDC3100 series to do code recovery for an operating system and major utilities. The whole project including the disassembler was about 9 man months. Another project required taking some dozen large eproms of 386 firmware converting to asm and back to forth. Again it took about two weeks to write the tools, and several weeks to reconstruct the forth code and provide the client with a clean room specification for the system design. If someone came to me wanting code recovery for any sized Virtex series fpga, I don't think that is a problem, would require a modest effort in tools that do not exist today. A clean room specification would take longer, and is linear to application size, as you actually have to understand the design to write it's specification. In general, clean room projects typically run about 15-35% of the original design labor for software projects ... and I suspect a similar range for hardware designs reverse engineered back to verilog or C using a decompiler approach. A Virtext front end for boomerang to FpgaC is probably less than months work, and would require some hand tweeking to handle odd cases of clock edge usage into a verilog module. > It seems that they feel it isn't worth the headaches. Not that it isn't > "possible." But then, it is "possible" I could visit the moon. When the engineering time for a hardware/software project is measured in a few man years, with a burdened cost of $500K and up, then $75-200K for code recovery or a clean room specification of the design can be a cost effective engineering expense to replace an old lost design or jump start a competitive redesign. > > As for once the bit stream has been encrypted (since Virtex II, 6 years > and counting), no one has broken it (3DES). And they have been trying. > > More than one outfit. > > It is even more unlikely that a direct attack on the newer 256 bit AES > encryption with battery backed up keys will also be able to succeed. Crypto attacks don't make sense .... other physical attacks would, if required. Nice big vaults with a shinny armor door are seldom the easiest way into a vault of the locks fail. The cinder block or concrete back wall, ceiling, or floor are probably much easier entry points, and cheaper to repair afterward.Article: 102188
robnstef@frontiernet.net wrote: > I have no use for these items, and if Xilinx doesn't see anything wrong > with me giving a couple to you, I could then mail them. I sincerely appreciate the offer Rob, but unless I'm missing something the devices you mention are older and consequently smaller devices than I really need. I'm looking to target one of the larger vendors devices on a hobbyist budget, and my primary obstacle is the high cost of the design software rather than the FPGAs and development boards themselves. Thanks to John Bass's earlier suggestion about ebay, the cost of the hardware is no longer much of an issue, but if you ever happen to run across an old dusty box labeled "Xilinx ISE Foundation," "Actel Libero Platninum", "Altera Quartus II Standard Edition," or even Lattice Semiconductor's full version of ispLEVER that hasn't yet been "activated", I would surely appreciate a copy of it. Regards, RonArticle: 102189
Austin Lesea wrote: > There have been inquiries to vendors 'who do this for a living' and they > have refused to quote on anything larger than a Virtex 1000 class > (V1000, 2V1000, 2S1000, 2vp7, 3S1000, 3S1200e). You can always "prove" how difficult it is ... follow the RSA example and offer a $20K challenge for reverse engineering an XC4VLX200 design to an HLL that can be modified and recompiled. And maybe $100K for a similar design that is DES locked. Maybe Ron and I would have a lot more fun on those projects :)Article: 102190
Austin Lesea wrote: > There have been inquiries to vendors 'who do this for a living' and they > have refused to quote on anything larger than a Virtex 1000 class > (V1000, 2V1000, 2S1000, 2vp7, 3S1000, 3S1200e). Please send your customers that need code recovery for larger devices to me :)Article: 102191
Ron, I have plenty of older Quartus II versions (4.2 right on up), but its the license file/dongle that I only have one of--sorry. If the Altera Quartus Web edition (free) will allow you to compile, but not generate programming files, for the Stratix families, you can forward me the design and I'll generate the programming files for you. I guess you'll have to trust that I won't steal your design. Rest assured that I would never engage in such an impropriety. But you did mention in one of your posts that you were thinking about making your design open source. Take care, RobArticle: 102192
John, Sure. No problem. If anyone asks, I'll let them know you will consider it. I had gone to get some quotes last year from some houses, and they had 'no bid' after looking at it. Some of these houses advertised that they would do exactly that, and had done so in the past (with a XC4005!). People were asking how difficult it was to do this, and we felt we should find out. Just be careful with your quote. One more word of caution; I have access to the schematics, the bitstream map, and anything else. When we have to reverse engineer a design for a customer (such as "why did the part fail the way it did" in some critical military application) it is still very tough to find which line of HDL was affected by the fault (presuming we even found a fault!). And, I agree that if the front door is solid steel then most attackers look for a less secure means of entry, like an open window. AustinArticle: 102193
Austin Lesea wrote: > Just be careful with your quote. Certainly. Source reconstruction is a pretty high risk contract even in the best cases. The absolute WORST contract I took was to reconstruct the CURRENT sources for 20 cabinets of two year old IBM Cobol that had been maintained online and lost (contract operations center refused to hand sources over when client decided to change vendors, luckily they managed to snarf binaries). Project was a year of painfully finding and fixing every bug and change to those sources during the previous two years by running in parallel with the production binaries for a year till I got it to match line for line. Most of it came up with strainght forward debugging in 3 months ... the last 5% took the rest of the year -- all of 1974. The entire financial and inventory system for a Los Angeles company.Article: 102194
> is there a way to handle some incremental flow with makefiles ..? > I know the process from c-programming ... only modified files > need to compile - but all of them need to be linked ... > could that save some time for FPGAs as well? > the synthezize step only needs to handle modified files ... > as I understand the flow the next step is merging everything (and > optimizing across modules)? I know synplify and xst support incremental synthesis flow, but they do it with user constraints not makefiles. HTH, Jim http://home.comcast.net/~jimwu88/tools/Article: 102195
I am not an expert with ModelSim but I feel this is true with testbenches: The testbench is run out as a script until all its input-output verifications are complete. As such, the run length of a testbench cannot be changed at ModelSim runtime and can only be done by increasing the input-output test vectors in the testbench right at the start. I hope I am able to get that through. I have experienced that ModelSim-XE simulates testbenches of a few microsecond duration quite quickly. So you are probably simulating a duration of a few seconds or more and hence the hour-long running time. You may hence also concetrate on finding ways to simulate only the time interval of interest (I don't know how to do that, though). And yes, if test fixtures are something quite different than testbenches, just ignore this post.Article: 102196
If you are targetting programmable hardware (which you most possible are), you can get IP cores to work for you. Check out opencores.org or Xilinx or Altera websites to find cores that provide functions you need.Article: 102197
fpga_toys@yahoo.com wrote: > And maybe $100K for a > similar design that is DES locked. hmm ... someone asks just how would you attack an encrypted Virtex part? There are two problems, first the key is on the chip being protected with a battery, and second getting to the unencrypted bit stream that passes through the chip at one or more parts. The key to attacking the chip would be to take one or more of the same chip and peel it apart to locate it's basic design, looking for the section of the chip where the 3DES engine is, the bit stream data path, and the muxes which switch the bitstream. Then decide where the best place to probe the clear text point is, and take a couple practice runs on a practice chip. Probing is very likely to require a non-contact solution if you can not easily reach a metalized trace with the clear text bitstream on it. Then the fun part, stripping down a live part on a board with the battery backup intact to preserve the key, and using the knowledge gained on practice parts to uncover the probe point on the target device, and getting it to reconfigure while you tap into the target clear text bit stream. Hopefully you can get your hands on two or three such devices just in case the first attempt has something very bad happen to the target device.Article: 102198
H iRob, Just a quick correction -- our CPLD is MAX II, which is a follow on to our MAX family of CPLDs (MAX7000 and MAX3000 series). Not to be confused with MaxPlus II, which was the design software that preceded Quartus. There's tons of info on these families available on our website (www.altera.com). And you can download a free copy of Quartus II Web Edition to try them out. Regards, Paul Leventis Altera Corp.Article: 102199
Hello Mark, I have done many runs on the actual chip and also the smulation. Here are the major differences that I have noticed and are a possible cause of failure for the actual chip. In the simulation, the transmission line of the UART is at HIGH when NOT transmitting anything, when I provide it with some data value and a write signal, It transmits it and then goes back high again. When the transmission is completed another signal called UART_RDY is asserted and that indicates that I can load in the next data value. In the actual synthesised design, the TX line keeps transmitting some random pattern over and over again, and is not held at HIGH state when I power the chip on. In other words the UART_RDY signal is never asserted, which implies that I cannot load data values from the PCI bus, as it is always waiting for the UART_RDY signal to be asserted. I have very little experience with ASIC/FPGA design, hence I am not able to come up with a way to hold the TX line at HIGH when the chip powers up. I have to stop the TX line from behaving in a random manner so that I can read the UART_RDY signal and then load data values from the PCI bus into it. Please advise. Thank you, Sandeep
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