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
I am up and running with 7.1 now. I have not seen Foundation after version 3. I guess it looks alright. I do not plan on using anything but text driven designs so the all of the graphical data entry won't help me. It's going to take me some time to really give good feedback on it. Maybe something for both Altera and Xilinx. If you are really interested in some feedback, I would personally take the time to enter data into an on-line survey about your tools if you set one up. Just a thought. I had hopes of going back to Foundation (I need to stop having those) of being able to port some older designs. It seems it is able to read projects from version 4, forward. I have written Xilinx to see if I can get a copy of version 4 to port older designs to it and then to 7. Has anyone tried this for fun?Article: 81476
Hi, Yes, I have tried ISE -- the OP asked for an alternative. Quartus isn't perfect, but I think the GUI is more intuitive and has a lower learning curve, and the tool is generally more integrated. Or for those script-lovers, you can script up the various pieces of the tool to run without having to ever look at the GUI. The OP was asking for an alteranative, and I provided one. Regards, PaulArticle: 81477
lecroy7200 wrote: > > I have found the case, and the CAE assigned, and I am working with > > Peter to resolve this. > > Wow, I was gone for 2 weeks, and here is a 52-thread mushroom. I joined Xilinx early 1988, when the XC3020 was being announced, and I was responsible for applications, technical support and all device documentation. I also started a quarterly magazine called Xcell (still alive) and wrote a 1.3-page article "The Effect of Marginal Supply Voltage" (Xcell#6, 4Q90, and reprinted in edited form in every databook up to 1994) Don't google it, you get only one valid hit, and it is in Russian. The last paragraph may be relevant here: "...The XC3000 stays configured for small dips, and is smart enough to reconfigure itself (if a master) or to ask for reconfiguration by pulling INIT and D/P Low (if a slave). XC3000 will not lock up; the user can initiate reconfiguration at any time by pulling D/P Low, or, if D/P is Low already, by forcing a High-to-Low transition on RESET..." NOTE: IT SAYS: HIGH-TO-LOW TRANSITION ON RESET. Then follows a description of brown-out (as Phil Freidin mentioned) but that only relates to early XC2000, which lack the circuit that responds to the High-to-Low transition on RESET. Once Vcc has dropped below 2 V, these chips need a very low voltage (<0.1V) on Vcc before they can be reconfigured. But that was early XC2000, not XC3000. I very much doubt that the XC3000 can spontaneously unconfigure itself. In those days we shipped tens of thousands of parts per week, today we ship millions per week. If our devices were unreliable, Xilinx would be out of business. And we obviously are not! After 45 years in this profession, I have formulated Peter's Rule: "If a problem is so obscure that it defies solution by the smartest and most helpful engineers, then the real cause is most likely so primitive and basic that nobody stooped low enough to see it" So, check the power supply, the connectors, the traces and solder joints and decoupling capacitors. And check for transients on any pin. I am sure the problem is outside the chip. And please try the High-to-Low transition on RESET. Peter Alfke, Xilinx ApplicationsArticle: 81478
> Hi folks, > I'm trying to get a DDR-SDRAM controller work as an AHB slave. > According to the transfer timings in the AMBA Spec. Rev. 2, the next > transfer can't go on until the slave involved in the previous transfer > sets the HREADY signal. That means each time a read transfer associated > with the DDR is initiated, AHB masters have to wait until the DDR finishes > the read burst and puts the read data on the bus, and even another read > command involved with the same row as in the current read transfer is not > allowed. I think that's really a waste in timing, and will lead to a low > efficiency of the DDR bandwidth. > Any solutions? > regards, > Kevin Euhm, consider doing 'smart' things like prefetch, data buffering,... I've implemented an AHB bridge to the Altera DDR-SDRAM controller and I'm achieving 92% of the bandwith in burst mode. Both read and write. So for a DDR333 CAS2.5 and 64 bit DDR I've got 2.4Gbytes/s. JanArticle: 81479
So my simulations aren't coming out right. I've got a big block of VHDL
that synthesizes down to a decent size block of stuff, gated on the way
out with synchronously cleared D flip-flops. I've looked over the RTL
schematic and one of my signals cooks down, correctly, to:
FDR
.--o--.
1 --------------|D S Q'------------- OUT
| |
CLK --------------|> |
| R Q|
'--o--'
|
|
SYNC_RST -----------------'
(created by AACircuit v1.28.5 beta 02/06/05 www.tech-chat.de)
The rest have more exciting things going to the D input, but all are
suffering from the same problem, which is that the flip-flops, while
they sim correctly in the behavioral model, miss the first clock edge in
all sims from Post-Translate on, that is after I drop the SYNC_RST line
there is a rise, fall, rise on CLK before OUT goes high. Sounds like a
setup timing problem, but CLK is only 20 MHz and SYNC_RST is low for a
full 10 ns before the first rising edge. I realize the Spartan 3 isn't
the fastest chip on the market, but 10 ns is still enough time for it to
run to the corner store, pick up a cup of coffee, and still make it back
in time for the edge.
I'm using ISE 6.3.03i and a freshly installed ModelSim Starter 6.0. Any
ideas on what could be going on?
-- Rob
Article: 81480Mentre io pensavo ad una intro simpatica "Ray Andraka" scriveva: > > The system clock is usually some integer multiple of the sample (A/D) > clock. In order to minimize the hardware, you'll want to run the clock > as fast as your design will allow so that you can take advantage of > multiple clocks per sample. You usually can use the clock managers in > the FPGA to obtain the multiplied clock. For multiple channels in a > single filter, your clock should be an integer multiple of > (channels*sample clock). OK, so I don't have to provide this system clock on a pin, I have only to provide the sample clock? I apologize for the dumb questions but I'm a newbie in digital design. -- A fool and his money are soon partying. |\ | |HomePage : http://nem01.altervista.org | \|emesis |XPN (my nr): http://xpn.altervista.orgArticle: 81481
Tommy Thorn <foobar@nowhere.void> writes: > Oh yes. I can't be the only one here who would much rather run > everything from a Makefile. No, you're not the only one. I run both Quartus and ISE on Linux with Makefiles (well in the Quartus case most of the work is done in Tcl). I prefer to check all the files out from CVS, run make which will run synthesis, ngdbuild, map, par, bitgen, trce, netgen, and optionally upload the bit file (using impact in batch mode) to the FPGA. The only FPGA GUI tool I use every now and then is the FPGA editor (I use signalscan for my simulations). If GUI is Driving Under Influence, then what does GUI mean? Petter -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?Article: 81482
Seeing that you have decided to continue to post to the public thread rather than contact me directly, I will assume that this is how you wish to handle this issue. > "...XC3000 will not lock up; the > user can initiate reconfiguration at any time by pulling D/P Low, or, > if D/P is Low already, by forcing a High-to-Low transition on > RESET..." NOTE: IT SAYS: HIGH-TO-LOW TRANSITION ON RESET. I have read this document and I agree that this is what it states. If you had taken the time to read all of the posts, you would notice that this was one of the first things I had verified. > I very much doubt that the XC3000 can spontaneously unconfigure itself. I am only posting what I am seeing. You can choose to agree or disagree or even roll up your sleeves and check for yourself. > In those days we shipped tens of thousands of parts per week, today we > ship millions per week. If our devices were unreliable, Xilinx would be > out of business. And we obviously are not! It would be interesting to see how many of the 3000 series devices are sold. Regardless, I really don't care about the companies track record at this point. I am having a specific problem with a specific device and the question is how best to handle it. If Xilinx does not want to be part of the problem solving, this is fine. > After 45 years in this profession, I have formulated Peter's Rule: > "If a problem is so obscure that it defies solution by the smartest > and most helpful engineers, then the real cause is most likely so > primitive and basic that nobody stooped low enough to see it" Now this is an arrogant statement! You are entitled to your opinions of your customers and yourselves. > So, check the power supply, the connectors, the traces and solder > joints and decoupling capacitors. And check for transients on any pin. > I am sure the problem is outside the chip. And please try the > High-to-Low transition on RESET. Your way behind on what has been done to determine the root cause of this problem. It is a shame that you have decided to take what I would consider the unprofessional route of pointing the finger at your customer rather than trying to understand what has been done to identify the problem. If you do decide that your would like to try and work with us to solve this issue, I am more than willing to share with you everything I have seen to date. In the mean time I plan to continue with my testing to determine if there is a reliable way to detect the fault.Article: 81483
lecroy7200@chek.com wrote: > Seeing that you have decided to continue to post to the public thread > rather than contact me directly, I will assume that this is how you > wish to handle this issue. I think Peter posted here, because there was a large thread, and he was back from a 2 week absence. <snip> > > > Your way behind on what has been done to determine the root cause of > this problem. It is a shame that you have decided to take what I would > consider the unprofessional route of pointing the finger at your > customer rather than trying to understand what has been done to > identify the problem. If you do decide that your would like to try and > work with us to solve this issue, I am more than willing to share with > you everything I have seen to date. If you want Xilinx to assist on support for an EOL device, you could try to not annoy them ? > In the mean time I plan to continue with my testing to determine if > there is a reliable way to detect the fault. IIRC you have seen this ~6 times. Do you have a 'feel' yet for the correlating cause, over those 6 times - any common event or stimulus ? Even tho this is an EOL device, the reason to try and nail this is to check that no new devices have the same issue. -jgArticle: 81484
Hi Tuukka, > On 2005-03-23, Ben Twijnstra <btwijnstra@gmail.com> wrote: >> I'm pushing for this as well. Would you be OK with a GUI-less version? > > If I'd have Altera FPGA, definitely yes. I probably would have considered > purchasing Altera, if there would have been decent Linux software out to > try. Now it's a bit late, though. > > There needs to be an easy tutorial on using the CLI tools, but I trust > Altera can do it, or they already have. There's a whopping big TCL scripting manual in dead-tree format (200+ pages if I'm correct) that comes with Quartus 4.2. Also, work is under way to document each and every setting that can be set in the GUI and that the Quartus TCL interpreter understands. Then of course there's the quartus_sh --qhelp command that will give you online help for the command-line option of every Quartus command. Best regards, BenArticle: 81485
> On Wed, 23 Mar 2005 16:13:45 +0100, Sylvain Munaut wrote: > > >>You need portmap installed and started. Then the browser will work fine. > > > Portmap is installed but it's dead. When I do a status on portmap I get > > Executing /etc/rc.d/init.d/portmap status .. > > portmap dead but subsys locked > > Any ideas about how to get portmap to work? I had the same problem and I was not able to start portmap from prompt, but I resolved the problem using the Gnome tool which manages process and daemon. In the Italian version it's in a menu called "Services", you can try to start portmap here, it seems to work. And the browser problems are resolved too (just set firefox or mozilla instead of netscape in "Preferences" -> "Browser" in ISE environment). Bye!Article: 81486
Jim Granville wrote: > lecroy7200@chek.com wrote: > > > Seeing that you have decided to continue to post to the public thread > > rather than contact me directly, I will assume that this is how you > > wish to handle this issue. > > I think Peter posted here, because there was a large thread, and he was > back from a 2 week absence. I agree that it is a lot to take in. I will not comment on why Peter felt he should post to the group. That was his choice to make. I was under the impression from Austin's last post that we would handle this outside of a public group. > > > If you want Xilinx to assist on support for an EOL device, you could > try to not annoy them ? Sorry you feel this way Jim. The goal here was certainly not to do so. I am only presenting my findings. If my findings do not match up with what Xilinx has published or stated in the group, I will point it out. How they react to that is up to them. If your refering to my posting on how the hotline was handled, remember that it was Xilinx who asked for this information in a public group. Up till then I only posted that I had been having little to no responce from them. > > In the mean time I plan to continue with my testing to determine if > > there is a reliable way to detect the fault. > > IIRC you have seen this ~6 times. Do you have a 'feel' yet for the > correlating cause, over those 6 times - any common event or stimulus ? Yes, you are correct in that I have seen the failure six times now. At this time everything still appears to be random, but again I have only duplicated the problem twice from when I started posting. It's not a lot of data to draw a conclusion from. I am trying everything I can to cause the parts to get into this mode, but nothing I do seems to effect it. The only thing I have a "feel" about is the internal oscillator dropping out. If I reproduce the problem and the oscillator drops out as before I will have a lot more confidence that this is why the part can not recover. > Even tho this is an EOL device, the reason to try and nail this is to > check that no new devices have the same issue. There are two items that need to be addressed. The first and most important is to minimize the effect this will have on our customers. That is why my focus is on finding a way to detect the failure (with no changes to the hardware). The second reason is to minimize our risk in future designs.Article: 81487
Ben Twijnstra wrote: > Hi Tuukka, > > > There's a whopping big TCL scripting manual in dead-tree format (200+ pages > if I'm correct) that comes with Quartus 4.2. Also, work is under way to > document each and every setting that can be set in the GUI and that the > Quartus TCL interpreter understands. > You can save the trees and read the 358 page document from http://www.altera.com/literature/manual/TclScriptRefMnl.pdf The document being referred to by Ben is the Quartus Scripting Reference Manual. It is slight misnomer to call it a Tcl scripting reference. This document covers two different approaches for scripting, each with their own strengths. One is command line scripting, where you call the different command line executables quartus_map, quartus_fit, quartus_tan, quartus_eda, quartus_asm and quartus_pgm with command line options. If you are familiar with the Xilinx compiler executables with their - switches on the command line this will be very easy to understand. The second approach allows you to use the Tcl programming language for creating your design flows. This is more powerful than command line scripting as you can use the rich Tcl API supported by the Quartus executables to script and automate your design flows, right from setting up your project, through compilation and verification. For e.g. if you wanted to control our flow based on the condition of certain design objects in your compiler report, or create custom timing analysis reports the Tcl approach is the way to go. Hope this helps, Subroto Datta Altera Corp.Article: 81488
I have a bank of On Semiconductor EP445 1:8 deserializer chips operating at LVPECL levels. The eight outputs are single-ended. How does one bring a single-ended LVPECL signal into a Virtex II? Using buffers to make them differential is out of the question. I have 64 of these signals.Article: 81489
"Quiet Desperation" <nospam@nospam.com> wrote in message news:240320051704165633%nospam@nospam.com... > I have a bank of On Semiconductor EP445 1:8 deserializer chips > operating at LVPECL levels. > > The eight outputs are single-ended. > > How does one bring a single-ended LVPECL signal into a Virtex II? > > Using buffers to make them differential is out of the question. I have > 64 of these signals. First, the FPGA banks would need to be at 3.3V. Then, you could: 1) Use two FPGA inputs (P/N pairs) per LVPECL output. The N side of one of the diff input pairs would be biased to the common-mode level of the LVPECL output. The drawback of this is that it will take 128 FPGA input pins. or 2) Use SSTL3 inputs and tie all the VREF pins to the bias point (the common-mode level of the LVPECL outputs). This will reduce the total number of FPGA input pins required. BobArticle: 81490
Hi, I just finished viewing the fpga power consumption net seminar that Vaughn presented today. I found it informative and, to me, it apeared to be objective. According to Vaughn's experiments and measurements, Stratix 2 exhibits lower dynamic power dissipation in the core and similar power dissipation in the IO; beyond that his experimental results contend that the highly touted static/leakage power advantage that V4 is supposed to have is very minor; some might even say negligable. I am very curious to read Austin and Peter's opinions of this presentation. Ljubisa Bajic ATI Technologies ---------- My opinions do not represent those of my employer.Article: 81491
In article <Y%K0e.3247$gI5.474@newsread1.news.pas.earthlink.net>, Bob <nimby1_notspamm_@earthlink.net> wrote: > "Quiet Desperation" <nospam@nospam.com> wrote in message > news:240320051704165633%nospam@nospam.com... > > I have a bank of On Semiconductor EP445 1:8 deserializer chips > > operating at LVPECL levels. > > > > The eight outputs are single-ended. > > > > How does one bring a single-ended LVPECL signal into a Virtex II? > > > > Using buffers to make them differential is out of the question. I have > > 64 of these signals. > > > First, the FPGA banks would need to be at 3.3V. Then, you could: > > 1) Use two FPGA inputs (P/N pairs) per LVPECL output. The N side of one of > the diff input pairs would be biased to the common-mode level of the LVPECL > output. The drawback of this is that it will take 128 FPGA input pins. > > or > > 2) Use SSTL3 inputs and tie all the VREF pins to the bias point (the > common-mode level of the LVPECL outputs). This will reduce the total number > of FPGA input pins required. > > Bob Eewww... Thanks for the info, though. I'll ponder these two. The 128 inputs is fine because if there were a version of the 445 with differental outputs, I'd buy it. My resistance to using buffers to make them differential was the number of external buffers I would need. The SSTL3 is an intersting idea.Article: 81492
Quiet Desperation wrote: > I have a bank of On Semiconductor EP445 1:8 deserializer chips > operating at LVPECL levels. > > The eight outputs are single-ended. > > How does one bring a single-ended LVPECL signal into a Virtex II? > > Using buffers to make them differential is out of the question. I have > 64 of these signals. Howdy, That is a bit of a toughie. Spec's for the EP445: Voh is between 2155 and 2540 mV. Vol is between 1355 and 1740 mV. Min Swing ~800 mV, although typical looks to be closer to 850 or higher. Looks like the output is normally centered around ~1950 mV, although spec shows it could be as low as 1790 or as high as 2115. As you probably know, this doesn't match up with any of the "normal" standards. I'll bet you could abuse the GTLP or single-ended SSTL or HSTL modes to get the job done by adjusting the vref and vcco values up to the values you need for this, although all of those standards have very small hysteresis. So you might be able to get away with AC-coupling the signals and re-biasing them, in which case not only could you perhaps use the above input types, but also maybe a PCI or LVCMOS1_n input type? Or as Bob posted, you could go ahead and chew up 2x the number of pins and bias the _n input of a differential receiver to the mid-point. Good luck, MarcArticle: 81493
My friend has been telling me that the ASIC design industry suffers from extremely expensive tooling (a single Design Compiler license is over $100k USD), ridiculously high NRE (mask-set for any standard-cell fab process), and equally expensive/difficult "back-end" (place&route) workflow. On the opposite end, I eye with envy the FPGA designer's world with very low startup costs. A hobbyist can buy a simple (<$250 USD) pre-made prototype-board, and thanks to vendor supplied free-tools, crank out simple designs. Obviously, complex designs (involving SOC blocks like a CPU-core, I/O standard core, etc.) require more capital investment for the IP and development-kits, but they're still very very cheap. So is it just a matter of time before a lot of the FPGA-jobs/employment migrate overseas? I see this already happening with some basic ASIC jobs (my colleague at Broadcom says Broadcom began outsourcing simple ASIC tasks a few years back.)Article: 81494
Nios-convert is causing me grief.
I am converting a 2249kB srec to a .mif but getting the following error
message:
nios-convert A.srec c:\B.mif
Out of memory!
Does anyone know why this is occuring? I am working on a fairly decent
machine. The .mif turns out (when it was working) to be around 7500kB.
Evan
Article: 81495Hello, Thank you very much for your replies. I used the board in standalone mode before, so it was really really difficult to configure the usb. So now I use the Linux operating system. In that way I have to install the drivers for the usb webcam and the vedio card, then I have to recompile the kernel, which is too complex. So I give up this proposal and try to use the ethernet to transfer and receive the data. I hope it would be easier. :DArticle: 81496
Hello,
I want to set up a conncetion between ML310 and the PC. I set the
PC as server and the ML310 board as a client. Is there any socket API
in Linux operating system in the board ML310 that I can use?
Thanks!!!
Article: 81497
Hello,
I want to access the ethernet on the ML310 board to transfer data
to a PC and receive data from a PC. But I find the only way to access
the ethernet is under the operating system. Then I chose Linux. Can I
directly create a c file in Linux and then compile and execute it? In
that way, how can I download the bitstream from EDK to the board?
I don't quite understand how to use Linux operating system in EDK
environment. Can anybody tell me?
Thanks a lot! :D
Article: 81498you'll have to wait for 100 ns (if you didn't set it to another values) for the GSR-Net (global set-/reset-net) to become inactive...Article: 81499
Marc Randolph wrote: >Quiet Desperation wrote: > > >>I have a bank of On Semiconductor EP445 1:8 deserializer chips >>operating at LVPECL levels. >> >>The eight outputs are single-ended. >> >>How does one bring a single-ended LVPECL signal into a Virtex II? >> >>Using buffers to make them differential is out of the question. I >> >> >have > > >>64 of these signals. >> >> > >Howdy, > >That is a bit of a toughie. Spec's for the EP445: > >Voh is between 2155 and 2540 mV. >Vol is between 1355 and 1740 mV. >Min Swing ~800 mV, although typical looks to be closer to 850 or >higher. > >Looks like the output is normally centered around ~1950 mV, although >spec shows it could be as low as 1790 or as high as 2115. > > > For this you have the VBB output on single ended ECL devices. Indeed 3.3V SSTL has the highest VREF and should suit best with one EP445 connected to one IO-bank with VBB connected to VREF. I once saw an app note were they used resistor dividers to get from PECL to LVDS. This could be done either to accomplish true SSTL levels but might degrate speed. One might just have a look ar http://www.onsemi.com/pub/Collateral/AND8066-D.PDF >As you probably know, this doesn't match up with any of the "normal" >standards. I'll bet you could abuse the GTLP or single-ended SSTL or >HSTL modes to get the job done by adjusting the vref and vcco values up >to the values you need for this, although all of those standards have >very small hysteresis. > > > That's no problem as long as your VREF is ok. >So you might be able to get away with AC-coupling the signals and >re-biasing them, in which case not only could you perhaps use the above >input types, but also maybe a PCI or LVCMOS1_n input type? > > > From performance point of view this is best if voltage translation is required, but requires DC balanced data patterns. >Or as Bob posted, you could go ahead and chew up 2x the number of pins >and bias the _n input of a differential receiver to the mid-point. > > > The advantage of using seperate VREF pins (that's basicly what you are doing) could be that the IO bank restriction falls. But even on parts with high IO count banking shouldn't be a problem. I'd prefer single ended connections (from the EP445) from the PCBs point of view. Regards Thomas
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