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
Has anyone used avnet's V2P development kit? if so maybe you could help with some questions i've been struggling with. I am trying to use the device without using the PPC or EDK. I am trying to write data over the PCI bridge (a spartan IIe) to a shared SRAM, or data directly from the bridge through to the V2P if possible. I've been perusing the schematics and VHDL included with the simple memory project. One thing that I still don't understand is how the V2P gives control of the shared sram bus to the pci controller. I can see the signal TRGT_IRQ is a request from the pci for ownership of the bus, but how does the V2P respond to that request and through which I/O pin (to the bridge)? Also I downloaded the schematic for the sram (CY7C1062AV33) and notice that most of the data/control signals in the sram schematic map to the V2P directly (as far as the labels of the control signals). Some don't. For instance the sram has only 19 address pins whereas the V2P has 24 address pins. Which of these map to the 19 pins on the sram (through the Spartan)? Since there is one memory bus that is connected to SDRAM, Spartan2e, V2P. What determines which device will be written to/read from. Is this simply handled through a memory address offset? Also there are three pins (CE1,2,3) on the sram that seem to map to one signal (SRAM_CS_L). Is this correct? I cant really tell how they are being mapped since the bridge design docs dont really explain it. thanks for your help, -- Geoffrey Wall Masters Student in Electrical/Computer Engineering Florida State University, FAMU/FSU College of Engineering wallge@eng.fsu.edu Cell Phone: 850.339.4157 ECE Machine Intelligence Lab http://www.eng.fsu.edu/mil MIL Office Phone: 850.410.6145 Center for Applied Vision and Imaging Science http://cavis.fsu.edu/ CAVIS Office Phone: 850.645.2257Article: 86601
Austin Lesea wrote:
> Not really complex, but yes, it consumes area. And since mroe than 99%
> of present users don't use it
Maybe they don't use it because they don't have this feature implemented?
:-)
Cryptography is not the main reason for the existence of bitstream
encryption. It's simply too easy to clone an FPGA-based device.
BTW, is there any export limitation related to the FPGA chips with
embedded bitstream encryption? Most of the cryptographic devices
one can buy without special licenses use very short keys (40 bits or so),
so this would mean that FPGAs are not considered to be cryptographic
devices or they are, but they can be crackd by the NSA guys
(implemented using nonlinear keyspaces, internal secret keys, key
escrow systems and many other sophisticated ways.). What is the position
of the US government on this subject? (of course I would like to know
only the publically available facts -- I don't know much about this
interesting
issue).
Best regards
Piotr Wyderski
Article: 86602All, I have instatiated the SGMII block into my design and am attempting to get it to autonegotiate. It sends out the /C1/ and /C2/ ordered sets indefinetly with Config_Reg values equal to zero. I can never get it to send the correct Config_Reg values. Has anyone had this issue? Thanks...Article: 86603
In article <da121k$ke1@cliff.xsj.xilinx.com>, Austin Lesea <austin@xilinx.com> wrote: >Nick, > >No one has asked for what you mentioned. Probably for the reasons you >mention. It seems strange that they haven't asked, because both of these would be "Big Deal" improvements to what is very public knowledge and inference: The ability to load a NEW encryption key from within the FPGA is a very powerful feature: it allows a bunch of devices who's bitfile is initially encrypted with a common key to all customize themselves: The first time they are powered on by the customer, the device generates its new key, stores it in the key register, reencrypts the bitfile, and is happy. Now each instance has its own unique random key, that it can use to protect its own particular bitfile and secrets unique to that bitfile (other cryptokeys). Instances could also generate NEW keys giving some interesting/possible properties to generate forward security. Without this feature, you can only really do this under very restricted conditions (initial customer poweron) because it has to go in the clear over the JTAG pins. But with this feature, you can do it all the time, because an attacker who can monitor the "cleartext" wires WITHIN the FPGA already has probably broken the system. Partial reconfiguration when encryption is active is FAR more dangerous, as if you could trick the initial config to allow an attacker config to be loaded, all bets are off. But, OTOH, it would be a very, VERY big deal to the JTRS (Joint Tactical Radio System) crowd, as they are going to want to reconfigure large modules at runtime to do the software-defined radio which is the keystone of the system, yet also probably want the bitfile encryption over everything. >My biggest problem is that whatever we do for security needs to be so >incredibly well thought through, that adding something in the next >generation becomes a real issue. An added feature may bring on a whole >new set of issues that have to be thought through again! Yeup. Rekeying (WRITE only) from within the configuration is probably "not bad" on this. It needs to be thought through, but its pretty easy to wedge the device when rekeying (so it needs to be blanked/restarted), but pretty hard to un-safe the device. But allowing partial reconfig within the encrypted domain, even limited from within the FPGA, opens up a huge thorny set of potential issues. These issues would come up in particular configurations, but as Xilinx has to provide a lot of guidance to customers already on partial config. One question: Could you go to the spooks and guys with jitters about JTRS with "Here is what the open community THINKS that you want but are unwilling to say and why" and get a "yes" or "no" answer out of them? -- Nicholas C. Weaver. to reply email to "nweaver" at the domain icsi.berkeley.eduArticle: 86604
In article <da1f83$4qs$1@news.dialog.net.pl>, Piotr Wyderski <wyderskiREMOVE@ii.uni.wroc.pl> wrote: >BTW, is there any export limitation related to the FPGA chips with >embedded bitstream encryption? Most of the cryptographic devices >one can buy without special licenses use very short keys (40 bits or so), >so this would mean that FPGAs are not considered to be cryptographic >devices or they are, but they can be crackd by the NSA guys >(implemented using nonlinear keyspaces, internal secret keys, key >escrow systems and many other sophisticated ways.). What is the position >of the US government on this subject? (of course I would like to know >only the publically available facts -- I don't know much about this >interesting >issue). The crypto restrictions have largely gone away. Now its basically you can't sell serious crypto to the bad-actor countries. -- Nicholas C. Weaver. to reply email to "nweaver" at the domain icsi.berkeley.eduArticle: 86605
zoinks@mytrashmail.com wrote: > I already found the problem: > > apparentlythe ucf files are case sensitive, and I forgot a cap > d'oh! Yep -- That's one reason why it's usually convenient to start out with no constraints and run the tools once. Then back-annotate the pin list into the .ucf. Then you'll have all of the pins and their (assigned-by-the-tools locations. You can then go in with a text editor and change the pin locations, or use the GUI to do it. -aArticle: 86606
Piotr, There are no restrictions on Xilinx in selling or shipping the AES 256 bit decryptor in V4 (or any restrictions of the 3DES in VII, VII Pro, VII Pro-X). We are shipping an implimentation of the decryptor which is based on the NIST standard (c code available on line). Since the AES 256 is a standard, there are no restrictions on export. For a very short time, back when we introduced Virtex II, there were restrictions against shipping 3DES encryption to certain countries. This meant that we could not ship our software to those countries (as it has the encryption part coded into it). That restriction was later removed before we had to take any actions. Austin Piotr Wyderski wrote: > Austin Lesea wrote: > >> Not really complex, but yes, it consumes area. And since mroe than >> 99% of present users don't use it > > > Maybe they don't use it because they don't have this feature > implemented? :-) > > Cryptography is not the main reason for the existence of bitstream > encryption. It's simply too easy to clone an FPGA-based device. > > BTW, is there any export limitation related to the FPGA chips with > embedded bitstream encryption? Most of the cryptographic devices > one can buy without special licenses use very short keys (40 bits or so), > so this would mean that FPGAs are not considered to be cryptographic > devices or they are, but they can be crackd by the NSA guys > (implemented using nonlinear keyspaces, internal secret keys, key > escrow systems and many other sophisticated ways.). What is the position > of the US government on this subject? (of course I would like to know > only the publically available facts -- I don't know much about this > interesting > issue). > > Best regards > Piotr Wyderski >Article: 86607
Nicholas, Oh yes, I can play the game to find out. Right now, the JTRS crowd has decided to use a software uP, and not use reconfiguration of an FPGA. Seems that they already have all the c code, and they can't risk taking the time to convert it. They won't meet the power budget, they won't meet the size budget, and they won't meet the eventual requirements (as the uP is far too weak to do any of the newer and more powerful waveforms which are not required in the first phase of JTRS). They still need an FPGA for glue and some acceleration even with the uP. It is painful when you see how your tax dollars get mis-spent, first hand. Austin Nicholas Weaver wrote: > In article <da121k$ke1@cliff.xsj.xilinx.com>, > Austin Lesea <austin@xilinx.com> wrote: > >>Nick, >> >>No one has asked for what you mentioned. Probably for the reasons you >>mention. > > > It seems strange that they haven't asked, because both of these would > be "Big Deal" improvements to what is very public knowledge and > inference: > > The ability to load a NEW encryption key from within the FPGA is a > very powerful feature: it allows a bunch of devices who's bitfile is > initially encrypted with a common key to all customize themselves: > The first time they are powered on by the customer, the device > generates its new key, stores it in the key register, reencrypts the > bitfile, and is happy. > > Now each instance has its own unique random key, that it can use to > protect its own particular bitfile and secrets unique to that bitfile > (other cryptokeys). Instances could also generate NEW keys giving > some interesting/possible properties to generate forward security. > > Without this feature, you can only really do this under very > restricted conditions (initial customer poweron) because it has to go > in the clear over the JTAG pins. But with this feature, you can do it > all the time, because an attacker who can monitor the "cleartext" > wires WITHIN the FPGA already has probably broken the system. > > > > Partial reconfiguration when encryption is active is FAR more > dangerous, as if you could trick the initial config to allow an > attacker config to be loaded, all bets are off. But, OTOH, it would > be a very, VERY big deal to the JTRS (Joint Tactical Radio System) > crowd, as they are going to want to reconfigure large modules at > runtime to do the software-defined radio which is the keystone of the > system, yet also probably want the bitfile encryption over everything. > > > >>My biggest problem is that whatever we do for security needs to be so >>incredibly well thought through, that adding something in the next >>generation becomes a real issue. An added feature may bring on a whole >>new set of issues that have to be thought through again! > > > Yeup. Rekeying (WRITE only) from within the configuration is probably > "not bad" on this. It needs to be thought through, but its pretty > easy to wedge the device when rekeying (so it needs to be > blanked/restarted), but pretty hard to un-safe the device. > > But allowing partial reconfig within the encrypted domain, even > limited from within the FPGA, opens up a huge thorny set of potential > issues. These issues would come up in particular configurations, but > as Xilinx has to provide a lot of guidance to customers already on > partial config. > > > One question: Could you go to the spooks and guys with jitters about > JTRS with "Here is what the open community THINKS that you want but > are unwilling to say and why" and get a "yes" or "no" answer out of > them? >Article: 86608
Why not a small microcontroller like a PIC 10F series?Article: 86609
In article <da1jce$1cr1@cliff.xsj.xilinx.com>, Austin Lesea <austin@xilinx.com> wrote: >Nicholas, > >Oh yes, I can play the game to find out. > >Right now, the JTRS crowd has decided to use a software uP, and not use >reconfiguration of an FPGA. > >Seems that they already have all the c code, and they can't risk taking >the time to convert it. > >They won't meet the power budget, they won't meet the size budget, and >they won't meet the eventual requirements (as the uP is far too weak to >do any of the newer and more powerful waveforms which are not required >in the first phase of JTRS). They still need an FPGA for glue and some >acceleration even with the uP. They want to do a uP version of all those standards? ICK. CDMA alone is a pain in da butt (and one of the standards supposed to be supported: JTRS radios include cellphone functionality too), let alone the UWB stuff they want to do. >It is painful when you see how your tax dollars get mis-spent, first hand. It would actually be cool to do the "Calm" project as an alternative: A multiband software radio with all the cool crypto stuff in an FPGA platform, just to show how superior FPGAs are for stuff like that. :) -- Nicholas C. Weaver. to reply email to "nweaver" at the domain icsi.berkeley.eduArticle: 86610
On Thu, 2005-06-30 at 06:56 -0700, Shai wrote: > Hello, > > Is there any way of converting an .mcs file into a bit file....in > Xilinx FPGAs If you have a board with PROM and FPGA then program the mcs file into the PROM, cycle the power to the board to load the FPGA, and then read the design out of the FPGA using Impact and save the result as your bit file. James.Article: 86611
if no interest,u can ignore this topic.Article: 86612
I'm playing around with sigma-delat ADC and DAC for audio. It's amazing
how good this works without any active components. Just Rs and Cs.
The question now is: Can I hook a speaker direct to the output pins of
an FPGA?
The idea is to omit any passive components as the speaker acts as
low-pass filter and to use two pins, feeding one with the inverted
sigma-delta stream (or PDM), to build a bridge amplifier (class D?).
With 3V3 output swing this should result (on an 8 Ohm speaker) in an
output power of:
Peff = Ueff^2/R = (Up/sqrt(2))^2/R =
= (3.3V/2*sqrt(2)/sqrt(2))^2/8Ohm = 340mW
First question: Is the multiplication with sqrt(2) correct? The idea
is that it is a class D amplifier with rectangular output resulting
in a sine wave that is sqrt(2) times higher than Up of the square wave.
Second question: Is the inductive load from the speaker an issue for
the output drivers?
Martin
Article: 86613On Thu, 30 Jun 2005 14:52:21 -0700, Martin Schoeberl wrote: > I'm playing around with sigma-delat ADC and DAC for audio. It's amazing > how good this works without any active components. Just Rs and Cs. > > The question now is: Can I hook a speaker direct to the output pins of > an FPGA? > > The idea is to omit any passive components as the speaker acts as > low-pass filter and to use two pins, feeding one with the inverted > sigma-delta stream (or PDM), to build a bridge amplifier (class D?). > With 3V3 output swing this should result (on an 8 Ohm speaker) in an > output power of: > > Peff = Ueff^2/R = (Up/sqrt(2))^2/R = > = (3.3V/2*sqrt(2)/sqrt(2))^2/8Ohm = 340mW > > First question: Is the multiplication with sqrt(2) correct? The idea is > that it is a class D amplifier with rectangular output resulting in a > sine wave that is sqrt(2) times higher than Up of the square wave. > > Second question: Is the inductive load from the speaker an issue for the > output drivers? > > Martin I think the thing you have forgotten is the output driver resistance (or drive current capability). Peak current would be ~400 mA! Would probably work ok with about 20 outputs in parallel... (or one of those little PMOS/NMOS SOT23 MOSFET pairs) Peter WallaceArticle: 86614
Martin Schoeberl wrote: > I'm playing around with sigma-delat ADC and DAC for audio. It's amazing > how good this works without any active components. Just Rs and Cs. > > The question now is: Can I hook a speaker direct to the output pins of > an FPGA? > > The idea is to omit any passive components as the speaker acts as > low-pass filter and to use two pins, feeding one with the inverted > sigma-delta stream (or PDM), to build a bridge amplifier (class D?). > With 3V3 output swing this should result (on an 8 Ohm speaker) in an > output power of: > > Peff = Ueff^2/R = (Up/sqrt(2))^2/R = > = (3.3V/2*sqrt(2)/sqrt(2))^2/8Ohm = 340mW > > First question: Is the multiplication with sqrt(2) correct? The idea > is that it is a class D amplifier with rectangular output resulting > in a sine wave that is sqrt(2) times higher than Up of the square wave. > > Second question: Is the inductive load from the speaker an issue for > the output drivers? > > Martin TI have a range of Class D amplifiers, so their data gives good info on Filterless Class D. You are pushing things a little doing this straight into the FPGA [ I hope it's a cheap one :) ] If you work 3.3V / 8 Ohms, that's 412mA, into a bridge load, you are asking for - from a single IO pin.... ?! Possibly on a whole port/bridge side ? -jgArticle: 86615
So you would have one pin driving a High into the 8 Ohm speaker, while the other pin sinks a Low. No pin would ever be negative, but you have the drive impedance plus the sink impedance in series with the speaker. Each of the three might be around 8 Ohm, for a total of 24 Ohm, and a peak current closer to 100 mA. If you pick the strongest output standard, you still will have limited aplitude. I agree with the suggestion of a low-cost Clas-D amplifier instead. Peter AlfkeArticle: 86616
Minimum wrote: > if no interest,u can ignore this topic. His point is that there very likely will *be* no interest. IANAL, but it would seem pretty clean that any company using stolen IP like this could be in a world of legal hurt. Have you considered that in addition to that, people belonging to the companies from which the IP originated may well also read this newsgroup? JeremyArticle: 86617
Hi! I've already googled and dug through several online lists of FPGA boards, but haven't found what I'm looking for, yet. I'm needing a Cyclone board that has at least 32 LVDS I/O pins available (and terminated). With at least one PLL available to be driven from an external source. Target price of less than $500 U.S. Thanks, KeithArticle: 86618
The chapter on Semaphore Synchronization on pg. 128 and Appendix D on pg. 537ff of http://www.xilinx.com/bvdocs/userguides/ppc_ref_guide.pdf provide detailed information about lwarx and stwcx. lwarx and stwcx. are low-level assembly instructions always operating on a single word. They are used to implement higher-level constructs like semaphores or critical section that can then be used to atomically access larger sections of memory. Appendix D lists some examples. - Peter Gladiator wrote: > Hi, > > I am working with the PPC405 processor on a Virtex2Pro board and was > wondering if it's possible to access the reservation granule where > reservations for the semaphore instructions <i>lwarx</i> and > <i>stwcx</i> are set? > > Your help will be greatly appreciated > > Robin Maleche >Article: 86619
This will work only if the prtPUSH_BUTTON1 is not an external clock. But if we are using the edge of this signal the tool will assume that it is a clock signal and assigns the BUFGP buffer for that this will conflict with the .ucf constarins and will give error at the time of mapping. We must use the .ucf as you suggested but then there should be a way to disable the clock buffereing at the time of synthesize.Article: 86620
Using a push button as a clock input to modern fast logic is an invitation to disaster. The contact bounce will play havoc with your design. Peter Alfke vssumesh wrote: > This will work only if the prtPUSH_BUTTON1 is not an external clock. > But if we are using the edge of this signal the tool will assume that > it is a clock signal and assigns the BUFGP buffer for that this will > conflict with the .ucf constarins and will give error at the time of > mapping. > We must use the .ucf as you suggested but then there should be a way to > disable the clock buffereing at the time of synthesize.Article: 86621
Andy Peters wrote: > zoinks@mytrashmail.com wrote: >> I already found the problem: >> >> apparentlythe ucf files are case sensitive, and I forgot a cap >> d'oh! > > Yep -- That's one reason why it's usually convenient to start out with > no constraints and run the tools once. Then back-annotate the pin list > into the .ucf. Then you'll have all of the pins and their > (assigned-by-the-tools locations. You can then go in with a text > editor and change the pin locations, or use the GUI to do it. > > -a Another small hint: if you are trying to constrain internal nets, make sure you did not select the flatten option. If your design is flattened, the hierarchy and net names will change and will be renamed. Regards, rudi ============================================================= Rudolf Usselmann, ASICS World Services, http://www.asics.ws Your Partner for IP Cores, Design, Verification and Synthesis ****** Certified USB 2.0 HS OTG and HS Device IP Cores ******Article: 86622
geoffrey wall wrote: > Has anyone used avnet's V2P development kit? Nope. > Since there is one memory bus that is connected to SDRAM, Spartan2e, V2P. > What determines > which device will be written to/read from. Is this simply handled through a > memory address offset? My guess is that you would have an address decoder - this is the standard way - for instance, given 4 equal size memory spaces, you can drive a chip select off the top two bits, ie 00xxxxxxxxxxxxxxxxxxxxxxxxxxxxx = Device 1 01xxxxxxxxxxxxxxxxxxxxxxxxxxxxx = Device 2 10xxxxxxxxxxxxxxxxxxxxxxxxxxxxx = Device 3 11xxxxxxxxxxxxxxxxxxxxxxxxxxxxx = Device 4 > Also there are three pins (CE1,2,3) on the sram that seem to map to one > signal (SRAM_CS_L). Is this correct? Likely - often these devices have multiple chip enables, some active-high and some active-low, so that you can bank a few of them up with a few bits of copper, rather than having to have an extra address decoder. You'd have to check the datasheet for the ram, and see if the SRAM_CS_L signal is driven out as-is to the RAM (check if it matches). > I cant really tell how they are being mapped since the bridge design docs > dont really explain it. You might want to try simulating the design, to see how it works - build a board level testbench and a simple PCI stimulator, and see what it does. This might be an easy way of better understanding the design. Often the memory manufacturers have models of their chips (in verilog, vhdl or other format), which may help. I suspect you may have to find some further documentation as well. Are there other sample designs? You may be able to compare them to glean more information. JeremyArticle: 86623
fortiz80@gmail.com wrote: > Hi all, > > Xilinx has announced support for DDR2 up to 533 MHz. Are there any > physical limitations that won't allow higher frequencies to be used? Umm.. That's 533M*bit* (267MHz). You could try: a) Working through the app notes (I know at least some of them have timing budget calculations) b) Attempting to build a simple design using something like the memory interface generator, and targeting it to a specific chip. These might provide you with more information.. My guess would be that losing 350 ps odd off the timing budget would be the killer - the question of why could probably be answered by examining it in the above fashion. I'd be curious myself actually - particularly if you ran through these and came to the conclusion that it could be done... JeremyArticle: 86624
Jedi wrote: > Hello... > > Wasn't there once an application note on Actel.com > for initialising internal RAM from an SPI memory? > > > rick Yes, and it is still there: http://www.actel.com/documents/EmbeddedSRAMInit_AN.pdf
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