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
Jonathan Bromley wrote: > Duck 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. Sorry to say I still don't understand. Only in the caseTco(min) >= Thold(max) and Tpd(min) =< Tskew(max), the next inequality will hold Tco(min) >= Tco(min) + Tpd(min) - Tskew(max) >= Thold(max), and the glitch actually doesn't affect hold time rule. Otherwise the glitch will be within hold time interval, therefore the new input is not really HOLD. Did you already assume the above facts, or am I still missing something?Article: 14501
Jonathan Bromley writes:
> Indeed. Does the '!' cost one cycle for the sender, the same cycle as
> the target uses to action its '?' ?
Yes.
>> 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)
It's beyond standard Occam. The bug isn't anything to do with seizing
up -- that behaviour is fine and good if the output channel isn't ready.
The bug is that if the output blocks, `var3' that it is outputting is
overwritten by the assignment on the previous line, so eventually the
wrong value is output. The assignment takes place _during the same
cycle_ as the first cycle of the output attempt.
The above code works fine if you remove the `par' and reverse the order
of the channel/assignment statements. But then, it runs 4 times slower.
It also works fine if you place `par' around the first three statements,
and put the send before the `par'. Then it only runs 2 times slower (2
cycles per datum instead of 1). Example is below.
This is what I mean by the Handel-C timing rules allowing for succint
code. A lot of things in both code examples are defined to happen
during the same clock cycle -- something which isn't possible in Occam.
It allows for some powerful and compact pipeline code.
>> 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>
> (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.
No overruns, unless I made a mistake. 1-place buffer is there
_specifically_ to prevent overrun problems, and it works. It doesn't
swallow input data -- it's a proper blocking pipeline. Did you miss the
inner do..while loop?
You don't even need the buffer if you're prepared to take an extra cycle
per datum. I only use `prialt' when I need a really fast pipeline.
[ And IMO, this is the elegant, if suboptimal version. It is the
fastest of the smallest (measured in cycles & flip-flops):
while (1) {
output ! var3 - 1; // Step 3.
par {
input ? var1;
var2 = var1 * 10; // Some misc. calculation step 1.
var3 = var2 * var2; // Step 2.
}
}
]
> 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?
Given that you and I are the only people having this discussion, I think
the NG could be a bit premature :-)
Still, votes from people watching would be welcome...
-- Jamie
Article: 14502Jamie Lokier <spamfilter.jan1999@tantalophile.demon.co.uk> writes: [ snip ] > the NG could be a bit premature :-) Indeed! There is also the danger that other, more VHDL-ish, people might be tempted to look away from Handel-C if the discussion about it only happens in an esoteric newsgroup. I'd rather see more about Handel-C in other groups as well (such as comp.cad.synthesis etc.) By the way: Has anybody thought of using Handel-C in conjunction with system-level simulators such as COSSAP or SPW? Yes, I know this means multorate and everything but it would be extremely useful. > > Still, votes from people watching would be welcome... > > -- Jamie Don't make Handel-C esoteric, it should be seen by everybody :) Cheers Matthias -- Matthias Sauer Siemens AG, Semiconductor Group Phone: +49-89-63684921 HL CR CE Fax: +49-89-63681066 PO Box 801760 email: Matthias.Sauer@siemens-scg.com D-81617 Munich, GermanyArticle: 14503
Bruce Nepple wrote in message ... >Just a wild guess, but isn't FPGA Express from Synopsys > Yes, but I have heard that they don't sell it themselves, it only comes bundled with other packages. >>Viewlogic Support didn't reply!!! >>Do someone know how to resolve this problem???? >> We have FPGA Express as part of Workview Office, hence Samer talking about Viewlogic. JimArticle: 14504
Brian Dam Pedersen wrote: > > 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. Whoops. Got it the wrong way round, sorry. I never had a good memory for names :-) At least I had the wit to define what I meant as well! > >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. Of course you are right; but all your points would be answered by a synthesis methodology that could develop a truly self-timed logic system (so that manufacturing tolerances *don't* cause trouble) from a suitable functional description. AFAIK the basic theory needed to underpin such a methodology is already in place; I think you will find that, at least in principle, your "worst problem" is *not* insoluble. Self-timed logic gurus, where are you now? Jonathan BromleyArticle: 14505
Duck Foot wrote: > > Jonathan Bromley wrote: <big snip> > > > > 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. > > Sorry to say I still don't understand. Only in the case > Tco(min) >= Thold(max) and > Tpd(min) =< Tskew(max), > > the next inequality will hold > Tco(min) >= Tco(min) + Tpd(min) - Tskew(max) >= Thold(max), > > and the glitch actually doesn't affect hold time rule. > Otherwise the glitch will be within hold time interval, > therefore the new input is not really HOLD. You've lost me. To take your last line of algebra in two parts Tco(min) >= Tco(min) + Tpd(min) - Tskew(max) is just the same as Tpd(min) >= Tskew(max) (by subtracting Tco(min) from both sides) contradicting your earlier hypothesis. I think you are assuming that what matters is Tco(min) >= Thold(max) --(3) which is not the whole story. Consider two flops. FF1 receives a clock at t=0; its output changes at Tco. This output provides a new input to FF2 at Tco+Tpd. But FF2 is clocked Tskew later than FF1, so the time from FF2's clock to the "glitchy" change on its input is Tco+Tpd-Tskew. This time must be larger than FF2's hold time: hence my relationship (1), where I've filled-in the worst case values for everything. So my (1) is a much stronger condition than your (3), because it takes into account the clock skew (note that Tpd(min) is almost invariably zero because some of the inter-flop logic is just wire). You can't get a glitch any earlier than the earliest possible output change, Tco(min) after the clock; to guarantee successful operation of the state machine you must meet my condition (1); by so doing, you have also effectively guaranteed that any output glitches will not affect the state machine's synchronous operation. Sorry if this wasn't clear. BTW if my two criteria (1) and (2) are applied globally to the whole state machine they will be unduly pessimistic because the worst-case left-hand-side of the equality will probably not occur on the same flop as the worst-case right-hand-side. But they provide an easy way of making things 100% safe. Jonathan BromleyArticle: 14506
As some/many of you may know, Minc/Synario closed their doors and had turn over their assets to be liquidated (see EETimes article, dated around Dec 18, 1998). I am trying to determine what people/other organizations are doing to support the programming of PLDs (and possibly CPLDs) now that the company that supplied ABEL has shut down. It appears that Logical Devices may be the only "non-biased" vendor out their, with their CUPL system that targets multiple PLD vendor devices. Any thoughts/insights on this matter are welcomed. -Bob p.s. I have not received any inputs from our AVNET reps regarding what Xilinx's plans are regarding what Xilinx purchased from the liquidator.Article: 14507
Gerald Shin wrote:
> 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,
> Gerald
Here are some links to pages that may have what you are looking
for.Happy Hunting
http://pages.tico.com/chase/hdl.html
http://www.optimagic.com/
--
~~~ "It's not a BUG,
/o o\ / it's how I make my living"
( > )
\ ~ / Jerry English
_]*[_ FOE of Script Lords
Article: 14508Go to http://www.xilinx.com/products/software/mincsynario/ms-infosite.htm to get the official word on how Xilinx will handle things. Randy On 2 Feb 1999 13:26:20 GMT, rjmyers@ti.com (Robert Myers) wrote: >As some/many of you may know, Minc/Synario closed their >doors and had turn over their assets to be liquidated >(see EETimes article, dated around Dec 18, 1998). > >I am trying to determine what people/other organizations >are doing to support the programming of PLDs (and possibly >CPLDs) now that the company that supplied ABEL has shut down. >It appears that Logical Devices may be the only "non-biased" >vendor out their, with their CUPL system that targets >multiple PLD vendor devices. > >Any thoughts/insights on this matter are welcomed. > >-Bob > >p.s. I have not received any inputs from our AVNET reps >regarding what Xilinx's plans are regarding what Xilinx >purchased from the liquidator. > >Article: 14509
New York, Syracuse; Senior Engineer; Hardware, Imaging, Video, FPGA -Senior Engineer -Syracuse, NY -Salaried, Full-Time, Direct Employee, Solid Benefits (Relocation Assistance Available) Must have: signal processing, algorithms, FPGAs, and exposure to...video, or imaging &/or sensor systems applications. Client using Altera, ViewLogic and Spice CAE/CAD tools. 60-70% design/detailed design; 30-40% systems level work. Please refer to JO# 582RJS in your response. lisa_crawford@cmagroup.com Lisa Crawford Sr. Researcher & Associate Recruiter ljc@cmagroup.com IT & Software Solutions Team Career Marketing Associates http://www.cmagroup.com/IT.htmlArticle: 14510
Jamie Lokier wrote:
> >> (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.
> >> }
>
> It's beyond standard Occam. The bug isn't anything to do with seizing
> up -- that behaviour is fine and good if the output channel isn't ready.
> The bug is that if the output blocks, `var3' that it is outputting is
> overwritten by the assignment on the previous line, so eventually the
> wrong value is output. The assignment takes place _during the same
> cycle_ as the first cycle of the output attempt.
OK, I see what you mean.
<re. a different pipeline example>
> > (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.
>
> No overruns, unless I made a mistake. 1-place buffer is there
> _specifically_ to prevent overrun problems, and it works. It doesn't
> swallow input data -- it's a proper blocking pipeline. Did you miss the
> inner do..while loop?
Just being careless I think. Thanks for the clarification.
You have nicely made the point that, as with any new tool, one gets
to understand its subtler ramifications only after using it for
serious work for a while. Time for me to go and get in some practice.
Meanwhile, some folk out there should be eating their hearts out
when they see how much you can do with even simple use of
Handel-C channels.
Jonathan Bromley
Article: 14511Sounds like a Binary Rate Multiplier. >It can only generate a pulse train that _ON AVERAGE_ is a multiple of the signal >input frequency. It cannot produce the steady locked frequency an analogue PLL >can. -- 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: 14512
NT does thrash the hell out of the hard disk (Microsoft's wonderful memory "management") but how can it "thrash" a RAM? I don't know of any way to thrash a RAM. Either the interface is marginal (in which case you will get many immediate problems) or not. >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. -- 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: 14513
I think this is the *only* possible answer, together with win95 probably being less sensitive to wrong opcodes being executed ;) >I think it actually uses the memory, that W95 just doesn't... -- 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: 14514
Be VERY careful with CUPL. About 2 years ago we sent back version 4.7 as being "unfit for purpose" and under English law eventually got our money back. At that time there was no support for hierarchal design and only limited macro functions. To produce a counter you had two choices - hand write the equations yourself, or, using a for-generate construct, construct a state machine with an explicit state for every counter value. The second method would not allow counters longer than 10 bits. The device independant compilation was not great, the documentation poor and the supplied fitters mostly those available for free from vendor's websites. Some months after we settled on Altera, I noticed on their web site that CUPL were charging $300 USD to upgrade to the 32 bit version, even to those who had purchased "Keep Current Maintenance". I have ranted on about this at length before, look up deja news under "cupl opinions anyone" I think the thread was called. Of course, their version 5.0 might be completly wonderful, but their web site does not give me confidence that it is. In short you get what you pay for. CUPL is the cheapest. In article <796uds$cb3@news.rsc.raytheon.com> rjmyers@ti.com writes: > As some/many of you may know, Minc/Synario closed their > doors and had turn over their assets to be liquidated > (see EETimes article, dated around Dec 18, 1998). > > I am trying to determine what people/other organizations > are doing to support the programming of PLDs (and possibly > CPLDs) now that the company that supplied ABEL has shut down. > It appears that Logical Devices may be the only "non-biased" > vendor out their, with their CUPL system that targets > multiple PLD vendor devices. > > Any thoughts/insights on this matter are welcomed. > > -Bob > -- Steve Dewey Steve@s-deweynospam.demon.co.uk Too boring to have an interesting or witty .sig file.Article: 14515
Peter wrote: > > NT does thrash the hell out of the hard disk (Microsoft's wonderful > memory "management") but how can it "thrash" a RAM? I don't know of > any way to thrash a RAM. Either the interface is marginal (in which > case you will get many immediate problems) or not. > > >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. > > -- > Peter. > AFAIK NT will bypass the bios and do it's own disk access(you can for example access disks not detected in the bios), I have have not idea how, but could it be possible that it does something similar to RAM??? Because I've seen several maschines that have been running 95 for years with no more than the usual problems:), and when trying to install NT it can't even get through the installation without crashing, and often changing the RAM has solved the problem, sometimes just swapping the RAM modules will help makes you wonder :) --Lasse --___--_-_-_-____--_-_--__---_-_--__---_-_-_-__--_---- Lasse Langwadt Christensen, MSEE (to be in 1999) Aalborg University, Department of communication tech. Applied Signal Processing and Implementation (ASPI) http://www.kom.auc.dk/~fuz , mailto:langwadt@ieee.orgArticle: 14516
Let's get back to basics: A synchronous digital design can only generate output changes that are separated by n times the clock period ( or half period when clocking by either clock edge is possible). So if you use a 10 MHz clock, the output transitions can only be spaced integer multiples of 100 ns. ( or 50 ns as mentioned above ). So if you want to generate 30 MHz, ( 33.33333... ns period ) or any other frequency that does not have a ns-period ending in two zeros, the output cannot possibly be a pure frequency, but will only average the desired frequency, which means it has sidebands. The classical case is a phase accumulator that, if long enough, can generate an average output frequency with very fine resolution, down to the milliHz, but it it is still limited to output changes occurring as a result of the internal clock edge. If you can live with this, FPGAs offer a beautiful, fast and compact implementation. Hint, hint, end of commercial :-) An analog VCO does not have this limitation, but suffers of course from random phase noise and other problems that might be introduced by the generation and analog filtering of the VCO control voltage. Peter Alfke, Xilinx ApplicationsArticle: 14517
Lasse Langwadt Christensen wrote: > AFAIK NT will bypass the bios and do it's own disk access(you can for > example access disks not detected in the bios), I have have not idea > how, but could > it be possible that it does something similar to RAM??? Because I've > seen > several maschines that have been running 95 for years with no more than > the > usual problems:), and when trying to install NT it can't even get > through the > installation without crashing, and often changing the RAM has solved the > problem, sometimes just swapping the RAM modules will help Well. There is no direct software layer between RAM and the CPU (such as the BIOS with HDDs) but Win NT treats everything controllable by the BIOS settings as it's own property including RAM timing and cache strategy. This can mess up things pretty bad if the BIOS is set, so that things are running fine, and then NT gets the idea that tweaking a few timing parameters can optimize things. This optimization ends up blowing up the system. Newer (faster) RAM is usually the solution to a problem that shouldn't have been there in the first place (the MS "we know better" attitude). Win 95 is too stupid to make any assumptions about low level HW, and thus happily works with whatever settings are put in the BIOS - the Forrest Gump of OSs. OS/2 in its early versions did have the same problems, especially if the RAM timing was different in some modules (could happen in the good ol' days). Then OS/2 assumed that the fastest RAM was available in all modules leading to severe timing problems in some memory areas. Guess who initially designed OS/2 ? Completely off topic by the way.. -- Brian Pedersen, DSP Student _/ _/_/_/ _/_/_/ _/ Applied Signal Processing and Implementation _/_/ _/ _/ _/ _/ Department of Communication Technology _/ _/ _/_/_/ _/_/_/ _/ Aalborg University, Denmark _/_/_/_/ _/ _/ _/ URL: http://www.danbbs.dk/~kibria/brian/ _/ _/ _/_/_/ _/ _/Article: 14518
> NT gets the idea that tweaking a few timing parameters can optimize things. I do not believe NT goes out and changes any of the chip set timing for DRAM access. NT would have to have knowledge about EVERY chip set out there, and that just isn't the case. AustinArticle: 14519
"Austin Franklin" <aus3tin@darkroom.com> writes: >I just bought a 72pin standard PC SIMM. It claims to be 64M 5V 60ns EDO. >OK, that's all well and good, but it has 12 chips on it. If 72 pin SIMMs >have a 32 bit data path, how is 32 divisible by 12? I have a feeling this isn't what you have, but I have bought SIMMs that were sold as 4Mx32, but were actually 4Mx36. They are made by Siemens. I got the SIMM data sheet, and the chip data sheet. THe chips really are 4Mx3, and 12 of them make 4Mx36. It is likely enough easier to make 4Mx3 chips than 4Mx4. -- glenArticle: 14520
Austin Franklin wrote: > > > NT gets the idea that tweaking a few timing parameters can optimize > things. > > I do not believe NT goes out and changes any of the chip set timing for > DRAM access. NT would have to have knowledge about EVERY chip set out > there, and that just isn't the case. No. It just keeps the hands off the ones that it don't know. As far as I can see this is the only plausible explanation for NT (and OS/2) crashing where other OSs succeed. -- Brian Pedersen, DSP Student _/ _/_/_/ _/_/_/ _/ Applied Signal Processing and Implementation _/_/ _/ _/ _/ _/ Department of Communication Technology _/ _/ _/_/_/ _/_/_/ _/ Aalborg University, Denmark _/_/_/_/ _/ _/ _/ URL: http://www.danbbs.dk/~kibria/brian/ _/ _/ _/_/_/ _/ _/Article: 14521
In article <36B6F6EA.F19A0F58@brookes.ac.uk>, Jonathan Bromley <jsebromley@brookes.ac.uk> wrote: > >You've lost me. To take your last line of algebra in two parts > Tco(min) >= Tco(min) + Tpd(min) - Tskew(max) >is just the same as > Tpd(min) >= Tskew(max) (by subtracting Tco(min) from both sides) >contradicting your earlier hypothesis. > >I think you are assuming that what matters is > > Tco(min) >= Thold(max) --(3) > I dont follow your logic. Lets go through the steps: Tco(min) >= Tco(min)+Tpd(min)-Tskew(max) Then by substracting Tco from both sides we get: 0>=Tpd(min)-Tskew(max) Then Tskew goes to the left side and we get: Tskew(max) >= Tco(min) Which is the reverse of your inequality.Article: 14522
Samer EL HAJJ <samer@dotcom.fr> wrote in <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???? > You can get an evaluation license (for 14 days or so) from synopsys. Look at the download pages for FPGA express. > Thanks in advance! > Hope it helps > mailto:samer1@hotmail.com > Mats -- Matthias Brucke Fachbereich Informatik Entwurf Integrierter Schaltungen Universitaet Oldenburg Tel: 0441-798-2153 Fax: 0441-798-2145Article: 14523
Rita Madarassy wrote:
> I dont follow your logic.
A polite way of saying (correctly) that I was wrong.
> Lets go through the steps:
No, let's not, it's too embarrassing: two goofs in two successive
posts in the same thread. Inexcusable. That's the downside
of getting older :-(
I was trying to point out that Duck Foot's previous comment
was some way off beam - he'd introduced the irrelevant
requirement Tco>Thold which is just a special case of my
inequality (1) when Tpd=0, Tskew=0. But I added fog to
confusion by getting it wrong. Sorry!
for (i=0; i<100; i++)
printf("I must not hit SEND before proof-reading \n");
Jonathan Bromley
Article: 14524PLDApplications, Altera, Direct Insight, and Viewlogic are pleased to announce a one-off technical seminar entitled "IP Integration - A Practical Approach". Using a real example in which a PCI-core was successfully integrated in the design of a data-acquisition system, leading experts in the field will guide you through the challenges of successful sourcing, design-in, verification and implementation of IP. Where: Savill Court Hotel and Conference Centre, Egham, UK (M25 J13). When: Thursday March 4th, all day. Booking: Free, first-come, first served. See: www.edasource.com/ipseminar.html or www.plda.com -- David Pashley < --------------------------- < < < --- mailto:david@edasource.com | Direct Insight Ltd < < < < > Tel: +44 1280 700262 | | http://www.edasource.com < < < Fax: +44 1280 700577 | ------------------------------ < ---------------------------------
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