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
Magnus Homann <d0asta@mis.dtek.chalmers.se> wrote in message
news:ltzori3iru.fsf@mis.dtek.chalmers.se...
> [Rumours]
> Wasn't the Ariane 5 suppsoed to have different SW for some controlling
> functions, but they run out of time, and didn't implement it. The
> results are known.
> [End Rumours]
I think about this event every time I read "code reuse" in the trade rags,
which is to say, frequently. ("Heck, Orville, 8 bits is enough for the
altitude variable in the flight software...")
--
Gary Watson
gary@nexsan.sex (Change dot sex to dot com to reply!!!)
Nexsan Technologies Ltd.
Derby DE21 7BF ENGLAND
http://www.nexsan.com
Article: 21701Having read most of this thread I have the following global comments. 1)If you just want to play then surely you can understand that company A or X have better things to do than to be bothered with even a few hundred people going "your" route. 2)Assuming that your a better programmer than those employed by A or X (I actually think that, on average, this is likely), your tool might end up in some way better than the commercial stuff (which I don't think is likely), I would imagine that you would insist on the GNU/open source license. If its a better tool then the whole world would use it with hundreds of its inevitable variants. A or X would find themselves giving crap support for a great tool to people who have no interest in software instead of good support to a reasonable tool. This is not in their interest (or mine). 3) Vantis failed for the second time(I think) with an FPGA family about 2 years ago. I was told that "our silicon is great but our tools just didn't deliver". This gives some indication of the difficulty involved. 4) People have talked about the likelyhood of a bad bitstream damaging the device, I would be interested in knowing the real figure but I would expect that 99.something% bitstreams would cause this. 5) You talk about all this being simillar to micro-controllers. Yes it is possible for a micro-controller to destroy itself if programmed badly but some very simple hardware design would eg current limit its pins. I'm sure that the final, cost engineerd, dishwasher could destroy itself if prgrammed badly but I'm equally sure that the software protoyping dev system couldn't. Your FPGA would not tolerate this, it would sit there with one internal driver(eg) frying nicely, drawing so little current that you wouldn't notice. In short, company A and X are interested in making money. I have no problem with that, if you do I suggest that you change planets. They are interested in selling to customers who are going to buy buckets of their stuff, to whom they give the software to for nothing and give excellent support. The standard business saying "20% of their customers give them 80% of their business" holds true and the rest of us (well, the rest of you actually) are hanging on. The good news is that our volumes drive down the prices for you (your buying n million devices for nearly nothing), the bad news is that your not getting quite what you want. I suggest that you go cry in your beer and then go find something that people will let you play with. Sent via Deja.com http://www.deja.com/ Before you buy.Article: 21702
Xilinx does have some error checking in the bitstream which will prevent loads of a bitstream that has been corrupted, but that doesn't stop you from loading a bad bitstream that has the right CRCs in it (which is unlikely to happen with a corrupted bitstream, but easy to do if you manipulate the bitstream taking care to get the CRC's right). I don't believe the Atmel 6K has any error checking in the device... The particularly bad scenario is multiple outputs driving a node to different levels. One or two might not damage teh device, but do that to several drivers in a small area and you'll damage the device. Do it on a chip wide basis, and you'll see the genie escape in a puff of smoke. Keep in mind that it is not just the tri-states, but the outputs of every logic cell that could be connected to something driving the opposite value. Normally, the tools will keep you from doing that. Manipulating the bitstream directly bypasses all the protection. Andrew Brown wrote: > I had assumed the bit-streams had built in error detection to avoid bringing > the device out of the configuration state until the bit stream had been > verified. That should stop any 'major' violations in the design. But, it > would n't stop things like massive fanout on drivers which would not be good > for the chip ! > > A. > > "Ray Andraka" <randraka@ids.net> wrote in message > news:38E17B8C.5F2B7880@ids.net... > > Its even worse than that. Your reference is to an easy to make mistake of > multiple drivers on a > > line, which the tools will prevent. When you crawl inside the bitstream > it is very easy to make > > more than one signal an output into a route. For example, I am acutely > aware of one FPGA that > > gets programmed with "let the magic smoke out" if you load it with a > bitstream with all the bits > > set to one. You program enough misconnects at once, and you have less > than a fraction of a > > second before your part does its China Syndrome imitation. Not many > devices are immune either! > > -- > > -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 > > > > -- -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: 21703
No, I'm just presenting the technical side of what I suspect is the vendor's reluctance to release it. There are times I've needed to get into the bitstream to modify it slightly, and there an open format would have been helpful. On the otherhand, I can plainly see why the Vendors would not want to put this out for general consumption. Greg Alexander wrote: > In article <pLMYl5dhX7hK-pn2-XheSdoZUGmYc@localhost>, Keith R. Williams wrote: > >On Wed, 29 Mar 2000 00:44:09, Ray Andraka <randraka@ids.net> > >wrote: > > > >> Well, no. It's application is not determined, but it's function is. It is a rather > >> complex state machine that executes a limited number of different instructions, generally > >> in a serial fashion. The hardware is what it is and you can't change it no matter what > >> you do to the processor (well, putting power on it backwards to change it into a lump of > >> epoxy encapsulated glass doesn't count). As a result, the permutations of how it gets > >> used in a system are pretty well limited. The timing of the signals, the functions of the > >> pins etc all remain pretty much the same (some pins may be programmable for more than one > >> function, but you can't move a pin to another location etc). All of this constrains the > >> range of applications much more so than what you have with an FPGA. It also allows the > >> vendor to get away with a relatively small number of applications notes discussing how it > >> gets used in a system. An error in the microprocessor instruction stream generally will > >> not damage the processor, and each instruction is more or less stand-alone. An FPGA > >> bitstream sequence very is very tightly coupled to itself, in that 1) A wrong bitstream > >> can burn up the device in many families, 2) the bitstream as a whole has to be internally > >> consistent to make the connections between logic blocks. > > > >I really hadn't considered this but yes, the Xilinx and > >Synplicity tools do warn (actually more like stop dead) of > >impending doom when two drivers are on the same net when they > >could be activated at the same time. This is an excellent > >argument in favor of keeping the bitstream proprietary. > > Let me sumarize this to make sure I get it straight: Because you don't feel > like spending the effort to write the stream directly or write software to > check the bitstream's validity (perhaps as writing it), they shouldn't > release the bitstream specs for anyone to use? -- -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: 21704
I didn't mean to imply that hardware is harder to do than software (the fact that I write crummy C code but seem to do pretty well with hardware would suggest perhaps the opposite is true ;-) ). What I'm trying to say, is difficulties with programming a microprocessor are not as likely to generate support calls for the chip vendor. Those errors are pretty well understood as software errors. From what I've seen (admittedly from the outside) the FPGA support calls run over a much broader range because it is often not as easy to determine where the problem lies since the line between the user stuff and the chip is blurred, plus the average FPGA user has not taken the time to really understand the architecture/tools so he ends up making mistakes that look for all the world like problems wiht the chip or tools. Perhaps part of the problem is that the silicon vendor is also the tools vendor for the FPGAs, which is typically not the situation with microprocessors. Rickman wrote: > Ray Andraka wrote: > > Well, no. It's application is not determined, but it's function is. It is a rather > > complex state machine that executes a limited number of different instructions, generally > > in a serial fashion. The hardware is what it is and you can't change it no matter what > > you do to the processor (well, putting power on it backwards to change it into a lump of > > epoxy encapsulated glass doesn't count). As a result, the permutations of how it gets > > used in a system are pretty well limited. The timing of the signals, the functions of the > > pins etc all remain pretty much the same (some pins may be programmable for more than one > > function, but you can't move a pin to another location etc). All of this constrains the > > range of applications much more so than what you have with an FPGA. It also allows the > > vendor to get away with a relatively small number of applications notes discussing how it > > gets used in a system. An error in the microprocessor instruction stream generally will > > not damage the processor, and each instruction is more or less stand-alone. An FPGA > > bitstream sequence very is very tightly coupled to itself, in that 1) A wrong bitstream > > can burn up the device in many families, 2) the bitstream as a whole has to be internally > > consistent to make the connections between logic blocks. > > Your point summarizes to, ==FPGAs are more complex because you are > programming hardware and hardware is more complex than software== I > disagree with this concept. The pins on the chip may not move and the > timing in relation to the clock may not change, but there are very > significant issues in how to connect a micro to your circuit in terms of > "if I use this pin for that and that pin for this, then I can only use > this other pin for this and not that". > > The higher level timing, which is what you will be coding in software > which is what we are talking about, can be just as complex as the low > level timing, if not more so. Then on top of all that, there are very > significant issues in software design that you will never see in > hardware. Many processors have special instructions for semaphores and > other interlocked operations which almost never occur in hardware > designs, and if they do are rather trivial to deal with since you can > design the hardware to do just what you want. > > And a micro may not selfdestruct just because you misprogram it, but you > can certainly do damage with your circuit it is in. This is one of those > cases where it can be VERY important to control the timing of your code. > Just ask the designers of an inkjet printer! I wonder how many print > heads were destroyed before they got the first unit up and running? It > would also be a very simple task to write a program to verify that a > bitstream won't do damage to a chip. This could be provided along with > the full description of the bitstream format to protect the engineer > from himself ;) > > We can argue points of complexity for a long time, but I doubt that you > can make a supportable argument that there is something inherently more > difficult about designing hardware over designing software for a micro. > > But even if FPGAs are more complex to program than a micro, is that > really a reason to prevent an engineer from having the information to > use a chip the way he wants? > > -- > > Rick Collins > > rick.collins@XYarius.com > > remove the XY to email me. > > Arius - A Signal Processing Solutions Company > Specializing in DSP and FPGA design > > Arius > 4 King Ave > Frederick, MD 21701-3110 > 301-682-7772 Voice > 301-682-7666 FAX > > Internet URL http://www.arius.com -- -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: 21705
I am designing a processor that runs the calculator game "worm". I have
designed it in VHDL and I am going to use a Flex10k part to synthesize
it. I want help with the VGA display. Basically if anyone can help me find
something on how I can build a VGA module that will interact with my
datapath and the game as a whole.
--
---------------------------------------------------
"time and space are modes by which we think...... |
they are not the conditions in which we live." |
|
~~Einstein |
---------------------------------------------------
Anshuman Sharma
Georgia Institute of Technology, Atlanta Georgia, 30332
Email: gte600f@prism.gatech.edu
anshu@abraxis.com
Article: 21706Hi all We have one of these boards and are having some hassle because the data sheet on the web site gives the wrong FPGA to PC104 bus interface pin mapping. We are also not sure about the FPGA to ZBT RAM pin mapping (or any of the rest of it). This part of the data sheet appears to have been copied from the X240 data sheet but doesn't match the PCB. APS have not replied to our emails about this. Before we resort to microscope and continuity tester can anybody help with any more info? Regards KateArticle: 21707
I've noticed that there are now a couple of hardware TCP/IP implementations around, like the Seiko S7600, and there is a VHDL TCP/IP stack in some IP at www.iReady.net. Does there exist a free or low cost attempt at a TCP/IP stack which would fit in a Xilinx FPGA? I'm thinking in terms of a system-on-a-chip web appliance, and/or a high speed NAS processor. -- Gary Watson gary@nexsan.sex (Change dot sex to dot com to reply!!!) Nexsan Technologies Ltd. Derby DE21 7BF ENGLAND http://www.nexsan.comArticle: 21708
--------------22F4A0421E54CA156D3EAD6D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit http://www.xilinx.com/support/support.htm type SEU, and select everything gets you 14+ references and papers on the website...doesn't anyone ever if check what's already there? Austin Joe Hass wrote: > In article <38E01B5D.9EBC46FD@nospam.erols.com>, > rk <stellare@nospam.erols.com> writes: > |> Here's some data, from Los Alamos National Labs, presented at MAPLD 1999, for Virtex > |> devices: > |> LETth Saturated X-Sec > |> MeV-cm^2/mg cm^2/bit > |> CLB 5.0 6.5 x 10^-8 > |> LUT 1.8 21.0 x 10^-8 > |> BRAM 1.2 16.0 x 10^-8 > > Thanks for posting this data. Were there any threshold LET values for > latchup presented? Latchup can be a more severe threat in the sense > that it can complicate the board-level and power supply design issues. > Of course, you can't use TMR within a single FPGA to avoid latchup, > either...but I suspect that you know this already. > > Can you give me a bit more of a reference for this paper so I can try > to get ahold of a copy? > > Thanks, > Joe > -- > --------------------------------------------------------------------------- > == K. Joseph Hass == Microelectronics Research Center == > == http://www.mrc.unm.edu/~jhass == 801 University Blvd SE, Suite 206 == > == (505) 272-7055 == Albuquerque, NM 87106-4340 USA == --------------22F4A0421E54CA156D3EAD6D Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit <!doctype html public "-//w3c//dtd html 4.0 transitional//en"> <html> <a href="http://www.xilinx.com/support/support.htm">http://www.xilinx.com/support/support.htm</a> <p>type SEU, and select everything <p>gets you 14+ references and papers on the website...doesn't anyone ever if check what's already there? <p>Austin <p>Joe Hass wrote: <blockquote TYPE=CITE>In article <38E01B5D.9EBC46FD@nospam.erols.com>, <br> rk <stellare@nospam.erols.com> writes: <br>|> Here's some data, from Los Alamos National Labs, presented at MAPLD 1999, for Virtex <br>|> devices: <br>|> LETth Saturated X-Sec <br>|> MeV-cm^2/mg cm^2/bit <br>|> CLB 5.0 6.5 x 10^-8 <br>|> LUT 1.8 21.0 x 10^-8 <br>|> BRAM 1.2 16.0 x 10^-8 <p>Thanks for posting this data. Were there any threshold LET values for <br>latchup presented? Latchup can be a more severe threat in the sense <br>that it can complicate the board-level and power supply design issues. <br>Of course, you can't use TMR within a single FPGA to avoid latchup, <br>either...but I suspect that you know this already. <p>Can you give me a bit more of a reference for this paper so I can try <br>to get ahold of a copy? <p>Thanks, <br>Joe <br>-- <br>--------------------------------------------------------------------------- <br>== K. Joseph Hass == Microelectronics Research Center == <br>== <a href="http://www.mrc.unm.edu/~jhass">http://www.mrc.unm.edu/~jhass</a> == 801 University Blvd SE, Suite 206 == <br>== (505) 272-7055 == Albuquerque, NM 87106-4340 USA ==</blockquote> </html> --------------22F4A0421E54CA156D3EAD6D--Article: 21709
On Wed, 16 Feb 2000 13:34:13 GMT, rob_dickinson@my-deja.com wrote: >Can I STRONGLY suggest that you spend a couple of hours finding out >what a CPLD is, otherwise this will only be the first of many foolish >things that you try to do with your "design". > >I'm not that familliar with the XILINX CPLD's but if this is a one off >student(ish) design then you can delay your clock by feeding it through >at least three(?) macrocells and then EXOR the input clock with the >delayed version. This will give you a very short pulse on the rising >and falling edge of your clock which you can clock everything else >with. > >When you have discovered what a CPLD is you will see how dangerous this >is but it will get you out of a hole if your PCB is allready built. > >Rob > > >Sent via Deja.com http://www.deja.com/ >Before you buy. A slightly safer way of doing it is as follows: The input clock is fed to the input of an XOR and to the D pin of a DFF. The output of the DFF is fed back to the other input of the XOR. The output of the XOR feeds the clock of the DFF and the doubled clock. The width of the doubled clock is determined by the delay going through the DFF and the XOR. If you want to lenghten the width of the doubled clock, add delay between the DFF output and the XOR. The advantage to this design is that you know that the clock will be long enough to clock the F/Fs in the design. LaRellArticle: 21710
Is the software usable with any real FPGAs or it is just an academic exercise? Tried to download paper, but it was >Not Found > >The requested URL /~vaughn/papers/fpl97.ps.gz was not found on this server. Vaughn Betz wrote: > > A new version of the "academic" VPR and T-VPack packing, placement and routing > CAD tool set for research is available on my web site. This latest version > includes the enhancements Alexander (Sandy) Marquardt made to VPR during his > M. S. degree -- timing-driven logic block packing and timing-driven placement. > It can be freely used for non-commercial research, and can be downloaded > from: > > http://www.eecg.toronto.edu/~vaughn/vpr/vpr.html > > Just for clarity, this code is the "academic" (i.e. code written at the > Univerity of Toronto during various students' grad degrees) VPR -- it is not > the code for the more recent, commercial version of VPR. > > Vaughn Betz regards, Tom Burgess -- Digital Engineer Dominion Radio Astrophysical Observatory P.O. Box 248, Penticton, B.C. Canada V2A 6K3 Email: tom.burgess@hia.nrc.caArticle: 21711
For a design of a Virtex Circuit programmed with a Xilinx 1804 PROM, there is a reason that the the CF output of the chip will be grounded. The 1804 PROM datasheet doesn't spec the short-circuit current, nor does it mention whether or not it the pads can drive GND for any prolonged time. Anyone know whether or not the PROM's I/O pads are are safe to drive short-circuit loads? -john lockwoodArticle: 21712
I have a convolution design targetting XC4000 series. One using schematics with proper floorplanning and another one using VHDL at RTL level (pretty the same but not mapped onto the LUTs and not placed). I got 20% improvement in speed and 5% in area by using floorplanning. I am using Synopsys as a VHDL synthesiser. That seems too much for me (20% of speed). Why are people advocating behavioural synthesis if VHDL at RTL level lags 20% in speed compared to floorplanning??? Even worse, I took another design containing 9 pretty complicated state machines. I got 100 CLB saving by using floorplanning compared to VHDL at RTL level (the latter occupies 550 CLBs) !!!! and more than 20% speed improvement. I do not know if this is a valid figure? or is my RTL coding poor??Article: 21713
Does anybody know if it's possible to build a redundant multiplier (i.e.
digit set {-3,...,3}) using conventional adders (i.e. digit set {0,1}) to do
the sums of partial products? I Hope not.
Be careful because the answer is not easy.
The intention is to use the very effective conventional 4-bit adders that
are in a FPGA to do the additions of redundant partial products. Otherwise,
implement redundant adders is very costly in FPGAs.
Thank you in advance,
Joe
Article: 21714In article <8bt2io$rnp$1@nnrp1.deja.com>, rob_dickinson@my-deja.com wrote: >Having read most of this thread I have the following global comments. > >1)If you just want to play then surely you can understand that company >A or X have better things to do than to be bothered with even a few >hundred people going "your" route. Total disagreement. As I've said before, most people competent in the field learned most of what they knew going in just playing around. The more hobbyists playing with it today the more companies buying hte things tomorrow. I think Linux's commercial success proves that -- I don't think managers picked it because htey liked it, I think managers picked it because their employees said "I know and like Linux, it'll do the job and if it doesn't we'll make it." >2)Assuming that your a better programmer than those employed by A or X >(I actually think that, on average, this is likely), your tool might >end up in some way better than the commercial stuff (which I don't >think is likely), I would imagine that you would insist on the GNU/open >source license. If its a better tool then the whole world would use it >with hundreds of its inevitable variants. A or X would find themselves >giving crap support for a great tool to people who have no interest in >software instead of good support to a reasonable tool. This is not in >their interest (or mine). I would not assume I'm a better programmer than employees of A or X, merely that I know better what I want. Also, "inevitable variants" is greatly overstated -- how many times has Linux (kernel) branched? gcc? ACS? Those that have branched are slowly reintegrating, making the branches look more like alpha/beta testing cycles than actual branches. At any rate, the points about support are probably valid and I would blame A or X for supporting the third party products, but I can see why they would decide otherwise. I could argue that if they got a lot of hobbyist interest, they wouldn't be faced with supporting people at companies, and hobbyists usually don't expect too much support from vendors. In other words, the people who actually get hired will already be familiar with how to use the FPGAs. I won't, though, because I really don't want to speculate too much on how the real world works out. There are a lot of employed morons out there on tech support lines all day. Note that XDL exists and provides just as much potential for hard to support 3rd party products. >3) Vantis failed for the second time(I think) with an FPGA family about >2 years ago. I was told that "our silicon is great but our tools just >didn't deliver". This gives some indication of the difficulty involved. >4) People have talked about the likelyhood of a bad bitstream damaging >the device, I would be interested in knowing the real figure but I >would expect that 99.something% bitstreams would cause this. Yeah, that is a worry. >5) You talk about all this being simillar to micro-controllers. Yes it No I don't. That was someone else's comment. I wish to build something similar to a micro-controller, but that is a side issue. >is possible for a micro-controller to destroy itself if programmed >badly but some very simple hardware design would eg current limit its >pins. I'm sure that the final, cost engineerd, dishwasher could >destroy itself if prgrammed badly but I'm equally sure that the >software protoyping dev system couldn't. Your FPGA would not tolerate >this, it would sit there with one internal driver(eg) frying nicely, >drawing so little current that you wouldn't notice. > >In short, company A and X are interested in making money. I have no >problem with that, if you do I suggest that you change planets. They >are interested in selling to customers who are going to buy buckets of >their stuff, to whom they give the software to for nothing and give >excellent support. The standard business saying "20% of their >customers give them 80% of their business" holds true and the rest of >us (well, the rest of you actually) are hanging on. The good news is >that our volumes drive down the prices for you (your buying n million >devices for nearly nothing), the bad news is that your not getting >quite what you want. Yes. Thanks. :) >I suggest that you go cry in your beer and then go find something that >people will let you play with. Being 19, the government here also doesn't allow me the choice between crying in beer or crying in my milk. If only the engineering secrecy were as easily circumvented as prohibition. :)Article: 21715
Tom Burgess <tom.burgess@hia.nrc.ca> wrote in message news:38E245D1.B020618E@hia.nrc.ca... > Is the software usable with any real FPGAs or it is just an academic exercise? Isn't this the stuff Altera is picking up? SteveArticle: 21716
The data sheet describes CF as an open drain ( "open collector" ) output. That means you can short-circuit it to ground as long as you like, since there is no active pull-up inside the chip. Peter Alfke, Xilinx Applications ==================================== John Lockwood wrote: > For a design of a Virtex Circuit programmed with > a Xilinx 1804 PROM, there is a reason that the > the CF output of the chip will be grounded. > > The 1804 PROM datasheet doesn't spec the > short-circuit current, nor does it mention whether or > not it the pads can drive GND for any prolonged time. > > Anyone know whether or not the PROM's I/O pads > are are safe to drive short-circuit loads? > > -john lockwoodArticle: 21717
In article <38E21159.490EB7CD@ids.net>, Ray Andraka wrote: >No, I'm just presenting the technical side of what I suspect is the vendor's reluctance to >release it. There are times I've needed to get into the bitstream to modify it slightly, and >there an open format would have been helpful. On the otherhand, I can plainly see why the >Vendors would not want to put this out for general consumption. I was replying to Keith, not you. :)Article: 21718
This is a multi-part message in MIME format. --------------9E7AA152B15CADB4B25C6059 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit All, If I interpret the datasheet, it says that the 4 global clock nets in a Xilinx Virtex device can only be used for clocks. Before we read this, we implemented a reset signal using one of the global clock buffers and global clock nets. We did not get any errors in synthesis or place and route. We have done gate level simulations on the netlist and it simulates fine. However, the Xilinx doc clearly states that, "Four global buffers drive the four primary global nets that in turn drive any clock pin." So, the question remains: Can we use the global nets for global signals other than clocks??? Tom --------------9E7AA152B15CADB4B25C6059 Content-Type: text/x-vcard; charset=us-ascii; name="tomm.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Tom McLaughlin Content-Disposition: attachment; filename="tomm.vcf" begin:vcard n:McLaughlin;Tom tel;fax:314-935-7302 tel;work:314-935-7198 x-mozilla-html:FALSE url:http://www.arl.wustl.edu/~tomm org:Washington University;Applied Research Lab version:2.1 email;internet:tomm@arl.wustl.edu title:Research Associate adr;quoted-printable:;;One Brookings Drive=0D=0ACampus Box 1045-ARL;St. Louis;MO;63130;USA x-mozilla-cpt:;0 fn:Tom McLaughlin end:vcard --------------9E7AA152B15CADB4B25C6059--Article: 21719
hi, if i am not wrong, it will still route to any CLB input , but the delay and signal skew will not be good. spyng In article <38E285A0.2555F77D@arl.wustl.edu>, Tom McLaughlin <tomm@arl.wustl.edu> wrote: > This is a multi-part message in MIME format. > --------------9E7AA152B15CADB4B25C6059 > Content-Type: text/plain; charset=us-ascii > Content-Transfer-Encoding: 7bit > > All, > If I interpret the datasheet, it says that the 4 global clock nets in a > Xilinx Virtex device can only be used for clocks. Before we read this, > we implemented a reset signal using one of the global clock buffers and > global clock nets. We did not get any errors in synthesis or place and > route. We have done gate level simulations on the netlist and it > simulates fine. However, the Xilinx doc clearly states that, "Four > global buffers drive the four primary global nets that in turn drive any > clock pin." > > So, the question remains: > > Can we use the global nets for global signals other than clocks??? > > Tom > > --------------9E7AA152B15CADB4B25C6059 > Content-Type: text/x-vcard; charset=us-ascii; > name="tomm.vcf" > Content-Transfer-Encoding: 7bit > Content-Description: Card for Tom McLaughlin > Content-Disposition: attachment; > filename="tomm.vcf" > > begin:vcard > n:McLaughlin;Tom > tel;fax:314-935-7302 > tel;work:314-935-7198 > x-mozilla-html:FALSE > url:http://www.arl.wustl.edu/~tomm > org:Washington University;Applied Research Lab > version:2.1 > email;internet:tomm@arl.wustl.edu > title:Research Associate > adr;quoted-printable:;;One Brookings Drive=0D=0ACampus Box 1045-ARL;St. Louis;MO;63130;USA > x-mozilla-cpt:;0 > fn:Tom McLaughlin > end:vcard > > --------------9E7AA152B15CADB4B25C6059-- > > Sent via Deja.com http://www.deja.com/ Before you buy.Article: 21720
It depends on the Xilinx family: In XC4000 and all its derivatives ( incl. Spartan and SpartanXL) you can use the global nets for anything you might want. In Virtex and its derivatives ( incl. Spartan-II) you can use the global clock nets *ONLY* as clocks. If you were to use them for other purposes, the routing would actually use the normal routing channels. So this would be self-defeating. Peter Alfke, Xilinx Applications ========================================= Tom McLaughlin wrote: > All, > If I interpret the datasheet, it says that the 4 global clock nets in a > Xilinx Virtex device can only be used for clocks. Before we read this, > we implemented a reset signal using one of the global clock buffers and > global clock nets. We did not get any errors in synthesis or place and > route. We have done gate level simulations on the netlist and it > simulates fine. However, the Xilinx doc clearly states that, "Four > global buffers drive the four primary global nets that in turn drive any > clock pin." > > So, the question remains: > > Can we use the global nets for global signals other than clocks??? > > TomArticle: 21721
I am evaluating MaxPlus 9.5 and am finding that often the software can not seem to locate the dongle during the build process on larger designs. The software give me a license error message. Also, when selecting the Quartus fitter, I am getting internal errors (contact Altera, who never has a clue). Both problems occur on two different computers. Just wonder if anyone else is using this version yet.Article: 21722
Hi all, Anyone out there know of any references, texts or otherwise, that may give me an idea on how to take in a 10gbit/s serial data stream into an fpga or an array of fpga's ? Also, any ideas on what I should be looking for in and fpga to be able to accept that kind of input ? TIA AnoopArticle: 21723
Ray Andraka <randraka@ids.net> writes: > Well, no. It's application is not determined, but it's function is. It is a rather > complex state machine that executes a limited number of different instructions, generally > in a serial fashion. The hardware is what it is and you can't change it no matter what > you do to the processor (well, putting power on it backwards to change it into a lump of > epoxy encapsulated glass doesn't count). As a result, the permutations of how it gets > used in a system are pretty well limited. The timing of the signals, the functions of the > pins etc all remain pretty much the same (some pins may be programmable for more than one > function, but you can't move a pin to another location etc). All of this constrains the > range of applications much more so than what you have with an FPGA. It also allows the > vendor to get away with a relatively small number of applications notes discussing how it > gets used in a system. An error in the microprocessor instruction stream generally will > not damage the processor, and each instruction is more or less stand-alone. An FPGA > bitstream sequence very is very tightly coupled to itself, in that 1) A wrong bitstream > can burn up the device in many families, 2) the bitstream as a whole has to be internally > consistent to make the connections between logic blocks. Let me disagree. If I buy say an AVR controller, almost every pin on the chip is an I/O pin, freely usable for any purpose I want. In that sense, the permutations it can be used in is pretty much the same as an FPGA with the same number of pins. As a matter of fact, there's quite a range of applications where the two would be interchangeable. It is up to your software to use portB(3) or portD(7) for any given function, that is, pins can be moved all around the place. While the reaction time of a microcontroller is orders of magnitude slower than that of an FPGA, it is not fundamentally different in that it receives stimuli and its response behaviour is determined by its program (bitstream, if you like) that you have downloaded into it. A microprocessor code or bitstream is just as coupled with itself as an FPGA bitstream - if you change a single bit in a single instruction, you can (and with a high probablity you will) screw up the functionality of your controller the same way as you'd mess up the FPGA. You won't destroy a stand-alone chip, I have to admit this one. Instructions are *never* standing alone. Every instruction gets its (functional) meaning from being part af the overall instruction stream, the program, just like any FF in an FPGA gets its meaning from being part of the overall circuitry. Dumping a random bitstream into a uC won't make it behaving any more useful than dumping the same bitstream into an FPGA. It probably won't smoke but that's about it. The uC bitstream as a whole has to be (self-) consistent the same way as in 2). I understand the difference between the *architecture* of an FPGA and a microcontroller. This architectural difference makes them suitable for different (but overlapping) application domains. Computationally they are equivalent, anything an FPGA can do a uC can (given enough time) and anything a uC can do, an FPGA can (assuming that the FPGA is big enough). I just don't see why should they be fundamentally different in terms of specifications. Zoltan -- +------------------------------------------------------------------+ | ** To reach me write to zoltan in the domain of bendor com au ** | +--------------------------------+---------------------------------+ | Zoltan Kocsi | I don't believe in miracles | | Bendor Research Pty. Ltd. | but I rely on them. | +--------------------------------+---------------------------------+Article: 21724
On Wed, 29 Mar 2000 05:14:27, galexand@sietch.bloomington.in.us (Greg Alexander) wrote: > In article <pLMYl5dhX7hK-pn2-XheSdoZUGmYc@localhost>, Keith R. Williams wrote: > >On Wed, 29 Mar 2000 00:44:09, Ray Andraka <randraka@ids.net> > >wrote: > > > >> Well, no. It's application is not determined, but it's function is. It is a rather > >> complex state machine that executes a limited number of different instructions, generally > >> in a serial fashion. The hardware is what it is and you can't change it no matter what > >> you do to the processor (well, putting power on it backwards to change it into a lump of > >> epoxy encapsulated glass doesn't count). As a result, the permutations of how it gets > >> used in a system are pretty well limited. The timing of the signals, the functions of the > >> pins etc all remain pretty much the same (some pins may be programmable for more than one > >> function, but you can't move a pin to another location etc). All of this constrains the > >> range of applications much more so than what you have with an FPGA. It also allows the > >> vendor to get away with a relatively small number of applications notes discussing how it > >> gets used in a system. An error in the microprocessor instruction stream generally will > >> not damage the processor, and each instruction is more or less stand-alone. An FPGA > >> bitstream sequence very is very tightly coupled to itself, in that 1) A wrong bitstream > >> can burn up the device in many families, 2) the bitstream as a whole has to be internally > >> consistent to make the connections between logic blocks. > > > >I really hadn't considered this but yes, the Xilinx and > >Synplicity tools do warn (actually more like stop dead) of > >impending doom when two drivers are on the same net when they > >could be activated at the same time. This is an excellent > >argument in favor of keeping the bitstream proprietary. > > Let me sumarize this to make sure I get it straight: Because you don't feel > like spending the effort to write the stream directly or write software to > check the bitstream's validity (perhaps as writing it), they shouldn't > release the bitstream specs for anyone to use? Well, yes, looking at the issue from the other side of the mirror. Support costs are a major part of a company's costs. It makes perfect sense to minimize that cost in any reasonable way. Sure, many times I don't lake the "way", but that is their call. I was rather on your side until I thought about the *mess* of wiring and switching in a modern FPGA. No, I think you're wrong now. I cannot imagine any company trying to make a buck releasing this information without *strict* controls. I'm qute sure this information is released, but with such controls. I'm rather a fan of the open software movement and would really appreciate Linux based tools for FPGAs (my target system runs Linux, which I fought for for months), but I'm humble enough to realize that I can't know everything. I'll even run Windows, if I can get support for my problems, of which there are many. You said it perfectly Greg. I'm more interested in solving a problem, than learning minutae. My problem now is far bigger than bitstreams. I cannot imagine having enough time to worry about such. These things change with the wind. I'm told that even Virtex and VirtexE have totally different bitstreams. This is going to cause me all sorts of problems supporting both (as he says lobbying to replace the Virtex parts with /E's, when he can latch onto them). No Greg, we live in *very* different worlds. Xilinx want's to make money for their stock-holders and I have no problems with this noble goal. Unfortunately, that means we both suffer, but opposite extremes. You want something for nothing, and I can't buy what I need for any money. We're not that far different though. Neither cares about money (however, the money that I don't care about here is my employer's ;-). ---- Keith P.S. Sorry to vent, but it's been a *BAD* week!
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