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
Hallo, reading XST user guide it seems that it's not possbile to implement a rom into a cpld, so I have made some experiment with the following code and ISE has compiled everything without reporting errors. I don't have a real cpld to program, so I would ask if it can function before buying it. type rom_type is array (359 downto 0) of std_logic_vector (15 downto 0); signal ROM : rom_type:= ( X"200A", X"0300", X"8101", X"4000", X"8601", X"233A", X"0300", X"8602", X"2310", X"203B", X"8300", X"4002", X"8201", X"0500", X"4001", X"2500", X"0340", X"0241", X"4002", X"8300", X"8201", X"0500", X"8101", X"0602", X"4003", X"241E", X"0301", X"0102", X"2122", X"2021", X"0301", X"0102", X"2222", X"4001", X"0342", X"232B", X"0900", X"0302", X"0102", X"4002", X"0900", X"8201", X"2023", X"0303", X"2433", X"0301", X"4004", X"0301", X"1002", X"2137", X"2036", X"0301", X"0102", X"2237", X"4004", X"0304", X"4040", X"2500", X"2500", X"2500", X"200A", X"0300", X"8101", X"4000", X"8601", X"233A", X"0300", X"8602", X"2310", X"203B", X"8300", X"4002", X"8201", X"0500", X"4001", X"2500", X"0340", X"0241", X"4002", X"8300", X"8201", X"0500", X"8101", X"0602", X"4003", X"241E", X"0301", X"0102", X"2122", X"2021", X"0301", X"0102", X"2222", X"4001", X"0342", X"232B", X"0900", X"0302", X"0102", X"4002", X"0900", X"8201", X"2023", X"0303", X"2433", X"0301", X"4004", X"0301", X"1002", X"2137", X"2036", X"0301", X"0102", X"2237", X"4004", X"0304", X"4040", X"2500", X"2500", X"2500", X"200A", X"0300", X"8101", X"4000", X"8601", X"233A", X"0300", X"8602", X"2310", X"203B", X"8300", X"4002", X"8201", X"0500", X"4001", X"2500", X"0340", X"0241", X"4002", X"8300", X"8201", X"0500", X"8101", X"0602", X"4003", X"241E", X"0301", X"0102", X"2122", X"2021", X"0301", X"0102", X"2222", X"4001", X"0342", X"232B", X"0900", X"0302", X"0102", X"4002", X"0900", X"8201", X"2023", X"0303", X"2433", X"0301", X"4004", X"0301", X"1002", X"2137", X"2036", X"0301", X"0102", X"2237", X"4004", X"0304", X"4040", X"2500", X"2500", X"2500", X"200A", X"0300", X"8101", X"4000", X"8601", X"233A", X"0300", X"8602", X"2310", X"203B", X"8300", X"4002", X"8201", X"0500", X"4001", X"2500", X"0340", X"0241", X"4002", X"8300", X"8201", X"0500", X"8101", X"0602", X"4003", X"241E", X"0301", X"0102", X"2122", X"2021", X"0301", X"0102", X"2222", X"4001", X"0342", X"232B", X"0900", X"0302", X"0102", X"4002", X"0900", X"8201", X"2023", X"0303", X"2433", X"0301", X"4004", X"0301", X"1002", X"2137", X"2036", X"0301", X"0102", X"2237", X"4004", X"0304", X"4040", X"2500", X"2500", X"2500", X"200A", X"0300", X"8101", X"4000", X"8601", X"233A", X"0300", X"8602", X"2310", X"203B", X"8300", X"4002", X"8201", X"0500", X"4001", X"2500", X"0340", X"0241", X"4002", X"8300", X"8201", X"0500", X"8101", X"0602", X"4003", X"241E", X"0301", X"0102", X"2122", X"2021", X"0301", X"0102", X"2222", X"4001", X"0342", X"232B", X"0900", X"0302", X"0102", X"4002", X"0900", X"8201", X"2023", X"0303", X"2433", X"0301", X"4004", X"0301", X"1002", X"2137", X"2036", X"0301", X"0102", X"2237", X"4004", X"0304", X"4040", X"2500", X"2500", X"2500", X"200A", X"0300", X"8101", X"4000", X"8601", X"233A", X"0300", X"8602", X"2310", X"203B", X"8300", X"4002", X"8201", X"0500", X"4001", X"2500", X"0340", X"0241", X"4002", X"8300", X"8201", X"0500", X"8101", X"0602", X"4003", X"241E", X"0301", X"0102", X"2122", X"2021", X"0301", X"0102", X"2222", X"4001", X"0342", X"232B", X"0900", X"0302", X"0102", X"4002", X"0900", X"8201", X"2023", X"0303", X"2433", X"0301", X"4004", X"0301", X"1002", X"2137", X"2036", X"0301", X"0102", X"2237", X"4004", X"0304", X"4040", X"2500", X"2500", X"2500" ); signal addr : std_logic_vector(8 downto 0); begin Rom_Proc : process ( Clk ) is begin if ( rising_edge(Clk) ) then if ( Reset = '1' ) then addr <= (others => '0'); do <= (others => '0'); else addr <= addr + 1; do <= ROM(conv_integer(addr)); end if; end if; end process; Thanks, MarcoArticle: 129101
On Thu, 14 Feb 2008 10:01:19 -0000, "Symon" <symon_brewer@hotmail.com> wrote: >Allan Herriman wrote: >> A couple of years ago I would have said that XFP was the only 10Gb/s >> serial interface to use; now I would consider SFP+, as SFP+ will >> probably be much cheaper than XFP over the lifetime of products >> currently being designed. >> >> Regards, >> Allan > >Hi Allan, >Thanks for your post. Have you used SFP+ yourself yet? I'd be interested to >hear your opinions and experiences. >Thanks, Symon. No, I haven't used it yet, but I would consider it for future 10Gb/s products. I think we're just at the cusp. SFP+ Ethernet switches are available from some of the smaller switch manufacturers. I predict within a year or two, HP, Cisco, etc. will have matching products. Then the prices for the more common optics (e.g. 10km 1310nm) will drop. Some of our customers want 1550nm optics with 80km reach. That's possible (but expensive) in XFP, but I don't think it's available at all in SFP+ yet. Disclaimer: this is all conjecture on my part. Regards, AllanArticle: 129102
Marco T. wrote:
> Hallo,
> reading XST user guide it seems that it's not possbile to implement a
> rom into a cpld, so I have made some experiment with the following
> code and ISE has compiled everything without reporting errors.
>
> I don't have a real cpld to program, so I would ask if it can function
> before buying it.
There is no hardware reason, why it shouldn't work, but most of the time
CPLDs are smaller, so try to compile it for your CPLD to be sure it fits
into the device.
BTW: Xilinx has some templates for ROM, RAM etc. If the (pure VHDL) code
looks like the template, in FPGAs it is synthesized as BRAM. I've seen it
somewhere on the Xilinx site.
For a CPLD maybe you can save some LUTs, if you don't clock your ROM, e.g.
like this:
process
begin
case address is
when "0000" => q <= "100";
when "0001" => q <= "101";
...
when others => q <= "000";
end case;
end process;
For a FPGA it would require more LUTs, if it can't be optimized in BRAMs.
--
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Article: 129103
when others => LEDs <= not LEDs;
might be an interesting check that something is happening...
Article: 129104Hello all, Is MicroBlaze 7.0 compatible with Virtex-II Pro devices? XPS 9.2.02 doesn't seem to offer it as an option, but I haven't found any documentation which confirms specifically one way or the other whether support exists or is planned for the future. [The rest of this message is just what I *have* manage to find; the short answer is "nothing conclusive".] The Xilinx press release for XPS says "XPS 9.2 supports MicroBlaze and PowerPC processing design for Virtex-5, Virtex-4, Virtex-II Pro, and Spartan(TM)-3 FGPAs." -- this seems to imply that it supports MicroBlaze on Virtex-II Pro, though obviously it can't support PPC on V5 or S3... The microblaze sell sheet only mentions Virtex-5, Virtex-4, and Spartan-3 as target families, though it doesn't explicitly exclude any others. None of the technical documentation (like the Reference Manual) mentions which families MicroBlaze is supported on or for which families support is planned. I've had a look through the Xilinx website and forums, and searched the comp.arch.fpga archive, and found nothing.Article: 129105
Hello, I have programmed the 2 cascaded xilinx-PROMs of my development board with incorrect files (.mcs files). What I have actually done is program prom1 with the .mcs file that should go to prom2 and the other way around... :-) The two files contain one configuration for the FPGA. What happened is that eventually the fuse of the board was burnt.. I have replaced with a new fuse and want to reprogram the Proms with valid files in the right way. So, my question is: how can I do this without the FPGA getting programmed at power-up. I want to power-up the board, program the PROMs with Impact and then allow the fpga to get configured by the PROMs. I am working on the Avnet Xilinx V2pro evaluation board with one XC2VP7 FPGA and 2 XC18V04 proms. Thank you in advance guys! GeorgeArticle: 129106
Hi Syms - Great questions. I have only second-hand information from the board designer, but some answers below. "Symon" <symon_brewer@hotmail.com> wrote in message news:fp137v$pol$1@aioe.org... > > How do you know the I/P pad failure is short to VCCO? Ohmmeter, probing from Phy pins. Impossible to isolate the short with both parts still mounted. So there's an assumption that the FPGA input was more likely to fail than the Phy output, and that the short is not on the PCB itself. Both boards worked normally for some period of time (weeks) before the failures occurred. > Did each board failed the same single FPGA pin? Yes. If you buy the overshoot theory then you can hypothesize that there is something about that trace (for example length) that exacerbates the overshoot. If you don't buy the overshoot theory then it seems quite a coincidence that the same pin failed on both boards. > You've got a ground plane, right? Yes, several. It's a 12-layer board. > What's the rise time of the signals? Don't know, but it's 125MHz DDR, so must be in the 1ns or less neighborhood. > Did replacing the FPGA on the board fix the problem? Hasn't happened yet. > How did your mate measure the overshoot? (I.e. can he work a high speed > 'scope properly?) He knows what he's doing, but no high-speed scope, and he did not put a lot of effort into the analysis (locked onto the overshoot theory). Plus he can only probe at the Phy, which is the opposite end of the trace from the FPGA. With a fast driver and a 2" unterminated trace there will certainly be some nice overshoot, but may not be 500mV. > Does he wear an earth strap or nylon pants when probing? (Ahem!) Hell if I know! > Any 12V traces nearby on the board that a probe can short to these signal > lines? Nope. > Have you tried simulating with Hyperlynx or somesuch? It's available, but no. > Did you ask Xilinx to take a look at the broken parts? Suggested it, but no. > Are the two failures from the same batch? Not certain but highly likely. > Are you sure the 2.5V power supply can't overvoltage? Unlikely. It's a TI switcher with soft start. 2.5V regulated off 3.3V. 3.3V regulated off 9V. Thanks for taking the time to respond! RobArticle: 129107
On Thu, 14 Feb 2008 06:15:26 -0600, "RCIngham" <robert.ingham@gmail.com> wrote: >>I would like to know if a FPGA is suited for this application: sound >>sources localization and separation. The algorithm comes in 3 steps: >>sources detection using a steered beamformer (in frequency-domain), a >>particle filter to track the sources and a combination of a geometric >>source separation algorithm and a non-linear post-filter for source >>separation. >> >>Also, the audio stream comes from an array of 8 microphones, and all >>possible microphone pairs must be considered during the detection >>phase. >> >>This algorithm is already implemented of a floating point DSP and I >>would like to know if a FPGA could be a good choice to improve >>performance. > >What aspect(s) of "performance" are you trying to improve? > >> >>I heard that a FPGA wouldn't beat a DSP in floating point calculation, >>what do you think about that? Still, I know that an implementation on >>a FPGA will require a lot of work to translate the code anyway, so I >>suppose it wouldn't be harder to rethink it directly in fixed point. > >Mostly true. FPGAs with hardware multipliers are essentially fixed-point, >but can be extended to floating-point with sufficient "skill in the art". >But if the algorithm will run fine on a fixed-point DSP, that might >improve "performance" enough, anyway. > One advantage of FPGAs is you can tailor data paths to be exactly the right width for your application - this may reduce the need for FP. Wider fixed-point woudl also have the advantage of better accuracy than FP of the same size.Article: 129108
On Thu, 14 Feb 2008 06:51:06 -0800 (PST), "Marco T." <marcotoschi@gmail.com> wrote: >Hallo, >reading XST user guide it seems that it's not possbile to implement a >rom into a cpld, so I have made some experiment with the following >code and ISE has compiled everything without reporting errors. ROM is not a very efficient use of CPLD resources, but will work within teh size limitations. However be aware that as the synthesiser may be converting your ROM data into hardwired logic, it is quite likely that if you change the ROM data, it may no longer fit, or the timing may change significantly. Your data has a large proportion of 0 bits, and so is probably more amenable to ROMMing in a CPLD than the same amount of random data.Article: 129109
"AugustoEinsfeldt" <aee@terra.com.br> wrote in message news:7189d166-519f-4a9d-9df6-18541918ab0b@e23g2000prf.googlegroups.com... > Hi Rob, > Like Symon had quoted you have to provide more information, like: > - Are the affected pins nearby to 2.5V pins or traces? I have seen > board short circuit that happens only after assembly process due to > thermal or mechanical stress. > - Are you sure it is not related to board assembling process? > - Did you extracted the Phy or FPGA to know which device is causing > the short to 2.5V? > - If the short doesn't happen in the moment the board is energyzed how > long it takes to happen? Does the board/device increase in temperature > before it happens? > - Freezing the board changes the behavior? > - Only when all possible board related causes can be discarded then > the stress could be reason and only then the talk about overshoot or > silicon behavior should arise. > > Good luck, > -Augusto Hi Augusto - Can't rule out board/assembly issues, but both boards did work for a period of weeks (not constant use). No parts were removed to isolate the short. The short was "assumed" to be in the FPGA pad. Not very thorough, but this project is crunched for time and budget. Poor excuse, but reality. And I have limited control. Neither of these boards was run in the temperature chamber. Thanks for the thoughtful questions. I'll post back if we get this definitively resolved. RobArticle: 129110
On Feb 14, 7:58 am, Philip Potter <p...@doc.ic.ac.uk> wrote: > Is MicroBlaze 7.0 compatible with Virtex-II Pro devices? XPS 9.2.02 > doesn't seem to offer it as an option, but I haven't found any > documentation which confirms specifically one way or the other whether > support exists or is planned for the future. microblaze is entirely soft so it works on any xilinx fpga. but why would you want to use a 100mhz microblaze instead of a 300mhz powerpc? (or do you want to use an xc2vp2?) alan nishiokaArticle: 129111
Philip, In the Microblaze users guide http://www.xilinx.com/ise/embedded/mb_ref_guide.pdf page 94, it details how any device listed is supported (by 7.0), and V2 Pro is on that list. Additionally, many statements are made that old code may be run on the new core (full backward compatibility is assured). The latest released version is the one suggested for any new application (as is the general policy for all cores, software, and IP). Is there a specific concern you have? AustinArticle: 129112
On Feb 13, 8:00=A0pm, "RobJ" <r...@abc.net> wrote: > Out of a lot of 12 boards we've had two now that have experienced input pa= d > failures (shorts to VCCO). These are LVDCI_25 IBUFs with VCCO =3D 2.5V. Th= ey > are being driven by 2.5V LVCMOS output buffers from a Marvell Phy (RGMII > interface). The Phy and Virtex-4 I/O are powered by the same 2.5V supply. > The traces are in the 1.5" to 2" range and are unterminated. The engineer > responsible for the board suspects overshoot, and says he has observed > overshoot of up to 500mV on these lines (which happens to be the absolute > max for Virtex-4 2.5V inputs). > > These traces and pins are not exposed so ESD is almost impossible as a cau= se > of the failures. The Virtex-4 inputs are pretty beefy (well protected), an= d > I personally have never seen an input buffer fail on any IC due to oversho= ot > from a compatible driver (as opposed to being overvoltaged by an > incompatible driver). So I have my doubts about overshoot causing the > failures and want to make sure we understand this before building more > boards. The current plan for the respin is to add series terminators to da= mp > the signals. Even if the problem was not overshoot, the resistors are a go= od > idea. I'm just looking for ideas and experiences on this. > > Thanks, boys (and girls!). > > Rob You say your input is LVDCI_25 and unterminated. To me, this is conflicting information. Isn't the LVDCI_25 explicitly internally terminated by the DCI termination scheme applied to that pad? I know what DCI is capable of but despite being "ready" for DCI in a design or two, I've never used it so I don't have the practical experience of configuring those input terminations. Another question for the system if the DCI input termination is present: how much drive is required by the PHY and is it happy to deliver that power? It's certainly a quandry. - John_HArticle: 129113
Hi, The case process needs to have 'Count' in the sensitivity list. Also, RST is not needed there, and this is a combinatorial mux. HTH -P@ rossalbi wrote: > hi, i have writen a pice of code which should impliment a value on > the > LEDs of my FPGA development board as the signal 'count' increases. > However it is going strait to the ' when others => LEDs <= > "00000000"; > ' value. > > any help would be much appreciated... > > > -- Declare signals > signal CLK : std_logic; > signal RST : std_logic; > signal Count : std_logic_vector(21 downto 0); > signal LEDs : std_logic_vector(7 downto 0); > signal LEDVal : std_logic_vector(7 downto 0); > signal Dir : std_logic; > > > begin > > > -- Tie unused signals > User_Signals <= "ZZZZZZZZ"; > IO_CLK_N <= 'Z'; > IO_CLK_P <= 'Z'; > IO <= (0=>LEDs(0), 1=>LEDs(3), 41=>LEDs(4), 42=>LEDs(1), > 43=>LEDs(4), > 44=>LEDs(5), 45=>LEDs(2), 46=>LEDs(7), > others => 'Z'); > > > -- Clock divider > process (CLK, RST) > begin > if (RST='1') then > Count <= (others=>'0'); > elsif (CLK'event and CLK='1') then > Count <= Count + 1; > end if; > end process; > > > process (CLK, RST) > begin > > > case Count is > when "0000000000000000000000" => LEDs <= "00000001"; > when "0000000000000000000001" => LEDs <= "00000010"; > when "0000000000000000000010" => LEDs <= "00000100"; > when "0000000000000000000011" => LEDs <= "00001000"; > when "0000000000000000000100" => LEDs <= "00001001"; > . > . > when "0000000000000001111110" => LEDs <= "01000000"; > when "0000000000000001111111" => LEDs <= "10000000"; > > > when others => LEDs <= "00000000"; > end case; > > > end process; > >Article: 129114
austin wrote: > Philip, > > In the Microblaze users guide > > http://www.xilinx.com/ise/embedded/mb_ref_guide.pdf > > page 94, it details how any device listed is supported (by 7.0), and V2 > Pro is on that list. (I think you mean page 91?) Thank you! I had seen that, but it didn't quite register the first time. > Additionally, many statements are made that old code may be run on the > new core (full backward compatibility is assured). > > The latest released version is the one suggested for any new application > (as is the general policy for all cores, software, and IP). > > Is there a specific concern you have? As I said, XPS 9.2.02 doesn't seem to let me instantiate a MicroBlaze when my project is set for xc2vp30; I took this to mean MicroBlaze is not available for that device family. It seems though I can work around this by changing to V4, instantiating microblaze and changing back again. FWIW, I'm interested in Microblaze as part of a research project into automated design of DSP circuits, and I'm investigating what situation (if any) Microblaze would be an appropriate solution. I have an XUP board with an xc2vp30 so it would be nice to be able to target this. PhilArticle: 129115
Marco T. wrote: > Hallo, > reading XST user guide it seems that it's not possbile to implement a > rom into a cpld, They probably mean in the native hardware. You can certainly do small tables, they just get packed into product terms/macrocells. > so I have made some experiment with the following > code and ISE has compiled everything without reporting errors. If it compiled without errors, then it should be OK. You will get 'Unable to FIT' type messages if it faile. So look at the fitter report file, to see the product term usage per output. > > I don't have a real cpld to program, so I would ask if it can function > before buying it. > > > type rom_type is array (359 downto 0) of std_logic_vector (15 downto > 0); Always a good idea to start with a small example, to verify the flow and constructs, and then expand it. If speed is not critical, you can use a CPLD+SerialEEPROM as a Serial ROM/parallel output. -jgArticle: 129116
Not true! How you describe the logic in HDL greatly influences the gate resources. Yes the two implementations will function identically. I have verified this with random vectors and assertions. Both implementations behave the same. The difference comes when you map to gates. The case statement In theory should produce a fast result at the expenses of how the number of gates. Where as the div/mod version makes use of cascading to reduce the logic at the expense of speed. It is the same with descriptions of n-bit adders. You can code it with a+b, and let the Synthesizer do what ever it wants. Or you can describe the final layout type explicitly. Example: You need lower gate count and don't care about speed. You would cascade the full-adders giving you n*(2 gate delay), If you want speed but don't care about gates you code a Carry-Look ahead adder where the delay is fixed at (6 gate delay) but the logic gate count grows exponentially. Synthesizers do not take the final functionality and map the logic the same way. They can do that with the right switches. But by default they will look at your coding style to determine the way to map the logic. In the case statement was expaned up to 64 bit -binary to 19 BCD. You would find a very large difference in resource requirements for the logic vesus the div/mod method. "nospam" <nospam@please.invalid> wrote in message news:v3f6r3lrakmjbpqdh76nnpd6r0jts5230p@4ax.com... > "Dwayne Dilbeck" <ddilbeck@yahoo.com> wrote: > >>Don't try it. XST will complain that the second operand of DIV and MOD >>operators have to be powers of two, atleast, in the webpack version. >> >>I ran your code and the below code through the Cadence HDL-ICE >>synthesizer. >>(For Emulation only) The case statement was mapped to 188 cells in thier >>library, the DIV/MOD mapped to 92 cells. (AND02,OR02,XOR02,INV,etc.) >> >>But since this code doesn't work in the free ISE it doesn't matter. >> >>module bcd(ibin, bcd2,bcd1,bcd0); >> >> input [7:0] ibin; >> output[3:0] bcd2, bcd1, bcd0; >> >> wire [7 : 0] temp [0:1]; >> >> assign temp[0] = ibin/4'd10; >> assign bcd0 = ibin%4'd10; >> assign temp[1]= temp[0]/4'd10; >> assign bcd1 = temp[0]%4'd10; >> assign bcd2 = temp[1]%4'd10; >> >>endmodule > > This is static logic, each output is defined by a logical equation > containing inputs. Regardless of how you express it in HDL the equations > are the same and the synthesiser should minimise and fit them just the > same. > > Shitty that your synthesiser didn't, assuming you really did express the > same thing in different ways. > --Article: 129117
Philip, Let me check. Might be a bug. AustinArticle: 129118
Hi, I am using the Xilinx ISEWebPack 8.1i together with a Spartan 3 Starter Kit (Digilent, bought from Xilinx). Now, from time to time I get an error message about failed program download to the FPGA from the Xilinx download tool. The procedure I use for download is always the same: generate .bit file, Initialize chain (first select .bit for the Spartan, then bypass the PROM), then right click on the Spartan Icon, select "Program". Mostly then, "Success" is signaled, but, seemingly randomly, "Failed" is returned as a big red warning sign. In these cases I usually reset to the PROM-configuration and try the cycle beginning with Init-Chain above again, sometimes I shorten it to just doing the "Program" with right-click-select. After a couple of tries, this seemed to work at all times. Now my question: What is the reason of these errors? Are they just random mishaps or can they be caused by errors in my design? Are especially timing errors in the design a possible source of download errors? (I ask this last question, because I have just completed a little state machine, that lets my processor interact with the SRAM as if it were synchronous. I used what I thought was a conservative and safe design with comfortable timing margins, but afterwards had two paths with 2.7ns "slack?" on a 10ns clock. As I inspected the paths in the post PAR timing analyzer, they seemed to me falsely analyzed and I decided to make a .bit file and download anyway. Superficially it seems to work (my cpu is correctly executing an endless loop writing to screen and copying memory blocks in the SRAM) but first I got repeatedly these "programming failed" messages, chance?). Thanks in advance for all answers! Jürgen -- Jürgen Böhm www.aviduratas.de "At a time when so many scholars in the world are calculating, is it not desirable that some, who can, dream ?" R. ThomArticle: 129119
RobJ wrote: > Out of a lot of 12 boards we've had two now that have experienced input pad > failures (shorts to VCCO). These are LVDCI_25 IBUFs with VCCO = 2.5V. They > are being driven by 2.5V LVCMOS output buffers from a Marvell Phy (RGMII > interface). The Phy and Virtex-4 I/O are powered by the same 2.5V supply. > The traces are in the 1.5" to 2" range and are unterminated. The engineer > responsible for the board suspects overshoot, and says he has observed > overshoot of up to 500mV on these lines (which happens to be the absolute > max for Virtex-4 2.5V inputs). You have to look at the amount of energy that can be contained in only 2" of trace. Calculate the worst case inductance and current you can get flowing in such a trace, and see if it can develop a damaging amount of energy. I have REAL doubts that is your problem. JonArticle: 129120
Timing issues are not going to effect the ability to program. Timing issues will cause you to recieve values that you are not expecting inside the design. Are you using the USB or Parrallel cable? A programming error occurs becuase the transmision to the FPGA is corrupted. You could have a bad board where the JTAG header isn't connected well. That would affect transmision and make it sparatic. You could have a faulty programming cable that could make it sparatic. Your USB or Parrallel ports could be sub standard and not sufficient to the task. Try checking those areas. Timing in your desgin will not effect your ability to down load. "Jürgen Böhm" <jboehm@gmx.net> wrote in message news:fp274c$o76$00$1@news.t-online.com... > > Hi, > > I am using the Xilinx ISEWebPack 8.1i together with a Spartan 3 > Starter Kit (Digilent, bought from Xilinx). Now, from time to time I get > an error message about failed program download to the FPGA from the > Xilinx download tool. > > The procedure I use for download is always the same: generate .bit > file, Initialize chain (first select .bit for the Spartan, then bypass > the PROM), then right click on the Spartan Icon, select "Program". > Mostly then, "Success" is signaled, but, seemingly randomly, "Failed" > is returned as a big red warning sign. In these cases I usually reset to > the PROM-configuration and try the cycle beginning with Init-Chain above > again, sometimes I shorten it to just doing the "Program" with > right-click-select. After a couple of tries, this seemed to work at all > times. > > Now my question: What is the reason of these errors? Are they just > random mishaps or can they be caused by errors in my design? Are > especially timing errors in the design a possible source of download > errors? (I ask this last question, because I have just completed a > little state machine, that lets my processor interact with the SRAM as > if it were synchronous. I used what I thought was a conservative and > safe design with comfortable timing margins, but afterwards had two > paths with 2.7ns "slack?" on a 10ns clock. As I inspected the paths in > the post PAR timing analyzer, they seemed to me falsely analyzed and I > decided to make a .bit file and download anyway. Superficially it seems > to work (my cpu is correctly executing an endless loop writing to screen > and copying memory blocks in the SRAM) but first I got repeatedly these > "programming failed" messages, chance?). > > Thanks in advance for all answers! > > Jürgen > > > > -- > Jürgen Böhm www.aviduratas.de > "At a time when so many scholars in the world are calculating, is it not > desirable that some, who can, dream ?" R. ThomArticle: 129121
Jürgen Böhm wrote: > I am using the Xilinx ISEWebPack 8.1i together with a Spartan 3 > Starter Kit (Digilent, bought from Xilinx). Now, from time to time I get > an error message about failed program download to the FPGA from the > Xilinx download tool. Try to set the programming transfer speed to some lower values. This will fix problems with cables, PC parallel ports etc. -- Frank Buss, fb@frank-buss.de http://www.frank-buss.de, http://www.it4-systems.deArticle: 129122
Dwayne Dilbeck wrote: > Timing issues are not going to effect the ability to program. Timing issues > will cause you to recieve values that you are not expecting inside the > design. > > Are you using the USB or Parrallel cable? A programming error occurs > becuase the transmision to the FPGA is corrupted. You could have a bad > board where the JTAG header isn't connected well. That would affect > transmision and make it sparatic. You could have a faulty programming cable > that could make it sparatic. Your USB or Parrallel ports could be sub > standard and not sufficient to the task. I use the so called "Parallel Cable 3" (Digilent JTAG3) (connected to the so called J7 header of the Starter Kit). It can be found as JTAG3 cable on the page http://www.digilentinc.com/Products/Catalog.cfm?Nav1=Products&Nav2=Cables&Cat=Cable As it is advertised as a "low-cost-solution", one could speculate about the cable as the source of the problem - but maybe another reason is, that I left the cable plugged into the board for months and maybe somehow oxidation crept in. > > Try checking those areas. Timing in your desgin will not effect your > ability to down load. > Thanks for this information - it is always a bit difficult for an FPGA hobbyist without academic background in electrical engineering not to fall prey to vague ideas, speculations and misconceptions. Jürgen -- Jürgen Böhm www.aviduratas.de "At a time when so many scholars in the world are calculating, is it not desirable that some, who can, dream ?" R. ThomArticle: 129123
When you download a design into the FPGA, there is no timing analysis being performed. You can download any nonsense design, as long as it is coded right and generates the right CRC check, and has the appropriate number of configuration clock cycles. So you should look elsewhere for the cause of unreliable configuration. One cause could be poor signal integrity of the configuration clock line. Just my $0.02 worth. Peter Alfke Jürgen Böhm wrote: > Hi, > > I am using the Xilinx ISEWebPack 8.1i together with a Spartan 3 > Starter Kit (Digilent, bought from Xilinx). Now, from time to time I get > an error message about failed program download to the FPGA from the > Xilinx download tool. > > The procedure I use for download is always the same: generate .bit > file, Initialize chain (first select .bit for the Spartan, then bypass > the PROM), then right click on the Spartan Icon, select "Program". > Mostly then, "Success" is signaled, but, seemingly randomly, "Failed" > is returned as a big red warning sign. In these cases I usually reset to > the PROM-configuration and try the cycle beginning with Init-Chain above > again, sometimes I shorten it to just doing the "Program" with > right-click-select. After a couple of tries, this seemed to work at all > times. > > Now my question: What is the reason of these errors? Are they just > random mishaps or can they be caused by errors in my design? Are > especially timing errors in the design a possible source of download > errors? (I ask this last question, because I have just completed a > little state machine, that lets my processor interact with the SRAM as > if it were synchronous. I used what I thought was a conservative and > safe design with comfortable timing margins, but afterwards had two > paths with 2.7ns "slack?" on a 10ns clock. As I inspected the paths in > the post PAR timing analyzer, they seemed to me falsely analyzed and I > decided to make a .bit file and download anyway. Superficially it seems > to work (my cpu is correctly executing an endless loop writing to screen > and copying memory blocks in the SRAM) but first I got repeatedly these > "programming failed" messages, chance?). > > Thanks in advance for all answers! > > Jürgen > > >Article: 129124
Jon Elson wrote: > > > RobJ wrote: > >> Out of a lot of 12 boards we've had two now that have experienced >> input pad failures (shorts to VCCO). These are LVDCI_25 IBUFs with >> VCCO = 2.5V. They are being driven by 2.5V LVCMOS output buffers from >> a Marvell Phy (RGMII interface). The Phy and Virtex-4 I/O are powered >> by the same 2.5V supply. The traces are in the 1.5" to 2" range and >> are unterminated. The engineer responsible for the board suspects >> overshoot, and says he has observed overshoot of up to 500mV on these >> lines (which happens to be the absolute max for Virtex-4 2.5V inputs). > > > You have to look at the amount of energy that can be contained in only > 2" of trace. Calculate the worst case inductance and current you can > get flowing in such a trace, and see if it can develop a damaging amount > of energy. I have REAL doubts that is your problem. > > Jon and not just the energy - that +500mV limit is not a damage rating, it is where the clamp diode will start to think about conducting. These devices are rated at 3.3V + overshoot, so the levels to damage oxides, or even clamp diodes, will need a LOT of energy Something else is going on. Have you checked the removed devices, to verify the failures ? -jg
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