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 May 28, 5:05=A0am, Bert_Paris <do_not_s...@me.com> wrote: > Nad a formul=E9 la demande : > > > Hi, > > I didn't find any information concerning cyclone3 device and other seri= al > > flash connection thant the Altera ones. > > I would like to implement a cyclone3 FPGA with an AT45DB serial flash b= ut > > find nowhere some explanation on this point. > > Does anybody already try to do this? or does anybody have a paper on > > this? > > > THanks in advance > > > Nad > > Hi Nad, > > I suggest you carefully compare your Atmel Flash commands vs Altera's > EPCS that are described at :http://www.altera.com/literature/hb/cfg/cyc_c= 51014.pdf > I know by experience that many serial flash devices (ST, Numonics...) > are "quite compatible". > It's not had to be compatible enough to be used to hold the bitstream & > load the FPGA at powerup. If you want to use the standard Altera > programming tools, you need to check more commands beyond the simple > read operations (you'll need erase and write, indeed). Update > incompatibility can be overcome by using other tools, including remote > update through the FPGA (we have implemented this remote programming > option in our Ethernet kit). > > Hope this helps, > Bert Are you saying you have successfully used commodity SPI flash in lieu of an EPCS device? By all rights, it should work electrically. Given the Spartan 3E and Virtex 5 can both boot from nearly any commodity SPI flash, I'm a bit surprised Altera hasn't followed suit However, I'm spinning a board right now with a Cyclone III, and I would *LOVE* to be able to drop the EPCS in favor of a cheap SPI flash - even if I have to write the programming firmware myself.Article: 140951
Hello, just some questions concerning the EAPR flow for Xilinx.. The examples related to the EAPR allow to access the bitstreams stored in a compact flash (SystemACE) .. Has any body any experience in moving the bitstreams to a DDR RAM initially and let the ICAP access the bitstreams from there .. ? What are the advantages and disadvantages .. Also i would like to know if there are any C functions that i can add to the processor code to print out the reconfiguration time between the switching of the bitstreams ? Thanks QuadriArticle: 140952
On May 30, 11:16=A0am, j...@beniston.com wrote: > > From what I have read it is not the binary code that is a problem. =A0I > > don't think you can patent that. > > Sure. However, as you mention, there are some instructions / features > that may be difficult to implement without violating a patent, thereby > meaning you are not 100% compatible (not that the various ARMs > themselves are). For patents possibly covering instructions, you > have: > > 5583804: Data processing using multiply-accumulate instructions > > Although there was some evidence in the picoTurbo case that this > patent may not be valid has it had been publicly disclosed before > filing. > > > =A0ARM patented some aspect of their > > interrupt handling that is essential to a correct implementation. > > I'm =A0not sure when that runs out, but that is the only patent I know > > of in the ARM family that can't be designed around. =A0 > > That is 5386563: Register substitution during exception processing. It > has a couple more years before it expires. > There is also 5701493: Exception handling method and apparatus in data > processing systems > > There is potentially prior art that would invalidate 5386563. > > Then you have the patents covering thumb mode: > > 5758115/6021265: Interoperability with multiple instruction sets > 5568646: Multiple instruction set mapping > 5740461: Data processing with multiple instruction sets > > If you have a single decoder you might be able to work around these. > > There's probably a few others as well. > > Jon I'm not sure how many of these would actually be an issue in an FPGA implementation of the ARM instruction set. I believe a patent covers an implementation of a concept, not the concept itself. So if you can get the job done without using the same implementation, you should be ok. But I have not read any of these patents. I read here or another newsgroup that the problem was the particular patent relating to the interrupt handling would be very hard to work around. RickArticle: 140953
> I'm not sure how many of these would actually be an issue in an FPGA > implementation of the ARM instruction set. =A0I believe a patent covers > an implementation of a concept, not the concept itself. =A0 Doesn't it depend if the claims are method or apparatus? JonArticle: 140954
I got same situations on ubuntu 9.04, ise 10.1 libusb has solved the problem, but not for 11.1, what's happened on xilinx guys? 8-( PS: the cable driver sames works, couse the LED is on, but iMPACT refuse to recognize it, that's bad. anyone has the cure?Article: 140955
On Jun 1, 3:34=A0am, Charles <chr...@gmail.com> wrote: > I got same situations on ubuntu 9.04, ise 10.1 libusb has solved the > problem, but not for 11.1, what's happened on xilinx guys? =A0 8-( > > PS: the cable driver sames works, couse the LED is on, but iMPACT > refuse to recognize it, that's bad. > > anyone has the cure? I finally found the reason, the libusb package installed by apt-get in ubuntu 9.04 DIDN'T has the soft link named "libusb.so", so you need do this to fix the problem: sudo ln -s /lib/libusb-0.1.so.4.4.4 libusb.so and the cable works fine now. hope this help.Article: 140956
On May 29, 6:33 pm, rickman <gnu...@gmail.com> wrote: > On May 29, 3:25 pm, jleslie48 <j...@jonathanleslie.com> wrote: > > > > > On May 29, 1:47 pm, doug <x...@xx.com> wrote: > > > > jleslie48 wrote: > > > > On May 29, 10:52 am, doug <x...@xx.com> wrote: > > > > >>>I haven't mentioned jitter because I simply do not know. As I'm > > > >>>working with a relatively slow clock of 2MHz, I can't believe that > > > >>>jitter is an issue. I'm synching a RS485 signal if that answers the > > > >>>question. > > > > >>I am puzzled. If all you want to do is decode a serial signal, why > > > >>not just decode it with a higher speed clock as is done in a > > > >>regular UART? If you are sending, you can generate a clock within > > > >>the tolerance of the other receiver without any trouble. > > > > > this is how I DECODE the serial signal. I'm not trying to decode it > > > > at this time, but rather have my fpga repeat the signal with no phase > > > > difference when the signal is lost. > > > > I see the requirement now. Decoding the signal and retransmitting it > > > makes it easy to deal with loss of signal but how do you deal with > > > reacquisition of signal and fitting that nicely into a data stream? > > > > > The point is my fpga is a middleware layer, and it cannot add any > > > > phase difference to the downstream consumer of the signal. I do know > > > > know or have control of the end consumer of the data stream. > > > > This always makes it harder. > > > I've created a semaphore flag to mark who is creating the output > > signal to the downstream consumers. If the inbound signal is missing, > > I use the internally generated signal. On acquisition of the inbound > > signal, I set the semaphore to adjust the output signal to that, and > > that [will] trigger this new ~re-sync~ the internally generated signal > > to the newly aquirred inbound signal. Should the inbound signal then > > be lost, the internal signal will have already been set up to the > > exact phase of the last known inbound, and so the downstream device > > should be unaware of the difference (plus or minus a few clock > > pulses.) The idea is if the loss of signal is due to a wire > > disconnect, when the user reconnects the wire, everything is the > > same. If he has re-cycled the power on the producer, well then the > > act of re-acquisition of will reset the internally generated signal > > for the new rs485 signal. > > Is this clock a sine wave or a digital clock? I see people talking > about using a DDS with ROM and DAC to generate a sine wave. Is that > what you need or is this just a digital problem? > > I am also working on a similar problem. It is actually detecting a > clock within the data, but the same problem, to continue the clock > with minimal change in phase when no transitions are present in the > data. You need to spec what time duration you expect this to work > over. Unless both producers of the clock signal are running from a > common reference clock, there will always be some slip in phase since > the frequencies are not exactly the same. > > When the input returns, you need to make sure the internal DCO > (digitally controlled oscillator, no ROM table to generate a sine > wave) adjusts slowly so the downstream device is not upset by the wide > frequency changes. But that is a matter of specification. > > The part of this which may be subtle is the design of the PLL, in > particular the filter. This determines the response of the PLL to > changes in the input and how stable the output will be. I am still > working to prove that my design is stable for all inputs (input being > not just the input to the board, but the input after it has been > synchronized which produces some modulation). > > Rick straight digital signal. I don't have exact specifications as to how much off-phase is acceptable. Its a strange project. Basically I have a producer consumer pair made by a company, and a customer who wants to be able to open up the consumer portion of the product to multiple vendors. My company has won the contract to make the middle- ware converter, but the original developer of the producer-consumer has not been all to forth-coming with how the interaction between the pair works. Its a bit weird, they have a vested interest in not opening the system up to other vendors, its not a surprise to me that I have little to go on.Article: 140957
On May 31, 6:00=A0pm, jleslie48 <j...@jonathanleslie.com> wrote: > On May 29, 6:33 pm, rickman <gnu...@gmail.com> wrote: > > > > > On May 29, 3:25 pm, jleslie48 <j...@jonathanleslie.com> wrote: > > > > On May 29, 1:47 pm, doug <x...@xx.com> wrote: > > > > > jleslie48 wrote: > > > > > On May 29, 10:52 am, doug <x...@xx.com> wrote: > > > > > >>>I haven't mentioned jitter because I simply do not know. =A0As I= 'm > > > > >>>working with a relatively slow clock of 2MHz, I can't believe th= at > > > > >>>jitter is an issue. =A0I'm synching a RS485 signal if that answe= rs the > > > > >>>question. > > > > > >>I am puzzled. If all you want to do is decode a serial signal, wh= y > > > > >>not just decode it with a higher speed clock as is done in a > > > > >>regular UART? =A0If you are sending, you can generate a clock wit= hin > > > > >>the tolerance of the other receiver without any trouble. > > > > > > this is how I DECODE the serial signal. =A0I'm not trying to deco= de it > > > > > at this time, but rather have my fpga repeat the signal with no p= hase > > > > > difference when the signal is lost. > > > > > I see the requirement now. Decoding the signal and retransmitting i= t > > > > makes it easy to deal with loss of signal but how do you deal with > > > > reacquisition of signal and fitting that nicely into a data stream? > > > > > > The point is my fpga is a middleware layer, and it cannot add any > > > > > phase difference to the downstream consumer of the signal. I do k= now > > > > > know or have control of the end consumer of the data stream. > > > > > This always makes it harder. > > > > I've created a semaphore flag to mark who is creating the output > > > signal to the downstream consumers. =A0If the inbound signal is missi= ng, > > > I use the internally generated signal. =A0On acquisition of the inbou= nd > > > signal, I set the semaphore to adjust the output signal to that, and > > > that [will] trigger this new ~re-sync~ the internally generated signa= l > > > to the newly aquirred inbound signal. =A0Should the inbound signal th= en > > > be lost, the internal signal will have already been set up to the > > > exact phase of the last known inbound, and so the downstream device > > > should be unaware of the difference (plus or minus a few clock > > > pulses.) =A0 The idea is if the loss of signal is due to a wire > > > disconnect, when the user reconnects the wire, everything is the > > > same. =A0If he has re-cycled the power on the producer, well then the > > > act of re-acquisition of will reset the internally generated signal > > > for the new rs485 signal. > > > Is this clock a sine wave or a digital clock? =A0I see people talking > > about using a DDS with ROM and DAC to generate a sine wave. =A0Is that > > what you need or is this just a digital problem? > > > I am also working on a similar problem. =A0It is actually detecting a > > clock within the data, but the same problem, to continue the clock > > with minimal change in phase when no transitions are present in the > > data. =A0You need to spec what time duration you expect this to work > > over. =A0Unless both producers of the clock signal are running from a > > common reference clock, there will always be some slip in phase since > > the frequencies are not exactly the same. > > > When the input returns, you need to make sure the internal DCO > > (digitally controlled oscillator, no ROM table to generate a sine > > wave) adjusts slowly so the downstream device is not upset by the wide > > frequency changes. =A0But that is a matter of specification. > > > The part of this which may be subtle is the design of the PLL, in > > particular the filter. =A0This determines the response of the PLL to > > changes in the input and how stable the output will be. =A0I am still > > working to prove that my design is stable for all inputs (input being > > not just the input to the board, but the input after it has been > > synchronized which produces some modulation). > > > Rick > > straight digital signal. =A0I don't have exact specifications as to how > much off-phase is acceptable. =A0Its a strange project. =A0Basically I > have a producer consumer pair made by a company, and a customer who > wants to be able to open up the consumer portion of the product to > multiple vendors. =A0 My company has won the contract to make the middle- > ware converter, but the original developer of the producer-consumer > has not been all to forth-coming with how the interaction between the > pair works. =A0Its a bit weird, they have a vested interest in not > opening the system up to other vendors, its not a surprise to me that > I have little to go on. On May 27 I described a solution, but nobody ever commented on it... Peter AlfkeArticle: 140958
I'm using a Micrel KSZ9021GQ Gigabit Ethernet PHY for a project, and I noticed while looking through the data sheet that the TX_CLK and GTX_CLK are on the same pin. In 10/100 mode, it works as expected for MII mode - 2.5MHz or 25MHz output to the MAC. In 1000 mode, it turns into an input, and the FPGA has to source 125MHz to the PHY. The core I'm using has the two clocks as separate ports. I had planned to simply tie an output pin to an dedicated clock input pin, and route that to the combined pin on the PHY. The clock input will see all of the input clocks, but I can at least tri-state the output driver in 10/100 mode. My question is how to do this safely. It may take several microseconds to figure out when the PHY has switched modes - either using MDIO or looking at the LED signals. I would assume that there would be a period where none of the link indicators are active, which I could use to shut off the GMII transmit clock. Has anyone else used this part, or one like it, and solved this one? For reference, I'm using a Cyclone III EP3C16. The TX_CLK input is routed to a global clock net, and the GTX_CLK output is on a nearby single-ended pin. I put a 50-ohm resistor near the FPGA - since it's sourcing the fastest clock. Thanks! -SethArticle: 140959
jleslie48 wrote: > On May 29, 6:33 pm, rickman <gnu...@gmail.com> wrote: > >>On May 29, 3:25 pm, jleslie48 <j...@jonathanleslie.com> wrote: >> >> >> >> >>>On May 29, 1:47 pm, doug <x...@xx.com> wrote: >> >>>>jleslie48 wrote: >>>> >>>>>On May 29, 10:52 am, doug <x...@xx.com> wrote: >> >>>>>>>I haven't mentioned jitter because I simply do not know. As I'm >>>>>>>working with a relatively slow clock of 2MHz, I can't believe that >>>>>>>jitter is an issue. I'm synching a RS485 signal if that answers the >>>>>>>question. >> >>>>>>I am puzzled. If all you want to do is decode a serial signal, why >>>>>>not just decode it with a higher speed clock as is done in a >>>>>>regular UART? If you are sending, you can generate a clock within >>>>>>the tolerance of the other receiver without any trouble. >> >>>>>this is how I DECODE the serial signal. I'm not trying to decode it >>>>>at this time, but rather have my fpga repeat the signal with no phase >>>>>difference when the signal is lost. >> >>>>I see the requirement now. Decoding the signal and retransmitting it >>>>makes it easy to deal with loss of signal but how do you deal with >>>>reacquisition of signal and fitting that nicely into a data stream? >> >>>>>The point is my fpga is a middleware layer, and it cannot add any >>>>>phase difference to the downstream consumer of the signal. I do know >>>>>know or have control of the end consumer of the data stream. >> >>>>This always makes it harder. >> >>>I've created a semaphore flag to mark who is creating the output >>>signal to the downstream consumers. If the inbound signal is missing, >>>I use the internally generated signal. On acquisition of the inbound >>>signal, I set the semaphore to adjust the output signal to that, and >>>that [will] trigger this new ~re-sync~ the internally generated signal >>>to the newly aquirred inbound signal. Should the inbound signal then >>>be lost, the internal signal will have already been set up to the >>>exact phase of the last known inbound, and so the downstream device >>>should be unaware of the difference (plus or minus a few clock >>>pulses.) The idea is if the loss of signal is due to a wire >>>disconnect, when the user reconnects the wire, everything is the >>>same. If he has re-cycled the power on the producer, well then the >>>act of re-acquisition of will reset the internally generated signal >>>for the new rs485 signal. >> >>Is this clock a sine wave or a digital clock? I see people talking >>about using a DDS with ROM and DAC to generate a sine wave. Is that >>what you need or is this just a digital problem? >> >>I am also working on a similar problem. It is actually detecting a >>clock within the data, but the same problem, to continue the clock >>with minimal change in phase when no transitions are present in the >>data. You need to spec what time duration you expect this to work >>over. Unless both producers of the clock signal are running from a >>common reference clock, there will always be some slip in phase since >>the frequencies are not exactly the same. >> >>When the input returns, you need to make sure the internal DCO >>(digitally controlled oscillator, no ROM table to generate a sine >>wave) adjusts slowly so the downstream device is not upset by the wide >>frequency changes. But that is a matter of specification. >> >>The part of this which may be subtle is the design of the PLL, in >>particular the filter. This determines the response of the PLL to >>changes in the input and how stable the output will be. I am still >>working to prove that my design is stable for all inputs (input being >>not just the input to the board, but the input after it has been >>synchronized which produces some modulation). >> >>Rick > > > straight digital signal. I don't have exact specifications as to how > much off-phase is acceptable. Its a strange project. Basically I > have a producer consumer pair made by a company, and a customer who > wants to be able to open up the consumer portion of the product to > multiple vendors. My company has won the contract to make the middle- > ware converter, but the original developer of the producer-consumer > has not been all to forth-coming with how the interaction between the > pair works. Its a bit weird, they have a vested interest in not > opening the system up to other vendors, its not a surprise to me that > I have little to go on. At least it makes your life interesting. Good luck. >Article: 140960
I am using Virtex4 FPGA at really low frequecy (150KHz). I need to double the clock at this frequency and would like to use DCM for it. I am not sure if the DCM in V4 LX100 can take such low frequency. Any ideas will be great. Thanks. CPArticle: 140961
On May 31, 8:00=A0pm, cpan...@yahoo.com wrote: > I am using Virtex4 FPGA at really low frequecy (150KHz). =A0I need to > double the clock at this frequency and would like to use DCM for it. > I am not sure if the DCM in V4 LX100 can take such low frequency. > > Any ideas will be great. > > Thanks. > > CP The DCM cannot handle this, but I published a circuit many years ago, in the "Six easy pieces" group: Run your low frequency through an XNOR circuit, its output is the doubled frequency. That output also clocks a flip-flop whose Q output, through an inverter, feeds its own D input. Obviously a toggling flip-flop. That D input is also connected to the other input of the XNOR gate. That's all. Here is the text: 4. Double the Clock Frequency An input signal can be doubled in frequency, provided the resulting 2f clock can tolerate cycle-to-cycle jitter caused by an imperfect input duty cycle. The circuit described above generates an output pulse in response to each transition of the input. The output rising edge is delayed one TILO from either input transition. The output High time is the sum of a clock-to-Q delay plus two TILO delays, about 2 ns in a fast part. This output pulse clocks other flip-flops on the same die reliably. (At a low temperature and high VCC, the pulse will be shorter, but the flip-flop response is also faster under these conditions.) Any control input that prevents the flip-flop from toggling changes the output frequency to fout =3D fin. This asynchronous circuit is frowned upon by all true digital designers. It should only be used as a tool of last resort. Note that the DLL or DCM in all Virtex or Spartan-II devices provide frequency doubling for free, if the input frequency is larger than 25 MHz. The frequency-doubler circuit explained above has no minimum frequency limitation.Article: 140962
I have a implemented design based on MIG2.3, which supports the following kind of 200pin DDR2 SODIMM modules: MT4HTF1664HY MT4HTF3264HY MT4HTF6464HY I noted that the three modules all have 4 chips in one module, and these modules are very hard to buy. While there are a lot of different types of SODIMM modules in markets, most of them have 8 or 16 chips in one module. Since the 200-pin SODIMM is a memory interface standard, could I use these modules instead? Need I change the FPGA deisgn or not? Need I change the board schematic or not?Article: 140963
Hi as this comes to topic again and again, and as it is no longer available from the original location and as i have it converted to PDF and as I happen to have one "micro IP" based on the ideas described there, i did upload this PDF version should be accessible as http://antti-brain.googlegroups.com/web/6EASY.pdf it is based on snapshot taken from web.archive.com, hopefully i get no C&D letters now (well i would just remove the document then :) AnttiArticle: 140964
On 1 June, 04:40, Peter Alfke <al...@sbcglobal.net> wrote: > On May 31, 6:00=A0pm, jleslie48 <j...@jonathanleslie.com> wrote: > > > > > On May 29, 6:33 pm, rickman <gnu...@gmail.com> wrote: > > > > On May 29, 3:25 pm, jleslie48 <j...@jonathanleslie.com> wrote: > > > > > On May 29, 1:47 pm, doug <x...@xx.com> wrote: > > > > > > jleslie48 wrote: > > > > > > On May 29, 10:52 am, doug <x...@xx.com> wrote: > > > > > > >>>I haven't mentioned jitter because I simply do not know. =A0As= I'm > > > > > >>>working with a relatively slow clock of 2MHz, I can't believe = that > > > > > >>>jitter is an issue. =A0I'm synching a RS485 signal if that ans= wers the > > > > > >>>question. > > > > > > >>I am puzzled. If all you want to do is decode a serial signal, = why > > > > > >>not just decode it with a higher speed clock as is done in a > > > > > >>regular UART? =A0If you are sending, you can generate a clock w= ithin > > > > > >>the tolerance of the other receiver without any trouble. > > > > > > > this is how I DECODE the serial signal. =A0I'm not trying to de= code it > > > > > > at this time, but rather have my fpga repeat the signal with no= phase > > > > > > difference when the signal is lost. > > > > > > I see the requirement now. Decoding the signal and retransmitting= it > > > > > makes it easy to deal with loss of signal but how do you deal wit= h > > > > > reacquisition of signal and fitting that nicely into a data strea= m? > > > > > > > The point is my fpga is a middleware layer, and it cannot add a= ny > > > > > > phase difference to the downstream consumer of the signal. I do= know > > > > > > know or have control of the end consumer of the data stream. > > > > > > This always makes it harder. > > > > > I've created a semaphore flag to mark who is creating the output > > > > signal to the downstream consumers. =A0If the inbound signal is mis= sing, > > > > I use the internally generated signal. =A0On acquisition of the inb= ound > > > > signal, I set the semaphore to adjust the output signal to that, an= d > > > > that [will] trigger this new ~re-sync~ the internally generated sig= nal > > > > to the newly aquirred inbound signal. =A0Should the inbound signal = then > > > > be lost, the internal signal will have already been set up to the > > > > exact phase of the last known inbound, and so the downstream device > > > > should be unaware of the difference (plus or minus a few clock > > > > pulses.) =A0 The idea is if the loss of signal is due to a wire > > > > disconnect, when the user reconnects the wire, everything is the > > > > same. =A0If he has re-cycled the power on the producer, well then t= he > > > > act of re-acquisition of will reset the internally generated signal > > > > for the new rs485 signal. > > > > Is this clock a sine wave or a digital clock? =A0I see people talking > > > about using a DDS with ROM and DAC to generate a sine wave. =A0Is tha= t > > > what you need or is this just a digital problem? > > > > I am also working on a similar problem. =A0It is actually detecting a > > > clock within the data, but the same problem, to continue the clock > > > with minimal change in phase when no transitions are present in the > > > data. =A0You need to spec what time duration you expect this to work > > > over. =A0Unless both producers of the clock signal are running from a > > > common reference clock, there will always be some slip in phase since > > > the frequencies are not exactly the same. > > > > When the input returns, you need to make sure the internal DCO > > > (digitally controlled oscillator, no ROM table to generate a sine > > > wave) adjusts slowly so the downstream device is not upset by the wid= e > > > frequency changes. =A0But that is a matter of specification. > > > > The part of this which may be subtle is the design of the PLL, in > > > particular the filter. =A0This determines the response of the PLL to > > > changes in the input and how stable the output will be. =A0I am still > > > working to prove that my design is stable for all inputs (input being > > > not just the input to the board, but the input after it has been > > > synchronized which produces some modulation). > > > > Rick > > > straight digital signal. =A0I don't have exact specifications as to how > > much off-phase is acceptable. =A0Its a strange project. =A0Basically I > > have a producer consumer pair made by a company, and a customer who > > wants to be able to open up the consumer portion of the product to > > multiple vendors. =A0 My company has won the contract to make the middl= e- > > ware converter, but the original developer of the producer-consumer > > has not been all to forth-coming with how the interaction between the > > pair works. =A0Its a bit weird, they have a vested interest in not > > opening the system up to other vendors, its not a surprise to me that > > I have little to go on. > > On May 27 I described a solution, but nobody ever commented on it... > Peter Alfke Peter, there is not always comments on feedback on useful postings, sure some did see it hm, i wonder that there is no DPLL IP cores on the public someone must have used similar methods AnttiArticle: 140965
On May 31, 9:00 pm, jleslie48 <j...@jonathanleslie.com> wrote: > On May 29, 6:33 pm, rickman <gnu...@gmail.com> wrote: > > > Is this clock a sine wave or a digital clock? I see people talking > > about using a DDS with ROM and DAC to generate a sine wave. Is that > > what you need or is this just a digital problem? > > > I am also working on a similar problem. It is actually detecting a > > clock within the data, but the same problem, to continue the clock > > with minimal change in phase when no transitions are present in the > > data. You need to spec what time duration you expect this to work > > over. Unless both producers of the clock signal are running from a > > common reference clock, there will always be some slip in phase since > > the frequencies are not exactly the same. > > > When the input returns, you need to make sure the internal DCO > > (digitally controlled oscillator, no ROM table to generate a sine > > wave) adjusts slowly so the downstream device is not upset by the wide > > frequency changes. But that is a matter of specification. > > > The part of this which may be subtle is the design of the PLL, in > > particular the filter. This determines the response of the PLL to > > changes in the input and how stable the output will be. I am still > > working to prove that my design is stable for all inputs (input being > > not just the input to the board, but the input after it has been > > synchronized which produces some modulation). > > > Rick > > straight digital signal. I don't have exact specifications as to how > much off-phase is acceptable. Its a strange project. Basically I > have a producer consumer pair made by a company, and a customer who > wants to be able to open up the consumer portion of the product to > multiple vendors. My company has won the contract to make the middle- > ware converter, but the original developer of the producer-consumer > has not been all to forth-coming with how the interaction between the > pair works. Its a bit weird, they have a vested interest in not > opening the system up to other vendors, its not a surprise to me that > I have little to go on. So I guess you are just going to have to try and if it doesn't work, analyze the result and try again. Do you have any visibility into the consumer box or is that verboten? The real question is, did your company bid a fixed price or cost plus? ;^) RickArticle: 140966
On May 29, 9:15=A0pm, "MikeWhy" <boat042-nos...@yahoo.com> wrote: > "Mike Treseler" <mtrese...@gmail.com> wrote in message > > news:78b42pF1lj91bU1@mid.individual.net... > > > Weng Tianxiang wrote: > > >> I don't like to print download version of many documents. The download > >> prints are huge and not easy to keep them in order. > > >http://www.google.com/search?q=3Dkindle+dx > > A not unreasonable alternative today is to take the same $500 and buy a g= ood > double sided network printer (HP P2015N) and a 19 ring comb binder. OTOH,= I > might be just sore that I spent my $500 and did just that. For sure, eith= er > way is faster, more convenient, and overall cheaper than sending every > document to Kinkos for printing. > > I have a few reservations about the Kindle DX. If you have one and use it > for, specifically, Xilinx and similar other PDF documents, can you fill m= e > in on how well it's working for you? I'm mostly interested in comparing e= ase > of use to printed, letter size documents. Is the screen a full letter siz= e > page in size? If not, is it reasonably easy to zoom and navigate? How eas= y > is it to download your documents to the device? Can you at least minimall= y > search the document for specific text? Does it work well with the PDF tab= le > of contents and bookmarks? I'm not especially keen on the wireless servic= e > charges, and would prefer to focus on its equivalence to a printed page. > Thanks. Quite frankly I would think that the whole idea of Kindle misses the original point of having the book in print. If you want an electronic reader, your PC is still better than Kindle. If you want the convenience of printed pages you can cover your desk with, mark up, quickly scan through, etc. you still really want a print. Maybe Xilinx is missing an opportunity to sell printed user guides, but my guess is that the real reason printed manuals are going away is the rate at which the data becomes obsolete or otherwise irrelevant. One of my colleagues here likes to print the user guides reduced to half-size thereby getting 4 pages to a sheet of letter paper. Then bound along the long side you can see four pages at a time. Try that on a PC screen... Regards, GaborArticle: 140967
On May 30, 1:18=A0pm, "Phil Jessop" <p...@noname.org> wrote: > "rana" <rande...@gmail.com> wrote in message > > news:4df88a41-379c-4494-a721-c5b76369bfa7@h11g2000yqb.googlegroups.com... > > > hi, > > i have an asynchronous fifo that i need to time constrain. please help > > me with this. > > > rd clk =3D 50mhz > > wr clk =3D 200mhz > > gray count is passed from on domain to another > > > thank you, > > randeel. > > To save trashing data, first you need to ensure rd clk freq > wr clk freq Actually you don't know that without more information about the system. I assume there is a write enable as well as a write clock, and that the average write data rate is below the maximum read data rate? In any case, since the two clocks are presumed asynchronous, the interface timing between the clocks needs to work by design, i.e. no constraints will help there. Each clock domain would need a period constraint, and you could place some "ignore" style constraints to avoid unnecessary warnings about clock crossings, especially if the two clocks are actually related and the synthesis tool attempts to meet sub-cycle timing. Regards, GaborArticle: 140968
Hi, I am trying simulating xapp1113 in Matlab simulink. The following message appears. I don't know how to solve it. Anyone can shed some light on it? Thanks a lot. HDL compilation failed. ERROR:HDLParsers:3281 - "C:/DOCUME~1/WNS/LOCALS~1/Temp/xlisim4a23e7da/ xlisim_xldds_compilerv11.vhd" Line 70. behavioral is not an architecture body for dds_compiler_v2_0 in library XilinxCoreLib. Error occurred during "Simulation Initialization".Article: 140969
Hi, I am trying simulating a small Xilinx example with a DDS in Matlab simulink. The following message appears. I don't know how to solve it. Anyone can shed some light on it? Thanks a lot. HDL compilation failed. ERROR:HDLParsers:3281 - "C:/~Temp/xlisim4a23e7da/ xlisim_xldds_compilerv11.vhd" Line 70. behavioral is not an architecture body for dds_compiler_v2_0 in library XilinxCoreLib. Error occurred during "Simulation Initialization".Article: 140970
[Haven't yet figured out the fauna of forums.xilinx.com. I posted there
first, but received no reply, so I'm opting for the tried and true c.a.f.]
I'm working on some XDL tools, and I need an upper bound on the number
of tiles in the largest Virtex6 devices. The ISE 11.1 info doesn't yet
list any support for Virtex6, so I wondered if anybody else might happen
to know. Note that dimensions like SLICE_XnYm are insufficient for my
purposes.
If anybody with access to the right tools is willing to check, the
following should work for the xc6vlx760:
xdl -report xc6vlx760
grep tiles xc6vlx760.xdlrc
The two lines that come out of that would give me the row and column and
total tile counts.
Article: 140971On 1 June, 18:20, Neil Steiner <neil.stei...@east.isi.edu> wrote: > [Haven't yet figured out the fauna of forums.xilinx.com. =A0I posted ther= e > first, but received no reply, so I'm opting for the tried and true c.a.f.= ] > > I'm working on some XDL tools, and I need an upper bound on the number > of tiles in the largest Virtex6 devices. =A0The ISE 11.1 info doesn't yet > list any support for Virtex6, so I wondered if anybody else might happen > to know. =A0Note that dimensions like SLICE_XnYm are insufficient for my > purposes. > > If anybody with access to the right tools is willing to check, the > following should work for the xc6vlx760: > > =A0 =A0 =A0xdl -report xc6vlx760 > =A0 =A0 =A0grep tiles xc6vlx760.xdlrc > > The two lines that come out of that would give me the row and column and > total tile counts. if somebody would tell you this, Xilinx would sue them this info still under NDA, until the 11.1 SP1 is out AnttiArticle: 140972
On Jun 1, 11:17=A0am, fl <rxjw...@gmail.com> wrote: > Hi, > I am trying simulating a small Xilinx example with a DDS in Matlab > simulink. The following > message appears. I don't know how to solve it. Anyone can shed some > light on it? Thanks a lot. > > HDL compilation failed. > ERROR:HDLParsers:3281 - > =A0 =A0"C:/~Temp/xlisim4a23e7da/ > xlisim_xldds_compilerv11.vhd" > =A0 =A0Line 70. behavioral is not an architecture body for > dds_compiler_v2_0 in > =A0 =A0library XilinxCoreLib. > > Error occurred during "Simulation Initialization". I find the error part is a VHDL configuration routine, see below. I cannot find any solution of it. Can you help me out? Thanks. -- Configuration specification for all : wrapped_dds_compiler_virtex5_2_0_87be4d13cd09654c use entity XilinxCoreLib.dds_compiler_v2_0(behavioral) generic map( c_use_dsp48 =3D> 0, c_phase_offset_value =3D> "0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0", c_channels =3D> 4, c_phase_increment_value =3D> "0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0", c_has_rdy =3D> 0, c_has_sclr =3D> 0, c_phase_offset =3D> 0, c_data_width =3D> 32, c_accumulator_latency =3D> 1, c_phase_angle_width =3D> 11, c_enable_rlocs =3D> 0, c_phase_increment =3D> 1, c_has_rfd =3D> 0, c_negative_sine =3D> 0, c_has_channel_index =3D> 1, c_latency =3D> -1, c_por_mode =3D> 0, c_has_ce =3D> 1, c_family =3D> "virtex5", c_outputs_required =3D> 2, c_pipelined =3D> 0, c_accumulator_width =3D> 32, c_mem_type =3D> 1, c_optimise_goal =3D> 0, c_negative_cosine =3D> 0, c_noise_shaping =3D> 2, c_xdevicefamily =3D> "Virtex5", c_output_width =3D> 21); -- synthesis translate_on BEGIN -- synthesis translate_off U0 : wrapped_dds_compiler_virtex5_2_0_87be4d13cd09654c port map ( addr =3D> addr, ce =3D> ce, clk =3D> clk, we =3D> we, data =3D> data, channel =3D> channel, cosine =3D> cosine, sine =3D> sine); -- synthesis translate_onArticle: 140973
On Jun 1, 11:17=A0am, fl <rxjw...@gmail.com> wrote:
> Hi,
> I am trying simulating a small Xilinx example with a DDS in Matlab
> simulink. The following
> message appears. I don't know how to solve it. Anyone can shed some
> light on it? Thanks a lot.
>
> HDL compilation failed.
> ERROR:HDLParsers:3281 -
> =A0 =A0"C:/~Temp/xlisim4a23e7da/
> xlisim_xldds_compilerv11.vhd"
> =A0 =A0Line 70. behavioral is not an architecture body for
> dds_compiler_v2_0 in
> =A0 =A0library XilinxCoreLib.
>
> Error occurred during "Simulation Initialization".
I find the error part is a VHDL configuration routine, see below. I
cannot find any solution of it. Can you help me out? Thanks.
Line 70 is the "for all" line.
-- Configuration specification
for all : wrapped_dds_compiler_virtex5_2_0_87be4d13cd09654c
use
entity XilinxCoreLib.dds_compiler_v2_0(behavioral)
generic map(
c_use_dsp48 =3D> 0,
c_phase_offset_value =3D>
"0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0",
c_channels =3D> 4,
c_phase_increment_value =3D>
"0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0",
c_has_rdy =3D> 0,
c_has_sclr =3D> 0,
c_phase_offset =3D> 0,
c_data_width =3D> 32,
c_accumulator_latency =3D> 1,
c_phase_angle_width =3D> 11,
c_enable_rlocs =3D> 0,
c_phase_increment =3D> 1,
c_has_rfd =3D> 0,
c_negative_sine =3D> 0,
c_has_channel_index =3D> 1,
c_latency =3D> -1,
c_por_mode =3D> 0,
c_has_ce =3D> 1,
c_family =3D> "virtex5",
c_outputs_required =3D> 2,
c_pipelined =3D> 0,
c_accumulator_width =3D> 32,
c_mem_type =3D> 1,
c_optimise_goal =3D> 0,
c_negative_cosine =3D> 0,
c_noise_shaping =3D> 2,
c_xdevicefamily =3D> "Virtex5",
c_output_width =3D> 21);
-- synthesis translate_on
BEGIN
-- synthesis translate_off
U0 : wrapped_dds_compiler_virtex5_2_0_87be4d13cd09654c
port map (
addr =3D> addr,
ce =3D> ce,
clk =3D> clk,
we =3D> we,
data =3D> data,
channel =3D> channel,
cosine =3D> cosine,
sine =3D> sine);
-- synthesis translate_on
Article: 140974On Jun 1, 12:05=A0am, Antti <Antti.Luk...@googlemail.com> wrote: > Hi > > as this comes to topic again and again, and as it is no longer > available from the original location > and as i have it converted to PDF and as I happen to have one "micro > IP" based on the ideas > described there, i did upload this PDF version > > should be accessible as > > http://antti-brain.googlegroups.com/web/6EASY.pdf > > it is based on snapshot taken from web.archive.com, > hopefully i get no C&D letters now > (well i would just remove the document then :) > > Antti Hi Antty and Peter, Thank you for your good information. Yesterday I run across a patent by Lester Schowe of Maxtor Corporation, titled "Circuit For Synchronous, Glitch-Free Clock Switching", having a similar schemes as Peter's, but it uses 6 flip- flops. The printed copy of the patent was collected in my a folder called "My most favorite patents" http://www.google.com/patents?id=3D_px7AAAAEBAJ&dq=3Dpatent:5315181&as_drrb= _ap=3Dq&as_minm_ap=3D0&as_miny_ap=3D&as_maxm_ap=3D0&as_maxy_ap=3D&as_drrb_i= s=3Dq&as_minm_is=3D0&as_miny_is=3D&as_maxm_is=3D0&as_maxy_is=3D I think Lester's may be real glitch-free when switching between two asynchronous clocks. Peter's scheme only uses one level of flip-flop to coordinate two asynchronous clocks and it seems to me that it is not long enough to reliably do the job. Weng
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