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
On Apr 15, 7:41=A0am, Ben_Quem <B_quemen...@hotmail.com> wrote: > Usually I will try to have a 10% slack on all generated clock : > for 50 MHz (20ns) , I will try to get a worst case slack of 2ns > for 100 MHz (10ns) , I will try to get a worst case slack of 1ns. Defining the allowable slack as a percentage of clock period has no rationale basis. A design that fails due to setup or hold timing will do so because the input signal did not arrive at the correct time relative to the sampling edge...that simple. Whether the clock frequency of the signal that does the sampling is 100 MHz or 1 Hz is not relevant. > The person who told me to follow this rule , has been working in the > military domain for 20 years. > OK... > Someone else told me lower value for the worst case slack is > acceptable ,he told me a 0.00000x ns slack will work, because the > vendor already include margin in the calculation for the worst slack. You are free to assume whatever you would like, but you'll get no support from the supplier for a failed design if you violate timing requirements. The data sheets are generally specified to be valid over certain operating temperature and voltage ranges. A given design in many cases does not operate over the entire range so in that sense there is likely some 'margin' in the numbers that the supplier lists and might form some basis for using 0 slack. However, the other thing that goes into the timing numbers that will not work in your favor are the other test conditions, like the following all of which will degrade timing (i.e. force you to consider having greater than 0 slack) - Osc period uncertainty (it's small, but it's not zero) - I/O signal delays (signals don't get from here to there on a PCB in zero time) - Signal quality (an input signal that takes a few round trips on the PCB to settle down before being sampled requires much more time than a terminated, no reflection signal) - Signal switching time (when does a slowly rising input really become a '1'?) - Jitter on DCM/PLLs (they're not zero) - Supply voltage noise There are many other effects to consider as well. > or could someone explain which rule they > are using to validate timing closure ? > Consider and get an understanding of all of the sources of uncertainty that may exist and then simply do the timing analysis properly to the best of your ability. Then find someone who knows more than yourself about timing analysis and ask that person to peer review your method and results. Then go back and update your analysis. Once you have a better understanding, you'll also realize that it is likely that there still other things that you probably don't really know about but don't want to get burned on either...so you add in some additional margin...adding 0 implies that you think you've covered all of your bases, that is most likely not a correct assumption. Kevin JenningsArticle: 139826
"Jonathan Bromley" <jonathan.bromley@MYCOMPANY.com> wrote in message news:i0sbu4ho61tdp17511b4em80i2d9vn1u5h@4ax.com... > Unhappy memories of my first-ever CMOS > project, where I left the reset input floating. > It would often work for a few minutes. I've had two CMOS idiocies that I can remember. One was a RAM that would perform writes when the addresses were floating (even though the CS and WE inputs were held to the appropriate levels). The other was debugging a system with a fair chunk of CMOS (as well as some analog and ECL). It was working, but not reliably, and it took me about 15 minutes to realize I wasn't applying power to the CMOS section. The whole section seemed to be powering itself off the inputs.Article: 139827
On Apr 15, 5:34=A0pm, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com> wrote: > On Wed, 15 Apr 2009 07:30:24 -0700 (PDT), > > halong <cco...@netscape.net> wrote: > >Floating causes head ache > > Indeed. =A0Unhappy memories of my first-ever CMOS > project, where I left the reset input floating. > It would often work for a few minutes. =A0Or it > would fail to work until you moved a finger > close to it. > > Sensible people don't make that sort of mistake > twice. =A0I think it took me three or four such > situations before I learnt my lesson :-( > -- > Jonathan Bromley, Consultant > > DOULOS - Developing Design Know-how > VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services > > Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK > jonathan.brom...@MYCOMPANY.comhttp://www.MYCOMPANY.com > > The contents of this message may contain personal views which > are not the views of Doulos Ltd., unless specifically stated. LOL, eh, well the reason why it happened, was well, lets say acceptable... I wanted to connect to reset input to switch in such way that i can not make mistake about polarity..:) thats why i did not choose a push button (what has pullup on board), i did just select the slide switch as it has 2 stable positions.. and well.. yes a 3rd one that is also possible made stable, and in such case remains as floating was just a funny misbehaviour, not a mistake,, well if then well, yes i should have enabled the onchip pullup right away what i didnt. when design actual boards, the reset is most sensitive, and i am always VERY paranoid about anything connected to reset pin AnttiArticle: 139828
>From http://www.xilinx.com/ise/ossupport/index.htm Xilinx supports SUSE Linux Enterprise 10* (SLE) and Red Hat Enterprise Linux Desktop 5 (RHLE5) but I have to work with OpenSuse 10.3. I did succeed in installing ISE & EDK 10.1 on OpenSuse 10.3 but it does not work for the Service Packs 3. Neither does Xilupdate works (see errror messages bellow). I successfully installed ISE & EDK 10.1 with Service Pack 3 (SP3) on CentOS5 (clone of RHLE5). It also works in VirtualBox under OpenSuse 10.3 what I could consider as an alternative solution. Since OpenSuse and SLE might be really similar, I am wondering here from some help to install the SP3 on OpenSuse 10.3. Some package may be needed to properly install the SP3, right ? I remember I add to install the package compat-db.x86_64 for the CentOS5 install. Thank community for any help. Nicolas -- Here are the command and error messages : /tmp/tools/Xilinx/downloaded_files/10_1_03_lin64 > ./setup QTextEdit::setProperty( "alignment", value ) failed: property invalid, read-only or does not exist QLayout "QHBoxLayout" added to QDialog "CWU_ProgressThr", which already has a layout ./setup: line 41: 18295 Segmentation fault $setuploc/bin/lin64/ xilinxupdate ./xilinxupdate and setup ends after 7% download. The same thing appens when we tempted to run directly xilupdate from ise directory tmp/tools/Xilinx/ISE/bin/lin64 > ./xilinxupdate after 4% downloadArticle: 139829
Hi all, Register : rcom_sync_time The rcom_sync_time register contains the current value of the RCOM sync timer, which is used to time tag received and transmitted messages. It will count to 131 ms before rolling over. It will satisfy the following requirements. 1) The rcom_sync_time register shall return the 17 bits (16:0) of the value of a free running timer that has the following properties. a) The timer has a resolution of 1us. b) The timer rolls over at 131ms. Could anyone give me the clear steps how to understand this requimrement. If it is not in sufficient manner than i can provide some more details.Article: 139830
Pete Fraser <pfraser@covad.net> wrote: (snip) > The other was debugging a system with a fair chunk > of CMOS (as well as some analog and ECL). > It was working, but not reliably, and it took me about > 15 minutes to realize I wasn't applying power to the > CMOS section. The whole section seemed to be > powering itself off the inputs. With protection diodes on the inputs, it will likely do that as long as at least one input is high (enough). I believe that there are circuits powered off RS-232 that use a similar power method, though likely with a capacitor to keep it running. -- glenArticle: 139831
KJ <kkjennings@sbcglobal.net> wrote: > On Apr 15, 7:41?am, Ben_Quem <B_quemen...@hotmail.com> wrote: >> Usually I will try to have a 10% slack on all generated clock : >> for 50 MHz (20ns) , I will try to get a worst case slack of 2ns >> for 100 MHz (10ns) , I will try to get a worst case slack of 1ns. > Defining the allowable slack as a percentage of clock period has no > rationale basis. A design that fails due to setup or hold timing will > do so because the input signal did not arrive at the correct time > relative to the sampling edge...that simple. Whether the clock > frequency of the signal that does the sampling is 100 MHz or 1 Hz is > not relevant. With the assumption that the clock period is based on the critical path propagation delay it doesn't seem so bad. For many designs, the considerations tend to scale with the propagation delay, and hence the minimum clock period. (snip) > You are free to assume whatever you would like, but you'll get no > support from the supplier for a failed design if you violate timing > requirements. The data sheets are generally specified to be valid > over certain operating temperature and voltage ranges. A given design > in many cases does not operate over the entire range so in that sense > there is likely some 'margin' in the numbers that the supplier lists > and might form some basis for using 0 slack. However, the other thing > that goes into the timing numbers that will not work in your favor are > the other test conditions, like the following all of which will > degrade timing (i.e. force you to consider having greater than 0 > slack) > - Osc period uncertainty (it's small, but it's not zero) Austin mentioned this one. > - I/O signal delays (signals don't get from here to there on a PCB in > zero time) Should be included in timing calculations. > - Signal quality (an input signal that takes a few round trips on the > PCB to settle down before being sampled requires much more time than a > terminated, no reflection signal) Yes, this one is important. > - Signal switching time (when does a slowly rising input really become > a '1'?) > - Jitter on DCM/PLLs (they're not zero) > - Supply voltage noise > There are many other effects to consider as well. -- glenArticle: 139832
Hi, We are looking at interfacing the Cyclone III EP3C40 with an SDRAM at 90 MHz. We are considering having the FPGA generate the clock to the interface and find a way to ensure both the sdram and the cyclone III are in phase regarding the clock. We could not find up to now a mechanism that would ensure that both the SDRAM and the cyclone III will have their clock almost with the same phase relationship over temperature, voltage and process. Could someone provide us with indications regarding the implementation ? Today we thought of using a specific PLL to generate a delayed clock towards the SDRAM so that we can compensate for the propagation delay of the clock towards the SDRAM. With this mechanism we do not see how process, temperature and voltage variations impacts on propagation delay will be taken care of. Could someone provide us with more explanations ? We are familiar with some board deskew features once available with Xilinx parts such as Virtex II or Virtex II Pro using two DLLs and performing board deskew but Altera does not seem to promote such mechanisms. Best regards, JFArticle: 139833
jean-francois hasson wrote: > We are looking at interfacing the Cyclone III EP3C40 with an SDRAM at 90 > MHz. We are considering having the FPGA generate the clock to the > interface and find a way to ensure both the sdram and the cyclone III > are in phase regarding the clock. We could not find up to now a > mechanism that would ensure that both the SDRAM and the cyclone III will > have their clock almost with the same phase relationship over > temperature, voltage and process. http://www.google.com/search?q=zero+delay+clock+bufferArticle: 139834
On Apr 15, 1:51=A0pm, JSreeniv <sreenivas.jyo...@gmail.com> wrote: > Hi all, > > Register : rcom_sync_time > > The rcom_sync_time register contains the current value of the RCOM > sync timer, which is used to time tag received and transmitted > messages. =A0It will count to 131 ms before rolling over. It will > satisfy the following requirements. > > 1) The rcom_sync_time register shall return the 17 bits (16:0) of the > value of a free running timer that has the following properties. > =A0 =A0 =A0 =A0 a) The timer has a resolution of 1us. > =A0 =A0 =A0 =A0 b) The timer rolls over at 131ms. > > Could anyone give me the clear steps how to understand this > requimrement. If it is not in sufficient manner than i can provide > some more details. Seems pretty clear to me: Timer counts up at a rate of one count per microsecond. Timer has 17 bits. Timer wraps back to zero after reaching 2^17 counts or approximately 131 milliseconds. Current value of the Timer is readable via a register called rcom_sync_time. So what part isn't clear?Article: 139835
>jean-francois hasson wrote: > >> We are looking at interfacing the Cyclone III EP3C40 with an SDRAM at 90 >> MHz. We are considering having the FPGA generate the clock to the >> interface and find a way to ensure both the sdram and the cyclone III >> are in phase regarding the clock. We could not find up to now a >> mechanism that would ensure that both the SDRAM and the cyclone III will >> have their clock almost with the same phase relationship over >> temperature, voltage and process. > >http://www.google.com/search?q=zero+delay+clock+buffer > I assume the fpga will write and read to the sdram with same clk. I wonder why the clk should stay in phase since the write implies source synchronous interface(clk and data go together, any delay affects both data and clk). while the read is destination synchronous(clk opposite data). I have done sdram at 154MHz with stratix II and simply optimised the timing window for both directions having estimated the board delay,without problem.Article: 139836
>>jean-francois hasson wrote: >> >>> We are looking at interfacing the Cyclone III EP3C40 with an SDRAM at >90 >>> MHz. We are considering having the FPGA generate the clock to the >>> interface and find a way to ensure both the sdram and the cyclone III >>> are in phase regarding the clock. We could not find up to now a >>> mechanism that would ensure that both the SDRAM and the cyclone III >will >>> have their clock almost with the same phase relationship over >>> temperature, voltage and process. >> >>http://www.google.com/search?q=zero+delay+clock+buffer >> > >I assume the fpga will write and read to the sdram with same clk. I wonder >why the clk should stay in phase since the write implies source >synchronous >interface(clk and data go together, any delay affects both data and clk). >while the read is destination synchronous(clk opposite data). >I have done sdram at 154MHz with stratix II and simply optimised the >timing window for both directions having estimated the board delay,without >problem. > one more issue,just realised. What do you mean by compensating for board delay,clk will always suffer the delay. Do you have another clock in sdram?Article: 139837
On Apr 13, 10:11=A0am, ivan <ivan.so...@gmail.com> wrote: > Hi, > I've been playing around with ISE 10.1 (and also 9.2i) and Spartan 3- > AN. > When I open Project Navigator, synthesize my design and program it > into FPGA using iMPACT, everything works fine. But, if I change > something in the design (like, for instance, turn on the LED that was > previously off), and start iMPACT again (it offers me to choose the > bit file, as it did the first time), for some reason it only downloads > the old design to the board, no matter that I chose the new bit file. > Things work normally when I close Xilinx altogether and start it up > again. > > Is this a bug, or did I skip some setup options? > > Please help, it's REALLY annoying to have to turn of the hole ISE > everytime I wan't to try something new! > > Thanks, > Ivan. Every so often we have the same issue. (the bit file is fine, so does the time stamp, the issue we belive have to do with cashing though not sure if impact or window). just close impact and reopen it. no need to close ise just impact. BW.Article: 139838
jean-francois hasson wrote: > We are looking at interfacing the Cyclone III EP3C40 with an SDRAM at 90 > MHz. We are considering having the FPGA generate the clock to the > interface and find a way to ensure both the sdram and the cyclone III > are in phase regarding the clock. Altera provides a comprehensive sdram controller wizard that should satisfy all your requirements. Regards, -- Mark McDougall, Engineer Virtual Logic Pty Ltd, <http://www.vl.com.au> 21-25 King St, Rockdale, 2216 Ph: +612-9599-3255 Fax: +612-9599-3266Article: 139839
On Apr 15, 4:19 pm, jean-francois hasson <jfhas...@club-internet.fr> wrote: > Hi, > > We are looking at interfacing the Cyclone III EP3C40 with an SDRAM at 90 > MHz. We are considering having the FPGA generate the clock to the > interface and find a way to ensure both the sdram and the cyclone III > are in phase regarding the clock. We could not find up to now a > mechanism that would ensure that both the SDRAM and the cyclone III will > have their clock almost with the same phase relationship over > temperature, voltage and process. Could someone provide us with > indications regarding the implementation ? > Today we thought of using a specific PLL to generate a delayed clock > towards the SDRAM so that we can compensate for the propagation delay of > the clock towards the SDRAM. With this mechanism we do not see how > process, temperature and voltage variations impacts on propagation delay > will be taken care of. Could someone provide us with more explanations ? > We are familiar with some board deskew features once available with > Xilinx parts such as Virtex II or Virtex II Pro using two DLLs and > performing board deskew but Altera does not seem to promote such mechanisms. > > Best regards, > > JF To be honest, I'm not sure why you are concerned with the routing delay on the PWB. Your SDRAM should be close to the FGPA to minimize SI issues and I would expect the routing delay to be under 1 ns. If you are using SDRAM that should be a reasonably small portion of the cycle time that it won't matter much. Still, if you need to reduce that, you can have the FPGA generate the clock, routing it to the SDRAM with a trace of a known length. Also route a second, identical clock output back to the FPGA with the same length trace. This may require some serpentine coils, but with a short route it shouldn't use too much board space. Then both devices will be receiving an external clock that is totally in phase other than any skew generated internally in the FPGA. RickArticle: 139840
Hi, What I was more worried about is the PVT compensation. Using the setup you suggest it should do. However we don't have much margin on the design so any ns we can get is welcome. Best regards, JFArticle: 139841
>Hi, > >What I was more worried about is the PVT compensation. Using the setup >you suggest it should do. However we don't have much margin on the >design so any ns we can get is welcome. > >Best regards, > >JF > I believe cyclone III allows for dynamic PLL configuration, see AN507 kadhiemArticle: 139842
Hi everybody, in my design i have a timing problem with an ADC. I have this problem since my design has become more dense: This is the ADC I'm using: AD677 (http://www.analog.com/static/ imported-files/data_sheets/AD677.pdf) My ADC-Entity has 3 inputs and 3 outputs. (see datasheet) BUSY: IN SCLK: IN SDATA: IN CAL: OUT CLK: OUT SAMPLE: OUT How do i now define the relationship between the CLK-output and the SCLK-input for example? In the datasheet are the timing- specifications. Abstract of my *.UCF file: NET ADC1_BUSY LOC = C25; NET ADC1_SCLK LOC = E24; NET ADC1_SDATA LOC = B24; NET ADC1_CAL LOC = E14; NET ADC1_CLK LOC = D11; NET "ADC1_SAMPLE" LOC = F14; I hope somebody with some experience in constraining a design can give me some hints. The only timing constraint i'm using right now is the period constraint for the 100 MHz-clock i'm using. I'm an absolute beginner in timing-constraint.... In advance thanks a lof for your help. sincerely yours Olli Here the whole UCF-File: CONFIG STEPPING = "2"; NET clk LOC = B13; NET ADC_reset LOC = G9; NET ADC1_BUSY LOC = C25; NET ADC1_CAL LOC = E14; NET ADC1_CLK LOC = D11; NET ADC1_SCLK LOC = E24; NET ADC1_SDATA LOC = B24; NET ADC2_BUSY LOC = F24; NET ADC2_CAL LOC = D13; NET ADC2_CLK LOC = D14; NET ADC2_SAMPLE LOC = C11; NET ADC2_SCLK LOC = C26; NET ADC2_SDATA LOC = E23; NET DEACTIVATE_N LOC = N25; NET MESS_DONE LOC = L26; NET MESS_ENABLE LOC = E2; NET M_RESET LOC = E1; NET DIP_STRING LOC = A4; NET DIP_TD_READMODE LOC = B6; NET DOUT LOC = C24; NET Druck_VCC LOC = F11; NET DIN LOC = A23; NET MCLK LOC = F16; NET SCLK LOC = B23; NET MITTLUNG_LED LOC = V25; NET MITTLUNG0 LOC = B4; NET MITTLUNG1 LOC = C6; NET modell_MESSUNG LOC = G10; NET SER_IN_0 LOC = U4; NET SER_IN_1 LOC = AA11; NET SER_OUT_0 LOC = V4; NET SER_OUT_1 LOC = AC11; NET "SER_OUT_2" LOC = AC15; NET "SER_IN_2" LOC = AC14; NET SHIFT_5_TO_3<7> LOC = AC12; NET SHIFT_5_TO_3<6> LOC = AA13; NET SHIFT_5_TO_3<5> LOC = AD13; NET SHIFT_5_TO_3<4> LOC = AB13; NET SHIFT_5_TO_3<3> LOC = AC13; NET SHIFT_5_TO_3<2> LOC = AA14; NET SHIFT_5_TO_3<1> LOC = AD14; NET SHIFT_5_TO_3<0> LOC = AB14; NET TASTER1 LOC = D2; NET TASTER2 LOC = D1; NET TD_out LOC = F12; NET TD_out2 LOC = F13; NET TD_VCC LOC = D16; NET TD_VCC2 LOC = D15; NET URX_LED LOC = K26; NET URX_TX_go_to LOC = C10; NET "clk" TNM_NET = clk; TIMESPEC TS_clk = PERIOD "clk" 10 ns; NET "mittlung_LED" LOC = V25; NET "ADC1_SAMPLE" LOC = F14; NET "EIN_kHZ" LOC = AA15; NET "EIN_kHz" LOC = AA15; NET "pin_x" LOC = AD25; NET "pin_y" LOC = AC19; NET "pin_z" LOC = AD19; NET "sync" LOC = AC16; NET "sendclk" LOC = AA16;Article: 139843
On Apr 15, 4:24=A0pm, austin <aus...@xilinx.com> wrote: > Ben, > > The advice you were given is safe, to be sure, but far too > conservative. > > The slack should be the total of all instabilities in the clock > period, both intrinsic, and extrinsic. > > If there was no phase noise (jitter), the slack could be zero. > > However, there is jitter on any oscillator, which might be 35 to 100 > ps peak to peak, and the jitter caused by all the signals switching > internally, and all the IOs switching externally. =A0This is "system > jitter" and may vary from hundreds of ps, to as much as two > nanoseconds (in the case of poor bypassing, extreme ground bounce, bad > signal integrity). > > In the "old days" designers would not care about signal integrity, or > power supply integrity, and then be overly conservative in their slack > to make up for their neglect. =A0Sometimes the system would still fail, > due to their ignorance. > > Now, the practice is to perform a reasonably good signal integrity > analysis, as well as follow best practices on bypassing and power > distribution. > > One adds all the peak to peak jitter sources (Xilinx ISE does this for > you, but you need to supply the system jitter number), quadratically: > that is peak to peak "adds" as the square root of the sum of the > squares. =A0100 ps of clock jitter, plus 200 ps of system jitter is sqr > (100^2+200^2) or ~224 ps peak to peak). > > The slack required is then just the peak -, or the minimum possible > clock period, which is 1/2 the 224, or 114 ps. > > Again, if you place a system jitter value in the tools, this will be > taken into account, and any slack will already have the system jitter, > DCM jitter, PLL jitter, and clock jitter accounted for. =A0Thus, a value > of 0 after taking these into account is acceptable. > > Once built, the system jitter should be measured, so that you are sure > you still have 0 or positive slack. > > Austin Thanks a Lot for all your answers. I understand I need to include/ understand my system jitter in order to get to timing closure. Thanks again BenArticle: 139844
Hi all I am a novice with timing constraint. I have a question about OFFSET OUT I am driving a 12 bits parallel DAC. DAC_DATA_OUT is the group representing the 12 bits data BUS. I have a DAC_DATA_OUT and a DAC_CLK signals I want to constraint. The data sheet of the DAC says the Input Setup time is 2ns min. (Data must be valid at least 2ns before the clock rising edge). (input hold time = 1.5 ns min) My main system clock CLK_20MHz is feeding a DCM which generate a CLK0_20MHz. I have DAC1_CLK <= CLK0_20MHz; I then have the following constraint : (A) : "DAC_CLK" OFFSET OUT 20 ns AFTER CLK_20MHz'HIGH (B) : "DAC_DATA_OUT" OFFSET 7 ns AFTER CLK_20MHz'HIGH With (A) I am saying my DAC_CLK will be at the PAD 20 ns after CLK_20MHz rising edge. Is 20 ns a exact value or a maximum time ?. i.e could my DAC_CLK be at the pads before 20 ns ? (Let's say 5 ns after CLK_20MHz Rising egde ?) With (B) I am saying my DAC_DATA_OUT will be at the PAD 7 ns after CLK_20MHz rising edge. To make sure the DAc will be sampling the digital signal at the right time we need to have a minimum of 2ns (setup time). if "SIGNAL" OFFSET OUT xx ns AFTER CLK'Rising , means the implemented design will have SIGNAL valid exactly xx ns (fixed time) after CLK'rising , then I can see the constraint (A) and (B) make sure I have DAC_DATA_OUT ready 13 ns (20ns - 7 ns) before DAC_CLK. But if this is not a fixed delay , then I can see a problem in the following case : Let's say this is not a fixed 20ns delay , but this is a maximum value , then it could be lower than 20ns. For exemple 5 ns . If (B) is really implemented with 7ns and (A) with 5 ns then we can see in this case my DAC_CLK'rising will be ready before DAC_DATA_OUT (negative SETUP time 5ns - 7ns = -2 ns). Could somebody please clarify the above. Thanks for your help BenArticle: 139845
Hi all I am a novice with timing constraint. I have a question about OFFSET OUT I am driving a 12 bits parallel DAC. DAC_DATA_OUT is the group representing the 12 bits data BUS. I have a DAC_DATA_OUT and a DAC_CLK signals I want to constraint. The data sheet of the DAC says the Input Setup time is 2ns min. (Data must be valid at least 2ns before the clock rising edge). (input hold time = 1.5 ns min) My main system clock CLK_20MHz is feeding a DCM which generate a CLK0_20MHz. I have DAC1_CLK <= CLK0_20MHz; I then have the following constraint : (A) : "DAC_CLK" OFFSET OUT 20 ns AFTER CLK_20MHz'HIGH (B) : "DAC_DATA_OUT" OFFSET 7 ns AFTER CLK_20MHz'HIGH With (A) I am saying my DAC_CLK will be at the PAD 20 ns after CLK_20MHz rising edge. Is 20 ns a exact value or a maximum time ?. i.e could my DAC_CLK be at the pads before 20 ns ? (Let's say 5 ns after CLK_20MHz Rising egde ?) With (B) I am saying my DAC_DATA_OUT will be at the PAD 7 ns after CLK_20MHz rising edge. To make sure the DAc will be sampling the digital signal at the right time we need to have a minimum of 2ns (setup time). if "SIGNAL" OFFSET OUT xx ns AFTER CLK'Rising , means the implemented design will have SIGNAL valid exactly xx ns (fixed time) after CLK'rising , then I can see the constraint (A) and (B) make sure I have DAC_DATA_OUT ready 13 ns (20ns - 7 ns) before DAC_CLK. But if this is not a fixed delay , then I can see a problem in the following case : Let's say this is not a fixed 20ns delay , but this is a maximum value , then it could be lower than 20ns. For exemple 5 ns . If (B) is really implemented with 7ns and (A) with 5 ns then we can see in this case my DAC_CLK'rising will be ready before DAC_DATA_OUT (negative SETUP time 5ns - 7ns = -2 ns). Could somebody please clarify the above. Thanks for your help BenArticle: 139846
> >This is probably a very basic question, but do analog circuits need >anything like reset? >For example, given that a PLL is mostly analog, does it need reset >input? > If the phase comparator is more complicated than an XOR gate, then that will benefit from reset.Article: 139847
wooster.berty@gmail.com escribió: > On Apr 13, 10:11 am, ivan <ivan.so...@gmail.com> wrote: >> Hi, >> I've been playing around with ISE 10.1 (and also 9.2i) and Spartan 3- >> AN. >> When I open Project Navigator, synthesize my design and program it >> into FPGA using iMPACT, everything works fine. But, if I change >> something in the design (like, for instance, turn on the LED that was >> previously off), and start iMPACT again (it offers me to choose the >> bit file, as it did the first time), for some reason it only downloads >> the old design to the board, no matter that I chose the new bit file. >> Things work normally when I close Xilinx altogether and start it up >> again. >> >> Is this a bug, or did I skip some setup options? >> >> Please help, it's REALLY annoying to have to turn of the hole ISE >> everytime I wan't to try something new! >> >> Thanks, >> Ivan. > > Every so often we have the same issue. (the bit file is fine, so does > the time stamp, the issue we belive have to do with cashing though not > sure if impact or window). > just close impact and reopen it. no need to close ise just impact. > BW. I see a similar issue some time and with specific Windows installations, but I'm not sure if a ISE bug or a file handle system bug. By some obscure reason - as a file system buffer actualization bug - when you run the implementation chain tools ISE use an older copy of your sources, then your bitstream has the correct time stamp but was generated from older sources. I see also that this issue was more frequent long debug sessions without shut-down the machine. One way to check this is Close ISE -> Restart Windows -> Open ISE and rerun all implementation and compare results. Additional info : I never catch this issue with our actual work points ISE 10.1.03 Windows XP SP3 3 GB RAM ISE 10.1.03 Ubuntu 8.04 1 GB RAM ISE 10.1.03 Ubuntu 8.10 1 GB RAM but was a "know issue" to us with ISE 8.2 Windows XP SP2 1 GB RAM WalterArticle: 139848
On Apr 16, 8:11=A0am, Ben_Quem <B_quemen...@hotmail.com> wrote: > Hi all > > I am a novice with timing constraint. > > I have a question about OFFSET OUT > I am driving a 12 bits parallel DAC. > DAC_DATA_OUT is the group =A0representing the 12 bits data BUS. > I have a DAC_DATA_OUT and a DAC_CLK signals I want to constraint. > The data sheet of the DAC says the Input Setup time is 2ns min. =A0(Data > must be valid at least 2ns before the clock rising edge). (input hold > time =3D 1.5 ns min) > My main system clock CLK_20MHz is feeding a DCM which generate a > CLK0_20MHz. > > I have DAC1_CLK <=3D CLK0_20MHz; > > I then have the following constraint : > > (A) : "DAC_CLK" OFFSET OUT 20 ns AFTER CLK_20MHz'HIGH > (B) : "DAC_DATA_OUT" OFFSET 7 ns AFTER CLK_20MHz'HIGH > > With (A) I am saying my DAC_CLK will be at the PAD 20 ns after > CLK_20MHz rising edge. > Is 20 ns a exact value or a maximum time ?. i.e could my DAC_CLK be at > the pads before 20 ns ? (Let's say 5 ns after CLK_20MHz Rising egde ?) > Yes. > With (B) I am saying my DAC_DATA_OUT will be at the PAD 7 ns after > CLK_20MHz rising edge. > Maximum 7 ns, no specified minimum. > To make sure the DAc will be sampling the digital signal at the right > time we need to have a minimum of 2ns (setup time). > > if "SIGNAL" OFFSET OUT xx ns AFTER CLK'Rising , means the implemented > design will have SIGNAL valid exactly xx ns (fixed time) after > CLK'rising , then I can see the constraint (A) and (B) make sure I > have DAC_DATA_OUT ready 13 ns (20ns - 7 ns) before DAC_CLK. > But if this is not a fixed delay , then I can see a problem in the > following case : > > Let's say this is not a fixed 20ns delay , but this is a maximum > value , then it could be lower than 20ns. For exemple 5 ns . > If (B) is really implemented with 7ns and (A) with 5 ns then we can > see in this case my DAC_CLK'rising will be > ready before DAC_DATA_OUT (negative SETUP time 5ns - 7ns =3D -2 ns). > > Could somebody please clarify the above. > > Thanks for your help > > Ben The standard way to handle setup and hold offsets for source synchronous clocking is to do it by design. The implementation tools are not set up to create minimum delays for you. You have choices: If your part has DDR output flip-flops, use one for the clock and IOB flip-flops for the data. This puts the edges of data and clock coincident at the pin. Make sure your clock phase is inverted so the correct edge for the DAC is in the center of the data period. If you don't have DDR output flip-flops, you can still invert the clock to the pin. Make sure that your clock to output delay is less than 1/2 clock cycle. Should be easy at 20 MHz. Regards, GaborArticle: 139849
Hi all I have trouble with a device from Xilinx, the Coolrunner II CPLD Starter Kit. The FPGA is XC2C256-7TQG144C. It was delivered with a resource CD (containing the required drivers) and the ISE10.1 design suite Take a look at http://www.xilinx.com/products/devkits/SK-CRII-L-G.htm for a complete description The device connects to the PC with a simple USB-cable, nothing else is required I followed instructions for installation as provided in the manual. USB-Drivers have been correctly installed. What happens: From iSE or even from Impact as stand alone application I try to communicate with the board. All settings are as displayed in the manual Impact says: Source driver files not found. The Platform Cable USB is not detected. Please connect a cable.If a cable is connected, please disconnect and reconnect to the usb port, follow the instructions in the 'Found New Hardware Wizard', then retry the Cable Setup operation. Cable connection failed ... Reconnecting is not resulting in a message 'Found New Hardware' as everything is properly installed (usb drivers before plugging in the device) I tried on another computer with the same result. Can anyone solve this problem ? Thanks a lot Gert
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