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
Sir/Madam,
1. What are the applications that Reed solomon codes are best suited for ?
Why ?
Can they be used in GSM ? Do convolutional codes perform better in GSM
systems ?
Do RS codes find applications in wireless communications ? Please
explain.
2. Where can I find the following specs :
Intelsat IESS-308
RTCA D0-217 Appendix F, Revision D
and the proposed ITU-TS SG-18(formerly CCITT SG-18) standards ?
I'm a student and I'll be glad if someone could lead me to the answers to
the above questions.
Thank You,
Regards,
Pradeep Rao
Article: 20076>The other thing I found that was causing the infinite loops was bugs in the >design, not the program. I'm not sure of your design stage, but Quartus is >poor at the early stage of designs. The culprit was Resets. Xanatos, first of all thank you for the info about QUARTUS. Just another question about those design bugs which cause fitter infinite loops: apart from the reset fanout, were some of them caused by design's details incompatible with the hardware structure of the FPGA ? (example:I remember a clock, placed on a dedicated low skew line in a Flex 10K and connected to an output pin in a design, caused an infinite loop in MAXPLUS2 due to the impossibility to connect internal global signal to an output). Can you remember other "categories" of design bugs which cause such loops ? Thanks in advance. Giuseppe Giachella ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com Sent via Deja.com http://www.deja.com/ Before you buy.Article: 20077
Hi Folks, EEPROM based FPGAs are in-circuit re-programmable FPGAs, which are, unlike SRAM based FPGAs, not volatile. Their disadvantage, I presume, is that they are slower. Could you think about any other disadvantage? or advantage? compared to SRAM based ones. Cheers.Article: 20078
Actually, the EEPROM cells do not slow down the logic per se, as they are used to control pass transistor switches rather than handling the signal directly. However, the process for EEPROMs is a step behind the process for SRAM, so there is more opportunity for the SRAM devices to be tweaked for maximum performance. That said, there are significant architectural differences between the EEPROM and SRAM devices that have nothing really to do with the storage technology that may make a device more or less suited to your application. Personally, I like the SRAM devices because they give you a sizable advantage in system debug and test, as well as giving you the opportunity for using reconfiguration as part of the processing. The debug and test issues are addressed in the Radar Environment simulator (MAPLD98) paper on my website. George wrote: > Hi Folks, > > EEPROM based FPGAs are in-circuit re-programmable FPGAs, which are, unlike > SRAM based FPGAs, not volatile. Their disadvantage, I presume, is that they > are slower. Could you think about any other disadvantage? or advantage? > compared to SRAM based ones. > > Cheers. -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email randraka@ids.net http://users.ids.net/~randrakaArticle: 20079
Hi people,
I need some informations about FPGA's reconfigurations mode like:
Full Reconfiguration, Partial Reconfiguration, Multiple-Context
Configuration, Dynamic Configuration, Striped Configuration and the most
important for me, Configuration Cloning.
If anyone could help me ....... mail to: anoriaki@comp.ufscar.br
thanks.
Nori.
Sent via Deja.com http://www.deja.com/
Before you buy.
Article: 20080I've got two cases that are creating a problem with using the Virtex GSR with flip-flop primitives for me: 1) I've got a flip-flop that I need to have use the synchronous reset that goes directly into the FF (virtex). I also want it to start up initialized with GSR. That flip-flop is instantiated as a primitive (FDRE) in my code so that I can put RLOCs on it to place it from within the code. Normally, this could be handled at an RTL level with appropriate coding, but where I'm instantiating the primitive, I don't see a way of getting GSR in there too. 2) I've got a case where I instantiate a FDE and an SRL16E and place them both in the same half of the slice. The reset/clear on the FDE is unusable in the design because it is shared with the SRL16E enable. If I instantiate an FDCE to get a GSR input, the tools don't seem to make it into an FDE when they recognize the GSR, and it results in a mapper failure. Has anyone encountered this and found a suitable workaround (RTL coding doesn't count, I need to specify placement). -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email randraka@ids.net http://users.ids.net/~randrakaArticle: 20081
On Tue, 25 Jan 2000 20:32:46 -0800, John Larkin <jjlarkin@highlandSnipSniptechnology.com> wrote: >thanks for the reference. The papers are interesting, but both ignore >plane capacitance. A power-ground plane pair with a small dielectric >gap (a few mills can be easily had) is in fact a very low impedance >transmission line. Transients looking into the parallel planes (as I >see with my TDR experiments) see low-Z transmission line in all radial >directions. My testing indicates that the highest impedance a chip >pin sees is the via that reaches down from the pin to the power or >ground plane; the planes themselves (if the dielectric gap is small) >are very stiff for fast transients. Of course, if you need X colombs >of charge to keep your chip happy, you'd better have n*X farads >available somewhere to supply it. And that's the problem: not only do you need n*X farads somewhere, but somewhere pretty close by. It's well understood that it takes on the order of 160ps for a signal to travel 1 inch on a trace embedded in FR-4. What's less well understood is that this limitation applies to power planes, too, which, as you've said, are nothing more than very low-impedance transmission lines. If a capacitor is, say, 3 inches from a chip, it takes ~1/2ns for the request for current to travel from the chip to the capacitor , and another ~1/2ns for the current to travel back to the chip. And that's optimistic; the capacitor and its connection to the board are inductive, slowing down the response even further. If the chip is attempting to switch outputs with a 1ns risetime, by the time the 3-inch-away capacitor supplies current, it's all over but the shouting. To see if planes alone are enough to supply transient current, let's consider the following example. Suppose that an FPGA in a BGA package is attempting, worst-case, to switch 100 outputs from LOW to HIGH, and let's further suppose that the risetimes are 1ns. If the outputs are driving 50 ohm traces, the di/dt is 100*(3V/50 ohms)/1ns = 6A/ns (!). (This is reduced somewhat by the output impedance of the FPGA drivers, but drivers as low as 10-20 ohms are commonplace..) If the board has two pairs of adjacent power and ground planes, and if the power and ground planes in a pair are separated by a 5 mil dielectric, we get approximately 2*200pf/in2 = 400pF/in2 of capacitance. Now the big question: how much plane capacitance can the chip actually "see" when it's switching? My general rule of thumb is to include only the capacitance that's within risetime/6 of the chip, so that the current request can get to the capacitance and back before the transition is more than 1/3rd of the way done. But in this case I'm going to load the dice in your favor and double that distance to risetime/3, or 1/3 ns. The effective distance is therefore about 2 inches, or the time a signal can travel in 1/3 ns. So we'll assume that any point on a power plane within a radius of 2 inches of the chip can contribute current to the transitions. We have a total of pi*2*2*400pf = 5nF at our service. The droop on the plane attributable to the transition is therefore: de = dt * i/C = 1ns * 6A/5nF = 1.2V That's not good. Simply put, there isn't enough capacitance on the planes to help us completely manage Vcc droop. At this point it may be tempting to point to all of the capacitance on the remainder of the plane, but it doesn't help us, either; by the time we can communicate with it, the transition is supposed to be over. We could improve things somewhat by using a couple of buried capacitance layers instead of the closely-spaced planes, thereby roughly doubling the available capacitance. But that still leaves us with lots of Vcc noise. This may seem like an outrageously pessimistic example. In fact, I think it's optimistic. Consider the following: - Many modern-day chips have risetimes faster than 1ns. If you really want to be depressed, re-run the numbers with a 0.5ns risetime. - I haven't accounted for the current needed to supply the internal switching requirements of the chip. - I've assumed that the chip has exclusive use of all the plane capacitance within a 2" radius. I haven't seen many high-speed boards that are this sparsely populated. In short: we need some (relatively) high-speed bypass capacitance reasonably close (tr/6) to the chip to supply the current that the plane can't. And we probably need more capacitors than would be indicated by voltage droop calculations alone, because these caps and their interconnects are both inductive and resistive, and we can mitigate both by putting multiple caps in parallel. What's more, as the Sun paper indicates, we need low-inductance hook-ups for these capacitors, or they'll be useless. Irrelevant aside: I've always found it ironic that it's actually easier to design power distribution for ECL, which despite its high-speed reputation is more or less constant-current, than it is to design power distribution for CMOS. It's the current changes that kill us. >I think my point is that, for properly designed multilayer boards, the >planes themselves are an enormous asset in supplying low-impedance >power for fast transients. My TDR tests indicate that additional >bypass caps can be scattered about, and improve the apparent >capacitance a pin sees, without having to be really close to every >pin. I have never observed the multiple-resonances effects predicted >by the Sun paper Spice models for paralleled caps; I suspect they >didn't model the planes. The folks at Sun are aware of the effects of plane capacitance; in fact, the paper I cited mentions the role of the power plane in suppressing spikes in the >200MHz region. There's also a reference to a to-be-published paper on power plane analysis for CMOS power distribution systems. I agree that the planes are an enormous asset in power distribution; they are of greatest help at higher frequencies. But in many cases, they simply aren't enough by themselves. >As I get braver, I am using fewer bypass caps, spread farther apart, >and am still measuring very clean Vcc and ground noise levels. As >parts get smaller, and have *lots* of pins, one eventually will be >faced with brickwalling the backside of the board with thousands of >head-to-butt capacitors. This will eventually get silly, and our >Manufacturing people will stop saying 'hello' in the hallways. I find that the manufacturing folks are accommodating if they are told why something is being done, and if that something prevents a board spin. Take care, Bob Perlman ----------------------------------------------------- Bob Perlman Cambrian Design Works Digital Design, Signal Integrity http://www.best.com/~bobperl/cdw.htm Send e-mail replies to best<dot>com, username bobperl -----------------------------------------------------Article: 20082
On Fri, 31 Dec 1999 11:20:44 -0600, "Larry Edington" <larryeSpam.Me.Not@centuryinter.net> wrote: >I'm looking at an FPGA for project I'm working on and am concerned about >security. CPLD's and ASIC's I'm familiar with but FPGA's are a new trick for >me. > >I'm looking at Altera and Xilinx. > >It appears that most FPGA's are programmed with a serial eeprom. I'm >concerned about the security the data in the eeprom. What keeps someone from >simply copying your eeprom to duplicate your FPGA's programming? You can also load from a microprocessor or part of a parallel eprom elsewhere in the system. It would take a lot more work for someone to reverse engineer if done this way. In an extreme case, a missile containing these devices is loaded at boot time from the launcher. Once launched, the hard configuration data is no longer part of the system. Once power is lost, the configuration is also lost. Failed missiles cannot be reverse engineered by the enemy. > >Maybe this is a stupid question but I'm still learning about FPGA's. Since I >will have some encryption / decryption functions in the FPGA, this is a big >concern for me. What do you need to do to protect your design when using >FPGA's ? > >thanks, >Larry E. >Remove Spam_me_not to reply via email. > > >Article: 20083
Yes, EEPROM technology is slower than SRAM. This comes into play in two areas. First, for loading, as all the configuration bits need to be written, or perhaps partial reconfiguration if an architecture would support that. Secondly, for applications that use the configuration memory as logic (i.e., using LUTs as memories). For switching, though, I don't think it will make that much difference, since the cell sense mechanism needs to ultimately bias a FET pass transistor. In practice, the Xilinx designs, for example, are frequently used to drive a process at a semiconductor foundry. The EEPROM cells will have extra processing steps and so should be lagging by perhaps a generation or two, giving just slower chips. Additionally, device architecture will play a big role as does the application. A hard-wired carry chain in the latest process for artithmetic operatios will be difficult to beat. Please take the above with a grain of salt, just got done shoveling yet again (thanks to the snow plow blocking us in) and I'm wiped! rk ==================== George wrote: > Hi Folks, > > EEPROM based FPGAs are in-circuit re-programmable FPGAs, which are, unlike > SRAM based FPGAs, not volatile. Their disadvantage, I presume, is that they > are slower. Could you think about any other disadvantage? or advantage? > compared to SRAM based ones. > > Cheers.Article: 20084
Oops, left off one item, in-circuit programming. While not necessary in principle, you may need to supply some odd-ball voltages to drive the programming element. For example, the latest EEPROM-based FPGA device requires +16.5V and -12V supplies. Additionally, they have restrictions on driving I/O pins during programming. This is not a fundamental limit of the technology, as many EEPROM-based devices have internal charge pumps to derive the required voltages, giving the user a simple interface, say perhaps a voltage for the core and a separate one for the I/O drivers. EEPROMs such as the Seeq 28C256 have had this for many years, letting the user run with a single +5VDC line. Others, such as some models made by Northrop-Grumman, allow either an internal pump to be used or an external one to be provided. They allow a choice for environmental reasons. rk ========================= rk wrote: > Yes, EEPROM technology is slower than SRAM. This comes into play in two > areas. First, for loading, as all the configuration bits need to be written, > or perhaps partial reconfiguration if an architecture would support that. > Secondly, for applications that use the configuration memory as logic (i.e., > using LUTs as memories). For switching, though, I don't think it will make > that much difference, since the cell sense mechanism needs to ultimately bias a > FET pass transistor. > > In practice, the Xilinx designs, for example, are frequently used to drive a > process at a semiconductor foundry. The EEPROM cells will have extra > processing steps and so should be lagging by perhaps a generation or two, > giving just slower chips. Additionally, device architecture will play a big > role as does the application. A hard-wired carry chain in the latest process > for artithmetic operatios will be difficult to beat. > > Please take the above with a grain of salt, just got done shoveling yet again > (thanks to the snow plow blocking us in) and I'm wiped! > > rk > > ==================== > > George wrote: > > > Hi Folks, > > > > EEPROM based FPGAs are in-circuit re-programmable FPGAs, which are, unlike > > SRAM based FPGAs, not volatile. Their disadvantage, I presume, is that they > > are slower. Could you think about any other disadvantage? or advantage? > > compared to SRAM based ones. > > > > Cheers.Article: 20085
Hi Does anyone know what has happened to the FreeCore Homepage (www.freecore.com)? I have not been able to get through since the start of this year. Cheers -- Steve Dewey Remove 123 for emailArticle: 20086
One point in this debate is that Xylinx seem to put the DLLs into ALL the Virtex and Spartan parts. Altera definitely only puts them into certain speed grades/packages/device sizes. So you have to pay extra and probably not use the speed grade, package, or device size that you thought. It is my opinion that Altera literature is _almost_ misleading about this: unless you read the small print, you could order a device, and not realise that only the -x parts have these features. It makes me really pissed, but there is no chance of the money for a set of Xylinx tools at present, so I'm stuck. -- Steve Dewey remove 123 for emailArticle: 20087
In article <zYiOLEAGB2j4EwGk@s-dewey.demon.co.uk>, Steve Dewey <steve@s-dewey123.demon.co.uk> wrote: >One point in this debate is that Xylinx seem to put the DLLs into ALL >the Virtex and Spartan parts. Altera definitely only puts them into >certain speed grades/packages/device sizes. So you have to pay extra and >probably not use the speed grade, package, or device size that you >thought. > >It is my opinion that Altera literature is _almost_ misleading about >this: unless you read the small print, you could order a device, and not >realise that only the -x parts have these features. > >It makes me really pissed, but there is no chance of the money for a set >of Xylinx tools at present, so I'm stuck. How large a design are you dealing with? Xilinx makes some limited versions for students and small designs which are cheap. -- Nicholas C. Weaver nweaver@cs.berkeley.eduArticle: 20088
Try http://www-ee.eng.hawaii.edu/~pramod/ee628/viterbi.html This is a good starting point Tbu -- Thomas BurchardArticle: 20089
The DLLs aren't the only advantage the Xilinx has over Altera, at least for arithmetic intensive designs. See my previous rants on that for more details. If your device is small, you can get the student edition tools for a song. If it is a big design, the cost of the tools will be insignificant compared to your medical bills from banging your head against the wall. Besides, with the price difference for the Cadillac parts, it won't be many parts before you've paid more than you would have for the Xilinx tools. You might talk to your FAE/local sales rep to see if you can get a break for volume or just trying the tools out. If it means gaining another account, especially a potentially lucrative one, these guys have been known to deal a little. Steve Dewey wrote: > One point in this debate is that Xylinx seem to put the DLLs into ALL > the Virtex and Spartan parts. Altera definitely only puts them into > certain speed grades/packages/device sizes. So you have to pay extra and > probably not use the speed grade, package, or device size that you > thought. > > It is my opinion that Altera literature is _almost_ misleading about > this: unless you read the small print, you could order a device, and not > realise that only the -x parts have these features. > > It makes me really pissed, but there is no chance of the money for a set > of Xylinx tools at present, so I'm stuck. > > -- > Steve Dewey > remove 123 for email -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email randraka@ids.net http://users.ids.net/~randrakaArticle: 20090
This is a multi-part message in MIME format.
--------------8D31918EB976B4BF08400CE5
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
hai folks
do you anyone know about ORCA 3T series carry chain
1. what is the basic advanatge in ORCA 3T carry chain than XC4000 from
xilinx
what are basic advanatges and disavantages in both of this
anyone knows this, i need your help
thanks in advance
kamal
--------------8D31918EB976B4BF08400CE5
Content-Type: text/x-vcard; charset=us-ascii;
name="raja.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for raja
Content-Disposition: attachment;
filename="raja.vcf"
begin:vcard
n:kamalanathan;Raja
tel;home:07 38761962
tel;work:07 33658849
x-mozilla-html:FALSE
adr:;;;;;;
version:2.1
email;internet:raja@elec.uq.edu.au
fn:Raja kamalanathan
end:vcard
--------------8D31918EB976B4BF08400CE5--
Article: 20091
In article <388f1ed7.133032340@nntp.best.com>,
Bob Perlman <bobperl@best_no_spam_thanks.com> wrote:
>If the board has two pairs of adjacent power and ground planes, and if
>the power and ground planes in a pair are separated by a 5 mil
>dielectric, we get approximately 2*200pf/in2 = 400pF/in2 of
>capacitance. Now the big question: how much plane capacitance can the
>chip actually "see" when it's switching? My general rule of thumb is
>to include only the capacitance that's within risetime/6 of the chip,
>so that the current request can get to the capacitance and back before
>the transition is more than 1/3rd of the way done. But in this case
>I'm going to load the dice in your favor and double that distance to
>risetime/3, or 1/3 ns.
I don't think this is correct. The plane capacitance is not like a
capacitor at the end of a transmission line- it is much closer to an ideal
capacitance. Think of it this way: if you assume the plane is a
transmission line, you naturally want to know what its characteristic
impedance is. A tiny 8 mil trace is maybe 50 ohms- so a one ohm load will
cause a voltage drop to 1/51 until the power propogates down the line. The
same is true for the power plane, except that its impedance is much much
lower, so there will be almost no droop (except by the amount you calculate
when you assume you're discharging an ideal capacitor).
Think of it this way- the single point of discharge is being fed by an ever
growing ring of distributed capacitance. This ring is expanding in all
directions, so it is really like a low impedance transmission line. I would
like to know exactly what happens when decoupling capacitors recharge the
plane- I think they see the whole plane as well- not an inductive path to
the sink (as with microstrip ground returns).
--
/* jhallen@world.std.com (192.74.137.5) */ /* Joseph H. Allen */
int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0)
+r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2
]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}
Article: 20092An IBUF and an OBUF ? In article <388EB6FD.5916DFA9@digigram.com>, =?iso-8859-1?Q?J=E9r=E9mie?= WEBER <jwr@digigram.com> wrote: >Do you know how to link two pins of a virtex fpga like if it is a wire >between this two pins ( in order to bypass a fpga... ) >Article: 20093
# in UCF
NET "in_net" LOC = "B4";
NET "out_net" LOC = "B5";
# in top level VHDL
LIBRARY IEEE;
USE IEEE.STD_LOGIC_1164.ALL;
ENTITY myTest is
PORT(
in_net : IN std_logic;
out_net : OUT std_logic
);
END myTest;
ARCHITECTURE testARCH OF myTest IS
BEGIN
out_net <= in_net;
END testARCH;
remember to look into the data book to see what kind of delay you're going
to incure ... it may be something on the order of 6ns or so depending upon
what kind of device you use...
m
Matt Billenstein
http://w3.one.net/~mbillens/
mbillens@one.net
"Jérémie WEBER" <jwr@digigram.com> wrote in message
news:388EB6FD.5916DFA9@digigram.com...
| Do you know how to link two pins of a virtex fpga like if it is a wire
| between this two pins ( in order to bypass a fpga... )
|
Article: 20094We're actually getting into the layout now and I'm not so scared now that I've found the "correct" dimensions and a suggested escape routing note for the FG parts... it turns out the solder balls on the FPGA are substantially larger than the foot print that is suggested goes on the board... thus, I get a ton of more room between pads to route stuff and place vias. I'll forward the appnote to anyone who'd like to see; I don't think it can be found on the Xilinx website. m Matt Billenstein http://w3.one.net/~mbillens/ mbillens@one.net "Keith R. Williams" <krw@attglobal.net> wrote in message news:pLMYl5dhX7hK-pn2-qfE65ylclhD2@localhost... | On Sun, 19 Jan 3900 04:04:17, "Matt Billenstein" | <mbillens@one.net> wrote: | | > All, | > | > I've not seen (or cannot find) an appropriate appnote or reference design | > for laying down these fine pitch BGA parts (say FG256 for example) There | > doesn't seem to be a lot of room between BGA solder pads (0.400 millimeters | > nominal) to route out or drop vias of any substantial size... I can route | > out two rows around the whole part with very little trouble, but I think I | > have to dogbone anything further inside the part. How are you folks here | > doing it? | | When I switched FPGA manufacturers (at gun-point :-|) I went from | a BG560 to a FG680 to make things a little easier (it didn't). My | choices were either a 3mil line width to get two out traces per | channel or another plane and 5mil traces and one per channel. | Since I needed a 50 ohm environment and this widget is a "cost is | no object" type of deal, I chose another plane (actually two - | one for another power plane to keep 50 ohms). I have a total of | ten planes (5p, 5S). | | ---- | Keith | |Article: 20095
Ray Try putting an INIT attribute on the flop. To quote the reference guide (page 18-9 in dev_ref.pdf): For Xilinx Virtex devices, a high signal on the GSR (Global Set/Reset) net initializes each flip-flop and latch to the state (0 or 1) specified by its INIT property (default is 0).... The syntax would be the same as adding an RLOC. In VHDL: attribute INIT: string; attribute INIT of Fipper:label is "S"; -- or "R" Of course the simulation won't match up unless you cook up your own version of the flop. Ray Andraka <randraka@ids.net> wrote in message news:388F4F58.6436047@ids.net... > I've got two cases that are creating a problem with using the Virtex > GSR with flip-flop primitives for me: > > 1) I've got a flip-flop that I need to have use the synchronous reset > that goes directly into the FF (virtex). I also want it to start up > initialized with GSR. That flip-flop is instantiated as a primitive > (FDRE) in my code so that I can put RLOCs on it to place it from within > the code. Normally, this could be handled at an RTL level with > appropriate coding, but where I'm instantiating the primitive, I don't > see a way of getting GSR in there too. > > 2) I've got a case where I instantiate a FDE and an SRL16E and place > them both in the same half of the slice. The reset/clear on the FDE is > unusable in the design because it is shared with the SRL16E enable. If > I instantiate an FDCE to get a GSR input, the tools don't seem to make > it into an FDE when they recognize the GSR, and it results in a mapper > failure. > > Has anyone encountered this and found a suitable workaround (RTL coding > doesn't count, I need to specify placement). > > -- > -Ray Andraka, P.E. > President, the Andraka Consulting Group, Inc. > 401/884-7930 Fax 401/884-7950 > email randraka@ids.net > http://users.ids.net/~randraka > >Article: 20096
Replying to a slightly different question, Andy Peters <apeters.Nospam@nospam.noao.edu.nospam> wrote > I don't know anything about the XC6200 stuff, but all of the > currently-supported Xilinx chips have global low-skew clock buffers. Using > them in VHDL is quite simple: use your clock signal ONLY as the clock signal > for all of your flip-flops. Any real synthesis tool will note that the > signal's a clock net and assign a BUFGLS (or whatever the low-skew clock > buffer's called). Then, the P+R tools will go "A-ha!" and automatically > route the chip with that clock signal put onto a global clock net. But the Virtex secondary clocks seem to be more dificult. The Virtex data sheet has this to say about secondary clock nets: The secondary local clock routing resources consist of 24 backbone lines, 12 across the top of the chip and 12 across bottom. From these lines, up to 12 unique signals per column can be distributed via the 12 longlines in the column. These secondary resources are more flexible than the primary resources since they are not restricted to routing only to clock pins. I don't quite understand this because the routing resources between the HBACKBONE lines and the VLONG lines appear to be sparse in the extreme. Looking at the FPGA Editor screen, it appears that _at any given column_ you can only exit to a VLONG from two of the HBACKBONE lines. Also having gotten onto one of the VLONG wires, it does not seem to be possible to clock (or access at all) all the CLBs in a column. I guess I am not reading the FPGA Editor screen correctly... It would be really, really nice to have a clear picture of how this secondary clock routing works so that we can floorplan our designs. Even if the tools will do the "right thing", it is hard to floorplan the rest of the design without an understanding of what the layout requirements are for secondary clock routing. Ideally Xilinx can answer this, but there does not appear to be anything on their site and the standard FAE response is "secondary clock routing will be used for a net if you specify MAXSKEW=0 in the UCF". Following a future software release, the magic words will become "NET xxx USELOWSKEWLINES". If Xilinx aren't telling, maybe Philp F knows how the silicon works... /rantArticle: 20097
> Hi > > Does anyone know what has happened to the FreeCore Homepage > (www.freecore.com)? > > I have not been able to get through since the start of this year. > > Cheers > -- > Steve Dewey > Remove 123 for email The last time I've seen it was in december. But as far as I know, this wasn't a freecore page in december, because on this page only were Xilinx Cores (in december). In January the page has been removed. I suppose that freecore.com was bought by Xilinx at the end of last year. Andreas HeinerArticle: 20098
Dear All, I'm looking for a small and free microcontroller core (8051). Can someone tell me, where to find information about this core in the web. Any information is greatly appreciated !! Regards, Holger AzenhoferArticle: 20099
In article <388ED3A9.94347124@elis.rug.ac.be>, Jo Depreitere <jdp_nospam@elis.rug.ac.be> writes >Steve Bird wrote: >> >> In article <388e1f97.4722839@news.dial.pipex.com>, eml@riverside- >> machines.com.NOSPAM writes >> >Anyone managed this? I've tried modding the boot sector with a '95 >> >boot disk and Debug, but Debug can't even see the C drive, let alone >> >modify the boot sector. And does anyone know where the serial number >> >is? Presumably the NTFS location is different from the FAT16 and FAT32 >> >locations. >> > >> >By the way, this is (I think) legal. >> > >> >> Depends on why you would want to do this... If you're trying to subvert >> a s/w licensing schema (say FLEXlm) then its not. > >But if you buy a new (faster) PC, shouldn't they allow you to use your >old software? And with FLEXlm you have to fiddle with the serial number >(i.e., if you have a student license which has no support). It's not >exactly legal, but they can't really object to this, since I bought >the software and I want to keep on using it(?) > >Jo > You should be able to move your s/w to a new machine. However, my point was about using this technique to 'aquire' a use of s/w which was not paid for. Some vendors make the rehosting of s/w difficult, which it should, in an ideal world, not be. However, from the vendors perspective they have no way of knowing if the original machine is truely being decommisioned. There is no easy answer---if every user of s/w paid the due fees then this would not be an issue. Our own company view of licensing is that it is a technique to keep honest users honest, the effort required to prevent determined hackers is not economic and can become a barrier to adoption. I don't want to start a flame war here---as a small company every 'hacked' license hurts, not just us, but real users as it reduces the development investment. At the end of the day I like to take home a pay check, just like everyone else!
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