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
You may need to update to the latest service pack to 4.2 >From the Altera Quartus site: "All platforms of Quartus II software version 4.1 and 4.1 service pack 1, including the free Web Edition, have an issue in the counter implementation such that when synchronous clear and asynchronous set signals are used, the synchronous clear signal logic is not generated. This issue occurs only when all three of the following conditions occur: 1.. The design targets a Stratix, Stratix GX, Cyclone, MAX II, or HardCopy Stratix device. 2.. The counter uses both synchronous clear and asynchronous set signals. 3.. The counter is explicitly instantiated with the lpm_counter megafunction in Quartus II integrated synthesis or any third-party synthesis software or in a schematic file, or is inferred by Quartus II integrated synthesis. Note: Third-party synthesis tools do not infer the lpm_counter megafunction and users of these tools will not be affected by this issue unless the user explicitly instantiates the lpm_counter megafunction in their VHDL or Verilog code." John Cain, Power Processing, Inc., Phx, AZ - Electronic Design from Concept to Product "pjjones" <hjones1380@hotmail.com> wrote in message news:2e1d5e40.0410211052.58d72a63@posting.google.com... > Hi, > I'm attempting to implement a 12-bit counter from a vhdl file using > the lpm_counter. The output count goes something like this > 125..126..255..128..129 > That is, bit 8 (output[7]) goes high one clock cycle too early. The > same thing happens when bit 9 (output[8]) goes high, this time the > count is as follows: > 251..252..509..510..383..256..257..258 > Once again bit 8 goes high one clock cycle early, and bit 9 changes 3 > cycles early. > > At first, I noticed this and assumed there was a problem in my logic > driving the counter. Using Quartus, I created a new 12 bit counter > using the mega-function wizard and placed it next to my vhdl > component. That counter has the exact same glitch. sclr and sset are > grounded, updown and cnt_en are connected to vcc. The only input is a > clock. Next I completely removed my component, and the counter still > has a glitch in the output. The entire .bdf file is a counter with an > input clock and output lines, the glitch remains. > > Next, I created a new project, re-created a counter, and of course > this one works flawlessly. > > It seems that no matter what I do, I can't make the broken counter > work correctly, nor break the working counter by adding my component > to it. > > Has anyone experienced something similar to this before? Any ideas on > how to fix it?Article: 74926
In theory, it's perfectly fine not to reset a bunch of FF's if you can guarantee that a reset value will ripple through or if you really don't care about a state. In practise, we tend to reset all our FF's (synchronously, though it doesn't really make a difference) and then remove the reset for those FF's for which we can guarantee that it will get a defined state after we toggle the clock for a few cycles while reset remains asserted. We prefer not to have any FFs with an unknown condition when going out of reset. The risk is just to high that we overlook cases where we DO get into an unknown state. Reset behavior is one of the cases for which we still run a gatelevel simulation. As for speed, a case can be made that synchronous reset will eat some of your setup time because it puts an AND port in between the functional logic and the D input. But asynchronous FFs can have slower clock-to-Q times, which may or may not compensate. You'll have to check your datasheet. As for area: there's no fixed rule. Some libraries have FF's where the synchronous reset FFs has the same area as a similar FF without any reset at all. Again, check you databook. FPGA is another story alltogether. Check the other answers. :-) TomArticle: 74927
by the way, thanks for the info, I appreciate it. -PhillipArticle: 74928
I've included some code below that demonstrates the problem I am
having. When I take the vhdl code shown, create a symbol file from it
for Quartus II, then simulate it, there are glitches.
q_out[7] changes 1 clock cycle too early,
q_out[8] changes 2 clock cycles before q_out[7]
q_out[9] changes 4 clock cycles before q_out[8]
etc, etc
Please let me know if you can spot the problem.
-Phillip
-------------------------------------------------------------
LIBRARY ieee;
USE ieee.std_logic_1164.all;
LIBRARY lpm;
USE lpm.lpm_components.all;
ENTITY count_test IS
PORT
(
clock : in std_logic;
updown : in std_logic;
cnt_en : in std_logic;
sclr : in std_logic;
sset : in std_logic;
q : out std_logic_vector(11 downto 0) );
END count_test;
ARCHITECTURE arch OF count_test IS
SIGNAL q_out : std_logic_vector(11 downto 0);
COMPONENT lpm_counter
GENERIC (
lpm_width : POSITIVE;
lpm_modulus : NATURAL := 0;
lpm_direction : STRING := "UNUSED";
lpm_type : STRING := "LPM_COUNTER"
);
PORT
(
clock : IN STD_LOGIC ;
updown : IN STD_LOGIC := '1';
cnt_en : IN STD_LOGIC := '1';
sset : IN STD_LOGIC := '0';
sclr : IN STD_LOGIC := '0';
q : OUT STD_LOGIC_VECTOR (lpm_width-1 DOWNTO 0)
);
END COMPONENT;
BEGIN
q <= q_out(11 downto 0);
lpm_counter12_component : lpm_counter
GENERIC MAP (
lpm_width => 12,
lpm_type => "LPM_COUNTER",
lpm_direction => "UNUSED"
)
PORT MAP (
clock => clock,
updown => updown,
cnt_en => cnt_en,
sclr => sclr,
sset => sset,
q => q_out
);
END arch;
Article: 74929Kenneth Land wrote: > Altera's app note "Designing with FineLine BGA Packages" indicates that it > is ok to route one (or even two!) signals between 1.0mm balls. If you don't mind reading something from the other side of the fence, check the XAPP157 on xilinx web ;-) Also of interest is a paper from motorola, named "PBGAPRES.pdf" probably you can still find it at freescale. I also remember reading something on TIs WEB, as they also use BGA packages with 0.8 mm spacing. Good luck ... P.S. And check your gerber files with a goo editor, before you give them to the pcb house. Specially the solder stop and solder paste masks. My first experience with BGA pretty much was for the trash bin ;-)Article: 74930
Another tidbit: When Xilinx says reset or preset, we really mean that we force the flip-flop into one state or the other. None of that trickery with virtual preset, implemented by reset plus inverting D and Q (which would affect timing). Peter Alfke > From: Peter Alfke <peter@xilinx.com> > Organization: Xilinx,Inc > Newsgroups: comp.arch.fpga > Date: Thu, 21 Oct 2004 11:48:22 -0700 > Subject: Re: Async reset > > While we are on the subject of asynchronous clear or initialization at the > end of configuration: > The problem is the non-synchronous and non-simultaneous timing of the > release of this reset/preset signal, while the user clock is already > running. (Sorry for the convoluted sentence). > That's where state machines can get screwed up: the asynchronous (p)reset > might linger a little longer on one flip-flop than on the other, and the > user clock might occur during this timing difference. Bad luck! > That's why smart designers identify such state machines and give them an > additional, longer and synchronous reset input. An SRL16 is a convenient > tool to control this delay. > This subject has been covered here many times, but it bears repeatung... > Peter Alfke > >> From: Eric Crabill <eric.crabill@xilinx.com> >> Organization: Xilinx, Inc. >> Newsgroups: comp.arch.fpga >> Date: Thu, 21 Oct 2004 10:59:36 -0700 >> To: glen herrmannsfeldt <gah@ugcs.caltech.edu> >> Subject: Re: Async reset >> >> >> Hi, >> >> I hope someone will correct me if I'm wrong on this... >> >> For Xilinx FPGAs, all SLICE flip flops (and some other >> synchronous elements, too, like BlockRAM output registers, >> IOB flops, etc...) are initialized to a known state at >> the end of configuration by an internal, chip-wide async >> reset called GSR, or "global set/reset". It also happens >> to be the case that there's another signal, GTS, or "global >> three-state" that forces all I/O to be three-stated during >> configuration. These signals are not "visible" in the FPGA >> Editor view of the part at any place other than the STARTUP >> component. >> >> If you instantiate specific primitives, like FDC or FDP, >> you are also making a request on how you want these to be >> initialized by GSR (regardless of your use of an additional, >> async user reset). FDC initializes to 0. FDP initializes >> to 1. >> >> If you code stuff like: >> >> reg [1:0] myflop; >> >> always @(posedge clk or posedge init) >> begin >> if (init) myflop <= 2'b10; >> else myflop <= two_bit_whatever; >> end >> >> You have just inferred an FDC and and FDP, both of which are >> initialized by GSR at configuration, and both of which also >> have an asynchronous user control called "init". >> >> For a more detailed look, try implementing the code above, >> and then make a back-annotated netlist using netgen and you >> will see that the simulation model has the init signal >> logically OR'ed with a signal called GSR, located in the >> glbl.v file that you are supposed to use during simulation >> of back-annotated designs. >> >> If you code stuff like: >> >> reg [1:0] myotherflop; >> >> always @(posedge clk) myotherflop <= two_bit_whatever; >> >> You have just inferred two generic D flip flops, probably >> FD components, and even though you don't have an asynchronous >> user control on this, it will get initialized once at the >> end of configuration, by the GSR signal. I believe FD will >> default to 0, unless you specify otherwise. >> >> If you repeat the exercise using netgen, you will see that >> GSR is still used as an async reset, but there's no other >> signal OR'ed with it. >> >>> The synthesis often moves inverters around, and many signals, >>> including ones through FF's, are actually the inverse of the >>> expected signal. >> >> I would hope anyone doing this transformation would also change >> the "initialization state" of the flip flop when they also change >> it's sense -- otherwise the transformation is not really >> transparent... (I would argue it's wrong) >> >> Eric >Article: 74931
Peter Alfke wrote: > While we are on the subject of asynchronous clear or initialization at the > end of configuration: > The problem is the non-synchronous and non-simultaneous timing of the > release of this reset/preset signal, while the user clock is already > running. (Sorry for the convoluted sentence). > That's where state machines can get screwed up: the asynchronous (p)reset > might linger a little longer on one flip-flop than on the other, and the > user clock might occur during this timing difference. Bad luck! > That's why smart designers identify such state machines and give them an > additional, longer and synchronous reset input. An SRL16 is a convenient > tool to control this delay. > This subject has been covered here many times, but it bears repeatung... Perhaps the tools need a [AsyncReset with SyncRelease] option/tickbox, that novice users (and others) can enable ? For years in our uC products, we have used a tiny (6 byte) library that clears all user memory at power on. Saves a ton of grey hairs, and chasing erratic startup phantoms, plus eliminates chunks of InitVar code overhead. -jgArticle: 74932
O.K. I did something stupid, but as a newbie to both Verilog and Modelsim I expected a nice error message instead of no indication and no response while I watched all of my virtual memory get gobbled up. Then Modelsim closed (was killed by Windows). All because of: always PLX_LCLK0 <= #8 !PLX_LCLK0 ; (Note the incorrect usage of a blocking assign). Now the design was quite large so I've been beating myself about the head for weeks thinking there was too much logic to fit in my measly 2G of virtual memory, while the simulator was sitting at line 404 of the testbench (above) happily scheduling the next edge of PLX_LCLK0! Bottom line is: don't do that. (but why couldn't Modelsim just tell me I'm stupid instead of crashing...)Article: 74933
Peter Alfke wrote: > > Another tidbit: > When Xilinx says reset or preset, we really mean that we force the flip-flop > into one state or the other. None of that trickery with virtual preset, > implemented by reset plus inverting D and Q (which would affect timing). > But that does not mean that the tools won't invert the sense of a FF when they move inverters around. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 74934
My first experience with BGA, I stuck the vias in the pads. The company that was installing the chips for me said it would be fine. They got one to work out of about 20 tries, after which I gave up and did some research and redid the board the right way. 5/5 spacing is as low as I've gone, never had to try 4/4 with 2 tracks through yet. Sounds like fun.Article: 74935
> From: Jim Granville <no.spam@designtools.co.nz> > Organization: TelstraClear > Newsgroups: comp.arch.fpga > Date: Fri, 22 Oct 2004 10:40:19 +1300 > Subject: Re: Async reset > > Perhaps the tools need a [AsyncReset with SyncRelease] option/tickbox, > that novice users (and others) can enable ? > For years in our uC products, we have used a tiny (6 byte) library that > clears all user memory at power on. > Saves a ton of grey hairs, and chasing erratic startup phantoms, plus > eliminates chunks of InitVar code overhead. > > -jg > Nice idea, but you still have to define the physical area to be covered. If you instantiate several independent such blocks, they might not be macro-syncheronous ( I mean: synchronous to the clock, but not necessarily to the same clock tick). And within the area covered, you cannot tolerate a control-signal delay longer than one clock period. All that makes it difficult to provide one universal library element that covers all situations and all speeds... Peter AlfkeArticle: 74936
Hi Antti, Antti Lukats wrote: > "Jon Beniston" <jon@beniston.com> wrote in message >>"Antti Lukats" <antti@case2000.com> wrote in message >>>1) are you going to release the HDL sources? >>Similarly to you Antti, are you going to be releasing the HDL source for > NIOX? > lets put it that way, NIOX sources are obtainable ;) What does that mean? You earlier wrote: "NIOS-II verilog also exists, but it will not be GPL ;) " So, either it's available, or it's not. What's it to be? JohnArticle: 74937
You're probably on the edge with the timing. The reason it works differently when you re-synthesize with only minor changes is because the place and route software starts with a random seed. You could actually make no changes at all and it would work one time and not work the next (though even if it "works" it would probably break under hot/low power conditions). You might want to try a couple things -- take a heat gun set on low (or a hair dryer) and heat up the chip a little bit. Does the problem get worse? Spray it with cold spray -- does it get better? Also, raise the internal power supply voltage SLIGHTLY (like 1.5 volts to 1.55). Does the problem get better? If you lower the PS a little bit (like 1.45 volts) does it crap out? The silicon will run a little faster when it's cold and also when its voltage is a little high, so if your timing is on the edge then either of these factors might affect your circuit. If you've got a race condition, however, things might actually get worse when you cool the chip down or increase voltage. Ideally, you want your FPGA design to be stable even if it's got to suffer with both bad conditions -- hot AND low voltage.Article: 74938
Srinivas wrote: > Hi, > I'm looking to integrate a FPGA based program into a PC based > application. > I understand i need to write a serial interfacing code on the FPGA > side and an API on the PC side,considering i intend to use a RS 232 > serial interface bet'n the PC and the FPGA board. > I need help regarding the PC side API programming.I'll be using a 'C' > program and would like to call the FPGA based functions. > Can anyone suggest how i go about this?any references? > > TIA. > Srinivas Depends on what OS you are running on the PC. If Linux look for ioperm (just google), if windows look for inpout32.dll. There are probably a lot of other choices, but these worked for me. The downside is that a Linux program using ioperm has to be run as root or setuid root, which of couse is a security risc. /NSArticle: 74939
Srinivas wrote: > Hi, > I'm looking to integrate a FPGA based program into a PC based > application. > I understand i need to write a serial interfacing code on the FPGA > side and an API on the PC side,considering i intend to use a RS 232 > serial interface bet'n the PC and the FPGA board. > I need help regarding the PC side API programming.I'll be using a 'C' > program and would like to call the FPGA based functions. > Can anyone suggest how i go about this?any references? > > TIA. > Srinivas Goto LCC for Windows web page: http://www.cs.virginia.edu/~lcc-win32/ In Free download section you can find the Windows API Documentation. I havn't check if this document have the API descriptions for serial port but I guess it should be in it. Even if it doesn't it is still a good reference for Windows programming. Note: Not suitable for .NET environment. JoeArticle: 74940
Peter Alfke wrote: > >>From: Jim Granville <no.spam@designtools.co.nz> >>Organization: TelstraClear >>Newsgroups: comp.arch.fpga >>Date: Fri, 22 Oct 2004 10:40:19 +1300 >>Subject: Re: Async reset >> >>Perhaps the tools need a [AsyncReset with SyncRelease] option/tickbox, >>that novice users (and others) can enable ? >>For years in our uC products, we have used a tiny (6 byte) library that >>clears all user memory at power on. >>Saves a ton of grey hairs, and chasing erratic startup phantoms, plus >>eliminates chunks of InitVar code overhead. >> >>-jg >> > > Nice idea, but you still have to define the physical area to be covered. Understood, you clearly would need to specify the covered elements. Tho the tools could allow "all for that clock domain", and then tell the user the cost of that ? > If you instantiate several independent such blocks, they might not be > macro-syncheronous ( I mean: synchronous to the clock, but not necessarily > to the same clock tick). And within the area covered, you cannot tolerate a > control-signal delay longer than one clock period. Understood, but at these extremes, the tools should/could catch and warn on this ? > All that makes it difficult to provide one universal library element that > covers all situations and all speeds... Can you give a feel, via real examples, for when the control signal delay on a "Auto SyncRelease" reset, might end up longer than one clock period ? -jgArticle: 74941
This is not entirely true. Xilinx Virtex and later families can have the
flip-flops with either synchronous or asynchronous (re)sets, but not both unless
you use the LUT for the sync reset. The wiring to the built in reset pins on the
flip-flop can be connected to the global reset net. The flip-flops come up in a
known state at the end of configuration.
Generally speaking (asIC prototyping excepted...maybe), it is not advisable to use
an async reset in the FPGA. The issue is that the release of reset is
asynchronous to the clock, so you will get a situation where some flip-flops see
the release on one clock cycle where others see the release on the next cycle when
the reset is released close to the clock edge. The other issue is that an async
reset propagates through the flip-flop making a timing path that does not end at
the flip-flop. The timing tools historically have missed this timing path
(thinking back to the 4000 series tools), so there is a possibly hidden danger to
using async resets as well.
As far as resetting every flip flop in the design: it is not necessary. As long
as you break every synchronous feedback look in the design when you apply reset,
you can get your design to a known state in a known number of clocks. I described
this technique here within the past two weeks.
glen herrmannsfeldt wrote:
>
> Synchronous reset will be done using logic resources. It might
> be that there are enough CLB inputs not to add more, though it
> might need another column, depending on the function.
>
> A separate question is that asynchronous reset needs not to be
> too close to the clock edge, so it might need to be synchronized
> (even though not synchronous).
>
> -- glen
--
--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: 74942
You might try the Aldec tools. They give you much better
error messages, as well as a considerably more friendly user
interface.
Gabor Szakacs wrote:
> O.K. I did something stupid, but as a newbie to
> both Verilog and Modelsim I expected a nice error
> message instead of no indication and no response
> while I watched all of my virtual memory get gobbled
> up. Then Modelsim closed (was killed by Windows).
>
> A
--
--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: 74943Ray Andraka wrote: > This is not entirely true. Xilinx Virtex and later families can have the > flip-flops with either synchronous or asynchronous (re)sets, but not both unless > you use the LUT for the sync reset. The wiring to the built in reset pins on the > flip-flop can be connected to the global reset net. The flip-flops come up in a > known state at the end of configuration. My current project is with Altera ACEX, so I now looked up more exactly what it does. It seems that they provide asynchronous CLEAR and LOAD. If you specify only CLEAR (RESET) it is fine. If you specify only PRESET it will invert the logic and use CLEAR. If you use both, it needs one LUT input (DATA3) to be used for that function. So, it is a little more efficient to invert the logic if preset is used, and in that case the global reset will act as a preset. If neither is used, Quartus seems to be free to do it either way, and gives a warning to tell you that. I don't see that ACEX supplies a synchronous preset or clear, so I believe that would be done through LUT logic. It would seem that one should know the details for the logic family being used. -- glenArticle: 74944
Hi I have made a cyclone board.But when I download with jtag in quartusII.It reached 80% and then said "Error: CONF_DONE pin failed to go high in device 1". How should I solve the problem?Thanks! Best RegardsArticle: 74945
On Thu, 21 Oct 2004 16:21:58 -0700, wrote: > You're probably on the edge with the timing. The reason it works > differently when you re-synthesize with only minor changes is because > the place and route software starts with a random seed. You could > actually make no changes at all and it would work one time and not work > the next (though even if it "works" it would probably break under > hot/low power conditions). > Agreed - this is a likely problem. First thing to do is to perform a static timing analysis post-P&R on the entire design. Doing just some of the paths is not adequate. Hopefully you are not using gated clocks (where the main clock goes through a gate before it hits the clock pin of some of the flip-flops), ripple clocks (where the output of one f/f is used as the clock on another flip-flop) or asynchronous logic (typically placing gates on the set or reset pins of flip-flops). If you are using any of these techniques, pay extremely close attention to the timing, and try to avoid these techniques if you can. It should be possible to avoid using these techniques, as they are typically used in an attempt to reduce the size of a design or to maximize the clock rate. If you have multiple clocks in the design, you also have to take a close look at all of the signals that cross the boundary between clock domains. The issue is not so much metastability (unless you are, perhaps, really pushing the clock rates) but the handling of signals that must be processed as a coherent set. For example, if you have a binary counter that is incremented on one clock (clock A, say) but latched (registered) by another clock (call it clock B), it is very likely that the signals will be mis-read. Say the counter changes from 0111 to 1000 on a particular edge of clock A; clock B may sample some of the bits before they change, and some of the bits after they have changed (due to slightly different clock-to-output delays on the counter flops, to routing delays that vary from signal to signal, and to slightly different setup times on the sampling flops). In principle, the sampling register could contain any value at all. You have to be very careful in your design to prevent this type of problem when dealing with multiple clock domains, especially if the clocks are asynchronous with respect to each other. > You might want to try a couple things -- take a heat gun set on low (or > a hair dryer) and heat up the chip a little bit. Does the problem get > worse? Spray it with cold spray -- does it get better? Also, raise the > internal power supply voltage SLIGHTLY (like 1.5 volts to 1.55). Does > the problem get better? If you lower the PS a little bit (like 1.45 > volts) does it crap out? The silicon will run a little faster when it's > cold and also when its voltage is a little high, so if your timing is on > the edge then either of these factors might affect your circuit. If > you've got a race condition, however, things might actually get worse > when you cool the chip down or increase voltage. > This is useful for verifying the presence of further problems after checking the things mentioned above, but as a go-nogo test it is not particularly helpful in isolating and fixing the problem. These tests (as well as running with both a fast clock and a slow clock) are useful for determining if you have a problem(s), but provide little insight in fixing them. > Ideally, you want your FPGA design to be stable even if it's got to > suffer with both bad conditions -- hot AND low voltage. -- PhilArticle: 74946
Ray Andraka wrote: > > This is not entirely true. Xilinx Virtex and later families can have the > flip-flops with either synchronous or asynchronous (re)sets, but not both unless > you use the LUT for the sync reset. The wiring to the built in reset pins on the > flip-flop can be connected to the global reset net. The flip-flops come up in a > known state at the end of configuration. > > Generally speaking (asIC prototyping excepted...maybe), it is not advisable to use > an async reset in the FPGA. The issue is that the release of reset is > asynchronous to the clock, so you will get a situation where some flip-flops see > the release on one clock cycle where others see the release on the next cycle when > the reset is released close to the clock edge. The other issue is that an async > reset propagates through the flip-flop making a timing path that does not end at > the flip-flop. The timing tools historically have missed this timing path > (thinking back to the 4000 series tools), so there is a possibly hidden danger to > using async resets as well. I think advising against using an async reset is a bit strong. With attention to the issue, an async reset will work just fine. You just can't assume that all FFs will be released on the same clock edge. As to the timing issue, that timing condition applies to the assertion of the reset. If you are using the async input to reset the entire chip, I don't think the propagation time is an issue. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 74947
Hal Murray wrote: > There is an interesting discussion of this area for Spartan3 going > on. Subject is "spartan 3 on 4 layers" (this newsgroup) Found it. And it's highly interesting (if not controversial). Cheers, ChrisArticle: 74948
I have connected nCE to GND but the error is the same:( "kingkang" <305liuzg@163.net> wrote in message news:cl9om7$tol$1@mail.cn99.com... > Hi > I have made a cyclone board.But when I download with jtag in quartusII.It > reached 80% and then said "Error: CONF_DONE pin failed to go high in device > 1". > How should I solve the problem?Thanks! > Best Regards > >Article: 74949
Hi,Kedar I have implemented several different kinds of PR design on Virtex-II Pro. While at present,I can not implement a modular-PR design with a PPC included.(According to Xilinx-support,this should be avaiable when ISE-EDK7 released. While I am quite doubting about it.) Say what info you need. Or reply me by the above email address!(Attention,remove in the address all 'AT' manually) Rgds, Jeffsen
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