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
"B. Joshua Rosen" wrote: > The MV8000 could be done on a small Virtex part but not in a 4005, the > MV was a CISC machine the NOVA was am ultra simple RISC machine. The > original Nova should be able to fit easily in a 4005. If you look at the > Nova instruction set you will see that it requires no decoding and no > microcode. The ALC instruction, which is the only operation instruction, > has a pair of two bit fields for the register select, a two bit field > which controls the carry mux, a 3 bit field which controls the skip mux, > a two bit field which controls the shift mux, a bit which selects > arithmetic/logical, a bit for zero/register, and a couple of bits of the > operation. The load/store as I recall had only one addressing mode, base > + offset. There was also a Jump and a Jump and Link instruction, and a > couple of IO instructions and that was that. > It seems like the only architectural advance on this, until out-of-order, was the addition of pipelining to get the clock speed up. Or did the NOVA have that as well ?? PS I also loved the book & have been quoting that line down the years. If good lines were patentable you could have built your own custom commune on the proceeds.Article: 25426
Hi, I have a design for a device written using Renoir and ModelSim in VHDL. Initially it's targeted at a Xilinx Virtex. I need to generate an image of this VHDL in a form that is as flexible as VHDL (in terms of the ability to retarget) but is not in a human readable form so that it can't be reverse engineered. Any suggestions? Thanks Chris AndersonArticle: 25427
That was not the question. *When* does the high current draw happen. Is this as the Vdd ramps up, or is this after the chip is fully powered and starts the configuration? Supplying a high current after the supply is up is one thing. Suppling the high current while the supply is coming up is a different matter. Specifically, what is it that you are saying is *different* between the 4K series and the Virtex series??? Austin Lesea wrote: > > Rick, > > Virtex I parts require a 2A minimum current limited power supply if you > intend to start up at -40C. > > Austin > > rickman wrote: > > > Austin Lesea wrote: > > > > > > Henryk, > > > > > > The INIT holdoff warning applies to 4K only. It does not apply to > > > Virtex, and Virtex architecture derivatives. > > > > > > I am sorry for the confusion. > > > > > > In 4K, holding INIT and preventing clean out does not make the device > > > HOT -- it may be that the 4K device is in contention from the Vcc not > > > going down below a few hundred millivolts, and then the Vcc returns, > > > and the 4K device is in a partially configured state, and drawing > > > current. So the device is already HOT and getting hotter, and INIT > > > prevents the clean out. > > > ********************* This bit right here ******************************** > > > Again, Virtex, Virtex E, Spartan2 do not have this behavior. The ********************* This bit right here ******************************** This is the statement I am asking you to clarify. Tell us about the difference noted above. Perhaps I am not familiar with the INIT holdoff warning in the first place. My understanding was that pulling PRGM low started the clearing of the configuration memory. This proceeded until PRGM was released. Once complete, the INIT pin was released to indicate that configuration could procede. But if the INIT was held low externally, the FPGA would wait. How does this cause high current consumption? The configuration memory should have been cleared at this point and the supply current should be under control. What am I missing? > > > design is such that the means of contention that were caused by memory > > > contents which occurred in 4K do not exist in Virtex. > > > > Can you be a little more specific as to what behaviour you are talking > > about? The Virtex data sheet claims it needs up to 2 Amps of current for > > startup. So I assume that you are saying that the Virtex does not > > continue to draw heavy current when INIT is held low? Is that right? -- Rick Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. 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.comArticle: 25428
You are not totally correct Austin. If you want a square wave without a lot of jitter, then you do need the sine wave which can be filtered to produce a wave of just the fundamental. This is then compared to a fixed voltage to produce a square wave with no jitter. If you don't do this, you will have a time jitter equal to your master clock period as you noted. This is often not acceptable and the sine wave lookup, DAC and filter can be less circuitry than the VCXO, phase comparator and filter. In fact you can get the whole shebang in one chip less the filter. Austin Lesea wrote: > > Nestor, > > A DDFS (direct digital frequency synthesizer) is an adder/accumulator. > They have been around for perhaps 30 years now. I have used them for > years in FPGAs. The sine look up table is only used if you want a sine > wave. I have seen people use a sine look up table, a D/A, and then follow > that mess with a comparator -- TO GET A SQUARE WAVE! Think about it. The > MSB of the DDFS was already the signal they wanted! > > So, if you don't want a sine wave, don't add all that junk. > > The p-p jitter is the clock period used, and the Fout < 1/2 Fclock. > > I would use the highest frequency I could get away with. If you require > even less jitter, the output can be passed through a single simple VCXO > used in a PLL loop with an XOR phase detector and an external RC to remove > practically all of the jitter if the frequency output range is narrow > enough. > > Placing the DDFS in a locked loop, results in a complete digital locked > loop (Patented -- look it up, under my name). > > There are many nice parts out there that package the whole thing, and are > inexpensive, so you need to evaluate what it is going to be used for, and > decide if you want to build it in, or not. > > Also look at: > > http://www.xilinx.com/xcell/xl31/xl31_32.pdf > > for fractional synthesis,and other NCO's. > > Austin Lesea > > Nestor wrote: > > > Hi. > > > > Does anyone know any manufacturer who fabricates > > numerically-controlled crystal oscillators (NCXO), also known as > > digitally-controlled crystal oscillators (DCXO) which are suitable for > > digital phase-locked loop designs in VHDL and FPGAs? > > > > Although these blocks resemble a numerically-controlled oscillator > > (NCO), they differ in that the NCXO is not oversampled to generate the > > required output signal (an NCO needs to be oversampled by at least > > 8-times in order to have an acceptable low jitter output). Rather, a > > digital input word is fed to the NCXO and it synthesizes the required > > output frequency using a standard, low-cost crystal oscillator. The > > output is also a square wave, just like the standard crystal. In > > general, the NCXO has a narrow tuning range similar to a > > voltage-controlled crystal oscillator (VCXO), e.g. +/-150ppm relative > > to a frequency in the MHz range. > > > > The NCXO technology is fairly recent from what I understand, but > > allows one to replace a circuit composed of a digital-to-analog > > converter (DAC) and a VCXO by one chip that performs the exact same > > task will less design hassles. The DCXO is ideal for custom-made > > phase-locked loop (PLL) circuits using digital sections that can be > > implemented in VHDL and FPGAs. > > > > Since I haven't been able to find any NCXO manufacturers over the web, > > I am now looking to the knowledgeable engineers, designers and friends > > that frequent these newsgroups for some potential referrals and/or > > links. > > > > Thanks in advance for your help. > > > > Nestor -- Rick Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. 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.comArticle: 25429
It was a great line from a great era of computing. Who was the other supercomputer company? I worked at Star Technology for awhile and they called their array processors "supercomputers". "B. Joshua Rosen" wrote: > > That line was joke I love nanoseconds. After I left DG I went off to > another company, then in early to mid 80's I was at a supercomputer > startup that was composed mostly the same team as the MV8000 (went IPO, > rich for a month then then the stock went down the tubes). Since the > late 80's I've been consulting, mostly networking stuff these days. > > > rickman wrote: > > > > That is great! I have remembered and retold that line for years... > > > > What are you doing back? Did the commune close up? Or did they have an > > IPO? ;) > > > > "B. Joshua Rosen" wrote: > > > > > > Your right, I was. I'm the guy who said "I'm sick of nanoseconds, I'm > > > going off to a commune in Vermont where I'll deal with no period of time > > > shorter than a season". > > > > > > Josh > > > > > > Bob Perlman wrote: > > > > > > > > On Mon, 11 Sep 2000 02:02:05 +0200, "Michael Randelzhofer" > > > > <mrandelzhofer@compuserve.com> wrote: > > > > > > > > >Hi CPU-Freaks, > > > > > > > > > >When i hear about Data General, i always must recommend the book > > > > >"The soul of a new machine" from tracy kidder. > > > > > > > > > >It's an excellent story about motivation, and an exciting and funny reading > > > > >about the people > > > > >and the making of computers at Data General. > > > > > > > > > >The book is well known in the US and still available. > > > > >The german version (Die Seele einer neuen Maschine) is a perfect > > > > >translation but sold out (was rororo i expect). > > > > > > > > > >Happy reading... > > > > > > > > You're right; it's excellent. > > > > > > > > And if memory serves me, Josh Rosen's in it. > > > > > > > > Take care, > > > > Bob Perlman > > > > -- > > > > Rick Collins > > > > rick.collins@XYarius.com > > > > Ignore the reply address. To email me use the above address with the XY > > removed. > > > > 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 -- Rick Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. 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.comArticle: 25430
"S. Ramirez" wrote: > --I agree with you here 100%. I bet that if Andy, the original poster, had > a darn good Xilinx specific disty FAE, he wouldn't have the problem he is > having. His problem (my opinion) is that the disties are asking him a lot > of questions, contributing nothing to his cause, wasting his time, and they > are still getting the registration! Therefore, what they're doing works for > them. Part of the problem is that I really don't need the FAE. I'm really not pushing envelopes here. The last time the disty (I like that term!) people drove to Tucson (they're in Phoenix, so I'm sure that they wouldn't even bother if not for Raytheon being in town), I told them that I had chosen the XC4013XLA part for my new design. The first question they asked was, "Why not Virtex?" Well, let's see: the design didn't need that kind of speed, adding Yet Another Power Supply made things more complicated than I thought necessary, and, oh yeah, at the time, the tools for Virtex were still not "mature" yet. (I think F2.1i had just been released.) And you're right -- they're asking a lot of not-really-relevant questions. Like when I downloaded the CPLD Web Pack -- I was investigating using the CoolRunner 22V10 (needed a quick-fix PAL) because I thought it was an ISP part, or something, and then next thing I know, the phone rings, and it's the distributor asking if I was using a Xilinx CPLD in a new design, and when and how many would I be buying? (The answers were, "No, never and none," 'cause I ended up using a Lattice PALCE16V8 after downloading Lattice's fairly-neat PLD design tool. ABEL? Ack! Nope, no one from Lattice called.) To be honest, when I submit purchase reqs, I tell our buyer that I don't really care who supplies the parts. I try to buy 'em just before I need them. Oh yeah, production here means I'm ordering a dozen FPGAs, and the cost of the FPGA is in the noise compared with the cost of everything else. So, I tell the buyer that I need the parts now, and whoever can ship 'em gets to PO. I know that they will try to get the best price -- it's their job -- but really, why would a distributor even want to play in our low-quantity sandbox? And so all of the big disties have web sites when you can ostensibly look up price and delivery, but for VirtexE, they all have the note, "Call for info," which is what I was trying to avoid by using their (ugly, moronic) web site. I realize that when vendors sell direct, it pisses off their channel, but I'd really like to be able to go to (or have the buyer go to) the Xilinx web site, order up a dozen FPGAs, and be done with it. Or at least find out WHEN I'll be able to order my dozen FPGAs. "Sales Engineer" is an oxymoron. -- andy (Still waiting for Xilinx to send me a free coffee mug, or something. I guess I just don't buy enough parts.) ---------------------------- Andy Peters Sr. Electrical Engineer National Optical Astronomy Observatory 950 N Cherry Ave Tucson, AZ 85719 apeters (at) n o a o [dot] e d uArticle: 25431
"S. Ramirez" wrote: > Earlier, I posted a message to the newsgroup that explained how the > disties work and what their motivations are. A large amount of their time > is spent "registering" parts. I read that -- very enlightening! > You are correct in saying that they will jump all over you asking those > silly questions, because they are trying to build a case for registering the > design socket with, of all people, the Xilinx manufacturer's rep (Xilinx > rep)! What they don't understand is that timely availability of the part determines whether or not I can use it in a design. If VirtexE isn't available by the time I need to make a prototype, then I have to work around it. Plain Ol' Virtex with external LVDS driver/receivers is reasonable, but the board design is (obviously) completely different. Different power-supply requirements, too. > So my advice is, if you don't want the disties to come give you a 2 hour > PowerPoint presentation on why they are the chosen ones, A PowerPoint presentation is Exhibit "A" for the prosecution! My wife told me a funny story. She is involved with a web startup and she and her client were meeting with three or four e-commerce "solution providers." So, one of these providers sets up a meeting, and the slick sales-dude gets up there with the laptop and the projector and the PowerPoint, and starts with this presentation: "This is the Internet! [big cloud] And THIS is ECommerce!" So they sat through an hour of that kind of bullshit, then got up and left. Ecommerce provider didn't realize that in one minute flat they had completely blown any chance of getting this quite-large gig. > to call the Xilinx rep yourself regardless of the part. That's the plan. I like it. -- a ---------------------------- Andy Peters Sr. Electrical Engineer National Optical Astronomy Observatory 950 N Cherry Ave Tucson, AZ 85719 apeters (at) n o a o [dot] e d uArticle: 25432
Hmmm. Just a few caveats on this methodology in general.... What if your verilog module is to be driven by, or drives the outside world and needs bidirectional or tristate buffers? Can you ensure that tristates for an external i/o are not generated down in the hierarchy as internal tristate elements, but rather are promoted to the top level appropriately? If your target does not have tristates, how will the macro without I/O be synthesised? This may yield an illegal final netlist. Or does the system have a chip-wide GSR that is inferred as a startup block in both macro and full-chip? (take two startup blocks into the shower sir?) Or (ok, bad design practice, but I see it _all_ the time) is the Verilog a combinatorial piece of logic that ideally should be dissolved into the instantiating VHDL code to improve the critical path so meeting timing that would not be possible otherwise. Or does the Verilog have redundant inputs (test modes perhaps?)that should be tied to high/low in your FPGA application, but instead are synthesised. Will the P&R tool take care of these? I do not think so. Cheers Stuart For Email remove "NOSPAM" from the addressArticle: 25433
> Part of the problem is that I really don't need the FAE. I'm really not > pushing envelopes here. --Andy, you might need the disty FAE if you have to get parts from the disty. The FAE gets bonus miles for every new design socket that "uncovers." This means that even if you just order 5-10 parts, he gets a bonus for the socket that one of those parts goes into. Since you are a low volume user, the salesperson may not be taking you out to dinner and lunch, but the FAE will surely give you a call, because it is that one socket that he is interested in. If he can help you technically, then fine. But if he can't, then this is like a "freebie" to him. He doesn't need to spend much time with you; he just needs to get the minimal information that he needs to register the design. --If you can get parts through the rep, then disregard the above. > > The last time the disty (I like that term!) people drove to Tucson > (they're in Phoenix, so I'm sure that they wouldn't even bother if not > for Raytheon being in town), I told them that I had chosen the XC4013XLA > part for my new design. The first question they asked was, "Why not > Virtex?" Well, let's see: the design didn't need that kind of speed, > adding Yet Another Power Supply made things more complicated than I > thought necessary, and, oh yeah, at the time, the tools for Virtex were > still not "mature" yet. (I think F2.1i had just been released.) And > you're right -- they're asking a lot of not-really-relevant questions. > Like when I downloaded the CPLD Web Pack -- I was investigating using > the CoolRunner 22V10 (needed a quick-fix PAL) because I thought it was > an ISP part, or something, and then next thing I know, the phone rings, > and it's the distributor asking if I was using a Xilinx CPLD in a new > design, and when and how many would I be buying? (The answers were, > "No, never and none," 'cause I ended up using a Lattice PALCE16V8 after > downloading Lattice's fairly-neat PLD design tool. ABEL? Ack! Nope, no > one from Lattice called.) --You can bet your bottom burrito that Raytheon is the main reason they come to Tucson. You are a sideshow. --If you are browsing through the Xilinx web site, and that action caused a distributor to call you, then this means that the Xilinx rep turned him on to you. It is the rep that gets this "report" from Xilinx. The fact that the disty called you tells me something -- the rep and one of the disties are very tight with each other. Is it only one disty that seems to be favored this way? > To be honest, when I submit purchase reqs, I tell our buyer that I don't > really care who supplies the parts. I try to buy 'em just before I need > them. Oh yeah, production here means I'm ordering a dozen FPGAs, and > the cost of the FPGA is in the noise compared with the cost of > everything else. So, I tell the buyer that I need the parts now, and > whoever can ship 'em gets to PO. I know that they will try to get the > best price -- it's their job -- but really, why would a distributor even > want to play in our low-quantity sandbox? --The disties want to play in every deal, low quantity or not. Even though it's nickels and dimes to them, they make their money that way. If you look at the disty revenues, the majority of it is nickel and dime stuff. Most of it is unsolicited stuff, too. Rarely will disties play in the high volume market -- that market belongs to the direct accounts, i.e., the buyers have set up relationships with the reps to ensure that no middleman will up the price even by one penny. > And so all of the big disties have web sites when you can ostensibly > look up price and delivery, but for VirtexE, they all have the note, > "Call for info," which is what I was trying to avoid by using their > (ugly, moronic) web site. > > I realize that when vendors sell direct, it pisses off their channel, > but I'd really like to be able to go to (or have the buyer go to) the > Xilinx web site, order up a dozen FPGAs, and be done with it. Or at > least find out WHEN I'll be able to order my dozen FPGAs. --There is nothing in the book that says that the Xilinx rep has to turn on the disty to a potential customer. It is the disties' job to uncover design leads, talk customers into going with what is on their platter (line card), and follow up. If the customer goes directly to the rep, then the disty did not uncover the lead and there is no contractual agreement to hand the customer over to the disty. In your case, though, the rep may be turning you over to his/her favorite disty, because there is some favoritism there. > "Sales Engineer" is an oxymoron. > > -- andy --How about just leaving the "oxy" off? --SimonArticle: 25434
Some more hints for using more than 4 clocks in Virtex parts... Define which 4 clocks get to use the global buffers by using attributes (see your synthesis vendors docs) to force the usage of IBUFG/BUFG or IBUFG/DLL/BUFG combination. You want the clocks with the highest fanout to use the global buffers. For the rest of the clocks, use pins on the top or bottom of the chip, near the center or near the logic it will be clocking if the clock is coming from a pad. Use the USELOWSKEWLINES constraint in the ucf or use the Constraints Editor under the Advanced tab. This should work without the MAXDELAY constraints. Kate Xilinx Software Technical Marketing Johan Petersson wrote: > Hi Hannah, > > There is a USELOWSKEWLINES command that you put in the .ucf . There is > also > some way (i don't remember what it is called) to constrain the skew on a > wire - it might be set maxskew = xxx :) > > I have used that stuff with Leonardo Spectrum without problem.n The thing > is that > the par router will take MUCH longer time to complete if you use the set > maxskew > constraint, but maybe you can live with that. > > What I would do myself is to put > 'par ... -i 200 ..." > as a background job with those constraints and see how far you can get > with > your favourite placement :) > > Good luck, > Johan P, > WDI ltd Sweden > > email vhdl_ninja@yahoo.com > > Hanna Bruno wrote: > > > > The problem faced here, was that the non global clock net was being split into 4 > > groups. The synthesis tool must have done this and the resulting routing seemed > > to have skew between the 4 clock groups. The FAE said that there is a constraint > > that can be added in 3.1i to use low skewlines, I have to try that yet and > > prevent the synthesis tool from splitting the net. > > > > Thank you for your comments Jamie. > > > > HannahArticle: 25435
This is a multi-part message in MIME format.
--------------2B732704BC9EE118E83B179C
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Hi Thomas,
We had exactly your problem (XC9500 circuit behaviour changed
depending on inclusion of test points), but did not run timing
simulation, assumed that using the global clock guaranteed no
skew problems. (Why else would the part include global clocks
if this is not the case?!!?!)
After struggling with it for a while, we noticed that some
of the output signals had what may be non-standard signal names,
they used the character "-". After changing this to "_", the
problems _seemed_ to go away, and we attributed the failure to
the back-end configuration generation S/W silently hiccuping
on a dis-allowed character. (I still haven't found the legal
signal name definition for the XC9500 schematic design flow
in Foundation.)
That there may be a design flaw in the part such that
using a global clock does not guarantee setup/hold times
is _very_ scary.
What simulator did you use to get this result?
Could you please post a follow-up if you have any
further information on this? Has Xilinx said anything?
We had a Xilinx FAE in, he acknowledged that the failure
mode we had went away after we included our internal
test points (problem went away when we looked at it!),
but he had no solution to offer at the time. It was
only after changing the signal names (and possibly
some minor circuit change) that the problem
disappeared for us. But we never got solid
confirmation of what the problem really was.
Thomas Falk wrote:
>
> Hi Everyone!
>
> I'm having a problem in a fully synchronous design in a XILINX XC95108-10
> CPLD using the schematic entry. All Registers in the design are driven by
> one clock over GCK1.
>
> The problems are spurious errors which depended on the existence of test
> connections from the inner circuit connections to a pad. With the
> connections it workes, without not.
>
> Using the timing simulation I have narrowed down the problem to a hold
> violation on some of the D-FF. The simulation shows that in a simple shift
> register structure containing two D-FF, the second one will not take the
> right value, if the second one changes its output. It seems, the clock of
> second D-FF is too late regarding the change of the data at the output of
> the first D-FF, even if both D-FF are clocked by the same single via
> GCK1. From my point of view the same situation is given in each
> synchronous counter, ands that makes me a bit scary.
>
> I'm not sure how to handle this situation and have the following questions:
> - In the beginning this design was not completely synchronous. After the
> first appearance of these problems I changed it to a complete
> synchronous one, but as it seems, the situation got worse. Is it better
> to do such a design not completely in synchronous logic?
> - Is it possible to split up the clock net? One reason for the problems
> may be a high load on the clock net GCK1.
>
> Generally I would also like to know if there is a systematic way to deal
> with such problems or to prevent their appearance.
>
> Thanks for any answer,
>
> Thomas Falk
--------------2B732704BC9EE118E83B179C
Content-Type: text/x-vcard; charset=us-ascii;
name="jsmith.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for John L. Smith
Content-Disposition: attachment;
filename="jsmith.vcf"
begin:vcard
n:Smith;John L.
tel;work:858-320-4102
x-mozilla-html:FALSE
url:http://www.visicom.com
org:Visicom;Imaging Products
adr:;;10052 Mesa Ridge Court;San Diego;CA;92121;USA
version:2.1
email;internet:jsmith@visicom.com
title:Principal Engineer
x-mozilla-cpt:;30864
fn:John L. Smith
end:vcard
--------------2B732704BC9EE118E83B179C--
Article: 25436erika_uk@my-deja.com wrote: > > hey, > > accedding www.xilinx.com here from UK, has become really uncomfortable > expecially after 1:00 p.m GMT. > > has xilinx mirror site in UK or in europe > > --Erika There's a www.xilinx.dk you could try that wonder why www.xilinx.co.uk is only a redirect ? --Lasse (+)--------------------------(+) | Lasse Langwadt Christensen | | Aalborg, Denmark | (+)--------------------------(+)Article: 25437
In article <39BCFE1C.DF4C46B7@anderson.u-net.com>, Chris Anderson <chris@anderson.u-net.com> writes Hi Chris, Why don't you compile the design in Modelsim with the debug option turned off and then send the compiled files as a library directory. We had an embedded micro sent to us this way. Andre' >Hi, >I have a design for a device written using Renoir and ModelSim in VHDL. >Initially it's targeted at a Xilinx Virtex. I need to generate an image >of this VHDL in a form that is as flexible as VHDL (in terms of the >ability to retarget) but is not in a human readable form so that it >can't be reverse engineered. > >Any suggestions? > >Thanks > >Chris Anderson >Article: 25438
rickman wrote: > > It was a great line from a great era of computing. Who was the other > supercomputer company? I worked at Star Technology for awhile and they > called their array processors "supercomputers". > I was Alliant. After Alliant I consulted for a year to KSR which was also a DG spinoff. Both companies are long gone, as is the entire supercomputer industry.Article: 25439
Of course I meant I was at Alliant, not I was Alliant. I really should proof read things before I e-mail them. Josh "B. Joshua Rosen" wrote: > > rickman wrote: > > > > It was a great line from a great era of computing. Who was the other > > supercomputer company? I worked at Star Technology for awhile and they > > called their array processors "supercomputers". > > > > I was Alliant. After Alliant I consulted for a year to KSR which was > also a DG spinoff. Both companies are long gone, as is the entire > supercomputer industry.Article: 25440
There is an inexpensive online interactive FPGA and CPLD course at www.chalknet.com. Sent via Deja.com http://www.deja.com/ Before you buy.Article: 25441
Rick Filipkiewicz wrote: > > "B. Joshua Rosen" wrote: > > > The MV8000 could be done on a small Virtex part but not in a 4005, the > > MV was a CISC machine the NOVA was am ultra simple RISC machine. The > > original Nova should be able to fit easily in a 4005. If you look at the > > Nova instruction set you will see that it requires no decoding and no > > microcode. The ALC instruction, which is the only operation instruction, > > has a pair of two bit fields for the register select, a two bit field > > which controls the carry mux, a 3 bit field which controls the skip mux, > > a two bit field which controls the shift mux, a bit which selects > > arithmetic/logical, a bit for zero/register, and a couple of bits of the > > operation. The load/store as I recall had only one addressing mode, base > > + offset. There was also a Jump and a Jump and Link instruction, and a > > couple of IO instructions and that was that. > > > > It seems like the only architectural advance on this, until out-of-order, was the > addition of pipelining to get the clock speed up. Or did the NOVA have that as > well ?? > > PS I also loved the book & have been quoting that line down the years. If good > lines were patentable you could have built your own custom commune on the > proceeds. The late 60s/early 70s minicomputers, like the NOVA, executed one instruction at a time, there was no pipelining. The mid to late 70s minis overlapped instruction fetch with execution, but they usually took a couple of cycles per instruction. By the mid 80s the minisupers launched one instruction per cycle and had something like four instructions in the pipeline at one time. The current generation of superscalar micros try and launch 3 or 4 instructions per cycle and their pipelines are ten stages deep. The Pentium IV supposedly has a 20 deep pipe. The increasing pipeline depths have been a case of diminishing returns for a long time, it's just done because gates get cheaper every generation.Article: 25442
"John L. Smith" wrote: > Hi Thomas, > > We had exactly your problem (XC9500 circuit behaviour changed > depending on inclusion of test points), but did not run timing > simulation, assumed that using the global clock guaranteed no > skew problems. (Why else would the part include global clocks > if this is not the case?!!?!) > > After struggling with it for a while, we noticed that some > of the output signals had what may be non-standard signal names, > they used the character "-". After changing this to "_", the > problems _seemed_ to go away, and we attributed the failure to > the back-end configuration generation S/W silently hiccuping > on a dis-allowed character. (I still haven't found the legal > signal name definition for the XC9500 schematic design flow > in Foundation.) > > That there may be a design flaw in the part such that > using a global clock does not guarantee setup/hold times > is _very_ scary. > There's just one remote possibility that although you have your clock connected to a global clock input the fitter isn't actually using the global routing. You need to check at the fitting report to see if there's a line likek Signall ``fooclk'' mapped onto global clock net GCK<n> and this at the end Global (GCLK) optimisation :ON Also one other thing - a really unlucky setup time violation can look like a hold time one if the Tco delay is just greater than a clock period.Article: 25443
You are correct in stating that a filter is required to reduce jitter, A bandpass filter with high Q is what is needed. The PLL with VCXO has a Q of millions. A good tank circuit works also, but less well (Q ~100). Guess what happens when you put the square wave MSB) into the same band pass filter? Pop: out comes the fundamental (for less money). I always get a kick out of all of those expensive sine wave lookups tables and A/D's doing nothing. If a low Q filter is used, there is some tiny improvement in the lookup table conversion method due to the sideband power not adding to the overall phase noise. Don't take my word for it, use a good spectrum analyzer to analyze the sidebands at each point in the circuit. Take out the D/A and see what changes. It usually makes the jitter less because of D/A noise issues, reference nosie issues, and comparator noise issues. "The common wisdom is neither common, nor wise." anon. Austin rickman wrote: > You are not totally correct Austin. If you want a square wave without a > lot of jitter, then you do need the sine wave which can be filtered to > produce a wave of just the fundamental. This is then compared to a fixed > voltage to produce a square wave with no jitter. > > If you don't do this, you will have a time jitter equal to your master > clock period as you noted. This is often not acceptable and the sine > wave lookup, DAC and filter can be less circuitry than the VCXO, phase > comparator and filter. In fact you can get the whole shebang in one chip > less the filter. > > Austin Lesea wrote: > > > > Nestor, > > > > A DDFS (direct digital frequency synthesizer) is an adder/accumulator. > > They have been around for perhaps 30 years now. I have used them for > > years in FPGAs. The sine look up table is only used if you want a sine > > wave. I have seen people use a sine look up table, a D/A, and then follow > > that mess with a comparator -- TO GET A SQUARE WAVE! Think about it. The > > MSB of the DDFS was already the signal they wanted! > > > > So, if you don't want a sine wave, don't add all that junk. > > > > The p-p jitter is the clock period used, and the Fout < 1/2 Fclock. > > > > I would use the highest frequency I could get away with. If you require > > even less jitter, the output can be passed through a single simple VCXO > > used in a PLL loop with an XOR phase detector and an external RC to remove > > practically all of the jitter if the frequency output range is narrow > > enough. > > > > Placing the DDFS in a locked loop, results in a complete digital locked > > loop (Patented -- look it up, under my name). > > > > There are many nice parts out there that package the whole thing, and are > > inexpensive, so you need to evaluate what it is going to be used for, and > > decide if you want to build it in, or not. > > > > Also look at: > > > > http://www.xilinx.com/xcell/xl31/xl31_32.pdf > > > > for fractional synthesis,and other NCO's. > > > > Austin Lesea > > > > Nestor wrote: > > > > > Hi. > > > > > > Does anyone know any manufacturer who fabricates > > > numerically-controlled crystal oscillators (NCXO), also known as > > > digitally-controlled crystal oscillators (DCXO) which are suitable for > > > digital phase-locked loop designs in VHDL and FPGAs? > > > > > > Although these blocks resemble a numerically-controlled oscillator > > > (NCO), they differ in that the NCXO is not oversampled to generate the > > > required output signal (an NCO needs to be oversampled by at least > > > 8-times in order to have an acceptable low jitter output). Rather, a > > > digital input word is fed to the NCXO and it synthesizes the required > > > output frequency using a standard, low-cost crystal oscillator. The > > > output is also a square wave, just like the standard crystal. In > > > general, the NCXO has a narrow tuning range similar to a > > > voltage-controlled crystal oscillator (VCXO), e.g. +/-150ppm relative > > > to a frequency in the MHz range. > > > > > > The NCXO technology is fairly recent from what I understand, but > > > allows one to replace a circuit composed of a digital-to-analog > > > converter (DAC) and a VCXO by one chip that performs the exact same > > > task will less design hassles. The DCXO is ideal for custom-made > > > phase-locked loop (PLL) circuits using digital sections that can be > > > implemented in VHDL and FPGAs. > > > > > > Since I haven't been able to find any NCXO manufacturers over the web, > > > I am now looking to the knowledgeable engineers, designers and friends > > > that frequent these newsgroups for some potential referrals and/or > > > links. > > > > > > Thanks in advance for your help. > > > > > > Nestor > > -- > > Rick Collins > > rick.collins@XYarius.com > > Ignore the reply address. To email me use the above address with the XY > removed. > > 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.comArticle: 25444
> There's a www.xilinx.dk you could try that > > wonder why www.xilinx.co.uk is only a redirect ? > The link to www.xilinx.com is a lot faster from, here in the UK, than any other european mirror. In fact, in all aspects of life, the UK is much closer to the States than to mainland Europe, except the geography :-)Article: 25445
On Mon, 11 Sep 2000 12:45:44, "B. Joshua Rosen" <bjrosen@polybus.com> wrote: > Your right, I was. I'm the guy who said "I'm sick of nanoseconds, I'm > going off to a commune in Vermont where I'll deal with no period of time > shorter than a season". Well, there are no seasons here in Vermont, other than cold (and extensions of cold). Sure, the locals have a picnic when "summer" falls on Sunday, but that's a one-in-seven chance (yesterday was glorious). OTOH, there are *lots* of nanoseconds manufactured here, though we're tring to scale them down to picoseconds, to fit the quiet environment. ;-) ---- KeithArticle: 25446
On Mon, 11 Sep 2000 02:02:15, "S. Ramirez" <sramirez@deleet.cfl.rr.com> wrote: > Because square is a special case of rectangular, and Xilinx didn't want to > put them in a special case. To expand further, special cases may get "minority status" under US law, unfairly discriminating against the "squares" and more conservative designs of others. ...simple really. ;-) ---- Keith > > > <erika_uk@my-deja.com> wrote in message news:8pgrq7$83f$1@nnrp1.deja.com... > > hey, > > > > why virtex chips are rectangular and not square > > > > --ERIKA > > > > > > Sent via Deja.com http://www.deja.com/ > > Before you buy. > > > >Article: 25447
Thomas Karlsson wrote: > I trying to synthesize an old design written in verilog (which is not my > cup of tea, I use VHDL). This design instantiate some module, but I want > to use a new version of this module, written in VHDL. How do I do this? > I am using Synplify 6.0, which should support mixed language source > files, but it complains that the referenced module can not be found. It would be nice if Synplify would accept mixed language input like some simulators. I suspect that there are some lovely issues at the boundaries between the languages... Not holding my breath. I have an idea that I hope to try at work soon. What I have done was to compile a VHDL file and have Synplify write out a Verilog simulation file. (Options menu). I then renamed this file (foo.vm to foo2.v) and had Synplify compile foo2.v. It compiled to exactly the same result after place and route as the original file (foo.vhd) compiled to. This example was rather small, a hundred gates or so. What I hope to try is to compile a similar module in VHDL to a Verilog "simulation file", and instantiate this in a larger Verilog design, and then compile the whole thing to a EDIF for building into a FPGA. Synplicity's help file makes the point that "The Verilog and VHDL output files from Synplify are for functional simulation only." As such, this method is probably(?) unsupported(!!). A simulation to verify the whole procedure using a VHDL or Verilog netlist extracted from the placed and routed design would seem to be a very good idea. -- Phil HaysArticle: 25448
Hi As someboby said, you might better to define freq value needed. From my experience, I used SY82429 PECL PLL device which is programable in 7(6?)bits M/N style resolution that covers 100MHz? to 400MHz when driven by 16MHz external Xtal. I used them with Actel FPGA 4yrs ago. (SY** is Synergy's product.) As the device being PECL, it heats Xtal package up and the output freq drifts a lot. If compensation required, you might have to have trivial control loop for the external Xtal with Vari-Cap and OpAmp, which means... (--;) a lots of additional analog circuits. So, you might better to define jitters, drifts, IO signal levels, and so on. Sent via Deja.com http://www.deja.com/ Before you buy.Article: 25449
I am deadfully sorry that I missed to post followings If you can read japanese char/font on your pc, try to visit a japanese company http://www.tk1.speed.co.jp/tamadevice/sangyou-osc.htm They sell TCXO,VCXO,OCXO for 5ppm/2.5ppm/1.5ppm Regards (^^; Sent via Deja.com http://www.deja.com/ Before you buy.
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