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
Would it be possible to use the same DCM for my entire design? Its CLK0_OUT would come back to its feedback input port, would drive clk_0 input of the MiG interface and be the 100 MHZ clock for my other design modules? What buffer configuration would allow that, or do I require multiple DCMs? Thanks.Article: 121851
Is this a day-care center or a professional newsgroup? Somebody wants to design a 4-bit counter with two additional control inputs. That is about as trivial a problem as I can imagine. If he has a problem with that, he should read some simple text books on logic design, but not post nine times in this newsgroup, and cause a 23-long thread. This is a nice, patient, and helpful group. Just don't abuse it! Peter Alfke On Jul 13, 10:21 am, <miche> wrote: > > I'm SERIOUSLY trying to help here and you completely blew off my other > > questions in this email AND you have NEVER asked a question that I can > > recall. A question usually involves a question mark. Are you aware what > > that is? My apologies if you actually did ask questions in your previous > > posts, but I recall them all as "This is my situation." "Eagerly > > anticipating your reply." Please look at my response again from this > > morning and inform us: from what background do you come and how would you > > approach this in software (if you know programming languages). > > Hello, > I received the info from another member. > Just to be clear, I don't really like your question if I am > professional or hobbyist, also, you do not explain how > you define hobbyist/professional. Personally, I don't > think it matters, some professionals are amaturish, > and some amatures are professional. Don't try to > put people into boxes.Article: 121852
On 2007-07-13, PFC <lists@peufeu.com> wrote: > So, the question is, would experienced people be willing to spend a few > minutes reviewing my schematics to tell me if I have some obvious errors ? > What format should I use ? I use Eagle, so I can give Eagle files or > plain PDF. If you posted a link to the PDF, people would probably look... -- Ben Jackson AD7GD <ben@ben.com> http://www.ben.com/Article: 121853
My setup has two Xilinx FPGA's which communicate with one another through two unidirectional system-synchronous interfaces. FPGA 1 is an XC2V3000-FF1152-4 and FPGA 2 is an XC4VLX160-FF1148-11. Both devices get their clocks from the same input source on the board, and the clock traces are well-matched. FPGA 1 brings the input clock through an IBUFG and then into a CLKDLL, in which case the CLK0 output is used as both the DLL feedback clock and the system clock. FPGA 2 brings the input clock through an IBUFG and then into a DCM_ADV, in which case the CLK0 output is used as both the DCM feedback clock and the system clock. These unidirectional system-synchronous interfaces are basically data and data valid in both directions, and both FPGA's utilize the LVCMOS25 I/O standard and 12mA slow slew on their outputs. I have verified that all pads are utilizing the IOB registers. I have also verified that timing is met (with margin) on both devices and there aren't any unconstrained timing paths. The test sends packetized data from FPGA 1 to FPGA 2 in one direction, and FPGA 2 sends the data back to FPGA 1 in the other direction, with some data processing. When I clock these interfaces at 80MHz, everything works fine. However, when I lower the clock frequency to 40MHz (via the on-board oscillator), the interfaces start failing. I also tried 20MHz and 60MHz and see failures as well. What's really interesting is that when I keep FPGA 1 the same, but build a new FPGA 2 which does not use a DCM, the interfaces work at 40MHz as well as at 20MHz, 60MHz, and 80MHz. I have tried with my own DCM wrapper module as well as with a Xilinx-generated COREgen module and see the same behavior. If anyone can perhaps help me understand what may be causing this behavior I would certainly appreciate it. Below I've listed Xilinx Timing Analyzer data sheet report information for both FPGA 1 and FPGA 2 (with and without the DCM). I'd recommend copy-pasting and viewing with a fixed-point font. =) ** FPGA 1 outputs to FPGA 2 ** <pin> <clk to pad> FPGA_1_tx_data_out<0> 5.055 FPGA_1_tx_data_out<1> 5.055 FPGA_1_tx_data_out<2> 5.022 FPGA_1_tx_data_out<3> 5.028 FPGA_1_tx_data_out<4> 5.039 FPGA_1_tx_data_out<5> 5.050 FPGA_1_tx_data_out<6> 5.019 FPGA_1_tx_data_out<7> 5.019 FPGA_1_tx_valid_out 5.023 ** FPGA 1 inputs from FPGA 2 (No DCM) ** <pin> <setup> <hold> FPGA_2_tx_data_in<0> 2.929 0.512 FPGA_2_tx_data_in<1> 2.895 0.562 FPGA_2_tx_data_in<2> 2.905 0.553 FPGA_2_tx_data_in<3> 2.842 0.625 FPGA_2_tx_data_in<4> 2.852 0.616 FPGA_2_tx_data_in<5> 2.899 0.554 FPGA_2_tx_data_in<6> 2.890 0.562 FPGA_2_tx_data_in<7> 2.840 0.625 FPGA_2_tx_valid_in 2.835 0.630 ** FPGA 1 inputs from FPGA 2 (DCM) ** <pin> <setup> <hold> FPGA_2_tx_data_in<0> 1.415 -0.021 FPGA_2_tx_data_in<1> 1.381 0.029 FPGA_2_tx_data_in<2> 1.391 0.02 FPGA_2_tx_data_in<3> 1.328 0.092 FPGA_2_tx_data_in<4> 1.338 0.083 FPGA_2_tx_data_in<5> 1.385 0.021 FPGA_2_tx_data_in<6> 1.376 0.029 FPGA_2_tx_data_in<7> 1.326 0.092 FPGA_2_tx_valid_in 1.321 0.097 ** FPGA 2 (No DCM) outputs to FPGA 1 ** <pin> <clk to pad> FPGA_2_rx_data_out<0> 9.484 FPGA_2_rx_data_out<1> 9.496 FPGA_2_rx_data_out<2> 9.493 FPGA_2_rx_data_out<3> 9.492 FPGA_2_rx_data_out<4> 9.494 FPGA_2_rx_data_out<5> 9.516 FPGA_2_rx_data_out<6> 9.511 FPGA_2_rx_data_out<7> 9.529 FPGA_2_rx_valid_out 9.534 ** FPGA 2 (DCM) outputs to FPGA 1 ** <pin> <clk to pad> FPGA_2_rx_data_out<0> 4.383 FPGA_2_rx_data_out<1> 4.395 FPGA_2_rx_data_out<2> 4.392 FPGA_2_rx_data_out<3> 4.391 FPGA_2_rx_data_out<4> 4.393 FPGA_2_rx_data_out<5> 4.415 FPGA_2_rx_data_out<6> 4.41 FPGA_2_rx_data_out<7> 4.428 FPGA_2_rx_valid_out 4.433 ** FPGA 1 inputs from FPGA 2 ** <pin> <setup> <hold> FPGA_1_rx_data_in<0> 1.999 -1.022 FPGA_1_rx_data_in<1> 2.001 -1.024 FPGA_1_rx_data_in<2> 1.975 -0.998 FPGA_1_rx_data_in<3> 1.963 -0.986 FPGA_1_rx_data_in<4> 2.007 -1.030 FPGA_1_rx_data_in<5> 1.946 -0.969 FPGA_1_rx_data_in<6> 1.986 -1.009 FPGA_1_rx_data_in<7> 1.944 -0.967 FPGA_1_rx_valid_in 1.990 -1.013 Thanks, BrianArticle: 121854
I also need to multiplex the clock. There will be 3 inputs instead of the previous clock. As follows: clock1 clock2 clockselect always @(clocksel or clock1 or clock2) begin if(clocksel) clk<=clock2; else clk<=clock1; end This gives me warnings WARNING:Cpld - Possible asynchronous logic: Clock pin 'counter<0>.CLKF' has WARNING:Cpld - Possible asynchronous logic: Clock pin 'counter<1>.CLKF' has WARNING:Cpld - Possible asynchronous logic: Clock pin 'counter<2>.CLKF' has WARNING:Cpld - Possible asynchronous logic: Clock pin 'counter<3>.CLKF' has Waiting with anticipation.Article: 121855
All beware, confidense tricksters operate here.Article: 121856
On Jul 13, 2:38 pm, "bwilso...@gmail.com" <bwilso...@gmail.com> wrote: > My setup has two Xilinx FPGA's which communicate with one another > through two unidirectional system-synchronous interfaces. FPGA 1 is > an XC2V3000-FF1152-4 and FPGA 2 is an XC4VLX160-FF1148-11. Both > devices get their clocks from the same input source on the board, and > the clock traces are well-matched. FPGA 1 brings the input clock > through an IBUFG and then into a CLKDLL, in which case the CLK0 output > is used as both the DLL feedback clock and the system clock. FPGA 2 > brings the input clock through an IBUFG and then into a DCM_ADV, in > which case the CLK0 output is used as both the DCM feedback clock and > the system clock. These unidirectional system-synchronous interfaces > are basically data and data valid in both directions, and both FPGA's > utilize the LVCMOS25 I/O standard and 12mA slow slew on their > outputs. I have verified that all pads are utilizing the IOB > registers. I have also verified that timing is met (with margin) on > both devices and there aren't any unconstrained timing paths. > > The test sends packetized data from FPGA 1 to FPGA 2 in one direction, > and FPGA 2 sends the data back to FPGA 1 in the other direction, with > some data processing. When I clock these interfaces at 80MHz, > everything works fine. However, when I lower the clock frequency to > 40MHz (via the on-board oscillator), the interfaces start failing. I > also tried 20MHz and 60MHz and see failures as well. What's really > interesting is that when I keep FPGA 1 the same, but build a new FPGA > 2 which does not use a DCM, the interfaces work at 40MHz as well as at > 20MHz, 60MHz, and 80MHz. I have tried with my own DCM wrapper module > as well as with a Xilinx-generated COREgen module and see the same > behavior. > > If anyone can perhaps help me understand what may be causing this > behavior I would certainly appreciate it. Below I've listed Xilinx > Timing Analyzer data sheet report information for both FPGA 1 and FPGA > 2 (with and without the DCM). I'd recommend copy-pasting and viewing > with a fixed-point font. =) > > ** FPGA 1 outputs to FPGA 2 ** > <pin> <clk to pad> > FPGA_1_tx_data_out<0> 5.055 > FPGA_1_tx_data_out<1> 5.055 > FPGA_1_tx_data_out<2> 5.022 > FPGA_1_tx_data_out<3> 5.028 > FPGA_1_tx_data_out<4> 5.039 > FPGA_1_tx_data_out<5> 5.050 > FPGA_1_tx_data_out<6> 5.019 > FPGA_1_tx_data_out<7> 5.019 > FPGA_1_tx_valid_out 5.023 > > ** FPGA 1 inputs from FPGA 2 (No DCM) ** > <pin> <setup> <hold> > FPGA_2_tx_data_in<0> 2.929 0.512 > FPGA_2_tx_data_in<1> 2.895 0.562 > FPGA_2_tx_data_in<2> 2.905 0.553 > FPGA_2_tx_data_in<3> 2.842 0.625 > FPGA_2_tx_data_in<4> 2.852 0.616 > FPGA_2_tx_data_in<5> 2.899 0.554 > FPGA_2_tx_data_in<6> 2.890 0.562 > FPGA_2_tx_data_in<7> 2.840 0.625 > FPGA_2_tx_valid_in 2.835 0.630 > > ** FPGA 1 inputs from FPGA 2 (DCM) ** > <pin> <setup> <hold> > FPGA_2_tx_data_in<0> 1.415 -0.021 > FPGA_2_tx_data_in<1> 1.381 0.029 > FPGA_2_tx_data_in<2> 1.391 0.02 > FPGA_2_tx_data_in<3> 1.328 0.092 > FPGA_2_tx_data_in<4> 1.338 0.083 > FPGA_2_tx_data_in<5> 1.385 0.021 > FPGA_2_tx_data_in<6> 1.376 0.029 > FPGA_2_tx_data_in<7> 1.326 0.092 > FPGA_2_tx_valid_in 1.321 0.097 > > ** FPGA 2 (No DCM) outputs to FPGA 1 ** > <pin> <clk to pad> > FPGA_2_rx_data_out<0> 9.484 > FPGA_2_rx_data_out<1> 9.496 > FPGA_2_rx_data_out<2> 9.493 > FPGA_2_rx_data_out<3> 9.492 > FPGA_2_rx_data_out<4> 9.494 > FPGA_2_rx_data_out<5> 9.516 > FPGA_2_rx_data_out<6> 9.511 > FPGA_2_rx_data_out<7> 9.529 > FPGA_2_rx_valid_out 9.534 > > ** FPGA 2 (DCM) outputs to FPGA 1 ** > <pin> <clk to pad> > FPGA_2_rx_data_out<0> 4.383 > FPGA_2_rx_data_out<1> 4.395 > FPGA_2_rx_data_out<2> 4.392 > FPGA_2_rx_data_out<3> 4.391 > FPGA_2_rx_data_out<4> 4.393 > FPGA_2_rx_data_out<5> 4.415 > FPGA_2_rx_data_out<6> 4.41 > FPGA_2_rx_data_out<7> 4.428 > FPGA_2_rx_valid_out 4.433 > > ** FPGA 1 inputs from FPGA 2 ** > <pin> <setup> <hold> > FPGA_1_rx_data_in<0> 1.999 -1.022 > FPGA_1_rx_data_in<1> 2.001 -1.024 > FPGA_1_rx_data_in<2> 1.975 -0.998 > FPGA_1_rx_data_in<3> 1.963 -0.986 > FPGA_1_rx_data_in<4> 2.007 -1.030 > FPGA_1_rx_data_in<5> 1.946 -0.969 > FPGA_1_rx_data_in<6> 1.986 -1.009 > FPGA_1_rx_data_in<7> 1.944 -0.967 > FPGA_1_rx_valid_in 1.990 -1.013 > > Thanks, > Brian One obvious question is do you change the clock frequency on the fly, i.e. while the FPGA's are up and running, or do you re-load the FPGA's aftere the change? DCM's, at least in the Virtex 2 family, don't automatically re-synch after a frequency change. You need to apply the reset signal to the DCM after the new frequency is stable. Also don't rely on the "LOCK" output of the DCM for lock status. Once locked, this tends to stay on even if lock is lost. I use bit 1 of the status bus to check for lock. HTH, GaborArticle: 121857
On Jul 13, 11:52 am, Gabor <ga...@alacron.com> wrote: > On Jul 13, 2:38 pm, "bwilso...@gmail.com" <bwilso...@gmail.com> wrote: > > > > > My setup has two Xilinx FPGA's which communicate with one another > > through two unidirectional system-synchronous interfaces. FPGA 1 is > > an XC2V3000-FF1152-4 and FPGA 2 is an XC4VLX160-FF1148-11. Both > > devices get their clocks from the same input source on the board, and > > the clock traces are well-matched. FPGA 1 brings the input clock > > through an IBUFG and then into a CLKDLL, in which case the CLK0 output > > is used as both the DLL feedback clock and the system clock. FPGA 2 > > brings the input clock through an IBUFG and then into a DCM_ADV, in > > which case the CLK0 output is used as both the DCM feedback clock and > > the system clock. These unidirectional system-synchronous interfaces > > are basically data and data valid in both directions, and both FPGA's > > utilize the LVCMOS25 I/O standard and 12mA slow slew on their > > outputs. I have verified that all pads are utilizing the IOB > > registers. I have also verified that timing is met (with margin) on > > both devices and there aren't any unconstrained timing paths. > > > The test sends packetized data from FPGA 1 to FPGA 2 in one direction, > > and FPGA 2 sends the data back to FPGA 1 in the other direction, with > > some data processing. When I clock these interfaces at 80MHz, > > everything works fine. However, when I lower the clock frequency to > > 40MHz (via the on-board oscillator), the interfaces start failing. I > > also tried 20MHz and 60MHz and see failures as well. What's really > > interesting is that when I keep FPGA 1 the same, but build a new FPGA > > 2 which does not use a DCM, the interfaces work at 40MHz as well as at > > 20MHz, 60MHz, and 80MHz. I have tried with my own DCM wrapper module > > as well as with a Xilinx-generated COREgen module and see the same > > behavior. > > > If anyone can perhaps help me understand what may be causing this > > behavior I would certainly appreciate it. Below I've listed Xilinx > > Timing Analyzer data sheet report information for both FPGA 1 and FPGA > > 2 (with and without the DCM). I'd recommend copy-pasting and viewing > > with a fixed-point font. =) > > > ** FPGA 1 outputs to FPGA 2 ** > > <pin> <clk to pad> > > FPGA_1_tx_data_out<0> 5.055 > > FPGA_1_tx_data_out<1> 5.055 > > FPGA_1_tx_data_out<2> 5.022 > > FPGA_1_tx_data_out<3> 5.028 > > FPGA_1_tx_data_out<4> 5.039 > > FPGA_1_tx_data_out<5> 5.050 > > FPGA_1_tx_data_out<6> 5.019 > > FPGA_1_tx_data_out<7> 5.019 > > FPGA_1_tx_valid_out 5.023 > > > ** FPGA 1 inputs from FPGA 2 (No DCM) ** > > <pin> <setup> <hold> > > FPGA_2_tx_data_in<0> 2.929 0.512 > > FPGA_2_tx_data_in<1> 2.895 0.562 > > FPGA_2_tx_data_in<2> 2.905 0.553 > > FPGA_2_tx_data_in<3> 2.842 0.625 > > FPGA_2_tx_data_in<4> 2.852 0.616 > > FPGA_2_tx_data_in<5> 2.899 0.554 > > FPGA_2_tx_data_in<6> 2.890 0.562 > > FPGA_2_tx_data_in<7> 2.840 0.625 > > FPGA_2_tx_valid_in 2.835 0.630 > > > ** FPGA 1 inputs from FPGA 2 (DCM) ** > > <pin> <setup> <hold> > > FPGA_2_tx_data_in<0> 1.415 -0.021 > > FPGA_2_tx_data_in<1> 1.381 0.029 > > FPGA_2_tx_data_in<2> 1.391 0.02 > > FPGA_2_tx_data_in<3> 1.328 0.092 > > FPGA_2_tx_data_in<4> 1.338 0.083 > > FPGA_2_tx_data_in<5> 1.385 0.021 > > FPGA_2_tx_data_in<6> 1.376 0.029 > > FPGA_2_tx_data_in<7> 1.326 0.092 > > FPGA_2_tx_valid_in 1.321 0.097 > > > ** FPGA 2 (No DCM) outputs to FPGA 1 ** > > <pin> <clk to pad> > > FPGA_2_rx_data_out<0> 9.484 > > FPGA_2_rx_data_out<1> 9.496 > > FPGA_2_rx_data_out<2> 9.493 > > FPGA_2_rx_data_out<3> 9.492 > > FPGA_2_rx_data_out<4> 9.494 > > FPGA_2_rx_data_out<5> 9.516 > > FPGA_2_rx_data_out<6> 9.511 > > FPGA_2_rx_data_out<7> 9.529 > > FPGA_2_rx_valid_out 9.534 > > > ** FPGA 2 (DCM) outputs to FPGA 1 ** > > <pin> <clk to pad> > > FPGA_2_rx_data_out<0> 4.383 > > FPGA_2_rx_data_out<1> 4.395 > > FPGA_2_rx_data_out<2> 4.392 > > FPGA_2_rx_data_out<3> 4.391 > > FPGA_2_rx_data_out<4> 4.393 > > FPGA_2_rx_data_out<5> 4.415 > > FPGA_2_rx_data_out<6> 4.41 > > FPGA_2_rx_data_out<7> 4.428 > > FPGA_2_rx_valid_out 4.433 > > > ** FPGA 1 inputs from FPGA 2 ** > > <pin> <setup> <hold> > > FPGA_1_rx_data_in<0> 1.999 -1.022 > > FPGA_1_rx_data_in<1> 2.001 -1.024 > > FPGA_1_rx_data_in<2> 1.975 -0.998 > > FPGA_1_rx_data_in<3> 1.963 -0.986 > > FPGA_1_rx_data_in<4> 2.007 -1.030 > > FPGA_1_rx_data_in<5> 1.946 -0.969 > > FPGA_1_rx_data_in<6> 1.986 -1.009 > > FPGA_1_rx_data_in<7> 1.944 -0.967 > > FPGA_1_rx_valid_in 1.990 -1.013 > > > Thanks, > > Brian > > One obvious question is do you change the clock frequency on the > fly, i.e. while the FPGA's are up and running, or do you re-load > the FPGA's aftere the change? DCM's, at least in the Virtex 2 > family, don't automatically re-synch after a frequency change. > You need to apply the reset signal to the DCM after the new > frequency is stable. Also don't rely on the "LOCK" output of > the DCM for lock status. Once locked, this tends to stay on > even if lock is lost. I use bit 1 of the status bus to check > for lock. > > HTH, > Gabor The system is completely restarted when selecting a new clock frequency.Article: 121858
I've just got a brand new board with a Stratix II S180 on it. Before I power it on, I checked the power supply rails for short-circuits. I get 20 ohms on the 1.8V supply rail and 1.2 Ohms for the 1.2V. 20 ohms does not look like a short but 1.2 is rather small. On those supplies, I only have logic components and decap capacitors, the power supply is on another board. So any advice before I push a few amps in it? Short or not? (I must say that I'm somewhat stressed by the device price ;-) MarcArticle: 121859
<miche> wrote in message news:4697c87d_4@mk-nntp-2.news.uk.tiscali.com... >I also need to multiplex the clock. <snip> > Waiting with anticipation. Please wait. Please wait.Article: 121860
<miche> wrote in message news:4697b4a3$1_4@mk-nntp-2.news.uk.tiscali.com... >> I'm SERIOUSLY trying to help here and you completely blew off my other >> questions in this email AND you have NEVER asked a question that I can >> recall. A question usually involves a question mark. Are you aware what >> that is? My apologies if you actually did ask questions in your previous >> posts, but I recall them all as "This is my situation." "Eagerly >> anticipating your reply." Please look at my response again from this >> morning and inform us: from what background do you come and how would >> you >> approach this in software (if you know programming languages). > > Hello, > I received the info from another member. > Just to be clear, I don't really like your question if I am > professional or hobbyist, also, you do not explain how > you define hobbyist/professional. Personally, I don't > think it matters, some professionals are amaturish, > and some amatures are professional. Don't try to > put people into boxes. To address an audience effectively, you should know your audience. If you're an Electrical Engineering graduate, you should know electronics and logic inside out; being new to HDL involves quite a step that's easy for us to help with the transition. If you're a software engineer getting into the hardware world, you know how to do things procedurally with precision and grace in a serial machine; being new to the parallel nature of hardware involves quite a step that's easy for us to help with the transition. If you're a student with a difficult assignment, we've all been in your shoes; being new to the course material involves quite a step in the raw concepts involved that's easy for us to help with the transition. If you're a lazy engineer who's paid to do this work and expected to be confident in your abilities, you're a lazy good-for-nothing indiviual trying to sap the life out of others; being lazy isn't all bad because it's easy for us to poke fun at you and try to frustrate you to the point that you actually do your work or realize that this is a forum that can benefit you in the long run if you try to learn what you can't get from textbooks by asking well-considered questions. You have proven ineffective in trying to get information because you have not fully stated your needs. You say what you want with limited descriptions and expect us to produce an answer. Usually it takes a fortune teller (for a fee, of course) to give you that kind of detail from so little. As for "confidence tricksters" do you mean "con men?" There are no con artists on this forum that have become obvious over the years that many of us have frequented this board. What would POSSIBLY give you the idea from the responses you have received in these two threads? As far as I can tell, your conclusion comes from visiting this forum for three days.Article: 121861
miche wrote: > Hello, > I require a counter which counts up on positive clock; > can be reset to zero upon a reset signal; > will stop counting when reached max or rollover; > will restart counting only after a total reset, which is > not the same as the counter reset. (2 resets) > Waiting with anticipation. > Thanks. Go to http://www.standardics.nxp.com/products/counters/ and take your pick That will get you 95% of the way there. One of your specs MAY need a small amount of additional logic,but I'll leave that portion as an exercise for the student. -jgArticle: 121862
miche wrote: >>Hi Jon, >>:-) >>Actually that's quite a useful widget. Ta for the link! > > > Miserable gits. Wot ? - That gets very close to your stated requirements, and I'm with Symon - it's a nifty little counter. -jgArticle: 121863
<bwilson79@gmail.com> wrote in message news:1184351927.371890.102850@m3g2000hsh.googlegroups.com... > My setup has two Xilinx FPGA's which communicate with one another > through two unidirectional system-synchronous interfaces. FPGA 1 is > an XC2V3000-FF1152-4 and FPGA 2 is an XC4VLX160-FF1148-11. Both > devices get their clocks from the same input source on the board, and > the clock traces are well-matched. FPGA 1 brings the input clock > through an IBUFG and then into a CLKDLL, in which case the CLK0 output > is used as both the DLL feedback clock and the system clock. FPGA 2 > brings the input clock through an IBUFG and then into a DCM_ADV, in > which case the CLK0 output is used as both the DCM feedback clock and > the system clock. These unidirectional system-synchronous interfaces > are basically data and data valid in both directions, and both FPGA's > utilize the LVCMOS25 I/O standard and 12mA slow slew on their > outputs. I have verified that all pads are utilizing the IOB > registers. I have also verified that timing is met (with margin) on > both devices and there aren't any unconstrained timing paths. > > The test sends packetized data from FPGA 1 to FPGA 2 in one direction, > and FPGA 2 sends the data back to FPGA 1 in the other direction, with > some data processing. When I clock these interfaces at 80MHz, > everything works fine. However, when I lower the clock frequency to > 40MHz (via the on-board oscillator), the interfaces start failing. I > also tried 20MHz and 60MHz and see failures as well. What's really > interesting is that when I keep FPGA 1 the same, but build a new FPGA > 2 which does not use a DCM, the interfaces work at 40MHz as well as at > 20MHz, 60MHz, and 80MHz. I have tried with my own DCM wrapper module > as well as with a Xilinx-generated COREgen module and see the same > behavior. > > If anyone can perhaps help me understand what may be causing this > behavior I would certainly appreciate it. Below I've listed Xilinx > Timing Analyzer data sheet report information for both FPGA 1 and FPGA > 2 (with and without the DCM). I'd recommend copy-pasting and viewing > with a fixed-point font. =) <snip FPGA timing> > > Thanks, > Brian Do your DCMs have any phase offsets? The negative hold time for your last bunch of registers is a bit curious. If offsets are used to move the sampling points around, changing the frequency will increase or decreas the time shift attributed to the fixed phase shift, perhaps pushing your specs out of spec. Running the timing analyzer with different frequencies (one may be able to do this with one compile and multiple frequency specification lines, disabling the unneeded frequencies in the timing constraint list through the Timein Analyzer GUI) will show to what effect the phase offsets will affect your design.Article: 121864
miche wrote: > All beware, > confidense tricksters operate here. Just curious How old are you ? Is this your course major ? -jgArticle: 121865
"Marc Battyani" <Marc.Battyani@fractalconcept.com> wrote in message news:II6dnV22FJlaTQrbnZ2dnUVZ8sKlnZ2d@giganews.com... > I've just got a brand new board with a Stratix II S180 on it. Before I > power it on, I checked the power supply rails for short-circuits. I get 20 > ohms on the 1.8V supply rail and 1.2 Ohms for the 1.2V. 20 ohms does not > look like a short but 1.2 is rather small. On those supplies, I only have > logic components and decap capacitors, the power supply is on another > board. > > So any advice before I push a few amps in it? Short or not? > (I must say that I'm somewhat stressed by the device price ;-) > > Marc Do you still have a Stratix-II device unassembled? If you've broken the vacuum seal pack, you'd have to re-bake anyway. You could check the resistance on the unassembled parts you have. I'd tend to worry only if the lead resistance showed up as 1.2 ohms; you're concerned about solder shorts under the BGA. Solder shorts between power and ground (or between powers) is a problem. If you can bring up the board without configuring the FPGA, a boundary scan could tell you if there are any signals stuck at VCC or Ground. The point where you might damage the chip is if the signal was shorted to a rail and driven hard for an extended length of time. How would you gain confidence in any board that has an expensive part on it? If you aren't set up for boundary-scan or manufacturing defect analysis, you flick the power on and off and check for excessive warmth. You flick the power on... and off and check for excessive warmth. If you can check the current draw of the board during the power-supply ramp, you only need milliseconds to capture the trace on the digital scope and make sure it's around what you expect.Article: 121866
Using resistor value should work but I was looking if this can be easily done by changing something in the FPGA. EddieArticle: 121867
Totally_Lost wrote: <snip> > Last, the cost to Xilinx to include XC4K/Spartan support in XST would > have been relatively minor, maybe a man year or two. And as you note, > the hard part was already done, working, and shipping ... the place > and route, plus bit stream utilities which are the most device > dependent. While I've not seen the XST code, I would not have been > suprised if the difference between Spartan 2 support and providing > XC4K/Spartan support XST was actually less than a man year. > > There are still a large number of these student boards floating > around, without any affordable VHDL/Verilog synthesis support. Xilinx CPLD support goes back further than this, so that seems to exclude any fundamental road-blocks. They can still compile ABEL Code & target new CPLDs with that, so that's quite good longevity. I don't use Spartan, but what 'missing pieces' prevent someone doing a design in the present flows ? As you say, the P&R & bistream are all done, so that leaves a HDL to netlist compile ? - this could make a good student project ? Or, maybe even an open-source project ;) -jgArticle: 121868
"Marc Battyani" <Marc.Battyani@fractalconcept.com> wrote in message news:II6dnV22FJlaTQrbnZ2dnUVZ8sKlnZ2d@giganews.com... > I've just got a brand new board with a Stratix II S180 on it. Before I > power it on, I checked the power supply rails for short-circuits. I get 20 > ohms on the 1.8V supply rail and 1.2 Ohms for the 1.2V. 20 ohms does not > look like a short but 1.2 is rather small. On those supplies, I only have > logic components and decap capacitors, the power supply is on another > board. > > So any advice before I push a few amps in it? Short or not? I believe this is normal for some of the devices when you measure with a DMM. There was a thread on this topic in the past: http://groups.google.ca/group/comp.arch.fpga/browse_frm/thread/a241d334f3abce3/56cd0d704eb6e10c?lnk=st&q=power+ground+resistance+group%3Acomp.arch.fpga&rnum=13&hl=en#56cd0d704eb6e10c However, I have never encountered this behaviour in the devices I've used so far... /MikhailArticle: 121869
Matthew Hicks wrote: > You can use inline assembly with the tools provided by Xilinx since they > are basically GCC. You have to use the GCC inline assembly format > because inline assembly is compiler, not processor specific. Although, > the assembly commands are processor specific. IBM DeveloperWorks has > two good articles on assembly programming for the PowerPC family of > processors. You can find the instruction set reference doc on both the > Xilinx and IBM sites. Where is the documentation that shows the details of the calling sequence between C and assy functions - I have never been able to find that. Stuff like how arguments are put into registers/stack, what registers must be preserved, etc.? thanks, -JeffArticle: 121870
Marc , My temptation is to tell you it is bad, but I will resist the temptation! Seriously, a ohmmeter check may be dangerous: many use a 9 volt battery. Testing this way immediately violates the warranty (look at the absolute maximum ratings in the data sheet). 9 volts will kill a 1 or 1.2 volt Vcc part! I suggest that the very low core voltages, combined with the very large static leakage at 90 nanometers, means you may no longer use an ohmmeter to tell you anything. Instead, a 1.2 or 1.0 volt current limited power supply is required. AustinArticle: 121871
"austin" <austin@xilinx.com> wrote in message news:f78slk$fkp5@cnn.xilinx.com... > Marc , > > My temptation is to tell you it is bad, but I will resist the temptation! > > Seriously, a ohmmeter check may be dangerous: many use a 9 volt battery. > > Testing this way immediately violates the warranty (look at the absolute > maximum ratings in the data sheet). > > 9 volts will kill a 1 or 1.2 volt Vcc part! > > I suggest that the very low core voltages, combined with the very large > static leakage at 90 nanometers, means you may no longer use an ohmmeter > to tell you anything. > > Instead, a 1.2 or 1.0 volt current limited power supply is required. > > Austin My ohmmeter walked away at work, besides - I'd need an ohmmeter to check my ohmmeter. Don't they have high impedance outputs even when the resistance measurement goes to the 0-20 ohm range? As long as the measurement - through it's drive impedance - provided less than 1.2V through the 1.2 ohms (1 amp?!), measuring the 1.2V rail should be fine. Negative 1.2V could be a different matter. - John_HArticle: 121872
On 13 Jul, 19:46, <miche> wrote: > I also need to multiplex the clock. > There will be 3 inputs instead of the > previous clock. As follows: > > clock1 > clock2 > clockselect > > always @(clocksel or clock1 or clock2) > begin > if(clocksel) clk<=clock2; > else clk<=clock1; > end > > This gives me warnings > > WARNING:Cpld - Possible asynchronous logic: Clock pin 'counter<0>.CLKF' has > WARNING:Cpld - Possible asynchronous logic: Clock pin 'counter<1>.CLKF' has > WARNING:Cpld - Possible asynchronous logic: Clock pin 'counter<2>.CLKF' has > WARNING:Cpld - Possible asynchronous logic: Clock pin 'counter<3>.CLKF' has > > Waiting with anticipation. At least you tried this time. What is your target device?Article: 121873
"austin" <austin@xilinx.com> wrote > Marc , > > My temptation is to tell you it is bad, but I will resist the temptation! > > Seriously, a ohmmeter check may be dangerous: many use a 9 volt battery. > > Testing this way immediately violates the warranty (look at the absolute > maximum ratings in the data sheet). > > 9 volts will kill a 1 or 1.2 volt Vcc part! Ouch! Hopefully it was not the case this time :) > I suggest that the very low core voltages, combined with the very large > static leakage at 90 nanometers, means you may no longer use an ohmmeter > to tell you anything. > > Instead, a 1.2 or 1.0 volt current limited power supply is required. Good idea, I will make one for the next boards. Thanks to all. BTW I powered the boards. They did not blowup and the power supplies are at their normal levels. :) MarcArticle: 121874
Jeff Cunningham wrote: > Where is the documentation that shows the details of the calling > sequence between C and assy functions - I have never been able to find > that. Stuff like how arguments are put into registers/stack, what > registers must be preserved, etc.? I think this might be what you're looking for: http://the.wall.riscom.net/books/proc/ppc/cwg/a_abi.html#46046 (note it's generic PowerPC; it may reference stuff the embedded 405 doesn't support). ken
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