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
GaLaKtIkUs=99 wrote: > In my bgn file (report file of the last step: genrate programming file) > I got the followig warning: > > WARNING:PhysDesignRules:781 - PULLDOWN on an active net. PULLDOWN of > comp > s_o<0>/s_o<0> is set but the tri state is not configured. > > I have the following constaints in my ucf file: > > NET s_o<0> LOC =3D G5; #GPLED0 > NET "s_o<*>" PULLDOWN; > NET "s_o<*>" TIG; > NET "s_o<*>" SLEW =3D SLOW; > NET "s_o<*>" DRIVE =3D 2; > > Can anybody help? > > Mehdi Your problem is in the source code, not your constraints. It's complaining that you don't ever tristate the signal, either because your equations don't have a tristate term or because that term has been optimised away.Article: 93126
hiii i need immeadite help... i have to deliver a presentation. suppose i have to verify a D flip flop, what are the verification stages, how will i proceed with it. what are the steps to begin till end. its important so can any one out here just brief it out to me. thanks a million. byeArticle: 93127
Hi kl31n, I'm a little confused about your post. You're saying you thought you could effectively reduce the latency by having multiple floating-point units? You could certainly increase the bandwidth by having multiple units, but the latency will remain 33 cycles. If latency is not a problem then so long as you meet bandwidth requirements you'll be OK. With new data appearing at a rate of 5MHz, and being consumed at a rate of 3.03n Mhz, where n is the number of FPUs, n of 2 should be more than sufficient. I'm confused by your comment: "I cannot get under 260ns and this with whatsoever the number of dividers." If it doesn't work with 2 dividers, then you must have a problem that simply adding FPUs will never solve. Sorry if this is exactly what you're saying, but the way you used the word latency worried me somewhat. I'm guessing there's no way you could use a speed-optimised divide core? That way you could at least issue your inputs every 200ns, then pick up your outputs on the the other side every 200ns, provided that the latency of the FPU is acceptable. Cheers, RobinArticle: 93128
Hi,
I have been googling for a while
having noticed that there is no clear answer to my following problem:
The IEEE Std. 802.3 says the following: (section 3.2.8 Frame Check
Sequence field)
>Mathematically,the CRC value corresponding to a given frame is de =EF=AC=
=81ned by the following procedure:
>a)The =EF=AC=81rst 32 bits of the frame are complemented.
>=2E..
>e)The bit sequence is complemented and the result is the CRC.
I use the following CRC32-VHDL module:
-- File: PCK_CRC32_D8.vhd
-- Purpose: VHDL package containing a synthesizable CRC function
-- * polynomial: (0 1 2 4 5 7 8 10 11 12 16 22 23 26 32)
-- * data width: 8
-- Info: tools@easics.be
Now I want to simulate the CRC according to the IEEE standard. I have a
transmitter including the CRC32
module and a receiver including the CRC32 module.
But I have some doubts on how to perform a conform simulation.
Let's assume that the following bytes are transmitted via Ethernet(one
byte interface), they are fed into the easics- module:
byte0 =3D "00000000" (Integer 0)
byte1 =3D "00000001" (Integer 1)
.=2E.
byte255=3D"11111111" (Integer 255)
Are the following assumptions correct ?
1=2E The CRC has to be initialized to
NOT ("00000011 00000010 00000001 00000000")
2=2E The calculated CRC has to be inverted and appended in the following
manner:
first byte appendix: NOT CRC(31 DOWNTO 24)
second byte appendix NOT CRC(23 DOWNTO 16)
third byte appendix NOT CRC(15 DOWNTO 8)
fourth byte appendix NOT CRC(7 DOWNTO 0)
3=2E To which value do I have to reset the "remote" CRC module ?
4=2E Do I have to remove the CRC32 appendix of the Ethernet packets and
replace the four bytes with "00000000" ?
I would be very thankful if you could shed some light on it.
Rgds
Andr=C3=A9
Article: 93129Antti Lukats wrote: > "ABS" <abhishekbedi@gmail.com> schrieb im Newsbeitrag > news:1134518668.567217.216410@o13g2000cwo.googlegroups.com... > > hi all > > > > has anyone got any documents or refferals for 'J Tag Protocol ' , for > > reconfigurable hardware. > > I bet almost anyone here has... > > but JTAG primary function is BOUNDARY SCAN and not hardware reconfiguration, > even though lots (virtually all) current FPGA allow configuration over JTAG > interface > > > i would appreciate if any tutorials or realted links/documents can b > > passed on . > > thanks > > abhishek > > > On the grounds I want to find out if the OP is creatively lazy... The relevant specifications are: for pure JTAG (testing) IEEE 11.94.1 - (year) [there are a number of releases. Most devices comply with the 1994 release] For In System programmable devices using JTAG IEEE1536. Note that the 'BSDL' files for ISP specify the 1536 compatibility (See Altera or Xilinx docs) For testing cores with 'standard' interfaces, such as EJTAG (MIPS) or such as ARM core access, you would need to search for the specific information. EJTAG and ARM core JTAG access protocols are published, but not necessarily free. Both 1194 and 1536 are published, but not free, although there is a wealth of available information if you want to learn about it. Cheers PeteS > it takes a few seconds to find those documents by googling for them, if you > are too lazy for that there is no one who can help you. > > Antti > PS I admire 'creative lazyness' but not people who are just lazy.Article: 93130
Jeremy Stringer wrote: > Not quite on topic - but I thought somebody here might know - > > Does anybody know where I can get hold of the SGMII spec (Used on SFP > modules, esp. 10/100/1000 copper)? > > All I can find in the SFP/PHY datasheets that I've looked at so far is > references to the data bytes being repeated 10 times (Which doesn't help > much with autonegotiation). > > Thanks, > Jeremy SGMII is part of the IEE 802.x series. To get the spec, you have to either have a subscription or have access to a company that does ;) Cheers PeteSArticle: 93131
Hi We're looking at using an FPGA in a land based mission critical application (not life critical). The latest generation of devices with their huge resources are very tempting but the feeling is to stay with older technology particularly with their larger geometries and higher core voltages. With regard to the low voltages, a well designed PCB with clean supplies and a low impedance/inductance ground should reduce ground bounce, etc. to an acceptable level. Has anyone had bad experiences or have views regarding the use of these latest FPGA (and/or MCUs) devices in such applications ? Thanks DaveArticle: 93132
Daveb, your question indicates your suspicion that modern ICs ( like FPGAs) offer less reliable system solutions than the older technology. That suspicion is not shared by the (admittedly biased) IC industry, nor by the user community which accepts the newer technologies and higher capabilities gladly (even while they complain about the usual teething problems). You have to put more care (and knowledge) in your pc-board design, you have to pay more attention to signal integrity between ICs, but you get so much more capabilities that you can afford to think about self-checking or redundant designs that increase your reliability. If your suspicion were justified, it would be the kiss of death for progress as we are accustomed to expect... Peter Alfke, Xilinx ApplicationsArticle: 93133
Hello all, Thank you very much for explaining me everything clearly.The suggestions and information is highly useful.I think I must more homework to understand such problems. Thanks alot, MonicaArticle: 93134
but where is the problem? is this can influence the right behaviour of my design? MehdiArticle: 93135
Peter, I should have made myself clearer. By older technology I meant 'older' FPGA technology e.g Spartan-II with a 2.5V core voltage. I'm not suspicous of the newer devices' reliability, just keen to see what the consensus is regarding the ever reducing core voltage (i.e. reduced noice margins) & reliability of system implementations. DaveArticle: 93136
>Ray wrote: >Like you mentioned, these offer close to zero security. Any yo-yo with >an ounce of electronics knowledge can obtain the code from it, and it >doesn't take much more than that to make a circuit that will mimic the >serial number. It's not the serial number that offers security, it's the 64-bit key hidden behind SHA-1. I'm certainly not an expert, but googling turns up that only recently has SHA-1 been broken: http://www.schneier.com/blog/archives/2005/02/sha1_broken.html and it seems to have been around for quite a while. I don't think that "any yo-yo" could break a system that has resisted attack for (it looks like at least) 10 years.Article: 93137
Hi Ray, Thanks for your answer. I take an interest in your example. Can you send me the file.vhd with the clk rom your project. My problem is : I use with success the DLL in my project, but only for a free place and route. When I try to write a file.ucf with this dedicated pin "aa4" for my CLK, ISE (Version7.1) stop with error at the mapping. (need to use IBUF or other...) I aren't worried about the relative phase of the 32 and 48 Mhz clocks, but I would like to have duty cycle around 50% (40/60 max). Thanks for your help. Benoit. "Ray Andraka" <ray@andraka.com> a écrit dans le message news: ldHnf.5079$rB5.1219@dukeread01... > HB wrote: > > Gee, that sounds a lot like the GV associates board I used for the Radar > project shown in the gallery page of my website (the one with the CPU > fans on the FPGAs). In that case, there was a 48MHz clock for a USB > interface chip that was also connected to the FPGA, but not through a > clock pin and we had a separate clock oscillator that came through > another pin (I think it was 66 MHz). > > If you aren't worried about the relative phase of the 32 and 48 Mhz > clocks, you can bring the 48 Mhz clock in through the non-clock pin and > use general routing resources to get it to a DLL. From there you can do > the divide by 1.5 to get 32 MHz. > > I'd have to do some digging through the archives to find the clock > module for that design, but the point is you don't necessarily have to > bring the clock in on a clock pin if you aren't worried about clock skew.Article: 93138
Daveb, that's exactly what I was addressing. If you decouple Vccint well, and use the right multi-layer board for good Vcc distribution, there should be no FPGA-internal problem. You can still use 3.3-V I/O, even on the newest devices. We have made sure that the I/O can be 3.3-V capable and tolerant, even though that has increased our chip size and thus the cost. People build extremely reliable complex systems with the modern devices. We used to point to the Mars Rover, which used the then most-modern Virtex devices to control its wheel movement (and other functions). If NASA was willing to use the most modern technology for such a risky and high-visibilty and publicity project, you might also want to do that... Peter AlfkeArticle: 93139
Thanks Peter. I wonder what devices the Mars Beagle2 Lander used :)Article: 93140
I have a virtex II pro fpga pci board. I have to transfer data from fpga to the host computer over the pci bus.How should I go about it? I have a external pci bridge on the card between fpga and the pci.Now the vendor doesnt provide any details. I have a program given by vendor which can read data from memory on the board but the intitiation has to be from host i.e by running the program. I have to figure out how can I send data to host from fpga and how do I confirm that the host has captured the right data. Should I start with tweaking pci drivers or is there any other way ? -NiteshArticle: 93141
Nitesh The group may give more information if tell us what your development board is. Assuming that your development boards supports Initiator functions then you should be able to implement a DMA function across the PCI bus to your destination. You will need information from the O/S or drivers in the system such that you know where to write to as PCI based memory spaces are allocated normally at boot and hence not necessarily a fixed value. John Adair Enterpoint Ltd. - Home of Raggedstone1. The Low Cost Spartan3 PCI Development Board. http://www.enterpoint.co.uk "Nitesh" <nitesh.guinde@gmail.com> wrote in message news:1134588523.921681.202070@g47g2000cwa.googlegroups.com... >I have a virtex II pro fpga pci board. I have to transfer data from > fpga to the host computer over the pci bus.How should I go about it? > I have a external pci bridge on the card between fpga and the pci.Now > the vendor doesnt provide any details. I have a program given by vendor > which can read data from memory on the board but the intitiation has to > be from host i.e by running the program. I have to figure out how can I > send data to host from fpga and how do I confirm that the host has > captured the right data. > Should I start with tweaking pci drivers or is there any other way ? > -Nitesh >Article: 93142
I don't have the vhdl handy at the moment. You need to change your input buffer from an IBUFG to an IBUF to be able to place it on an arbitrary pin. You probably don't need to place anything else, nor do anything else special.Article: 93143
Hi John, I have read the paper and I think it is an excellent paper. What I want to know is how many products and applications will use it or have been using it? Thank you. WengArticle: 93144
JustJohn wrote: >>Ray wrote: >>Like you mentioned, these offer close to zero security. Any yo-yo with >>an ounce of electronics knowledge can obtain the code from it, and it >>doesn't take much more than that to make a circuit that will mimic the >>serial number. > > > It's not the serial number that offers security, it's the 64-bit key > hidden behind SHA-1. I'm certainly not an expert, but googling turns up > that only recently has SHA-1 been broken: > http://www.schneier.com/blog/archives/2005/02/sha1_broken.html > and it seems to have been around for quite a while. I don't think that > "any yo-yo" could break a system that has resisted attack for (it looks > like at least) 10 years. > Maybe I'm missing something here, but with a 1 wire device providing the key that lets the FPGA function, all you need to do is monitor the bits that are read out of the device, and then duplicate that bit pattern to enable the FPGA. Unless the query is different every time the FPGA starts up (which would either require different bitstreams or different external stimulus to the FPGA), you just play back the bitstream you recorded off a known good product. The FPGA itself is deterministic, and other than the battery backed encryption in V2, there is no key kept in the FPGA that isn't part of the device configuration.Article: 93145
Hi, I was wondering if anyone could comment on using Incremental Compilation in Quartus 5.1? Is there any problems partitioning your design? I just want to know if it is worth using it? Thanks, joeArticle: 93146
"Ray Andraka" <ray@andraka.com> schrieb im Newsbeitrag news:8U_nf.30503$Mi5.23903@dukeread07... > JustJohn wrote: > >>>Ray wrote: >>>Like you mentioned, these offer close to zero security. Any yo-yo with >>>an ounce of electronics knowledge can obtain the code from it, and it >>>doesn't take much more than that to make a circuit that will mimic the >>>serial number. >> >> >> It's not the serial number that offers security, it's the 64-bit key >> hidden behind SHA-1. I'm certainly not an expert, but googling turns up >> that only recently has SHA-1 been broken: >> http://www.schneier.com/blog/archives/2005/02/sha1_broken.html >> and it seems to have been around for quite a while. I don't think that >> "any yo-yo" could break a system that has resisted attack for (it looks >> like at least) 10 years. >> > Maybe I'm missing something here, but with a 1 wire device providing the > key that lets the FPGA function, all you need to do is monitor the bits > that are read out of the device, and then duplicate that bit pattern to > enable the FPGA. Unless the query is different every time the FPGA starts > up (which would either require different bitstreams or different external > stimulus to the FPGA), you just play back the bitstream you recorded off a > known good product. The FPGA itself is deterministic, and other than the > battery backed encryption in V2, there is no key kept in the FPGA that > isn't part of the device configuration. XAPP780 uses 2 unrelated on-chip ring oscillators to provide true random tokens for the security challenge. those ringoscillators use directed routing constraints and fail to synthesize :) AnttiArticle: 93147
Actually I believe that the stream is different everytime the design needs to authenticate. The protection ip contains some pseudo random number gen and with this, has the ability to generate unique stream. It would be too obvious to record and playback the same stream. Ray Andraka wrote: > JustJohn wrote: > > >>Ray wrote: > >>Like you mentioned, these offer close to zero security. Any yo-yo with > >>an ounce of electronics knowledge can obtain the code from it, and it > >>doesn't take much more than that to make a circuit that will mimic the > >>serial number. > > > > > > It's not the serial number that offers security, it's the 64-bit key > > hidden behind SHA-1. I'm certainly not an expert, but googling turns up > > that only recently has SHA-1 been broken: > > http://www.schneier.com/blog/archives/2005/02/sha1_broken.html > > and it seems to have been around for quite a while. I don't think that > > "any yo-yo" could break a system that has resisted attack for (it looks > > like at least) 10 years. > > > Maybe I'm missing something here, but with a 1 wire device providing > the key that lets the FPGA function, all you need to do is monitor the > bits that are read out of the device, and then duplicate that bit > pattern to enable the FPGA. Unless the query is different every time > the FPGA starts up (which would either require different bitstreams or > different external stimulus to the FPGA), you just play back the > bitstream you recorded off a known good product. The FPGA itself is > deterministic, and other than the battery backed encryption in V2, there > is no key kept in the FPGA that isn't part of the device configuration.Article: 93148
PeteS wrote: > Jeremy Stringer wrote: >> Not quite on topic - but I thought somebody here might know - >> >> Does anybody know where I can get hold of the SGMII spec (Used on SFP >> modules, esp. 10/100/1000 copper)? >> >> All I can find in the SFP/PHY datasheets that I've looked at so far is >> references to the data bytes being repeated 10 times (Which doesn't help >> much with autonegotiation). > > SGMII is part of the IEE 802.x series. To get the spec, you have to > either have a subscription or have access to a company that does ;) I do have the 802.3 documents - They quite clearly define MII (25MHz/4bit) and GMII (125MHz/8bit), but not (As far as I could tell) SGMII (625MHz DDR/1 bit, GE signalling, modified autonegotiation sequences, repeated payload bytes for 10/100). JeremyArticle: 93149
Has anyone had any experience using Xilinx RocketIO MGTs at data rates other than the PMA rates that are explicitly defined in the datasheet? I've had a fair amount of success with it, but functionality such as clock-data recovery has been troublesome for me. Because the predefined attributes for all 120 bits of the PMA configuration register seem to be geared for certain serial rates, and the documentation is vague at best in UG035, I'm pretty much left to guess and check whether or not changing any of these parameters (RXLOOPFILTER CAP, RES, for instance) might help me out. Thanks, Jeff
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