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
wv9557@yahoo.com (Will) wrote in message news:<4a885870.0301161730.88cd0e3@posting.google.com>... > > > what's the fun in buying a kit :)? > The following board is inspired by the XESS XCS series board, and > uses an XC4000 part. > > http://www.geocities.com/wv9557/fpga_pic.jpg Make that http://www.geocities.com/wv9557Article: 51601
Matt <matt@NOSPAMpeakfive.com> wrote in message news:<3E271B3D.41B50507@NOSPAMpeakfive.com>... > rickman wrote: > > > Sounds to me like you are a software person rather than a hardware > > designer, right? > > Let's just say the last time I designed hardware you could unsolder > parts using a plain old soldering iron and a solder sucker :) But you're > basically right. > > > When you write HDL descriptions of hardware, you don't > > write the code thinking of the problem and let the tool generate its own > > hardware to solve it like is often done in software development. > > Although this works pretty well with most compilers, HDL synthesizers > > are not as well developed. Normally a HDL developer will write his code > > thinking of the solution and use the HDL to describe what his solution > > should look like. This is a very different process. > > > > If you write HDL thinking of your solution then the tools work pretty > > well. In that case your example above is not really practical since an > > FFT written in C would not translate well at all into an HDL as normally > > used. > > This seems to be a hint to my answer. I'll rephrase the question. There > are companies that sell software that will take matlab or Handel-C and > turn it into fpgas. So fft->fpga is possible. What I want to do is > quantify how good that might be. There's another thread running about > schematic entry vs vhdl that implies that vhdl is ok if it's used to > describe data flow as opposed to serial process flow. This implies that > the serial->data flow translation is not so good. How bad is it? If > writing serial code generates an fpga that's half as fast as writing > data flow then that's not bad. If it's a 1000 times slower and is 10 > times the size then that's a serious problem. It's the usual assembly vs > C tradeoff. > > Assuming the program is written using data flow, can a compiler do a > good job of place and route or is this another case where the user has > to get involved? Considering that the graph theory anywhere near this > type of stuff is all NP I assume there is a problem. Since there are > tools that allow people to help with this I'm sure there's a loss of > efficiency by just letting the tool do everything. I just want to know > how much of a loss there is. > > Matt If you have a specific example of the type of SW-HW you might want to turn into FPGA, it would help alot to say so upfront rather than discuss FFTs which may not be where you are really going. Although the FFT is a good example and it is quite well understood by marketing, math, sw &hw guys, it is understood perhaps exceptionally well by hw guys because of the level of detail involved in creating the engines and almost not at all by marketing guys who might be just selling multipler counts (insider pun). Usually the cooley tukey algorithm as expressed on 1 sheet of paper is usually built as radix 2, what does it take to get it to hw? The last time I did a Wavelet->DCT->FFT it took a year to design the ASIC mapping the dirty Fortran code to inline flattened unrolled C code & turning into a datapath with a few other bodies to help. Doing this again today with FPGA with a different set of parameters might take half the time & half the bodies, due to experience & better tools. The Verilog that replaced the 30 odd lines of Fortran code was probably a few thousand lines and wouldn't be particularly readable unless you happened to be an FFT hw guy, but was provably exactly the same as the modified C code from the Matlab guys, bit for bit. FFTs though are special in that you can find quite a few persons here/elsewhere who have done this before a few times, and you can buy or borrow ready made designs that should be ok or good. A few ASIC chips have always been around for 1 or 2 decades. Over time the capabilities of FFT engines has gotten better tracking what the technology would allow. One of the nice things about hw design is that you figure the fundamental limits of what the specific ASIC/FPGAs are capable of, like high many multipliers are available & how fast they can cycle on a butterfly as well as available memory bandwidth. Then its just a question of working out the myriad details to keep all those MACs running near 100%. Of course the FFT can be computed faster and faster but the latency is a limiting factor so that really high performance hw desigers will have a deep pipeline of engines, each of which is further pipelined. For instance a 3us 1024 complex FFT might use 5 passes of radix4, each radix pass is a separate engine so 5 overlapping FFTs will be in flight continuosly each delayed by 3us rate. Each engine could use 12 multipliers rather than the (4)*4 the rad2 would use. So 60 odd multipliers running at 256 clocks or so every 3us gives 85MHz with final delay of 15us. Further, the 1st or last engine could be multiplier gutted dues to the simpler math involved but now you have a special engine, saves another 10-20% hw though. By playing with the micro architecture, the 12mul rad4 1 cycle engine could be replaced by 1mul 12 cycles, or 2muls 6 cycles and so on. One of the important aspects of FFT design is also trying to work with the limited bandwidth of available memory, nos of ports & nos of mem blocks. A novice might automatically go for rad2 because the code is so well known, but it would cost the most in terms of muls & memory cycles, it is important to reduce mem cycles to a minimum due to power used. Now rad4 can be computed at same rate as rad2 but with half the memory bandwidth & 3/4 the muls and half the total latency. Even bigger radix can be used, the max rate FFTs of any size will limit to 2 passes of sqr size. The sqr design then is a smaller FFT problem that can be recursively conquered/factored. Also not many people know that even rad2 can be computed with 3 muls instead of 4 at the cost of 8 adds instead of 6 and an extra bit of precision. The engine I used for DCT/FFT used a dual I/Q datapath architecture cycling 2 butterflies every 3 cycles. These rad2s were then cycled 12 times through temp reg files to build up a rad8 box with real mem only used on alternating input or output, so registers provided 2/3 of the bandwidth & mem power consumption 1/3 of simple effort. Now there are some pretty esoteric FFTs out there (see Blahut etc) that are specially tuned to cut down the muls by a factor or 2 over ct, but using prime radices plays havoc with the design effort. If you handed the same ct C code to HandelC, I have no idea what you could expect, but I think many here would probably agree that you might get a very basic design to run 5-10x worse, ie more area, much more cycle time. Doing it the hw way, also alows issues such as rounding & scaling to be specified directly & properly. If you try to use HandelC to do real hw design at the level of detail hw guys would get into, I'd say you beating a dead horse. On the other hand Celoxica has shown some impressive demos of Jpeg2000 C code and volume renderers running on RC1000 & spartan boards, where almost std C code was just magically converted, but I am just guessing that hw design could be 5-10x better. When shown the demos, I didn't bite the booth staff, I wish an honest writer could tell us what the knockdown might be. I could use Celoxica myself for experimenting, but then again Verilog, V2C, schematics, and deep design suits me fine. Seeing your web site, if you are familiar with Occam & its view of Processes, then you will know exactly where HandelC is coming from, since its is just the C version of Occam and Occam is basically a HDL simulator. If you have a more interesting app than FFT, lets us know. JJ eh not bad for a dumb hw jock that shouldn't be allowed on FPGAsArticle: 51602
There is nothing at the link http://www.geocities.com/wv9557 only a link to the the board's diagram .Please give the design details "Will" <wv9557@yahoo.com> wrote in message news:4a885870.0301162231.48d3637e@posting.google.com... > wv9557@yahoo.com (Will) wrote in message news:<4a885870.0301161730.88cd0e3@posting.google.com>... > > > > > > what's the fun in buying a kit :)? > > The following board is inspired by the XESS XCS series board, and > > uses an XC4000 part. > > > > http://www.geocities.com/wv9557/fpga_pic.jpg > > Make that > > http://www.geocities.com/wv9557Article: 51603
"rickman" <spamgoeshere4@yahoo.com> wrote in message > Maybe I don't understand the issue correctly. Are you saying that you > have a clock signal in your design that drives the clock inputs on FFs, > but you don't want to run it through the global clock buffer because > someone has given you a pinout that puts the clock on a different pin? > > This is not a good situation. If you don't use the global clock routing > it will use the general routing. You can, and most likely will, have > problems with clock skew where a signal that is changing because of the > clock will reach another FF before the clock does so that the FF will > latch the wrong value. > > I don't know why you are constrained to this pinout, but you should > think very hard about using a global clock buffer. Unless this clock > drives a very small section of the FPGA, I don't think I would try to > use general routing for a clock. > It is a design that I inherited when someone else left our company. Unfortunately the PCB is in production so the pinout cannot change. I assume it must have previously worked. My predecessor's PC has been wiped so I've had to recreate the .tcl and constaint files. It does only drive a small section of FPGA.Article: 51604
> 2. Clock syncronization between the two boards is another issue. I can > think of one way to do it. Use a pll in one FPGA device and take an > output of the clock from this FPGA (FPGA 1). Supply this output clock > of FPGA 1 as the input clock to FPGA 2 on the second board. Would this > work and if so, Is this the right way ? What other ways would be used > if any ? Which would be more efficient in terms of clock skew ? When you apply a single external clock to two FPGA devices of different type/manufacturer, their flipflops don't necessarily clock at the same time. You may experience considerable clock skew between the two. You get rid of long-term differences, yes. But you still have to employ interface protocols to transfer data from one FPGA to the other. MarcArticle: 51605
Ray Andraka wrote: > Use SRL16's. Write shifts the data in, read is accomplished with a simple > up-down counter that counts up for write, down for read. Nice because only one > counter is needed, and that counter provides a count of how many words are in > the fifo too. > For high speed operation its probably worth adding a register on the outputs. If you can tolerate an extra clock's latency then its easy but to get the same write -> output valid delay (0) then the input needs to be steered straight to the output reg if the FIFO is empty.Article: 51606
Prashant wrote: >>While a design spread over multiple chips are much harder to simulate, >>it might be cheaper to do a board with everything in one chip. >> >>Rene > > > I would rather use a single device. But there are many reasons which > make that difficult. The design size is not small enough to meet the > timing requirement and fit in a single device as of now. Also, two > different companies could be working on the project with neither > wanting to give out IP (for good reasons). In such a situation, > multiple boards are inevitable. Also one of the boards may have an > ASIC on it. Then it is a matter of specifying the interface between the two right and providing a simulation for the other part. It would be too bad to eventually realize with a logic analyzer that the interface was not understood identically. Rene -- Ing.Buero R.Tschaggelar - http://www.ibrtses.com & commercial newsgroups - http://www.talkto.netArticle: 51607
Hello, how can we rename an implementation project within the Xilinx tool. I want to create a clone copy of a project by giving it another name ThanksArticle: 51608
Hello All, If the signals are to be synced to the clock then definitely there is an issue. However one can use the delay property of a IO Pad (Xilinx-FPGA). The idea is to put the clock thru a normal IO pad without delay constraint. Then find the skew involved in the path from the pad to the BUFGP. If it is in the range of 2 ns, then use the constraint of inserting delay at the pad for the other signals that are being clocked w.r.t the clock. Regards Amit Ashara Ray Andraka <ray@andraka.com> wrote in message news:<3E278C4D.C9BF40B@andraka.com>... > I concur with bringing the clock to a bufg (not an ibufg) once it is in the chip. The DLL won't clean up > a clock with jitter, the best it will do is restore symmetry to the duty cycle. If you have external > signals also sync'ed to the clock, you are in for a possibly rough ride for sampling those signals as the > clock skew is no longer tightly controlled. If you had a clock out from the FPGA you could use that with > a DLL to clean up the clock timing, but then you'd be back in the same situation of having to respin the > board. > > Amit wrote: > > > Hi All, > > > > I Agree with Falk Brunner's suggestion of routing the clock from a > > normal I/O pin to a IBUF and BUFG so that it can take the global > > routing resource. But do not try to put an IBUFG as it will be locked > > to a clock pad. Also to stabilise the clock try using a DLL or a DCM > > alongwith it. In this case the clock to the internal logic will be a > > very stable clock. > > > > Regards, > > Amit > > > > "Falk Brunner" <Falk.Brunner@gmx.de> wrote in message news:<b06vfj$mcpnb$1@ID-84877.news.dfncis.de>... > > > "rickman" <spamgoeshere4@yahoo.com> schrieb im Newsbeitrag > > > news:3E26F6D3.18D62D71@yahoo.com... > > > > > > Agree. > > > > > > A clock should only be routed on a global clock net. Yes, you can also use > > > local routing, but this is the high art for the guys that know what they are > > > doing. > > > But In this case, the is a possibility to workaround this problem. > > > Instanciate a IBUF (normal input buffer) and a BUFG (global clock buffer). > > > This way, you can get your clock signal into you FPGA via a normal IO pin > > > and route it internaly to the global clock buffer. The only thing you will > > > not ave compared to the dedicated clock input is, the defined timing > > > relation between the clock on the input pin and the clock on your global > > > clock net, means, the skew between them is more of less random within some > > > limits. But this wont be a problem if you have no control line comming into > > > you FPGA with a fixed timing relation to your clock. > > -- > --Ray Andraka, P.E. > President, the Andraka Consulting Group, Inc. > 401/884-7930 Fax 401/884-7950 > email ray@andraka.com > http://www.andraka.com > > "They that give up essential liberty to obtain a little > temporary safety deserve neither liberty nor safety." > -Benjamin Franklin, 1759Article: 51609
I have been trying to compile a project. I could compile in DEBUG mode easily and it was quite fast. But the problem starts when I try to compile EDIF. It starts to compile the EDIF as usual, after few minutes when it is expanding netlist, DK1 stops doing anything. I have the latest DK1 version. I checked the program status in Windows task manager, I could see that the CPU is in idle state, doing nothing, although I was only running DK1. I left the compiler to take its time, after a day, it is still compiling. I am using a Pentium III with 895 MHz processor and more than 1 GHz virtual memory (RAM). I can see that RAM requirement shoots up to 750 or 800 MB for this EDIF compilation. I have tried using MSVC and GCC, both gave me similar problems, I also tried to run DK1 in WINDOWS 2000 and XP platform, the problem existed in both cases. Please advice me what can be possible reason for this problem. Regards Imad, Aalborg University, DenmarkArticle: 51610
I added a gallery section to my website where I'll put up some floorplans as I have
time. I put the XC2V6000 one I mentioned here up there for now.
Ray Andraka wrote:
> I think I disagree with you here. One shouldn't need to flatten the hierarchy for
> debug nor for placement. For placement, RLOCs are hierarchical...use them for
> hierarchical floorplanning. We do this, and typically only spend a day or two on
> some quite extensively floorplanned designs. I really ought to put a floorplan
> gallery on my website to point out what I am talking about. If you've ever seen
> one of my design floorplans you'd immediately recognize that it is far different
> that what you usually see in floorplans. Hierarchy in the floorplanning saves
> gobs of time (I shudder to think how long it would have taken to floorplan a
> recent full XC2V6000 design if it wasn't done hierarchically. With hierarchy, I
> spent less than 20 hours in floorplanning including the time to put hte RLOCs in
> the code (the lower levels of the code were already RLOCed and are reused
> code). For debug, I generally use lots of simulation and a little bit of extra
> hooks added to the design. Again, I couldn't imagine trying to wade through a
> flattened design in that scenario.
>
> Frankly, I'm not sure how size swamps hierarchy. In fact, I think the larger the
> design the more necessary hierarchy is to keep the design problem sane. Hierarchy
> lets you divide and conquer in the design as well as in the verification.
>
> "Keith R. Williams" wrote:
>
> > Hierarchy only goes so far. Sheer size can swamp the best thought out
> > hierarchy. Eventually you need to flatten the hierarchy (placement,
> > debug, etc.). These things caught us many years ago, which is why VHDL
> > was chosen, I suspect.
> >
>
> --
> --Ray Andraka, P.E.
> President, the Andraka Consulting Group, Inc.
> 401/884-7930 Fax 401/884-7950
> email ray@andraka.com
> http://www.andraka.com
>
> "They that give up essential liberty to obtain a little
> temporary safety deserve neither liberty nor safety."
> -Benjamin Franklin, 1759
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 51611Are it possible to boot Spartan IIE in "Slave Serial Mode" directly from an microcontroller with SPI interface (master mode) ? /Michael WilspangArticle: 51612
Harjo,
You probably need to provide more details like,
* Who manufactured the motherboard? What chipset does it have?
* What type of PCI-X slot (PCI-X 66, PCI-X 100, or PCI-X 133) the slot
is?
* What frequency does LogiCORE PCI operate at? (33MHz or 66MHz)
* What is the PCI bus width of your PCI card?
* What configuration device is configuring the Spartan-II, and how fast
is it configuring it?
Anyhow, from the information you provided, here is my thoughts
about your problem.
I feel like the problem you are having is that the Spartan-II is not
being configured fast enough to catch RST# assertion.
As you know, Conventional PCI (That is, PCI 2.x) says devices have to be
active (In case of an SRAM FPGA, completely configured) within 100ms.
During that period, RST# is asserted, so that PCI devices can initialize
their FFs.
If the Spartan-II isn't getting configured within that period, it will
likely miss the RST# assertion, therefore, the design won't get
initialized correctly.
But this probably doesn't explain why your PCI card works in a
Conventional PCI slot, and not in a PCI-X slot.
To explain that, I will guess that in a PCI-X system, RST#'s assertion
period is shorter than in a Conventional PCI, therefore, your device
isn't getting the RST# needed to initialize the device.
If you are using XC18 series configuration PROM, you will like to raise
the configuration clock (You can do that without modifying your
design.).
Kevin Brace (If someone wants to respond to what I wrote, I prefer if
you will do so within the newsgroup.)
HJO wrote:
>
> Hello,
>
> We've got the following problem: Some time ago we finished a PCI interface
> card using a Spartan II FPGA and the Xilinx PCI core (3.3V). The card has
> been used in several computers since then and we have never had any problems
> with it.
> Recently we bought a new computer that also has to use this card, but it's
> equiped with PCI-X expansion slots. According to the PC's documentation the
> PCI-X slots are fully PCI 2.2 compliant. The Xilinx PCI core is also PCI 2.2
> compliant so there should be no problem. Unfortunately it does not work ! As
> far as we can see the problem is not PC related since several other
> (ordinairy) PCI cards work well with the PCI-X slot.
>
> Has anybody ever got this to work properly ? Or has anybody got any idea on
> what might be wrong ?
>
> Harjo.
Article: 51613My friend and myself have bought laptops and tried to run Modelsim on them. Everything works fine till we try to see some signals in the waveform. The waveform itself opens normaly, but when some signals are tried to be added into it, Modelsim crashes. The same problem occures on both of our computers. Does anybody know the reason?Article: 51614
What version of Modelsim? Is it the full version (SE/EE/PE) or something packaged with a vendor's tool set? What kind of license? What version of the operating system? How much RAM on your PC? scepan@serbiancafe.com wrote: > My friend and myself have bought laptops and tried to run Modelsim on > them. Everything works fine till we try to see some signals in the > waveform. The waveform itself opens normaly, but when some signals are > tried to be added into it, Modelsim crashes. The same problem occures > on both of our computers. Does anybody know the reason?Article: 51615
Hi Jock If it drives a small section of the FPGA then it can be simply routed from a normal IOB to a BUFGP and provided to the logic. Just take care if any signal is synchronous w.r.t the clock. Regards Amit "Jock" <ian.mcneil@uk.thalesgroup.com> wrote in message news:<b08i6u$isq$1@rdel.co.uk>... > "rickman" <spamgoeshere4@yahoo.com> wrote in message > > Maybe I don't understand the issue correctly. Are you saying that you > > have a clock signal in your design that drives the clock inputs on FFs, > > but you don't want to run it through the global clock buffer because > > someone has given you a pinout that puts the clock on a different pin? > > > > This is not a good situation. If you don't use the global clock routing > > it will use the general routing. You can, and most likely will, have > > problems with clock skew where a signal that is changing because of the > > clock will reach another FF before the clock does so that the FF will > > latch the wrong value. > > > > I don't know why you are constrained to this pinout, but you should > > think very hard about using a global clock buffer. Unless this clock > > drives a very small section of the FPGA, I don't think I would try to > > use general routing for a clock. > > > It is a design that I inherited when someone else left our company. > Unfortunately the PCB is in production so the pinout cannot change. I assume > it must have previously worked. My predecessor's PC has been wiped so I've > had to recreate the .tcl and constaint files. > > It does only drive a small section of FPGA.Article: 51616
I generated a VHDL output from a HandelC project, synthesized it and used the Xilinx tools to map and place and route for a XC4010XL. This works fine. Then I tried to generate a EDIF netlist with DK1 but the mapper tells me: NCD was not produced. All logic was removed from design. I checked the EDIF and found that no clock port is present. Instead a IPAD is the source of the clock signal in the netlist, which is removed by the mapper. any hints thanx ThomasArticle: 51617
> You get rid of long-term differences, yes. But you still have to employ > interface protocols to transfer data from one FPGA to the other. > > Marc I think it is these interface protocols that I'm trying to get an idea about (And I still dont have a lot). I also realized that my FPGA board does not have a clk out (unlike my mention of it in the 1st posting). Which means that while the board can accept external clocks, I dont see a way to send a clock out from the board. Any ideas how that can be achieved. Thanks, PrashantArticle: 51618
Apparently, in their infinite wisdom someone at PCI-SIG decided to us the membership dues and get "nasty" with the person who WAS hosting the only resource (I am aware of) for Device/Vendor IDs, and had them shut down for using the PCI logo as well as simply the word "PCI". http://www.yourvote.com/pci/ According to the letter that the PCI-SIG sanctioned through their lawyer, they CLAIM that EVEN the use of "PCI" is a violation: "so that we can prepare the necessary written assurances that you will discontinue all use of the name PCI..." Take a look at this URL, and if you are a PCI-SIG member, email them and/or the board of directors members if you feel this was a really dumb thing for them to do. AustinArticle: 51619
"Eric Smith" <eric-no-spam-for-me@brouhaha.com> wrote in message news:qh1y3cty1p.fsf@ruckus.brouhaha.com... > I wrote: > > Have you seen such a manual for a C compiler? > > "Austin Franklin" <austin@da98rkroom.com> writes: > > Er, yes. > > Where? On my book shelf.Article: 51620
Hi Keith, > Ok, call me dense. Not yet...but I'll reserve that right ;-) > If you push down the hierarchy to lower level > schematics, I can see there is no "synthesis" going on. Eventually > you'll end up with a schematic representation of a physical gate. Correct. > However, if you push down to HDL you'll have a abstraction of that gate > that is "synthesized" into the physical gate. Well, yeah. > > I'm not sure where the flowchart comes in. Does it have a > representation under it of a LUT/FF? Or is the physical construction > "synthesized" from the flowchart function. Flow charting "tools" can do either. The one I use is simply symbols with underlying schematics that allow me to drag and drop these symbols and create flowcharts. No synthesis is used. > > > The mainframe logic designers I worked with ~ten years ago used flow > > > charts for the entire design. The designs certainly were synthesized > > > (and simulated) from the flow charts. > > > > Are you talking board level schematics, chip schematics or what? I don't > > know the tool you are talking about. > > Chip, module, board, frame, processor, complex. All schematics (or > later, flowcharts). How, on earth, do you represent a physical PCB with a flowchart? > > > That too. The mainframes of the 70s-80's were designed using > > > schematics. The logic diagrams filled carts for a single system unit. > > > Call me skeptical on designs this size. > > > > That's why you use hierarchy. The more abstract (to a point, of course) you > > can define the functions, the better your hierarchy. > > Hierarchy only goes so far. Sheer size can swamp the best thought out > hierarchy. Er, no. You would rather weed through 1000 pages of text (or a schematic that is 100' x 100') than use hierarchy? Obviously you are talking about a REALLY feeble implementation of hierarchy, as this is simply not the case in "normal" use of it. > Eventually you need to flatten the hierarchy (placement, > debug, etc.). These things caught us many years ago, which is why VHDL > was chosen, I suspect. Absolutely not. Regards, AustinArticle: 51621
Hi there, I am trying to send characters serially using Atmel FPSLIC Board. Does any one knows how to do that . Thanks.Article: 51622
Not only is it really dumb but it sounds like selective persecution. Unless they go after every website that has "PCI" their copyright is invalid. They also have to prove that PCI is legally theirs to have. A quick google search comes up with... Prestressed Concrete Institute PCI Geomatics (since at least 1985) PCI Technologies Inc. (www.pci.com) It goes on and on. I went to the uspto.gov site and looked for PCI and there are a lot. I've read most of the yourvote/pci and the PCI-SIG is just asking for trouble. Steve > Take a look at this URL, and if you are a PCI-SIG member, email them and/or > the board of directors members if you feel this was a really dumb thing for > them to do.Article: 51623
Simply read this tread. Karl. <nospam@aol.com> wrote in message news:pjoe2vc6rh1juag4h0f9u805lb0v4c9q1q@4ax.com... > My last attempt at getting Altera support wound up with their > answering me with blanks. That's right, BLANK responses. And I don't > believe they read the messages either, based on previous answers. > > I have turned to Xilinx now, and must say that their (free) web-based > software and readily available parts (Digikey) beats Altera hands > down. Not to mention that I have seen Xilinx's presence on this > newsgroup! If Altera is here, they are well-hidden. > > > > On Mon, 13 Jan 2003 14:20:04 +0100, "Matjaz Finc" > <matjaz.finc@fe.uni-lj.si> wrote: > > >My experience: > > > >The Altera MySupport is useless, often slow and above all inapropriate in my > >experience. Looks like it's there just for marketing purposes - to be > >mentioned as superb on-line support for potential customers. When you (me) > >need help, usualy you get riduculous short answers that show they don't even > >try to read your whole message, not to mention answering it thoroughly and > >exactly. I often find the solution to my problems in this newsgroup (really > >prompt response!) or on my own before I get any info from MySupport that > >makes any sense. > > > >Regards, > >Matjaz > > > >"Austin Lesea" <austin.lesea@xilinx.com> wrote in message > >news:3E1C4F1E.1BD53CBD@xilinx.com... > >> Rene, > >> > >> Please, do not discourage people from using internet based support tools. > >> > >> I can not speak for Altera (obviously), but email and web-based support is > >> becoming a major means of asking and answering customer questions in a > >timely > >> fashion. > >> > >> The fact that Altera has someone who watches the comp.arch.fpga forum > >indicates > >> that they really do care about customer service, and 'caught' your inquiry > >in this > >> forum. > >> > >> Our hotline group would prefer that a case gets entered into their system, > >as they > >> will answer it quicker that way. But for those that wish to get other > >opinions, > >> this newsgroup is also valuable. > >> > >> I know that Xilinx takes this all very seriously, and watches response > >time vs. > >> how the case is entered to maintain quality of service target levels. > >> > >> > >> > >> Austin > >> > >> Rene Tschaggelar wrote: > >> > >> > Thanks for the quick reply. > >> > Amazingly quicker than the mentioned 'MySupport', > >> > but then again not - proves my point. > >> > > >> > Rene > >> > > >> > Subroto Datta wrote: > >> > > Rene, > >> > > A fix for this problem is under development. More details about its > >> > > availability will be posted as soon as the fix is tested and released > >in the > >> > > very near future (no later than end of this week). Thanks for bringing > >this > >> > > problem to our attention. > >> > > > >> > > - Subroto Datta > >> > > Altera Corporation > >> > > > >> > > "Rene Tschaggelar" <tschaggelar@dplanet.ch> wrote in message > >> > > news:3E1B4021.2090607@dplanet.ch... > >> > > > >> > >>I found a bug in quartus2 Web V2.2. > >> > >>When tring to place legacy components in schematic editor, > >> > >>such as the 74165b shiftregister, its connectors are off > >> > >>grid. This makes it somewhat hard to connect. > >> > >> > >> > >>Did anyone figure a workaround ? > >> > >> > >> > >>Their support is useless : login(!), place a question, > >> > >>relogin(!) to get a reply, so I didn't ask there. > >> > > >Article: 51624
> I think it is these interface protocols that I'm trying to get an idea
> about (And I still dont have a lot). I also realized that my FPGA
> board does not have a clk out (unlike my mention of it in the 1st
> posting). Which means that while the board can accept external clocks,
> I dont see a way to send a clock out from the board. Any ideas how
> that can be achieved.
Consider putting a "zero delay" PLL buffer chip right by
the clock generator and give each FPGA its own buffered
clock line.
-- Mike Treseler
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