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 Alex, I can take a look at it if you send it to me. /Mikhail "Alex" <alexmchale@gmail.com> wrote in message news:1150894390.663027.173230@g10g2000cwb.googlegroups.com... > In that case, that did not solve the problem. That was already > enabled. > > Any other thoughts? This is a complete road block for me in > development. I just don't understand why this thing won't work with > anything more complicated than directly wiring the switch to the LED. > > I can send a zip of my project to anyone willing to help. I'm using > Xilinx 8.1i WebPACK, with the latest service pack. > > Thank you. > > Alex McHale > > Ben Jones wrote: > > "Alex" <alexmchale@gmail.com> wrote in message > > news:1150821352.453929.125790@c74g2000cwc.googlegroups.com... > > > Yes, I am indeed using XST. Where is this "add I/O pads" option within > > > ISE? > > > > Process Properties for XST | Xilinx Specific Options | Add I/O Buffers > > (should be checked). > > > > Cheers, > > > > -Ben- >Article: 104226
Further, At least no one will tell us they broke into the chip. It could be that when the students worked at it for awhile, they realized that since they couldn't break it, there would be no degree, so they moved on to something easier to break into. I am sure that certain non-existent agencies spent more time hacking at it. But since they never tell anyone anything, I am just guessing. Obviously with enough money and enough time ... there is no 'perfect' lock. But we are in full compliance with FIPS 140-2. And we also have AES256 which is considered acceptable for the most secure crypto boxes. AES128 is not considered 'secure' enough. Don't ask me why, as the details are secret, and I am not cleared. I just hear and obey. I am sure that if AES128 had battery backed key storage, it would be perfectly good for any commercial crypto application. After all, today we use 3DES which is only 2E112 hard, and that is now considered within the reach of a mid-level attack. 2E128 provides only (only?) a 16 fold improvement over 2E112.... Austin Austin Lesea wrote: > backhus, > > That is something that we thought about. But, really what we talking > about is providing access to the crypto-engine through the general > interconnect, and control of that engine. > > It was considered that anything we do in this regard would have to be > completely and thoroughly tested so as not to be a back door, and > compromise security. > > It wasn't worth the work to have to prove we did not break something. > > Even the JTAG is considered a real threat to security, so we have a > method of disabling it once you have been configured with your encrypted > bitstream (in V4 and V5). > > Kevin of FPGA Journal is looking for student interns for some security > fun (in FPGAs). If anyone is interested, email me directly. > > We submitted our V2 Pro to 9 schools and universities (and some > non-existent agencies) three years ago, and no one has broken the > security, or even compromised it. That is what our security is about: > we gave the students the complete schematics of the PCB, provided series > access for PDA attacks, etc. All we asked was: tell us the key, or > make the TRNG deliver non-random numbers (affect operation). We wqnt to > know every weakness so we can fix it in the next version (and hopefully > not break anything). > > Austin > > backhus wrote: >> Hi Austin, >> besides everything concerning the security gain of an encrypted >> bitstream I have a different question. >> >> Xilinx offers a similar feature too in its Virtex4 (and 5?) FPGAs. >> Now, that some silicon already is used up by the AES algorithm, wouldn't >> it be nice to make it accessible to the custumer? Just the Keyscheduler >> and the round function, not the key memory. >> >> Would be a nice feature for some custumers, but (nearly) no drawback for >> all others. >> >> Best regards >> EilertArticle: 104227
One more thing... The 'solution' for Startix II requires an NDA for how to program the keys. Now, since there is 'no security through obscurity', this means that there is something they wish to hide. A back door? A flaw? Whatever it is, it must be a goodie... Full disclosure, and an open invitation to help us improve our solution. That is what Xilinx offers. Austin Austin Lesea wrote: > backhus, > > That is something that we thought about. But, really what we talking > about is providing access to the crypto-engine through the general > interconnect, and control of that engine. > > It was considered that anything we do in this regard would have to be > completely and thoroughly tested so as not to be a back door, and > compromise security. > > It wasn't worth the work to have to prove we did not break something. > > Even the JTAG is considered a real threat to security, so we have a > method of disabling it once you have been configured with your encrypted > bitstream (in V4 and V5). > > Kevin of FPGA Journal is looking for student interns for some security > fun (in FPGAs). If anyone is interested, email me directly. > > We submitted our V2 Pro to 9 schools and universities (and some > non-existent agencies) three years ago, and no one has broken the > security, or even compromised it. That is what our security is about: > we gave the students the complete schematics of the PCB, provided series > access for PDA attacks, etc. All we asked was: tell us the key, or > make the TRNG deliver non-random numbers (affect operation). We wqnt to > know every weakness so we can fix it in the next version (and hopefully > not break anything). > > Austin > > backhus wrote: >> Hi Austin, >> besides everything concerning the security gain of an encrypted >> bitstream I have a different question. >> >> Xilinx offers a similar feature too in its Virtex4 (and 5?) FPGAs. >> Now, that some silicon already is used up by the AES algorithm, wouldn't >> it be nice to make it accessible to the custumer? Just the Keyscheduler >> and the round function, not the key memory. >> >> Would be a nice feature for some custumers, but (nearly) no drawback for >> all others. >> >> Best regards >> EilertArticle: 104228
Try commenting out the very first line of your UCF file (add # symbol in the beginning of the line). It seems as the pin you chose is not a proper clock pin... /Mikhail "Alex" <alexmchale@gmail.com> wrote in message news:1150896252.928027.280080@c74g2000cwc.googlegroups.com... > Delving a bit deeper, I see that I am getting the following warnings > before the final error. When I disable "Add I/O Buffers," I get these > warnings on all of my lines. When it is enabled, I only get it for my > CLOCK. > > While I'm sure my net list is correct, this must be a symptom of the > issue that's preventing my vhdl to load. > > Any ideas? > > > > > WARNING:NgdBuild:483 - Attribute "LOC" on "CLOCK" is on the wrong type > of > object. Please see the Constraints Guide for more information on > this > attribute. > WARNING:NgdBuild:483 - Attribute "IOSTANDARD" on "CLOCK" is on the > wrong type of > object. Please see the Constraints Guide for more information on > this > attribute. >Article: 104229
Hi,
has anybody used before Celoxica's FPGA board RC10 with Xilinx's EDK
kit? Somehow, the bit stream I create, yields 'configuration error'
whenever I used the FTU3 utility provided by Celoxica to download the
bit file generated separately by EDK.
I even tried exporting the EDK flow, such that ISE will be
separately used to synthesize the design and generate the bit file. In
this case, the bit stream no longer yields 'configuraton error'.
However, the bit file does not work at all when I used the FTU3 utility
to download the bitstream.
I tried using only ISE standalone to synthesize a design and
generate the bit file, and only this works with the FTU3 utility
Anybody has any advice for me? I am currently using Celoxica's RC10
board for implementation of some microblaze based design.
thanks!
Chris
Article: 104230jmariano wrote: > Dear All, > <snip>> > Now, here is the strange part: > > - If I connect all the modules to pins in the FPGA, using, of course, > the .UCF file, the code > does not run. It freezes after only a few lines. The first line of my > code is a printf statement, > and only a few characters are sent to the uart. After that, noting else > happens. > > - If I comment, in the UCF file the, lines connecting the output GPIO > to the FPGA pins, the program runs as it is suppose to run (the input > GPIO is, for now, commented). > That is strange. I'd check the following: - make sure interrupts are disabled - if you are using 'printf' and not 'xil_printf' then the stack space requirements will be high. Check your linker script to make sure you are allocating enough space on the stack. - connect to the target using XMD, and see where exactly the processor is stalled. Correlate the PC back to the sources and see if you can spot the bug. - try using the Virtual Platform tool for your design. In cases that it does work, it spots invalid memory accesses earlier.. /SivaArticle: 104231
> > Unless ofcourse his code cycles through perverse data structures say 17 > blocks, always defeating the cache associativity design. > > If the code is such that performance is consistant for varying > scenarios, it has probably worked out okay, but if throughput drops for > some patterns, look for thrashing. So it doesn't hurt to know the > caches associative model to anticipate that. > > John Jakson > Unless you want complete control, you should just let the processor figure out what needs to be cached. If not, you have a few options: 1. Put the code you want to be cached in a separate section and load it directly into the cache. Some earlier posts by Peter Ryser would have more details on this. The disadvantage of this would be that there might be space in the cache that will be unused.. 2. Add a few BRAMs to OCM memory, and place your code there. This provides constant access times..However you are wasting BRAMS. /SivaArticle: 104232
Andy wrote: > I'm not sure I understand how your simplified state table optimization > is going to find identical sequences of states, since the individual > states do not have identical from's and to's compared to any other > individual states, but the sequence as a whole may be identical to > another sequence as a whole. This is why it is a multi-pass algorithm: If one sequence of states is identical to another sequence of states, then in particular the last state of each sequence is identical, and may be easily recognized and collapsed. Repeating on the new state machine, which has one less state than the original, uncovers that the next to last states (of the original) are also equivalent, and may be collapsed...each pass uncovers another equivalent state until the entire equivalent sequence is reduced.Article: 104233
Hi, I am currently using the Virtex-II Pro FPGA FF672 evaluation board from Xilinx. I have implemented the Aurora protocol and used that to send my modulated spectrum through the MGTs onto a spectrum analyzer. Now I have got a weird task: There's a Virtex-II Pro FPGA that receives data from 4 MGTs at 10Gbits/sec. Is it possible to combine the data and send it out at 40 Gbits/sec on the Rocket I/O?? I can only think of a multiplexer that selects one of the 10Gbits/sec and send it out on the Rocket I/O (the speed would be the same). 40 Gbits/sec--> I have no idea. Do let me know if you have come across such a problem and are aware of any solutions/pointers?? Thanks, VivekArticle: 104234
Hi, I am searching for a detachable Virtex-II Pro or a Virtex-4 FX series FPGA with rocket I?O capability. I do not want a huge evaluation board. After I program the FPGA and the Rocket I/O, I need to detach the board/mini-module. Please let me know if you are aware of such mini-modules. Thanks, VivekArticle: 104235
Mike Treseler wrote:
> I'll try your code on ISE and quartus when I get to work.
This file:
http://home.comcast.net/~mike_treseler/ffff.vhd
synthesizes fine with quartus 6.0 and ise8.1i
using a clean project and default contraints.
http://home.comcast.net/~mike_treseler/ffff.pdf
-- Mike Treseler
Device utilization summary:
---------------------------
Selected Device : 4vfx12sf363-12
Number of Slices: 3 out of 5472 0%
Number of Slice Flip Flops: 4 out of 10944 0%
Number of 4 input LUTs: 4 out of 10944 0%
Number of bonded IOBs: 6 out of 240 2%
Number of GCLKs: 1 out of 32 3%
---------------------------
Constraint | Requested| Actual |
Autotimespec constraint for clock net | N/A | 1.190ns|
Article: 104236Vivek, the present state-of-the-art in CMOS-FPGAs is that: 3.125 Gbps is fairly easy with dedicated transceivers (unidirectional, differential) 6 Gbps is doable in the same way 10 Gbps is very demanding, but has been proven to be possible, anything faster is impossible for a few years to come. The world of dedicated chips using exotic technologies may be different. Peter Alfke, Xilinx Applications ============ Vivek Menon wrote: > Hi, > I am currently using the Virtex-II Pro FPGA FF672 evaluation board from > Xilinx. I have implemented the Aurora protocol and used that to send my > modulated spectrum through the MGTs onto a spectrum analyzer. > Now I have got a weird task: > There's a Virtex-II Pro FPGA that receives data from 4 MGTs at > 10Gbits/sec. Is it possible to combine the data and send it out at 40 > Gbits/sec on the Rocket I/O?? > I can only think of a multiplexer that selects one of the 10Gbits/sec > and send it out on the Rocket I/O (the speed would be the same). 40 > Gbits/sec--> I have no idea. > Do let me know if you have come across such a problem and are aware of > any solutions/pointers?? > Thanks, > VivekArticle: 104237
Thanks for the pointer, Peter. But is there any way of combining say 4 X 2.5 Gbit/sec Rocket I/Os and send a 10 Gbits/sec on another Rocket I/O. Even the proof of concept will suffice. Thanks, Vivek Peter Alfke wrote: > Vivek, the present state-of-the-art in CMOS-FPGAs is that: > > 3.125 Gbps is fairly easy with dedicated transceivers (unidirectional, > differential) > 6 Gbps is doable in the same way > 10 Gbps is very demanding, but has been proven to be possible, > anything faster is impossible for a few years to come. > > The world of dedicated chips using exotic technologies may be > different. > Peter Alfke, Xilinx Applications > > ============ > Vivek Menon wrote: > > Hi, > > I am currently using the Virtex-II Pro FPGA FF672 evaluation board from > > Xilinx. I have implemented the Aurora protocol and used that to send my > > modulated spectrum through the MGTs onto a spectrum analyzer. > > Now I have got a weird task: > > There's a Virtex-II Pro FPGA that receives data from 4 MGTs at > > 10Gbits/sec. Is it possible to combine the data and send it out at 40 > > Gbits/sec on the Rocket I/O?? > > I can only think of a multiplexer that selects one of the 10Gbits/sec > > and send it out on the Rocket I/O (the speed would be the same). 40 > > Gbits/sec--> I have no idea. > > Do let me know if you have come across such a problem and are aware of > > any solutions/pointers?? > > Thanks, > > VivekArticle: 104238
On 2006-06-21, eascheiber@yahoo.com <eascheiber@yahoo.com> wrote:
> I suspect though that most of the times only a portion of the code is
> used that would
> fit into the cache. Is there a way I could ensure that this part of my
> code is so compiled
> that it could be all loaded into the cache at a time? I welcome any
> sugestions.
If you're worried about tag collisions preventing your code from all being
cached, the easiest way to avoid that would be to make sure the cachable
part is all contiguous.
One way to do this in the GNU toolchain is to make a custom link script
with a block like (nb you need an entire link script around this!):
.text : { *(cache) *(.text) }
Then you can use __attribute__ ((section ("cache"))) to put functions
there (you can hide that in a macro) (it goes between the return type
and the function name). You can turn that around and have a 'rare'
section and move that out to leave the rest close together.
--
Ben Jackson
<ben@ben.com>
http://www.ben.com/
Article: 104239www.xilinx.com/ml402 It has an SX35 though.. -Siva Peter Moreton wrote: > Hi, > > I am looking for an FPGA development board that can host a Xilinx > Virtex-4 XC4VSX25 device, because it has 128 multipliers and is > supported by the free Xilinx ISE Webpack edition - however, much > Googling has not turned up a board with this device. > > Can anyone tell me if a development board that hosts the Xilinx 'SX25 > exists? - ideally this would have a PCI/PCI-X/PCI-E interface, but > USB etc might be OK also. > > ThanksArticle: 104240
I snagged a different computer, installed WebPACK, the service packs, and tried again. It worked. It would appear that something is "broken" in my install on my workstation. Now to figure out how to program the flash so that the circuit "sticks" between power cycles... Thanks for looking. I appreciate it. Mike Treseler wrote: > Mike Treseler wrote: > > > I'll try your code on ISE and quartus when I get to work. > > This file: > > http://home.comcast.net/~mike_treseler/ffff.vhd > > synthesizes fine with quartus 6.0 and ise8.1i > using a clean project and default contraints. > http://home.comcast.net/~mike_treseler/ffff.pdf > > -- Mike Treseler > > > Device utilization summary: > --------------------------- > Selected Device : 4vfx12sf363-12 > Number of Slices: 3 out of 5472 0% > Number of Slice Flip Flops: 4 out of 10944 0% > Number of 4 input LUTs: 4 out of 10944 0% > Number of bonded IOBs: 6 out of 240 2% > Number of GCLKs: 1 out of 32 3% > --------------------------- > Constraint | Requested| Actual | > Autotimespec constraint for clock net | N/A | 1.190ns|Article: 104241
Vivek Menon wrote: > Hi, > I am searching for a detachable Virtex-II Pro or a Virtex-4 FX series > FPGA with rocket I?O capability. I do not want a huge evaluation board. > After I program the FPGA and the Rocket I/O, I need to detach the > board/mini-module. > Please let me know if you are aware of such mini-modules. > Thanks, > Vivek > I don't understand what you want to do. You need to provide more details if anyone is to be able to help you. Ed McGettigan -- Xilinx Inc.Article: 104242
Sorry for the uninteresting post, but I was trying my Altera design in ISE 8.1i and XST crashed immediately with FATAL_ERROR:Xst:Portability/export/Port_main.h:127:1.16 - This application has discovered an exceptional condition from which it cannot recover. Process will terminate etc. I tried to file a WebSupport case, but I can kind of understand the previous rant thread here as it is a really frustrating experience; I even tried resetting my password, but the login system doesn't give me access (this happens for both firefox and IE). Xilinx should probably look into this seriously as I'm sure that most would just give up and not report the bugs. I the meantime, if someone from Xilinx cares about this bug, please contact me directly (tommy-xilinx (at) numba-tu.com). All the best, TommyArticle: 104243
Vivek Menon wrote: > Thanks for the pointer, Peter. > But is there any way of combining say 4 X 2.5 Gbit/sec Rocket I/Os and > send a 10 Gbits/sec on another Rocket I/O. Even the proof of concept > will suffice. There are Virtex-II Pro X parts that have 10Gbit/s-capable RocketIOs, so with those it should be possible to have 4x2,5 Gbit/s coming in on 4 RocketIOs and send out 10gbit/s through another RocketIO. But the Pro X parts are hard to come by. cu, SeanArticle: 104244
Hi Sean, Can you please elaborate on Virtex-II Pro X and the technique to combine 4x2.5 Gbit/sec into 10 Gbit/sec? Thanks, Vivek Sean Durkin wrote: > Vivek Menon wrote: > > Thanks for the pointer, Peter. > > But is there any way of combining say 4 X 2.5 Gbit/sec Rocket I/Os and > > send a 10 Gbits/sec on another Rocket I/O. Even the proof of concept > > will suffice. > There are Virtex-II Pro X parts that have 10Gbit/s-capable RocketIOs, so > with those it should be possible to have 4x2,5 Gbit/s coming in on 4 > RocketIOs and send out 10gbit/s through another RocketIO. But the Pro X > parts are hard to come by. > > cu, > SeanArticle: 104245
> Eric,
> Any news from sourceforge ?
> http://xc3sprog.sourceforge.net/
> seems not available... is the rigth address ?
>
> Sandro
They created it this afternoon; it should be up! I'm going to import
the original code into svn right now...
...Eric
Article: 104246Hi Ed, I recently bought the Virtex-4 FX12 mini-module from Avnet and used it to implement some designs(ref: http://www.em.avnet.com/evk/home/0,1719,RID%253D0%2526CID%253D25726%2526CCD%253DUSA%2526SID%253D0%2526DID%253DDF2%2526LID%253D0%2526PVW%253D%2526BID%253DDF2%2526CTP%253DEVK,00.html). The mini-module has advantages(I presume) due to its smaller size and can be easily removed from the base-board. After implementing high speed designs on Virtex-II Pro using Rocket I/O(reference: Virtex-II Pro FF672 dev board from Xilinx), I would like to acquire a similar kind of mini-module that has the Virtex-II Pro or Virtex-4 FX FPGA with the Rocket I/O ports on the mini-module. It eases the problems while showing a demo and moreover clients are impressed with the small form factor of the mini-modules as compared to the huge evaluation boards. I hope this description is adequate. Please let me know if you know of any such boards. Thank you, Vivek Ed McGettigan wrote: > Vivek Menon wrote: > > Hi, > > I am searching for a detachable Virtex-II Pro or a Virtex-4 FX series > > FPGA with rocket I?O capability. I do not want a huge evaluation board. > > After I program the FPGA and the Rocket I/O, I need to detach the > > board/mini-module. > > Please let me know if you are aware of such mini-modules. > > Thanks, > > Vivek > > > > I don't understand what you want to do. You need to provide more > details if anyone is to be able to help you. > > Ed McGettigan > -- > Xilinx Inc.Article: 104247
Vivek Menon schrieb: > Hi Sean, > Can you please elaborate on Virtex-II Pro X and the technique to > combine 4x2.5 Gbit/sec into 10 Gbit/sec? Very simple. The key word is channel bonding. This is done every day in the 10G XAUI interfaces. So the idea is not new and it is doable without too much trouble. Regards Falk P.S. The 4x2.5G is 4x3.125G due to 8B10B coding.Article: 104248
I'm using a V2Pro based eval board with a simple set of frimware and
software files. The software set includes the Xvectors.S file from the
EDK library and I want/expect the code in the xvectors.S file to be
loaded into memory with the image.
The vector code is in section .vectors, which is mapped by the linker
script to 0xFFFF0000. However the map file shows zero length for the
section and the debugger confirms that what is loaded there is the next
section after the .vectors section.
map file snippet:
.vectors 0xffff0000 0x0
0xffff0000 __vectors_start = .
*(.vectors)
0xffff0000 __vectors_end = .
linker script snippet:
.vectors : {
__vectors_start = .;
*(.vectors)
__vectors_end = .;
} > plb_bram_if_cntlr_1
xvectors.S file snippet:
.section .vectors,"ax"
.globl _vectorbase
_vectorbase:
// Vector 0x0000, Jump to zero.
critical_interrupt 0000, 0
// Vector 0x0100, Critical interrupt.
critical_interrupt 0100, 1
It all looks right to me. I must be missing something. I've tried lots
of name/case/quoting changes. I can't get the code for the vectors
(expanded macro 'critical_interrupt" etc.) to be loaded in memory no
matter what I do. Even messed with the case of the .s file extension
which very bizarrely (to me anyway) changes whether the C preprocessor
is invoked.
Any clues or ideas??
Thanks
Steve
Article: 104249Thanks Siva, but the SX35 is not supported by ISE Webpack; only the SX25 is supported. I'm trying to avoid having to purchase the full ISE product. Rgds, Peter siva.velusamy@gmail.com wrote: > www.xilinx.com/ml402 > > It has an SX35 though.. > > -Siva > > Peter Moreton wrote: > > Hi, > > > > I am looking for an FPGA development board that can host a Xilinx > > Virtex-4 XC4VSX25 device, because it has 128 multipliers and is > > supported by the free Xilinx ISE Webpack edition - however, much > > Googling has not turned up a board with this device. > > > > Can anyone tell me if a development board that hosts the Xilinx 'SX25 > > exists? - ideally this would have a PCI/PCI-X/PCI-E interface, but > > USB etc might be OK also. > > > > Thanks
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