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
Have you considered the OCIDEC (OpenCores IDE Controller) project. This may be usefull reference if you want to do this for the sake of experience. I personally have not used this core but I think it might be worth something. You may want to check out the other IDE MP3 player projects out there for some clues. I know of at least one that uses a PIC and a CD-ROM drive. Good HuntingArticle: 80926
antonio bergnoli <bergnoli@pd.infn.it> writes:
> does anybody try it with a different linux platform from red hat
> enterprise? I have a debian testing and it don't work
Most likely you don't have the versions of libraries it wants, or (if
you're running 6.3i) you're not setting up the environment variables that
it needs.
I've been running ISE 6.3i on Fedora Core 3 (x86_64 version) on an
Athlon 64 for a while now, and on the regular x86 version of FC3 on a
laptop, and it works fine, but I had to set some environment variables
to get it going. IIRC, to install it I said something like:
DISPLAY=:0 LD_ASSUME_KERNEL=2.4.7 ./setup
I don't like setting special environment variables in my ~/.bash_profile
that are only needed by one program and may interfere with other
programs (like LD_ASSUME_KERNEL), so to run the installed programs,
I use a bash script in my ~/bin directory called x63:
#!/bin/sh
x=$HOMExilinx/ise63
export LD_ASSUME_KERNEL=2.4.7
export DISPLAY=:0
source $x/settings.sh
$x/bin/lin/$1
The way I normally use it is to say "x63 ise", but you can invoke
other tools like fpga_editor as well. This trivial script doesn't
have provision for passing command line arguments, but that could
easily be added.
I just installed ISE 7.1i on Fedora Core 3 last night. It needed a
few older libraries from Fedora Core 2, libcurl.so.2, libcurl.so.2.0.2,
libXm.so.3, and libXm.so.3.0.2. I extracted those from the Fedora Core 2
RPMs (curl-7.11.1-1.i386.rpm and openmotif-2.2.3-2.i386.rpm), and put
them in ~/xilinx/oldlibs. I think libcurl was only needed by the
installed, but I haven't verified that. I did the install by saying
LD_LIBRARY_PATH=~/xilinx/oldlibs ./setup
My script for running 7.1i is:
#!/bin/sh
x=$HOME/xilinx/ise71
export LD_LIBRARY_PATH=$HOME/xilinx/oldlibs
source $x/settings.sh
$XILINX/bin/$PLATFORM/$1
Thus far I've been able to rebuild all my old 6.3i projects with 7.1i,
and everything seems to work except that synthesis errors apparently
cause ISE to try to invoke some kind of script, and that appears to
be failing. But the synthesis error messages show up in the report
file so I don't care too much.
I tried installing the 64-bit version on the Athlon 64 system, but ran
into many more problems with it, and wasn't able to resolve them all.
However, I have a BaseX license, and it appears that BaseX isn't
supported in 64-bit, so perhaps it wouldn't have worked for me even if
I'd solved the other problems.
Eric
Article: 80927Uwe Bonnes wrote: > set the DISPLAY variable to :0 I had to do that with 6.3i, but 7.1i doesn't seem to need it. EricArticle: 80928
Alexei A. Frounze wrote about UARTs: > The oversampling not only makes it possible to determine the position of the > start bit, but also it combats the noise and errors. The 16 consecutive > sampled values (each being 0 or 1) are used to decide on the actual bit > value. If most of these 16 samples are 1, it's 1. Otherwise, it's 0. I wrote: > I've never seen a UART that behaves that way. Such a UART would be > very unreliable, because if the sender was slightly slow or fast relative > to the receiver, the 1 bits would get smeared into adjacent bits. "Alexei A. Frounze" <alexfru@chat.ru> writes: > I don't see where it's unreliable. The majority tells the final value. Your > "slightly", which is about 1/16th of the bit duration isn't going to make it > unreliable so badly. Sorry, I misread your statement. Majority voting all 16 samples would probably be OK, though it would be a little less reliable than majority sampling only near the center of the bit time. It's still the case that I've never heard of a UART using more than three samples near the center of the bit time, and most only use one. EricArticle: 80929
lecroy7200@chek.com wrote: > Thanks. I read the note and agree that the problem could be related to > some kind of transient. If the Done/Program pin were stuck in the low > state it appears that the device will still reset by monitoring the > state of the Reset pin. Err, maybe. Keep in mind that on many devices, the RESET does NOT reset everything, and is more aptly labeled reset request. It is not uncommon to see devices enter a illegal (but 'safe') state, that can only be exited by a power cycle. This is because chips often use internal POR cells, using simple RC elements. Such states are normally either external energy transient or runt-pulse related. That is why in some industries, the WDOG systems work by doing a Power-Cycle, rather than the less effective 'reset'. If you can sense this state, your best remedy could be to trigger a power re-cycle ? -jgArticle: 80930
I would say that everyone else seems to manage in producing working designs without rewritting either vhdl or verilog,niether of them are meant to be a 'programming language' so aproaching them from the point of view of a programmer isnt the best way of looking at them.Article: 80931
steve wrote: > Hi all, > > I want to graphically create and edit waveforms for documentation purpose. > > Xilinx's HDL Bencher does not exist under Linux... (too bad: it can export in HDL) > > Waveformer is $6000, gasp! > > A guy here uses some commercial spreadsheet...;-) please tell me what do you use! Joseph Palmer's XWave font is cute (and free): http://www.josephpalmer.com/etc-local/misc/xwave.zip It takes a little pR4<T=A1<e to master it, though. Cheers. -- PabloBleyerKocik/"Stop throwing stones. The night has a thousand pablo / saxophones. So get out there and rock, and roll @bleyer.org / the bones. Get busy!" -- Roll The Bones, RushArticle: 80932
Jim Granville wrote: > lecroy7200@chek.com wrote: > > > Thanks. I read the note and agree that the problem could be related to > > some kind of transient. If the Done/Program pin were stuck in the low > > state it appears that the device will still reset by monitoring the > > state of the Reset pin. > > Err, maybe. > Keep in mind that on many devices, the RESET does NOT reset everything, > and is more aptly labeled reset request. I am just going by what their data sheet says. From my testing, it does appear that the part functions this way as well. Not to say that it has not reached some "safe state" that reset won't shake it loose, because that appears to be what I am seeing. This design has the power down pin tied to VCC, but I broke it out to test this mode as well. I tried doing some basic DC tests as well as sweeping RF into the pin, but again was not able to replicate the problem. Yes, I can detect when the problem happens. Power cycling the system is not an option. Are the Xilinx guys still browsing this group? If so, any ideas from the masters? I am running out of ideas to try.Article: 80933
John Adair wrote: > Xilinx have started selling some stuff direct. I don't know if XCF01s are on > list, or if there are any problems, or costs, in getting UK delivery but > have a look. They sell a few Spartans, but not the proms to go with them! > > Alternatively try both halves of Memec with the franchaise. They are > technically in competition. I would use the telephone for maximum result. If > after trying all that you still have a problem give me a call and I'll try > and assist. Thanks for the offer. I'll try and give them a ring first but may take you up on that. I still can't get over the fact that there are no hobbiest type distributers for these entry level devices. Andy.Article: 80934
Hello group, I have a design that implements Ethernet (10-base) without a PHY chip straight into an Altera Cyclone. Things are working fine mostly, but I'd like to improve the electrical interface if possible. So far I've been using a transformer and two resistors into a standard 3.3V LVTTL pin. Levels were not optimal, so in some rare situations I lost connection. I've tried something different now which seems to work much better: connecting the transformer directly to 2 pins configured as LVDS (+ 100Ohm termination resistor). I admit that this is somewhat of a hack, but I'd be happy about your opinion wether it's a really bad one, e.g. if the voltage levels (Vpp = 2.5V) out of the transformer might kill the inputs. thanks, SukandarArticle: 80935
We have a board with 2, Virtex6000 FPGA's that was working fine. Recently the boards stopped working and we saw that one of the FPGA's (lets call this as FPGA 1)was not being programmed. We are using separate bank of serial eeproms to load the FPGA's in master serial mode and they use the default 4 MHz serial clock frequency. I checked the bit file in the eeproms and found that they passed the read/verify test using JTAG. But the FPGA would not load. Then I generated another eeprom file with 8 MHz serial clock frequency. The FPGA 1 magically started to work. Then when I tried loading the old file(4 MHz serial clock) it failed. Went back to 8Mhz it worked fine. Went back to 4MHz, it started working again and since then it has not failed. In all probablity there is nothing related to the frequency of loading the bit stream. Maybe the board is flaky in terms of layout and power supply, de-coupling etc... Did anybody else have any such experiences? On a side note, on a new batch of these boards the other FPGA (FPGA 2) frequently fails to load, while the FPGA 1 does not show any problems. Out of 5 boards fabricated 4 of them fail and only one board works fine. This was first board with FPGA and large BF957 package for the engineer and the PCB layout person. Did they miss something? This board is a PCI card. The 3.3V from the PCI bus is directly used as VCCIO and for VCCint there is a voltage regulator. Is there a problem in using 3.3v directly from a standard PC motherboard to power the FPGA I/O? What could such a behaviour be attributed too? Any pointers would be helpful. Thanks. BrijeshArticle: 80936
"Eric Smith" <eric@brouhaha.com> wrote in message news:qhoedmj5se.fsf@ruckus.brouhaha.com... > "Alexei A. Frounze" <alexfru@chat.ru> writes: > > I don't see where it's unreliable. The majority tells the final value. Your > > "slightly", which is about 1/16th of the bit duration isn't going to make it > > unreliable so badly. > > Sorry, I misread your statement. Majority voting all 16 samples would > probably be OK, though it would be a little less reliable than majority > sampling only near the center of the bit time. If the noise happens to invert two of the middle samples... I think better would be to have more than 3 and less than 16 to drop the boundary effects and count on more samples. 8? > It's still the case that I've never heard of a UART using more than > three samples near the center of the bit time, and most only use one. No problem here. AlexArticle: 80937
Repzak wrote: > Hej > > anyone who easily can tell me wich prom i have to add on this board : > http://www.coreworks.pt/basicboard.htm > > I would like the prom to be big enough to contain so much data as i can use > all the "space" in the fpga.. spartan2 300k > > i used just to upload, but have to use it to a school project and i want to > order the prom's in a good time before i have to use them > > thanks > > -- > Mvh Kasper It's hard to tell from the documentation what sort of PROM you need. If it is in an 8-pin DIP package you may be out of luck, since the 2 Megabit parts don't come in this package. Check out Atmel's site for AT17Fxxx flash-based or AT17LVxxx EEPROM parts.Article: 80938
Have you opened a case with our hotline? It appears you are getting into some strange state between on, and off. The devil is in the details, and working directly with the hotline is your best bet to resolve it. Austin lecroy7200@chek.com wrote: > Jim Granville wrote: > >>lecroy7200@chek.com wrote: >> >> >>>Thanks. I read the note and agree that the problem could be > > related to > >>>some kind of transient. If the Done/Program pin were stuck in the > > low > >>>state it appears that the device will still reset by monitoring the >>>state of the Reset pin. >> >>Err, maybe. >> Keep in mind that on many devices, the RESET does NOT reset > > everything, > >>and is more aptly labeled reset request. > > > I am just going by what their data sheet says. From my testing, it > does appear that the part functions this way as well. Not to say that > it has not reached some "safe state" that reset won't shake it loose, > because that appears to be what I am seeing. > > This design has the power down pin tied to VCC, but I broke it out to > test this mode as well. I tried doing some basic DC tests as well as > sweeping RF into the pin, but again was not able to replicate the > problem. > > Yes, I can detect when the problem happens. Power cycling the system > is not an option. Are the Xilinx guys still browsing this group? If > so, any ideas from the masters? I am running out of ideas to try. >Article: 80939
Alexei A. Frounze wrote: > "Eric Smith" <eric@brouhaha.com> wrote in message > news:qhoedmj5se.fsf@ruckus.brouhaha.com... >> "Alexei A. Frounze" <alexfru@chat.ru> writes: >>> I don't see where it's unreliable. The majority tells the final >>> value. Your "slightly", which is about 1/16th of the bit duration >>> isn't going to make it unreliable so badly. >> >> Sorry, I misread your statement. Majority voting all 16 samples >> would probably be OK, though it would be a little less reliable than >> majority sampling only near the center of the bit time. > > If the noise happens to invert two of the middle samples... I think > better would be to have more than 3 and less than 16 to drop the > boundary effects and count on more samples. 8? If you are going to be "smart" about it, you would be better off trying to detect the edges of bits so that you can resynchronize on each edge. What happens if you have 13 bits of noise and the real data in the middle part? Is the UART data defined as the majority of the bits or the value of the data at the sample point? I think if your majority voter is wrong, then you have a severe problem that needs to fixed elsewhere. > >> It's still the case that I've never heard of a UART using more than >> three samples near the center of the bit time, and most only use one. > > > No problem here. > > Alex -- Best Regards, Ulf Samuelsson ulf@a-t-m-e-l.com This message is intended to be my own personal view and it may or may not be shared by my employer Atmel Nordic ABArticle: 80940
> Sorry, I misread your statement. Majority voting all 16 samples would > probably be OK Will be a bad idea if the sampling rate (receiver baud rate) is a bit wrong. -- Maxim Shatskih, Windows DDK MVP StorageCraft Corporation maxim@storagecraft.com http://www.storagecraft.comArticle: 80941
Hmmm. That is not how it is supposed to work. We are looking into this and either I or someone else will get back to you. XST is supposed to catch this but perhaps something strange is happening. -- Brian Marius Vollmer wrote: > Brian Philofsky <brian.philofsky@no_xilinx_spam.com> writes: > > >>[...] >>If you did not use any translate_off / ons in the code, you should >>have seen errors during either XST or NGDBUILD as it would have >>identified the incorrect parameter and properly warned but if those >>are in the code, the tools ignore them as you are instructing with >>those commands. > > > This is not my experience. In the code below, the generic > associations marked with XXX are clearly wrong but go unnoticed. > > Also, I was unsuccessful in setting the "PERIOD" attribute from VHDL > (also marked with XXX in the code). Xst says: > > Timing constraint: NET clkgen_clk_100_buf PERIOD = 10 nS HIGH 5 nS > > But par does not see this constraint, I think. If I put the > constraint in a .ucf file, then par does see it. Hmmm. > > Thanks a lot, Brian! > > > Here is the code fragment: > > -- clock_generator -- generates deskewed system clocks and handles reset > > library ieee; > use ieee.std_logic_1164; > > library unisim; > use unisim.vcomponents.all; > > use work.common.all; > > entity clock_generator is > > generic ( > clk_var_mult : positive; -- Frequency multiplier for variable clock > clk_var_div : positive); -- Frequency divider > > port ( > -- external connections > clk_100_in : in u1; -- 100MHz Clock from external oscillator > clk_sd_out : out u1; -- 100MHz to SDRAM > clk_sd_in : in u1; -- 100MHz feedback from SDRAM > reset_in : in u1; -- Reset input from switch > > -- global clock and reset > clk_100 : out u1; -- Deskewed 100MHz clock, suitable for the > -- SDRAM controller, for example. > clk_var : out u1; -- Variable frequency clock, see generics. > reset : out u1); -- Reset > > end entity; > > architecture syn of clock_generator is > > signal clk_sd_in_buf, clk_100_deskewed, clk_100_buf : u1; > signal clk_var_unbuf, clk_var_buf : u1; > signal locked : u1; > > attribute period : string; > attribute period of clk_100 : signal is "10 ns"; -- XXX - no effect > attribute period of clk_var : signal is "40 ns"; -- XXX - no effect > > begin > > -- The 100MHz clock is directly routed to the SDRAM. The clock for > -- internal logic is deskewed with respect to the clock coming back > -- from the SDRAM. > > clk_sd_out <= clk_100_in; > > inbuf: IBUFG > port map ( > i => clk_sd_in, > o => clk_sd_in_buf); > > deskew: DCM > generic map ( > clkfx_mult => clk_var_mult, -- XXX - no error for this > clkfx_div => clk_var_div, -- XXX - no error for this > hi_xst_how_is_your_day => 0, -- XXX - no error for this > clkin_period => 10.0) > port map ( > rst => reset_in, > clkin => clk_sd_in_buf, > clkfb => clk_100_buf, > clk0 => clk_100_deskewed, > clkfx => clk_var_unbuf, > locked => locked); > > buf_clk_100: BUFG > port map ( > i => clk_100_deskewed, > o => clk_100_buf); > > buf_clk_var: BUFG > port map ( > i => clk_var_unbuf, > o => clk_var_buf); > > clk_100 <= clk_100_buf; > clk_var <= clk_var_buf; > reset <= not locked; > > end syn; >Article: 80942
On 14 Mar 2005 08:28:33 -0800, lecroy7200@chek.com wrote: >Thanks. I read the note and agree that the problem could be related to >some kind of transient. If the Done/Program pin were stuck in the low >state it appears that the device will still reset by monitoring the >state of the Reset pin. The key word in my previous article is "transient", as in maybe only for a microsecond or two. This corrupts an internal state machine, and the illegal state is something like "house cleaning complete", "configured" (which is no longer true), and "done" pin low (caused by "house cleaning complete"). As the done pin is an open drain signal, if the FPGA is pulling it low, then it cant tell if you are pulling it low out side as well. It needs for the FPGA to release this signal, and an external resistor to pull it up, before it can recognize an external pull down of this signal. >As a test, I forced the Prog pin low on one device in the chain. The >pin latches low as expected. I then forced a few clock cycles to get >the device into some mid data stream mode. I then pulled the reset low >and started a normal configuration. The part did recover, releasing the >Prog. pin at the end of the programming cycle. So, at least this all >seems to work. Yep. >My next step is to conduct noise onto the supply to see if I can >replicate the problem. Because this happens so infrequent, it is next >to impossible to find any other clues. >I tried a few different tests. I first reduced the supply votage on >the Xilinx devices by 500mV and ran the system as normal, but saw no >problems. I then reduced the supply voltage until I started to see >problem with the function of the devices (this was around 3.5 volts), >but as soon as the supply was returned to normal the parts would >function normal as well. Using a bias T I then injected a sinewave >onto the supply line. I ran the supply at 4.5 volts and injected a >500mV signal. I did multiple sweeps from 100KHz up to a bit over a GHz >and saw no problems. I then ran the same test with the supply at 5 >volts and again saw no problems. > >So far, it would appear the problem is not related to the supply >voltage or operating temperature. You haven't tried something like I have suggested. Try and have the power sitting at 5V, and pulse it low to 3V or 2.5V for 1 to 2 microseconds, then back high for much longer time (seconds). The problem I seem to remember is that the narow pulse is recognized by the voltage level detector in the FPGA, which starts the house cleaning, that wipes the config memory, but the 6uS filter stops the power glitch from being detected by the reconfiguration logic. The problem with the sinewave is that when it goes low it does so for too long to trigger the brownout problem. I am still fairly sure this is a powersupply transient problem. Philip Philip Freidin FliptronicsArticle: 80943
Jezwold wrote: > I would say that everyone else seems to manage in producing working > designs without rewritting either vhdl or verilog,niether of them are > meant to be a 'programming language' so aproaching them from the point > of view of a programmer isnt the best way of looking at them. Verilog and VHDL both tries to be many things at the same time, but at the core are specification languages. Programming languages are a special class of specification languages. That old "It's not a PL" is getting old as an excuse of either. Any decent first year student of programming languages looking at either would recognize many obvious deficiencies. VHDL is excessively verbose and it's much praised type safety is designed in a way that forces way too many explicit type casts. Verilog (which I know far better) is less verbose but is often too loose with what it allows. It's a mix of two models, schematic and behavioral, but it's impossible for any non-trivial design to be purely behavioral as the abstraction unit (the module) must be instantiated as a component and attached to wires and registers. I've witnessed HW development at a Silly Valley startup and observed how Verilog was mostly used as assembly, generated by big (and IMO nasty) perl scripts. I take that as a statement to the fact that we need something better. Tommy PS: For a certain class of problems, I like my own variant of Timogriffer-C: Hard-C (http://not.meko.dk/Hacks/hacks.html).Article: 80944
Hello all. I am interested in learning about FPGAs but don't know much about where to start. Should I get Xilinx FPGA starter kit? Would that be helpful for taking me by the hand and going through the basics? Are there any other things a beginner should be aware of? Please advise. ThanksArticle: 80945
One of the things you should consider is what type of systems or devices you want to design. Develop a list of requirements and identify what devices meet them. Altera and Xilinx offer limited editions of their software that you can download for free from their web sites. See which one you have a preference for. As for languages it is either Verilog or VHDL. Again it is a matter of personal preference or project requirements. You might search Amazon to see what books are available and reviews people have left. I bought an Altera Stratix II Kit because of features. But to get started XESS (www.xess.com) has the lowest price kits with software. DerekArticle: 80946
Do you have a project in mind or do you just want to get started? I agree with Derek that if you have a project in mind, then you should develop a list of requirements and identify what devices meet them. If you just want to get started, then you can buy an FPGA starter kit such as Spartan3 Starter Kit from Xilinx. Start SIMPLE, by building for example a 2 input AND gates. See if you can get the output right with 2 input switches and 1 LED output. Then build something slightly more complicated, such as an adder. You can learn by progressively increasing the complexity of your design. You don't need to know FPGA architecture in order to use it. You just need to know how to identify and use the I/O pins. And you don't need to know HDLs either. You can use Schematics if you want. HendraArticle: 80947
Hi, I am trying to design a non-coherent DPSK demodulator as part of my RX chain of a DSP system in verilog. I have to target my design on a Vertex-4 development board (for prototyping purposes). Till now, I have designed my RX chain using two multiplier cores (I and Q multiplied with their delayed versions) and an adder core ((In)*(In-10) + (Qn)*(Qn-10)). When I simulate my design at the behavioural level everything's working fine. I synthesize my design, no warnings/ INFO/ errors. But, when I do a post-translate simulation, my Q-channel multiplier stops working. Moreover, when I MAP my design and do a post-map simulation, the design does not work at all. I get no warnings or errors in any of the processes Can anyone help me. If someone decides to be gracious, I can send you my archived project to look at. I have had this problem in the past and couldnt solve it. It may be my test-bench (as it is very simple)...but i just can figure it out. Any help will be appreciated....i am on a schedule and would like to keep my job....Lrd have MERCY!!! Thanks MORPHEUSArticle: 80948
The serial PROM required depends on the configuration bits of the FPGA. Just look at the datasheet of the FPGA, you will come to know the configuration bit required, from which you can choose the serial prom required. The serial PROM required is also specified in the datasheet. Go through the datasheet. Regards PraveenArticle: 80949
Altera includes the Design Space Explorer (DSE) along with Quartus II. I have found this tcl script to be very helpful when I can get it to work for me. But lately, it has been very frustrating because it fails to explore the space I set it up to explore. Has anyone else seen this behavior? - I set up the exploration space in the DSE GUI, for example, to do a seed sweep. - DSE starts by running a compilation flow on the base. - DSE finishes this and archives the results. - DSE stops and displays a message that there are no errors or warnings. It doesn't go on to the next point in the exploration space. I have also tried this with the distributed computing option. DSE will create archives, one for each exploration point. It then submits one to a remote computer and fails to actually compile it, and the process ends. If you have seen this behavior, do you know what could be causing it and how to correct it. I have not found any references to this problem in the archives and haven't received much help yet from the Altera support group, but I am hoping this is forthcoming. I am running with the Windows XP operating system (also tried Windows 2000) and using the latest version of Quartus II (4.2 SP1). I have used DSE successfully, so it doesn't always display this behavior. Thanks in Advance, Doug
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