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
subint schrieb: > Hi, > I am using the platform studio first time.I like to know how i can add > my testbenches and remove the microblaze processor from the setup. > I am trying to generate the controller for my V4MB lx60 board > and i want to test the ddr in the board.From the tool(platform studio) > i can select the pheripherals and the processor etc but didnt have any > idea how can i use this to test my ddr.I tried to generate the hdl > code.But all the controllers are ipcores(black box) and i wont be able > to synthesize it using xilinx ise(library for these ipcores are > missing). > regards > subin EDK supports 1) MicroBlaze 2) PowerPC if you want to use EDK for any other purpose (eg no supported CPU from the list of supported CPU'S) then this is: "DO NOT" thing. It is possible to use the EDK IP cores outside the EDK system, but it really doesnt make sense in most of cases (read: almost never). If you want EDK (and EDK supplied IP cores) then use EDK the way it is intended to be used eg to design MB/PPC based SoC If you want to play around with DDR memory then take some DDR IP core any play with it. AnttiArticle: 104476
Thanks Duane. I have 16-bit data that needs to be converted to ASCII. SO I guess I will have to take a nibble and convert it into its ASCII equivalent and then give a space or next line to differentiate the next word. Thanks for the tip. Vivek Duane Clark wrote: > Vivek Menon wrote: > > does anybody have a function or package that converts data into ASCII?? > > You send one nibble (4 bits) at a time. If the nibble is between 0-9, > then add 0x30 (hex 30). If between a-f, add 0x60. It should be easy to > figure out how to do that in VHDL/Verilog. That will give you a hex display.Article: 104477
David, Fair enough. A good treatise of the subject: http://www.cl.cam.ac.uk/~mgk25/sc99-tamper.pdf And today's FPGA Journal: http://www.fpgajournal.com/articles_2006/20060627_security2.htm And, http://md.hudora.de/presentations/summerschool/2004-09-20/HardwareAttacks.pdf The slides that I would like to send to you do not exist on a public website (that I can find). The photo micro graphs that I have may have been ones that we got. They are in our V4 security presentation that our FAEs pitch. So, for anyone who really would like to see what an efuse looks like under a microscope, before and after programming, they will still have to email me and request I send it. Again, I love efuses. They are great. Hope to see them in a device. But, how they are used, and more importantly how they are represented has to be fair and honest. Austin David Brown wrote: > Austin Lesea wrote: >> David, >> >> As to convenience, place a lithium coin cell on the pcb per the app >> note. Ask the software to generate a random key for you (or pick one >> yourself), send the key to the JTAG port. Verify the key can be written >> and read, then write it in secure mode (so it can not be read out again >> without it being erased immediately). Program eeprom or other memory >> with encrypted bitstream. >> >> Done. >> >> Not sure about Altera, as they have now told us they keep secrets from >> even their customers, and you have to sign an NDA. But, in theory, you >> get a key (does their software generate random 128 bit keys? Let us >> suppose it does), program the part (How? It is a secret! But let us >> imagine it is as simple as JTAG), an then place encrypted design in the >> memory. >> >> Done. >> >> So, we have one more step: make sure their is a lithium coin cell on >> the pcb connected to the Vbatt pin. >> >> That is the total level of inconvenience we offer. >> > > Peter Alfke referred to Altera's solution as being more biased towards > convenience, while Xilinx's was more biased towards security. Since > Peter knows a great deal more than me about both security systems, I > assume that the difference in convenience is relevant (unless, of > course, he was referring to convenience for Altera rather than for the > customer). > > At the moment, and for the foreseeable future, I am not using either > Altera or Xilinx's bigger devices, and I am not overly concerned about > security. And I'm sure that if I did need such a design, then the > inconvenience of having a battery would not stop me using Xilinx - other > factors are more important. > > >> The benefit is that we offer all four levels of security in FIPS 140-2 >> compliance, and Altera offers no level of compliance at all with FIPS >> 140-2. >> >> What is so important about FIPS 140-2? It is the required security >> standard for the US Federal government, as well as for banks, networks, >> and others who are serious about security. >> >> Don't need FIPS 140-2? Then go ahead and use efuse keys. But also be >> aware of the risks. >> > > The risks must be balanced, and it's important to know them (I don't, > obviously, but I've never needed to know). What's important is to > protect the IP, which means increasing the costs until it is impractical > for someone to steal it. You don't need a zero risk solution, you need > something with a risk that is known to be low enough. I presume that > Altera will give customers more detailed information when necessary - > although I think the Xilinx-style openness is better. > >> As for reverse engineering, I can send you presentations of how efuse >> technology smart cards are reverse engineered (hacked). It is a junior >> level EE project at most universities now. >> > > I'm following this thread out of interest, and not from a need of > detailed knowledge. If you have public links of interest to others > here, post them here - others have questioned the accuracy of your > numbers and might like to see examples. It would of course be > interesting to hear Altera's viewpoint as well. > > As for sending anything directly to me - I appreciate the offer, but > there is no need, and it would be a waste of your time. Newsgroup posts > benefit more people. > > mvh., > > David > > >> Austin >> >> >> David Brown wrote: >>> Peter Alfke wrote: >>>> Let's not quibble over the price tag, and whether $10,000 is a >>>> meaningful hurdle. >>>> >>>> The debate was about key security, and the consensus in the crypto >>>> community is that things like efuses can be read out with moderate >>>> effort, while battery-backed up SRAM data is either much more secure or >>>> even perfectly secure, i.e. has never been cracked. >>>> >>>> Some people think batteries are a pain, others think they are just fine >>>> and last >15 years. >>>> >>>> It's security vs convenience. Xilinx picked security, Altera picked >>>> convenience. >>>> The choice is yours. Peter Alfke, Xilinx Applications >>>> >>> Any security system must be convenient, or it won't be used. A hefty >>> proportion of windows users have firewall software that came with their >>> machines, but it's turned off - simply because it is too inconvenient. >>> When it's enabled, the firewall keeps asking these daft questions about >>> whether your programs are allowed to do this or that - it's far easier >>> just to turn the stupid thing off. An advanced application level >>> software firewall may theoretically be more secure than a simple >>> "incoming bad, outgoing good" firewall, but it's no help if people don't >>> use it. >>> >>> The same thing probably applies here. I've no experience with either >>> Altera's or Xilinx's solutions, but I can understand the principle that >>> it's possible to read out efuses but not sram bits. If Altera's >>> solution is more convenient, then perhaps it is more secure in that >>> developers are more likely to use it? After all, all they need to do is >>> choose some options in the software - there is no need to add batteries >>> to the card, and to handle the support costs of dealing with lost keys >>> (users are so imaginative - "I took out the battery to make sure the >>> card got a proper reset"). >>> >>> As to how secure Altera's solution is - the Altera guys are not idiots, >>> and it is unbecoming of you to them as such. Sure, it's possible to >>> read out the efuses in theory, but my guess is you're going to have to >>> do a lot more than just a couple of $5000 rounds. I'm sure there are >>> theoretical methods of breaking Xilinx's security too, such as probing >>> the bit stream out of the decoder. Since you have to get access to the >>> device while power is on, it's going to be difficult - but I'm sure it >>> can be done given enough time and money (and boards to practise on). To >>> be secure, all a method has to do is raise the stakes high enough that >>> alternative methods are cheaper - once it is easer and cheaper to bribe >>> the original engineers for a copy of the code, the device is secure >>> enough.Article: 104478
Hi Gabor, Thank you for your response. I am living in California. Everything done by the notary is fine, but no date. Yes, they did write correct thing in a log book that belongs to theirs, but gave us anyt prove of the date. Is it enough when the package is shown in a court if necessary? Weng Gabor wrote: > You don't say where you had your documents notarized, but I know > that when I get a document notarized in New Hampshire, the notary > enters the description in a log book, which certainly has dates. > > I would suggest that you enter a date next to your signature yourself > when the documents are notarized. The notary stamp indicates that > the signing and dating was witnessed by a reliable person and a > record kept of this witnessing. > > HTH > Gabor > > Weng Tianxiang wrote: > > Hi, > > I read some books describing that preservation of patent ideas through > > a notary is valid in the law. > > > > Yesterday we put all patent materials into a large envelop and went to > > a notary to seal it. A lawyer in the notary put notary stamps on all > > papers and sealed the envelop properly with stamps too. What surprised > > us is there is no date!!! There are no date stamps like a register > > letter that must have a date stamp on the envelop. There is no receipt > > neither. > > > > What does It prove? What I need is a date a patent law court admits. > > But here there is no date. What is wrong? What should I do next? > > > > Thank you. > > > > WengArticle: 104479
Austin Lesea wrote: > David, > > Fair enough. What fascinating links! I always wondered how lock-picking was done... It was also interesting to see how smart cards are cracked, which is more relevant to real life than FPGA security (for most people, anyway). I'd assume that FPGAs are harder to crack - if nothing else, the size of the devices is on a different scale. The FPGA article suggests that both Altera's and Xilinx's methods are very secure, without being too specific. mvh., David > A good treatise of the subject: > http://www.cl.cam.ac.uk/~mgk25/sc99-tamper.pdf > > And today's FPGA Journal: > http://www.fpgajournal.com/articles_2006/20060627_security2.htm > > And, > http://md.hudora.de/presentations/summerschool/2004-09-20/HardwareAttacks.pdf > > The slides that I would like to send to you do not exist on a public > website (that I can find). The photo micro graphs that I have may have > been ones that we got. They are in our V4 security presentation that > our FAEs pitch. > > So, for anyone who really would like to see what an efuse looks like > under a microscope, before and after programming, they will still have > to email me and request I send it. > > Again, I love efuses. They are great. Hope to see them in a device. > But, how they are used, and more importantly how they are represented > has to be fair and honest. > > Austin > > David Brown wrote: >> Austin Lesea wrote: >>> David, >>> >>> As to convenience, place a lithium coin cell on the pcb per the app >>> note. Ask the software to generate a random key for you (or pick one >>> yourself), send the key to the JTAG port. Verify the key can be written >>> and read, then write it in secure mode (so it can not be read out again >>> without it being erased immediately). Program eeprom or other memory >>> with encrypted bitstream. >>> >>> Done. >>> >>> Not sure about Altera, as they have now told us they keep secrets from >>> even their customers, and you have to sign an NDA. But, in theory, you >>> get a key (does their software generate random 128 bit keys? Let us >>> suppose it does), program the part (How? It is a secret! But let us >>> imagine it is as simple as JTAG), an then place encrypted design in the >>> memory. >>> >>> Done. >>> >>> So, we have one more step: make sure their is a lithium coin cell on >>> the pcb connected to the Vbatt pin. >>> >>> That is the total level of inconvenience we offer. >>> >> Peter Alfke referred to Altera's solution as being more biased towards >> convenience, while Xilinx's was more biased towards security. Since >> Peter knows a great deal more than me about both security systems, I >> assume that the difference in convenience is relevant (unless, of >> course, he was referring to convenience for Altera rather than for the >> customer). >> >> At the moment, and for the foreseeable future, I am not using either >> Altera or Xilinx's bigger devices, and I am not overly concerned about >> security. And I'm sure that if I did need such a design, then the >> inconvenience of having a battery would not stop me using Xilinx - other >> factors are more important. >> >> >>> The benefit is that we offer all four levels of security in FIPS 140-2 >>> compliance, and Altera offers no level of compliance at all with FIPS >>> 140-2. >>> >>> What is so important about FIPS 140-2? It is the required security >>> standard for the US Federal government, as well as for banks, networks, >>> and others who are serious about security. >>> >>> Don't need FIPS 140-2? Then go ahead and use efuse keys. But also be >>> aware of the risks. >>> >> The risks must be balanced, and it's important to know them (I don't, >> obviously, but I've never needed to know). What's important is to >> protect the IP, which means increasing the costs until it is impractical >> for someone to steal it. You don't need a zero risk solution, you need >> something with a risk that is known to be low enough. I presume that >> Altera will give customers more detailed information when necessary - >> although I think the Xilinx-style openness is better. >> >>> As for reverse engineering, I can send you presentations of how efuse >>> technology smart cards are reverse engineered (hacked). It is a junior >>> level EE project at most universities now. >>> >> I'm following this thread out of interest, and not from a need of >> detailed knowledge. If you have public links of interest to others >> here, post them here - others have questioned the accuracy of your >> numbers and might like to see examples. It would of course be >> interesting to hear Altera's viewpoint as well. >> >> As for sending anything directly to me - I appreciate the offer, but >> there is no need, and it would be a waste of your time. Newsgroup posts >> benefit more people. >> >> mvh., >> >> David >> >> >>> Austin >>> >>> >>> David Brown wrote: >>>> Peter Alfke wrote: >>>>> Let's not quibble over the price tag, and whether $10,000 is a >>>>> meaningful hurdle. >>>>> >>>>> The debate was about key security, and the consensus in the crypto >>>>> community is that things like efuses can be read out with moderate >>>>> effort, while battery-backed up SRAM data is either much more secure or >>>>> even perfectly secure, i.e. has never been cracked. >>>>> >>>>> Some people think batteries are a pain, others think they are just fine >>>>> and last >15 years. >>>>> >>>>> It's security vs convenience. Xilinx picked security, Altera picked >>>>> convenience. >>>>> The choice is yours. Peter Alfke, Xilinx Applications >>>>> >>>> Any security system must be convenient, or it won't be used. A hefty >>>> proportion of windows users have firewall software that came with their >>>> machines, but it's turned off - simply because it is too inconvenient. >>>> When it's enabled, the firewall keeps asking these daft questions about >>>> whether your programs are allowed to do this or that - it's far easier >>>> just to turn the stupid thing off. An advanced application level >>>> software firewall may theoretically be more secure than a simple >>>> "incoming bad, outgoing good" firewall, but it's no help if people don't >>>> use it. >>>> >>>> The same thing probably applies here. I've no experience with either >>>> Altera's or Xilinx's solutions, but I can understand the principle that >>>> it's possible to read out efuses but not sram bits. If Altera's >>>> solution is more convenient, then perhaps it is more secure in that >>>> developers are more likely to use it? After all, all they need to do is >>>> choose some options in the software - there is no need to add batteries >>>> to the card, and to handle the support costs of dealing with lost keys >>>> (users are so imaginative - "I took out the battery to make sure the >>>> card got a proper reset"). >>>> >>>> As to how secure Altera's solution is - the Altera guys are not idiots, >>>> and it is unbecoming of you to them as such. Sure, it's possible to >>>> read out the efuses in theory, but my guess is you're going to have to >>>> do a lot more than just a couple of $5000 rounds. I'm sure there are >>>> theoretical methods of breaking Xilinx's security too, such as probing >>>> the bit stream out of the decoder. Since you have to get access to the >>>> device while power is on, it's going to be difficult - but I'm sure it >>>> can be done given enough time and money (and boards to practise on). To >>>> be secure, all a method has to do is raise the stakes high enough that >>>> alternative methods are cheaper - once it is easer and cheaper to bribe >>>> the original engineers for a copy of the code, the device is secure >>>> enough.Article: 104480
Andi, Thanks for sharing this information. Do you use native XST synthesis? Did you use EDK wizard to build your custom cores? Thanks, /Mikhail "Andi" <00andi@web.de> wrote in message news:ee9c94c.4@webx.sUN8CHnE... > We have a XC2VP40 with 98% silce utilization. The System contains a PPC405 300 MHz with PLB 100 Mhz and OPB 50 Mhz. On PLB side we have - plb sdram - plb emac - plb bram - plb dma ctrl ( own core) - plb user core 1 ( own core ) - plb user core 2 ( own core ) > > And i do not have any timing problems with ISE 8.1 and EDK 8.1. The flow needs quit a "long" time. But in the end i have (0) timing errors without planahead. > > AndiArticle: 104481
David, All I can say is that FIPS 140-2 requires the key memory can be erased. Since the NIST requires it, it must be because they feel that a key that can be erased is more secure than one that can not be erased. I happen to agree with them. Even if I do not know how to read the non-volatile key today, I might figure it out tomorrow. After all, it just sits there, awaiting discovery. How long the security must work is also a factor. If I am a government, I might require that the security is secure for 20 years or more. If I park my bicycle on the street, I only need security for a short while (until I get back). If I am a bank, and transacting business and transferring funds, I might need to be secure for a lifetime, maybe more. Austin David Brown wrote: > Austin Lesea wrote: >> David, >> >> Fair enough. > > What fascinating links! I always wondered how lock-picking was done... > It was also interesting to see how smart cards are cracked, which is > more relevant to real life than FPGA security (for most people, anyway). > I'd assume that FPGAs are harder to crack - if nothing else, the size > of the devices is on a different scale. > > The FPGA article suggests that both Altera's and Xilinx's methods are > very secure, without being too specific. > > mvh., > > David > > >> A good treatise of the subject: >> http://www.cl.cam.ac.uk/~mgk25/sc99-tamper.pdf >> >> And today's FPGA Journal: >> http://www.fpgajournal.com/articles_2006/20060627_security2.htm >> >> And, >> http://md.hudora.de/presentations/summerschool/2004-09-20/HardwareAttacks.pdf >> >> >> The slides that I would like to send to you do not exist on a public >> website (that I can find). The photo micro graphs that I have may have >> been ones that we got. They are in our V4 security presentation that >> our FAEs pitch. >> >> So, for anyone who really would like to see what an efuse looks like >> under a microscope, before and after programming, they will still have >> to email me and request I send it. >> >> Again, I love efuses. They are great. Hope to see them in a device. >> But, how they are used, and more importantly how they are represented >> has to be fair and honest. >> >> Austin >> >> David Brown wrote: >>> Austin Lesea wrote: >>>> David, >>>> >>>> As to convenience, place a lithium coin cell on the pcb per the app >>>> note. Ask the software to generate a random key for you (or pick one >>>> yourself), send the key to the JTAG port. Verify the key can be >>>> written >>>> and read, then write it in secure mode (so it can not be read out again >>>> without it being erased immediately). Program eeprom or other memory >>>> with encrypted bitstream. >>>> >>>> Done. >>>> >>>> Not sure about Altera, as they have now told us they keep secrets from >>>> even their customers, and you have to sign an NDA. But, in theory, you >>>> get a key (does their software generate random 128 bit keys? Let us >>>> suppose it does), program the part (How? It is a secret! But let us >>>> imagine it is as simple as JTAG), an then place encrypted design in the >>>> memory. >>>> >>>> Done. >>>> >>>> So, we have one more step: make sure their is a lithium coin cell on >>>> the pcb connected to the Vbatt pin. >>>> >>>> That is the total level of inconvenience we offer. >>>> >>> Peter Alfke referred to Altera's solution as being more biased towards >>> convenience, while Xilinx's was more biased towards security. Since >>> Peter knows a great deal more than me about both security systems, I >>> assume that the difference in convenience is relevant (unless, of >>> course, he was referring to convenience for Altera rather than for the >>> customer). >>> >>> At the moment, and for the foreseeable future, I am not using either >>> Altera or Xilinx's bigger devices, and I am not overly concerned about >>> security. And I'm sure that if I did need such a design, then the >>> inconvenience of having a battery would not stop me using Xilinx - other >>> factors are more important. >>> >>> >>>> The benefit is that we offer all four levels of security in FIPS 140-2 >>>> compliance, and Altera offers no level of compliance at all with FIPS >>>> 140-2. >>>> >>>> What is so important about FIPS 140-2? It is the required security >>>> standard for the US Federal government, as well as for banks, networks, >>>> and others who are serious about security. >>>> >>>> Don't need FIPS 140-2? Then go ahead and use efuse keys. But also be >>>> aware of the risks. >>>> >>> The risks must be balanced, and it's important to know them (I don't, >>> obviously, but I've never needed to know). What's important is to >>> protect the IP, which means increasing the costs until it is impractical >>> for someone to steal it. You don't need a zero risk solution, you need >>> something with a risk that is known to be low enough. I presume that >>> Altera will give customers more detailed information when necessary - >>> although I think the Xilinx-style openness is better. >>> >>>> As for reverse engineering, I can send you presentations of how efuse >>>> technology smart cards are reverse engineered (hacked). It is a junior >>>> level EE project at most universities now. >>>> >>> I'm following this thread out of interest, and not from a need of >>> detailed knowledge. If you have public links of interest to others >>> here, post them here - others have questioned the accuracy of your >>> numbers and might like to see examples. It would of course be >>> interesting to hear Altera's viewpoint as well. >>> >>> As for sending anything directly to me - I appreciate the offer, but >>> there is no need, and it would be a waste of your time. Newsgroup posts >>> benefit more people. >>> >>> mvh., >>> >>> David >>> >>> >>>> Austin >>>> >>>> >>>> David Brown wrote: >>>>> Peter Alfke wrote: >>>>>> Let's not quibble over the price tag, and whether $10,000 is a >>>>>> meaningful hurdle. >>>>>> >>>>>> The debate was about key security, and the consensus in the crypto >>>>>> community is that things like efuses can be read out with moderate >>>>>> effort, while battery-backed up SRAM data is either much more >>>>>> secure or >>>>>> even perfectly secure, i.e. has never been cracked. >>>>>> >>>>>> Some people think batteries are a pain, others think they are just >>>>>> fine >>>>>> and last >15 years. >>>>>> >>>>>> It's security vs convenience. Xilinx picked security, Altera picked >>>>>> convenience. >>>>>> The choice is yours. Peter Alfke, Xilinx Applications >>>>>> >>>>> Any security system must be convenient, or it won't be used. A hefty >>>>> proportion of windows users have firewall software that came with >>>>> their >>>>> machines, but it's turned off - simply because it is too inconvenient. >>>>> When it's enabled, the firewall keeps asking these daft questions >>>>> about >>>>> whether your programs are allowed to do this or that - it's far easier >>>>> just to turn the stupid thing off. An advanced application level >>>>> software firewall may theoretically be more secure than a simple >>>>> "incoming bad, outgoing good" firewall, but it's no help if people >>>>> don't >>>>> use it. >>>>> >>>>> The same thing probably applies here. I've no experience with either >>>>> Altera's or Xilinx's solutions, but I can understand the principle >>>>> that >>>>> it's possible to read out efuses but not sram bits. If Altera's >>>>> solution is more convenient, then perhaps it is more secure in that >>>>> developers are more likely to use it? After all, all they need to >>>>> do is >>>>> choose some options in the software - there is no need to add >>>>> batteries >>>>> to the card, and to handle the support costs of dealing with lost keys >>>>> (users are so imaginative - "I took out the battery to make sure the >>>>> card got a proper reset"). >>>>> >>>>> As to how secure Altera's solution is - the Altera guys are not >>>>> idiots, >>>>> and it is unbecoming of you to them as such. Sure, it's possible to >>>>> read out the efuses in theory, but my guess is you're going to have to >>>>> do a lot more than just a couple of $5000 rounds. I'm sure there are >>>>> theoretical methods of breaking Xilinx's security too, such as probing >>>>> the bit stream out of the decoder. Since you have to get access to >>>>> the >>>>> device while power is on, it's going to be difficult - but I'm sure it >>>>> can be done given enough time and money (and boards to practise >>>>> on). To >>>>> be secure, all a method has to do is raise the stakes high enough that >>>>> alternative methods are cheaper - once it is easer and cheaper to >>>>> bribe >>>>> the original engineers for a copy of the code, the device is secure >>>>> enough.Article: 104482
Hi, Do you know "reverse engineering has the protection of law"? A good paper in http://www.fpgajournal.com/articles_2006/20060627_security2.htm tell the following story: the Supreme Court ruling that "A trade secret law, however, does not offer protection against discovery by fair and honest means, such as by independent invention, accidental disclosure, or by so-called reverse engineering, that is by starting with the known product and working backward to divine the process which aided in its development or manufacture." I don't know it until today after reading a reference by Austin Lesea and I would like others to share the information. WengArticle: 104483
New problem: When I send the 8-bit test data like for eg.X"31", it should appear on the screen as "01".However this is not taking place. The terminal has baud rate 19200, 8 data bits, 1 stop bit and no flow control. what do I have to specify as start and stop bits?? Moreover I am using the files obtained from Heron Engg...IF anyone has worked on this, lemme know. Thanks, Vivek Vivek Menon wrote: > Thanks Duane. > I have 16-bit data that needs to be converted to ASCII. > SO I guess I will have to take a nibble and convert it into its ASCII > equivalent and then give a space or next line to differentiate the next > word. > Thanks for the tip. > Vivek > Duane Clark wrote: > > Vivek Menon wrote: > > > does anybody have a function or package that converts data into ASCII?? > > > > You send one nibble (4 bits) at a time. If the nibble is between 0-9, > > then add 0x30 (hex 30). If between a-f, add 0x60. It should be easy to > > figure out how to do that in VHDL/Verilog. That will give you a hex display.Article: 104484
Thanks! We did not purchase the board in April, but it was a good
joke. It would have been a lot less confusing had the LCD not
displayed:
MEMORY I/F TOOLKIT
Freq Errors
DDR 166.7MHZ 000000
..... etc..
Or if the two technical support or two FAEs I spoke with would have
known or been able to find out anything out about the board.
After not being able to build all the images, I set the board aside due
to the poor documentation and lack of support. I will check the link
you provided and see if these projects can actually be built. Not all
the files that the FAEs had sent in the past would.
Thanks again for taking the time to dig into this!
Peter Alfke wrote:
> Hi "lecroy"
> I checked with the designer of that board.
> It seems that we did not explain the purpose of that cheap little LCD
> display. It is not there for debugging the meory interfaces. It is
> mainly for displaying some cute lines at shows and conferences.
> That's why we do no longer support any interfaces to it.
>
> Use CipScope for serious memory interface debugging.
> Here is what I learned from the designer:
>
> " Hi Peter,
> The LCD panel is merely a display demo and never calls out errors in
> the memory interfaces. In later releases we removed this code to avoid
> confusion.
>
Article: 104485I'm using all Xilinx tools, namely ISE WebPACK. So I am to the point where I've got my VHDL written, and when I send the program using iMPACT, it loads in SRAM and performs as expected. So I'm ready to get this project to my hardware guy to design the board for our product. My question is, what file do I actually write to the EEPROM that we'll have connected to the Spartan? I see the "Generate PROM, ACE, or JTAG file" task, but when I run that I receive the following error: Active mode is BS ERROR:iMPACT - base class function generate() is called. // *** BATCH CMD : quit Count ReleaseSemaphore rc = 298. Again, using the "Configure Device (iMPACT)" task I can run iMPACT and load the SRAM of my Spartan 3E, and the device does what it should. I just need help in figuring out what file I'll be wanting to send to the PROM we'll be using. Thanks! Alex McHaleArticle: 104486
Hi,
Does anyone know of a way to stop Synplify from pre-pending a "Z" to
names of top-level entity I/O signals which begin with an underscore
("_") when generating EDIF?
Thanks.
- Jacob
Article: 104487Can anyone tell me the true availability of Xilinx Virtex5 Engineering samples ? I have talked to distributors who say they can't get V5 parts until next year but I keep seeing Xilinx ads for the V5 saying shipping now. Does anyone know if samples would be available in the Sept time frame and how does one go about getting a couple of parts?Article: 104488
Vivek Menon wrote: > New problem: > When I send the 8-bit test data like for eg.X"31", it should appear on > the screen as "01".However this is not taking place. The terminal has > baud rate 19200, 8 data bits, 1 stop bit and no flow control. > what do I have to specify as start and stop bits?? Moreover I am using > the files obtained from Heron Engg...IF anyone has worked on this, I don't know what Heron Engg is. But X"31" will display as "1" not "01". Have you simulated it and seen what the output looks like? The output should be high when not sending data, there is a single bit '0' as the start bit, then the 8 bits of data LSB first, then a '1' stop bit. That can be immediately followed by another start bit if more data is ready to be sent, else the output remains at '1' until more data is ready to be sent. Each bit should be 1/19200 seconds or approximately 52uS, but that does not need to be exact; a few percent difference is tolerable. There should be an RS232 interface chip between the FPGA and your serial cable.Article: 104489
Weng Tianxiang wrote: > Hi Gabor, > Thank you for your response. > > I am living in California. Everything done by the notary is fine, but > no date. Yes, they did write correct thing in a log book that belongs > to theirs, but gave us anyt prove of the date. Is it enough when the > package is shown in a court if necessary? Did they do this for free ? Their invoice should give you a date ? If you also record this in your diary, that is another common legal reference. -jgArticle: 104490
I tried a few workaround possibilities with no joy. It looks like you're
stuck with the Z (or z). \Literals, no. Attribute syn_keep, no. Attribute
syn_edif_scalar_format in three flavors, no. IBUF instantiated, no.
Sounds like it's time for an enhancement request! I'd love to know if there
*was* a workaround outside of filtering the edif.
<jacob.bower@gmail.com> wrote in message
news:1151521299.696601.186170@i40g2000cwc.googlegroups.com...
> Hi,
>
> Does anyone know of a way to stop Synplify from pre-pending a "Z" to
> names of top-level entity I/O signals which begin with an underscore
> ("_") when generating EDIF?
>
> Thanks.
> - Jacob
>
Article: 104491Alex wrote: > I'm using all Xilinx tools, namely ISE WebPACK. > > So I am to the point where I've got my VHDL written, and when I send > the program using iMPACT, it loads in SRAM and performs as expected. > So I'm ready to get this project to my hardware guy to design the board > for our product. > > My question is, what file do I actually write to the EEPROM that we'll > have connected to the Spartan? I see the "Generate PROM, ACE, or JTAG > file" task, but when I run that I receive the following error: > > Active mode is BS > ERROR:iMPACT - base class function generate() is called. > // *** BATCH CMD : quit > Count ReleaseSemaphore rc = 298. > You don't get Impact? If not, right click on the "Generate PROM, ACE, or JTAG file" task and select "Properties...". Turn off "Automatically Generate PROM or ACE file". Try rerunning it. Impact should open up.Article: 104492
Your first place to go is your FAE either at your distributor or if you are a large user a direct Xilinx FAE. As with any new family there is a roll out schedule and some parts may be several months away from even sampling. Do be careful of using very new parts in a design if you are on a time critical schedule as very often new parts are on longer lead times and have patchy supply than more established families. Even you are given supply assurances I would plan a fall back position so you are in the position to do something and not simply waiting for some silicon to show up. I think every vendor of FPGA silicon has suffered delays from time to time with new products so do expect the worst and be pleasantly surprised when they deliver early or on time. John Adair Enterpoint Ltd. jeffnewcomb@nci-usa.com wrote: > Can anyone tell me the true availability of Xilinx Virtex5 Engineering > samples ? I have talked to distributors who say they can't get V5 parts > until next year but I keep seeing Xilinx ads for the V5 saying shipping > now. Does anyone know if samples would be available in the Sept time > frame and how does one go about getting a couple of parts?Article: 104493
Hello all, I am starting a brand new design, memory speed is not important (but depth is). This is my first time designing with any high speed memory. I have two questions: 1. Why does Micron data sheet say minimum clock is 8ns (125MHz). What happens when you run DDR2 at lower speed (refresh problems?) 2. My simulation (Hyperlynx) looks OK with no termination. Has any body tried running DDR2 at 125MHz with no termination whatsoever (only 10 ohm series with DDR2 inputs) I would really appreciate any response Thanks, -- NaveedArticle: 104494
Hi, is there any way to communicate with software running on a NIOS2 SOPC through JTAG from custom software on a Host PC? maybe via JTAG UART etc... Would be nice if nios2-terminal provided a method to connect to the JTAG UART from own applications through Unix or TCP sockets, or something similar. Would be perfect if there was a public specification or source code example how to access a JTAG UART within a SOPC over JTAG? We currently design a device where a serial interface is used just for maintenance work. The same data could be exchanged via JTAG UART if only we knew how to access it from our own software (Piping to and from nios2-terminal isn't exactly what I'm looking for). Kolja -- mr. kolja waschk - haubach-39 - 22765 hh - germany fon +49 40 889130-34 - fax -35 - http://www.ixo.deArticle: 104495
Hi Duane, Instead of the Heron Eng, I used tha xapp341.pdf file from Xilinx that describes an implementation of a RS232 transmitter and receiver. I used only the transmitter. The testbench simulates properly on Modelsim. Now I used a baud generator suggested in this grp by Peter Hermannson to divide the 100 MHz clock by 325.5 to get 19200 baud rate and provided it to the clk of the RS232 transmitter. This module has a strobe signal. I assigned a push button to it and inverted the logic levels so that it works similar to the test bench. Still I don't see anything on the terminal..Any pointers?? Thanks, Vivek Duane Clark wrote: > Vivek Menon wrote: > > New problem: > > When I send the 8-bit test data like for eg.X"31", it should appear on > > the screen as "01".However this is not taking place. The terminal has > > baud rate 19200, 8 data bits, 1 stop bit and no flow control. > > what do I have to specify as start and stop bits?? Moreover I am using > > the files obtained from Heron Engg...IF anyone has worked on this, > > I don't know what Heron Engg is. But X"31" will display as "1" not "01". > > Have you simulated it and seen what the output looks like? The output > should be high when not sending data, there is a single bit '0' as the > start bit, then the 8 bits of data LSB first, then a '1' stop bit. That > can be immediately followed by another start bit if more data is ready > to be sent, else the output remains at '1' until more data is ready to > be sent. Each bit should be 1/19200 seconds or approximately 52uS, but > that does not need to be exact; a few percent difference is tolerable. > > There should be an RS232 interface chip between the FPGA and your serial > cable.Article: 104496
The DDR2s use Delay Locked Loops to produce strobes and data in specific timing relative to the system clock. Specifying a lower limit in the DDR2 definition allows the silicon vendors to design a delay line of specific length to implement the DLL function. Terminations probably are not required at 125 MHz; you can terminate in and only in the DDR2 itself by always driving the On Die Termination. <visualfor@gmail.com> wrote in message news:1151528734.566004.218370@p79g2000cwp.googlegroups.com... > Hello all, > > I am starting a brand new design, memory speed is not important (but > depth is). This is my first time designing with any high speed memory. > I have two questions: > > 1. Why does Micron data sheet say minimum clock is 8ns (125MHz). What > happens when you run DDR2 at lower speed (refresh problems?) > 2. My simulation (Hyperlynx) looks OK with no termination. Has any > body tried running DDR2 at 125MHz with no termination whatsoever (only > 10 ohm series with DDR2 inputs) > > > > I would really appreciate any response > > Thanks, > > -- > Naveed >Article: 104497
> 1. Why does Micron data sheet say minimum clock is 8ns (125MHz). What > happens when you run DDR2 at lower speed (refresh problems?) The DLL in the memory chip won't lock. In practice you can bend the spec a little. > 2. My simulation (Hyperlynx) looks OK with no termination. Has any > body tried running DDR2 at 125MHz with no termination whatsoever (only > 10 ohm series with DDR2 inputs) Samsung have an app note on using DDR at slower speeds in embedded apps with short PCB tracks and no terminations.Article: 104498
jeffnewcomb@nci-usa.com wrote: > Can anyone tell me the true availability of Xilinx Virtex5 Engineering > samples ? I have talked to distributors who say they can't get V5 parts > until next year but I keep seeing Xilinx ads for the V5 saying shipping > now. Does anyone know if samples would be available in the Sept time > frame and how does one go about getting a couple of parts? > We are shipping X5VLX50 and XC5VLX110 in the -CES1 speed grade and the FF676 and FF1153 packages. There will be a lead time between placing an order and getting them as we are in the limited engineering sample phase, but your distributor sales person should take your order and then get back to you with a delivery date. Ed McGettigan -- Xilinx Inc.Article: 104499
Hi Jim, We paid cash $20 and didn't get invoice. Recording in diary requires 2 other experts in the field to sign their names to meet patent idea requirements. But this is my home project, I couldn't get even 1 expert to sign, not mention 2 experts. Weng Jim Granville wrote: > Weng Tianxiang wrote: > > Hi Gabor, > > Thank you for your response. > > > > I am living in California. Everything done by the notary is fine, but > > no date. Yes, they did write correct thing in a log book that belongs > > to theirs, but gave us anyt prove of the date. Is it enough when the > > package is shown in a court if necessary? > > Did they do this for free ? > Their invoice should give you a date ? > If you also record this in your diary, that is another common legal > reference. > > -jg
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z