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
kebm@flash.net wrote: > While I agree that it does sound like satish is whining or > trying to lay > blame for why he hasn't gotten started on his project yet, > it really is the > responsibility of the local reps to keep the customer > happy. If they can't > help this guy out before he gets frustrated enough to post > a message like > this, perhaps one of their competitors can... > Let's put this silly case to rest. Right after I read the original posting, I forwarded it to our office in Hong-Kong, who forwarded it to our Indian rep. And satish is happy and has apologized profusely about his posting, as you can read here: "I am sorry to put the blame on such an well established company. After my request the local rep. has turned to me. Any how I apologise for putting this in the net." Serving a subcontinent that has a relatively small revenue base, is not easy. And just flaming on the internet is not the appropriate complaint procedure. End of story. Peter Alfke, Xilinx ApplicationsArticle: 14476
Austin Franklin wrote: > I am curious what the cost difference is between the two parts. Perhaps someone will post some prices. Spartan XL (say XCS05pc84-4) would be another interesting point. It would probably top the schematic's speed (the schematic is still locked into whatever Orca's cost and speed is), and I suspect it would be cheaper. Got the numbers? The VHDL design isn't locked into any part by non portable schematics. > Personally, that is how I compare parts...since it is difficult to > establish comparative parameters between two different vendors, I just look > for comparably priced parts that the design will work in....and choose the > cheaper part... It is silly to take a design that can work in a $14 part, > and implement it in a $45 part...unless you REALLY need the room for future > upgrades...or you really insist on using an HDL ;-) Total cost is a key metric, not cost per part. As an example, suppose you are building 30 boards (total, forever, that's the whole market) with 4 FPGAs each. The difference between the $45 parts and the $14 parts is less than $1000. How many hours do you work for $1000? How many hours would it take you to port this simple design to: Xilinx Spartan? Or Gatefield? Or for real speed and/or minimum cost per part, a gate array? Suppose you needed to make a RAD-hard variant? How long would it take to convert from a SRAM based FPGA to a antifuse based FPGA like for example, Actel? It took me about 71 seconds to have a fair idea as to what sort of speed this design would run in an a3265dx. Is ~25 MHz good enough? Or should I spend some time looking at other parts (like say a a1225xl)? Or doing some physical VHDL to improve the critical path? Is there a lot to be gained by floorplanning this design? Suppose that you evaluated all parts for a design and found that the BAR3456 was the only realistic choice, at $800 (gasp) each. Just as you finishing the design FOO inc. announced the FOO6543, same functionality, at $100 each.. Schematics would require a major redo. HDLs, on the other hand, might be as simple as running the tools again... -- Phil Hays "Irritatingly, science claims to set limits on what we can do, even in principle." Carl SaganArticle: 14477
I was wondering where I could get a hold of Espresso, the logic minimization tool, or any other logic minimization tool for a non-industrial price (under $100 or shareware) somewhere on the net. This information would be very valuable to me. Thanks, GeraldArticle: 14478
> The VHDL design isn't locked into any part by non portable > schematics. Since when are schematics non-portable? I guess they can be if you draw them 'instantiating' every element of the explicit library....but only a very inexperienced person would do such a thing. Anyone with any savvy would use higher lever symbols, and only 'instantiate' the very lowest level elements, making the schematics 98% portable. Once you 'instantiate' the low level schematic elements for a given technology, you can re-use them for future designs...and once you make the high level symbols, they are good for almost any technology.... It appears to be a very overlooked method of design....because it takes a bit of work up front. > Total cost is a key metric, not cost per part. Obviously. > How > many hours would it take you to port this simple design to: Xilinx > Spartan? Or Gatefield? Or for real speed and/or minimum cost per part, > a gate array? Not much time at all (Gatefield?) as I have libraries for most 'common' FPGAs and gate arrays. And even if I didn't have the library, it would take maybe a half an hour for 'normal' designs to make a new library... > Suppose you needed to make a RAD-hard variant? How long would it take > to convert from a SRAM based FPGA to a antifuse based FPGA like for > example, Actel? I only have to change a library reference line. Probably about 10 seconds. > Is > there a lot to be gained by floorplanning this design? In 98% of the designs I have done, yes. It takes so little time to do if the design is done correctly up front, and the benefit is always substantial. > Suppose that you evaluated all parts for a design and found that the > BAR3456 was the only realistic choice, at $800 (gasp) each. Just as you > finishing the design FOO inc. announced the FOO6543, same functionality, > at $100 each.. Schematics would require a major redo. HDLs, on the > other hand, might be as simple as running the tools again... Your assumptions are just not true. Schematics are usually as simple as changing a library reference, if the design is done correctly. We (this group) have hashed out this before. It is a fact HDLs fall short when it comes to doing high performance designs (speed/density) unless you 'over buy' the part (get a faster larger part then you need, which usually will cost you more). With HDLs floorplanning is currently difficult, especially if you change the design at all. Also, you can end up fighting with the HDL and the tools to get the thing to generate the gates you want. Every time I take a job that started as an HDL and the client wonders why they can't get the performance and density they were promised, it reinforces my belief that yes, schematics are more work up front...but in the long run, they are worth it. This experience comes from over 68 FPGA designs, 32 clients, and 11 years of doing mostly FPGAs. Austin "The fastest way from the top of the Empire State Building to the bottom is to jump, but better results would be achieved by taking the elevator. That is, of course, dependant on what the desired results were in the first place."Article: 14479
z80@ds2.com (Peter) writes:
> The way a CPU interfaces to RAM is determined by the hardware, not
> the O/S. But lots of people say what you say.
The hardware would be the chipset and that is in turn controlled by
the OS (and/or the BIOS). NT does, AFAIK, test the RAM at bootup and
also interrogates the modules for their parameters (that's what the
little EEPROM on the modules is for). If any of these informations
mismatch, it gets extremely concerned. As a matter of fact, sometimes
the data in the EEPROM is wrong or the EEPROM is missing altogether on
cheap modules. NT will cry foul if it encounters this situation,
whereas Win95 will live with whatever parameters (hopefully
conservative) have been set by the BIOS.
Achim Gratz.
--+<[ It's the small pleasures that make life so miserable. ]>+--
WWW: http://www.inf.tu-dresden.de/~ag7/{english/}
E-Mail: gratz@ite.inf.tu-dresden.de
Phone: +49 351 463 - 8325
Article: 14480Yes Austin but how? I know you are an experienced h/w man; you must be asking yourself the same question :) It has to be down to NT actually *using* the extra RAM, or doing something different with the chipset (e.g. wait states), or the RAM interface was marginal to start with and NT generates the violation traps whereas win9x doesn't and falls over some time (perhaps much later) instead. Most motherboards are built in Taiwan these days. My experience of their *high-end* design expertise is not good. And 100MHz, or even 66MHz, motherboard design is not far off state of the art. >I have experienced the exact same thing. It is even fussy about DIFFERENT >manufacturers SIMMs/chips in the same system.... -- Peter. Return address is invalid to help stop junk mail. E-mail replies to zX80@digiYserve.com but remove the X and the Y. Please do NOT copy usenet posts to email - it is NOT necessary.Article: 14481
Hi to all!! I installed an evaluation version of FPGA Express, but It ask me for a key... Viewlogic Support didn't reply!!! Do someone know how to resolve this problem???? Thanks in advance! mailto:samer1@hotmail.comArticle: 14482
Duck Foot wrote:
> Textbooks tell how to get rid of static hazards inherent in a sum of
> products network. They say the hazard comes from transitions between
> neighboring product terms, and can be eliminated by adding redundant
> implicants.
> Do we also call the transitions between two apart product terms,
> e.g. diagonally positioned ones, hazard? How can I eliminate glitches
> born of this kind of network? - In this case circling 0's to eliminate
> 0-hazard also results in diagonal configuration.
I use sychronous logic, and most of the glitches were found to be
combinations of synchronous signals. I could eliminate some of them by
adding redundant implications, but I still couldn't when the implicants were
not adjacent.
I wonder why most of you say glitches doesn't matter in synchronous
logic. In my humble view, it matters when it occurs on the edge of clock.
What do you think?
Article: 14483Duck Foot wrote: > I used sychronous logic, and most of the glitches were found to be > combinations of synchronous signals. I could eliminate some of them by > adding redundant implications, but I still couldn't when the implicants were > not adjacent. > I wonder why most of you say glitches doesn't matter in synchronous > logic. In my humble view, it matters when it occurs on the edge of clock. > What do you think? Well, I can speak only for myself, not for "most of you"; but here's my $0.02 anyway. If you have a classically-designed synchronous system of the Mealy type (i.e. with no output combinatorially dependent on any asynchronous input) then of course, as you say, any output glitches will occur close to clocking transitions because that's the only time that an internal signal is allowed to change. These glitches are not, however, "on the edge" of the clock. They occur one clock-to-output delay after the clock that caused the relevant internal state changes. This can't affect circuit operation - it truly doesn't matter - because of the way synchronous circuits, and in particular edge-triggered flipflops, work. Each flipflop looks at its inputs just _before_ the clock edge and computes what to do with its outputs just _after_ the clock edge. Clock-induced glitches can't affect the action of the flipflop. To be a little more precise about it: suppose the flops in your system have a setup time requirement (inputs must be stable at least this time before the clock edge) of Tsu; a clock- to-output delay (outputs change this time after the clock edge) of Tco; and, to be realistic, let's accept that the clock doesn't arrive at every flop in the system simultaneously, and the worst difference between any two flops' clock arrival time is Tskew. We must also take into account the propagation delay of the combinatorial logic that generates the new set of inputs from the existing outputs; call that Tpd. Finally we need to consider how long after a clock edge the inputs must remain stable for the flop to do its stuff reliably; that's the hold time, Thold. Then we put the whole thing into a real system which is being clocked with a clock period Tcyc. So, after the clock edge, flops see new inputs after Tco+Tpd. It's not hard to see where these two golden rules must come from: Tco(min)+Tpd(min)-Tskew(max) >= Thold(max) --(1) Tco(max)+Tpd(max)+Tskew(max)+Tsu(max) <= Tcyc --(2) (1) says that we must avoid the situation where an output change might appear as an input change on another flop so early that it violates the second flop's hold time requirement. (2) says we must not clock the system so fast that output changes appear as input changes so late that they violate the setup time. I suspect that you are worrying about (1): glitches around the clock edge might affect the behaviour of other flops _on that same edge_. But if the synchronous system is to work at all, (1) must be satisfied, glitches or no glitches; and so your glitches are harmless. Of course, there _is_ a problem if you have downstream logic which might be upset by the glitches on these outputs. But that occurs only when you have an output combinatorially dependent on two or more synchronous outputs that are changing on the same clock edge, and it is easily avoided by Gray-coding of the relevant internal state. Rule (2) is commonsense and says that you can't run the system faster than it is capable of going. But rule (1) is of a rather different kind: note that it is independent of the cycle time Tcyc! Rule (1) is the synchronous tyranny: it leads us to designing miraculous clock distribution arrangements so that Tskew(max) is minimised; and it leads to IC designers doing amazing things inside flipflops to make Thold negative if possible, because everyone is always fighting to make Tpd and Tco as SMALL as possible in order to allow faster clock speeds (see (2)). Note that Tpd and Tco can never be negative, by causality; but Thold can easily be negative if a delay path is introduced on the input signal within the flop (although this trick has a corresponding adverse effect on Tsu). [ End of lecture, start of personal opinion ] It's the existence of this synchronous tyranny that leads me to believe that fully synchronous design is ultimately a blind alley. It's by far the best we have right now, but that's only because the tools and techniques for proper asynchronous design are not yet fully developed into the mainstream. As I said at the start, just my $0.02. Jonathan BromleyArticle: 14484
Phil Hays wrote: > Austin Franklin wrote: > > > Personally, that is how I compare parts...since it is difficult to > > establish comparative parameters between two different vendors, I just look > > for comparably priced parts that the design will work in....and choose the > > cheaper part... It is silly to take a design that can work in a $14 part, > > and implement it in a $45 part...unless you REALLY need the room for future > > upgrades...or you really insist on using an HDL ;-) > > Total cost is a key metric, not cost per part. As an example, suppose > you are building 30 boards (total, forever, that's the whole market) > with 4 FPGAs each. The difference between the $45 parts and the $14 > parts is less than $1000. How many hours do you work for $1000? How > many hours would it take you to port this simple design to: Xilinx > Spartan? Or Gatefield? Or for real speed and/or minimum cost per part, > a gate array? i've done designs and moved them between actel, q-logic, gatefield, and gate arrays. by making symbols filled in with the lower-level, technology-specific primitives, it's relatively straightforward. of course, it's not optimal for a technology, and more work needs to be focused on the critical paths. you may even wish to re-optimize when switching between families from a particular vendor then again, from the output that i've seen from synthesizers, the human can usually do a far better job (where size doesn't make it impractical, there's limits to the size of a karnaugh map i'll do:) without very much trouble. if the design fits speedwise and spacewise into an available part, for a lot of situations i would agree that the hdl is faster, but not in all cases, as we can see below ... another thing that i have found is that different synthesizers do better and worse with different types of logic. so if you wish to push a technology, it frequently pays (pun intended) to have several synthesizers on hand for different sections of the design. no offense to the cae vendors out there, but one schematic package is a lot cheaper then buying, maintaining, and training on multiple tools. another example is the size of a design. for certain synthesizers who claim great speed in synthesis and technology mapping, they are frequently very fast as compared to older, slower synthesizers. for small designs. for large designs, i've seen the fast and nimble synthesizers break down and take many times longer and produce designs that are an order of magnitude larger than the normally slower synthesizer. ======================================================== > Suppose you needed to make a RAD-hard variant? How long would it take > to convert from a SRAM based FPGA to a antifuse based FPGA like for > example, Actel? It took me about 71 seconds to have a fair idea as to > what sort of speed this design would run in an a3265dx. Is ~25 MHz good > enough? Or should I spend some time looking at other parts (like say a > a1225xl)? Or doing some physical VHDL to improve the critical path? Is > there a lot to be gained by floorplanning this design? this is a good example as two things are changing; 1) the technology and 2) the application (rad-hard). which is easier and better? 1. just as a side point, i would say that the a3265dx and the a1225xl are poor choices for a rad-hard application. 2. commercial hdl tools tend to naturally choose flip-flops that are "rad soft" in the XL and DX technologies. so, you need to fuss with the tool some, which has become easier over the last year, to get the tool to specify either "c-mod" flip-flops for rad-tolerant applications or perhaps a tmr-triplet + voter configuration for harder applications. of course, these flip-flops are slower and larger than the flip-flops normally chosen by the synthesizer. and structures like ripple counters don't work well with tmr if your synthesizer just substitutes tmr-based f-f's for rad-soft ones; in this case, a bit different architecture is needed, which i haven't seen any synthesizers implement yet. but it's straightforward to implement with schematics. complicating matters with current software is getting the tool to infer flip-flops with differing levels of radiation hardness in the same design without going to structural vhdl. for example, some data registers may be non-critical and can take smaller, faster flip-flops while control sections may need to be fully radiation-hardened. this may result in more fussing with the code, perhaps repartitioning it into several smaller modules, which can be awkward. or perhaps synthesizer specific attributes. with schematics, one can just toss down the type of flip-flops that is wanted in each situation, leaving the design partitioning in its natural state. we have spent a bit of time [a few days] making up flip-flops that are ready to drop on the schematic with the same symbol but having different radiation characteristics. 3. don h., in a previous post, mentioned that the synthesizer replicated logic. this has been one of the weaknesses of commercial hdl tools and can be a serious issue for hi-rel/rad-hard applications, as two flip-flops, logically identical, may not physically have the same value as a result of radiation. i have seen cases where the cae tool, for example, replaced one flip-flop+inverter with two flip-flops, one having a true output the other having a complemented one. hopefully the next-state logic will eventually recover into a good state. however, in the case mentioned above, it was possible that two power fets were turned on (that's a longer story and gets us into the designer having used this same flip-flop asynchronously) with the result being quite a bit of current in the motor (and fuses did pop). so, with the hdl, you have to keep your eyes open for when the tools want to replicate logic and perhaps convince it not to do that. like in 2), above, controlling logic replication for a particular application is easy for a human to decide with a schematic; more awkward to control through a hdl. 4. lockout states are often, well, bad for this sort of application. using a schematic for a sequencer, which is frequently a pain, it's straightforward to ensure that there are no problems. if the cae tool uses a one-hot encoding to synthesize the state machine, for example, which does not have illegal state detection in it (and most synthesizer do not do that), you have a poor circuit for a radiation environment. then again, even if you use binary encoding (and make sure that the cae tool doesn't over-ride your selection because it knows better), and the number of your states is not exactly a power of 2, then you have to worry about the logic that is generated if you happen, as a result of radiation, to enter an unspecified state. vhdl's "others" clause doesn't help you here. one thing to do is to specify the number of states to be exactly a power of 2. then you must go in and make sure that the optimizer did notArticle: 14485
> (that's what the > little EEPROM on the modules is for). What little EEPROM? There are 'PD' pins on the 72 pin interface that, if used, give the size and speed of the SIMMs. There is no EEPROM on any of the 72 pin SIMMs I have... > NT will cry foul if it encounters this situation, > whereas Win95 will live with whatever parameters (hopefully > conservative) have been set by the BIOS. Well, NT actually crashes. That is not really crying 'foul', is it? AustinArticle: 14486
> Yes Austin but how? I know you are an experienced h/w man; you must be > asking yourself the same question :) Yes, I agree completely...I haven't researched the answer, because replacing the memory in the systems that have problems cures the problem.... I doubt NT changes BIOS or chip set parameters....it would have to know about every BIOS and chip set made, and to be made....and that just won't work. I think it actually uses the memory, that W95 just doesn't... A good question is, does Linux have the same issue? I'll do a DejaNews search, and post a question in a Linux news group... AustinArticle: 14487
I think you missed the boat here.. :-) I believe what Lim Sung-taek was referring to is server based licensing where a network server dishes out licenses upon request. This allows software to be installed on as many machines as desired, but only allows as many copies to run at once as the user has licenses for. Since he has the license locked to the NT server, that server must be running license manager software and have the license.dat file. Each client pc has an environment variable indicating that the license is served over the network, usually LM_LICENSE_FILE=_some_id_number_@_the_name_of_the_server We use it extensively here in our EDA Design Center. That is as much as I know about it, perhaps someone else can fill in more details on the server side. Also Lim Sung-taek may want to try contacting Xilinx Customer Support. Ray Andraka wrote: > > 1.4 used the ethernet address or c drive serial in place of a dongle. To > install it on multiple machines you either need unique license files for > each machine, or you need to make all the machine IDs the same. If your > key were the c drive serial number, you could get into Norton or similar to > alter the c drive serial numbers so they all match. Where your key is the > ethernet tag, you are stuck using it only on the machine with the matching > tag unless you can get an update license file from Xilinx. > <snip> > Lim Sung-taek wrote: > > > Hello, I'm installing Xilinx F1.4 to several PCs. And my newly updated > > license.dat indicates an ethernet card number of an NT server. I think > > that > > I should install so-called 'license server' but I have no information > > about > > it. I can't even figure out what should I start with. Can anyone advice > > me what to do or where can I get the related information? > > Thank you for reading this. Brian C. Boorman Harris RF Communications Rochester, NY 14610 XYZ.bboorman@harris.com <Remove the XYZ. for valid address>Article: 14488
Hello, I'm looking for the SPWM controller VHDL/Verilog/ABEL model. Does anyone have this model ? Thanks in advance. B.FangArticle: 14489
Jamie Lokier wrote:
>
> Jonathan Bromley writes:
> > All I meant was that it is sometimes handy to be able to express
> > certain types of logic as a sequence of intermediate calculations
> > even though the result will NOT be pipelined.
>
> `shared expr' gets close to what you want. I.e.:
> shared expr value1 = f1 (value);
> shared expr value2 = f2 (value);
> shared expr value3 = f3 (value1, value2);
> etc. All combinational.
Thanks, I'll look it up. Tho' it's not quite what I meant. I'll
post some examples in due course.
> > what happens when you communicate over a Handel-C channel? For the
> > three different scenarios: sender gets there first, target gets there
> > first, both arrive in the same clock cycle. This is something that
> > is rather skated-over in the published documentation.
>
> 1. Sender waits until a target is ready. Goto 3.
> 2. Target waits until a sender is ready. Goto 3.
> 3. Expression on sender side is assigned to variable on target side.
> Takes 1 cycle, as all assignments.
>
> Easy :-)
Indeed. Does the '!' cost one cycle for the sender, the same cycle as
the target uses to action its '?' ?
> Well I know nobody used `prialt' because I found tons of bugs a few
> months ago :-) (All fixed now).
which just goes to show that I _didn't_ use it; but then again, I
already came clean about that :-)
> prialt makes perfect sense and there's nothing deep really. But there
> are some really useful tricks you can pull. E.g., this pipeline does
> not work if the send blocks (spot the bug):
>
> while (1)
> par {
> input ? var1;
> var2 = var1 * 10; // Some misc. calculation step 1.
> var3 = var2 * var2; // Step 2.
> output ! var3 - 1; // Step 3.
> }
(for occam virgins, and for JL to check I understood: a par doesn't
complete until _all_ its components complete, so the 'output !' blocking
will sieze up the entire pipeline)
> But this pipeline does work all the time (assuming no typos). The logic
> is small too, despite the code size. Note: code does not normally have
> to look like this. Good use of macros etc...
<snip complicated-looking thing>
> Enjoy, <ahem>
Enjoyed as invited.
(1) I hadn't read the manual carefully enough, and didn't know
you could 'alt' on a send in Handel-C; I and many other occam users
would have given many pints of beer for that....
(2) it's a nice 1-place FIFO, elegantly done, but it still suffers
from overruns just like your FIFO-less pipeline: only it behaves
somewhat differently, swallowing and losing input data rather than
blocking it, and the existence of the 1-place buffer makes the
overrun much less likely of course.
I still think we're about due for a comp.lang.handelc NG. Are you
listening, Embedded Solutions? If so, how about lobbying for it?
Jonathan Bromley
Article: 14490Austin Franklin wrote in message <01be4df3$71c96bd0$3fab15d1@drt1>... >> (that's what the >> little EEPROM on the modules is for). > >What little EEPROM? There are 'PD' pins on the 72 pin interface that, if >used, give the size and speed of the SIMMs. There is no EEPROM on any of >the 72 pin SIMMs I have... > >> NT will cry foul if it encounters this situation, >> whereas Win95 will live with whatever parameters (hopefully >> conservative) have been set by the BIOS. > >Well, NT actually crashes. That is not really crying 'foul', is it? Presence detect on 72 pin modules is not used consistently, most BIOSes use a trial and error method to detect memory type. EEPROM is found on most SDRAM DIMM modules. I doubt that NT goes in and fiddles with the EEPROM - this is highly specific to the system board / chipset, and not supported by the BIOS. It is more likely that NT just "thrashes" the hell out of the DRAMs, and exposes weaknesses more quickly. -------------------------------------------------------------------- Pascal Dornier pdornier@pcengines.com http://www.pcengines.com Your Spec + PC Engines = Custom Embedded PC Hardware --------------------------------------------------------------------Article: 14491
This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BE4E08.4B317CC3 Content-Type: text/plain; charset="koi8-r" My guess is that NT produces much more intensity of memory (and other PC resources) references, than any other operating system. It has rather large kernel, and rather large interrupt latency - which means a lot of DIFFERENT instructions executed on every clock tick, and a lot of memory locations interrogated. Some interesting observation: when I work on my home computer in WinNT, one of TV channels loses colour signal! When I load MS DOS, everything is OK. -----Original Message----- From: Austin Franklin [mailto:aus3tin@darkroom.com] Posted At: Monday, February 01, 1999 6:00 PM Posted To: comp.arch.fpga Conversation: Off topic DRAM/SIMM question.... Subject: Re: Off topic DRAM/SIMM question.... > (that's what the > little EEPROM on the modules is for). What little EEPROM? There are 'PD' pins on the 72 pin interface that, if used, give the size and speed of the SIMMs. There is no EEPROM on any of the 72 pin SIMMs I have... > NT will cry foul if it encounters this situation, > whereas Win95 will live with whatever parameters (hopefully > conservative) have been set by the BIOS. Well, NT actually crashes. That is not really crying 'foul', is it? Austin ------_=_NextPart_001_01BE4E08.4B317CC3 Content-Type: text/html; charset="koi8-r" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <HTML> <HEAD> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; = charset=3Dkoi8-r"> <META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version = 5.5.2448.0"> <TITLE>NT sensitivity to PC hardware errors</TITLE> </HEAD> <BODY> <P><FONT SIZE=3D2 FACE=3D"Arial">My guess is that NT produces much more = intensity of memory (and other PC resources) references, than any other = operating system. It has rather large kernel, and rather large = interrupt latency - which means a lot of DIFFERENT instructions = executed on every clock tick, and a lot of memory locations = interrogated.</FONT></P> <P><FONT SIZE=3D2 FACE=3D"Arial">Some interesting observation: when I = work on my home computer in WinNT, one of TV channels loses colour = signal! When I load MS DOS, everything is OK.</FONT></P> <UL> <P><A NAME=3D"_MailData"><FONT SIZE=3D2 FACE=3D"Arial">-----Original = Message-----</FONT></A> <BR><B><FONT SIZE=3D2 FACE=3D"Arial">From: Austin Franklin = [<A = HREF=3D"mailto:aus3tin@darkroom.com">mailto:aus3tin@darkroom.com</A>]</F= ONT></B> <BR><B><FONT SIZE=3D2 FACE=3D"Arial">Posted = At:</FONT></B> <FONT SIZE=3D2 = FACE=3D"Arial">Monday, February 01, 1999 6:00 PM</FONT> <BR><B><FONT SIZE=3D2 FACE=3D"Arial">Posted = To:</FONT></B> <FONT SIZE=3D2 = FACE=3D"Arial">comp.arch.fpga</FONT> <BR><B><FONT SIZE=3D2 = FACE=3D"Arial">Conversation: </FONT></B> <FONT SIZE=3D2 = FACE=3D"Arial">Off topic DRAM/SIMM question....</FONT> <BR><B><FONT SIZE=3D2 = FACE=3D"Arial">Subject: </FONT>= </B> <FONT SIZE=3D2 FACE=3D"Arial">Re: Off topic DRAM/SIMM = question....</FONT> </P> <P><FONT SIZE=3D2 FACE=3D"Arial">> (that's what the</FONT> <BR><FONT SIZE=3D2 FACE=3D"Arial">> little EEPROM on the modules is = for).</FONT> </P> <P><FONT SIZE=3D2 FACE=3D"Arial">What little EEPROM? There are = 'PD' pins on the 72 pin interface that, if</FONT> <BR><FONT SIZE=3D2 FACE=3D"Arial">used, give the size and speed of the = SIMMs. There is no EEPROM on any of</FONT> <BR><FONT SIZE=3D2 FACE=3D"Arial">the 72 pin SIMMs I have...</FONT> </P> <P><FONT SIZE=3D2 FACE=3D"Arial">> NT will cry foul if it encounters = this situation,</FONT> <BR><FONT SIZE=3D2 FACE=3D"Arial">> whereas Win95 will live with = whatever parameters (hopefully</FONT> <BR><FONT SIZE=3D2 FACE=3D"Arial">> conservative) have been set by = the BIOS.</FONT> </P> <P><FONT SIZE=3D2 FACE=3D"Arial">Well, NT actually crashes. That = is not really crying 'foul', is it?</FONT> </P> <P><FONT SIZE=3D2 FACE=3D"Arial">Austin</FONT> </P> </UL> </BODY> </HTML> ------_=_NextPart_001_01BE4E08.4B317CC3--Article: 14492
Jonathan Bromley wrote: > If you have a classically-designed synchronous system of the Mealy type > (i.e. with no output combinatorially dependent on any asynchronous input) [snip] Just to be picky. You just described a Moore FSM. A Mealy FSM is characterized by the mere fact that the output is directly dependent on the input as well as current state, while the Moore machine output is only depending on current state. [snip a lot of usefull insight into synchronous design] >It's the existence of this synchronous tyranny that leads me to >believe that fully synchronous design is ultimately a blind alley. >It's by far the best we have right now, but that's only because the >tools and techniques for proper asynchronous design are not yet >fully developed into the mainstream. This statement is a little like the statements that sounds like "The only reason we don't use analog electronics is that the tools are not developed enough". Making a fully asynchronous (selfclocking) design may be possible, but changing functionality in such a beast will be a pain, so will taking care of tolerances - although small - in the silicon. That might be the worst problem, and it might be unsolveable, no matter how good the tools will be. A mix of the two is employed today, but in many applications it is not worth the cost of extra development time. Controlling clock skew can be a nightmare, but at least it is a smaller nigthmare than keeping track of hazard in a true asynchronous system. -- Brian Pedersen, DSP Student _/ _/_/_/ _/_/_/ _/ Applied Signal Processing and Implementation _/_/ _/ _/ _/ _/ Department of Communication Technology _/ _/ _/_/_/ _/_/_/ _/ Aalborg University, Denmark _/_/_/_/ _/ _/ _/ URL: http://www.danbbs.dk/~kibria/brian/ _/ _/ _/_/_/ _/ _/Article: 14493
Sung-taek, Is your current license a 'floating' license or a 'node-locked' license? A node-locked license allows only one PC to use the tool. A floating license allows multiple PCs (up to a limit which is set in license.dat file) on a network to access the tool. How do you figure out which one you have? A typical node-locked license file has INCREMENT and PACKAGE sections where as a typical floating license has SERVER and DAEMON sections in addition to INCREMENT and PACKAGE sections. If you have a node-locked license: upgrade to floating license to run f1.4 on multiple PCs. If you have a floating license: put license.dat on your NT server, set set LM_LICENSE_FILE = %path_to_license.dat%; (NT server) set LM_LICENSE_FILE = port_number@name_of_NT_server; (all other PCs) port_number is indicated at the end of SERVER line (default is 2200) in license.dat then, run license manager from your NT server. For more info, refer to Foundation Install and Release Documentation that comes with your F1.4 s/w package. Chapger 6 explains you how to set up security in detail. Bennet An Xilinx Applications Lim Sung-taek wrote: > Hello, I'm installing Xilinx F1.4 to several PCs. And my newly updated > license.dat indicates an ethernet card number of an NT server. I think > that > I should install so-called 'license server' but I have no information > about > it. I can't even figure out what should I start with. Can anyone advice > me what to do or where can I get the related information? > Thank you for reading this. > > Sung-taek Lim (totohero@poppy.snu.ac.kr)Article: 14494
I think a good example is the Boulder Creek Engineering logic analyzer, they use a cheap 3xxx series Xilinx part, it gets configured to do a high speed capture of the circuit data, then gets reconfigured as a serial interface that dumps the capured data. Never do both functions live in the FPGA at the same time. Very cheap, very clever, very elegant! Dave Fuhriman wrote in message <36B2314E.B26485BE@email.byu.edu>... >Hi, I've been researching reconfigurable computing for an article, and I >have found some good explanations of how it works. What I lack is a >solid analogy to give to other people to help them understand how it >works and how it's an improvement over what we had before. Something >like general purpose computing is like a Yugo, and reconfigurable >computing like a 'Vette -- something that explains why it's better. Has >anyone heard such an analogy that explains this concept to people like >me who use computers but don't know how to make them? Any help would be >appreciated. Thanks! >Article: 14495
Just a wild guess, but isn't FPGA Express from Synopsys Try http://www.synopsys.com bruce Samer EL HAJJ wrote in message <36B57BCA.2D43F065@dotcom.fr>... >Hi to all!! >I installed an evaluation version of FPGA Express, but It ask me for a >key... >Viewlogic Support didn't reply!!! >Do someone know how to resolve this problem???? > >Thanks in advance! > >mailto:samer1@hotmail.com >Article: 14496
Duck Foot wrote: > > Duck Foot wrote: > > > Textbooks tell how to get rid of static hazards inherent in a sum of > > products network. They say the hazard comes from transitions between > > neighboring product terms, and can be eliminated by adding redundant > > implicants. > > Do we also call the transitions between two apart product terms, > > e.g. diagonally positioned ones, hazard? How can I eliminate glitches > > born of this kind of network? - In this case circling 0's to eliminate > > 0-hazard also results in diagonal configuration. > > I use sychronous logic, and most of the glitches were found to be > combinations of synchronous signals. I could eliminate some of them by > adding redundant implications, but I still couldn't when the implicants were > > not adjacent. > I wonder why most of you say glitches doesn't matter in synchronous > logic. In my humble view, it matters when it occurs on the edge of clock. > What do you think? Glitches won't matter in synchronous logic, because all of the inputs change just after the clock edge. If you have met the setup time of the next flip flop, then you won't have any glitches on the next clock edge. That is the primary advantage of synchronous design. Just by measuring the delays between flip flops, you can tell if a given design will have timing problems and the design will never have race conditions or other glitches regardless of how you wire the logic. This type of synchronous design will also allow you to perform much faster simulations, since you can ignore the timing aspects and just simulate the functionallity of the logic. This is called "unit delay" simulation. -- Rick Collins redsp@XYusa.net remove the XY to email me.Article: 14497
Pascal Dornier wrote in message <36b5e06e$0$16679@nntp1.ba.best.com>... >Austin Franklin wrote in message <01be4df3$71c96bd0$3fab15d1@drt1>... >>> (that's what the >>> little EEPROM on the modules is for). >> >>What little EEPROM? There are 'PD' pins on the 72 pin interface that, if >>used, give the size and speed of the SIMMs. There is no EEPROM on any of >>the 72 pin SIMMs I have... >> >>> NT will cry foul if it encounters this situation, >>> whereas Win95 will live with whatever parameters (hopefully >>> conservative) have been set by the BIOS. >> >>Well, NT actually crashes. That is not really crying 'foul', is it? > > >Presence detect on 72 pin modules is not used consistently, most BIOSes use >a trial and error method to detect memory type. > >EEPROM is found on most SDRAM DIMM modules. > >I doubt that NT goes in and fiddles with the EEPROM - this is highly >specific to the system board / chipset, and not supported by the BIOS. It is >more likely that NT just "thrashes" the hell out of the DRAMs, and exposes >weaknesses more quickly. There is no EEPROM for SIMMs. EEPROMs are on DIMMs.Article: 14498
> A > good question is, does Linux have the same issue? I'll do a DejaNews > search, and post a question in a Linux news group... It appears Linux has the same issue with memory as NT, at least from what I saw in my searching... AustinArticle: 14499
Hi, Would anyone tell me how to write a clock multiplier in VHDL? BC
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