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
Nahum Barnea wrote: > Hi. > Is there a way to define a variable / parameter in the xilinx ucf file ? > > I want to P&R to several design parameters. > My clock frequency determine also my I/O setup requirement etc.. > > Thus I am looking for a way to easily switch from one ucf to another > by changing 1 parameter at most. > > Is it possible ? > > ThankX, > NAHUM. Unfortunately I think you're out of luck since Xilinx, alone of all the EDA vendors, has never implemented Tcl scripting for things like UCF. Maybe now they have bitten the bullet and decided that Linux is for real and not just a geek's toybox Tcl might happen ... meanwhile what I've done is to use a simple Perl script to generate parametrisable UCFs and embed this as part of a makefile.Article: 45826
Hi, I would like to give someone the programming bits for an FPGA for my design. Is there anyway the programming bits could be used to reverse engineer to my design ? What is the safest way to let someone use your design without them being able to figure out your FPGA design ? Thanks, PrashantArticle: 45827
szamani@ce.aku.ac.ir (Morteza) writes: > It may be useful to design at the very low level: Setting programmable > switches, MUXes select lines, etc, individually. (useful for designing > compact and fast library components, for example). > > Is there any straightforward way (e.g. schematic/text editors) to do > that? If you are targeting Virtex (or an Spartan-II with has an equal-size Virtex) then the JBits tool from Xilinx gives you such low level access from an Java text file. You can get it free by mailing jbits@xilinx.com -- Neil Franklin, neil@franklin.ch.remove http://neil.franklin.ch/ Hacker, Unix Guru, El Eng HTL/BSc, Programmer, Archer, Roleplayer - Make your code truely free: put it into the public domainArticle: 45828
Prashant, Use Triple DES config feature with three keys in Virtex II or Virtex II Pro. Then the bits don't help you at all. They can't even copy the bitstream and stamp out copies because the keys are hidden in the part, and can not be read out. Alternately, fill up an entire 2V6000 with your design. It would takes more than ten years of engineering to understand it. By then, you would be selling your new improved version. They would never be able to recover the original verilog or VHDL. If I gave you Microsoft Windows bits, could you figure out what Microsoft is doing? Given that you can place a Micro-Blaze uP in your design, you could have the part call home, and get its authorization to perform its function if and only if the customer was a valid one. Get creative. Austin Prashant wrote: > Hi, > > I would like to give someone the programming bits for an FPGA for my > design. Is there anyway the programming bits could be used to reverse > engineer to my design ? What is the safest way to let someone use your > design without them being able to figure out your FPGA design ? > > Thanks, > PrashantArticle: 45829
I think the TIG of xilinx constrain is a little simlar "Set_False_Path" of Design Compiler .For example,i have 3 clock(clk1/clk2/clk3) in my project. Do i need add the following constrain so that both P&R and Timing analyzer of xilinx ISE don't care them like Synopsys DC? *********************************** TIMESPEC "TS_clk1" = FROM "clk1" TO "clk2" TIG; TIMESPEC "TS_Clk2" = FROM "clk2" TO "clk3" TIG; TIMESPEC "TS_clk1" = FROM "clk1" TO "clk3" TIG; TIMESPEC "clk3" = FROM "clk1" TO "MDC_c_c" TIG; TIMESPEC "clk3" = FROM "clk2" TO "MDC_c_c" TIG;Article: 45830
I've been trying to get a simple GAL22v10 programmed so that I can get my little personal project going. I grabbed the old PALASM software off the net get a JEDEC file from it just fine. I buy some 22v10 except they're not GALs. They're PALs. I have an EMP10 (needham's) programmer, but it won't take PAL parts. Only Lattice GAL parts. I try anyway. The programming software tells me that the number of fuses in the file doesn't match the number of fuses in the device. Silly me! I thought 22V10 parts were all the same. It tells me that there are 5892 fuses in the GAL22V10 I specified in software and that the loaded JEDEC file only indicates 5828 fuses. Then it gives me an option to fill in the last 64 fuse map addresses with 0. So here are my questions. 1) Can I just tell it to fill in the remaining 64 and program a Lattice GAL22v10 just fine? 2) The palasm software spits out JEDEC files for the old PAL22V10. Can I use it to program a "modern" GAL part? Or do I have to juggle some more to get the proper software? If not, can anyone direct me to where I can find free or relatively cheapish software that will put out modern GAL jedec files? 3) Here's the other problem. The EMP10 programmer gives me 2 options in the GAL selection. One is GAL22V10 and the other is GAL22V10B (note the B suffix). I searched high and low and I can't find the GAL22V10B. It's been obseleted. All they sell are D suffix parts. What's the difference? If anyone can answer these questions, please answer. Don't be shy. You won't get much for your altruism, but you'll get a warm fuzzy for doing it. I hope. Thanks, LTArticle: 45831
Hi, I'm looking for a behavioral model for a Xilinx RAMB4_S8. I wrote my own model, but I am seeing differences between my simulation model and the synthesized FPGA behavior. Does anyone have a known-good model or know where I can find one. Thanks in Advance, Scott BakerArticle: 45832
"Daryl" <e-engineer@eastday.com> wrote in message news:<3d4f767d@shknews01>... > Hi, FPGA gurus, > > My question is "Is it necessary to instantiate the IPAD, OPAD, IBUF, OBUF, > IBUFG, ... in my HDL code of top-level ?" > > ----- if NO, > when I have to insert BUFG or/and BUFT explicitly, how to code to insert > what I want solely? -------- SNIP ---------- In Synplify, you don't have to instantiate I/O pads or BUFGs. It will add I/O pads to all top-level ports and even create Registered I/O pads by itself. It also recognizes clock nets and adds BUFGs automatically. Actually, the big problem is preventing Synplify from doing it if you want better control over your I/O pins (for example, we wanted to use both the registered and unregistered inputs of the same input pad - had a terrible time convincing Synplify that that's what we REALLY wanted). I haven't used XST or Exemplar for some time, but I am sure that they behave pretty much the same. Regards Assaf SarfatiArticle: 45833
Hi.
I would like to hear about the experience of xilinx users that used
"-k" flag in the "map" program.
I did'nt see a way to control this flag from the GUI, the help says
-k 4|5|6|7|8 Function size for covering combinational logic.
If -k
is not specified, the default is -k 4. This
gives the
best balance of runtime to quality of results.
Using
larger values of -k can give superior results
at the
expense of runtime.
And I wishto know did it realy helped virtex2 users or did it just
consume more time ?
ThankX,
NAHUM
Article: 45834
Hi, Assaf and others,
Thanks for your issues, Assaf.
Now I got your idea, I think I'd better instantiate all of IBUFs and
OBUFs explicitly in my top-level code, as well as IBUFGP and FDs, but NO
PADs.
Right?
Now, my puzzle turned to whether I should/had better add IBUFs or add
IFDs in on certain conditions. If I want to use OFD to save DFFs in interval
logic and reduce output delay, I have to code asynchronous outputs in
submodules? Is there a method for me to force a process or "always@.." block
to use OFD as DFF?
Best Regards,
Daryl
Article: 45835On Wed, 07 Aug 2002 03:24:54 GMT, "Scott L. Baker" <scd@teleport.com> wrote: >Hi, > >I'm looking for a behavioral model for a Xilinx RAMB4_S8. > >I wrote my own model, but I am seeing differences >between my simulation model and the synthesized FPGA >behavior. Does anyone have a known-good model or >know where I can find one. There is a model in the unisim library. The source for the unisim library is in your xilinx software installation. This thread contains instructions on how to compile it: http://groups.google.com/groups?threadm=7aa9e136.0201100122.44039324%40posting.google.com Regards, Allan.Article: 45836
"kkps" <kkps@rapid5.com> wrote in message news:c6efc5c9.0208050742.187cb4de@posting.google.com... > Hi all, > > I need to choose an AES (rijndael) IP core to use in Xilinx VirtexE. > There is a wide perplexing selection of core providers on the > internet. Does anybody have any recommendation regarding who is the > best (performance & cos I assume you already knew this, but if not, the NSA has helpfully implemented AES in VHDL for you. Everybody says these cores are sub-optimal in efficiency, but hey, they work, and they are free and un-copyrighted. If nothing else, you can leech the test benches. http://csrc.nist.gov/encryption/aes/round2/r2anlsys.htm#NSA If there are any other open source AES cores in VHDL or Verilog, I'd appreciate pointers to them here. GuerreArticle: 45837
Daryl wrote: > Hi, Assaf and others, > > Thanks for your issues, Assaf. > Now I got your idea, I think I'd better instantiate all of IBUFs and > OBUFs explicitly in my top-level code, as well as IBUFGP and FDs, but NO > PADs. > Right? I think Assaf was saying the opposite, at least for Synplify. > > Now, my puzzle turned to whether I should/had better add IBUFs or add > IFDs in on certain conditions. If I want to use OFD to save DFFs in interval > logic and reduce output delay, I have to code asynchronous outputs in > submodules? Is there a method for me to force a process or "always@.." block > to use OFD as DFF? > You don't have to do this. just synthesise as normal to get one of the standard FF types. Then use the -pr (= pack registers) flag to the Xilinx MAP program to tell it to put FFs into the IOBs if possible. You need to obey a few rules for this to work (applies to Virtex, XC4K is a bit different). o No logic before an InFF or after an OutFF, not even an inversion. o If there's both an InFF and an OutFF then they must share the same clock (obvious for global clocks). o If there's both an InFF and an OutFF they musy have the same initialisation signal but the 2 FFs can be configured to use it differently. This is not so obvious if (i) Synplify has e.g. fanned out a reset signal used by a 64-bit bitdir registered bus (ii) Synplify uses its trick of regarding sync set/reset as a way of absorbing logic, (iii) one direction has an init but the other doesn't. One final thing - by default the inferred IO pads are LVTTL. If you want something different then you can use the Synplify xc_padtype attribute either in the source on in a separate .sdc file. Note that contrary to Assaf I've not had any problems getting Synplify to synthesise correctly in the case (e.g. PCI) where I want both the direct and registered inputs from an IO pad.Article: 45838
Austin Lesea wrote: > Prashant, > > Use Triple DES config feature with three keys in Virtex II or Virtex II > Pro. Then the bits don't help you at all. > One thing I noticed is the the V-2 3DES keys are 64-bit but IIRC 3DES allows up to 112-bit. Is this down to the US cryptographic export restrictions ? Or is there some way of chaining together the 2 sets of 3 keys ?Article: 45839
Nahum Barnea wrote: > Hi. > I would like to hear about the experience of xilinx users that used > "-k" flag in the "map" program. > > I did'nt see a way to control this flag from the GUI, the help says > > -k 4|5|6|7|8 Function size for covering combinational logic. > If -k > is not specified, the default is -k 4. This > gives the > best balance of runtime to quality of results. > Using > larger values of -k can give superior results > at the > expense of runtime. > > And I wishto know did it realy helped virtex2 users or did it just > consume more time ? > > ThankX, > NAHUM Basically I think this is for designs where the input is a bunch of logic equations (e.g. coming from compiled schematics) and MAP has to do the work of allocating the logic to LUTs. For designs synthesised from HDLs this has already been done by the synth tool so -k most likely won't gain very much. In fact the Synplfy documentation recommends *not* using it since it will make the overall QOR worse, not better.Article: 45840
Rick Filipkiewicz wrote: > > > Basically I think this is for designs where the input is a bunch of logic > equations (e.g. coming from compiled schematics) and MAP has to do the > work of allocating the logic to LUTs. For designs synthesised from HDLs > this has already been done by the synth tool so -k most likely won't gain > very much. In fact the Synplfy documentation recommends *not* using it > since it will make the overall QOR worse, not better. I should have added that if you want to get 5+ input functions so that a critical path becomes less routing dependent then you can always structure your code so that the synth tool can "see" the opportunity to at least use a MUXF5. In the worst case you can always instantiate ...Article: 45841
Note that the lack of relocation offer could also be tied to the fact that you're using a headhunter. I have seen some companies say that they can either pay reloc or a headhunter, but not both ... John Jakson wrote: > > Austin Lesea <austin.lesea@xilinx.com> wrote in message news:<3D4FE14B.D56334C2@xilinx.com>... > > John, > > > > Times are tough. Xilinx did not have layoffs (oops, not pc), or have a > > 'RIF' as all other silicon companies did. We tightened our belts, stuck > > to what we do best, and continued to execute. > > > > Recently, we realized we have an opportunity to hire the absolute best > > engineers that had to be let go by their companies who were unable to > > weather the downturn. > > > > The terms and conditions are ours to make: since no one else is hiring > > (for ASIC, ASSP, or FPGA), it matters little if we do not offer relocation > > as a benefit. We have many other benefits that are more important. It is > > up to the candidate to decide what the trade-offs are, and if they make > > sense for them. > > > > > > > > As for Peter, and myself, no one ever offered us a relocation bonus. In > > the "old days" (and Peter is such a distinguished gentleman I would not > > offer to state when that was) for me, I was told that if I wanted the job, > > I could show up and interview for it. > > > > I know, we walked uphill in the snow to and from school, but hey, if you > > have never experienced tough times, you have nothing to provide you with a > > reference. > > > > As for discrimination, that is unfair and scurrilous to suggest: we hire > > the best, end of statement. I have engineers in their 60's working for > > me. I have engineers in their 20's working for me. I don't care how old > > they are, and neither do any other managers here. > > > > Peter worked in Sweden after he graduated from college in Germany. > > > > Austin > > > > Hi Austin > > Thanks for your response, I apologize for implying anything untoward. > > I very glad to hear that more senior engineers are working hard at > Xilinx. > > Anyway I was really unaware that reloc packages were so severely > limited by the industry at large today, as it has always been my > fortune to have been offered this in prior times for out of state > changes even when I think the economy was far worse 84 etc. I will > bear this in mind next time I talk to folks. > > Perhaps the head hunter should have been warned too, and I couldn't > find this info on your job site or on any of the positions in B & W. > > RegardsArticle: 45842
Kevin Brace <killspam4kevinbraceusenet@killspam4hotmail.com> wrote: > According to the Xilinx website, for XC4000 series, the only > design flow currently supported is EDIF. > Since ISE 4.2 no longer comes with Synopsys FPGA Compiler II, and XST > doesn't support XC4000 series, the ISE 4.2 user will have to buy a > separate third party synthesis tool. Alternatively, don't upgrade. BTW, I think you mean 4000E, XL, etc. Plain old 4000 isn't even supported by any tool post-XACT, afaik. Hamish -- Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>Article: 45843
If you want to use a specific UCF file for an implementation, you can use the command line option : NGDBUILD -uc ucf_file_name This way, you can use a script to implement the desing using a different UCF file for every iteration. Hope this helps. Francois Choquette LACIME nahum_barnea@yahoo.com (Nahum Barnea) wrote in message news:<fc23bdfc.0208061208.68c0f05b@posting.google.com>... > Hi. > Is there a way to define a variable / parameter in the xilinx ucf file ? > > I want to P&R to several design parameters. > My clock frequency determine also my I/O setup requirement etc.. > > Thus I am looking for a way to easily switch from one ucf to another > by changing 1 parameter at most. > > Is it possible ? > > ThankX, > NAHUM.Article: 45844
Hi,
I am trying to simulate 4 x CLK multiplier with DLLs in Spartan2 (as
described in XAPP132), but in ModelSim I am getting this error:
# ** Error: (vsim-3043) d:/Xilinx/verilog/src/unisims/OBUF.v(21):
Unresolved reference to 'glbl' in glbl.GTS.
It is because of line:
OBUF lckpad (.I(LOCKED_DLL), .O(LOCKED));
Can anybody help me?
Thank you a lot.
Peter.
Article: 45845In article <3D50E7C6.4488BFFA@algor.co.uk>, Rick Filipkiewicz <rick@algor.co.uk> wrote: >One thing I noticed is the the V-2 3DES keys are 64-bit but IIRC 3DES allows >up to 112-bit. Is this down to the US cryptographic export restrictions ? Or >is there some way of chaining together the 2 sets of 3 keys ? Hu? THe DES keys are 56 bits (with headers, padded to 64 bits), and 3 are chaned together to create a 3DES encryption. -- Nicholas C. Weaver nweaver@cs.berkeley.eduArticle: 45846
Hi, I understand the part where if you give out a programmed device, you can make it difficult for someone to break through, but what if I gave out the programmed bits. I will be giving the programming bits to someone so that he could use it. All the same I dont want him to figure out the design represented by the programming bits. Is it possible to get the design from the programming bits ? You may have answered the question, but I think I'm still a little confused. Thanks, Prashant Austin Lesea <austin.lesea@xilinx.com> wrote in message news:<3D505C89.5F4223BC@xilinx.com>... > Prashant, > > Use Triple DES config feature with three keys in Virtex II or Virtex II > Pro. Then the bits don't help you at all. > > They can't even copy the bitstream and stamp out copies because the keys > are hidden in the part, and can not be read out. > > Alternately, fill up an entire 2V6000 with your design. It would takes > more than ten years of engineering to understand it. By then, you would > be selling your new improved version. > > They would never be able to recover the original verilog or VHDL. > > If I gave you Microsoft Windows bits, could you figure out what Microsoft > is doing? > > Given that you can place a Micro-Blaze uP in your design, you could have > the part call home, and get its authorization to perform its function if > and only if the customer was a valid one. > > Get creative. > > Austin > > Prashant wrote: > > > Hi, > > > > I would like to give someone the programming bits for an FPGA for my > > design. Is there anyway the programming bits could be used to reverse > > engineer to my design ? What is the safest way to let someone use your > > design without them being able to figure out your FPGA design ? > > > > Thanks, > > PrashantArticle: 45847
Prashant, Someone pointed out that I missed your point: you want to give the bits to someone. If you give them the bits, then you can't just give them the keys too, as then they can decrypt the bitstream (with a c program) and see the bitstream in the clear (unencrypted). So the triple DES doesn't work for your situation. Thus the safest way to prevent them from reverse engineering is to have a large complex design that is just not worth their time to try to figure out. This is part of the problem selling IP: if it is simple, how do you protect yourself? A number of years ago, a large unamed telecom manufacturer I knew of, sent an ASIC to an unamed far eastern country for every switch board that was to be built. The ASIC cost a lot of money to the far eastern country factory (it was, in effect the royalty payment). The idea was that boards would not work without the key ASIC, and if any board was ever found without the exclusive ASIC from the telecom giant on it, they would then know they had been cheated. Such a part can be done today with a Coolrunner CPLD, and then turn on the security bits, so it can't be read back out. Reverse engineering it requires that they use all kinds of clever techniques to read out the internal states of the EEPROM (e-beam, backside emission, etc) or try to figure out what it is saying or doing that makes it the key. Nothing is foolproof, and as long as it is harder to crack it than it is worth, you succeed. Austin Prashant wrote: > Hi, > > I would like to give someone the programming bits for an FPGA for my > design. Is there anyway the programming bits could be used to reverse > engineer to my design ? What is the safest way to let someone use your > design without them being able to figure out your FPGA design ? > > Thanks, > PrashantArticle: 45848
prashantj@usa.net (Prashant) writes: >I understand the part where if you give out a programmed device, you >can make it difficult for someone to break through, but what if I gave >out the programmed bits. >I will be giving the programming bits to someone so that he could use >it. All the same I dont want him to figure out the design represented >by the programming bits. Is it possible to get the design from the >programming bits ? >You may have answered the question, but I think I'm still a little >confused. How much money does he have, and houw much is it worth it to him? If your design is worth $1,000,000 then worry because he can probably find someone to get the design from the bits for that price. If it is only worth $10,000 then he probably can't. (You don't say which device, how complicated it is, or things like that, but those probably aren't too far off. Maybe someone else will come up with different numbers.) -- glenArticle: 45849
Hi all I am facing a problem I can not understand: I have a signal that come sout of a LUT and goes: - to a pad FF (testpoint 1) - to an internal FF (DFF, no enable, global async reset) The output of this internal FF then goes to the rest of the design AND to another pad FF (testpoint 2) I have checked with both the floorplanner and the FPGA Editor: the LUT and the FF are in the same slice and directly connected. The FF clock input is normally connected to the global clock (no gated clock). The output of this FF remains low, even when its input goes high (testpoint 1 toggles, testpoint 2 remains low) Since the LUT and the FF are in the same slice, the propagation delay is really short, whereas the propagation delay between the LUT and the pad must be much longer. What am I missing? -- Nicolas MATRINGE IPricot European Headquarters Conception electronique 10-12 Avenue de Verdun Tel +33 1 46 52 53 11 F-92250 LA GARENNE-COLOMBES - FRANCE Fax +33 1 46 52 53 02 http://www.IPricot.com/
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