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, I need to place my FPGA designs in a safe platform, and I have some questions: 1. Does anybody know whether Virtex-4 AES bitstream protection has been broken? 2. Do you consider it a good protection? 3. What could a hacker do to overcome this protection, other than brute-force? 4. Are there other alternatives in the market, from other vendors than Xilinx, providing the same or higher level of security? Regards.Article: 129751
On Mar 3, 8:27=A0am, Kolja Sulimma <ksuli...@googlemail.com> wrote: > Hi, > > maybe you folks can help me with a design decision: > > I need to distribute a clock to up to ten identical boards. > The boards are all plugged into a backplane in a single row. > > In addition to the backplane the boards will be connected by > a twinax flatband cable on samtec connectors. For the clock > distribution I can choose between a bus structure cable or a > series of point to point connections between neighbouring boards. > > The leftmost of the identical boards shall provide a clock for all > the other boards. I am now concerned that a bus structure with > that many stubs will have problems maintaining a good signal quality. > > I could instead use point to point connections with fanout clock > buffers on each board to forward the clock to the next board. As far > as the signal quality goes this will obviously work very well, > BUT the boards need a fixed phase relationship. While the absolute > phase is of no importance, the phase must not drift over time or > temperature by more than 50ps or so. Ten buffers in a row would > probably have a larger drift, wouldn't they? > > Any ideas, how I can make a pure passive distribution work in a setup > like that? > > Also: How can I turn on the termination on the last board dynamically? > > Kolja Sulimma Since you're looking at precision timing requirements, you will have issues. Considering that 50ps is about a half centimeter of propagation delay on a PC board, you're already at a loss. If all you want is 50ps of repeatability (and account for the propagation delay as a fixed offset per board), your situation is better but still poor. If you use a standard backplane, do you really believe you can maintain fidelity going backplane to card to backplane to card to backplane to card.... If you had ideal terminations, with ideal connectors, you could achieve your goal. The impedance issues you have traveling through the connectors is probably enough to change the timing of the 2nd card depending on whether the 3rd or 4th (or 10th) cards are plugged in even with appropriate terminations. Buffering is also a problem since every buffer is going to add some noise. With a multiple-output clock buffer, you're still looking at channel matching as an issue. So, consider wandering off to the RF realm. Generate a sinusoidal high-frequency clock. Rather than using a full level signal you can passively split the sinusoid into your desired number of channels at the source or on the backplane and terminate each clock *on the backplane* and use an impedance-matched front end on your cards so they *look* like open circuits to the backplane traces. Alternatively, use one backplane-terminated trace for the sinusoidal clock and do a better job of making the cards look like open circuits to the buffers. In either case, you have added noise from the clock receive buffer on each card. If your cards are identical, you probably want a way to shut off the unused clocks on each destination card. Each card will have an offset from the first card based on the propagation delay across the backplane. The first card will have a different offset still since its clock is received before launching onto the backplane. You have a pretty strenuous requirement but you can eliminate many of the troubles by getting rid of reflections and tuning the receivers to look like open circuits. I once made a power splitter for a 155 MHz sinusoid by using 1-ft lengths of coax and T-connectors. Since two 50-ohm terminated cables teed together look like 25 ohms and 25 ohms across a 50 ohm, quarter wavelength cable looks like 100 ohms to the other side, 2 of these pairs look like 50 ohms when teed together. When properly terminated, each signal was 1/4 power. When I looked at one of the channels on a scope and removed one of the other terminations, the scope signal didn't get larger, it got smaller! It was fun to show people and have them scratch their heads over the situation. I had clean sinusoids in, clean sinusoids out, and used standard RF techniques to deal with stubs and impedances. Fun stuff. Now go off and have fun! - John_HArticle: 129752
Frai, Other than the public announcement that the NSA has approved V4 for single chip crypto systems, what else would you need? Seriously, no one has broken AES256, and no one has broken V4's implementation of AES256 (using the battery backed key memory). A hacker would not attack directly, rather they would wait outside your building, and offer cash to anyone willing to reveal the key to them. No other device exists that is 'generic' approved for all NSA single chip crypto systems. No ASIC, ASSP, nor FPGA. It has been called "completely disruptive technology" and many have told us "V4 will revolutionize the single chip crypto market." http://www.xilinx.com/prs_rls/2007/end_markets/0713_v4nsa.htm I just love it when there is 0 competition! AustinArticle: 129753
On Mar 4, 10:45=A0am, Tricky <Trickyh...@gmail.com> wrote: > On Mar 4, 3:23 pm, FPGA <FPGA.unkn...@gmail.com> wrote: > > > > > > > On Mar 4, 9:12 am, Tricky <Trickyh...@gmail.com> wrote: > > > > On Mar 4, 2:00 pm, FPGA <FPGA.unkn...@gmail.com> wrote: > > > > > On Mar 4, 4:26 am, Tricky <Trickyh...@gmail.com> wrote: > > > > > > On Mar 3, 9:15 pm, FPGA <FPGA.unkn...@gmail.com> wrote: > > > > > > > I have written a process to generate random numbers using UNIFOR= M. I > > > > > > was trying to check the results using "rand" in matlab. How do i= > > > > > > initialise the seed values of both these functions to the same v= alue. > > > > > > I see that the random numbers generated by UNIFORM are different= > > > > > > compared to rand when the seed values are left uninitialised. > > > > > > What do I need to change so that I get same output from both pro= grams. > > > > > > > Thanks > > > > > > Uninitilised positives (the seeds in this case) will take a value = of 1 > > > > > when they are put into the uniform function. Unitialised types whe= n > > > > > used will take type'low as their value > > > > > > positive'low =3D 1 > > > > > std_logic'low =3D 'u' > > > > > etc. > > > > > > so both of your first calls to uniform are seeding it with two 1s.= > > > > > > I dont know how the seeding works in matlab. It may not even use > > > > > positives, but the entire integer range. it is common in C to seed= the > > > > > random number generator with the system time. Does matlab do somet= hing > > > > > similar? The C random function only has 1 seed, whereas uniform ta= kes > > > > > 2. > > > > > I am not sure how the rand function in MATLAB works. I tried to sear= ch > > > > if the code of the function was described anywhere but couldnt find.= > > > > I dont know if we can get MATLAB to generate results as UNIFORM does= . > > > > As you said, uniform has 2 seeds while rand has 1. > > > > If anyone has an idea on how this can be done, please post your > > > > comment. > > > > Why not generate a file containing all the stimulus for the vhdl and > > > matlab model in one or the other, instead of trying to recreate the > > > random sequence?- Hide quoted text - > > > > - Show quoted text - > > > The goal is to check that the VHDL code generates results similar to > > MATLAB . I have written the outputs of both in seperate text files. I > > am not able to initialise the rand function to generate results > > similar to MATLAB and vice versa. Called MATLAB today to get some more > > information on how they have developed the rand function. They said > > that this information is not available to the public. > > I think one of the ways to do this would be, generating a pdf function > > for both cases and showing that their random distriution is similar. > > > If any of you have other ideas please post them. > > In that case, why are you even trying to do this? generate a file from > matlab that is used as the stimulus for the VHDL testbench. Then you > do not need to use the uniform function at all, and then you are > testing that the results match.- Hide quoted text - > > - Show quoted text - I have to use the UNFORM function to check if it behaves in sync with MATLAB. I have given up on getting the same results in matlab as in VHDL. I am just trying to get a pdf plot of both results. No idea on how to do this yet.Article: 129754
> 1. Does anybody know whether Virtex-4 AES bitstream protection has > been broken? Didn't hear anything public ... doesn't mean it hasn't been done ... and even if never done, doesn't mean it can't ... As always with security it depends on the value of what you're protecting. But unless it's a control process for cold fusion, I'd say you're most likely in the clear. > 2. Do you consider it a good protection? Most people do .... so do I :) > 3. What could a hacker do to overcome this protection, other than > brute-force - Bribe someone at the factory to 'listen' when programming the key - Physically break into your office and get the source code or unencrypted bit - Kidnap one of your lead developer's family members and shoot them one by one until he gives you what you want ... (iterate over the whole team as needed) They may all seem 'weird' options ... but that's how I'd do it if I had to ... SylvainArticle: 129755
CTW, This board was used with hardware-in-the-loop with an older SysGen (7.1, maybe?). You can contact your local Avnet FAE and they can get you the files. Bryan cwoodring wrote: > Hi, > Has anyone used this card with Xilinx System Generator to do hardware in > the loop simulation. I can not find a board description file for it in the > form that the System Generator wants. There is a utility in System > Generator called xlSBDBuilder;or something like that helps one create the > needed files to do hardware in the loop simulation over the JTAG, but you > need to know the pinouts of all the ports used on the card. > > If someone has already done this I'd greatly appreciate a copy of the needed > files. > > Thanks, > > CTWArticle: 129756
sdf wrote: > My question: is it possible by Quartus to infer some code into ROM > blocks when it is possible and all the rest let him to make synthesis > using ALUTs? > Or should I manually divide all my ROM-like code to what will inferred > into ROM blocks and that part which will be done usign ALUTs? The short answer: yes. I haven't done it myself, but I do know the Megawizard Plug-in Manager lets you choose whether you want ROM blocks synthesizes as block ram, luts or automatic. Check out the "altera_attribute" help. You should be able to specify on a per-entity basis whether block ram or logic is used to synthesis inferred rom/ram... 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: 129757
On 2=D4=C228=C8=D5, =C9=CF=CE=E710=CA=B148=B7=D6, MikeShepherd...@btinternet= .com wrote: > >Now I want to design aSDcard,for special use,I must use fpga to > >implement the interface between host controller and NAND flash,can > >someone give me some advice if it is easy to implement it?And where I > >can get the controller source files for free,3X. > > You want to design anSDcard??? > > You want to implement the interface between a host controller and NAND > flash? Well, that could make sense, if you're designing anSDcard. > > If you're designing an interface between the host controller and the > NAND flash, why do you need the source files for the controller? > Surely the interface specification is enough? > > Maybe you should slow down a little and say carefully what you're > trying to do. > > Mike Yes,I am desiging an interface between the host controller and the NAND flash,and I want to know how the controller operate.Article: 129758
You might want to also crosspost to comp.arch.fpga. "jtw" <wrightjt @hotmail.invalid> wrote in message news:L9pzj.14674$0o7.10494@newssvr13.news.prodigy.net... > It's probably been over 20 years since I've used Aplus--was it 1984, or > 1985? > > If you can post a snippet of the code, perhaps someone can translate? > > JTW > > "CTSportPilot" <girmann@gmail.com> wrote in message > news:af888fdd-386e-492b-89ee-568bf48e5ea2@e25g2000prg.googlegroups.com... >>I came across an ADF (Altera Desgn Format) file from an Altera EPLD. >> Does anyone out there know of a syntax primer on this dead HDL >> format? For those playing at home, this is an HDL from Altera that >> came with the A+PLUS software. Yes, I can convert it to more modern >> formats, but first I need to understand it. >> >> TIA! > >Article: 129759
On Mar 3, 4:16 pm, DJ Delorie <d...@delorie.com> wrote: > Antti <Antti.Luk...@googlemail.com> writes: > > 2) devices packages like Spartan-3E (including QN132 !) or better > > (microBGA 6x6 mm?) > > I keep wondering if there's a market for a few "unbalanced" devices, > like something with a ton of gates but in a tqfp-64 package. Or BGA > packages that only use the two outer rows for signals, for simpler > board routing. Hey, I'd be happy with pretty much *any* FPGA in a small leaded package, even a 100 pin TQFP. I am doing a current job with the Lattice XP family because it is the *only* FPGA available in a 100 pin QFP. They have exactly one size, the 3000 LUT part which is the smallest in the family. Fortunately there is little chance I will need a larger part. But on the other hand, I won't be able to consider anything fancy for this project because of this limitation. Of course, I could consider a no lead package such as a BGA, but for the most part they are much more expensive, as much as anything, because they have lots more pins. > Likewise, I'd like to see the occasional MCU with a ton of ram and a > little flash, rather than the other way as it usually is. Every once > in a while I need a smart buffer chip :-( I think there is an Atmel ARM part which has a huge amount of RAM although I want to say the flash is external, but it might be a dual die approach with both in the same package. It is one of their older parts and I expect it will only run at 33 MHz.Article: 129760
On Mar 3, 4:42 pm, Antti <Antti.Luk...@googlemail.com> wrote: > On 3 Mrz., 22:16, DJ Delorie <d...@delorie.com> wrote: > > > Antti <Antti.Luk...@googlemail.com> writes: > > > 2) devices packages like Spartan-3E (including QN132 !) or better > > > (microBGA 6x6 mm?) > > > I keep wondering if there's a market for a few "unbalanced" devices, > > like something with a ton of gates but in a tqfp-64 package. Or BGA > > packages that only use the two outer rows for signals, for simpler > > board routing. > > > Likewise, I'd like to see the occasional MCU with a ton of ram and a > > little flash, rather than the other way as it usually is. Every once > > in a while I need a smart buffer chip :-( > > oh yes, TQFP48 0.5mm pitch FPGA running from single voltage! > defenetly, but hey thats wish for new Lattice device ;) > > BTW, Actel QFN132 3 row QFN 0.5mm pitch CAN be used on > 2 layer PCB or even single layer. > > Antti I have not looked very hard at the 132 pin QFN package. But at 0.5 mm pin pitch, how exactly do you route signals from the middle row out? I guess the pins are actually 1.5 mm pitch on each row for 0.5 mm considering all three rows? One of the problems I have using 0.65 mm pitch QFPs is that I can't route between the pins. That is a real PITA. I sometimes think I would be better off with a wider pitch part, but I'm not sure I can fit them on the board... :^(Article: 129761
On Mar 3, 5:08 pm, n...@puntnl.niks (Nico Coesel) wrote: > "M.Randelzhofer" <techsel...@gmx.de> wrote: > >"Antti" <Antti.Luk...@googlemail.com> schrieb im Newsbeitrag > >news:467475ec-6d16-4789-acec-07d3c1a4977e@s19g2000prg.googlegroups.com... > >> here it is: > > >> 1) devices densities like in Spartan-3 (50..5000) > >> 2) devices packages like Spartan-3E (including QN132 !) or better > >> (microBGA 6x6 mm?) > >> 3) all good features of S3A/AN !! > >> 4) design security with OTP encryption key (like Lattice ECP2) > >> 5) other features as already planned by Xilinx > > >> Antti > >> has made his Christmas wish this year... or did I just describe > >> Lattice XP3 or Cyclone IV? > >> eh, I just wish Spartan-4 will have all the good things from Spartan-3 > >> subfamilies+extra goodies. > > >Hi Antti, > > >I've the same wishes, some additional i/O & memory cores would be nice: > > >6) USB2 host/slave interface with integrated PHY > > >7) Ethernet MAC + PHY > > >8) DDR2/3 core > > >9) some analog stuff (ADC, temp sensor, system supervisor) > > >S4 would be a serious competitor to 32bit microcontrollers, if some of their > >standard peripherals are included in low price FPGA's. > > You forget a standard ARM core, some internal flash (say 32KB to > 256KB), some memory (8KB to 64KB) and some standard pheripherals like > UART, SPI, I2C. Such a device would be a real killer. I would design > it in straight away if it existed today for a Spartan price. I thought you could get all that in an MCU? At that point do you even need the FPGA anymore??? After I had presented to the customer my approach using an FPGA do handle the data path for a simple board which had some standard and non standard interfaces, I found out about an ADI part which is a DSP combined with a high resolution Codec. I didn't look at it really hard, but at first glance, it looks like it could have been as good of a solution and a bit cheaper than the FPGA + codec. I will say I prefer writing VHDL to coding DSPs though. The toolsets tend to be cheaper too. But I have to say the DSP approach looks pretty good.Article: 129762
rickman <gnuarm@gmail.com> writes: > Hey, I'd be happy with pretty much *any* FPGA in a small leaded > package, even a 100 pin TQFP. There are plenty of Spartans in QFP packages, as well as other vendors... http://www.digikey.com/scripts/DkSearch/dksus.dll?Cat=2556262;keywords=fpga%20qfp;stock=1 > I think there is an Atmel ARM part which has a huge amount of RAM > although I want to say the flash is external, but it might be a dual > die approach with both in the same package. It is one of their > older parts and I expect it will only run at 33 MHz. The MCUs I'm working with are 20MHz, 24k flash and 2k ram. I think it would be interesting to see one with 2k flash and 24k ram, for example.Article: 129763
On Mar 3, 2:20 pm, sky46...@trline5.org wrote: > rickman <gnu...@gmail.com> wrote: > >On Mar 2, 7:19 pm, wmwmur...@gmail.com wrote: > >> On Mar 2, 3:15 pm, sky46...@trline5.org wrote: > > >> > wmwmur...@gmail.com wrote: > >> > >FPGA/CPLD group onLinkedIn > >> > > http://www.linkedin.com/e/gis/56713/3CC3BF77FD22 > >> > >Group for People Involved In the Design and Verification of FPGA's and > >> > >CPLD's to Exchange Idea's and Techniques. You should have FPGA/CPLD > >> > >Design/Verification on your Profile to Join. (The focus is more on > >> > >FPGA/CPLD in the product as opposed to FPGA's solely as a path to an > >> > >ASIC) > > >> > I prefer NNTP over webbforums that is pumped full of the latest webb-fad from > >> > the webmaster. Thread structure often missing. > > >> The one big advantage is that joining the group allows one to search > >> the members CV's and look for a few people to ask for a one-on-one > >> answer to something that they are familiar with. It also allows one > >> to build contacts in an area of interest, that one might not otherwise > >> meet. Hope this helps with why I started the group. There are other > >> reasons to join beyond this as well -- will save for later -- both > >> NNTP, andLinkedIncan be useful tools > > Usenet seem to attract people with more solid knowledge. Also getting trapped > in the get-the-latest-webb-browser race seems like a time waste. LinkedIn does hit the WebBrowser pretty hard, but seems to do OK in the later versions of Firefox, and there is a Mobile version too, Another nice aspect to LinkedIn, is that it does let one do some background research on a company/group/person BEFORE taking on a design -- nice things to know that one does not talk about on NNTP -- Do they breach their contracts?, Do they pay on time?, Do they break health/safety/environment regulations?, How are their PS&L Claims?, etc,etc,etc........Article: 129764
On Mar 4, 11:22 am, Antti <Antti.Luk...@googlemail.com> wrote: > On 3 Mrz., 23:08, n...@puntnl.niks (Nico Coesel) wrote: > > > > > "M.Randelzhofer" <techsel...@gmx.de> wrote: > > >"Antti" <Antti.Luk...@googlemail.com> schrieb im Newsbeitrag > > >news:467475ec-6d16-4789-acec-07d3c1a4977e@s19g2000prg.googlegroups.com... > > >> here it is: > > > >> 1) devices densities like in Spartan-3 (50..5000) > > >> 2) devices packages like Spartan-3E (including QN132 !) or better > > >> (microBGA 6x6 mm?) > > >> 3) all good features of S3A/AN !! > > >> 4) design security with OTP encryption key (like Lattice ECP2) > > >> 5) other features as already planned by Xilinx > > > >> Antti > > >> has made his Christmas wish this year... or did I just describe > > >> Lattice XP3 or Cyclone IV? > > >> eh, I just wish Spartan-4 will have all the good things from Spartan-3 > > >> subfamilies+extra goodies. > > > >Hi Antti, > > > >I've the same wishes, some additional i/O & memory cores would be nice: > > > >6) USB2 host/slave interface with integrated PHY > > > >7) Ethernet MAC + PHY > > > >8) DDR2/3 core > > > >9) some analog stuff (ADC, temp sensor, system supervisor) > > > >S4 would be a serious competitor to 32bit microcontrollers, if some of their > > >standard peripherals are included in low price FPGA's. > > > You forget a standard ARM core, some internal flash (say 32KB to > > 256KB), some memory (8KB to 64KB) and some standard pheripherals like > > UART, SPI, I2C. Such a device would be a real killer. I would design > > it in straight away if it existed today for a Spartan price. > > > -- > > Programmeren in Almere? > > E-mail naar nico@nctdevpuntnl (punt=.) > > well, Xilinx already own ARM IP-Core license, when Xilinx purchased > Triscend > they also got the IP licenses ownded by Triscend what included also > ARM. > > so it is possible that the ARM core see new life in Spartan-4, > Xilinx has no extra royalty to pay Yes, anything is possible. I might even win the Powerball... no, I don't buy tickets... So far, Xilinx has given no indication that they bought Triscend for any reason other than to keep ARM out of the FPGA market. Just like so many other companies that Xilinx bought and deleted, the purpose seems to have been to bury the technology rather than to develop it. Xilinx seems to have a strong opinion that CPU hard cores do not mesh well with FPGAs as it creates too many combinations of RAM, FPGA size and package so that the number of parts blooms to unmanageable numbers. But then Xilinx has a history of making a firm stand on a point and later reversing themselves when *they* think conditions are different. Meanwhile other companies eat their lunch for a bit while they are still making their stand. Embedded memory is one example. Xilinx was one of the last companies to add that to the FPGA. Later the integrated hard logic block was another reversal. I wonder if their line in the sand against Flash FPGAs will be another soon to happen reversal. When the focus on getting the most logic on a die for the lowest price was the main FPGA goal, the anti-Flash opinion sounded good. But I think the density is high enough now that there are tons of applications that will benefit from having the Flash integrated on the die even if there is a die size penalty due to the lagging process technology. Rather like the way that Intel and AMD can't figure out what to do with all the transistors on a die, so they are adding more and more copies of the CPUs, at some point FPGAs will have more than enough LUTs for most apps and other features will become the main selection criteria. It may not be the Spartan iv, but sometime soon, there will be a combo chip with a right sized FPGA, various peripherals (ones that make sense as a hard core rather than a soft one) and on die Flash memory, both as configuration and program storage for an integrated CPU. Isn't it ST Micro that has the Spear which is an ARM with bells and whistles including a metal programmable gate array? That is just one step away from having an on die FPGA... I would be willing to bet the only thing that stopped them from using an FPGA instead of a metal programmed part was patents... you know, the ones that Triscend had and now are buried in the vaults at Xilinx. I can see a guy pushing a dolly into an endless warehouse as the camera pulls back to show the mountains of buried IP... Maybe Xilinx was concerned that ARM might prove them wrong?!!Article: 129765
On 5 Mrz., 05:45, rickman <gnu...@gmail.com> wrote: > On Mar 3, 4:42 pm, Antti <Antti.Luk...@googlemail.com> wrote: > > > > > On 3 Mrz., 22:16, DJ Delorie <d...@delorie.com> wrote: > > > > Antti <Antti.Luk...@googlemail.com> writes: > > > > 2) devices packages like Spartan-3E (including QN132 !) or better > > > > (microBGA 6x6 mm?) > > > > I keep wondering if there's a market for a few "unbalanced" devices, > > > like something with a ton of gates but in a tqfp-64 package. Or BGA > > > packages that only use the two outer rows for signals, for simpler > > > board routing. > > > > Likewise, I'd like to see the occasional MCU with a ton of ram and a > > > little flash, rather than the other way as it usually is. Every once > > > in a while I need a smart buffer chip :-( > > > oh yes, TQFP48 0.5mm pitch FPGA running from single voltage! > > defenetly, but hey thats wish for new Lattice device ;) > > > BTW, Actel QFN132 3 row QFN 0.5mm pitch CAN be used on > > 2 layer PCB or even single layer. > > > Antti > > I have not looked very hard at the 132 pin QFN package. But at 0.5 mm > pin pitch, how exactly do you route signals from the middle row out? > I guess the pins are actually 1.5 mm pitch on each row for 0.5 mm > considering all three rows? One of the problems I have using 0.65 mm > pitch QFPs is that I can't route between the pins. That is a real > PITA. I sometimes think I would be better off with a wider pitch > part, but I'm not sure I can fit them on the board... :^( its 0.5mm pitch. middle row pins can not be used on 2 layer PCB only outer and inner row. my application did not need much IO so that was sufficient AnttiArticle: 129766
FWIW, Brian, thanks for your input. I could solve this map issue by disabling global optimization when building the IP block to be exported. Once the IP is inserted in the destination design, global_opt can be enabled again, if needed. -P@ brian.jackson@xilinx.com wrote: > Hello Pat, > > We have seen similar map issues in the past when sending large amounts > of LOC constraints via a UCF file to ISE. We've made some improvements > in both 10.1 ISE and PlanAhead to address them. Rather than just > passing LOC constraints, we've seen a much better success rate when > passing both LOC and BEL constraints. Therefore, in 10.1 release of > PlanAhead, we've defaulted both the Export IP and Export Pblock > commands to include both types of constraints in the UCF. The map > group has also fixed quite a few of these types of logic packing > scenarios that cause packing failures. > > I'm not sure what version of PlanAhead you are using, but the latest > 9.2 versions will output BEL constraints. If you are using 9.2, we'd > like to try it using 10.1 PlanAehad and ISE. It would be helpful if > you could file a bug against PlanAhead with the design data. If we > duplicate it here, it will be filed as a bug against the map tool. > > The other option is to strip out the 105 lines in question from the > UCF file. We find that the mapper with usually just put them back in > the same locations anyhow??? > > Please fell free to contact me directly to help resolve the issue. > > Brian Jackson > Marketing Manager, Xilinx > 720-652-3102 > > > On Feb 23, 10:17 am, PatC <p...@patocarr.com> wrote: >> Hi, >> >> I'm trying to insert an IP core generated by PlanAhead into our >> script-based flow, but map fails with Pack:679 error on several slices. >> >> The IP in question is a wrapper around the PCIe block plus, that >> contains our DMA engine. This component is pretty big and we decided to >> lock it down when we deliver the sources to our customers. Using >> PlanAhead, we intend to floorplan it tightly and lock its placement so >> the customer won't have timing issues. >> >> The exported IP is in the edn/ucf form, and it's imported into our xst >> flow without problems. I gutted the top level of the component and made >> it a black box. Xst and ngdbuild run without problems. Both transform >> the edn into an ngo. I also concatenated the system ucf to the component >> ucf and fixed the relative paths. >> >> Map fails with 105 error 679, and over 3 thousand warnings (some >> expected). Different runs give different results though. >> >> "Unable to obey design constraints (LOC=SLICE_X46Y115) which require the >> combination of the following symbols into a single SLICEL component" >> ... (snip - see below) >> "The clock enable signals don't agree. Please correct the design >> constraints accordingly." >> >> Looking at the SLICEL in PlanAhead, I see six symbols (3 LUTs, 3 FLOPs) >> and a seventh one that doesn't seem related to the others. Perhaps this >> is the one "clock enable" referred to in the error message. >> >> Also, doubting of the import-into-my-flow procedure, I made another PA >> project, where I import this same IP into the netlist, and it fails with >> the same errors. >> >> Has anybody seen this error? The answer records show some similar >> errors, but no explanation on how to work around it/fix it. >> >> Thanks in advance, >> -Pat >> >> Error Message: >> ------------------------------ >> ERROR:Pack:679 - Unable to obey design constraints (LOC=SLICE_X46Y115) >> which require the combination of the following symbols into a single >> SLICEL component: >> LUT symbol >> "ii_pci_express_interface/application_reg_file/mmux_ctl_reg_o_sig_60_mux00003 >> 11" (Output Signal = >> ii_pci_express_interface/application_reg_file/ctl_reg_o_sig_60_mux0000[8]) >> LUT symbol >> "ii_pci_express_interface/application_reg_file/mmux_ctl_reg_o_sig_60_mux00003 >> 21" (Output Signal = >> ii_pci_express_interface/application_reg_file/ctl_reg_o_sig_60_mux0000[9]) >> LUT symbol >> "ii_pci_express_interface/application_reg_file/mmux_ctl_reg_o_sig_62_mux00003 >> 11" (Output Signal = >> ii_pci_express_interface/application_reg_file/ctl_reg_o_sig_62_mux0000[8]) >> FLOP symbol >> "ii_pci_express_interface/application_reg_file/ctl_reg_o_sig_60_8" (Output >> Signal = ctl_reg<;60><;8>) >> FLOP symbol >> "ii_pci_express_interface/application_reg_file/ctl_reg_o_sig_60_9" (Output >> Signal = ctl_reg<;60><;9>) >> FLOP symbol >> "ii_pci_express_interface/application_reg_file/ctl_reg_o_sig_62_8" (Output >> Signal = ctl_reg<;62><;8>) >> The clock enable signals don't agree. Please correct the design >> constraints accordingly. >Article: 129767
On Feb 29, 3:21=A0pm, "comp.arch.fpga" <ksuli...@googlemail.com> wrote: > On 27 Feb., 10:42, harisr...@gmail.com wrote: > > > Hello Techies, > > I would like to use an off the shelf FPGA which I would be develpoing > > to test an ASIC or other FPGA. My questions is, > > 1. How do we connect the Output of FPGAs as Input of the ASIC and vice > > versa? > > 2. The FPGA has to check various protocols like SPI, UART and other > > things? > > > I need to know various methods by which this can be done. Any answers > > on this will be greatly apprecaited. > > Jokes aside: You should first find out, how to connect an asic to an > asic > and how to connect an FPGA to an FPGA. Mabye you can deduce the answer > to that question from that. > > Maybe you can find an example design that uses more than one chip and > see > how the connections are created. > > Here are some examples of how ASICs can be connected: > 1. Opticalhttp://www.eetimes.com/news/design/showArticle.jhtml;jsessionid= =3DPA2UO... > > 2. AC couplinghttp://www.ece.ncsu.edu/erl/html2/papers/paulf/2003/paulf_20= 03_09_fra... > > 3. + 4. + 5. > 3D stacking > Free Space Optical Interconnects > Radio Couplinghttp://www.eetimes.com/conf/iedm/showArticle.jhtml?articleID= =3D18306693... > > Kolja Sulimma Thanks a lot Kolja. I really appreciate your answers and will check the kinks you have provided. Regards HariArticle: 129768
Hi All, I want to implement a BERT test on FPGA. Can anyone give or point me to some good documentation for understanding how BERT test works? Thanks.Article: 129769
As Xilinx says in their documents, there is no unbreakable security. I guess if Virtex-4 security is based on the AES algorithm and a secret key, the way to break the security would be to play with the implementation of AES in the FPGA, through manipulation of the encrypted bitstream, probably combining it with a timing attack or any other sort of attack that could eventually make the AES algorithm work in the wrong way, exposing some exploits that might be used for further attacks. This would be cheap and can be easily automated, although it would probably take long and might fail. If this or any similar attack were successful, all designs that reside in a Virtex-4 FPGA would be exposed to hackers. Anyway, from the conceptual point of view, I agree that Virtex-4 level of security is fairly good. If you don't need in-field reconfiguration of the FPGA, the Actel Pro- Asic approach to security might be safer than Xilinx Virtex-4, since it does not let you play with the bitstream. This gives less tools for hackers to play with, making it very difficult for cheap attacks. Some expensive and time-consuming attacks might be possible, but this would only expose one design from one client, rather than all designs residing in Pro-Asic FPGAs around the world. Just a thought... Regards.Article: 129770
Hi, I test the EDK 9.2 MicroBlaze Tutorial (http://www.xilinx.com/support/techsup/tutorials/92_MB_Tutorial.pdf) for my Spartan3e Starter Board Rev.D using XPS 9.2.02i. After the bitsream is uploaded, the TestApp_memory is started and got on rs232: -- Entering main() -- Starting MemoryTest for DDR_SDRAM: Running 32-bit test...FAILED! Running 16-bit test...FAILED! Running 8-bit test...FAILED! -- Exiting main() -- I know, there was a problem using the MIG for this board. Is this my problem? and is it solved now? Thanks, OlafArticle: 129771
On 4 Mrz., 18:55, John_H <newsgr...@johnhandwork.com> wrote: > On Mar 3, 8:27 am, Kolja Sulimma <ksuli...@googlemail.com> wrote: > The impedance issues > you have traveling through the connectors is probably enough to change > the timing of the 2nd card depending on whether the 3rd or 4th (or > 10th) cards are plugged in even with appropriate terminations. That would be OK. I only need repeatability over time and temperature. Different setups can have different skews. Even two identical setups can have different skews. The skew only leads to a shift of the resulting image. That can be calibrated (or even ignored in many cases) But if I start accumlating an image today and run the experiment for a week any shift in skew during that time will smear the image. > Buffering is also a problem since every buffer is going to add some > noise. With a multiple-output clock buffer, you're still looking at > channel matching as an issue. > > So, consider wandering off to the RF realm. Generate a sinusoidal > high-frequency clock. Rather than using a full level signal you can > passively split the sinusoid into your desired number of channels at > the source or on the backplane and terminate each clock *on the > backplane* and use an impedance-matched front end on your cards so > they *look* like open circuits to the backplane traces. > Alternatively, use one backplane-terminated trace for the sinusoidal > clock and do a better job of making the cards look like open circuits > to the buffers. In either case, you have added noise from the clock > receive buffer on each card. > > If your cards are identical, you probably want a way to shut off the > unused clocks on each destination card. > > Each card will have an offset from the first card based on the > propagation delay across the backplane. The first card will have a > different offset still since its clock is received before launching > onto the backplane. > > You have a pretty strenuous requirement but you can eliminate many of > the troubles by getting rid of reflections and tuning the receivers to > look like open circuits. > > I once made a power splitter for a 155 MHz sinusoid by using 1-ft > lengths of coax and T-connectors. Since two 50-ohm terminated cables > teed together look like 25 ohms and 25 ohms across a 50 ohm, quarter > wavelength cable looks like 100 ohms to the other side, 2 of these > pairs look like 50 ohms when teed together. When properly terminated, > each signal was 1/4 power. When I looked at one of the channels on a > scope and removed one of the other terminations, the scope signal > didn't get larger, it got smaller! It was fun to show people and have > them scratch their heads over the situation. I had clean sinusoids > in, clean sinusoids out, and used standard RF techniques to deal with > stubs and impedances. Fun stuff. A standing wave came up during discussion here. The problem is, that this is very difficult for varying number of boards. I would rather not stock ten completely different, length matched cable setups. Thank you for your comments. KoljaArticle: 129772
Hi, I have a design for a custom made board with Spartan 3 xc3s1000 on it. There is a SATA controller on the same board. Since this SATA controller uses PCI interface to communicate to the outer world, I have used opencores PCI bridge inside FPGA to communicate with SATA controller. The synthesized design works fine however I do get some initialization errors at startup. It seems more like a timing problem to me. When analyzed critically, I observed that many of the timing constraints are being ignored by the synthesis tool (ISE 7.1i and ISE 9.2i). I have multiple clocks in my design and there are clock crossing domains. I have marked those domaing and TIGed them in the UCF. I am suspecting that the problem that I am facing is becuase of these ignored timing constraints. The portion of the UCF file where these timings contraints are written is pasted below. ======================================= INST "AD<0>" TNM = "PCI_AD"; INST "AD<1>" TNM = "PCI_AD"; INST "AD<2>" TNM = "PCI_AD"; INST "AD<3>" TNM = "PCI_AD"; INST "AD<4>" TNM = "PCI_AD"; INST "AD<5>" TNM = "PCI_AD"; INST "AD<6>" TNM = "PCI_AD"; INST "AD<7>" TNM = "PCI_AD"; INST "AD<8>" TNM = "PCI_AD"; INST "AD<9>" TNM = "PCI_AD"; INST "AD<10>" TNM = "PCI_AD"; INST "AD<11>" TNM = "PCI_AD"; INST "AD<12>" TNM = "PCI_AD"; INST "AD<13>" TNM = "PCI_AD"; INST "AD<14>" TNM = "PCI_AD"; INST "AD<15>" TNM = "PCI_AD"; INST "AD<16>" TNM = "PCI_AD"; INST "AD<17>" TNM = "PCI_AD"; INST "AD<18>" TNM = "PCI_AD"; INST "AD<19>" TNM = "PCI_AD"; INST "AD<20>" TNM = "PCI_AD"; INST "AD<21>" TNM = "PCI_AD"; INST "AD<22>" TNM = "PCI_AD"; INST "AD<23>" TNM = "PCI_AD"; INST "AD<24>" TNM = "PCI_AD"; INST "AD<25>" TNM = "PCI_AD"; INST "AD<26>" TNM = "PCI_AD"; INST "AD<27>" TNM = "PCI_AD"; INST "AD<28>" TNM = "PCI_AD"; INST "AD<29>" TNM = "PCI_AD"; INST "AD<30>" TNM = "PCI_AD"; INST "AD<31>" TNM = "PCI_AD"; TIMEGRP "PCI_AD" OFFSET = IN 7 ns BEFORE "CLK_66"; TIMEGRP "PCI_AD" OFFSET = OUT 11 ns AFTER "CLK_66"; INST "CBE<0>" TNM = "PCI_CBE"; INST "CBE<1>" TNM = "PCI_CBE"; INST "CBE<2>" TNM = "PCI_CBE"; INST "CBE<3>" TNM = "PCI_CBE"; TIMEGRP "PCI_CBE" OFFSET = IN 7 ns BEFORE "CLK_66"; TIMEGRP "PCI_CBE" OFFSET = OUT 11 ns AFTER "CLK_66"; NET "DEVSEL" OFFSET = IN 7 ns BEFORE "CLK_66"; NET "DEVSEL" OFFSET = OUT 11 ns AFTER "CLK_66"; NET "FRAME" OFFSET = IN 7 ns BEFORE "CLK_66"; NET "FRAME" OFFSET = OUT 11 ns AFTER "CLK_66"; NET "SATA_GNT" OFFSET = IN 10 ns BEFORE "CLK_66"; NET "IRDY" OFFSET = IN 7 ns BEFORE "CLK_66"; NET "IRDY" OFFSET = OUT 11 ns AFTER "CLK_66"; NET "PAR" OFFSET = IN 7 ns BEFORE "CLK_66"; NET "PAR" OFFSET = OUT 11 ns AFTER "CLK_66"; NET "PERR" OFFSET = IN 7 ns BEFORE "CLK_66"; NET "PERR" OFFSET = OUT 11 ns AFTER "CLK_66"; NET "SATA_REQ" OFFSET = OUT 12 ns AFTER "CLK_66"; NET "SERR" OFFSET = OUT 11 ns AFTER "CLK_66"; NET "STOP" OFFSET = IN 7 ns BEFORE "CLK_66"; NET "STOP" OFFSET = OUT 11 ns AFTER "CLK_66"; NET "TRDY" OFFSET = IN 7 ns BEFORE "CLK_66"; NET "TRDY" OFFSET = OUT 11 ns AFTER "CLK_66"; NET "SATA_IDSEL" OFFSET = IN 7 ns BEFORE "CLK_66"; ###################################################################################################### NET "CLK_125" TNM_NET = "CLK_125"; TIMESPEC "TS_CLK_125" = PERIOD "CLK_125" 8 ns HIGH 50 %; NET "CLK_66" TNM_NET = "CLK_66"; TIMESPEC "TS_CLK_66" = PERIOD "CLK_66" 14 ns HIGH 50 %; NET "uc_clk" TNM_NET = "uc_clk"; TIMESPEC "TS_uc_clk" = PERIOD "uc_clk" 1000 ns HIGH 50 %; NET "tx_clk" TNM_NET = "tx_clk"; TIMESPEC "TS_tx_clk" = PERIOD "tx_clk" 40 ns HIGH 50 %; NET "rx_clk" TNM_NET = "rx_clk"; TIMESPEC "TS_rx_clk" = PERIOD "rx_clk" 40 ns HIGH 50 %; #################### # Domains Created #################### # domain_clk_33 # domain_clk_uc # domain_clk_adc # domain_clk_66 # domain_emac_clk_rx # domain_emac_clk_tx NET "uc_clk" TNM_NET = "domain_clk_uc"; NET "CLK_66" TNM_NET = "domain_clk_66"; NET "CLK_33" TNM_NET = "domain_clk_33"; #NET "CLK_125" TNM_NET= "domain_clk_125" NET "CLK_ADC" TNM_NET = "domain_clk_adc"; NET "tx_clk" TNM_NET = "domain_clk_tx"; NET "rx_clk" TNM_NET = "domain_clk_rx"; TIMESPEC "TS_clk_uC_to_clk_66" = FROM "domain_clk_uc" TO "domain_clk_66" TIG; TIMESPEC "TS_clk_uC_to_clk_33" = FROM "domain_clk_uc" TO "domain_clk_33" TIG; #TIMESPEC "TS_clk_uC_to_clk_125" = FROM "domain_clk_uc" TO "domain_clk_125" TIG TIMESPEC "TS_clk_uC_to_clk_adc" = FROM "domain_clk_uc" TO "domain_clk_adc" TIG; TIMESPEC "TS_clk_uC_to_clk_tx" = FROM "domain_clk_uc" TO "domain_clk_tx" TIG; TIMESPEC "TS_clk_uC_to_clk_rx" = FROM "domain_clk_uc" TO "domain_clk_rx" TIG; TIMESPEC "TS_clk_66_to_clk_uc" = FROM "domain_clk_66" TO "domain_clk_uc" TIG; TIMESPEC "TS_clk_66_to_clk_33" = FROM "domain_clk_66" TO "domain_clk_33" TIG; #TIMESPEC "TS_clk_66_to_clk_125" = FROM "domain_clk_66" TO "domain_clk_125" TIG TIMESPEC "TS_clk_66_to_clk_adc" = FROM "domain_clk_66" TO "domain_clk_adc" TIG; TIMESPEC "TS_clk_66_to_clk_tx" = FROM "domain_clk_66" TO "domain_clk_tx" TIG; TIMESPEC "TS_clk_66_to_clk_rx" = FROM "domain_clk_66" TO "domain_clk_rx" TIG; TIMESPEC "TS_clk_33_to_clk_uc" = FROM "domain_clk_33" TO "domain_clk_uc" TIG; TIMESPEC "TS_clk_33_to_clk_66" = FROM "domain_clk_33" TO "domain_clk_66" TIG; #TIMESPEC "TS_clk_33_to_clk_125" = FROM "domain_clk_33" TO "domain_clk_125" TIG TIMESPEC "TS_clk_33_to_clk_adc" = FROM "domain_clk_33" TO "domain_clk_adc" TIG; TIMESPEC "TS_clk_33_to_clk_tx" = FROM "domain_clk_33" TO "domain_clk_tx" TIG; TIMESPEC "TS_clk_33_to_clk_rx" = FROM "domain_clk_33" TO "domain_clk_rx" TIG; TIMESPEC "TS_clk_adc_to_clk_uc" = FROM "domain_clk_adc" TO "domain_clk_uc" TIG; TIMESPEC "TS_clk_adc_to_clk_33" = FROM "domain_clk_adc" TO "domain_clk_33" TIG; #TIMESPEC "TS_clk_adc_to_clk_125"= FROM "domain_clk_adc" TO "domain_clk_125" TIG TIMESPEC "TS_clk_adc_to_clk_66" = FROM "domain_clk_adc" TO "domain_clk_66" TIG; TIMESPEC "TS_clk_adc_to_clk_tx" = FROM "domain_clk_adc" TO "domain_clk_tx" TIG; TIMESPEC "TS_clk_adc_to_clk_rx" = FROM "domain_clk_adc" TO "domain_clk_rx" TIG; TIMESPEC "TS_clk_tx_to_clk_uc" = FROM "domain_clk_tx" TO "domain_clk_uc" TIG; TIMESPEC "TS_clk_tx_to_clk_33" = FROM "domain_clk_tx" TO "domain_clk_33" TIG; #TIMESPEC "TS_clk_tx_to_clk_125" = FROM "domain_clk_tx" TO "domain_clk_125" TIG TIMESPEC "TS_clk_tx_to_clk_adc" = FROM "domain_clk_tx" TO "domain_clk_adc" TIG; TIMESPEC "TS_clk_tx_to_clk_66" = FROM "domain_clk_tx" TO "domain_clk_66" TIG; TIMESPEC "TS_clk_tx_to_clk_rx" = FROM "domain_clk_tx" TO "domain_clk_rx" TIG; TIMESPEC "TS_clk_rx_to_clk_uc" = FROM "domain_clk_rx" TO "domain_clk_uc" TIG; TIMESPEC "TS_clk_rx_to_clk_33" = FROM "domain_clk_rx" TO "domain_clk_33" TIG; #TIMESPEC "TS_clk_rx_to_clk_125" = FROM "domain_clk_rx" TO "domain_clk_125" TIG TIMESPEC "TS_clk_rx_to_clk_adc" = FROM "domain_clk_rx" TO "domain_clk_adc" TIG; TIMESPEC "TS_clk_rx_to_clk_tx" = FROM "domain_clk_rx" TO "domain_clk_tx" TIG; TIMESPEC "TS_clk_rx_to_clk_66" = FROM "domain_clk_rx" TO "domain_clk_66" TIG; NET "CLK_33_OBUF" TNM_NET = "CLK_33_OBUF"; TIMESPEC "TS_CLK_33_OBUF" = PERIOD "CLK_33_OBUF" 30.03 ns HIGH 50 %; TIMESPEC "TS_F2F" = FROM "FFS" TO "FFS" 14 ns; // *********************************************************************=======================// This is what I get from ISE 9.2 i during implementation process. /////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////// WARNING:Timing:3223 - Timing constraint PATH "TS_U_TO_D_path" TIG; ignored during timing analysis. WARNING:Timing:3223 - Timing constraint PATH "TS_clk_uC_to_clk_33_path" TIG; ignored during timing analysis. WARNING:Timing:3223 - Timing constraint PATH "TS_clk_uC_to_clk_adc_path" TIG; ignored during timing analysis. WARNING:Timing:3223 - Timing constraint PATH "TS_clk_uC_to_clk_tx_path" TIG; ignored during timing analysis. WARNING:Timing:3223 - Timing constraint PATH "TS_clk_uC_to_clk_rx_path" TIG; ignored during timing analysis. WARNING:Timing:3223 - Timing constraint PATH "TS_clk_66_to_clk_adc_path" TIG; ignored during timing analysis. WARNING:Timing:3223 - Timing constraint PATH "TS_clk_33_to_clk_uc_path" TIG; ignored during timing analysis. WARNING:Timing:3223 - Timing constraint PATH "TS_clk_33_to_clk_66_path" TIG; ignored during timing analysis. WARNING:Timing:3223 - Timing constraint PATH "TS_clk_33_to_clk_adc_path" TIG; ignored during timing analysis. WARNING:Timing:3223 - Timing constraint PATH "TS_clk_33_to_clk_tx_path" TIG; ignored during timing analysis. WARNING:Timing:3223 - Timing constraint PATH "TS_clk_33_to_clk_rx_path" TIG; ignored during timing analysis. WARNING:Timing:3223 - Timing constraint PATH "TS_clk_adc_to_clk_uc_path" TIG; ignored during timing analysis. WARNING:Timing:3223 - Timing constraint PATH "TS_clk_adc_to_clk_33_path" TIG; ignored during timing analysis. WARNING:Timing:3223 - Timing constraint PATH "TS_clk_adc_to_clk_66_path" TIG; ignored during timing analysis. WARNING:Timing:3223 - Timing constraint PATH "TS_clk_adc_to_clk_tx_path" TIG; ignored during timing analysis. WARNING:Timing:3223 - Timing constraint PATH "TS_clk_adc_to_clk_rx_path" TIG; ignored during timing analysis. WARNING:Timing:3223 - Timing constraint PATH "TS_clk_tx_to_clk_uc_path" TIG; ignored during timing analysis. WARNING:Timing:3223 - Timing constraint PATH "TS_clk_tx_to_clk_33_path" TIG; ignored during timing analysis. WARNING:Timing:3223 - Timing constraint PATH "TS_clk_tx_to_clk_adc_path" TIG; ignored during timing analysis. WARNING:Timing:3223 - Timing constraint PATH "TS_clk_tx_to_clk_rx_path" TIG; ignored during timing analysis. WARNING:Timing:3223 - Timing constraint PATH "TS_clk_rx_to_clk_uc_path" TIG; ignored during timing analysis. WARNING:Timing:3223 - Timing constraint PATH "TS_clk_rx_to_clk_33_path" TIG; ignored during timing analysis. WARNING:Timing:3223 - Timing constraint PATH "TS_clk_rx_to_clk_adc_path" TIG; ignored during timing analysis. WARNING:Timing:3223 - Timing constraint PATH "TS_clk_rx_to_clk_tx_path" TIG; ignored during timing analysis. WARNING:Timing:3175 - CLK_66 does not clock data from STOP WARNING:Timing:3225 - Timing constraint COMP "STOP" OFFSET = IN 7 ns BEFORE COMP "CLK_66"; ignored during timing analysis WARNING:Timing:3175 - CLK_66 does not clock data to STOP WARNING:Timing:3225 - Timing constraint COMP "STOP" OFFSET = OUT 11 ns AFTER COMP "CLK_66"; ignored during timing analysis WARNING:Timing:3175 - CLK_66 does not clock data from DEVSEL WARNING:Timing:3225 - Timing constraint COMP "DEVSEL" OFFSET = IN 7 ns BEFORE COMP "CLK_66"; ignored during timing analysis WARNING:Timing:3175 - CLK_66 does not clock data to DEVSEL WARNING:Timing:3225 - Timing constraint COMP "DEVSEL" OFFSET = OUT 11 ns AFTER COMP "CLK_66"; ignored during timing analysis WARNING:Timing:3175 - CLK_66 does not clock data to IRDY WARNING:Timing:3225 - Timing constraint COMP "IRDY" OFFSET = OUT 11 ns AFTER COMP "CLK_66"; ignored during timing analysis WARNING:Timing:3175 - CLK_66 does not clock data to TRDY WARNING:Timing:3225 - Timing constraint COMP "TRDY" OFFSET = OUT 11 ns AFTER COMP "CLK_66"; ignored during timing analysis WARNING:Timing:3175 - CLK_66 does not clock data from PERR WARNING:Timing:3225 - Timing constraint COMP "PERR" OFFSET = IN 7 ns BEFORE COMP "CLK_66"; ignored during timing analysis WARNING:Timing:3175 - CLK_66 does not clock data to PERR WARNING:Timing:3225 - Timing constraint COMP "PERR" OFFSET = OUT 11 ns AFTER COMP "CLK_66"; ignored during timing analysis WARNING:Timing:3175 - CLK_66 does not clock data from PAR WARNING:Timing:3225 - Timing constraint COMP "PAR" OFFSET = IN 7 ns BEFORE COMP "CLK_66"; ignored during timing analysis WARNING:Timing:3175 - CLK_66 does not clock data to PAR WARNING:Timing:3225 - Timing constraint COMP "PAR" OFFSET = OUT 11 ns AFTER COMP "CLK_66"; ignored during timing analysis WARNING:Timing:3175 - CLK_66 does not clock data to FRAME WARNING:Timing:3225 - Timing constraint COMP "FRAME" OFFSET = OUT 11 ns AFTER COMP "CLK_66"; ignored during timing analysis WARNING:Timing:3175 - CLK_66 does not clock data to SERR WARNING:Timing:3225 - Timing constraint COMP "SERR" OFFSET = OUT 11 ns AFTER COMP "CLK_66"; ignored during timing analysis WARNING:Timing:3175 - CLK_66 does not clock data to SATA_REQ WARNING:Timing:3225 - Timing constraint COMP "SATA_REQ" OFFSET = OUT 12 ns AFTER COMP "CLK_66"; ignored during timing analysis WARNING:Timing:3175 - CLK_66 does not clock data from SATA_IDSEL WARNING:Timing:3225 - Timing constraint COMP "SATA_IDSEL" OFFSET = IN 7 ns BEFORE COMP "CLK_66"; ignored during timing analysis WARNING:Timing:3175 - CLK_66 does not clock data from SATA_GNT WARNING:Timing:3225 - Timing constraint COMP "SATA_GNT" OFFSET = IN 10 ns BEFORE COMP "CLK_66"; ignored during timing analysis WARNING:Timing:3224 - The clock CLK_66 associated with TIMEGRP "PCI_AD" OFFSET = IN 7 ns BEFORE COMP "CLK_66"; does not clock any registered input components. WARNING:Timing:3225 - Timing constraint TIMEGRP "PCI_AD" OFFSET = IN 7 ns BEFORE COMP "CLK_66"; ignored during timing analysis WARNING:Timing:3224 - The clock CLK_66 associated with TIMEGRP "PCI_AD" OFFSET = OUT 11 ns AFTER COMP "CLK_66"; does not clock any registered output components. WARNING:Timing:3225 - Timing constraint TIMEGRP "PCI_AD" OFFSET = OUT 11 ns AFTER COMP "CLK_66"; ignored during timing analysis WARNING:Timing:3224 - The clock CLK_66 associated with TIMEGRP "PCI_CBE" OFFSET = OUT 11 ns AFTER COMP "CLK_66"; does not clock any registered output components. WARNING:Timing:3225 - Timing constraint TIMEGRP "PCI_CBE" OFFSET = OUT 11 ns AFTER COMP "CLK_66"; ignored during timing analysis ////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////// The question is why the tool is ignoring almost all timing constraints? My second question is, OFFSET IN OFFSET OUT contraints are used with respect to clock which is a global clock and locked to some GCLK pin. These constraints cannot be applied with respect to clocks which are genreated inside the FPGA. If I want to run the PCI on 33 MHz, I will get a divided by 2 version of the 66 MHz clock which is an external clock in my case. In that case, how would I apply the OFFSET IN OFFSET out constraints with respect to teh 33 MHz clock? I tried to use FROM TO constraints, is that OK? for example INST "FRAME" TNM = "PCI_FRAME"; TIMESPEC "TS_PCI_FRAME0" = FROM "PCI_FRAME" TO "PADS" 11 ns; TIMESPEC "TS_PCI_FRAME1" = FROM "PADS" TO "PCI_FRAME" 7 ns; Thanks in advance for reading such a long posting. I hope people out there have answers to my queries. Regards FarhanArticle: 129773
> 3. What could a hacker do to overcome this protection, other than > brute-force? I'd like to add something to this question. V4 security protects your bitstream. This is enough when you just want to avoid the cloning of your product. If you plan to implement a security application on V4 however, you will have to go further than just that. It's quite possible that your design will leak secrets despite the protected bitstream. Regards, MarcArticle: 129774
On Mar 5, 1:01 am, Antti <Antti.Luk...@googlemail.com> wrote: > On 5 Mrz., 05:45, rickman <gnu...@gmail.com> wrote: > > > > > On Mar 3, 4:42 pm, Antti <Antti.Luk...@googlemail.com> wrote: > > > > On 3 Mrz., 22:16, DJ Delorie <d...@delorie.com> wrote: > > > > > Antti <Antti.Luk...@googlemail.com> writes: > > > > > 2) devices packages like Spartan-3E (including QN132 !) or better > > > > > (microBGA 6x6 mm?) > > > > > I keep wondering if there's a market for a few "unbalanced" devices, > > > > like something with a ton of gates but in a tqfp-64 package. Or BGA > > > > packages that only use the two outer rows for signals, for simpler > > > > board routing. > > > > > Likewise, I'd like to see the occasional MCU with a ton of ram and a > > > > little flash, rather than the other way as it usually is. Every once > > > > in a while I need a smart buffer chip :-( > > > > oh yes, TQFP48 0.5mm pitch FPGA running from single voltage! > > > defenetly, but hey thats wish for new Lattice device ;) > > > > BTW, Actel QFN132 3 row QFN 0.5mm pitch CAN be used on > > > 2 layer PCB or even single layer. > > > > Antti > > > I have not looked very hard at the 132 pin QFN package. But at 0.5 mm > > pin pitch, how exactly do you route signals from the middle row out? > > I guess the pins are actually 1.5 mm pitch on each row for 0.5 mm > > considering all three rows? One of the problems I have using 0.65 mm > > pitch QFPs is that I can't route between the pins. That is a real > > PITA. I sometimes think I would be better off with a wider pitch > > part, but I'm not sure I can fit them on the board... :^( > > its 0.5mm pitch. > middle row pins can not be used on 2 layer PCB > only outer and inner row. my application did not > need much IO so that was sufficient I guess your first statement above that the part "CAN be used" on a 2 layer board means, there is no power or essential control signals on the middle row? So I guess it can be used if you don't mind losing a huge percentage of the I/O?
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