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 7/31/2013 5:13 PM, GaborSzakacs wrote: > > Most recent parts from Xilinx including Spartan 3A have SPI master > mode configuration, requiring nothing extra over the SPI flash itself > and a handful of resistors. Indirect SPI flash programming over > JTAG is supported by Impact, and you can generate SVF files to > do the programming with an embedded processor. Also because the > pins used for SPI config become I/O after config, you can use > the SPI flash in your design, and possibly come up with a more > "native" solution to field updates (without using JTAG). I'm not sure what the use of Impact implies. Does that mean connecting a PC with a dongle cable? That would be used in the factory perhaps, but in the field they want to use an CPU to drive the JTAG signals. They have that working for an Altera part, but not yet for the Lattice part and of course not for any Xilinx parts. -- RickArticle: 155651
On 31/07/2013 13:44, rickman wrote: [] >> <neatpick mode on> >> Nyquist criterion has nothing to do with being able to sample data. As a >> matter of fact your internal clock is perfectly capable to sample data >> flowing in your fpga without the need to be 2x the data rate. >> <neatpick mode off> > > I don't know what you are talking about. If you asynchronously sample, > you very much do have to satisfy the Nyquist criterion. A 2x clock, > because it isn't *exactly* 2x, can *not* be used to capture a bitstream > so that you can find the the transitions and know which bit is which. A data stream which is *exactly* flowing with a frequency f can be *exactly* sampled with a clock frequency f, it happens continuously in your synchronous logic. What happened to Nyquist theorem? If you have a protocol with data and clock, does it mean that you will recognize only half of the bits because your clock rate is just equal to your data rate? I'm confused... IMO calling a signal 'asynchronous' does not make any difference. Mr. Nyquist referred to reconstructing an analog signal with a discrete sampling (no quantization error involved). How does that applies to digital transmission? > Otherwise there wouldn't be so many errors in the existing circuit. It does not work not because of Nyquist limit, but because the recovery of a phase shift cannot be done with just two clocks per bit. [] > You can use the FPGA PLL to multiply your clock from 2x to 4x to allow > the DPLL to work correctly. This is what I meant indeed. I believe I confused DPLL with ADPLL...Article: 155652
On Wednesday, July 31, 2013 11:37:59 PM UTC+2, alb wrote: > On 31/07/2013 13:44, rickman wrote: > > [] > > >> <neatpick mode on> > > >> Nyquist criterion has nothing to do with being able to sample data. As a > > >> matter of fact your internal clock is perfectly capable to sample data > > >> flowing in your fpga without the need to be 2x the data rate. > > >> <neatpick mode off> > > > > > > I don't know what you are talking about. If you asynchronously sample, > > > you very much do have to satisfy the Nyquist criterion. A 2x clock, > > > because it isn't *exactly* 2x, can *not* be used to capture a bitstream > > > so that you can find the the transitions and know which bit is which. > > > > A data stream which is *exactly* flowing with a frequency f can be > > *exactly* sampled with a clock frequency f, it happens continuously in > > your synchronous logic. What happened to Nyquist theorem? > > > > If you have a protocol with data and clock, does it mean that you will > > recognize only half of the bits because your clock rate is just equal to > > your data rate? I'm confused... > > > > IMO calling a signal 'asynchronous' does not make any difference. Mr. > > Nyquist referred to reconstructing an analog signal with a discrete > > sampling (no quantization error involved). How does that applies to > > digital transmission? > > > > > Otherwise there wouldn't be so many errors in the existing circuit. > > > > It does not work not because of Nyquist limit, but because the recovery > > of a phase shift cannot be done with just two clocks per bit. > may not technically be Nyquist limit, but like so many things in nature the same relations are repeated and if you take NRZ you'll notice that the highest "frequency" (0101010101..) is only half of the data rate -LasseArticle: 155653
On 31/07/2013 15:36, RCIngham wrote: > [snip] >> >> A frame is defined as follows: >> >> - sync :'111' >> - header: dtype (4) - n.u.(2) - length (10) >> - data : (16) * length >> >> in principle between frames there can be any number of zeros (with bit >> stuffing). An 'all zero' pattern in this sense might be of any number of >> bits. >> > [snip] > > Unless 'length' is limited, your worst case has header "0000001111111111" > (with an extra bit stuffed) followed by 16 * 1023 = 16368 zeros, which will > have 2728 ones stuffed into them. Total line packet length is 19113 > symbols. Why you excluded the sync symbol? If the clocks are within 1/19114 of each other, the same number of > symbols will be received as sent, ASSUMING no jitter. 5*10e-5 is a very large difference. We are using 0.5 ppm oscillators. The amount of symbols received has to take into account phase shift otherwise bits will be lost or oversampled. > You can't assume > that, but if there is 'not much' jitter then perhaps 1/100k will be good > enough for relative drift to not need to be corrected for. Still not sure what you are trying to say. > So, for version 1, use the 'sync' to establish the start of frame and the > sampling point, simulate the 'Rx fast' and 'Rx slow' cases in parallel, and > see whether it works. by saying 'in parallel' you mean a data stream with some bits slower and some faster? I think the main problem lies on the slight difference in clock frequencies which lead to increasing phase shift to the point where a bit is lost or oversampled. > > BTW, this is off-topic for C.A.F., as it is a system design problem not > related to the implementation method. IMO is an implementation issue, no specs will tell me how many times I need to sample the data stream. The system design does not have a problem IMO, it simply specify the protocol between two modules. But I will be more than happy if you could point me out to some more appropriate group.Article: 155654
rickman wrote: > I'm not sure what the use of Impact implies. Does that mean connecting > a PC with a dongle cable? That would be used in the factory perhaps, > but in the field they want to use an CPU to drive the JTAG signals. > They have that working for an Altera part, but not yet for the Lattice > part and of course not for any Xilinx parts. > Yes, you certainly can do that, and Xilinx has some articles on how to write your computer code to take a .bit file loaded into a processor's EPROM and perform the various modes of download available. There is serial config, parallel config, JTAG config, etc. To do this from a CPU, you want slave mode, where the CPU clocks the bits into the FPGA. For a serial EPROM chip you select master serial, so the FPGA generates the bit clock. The newer FPGAs have almost too MANY modes of configuration. JonArticle: 155655
Rick... I check the Actel/Microsemi lead you started down on the original p= ost, they have options available in your target size, 100 pin QFP, are flas= h based/reprogrammable over JTAG and I think should have very similar power= requirements to your original design. I am looking at this chip, availabl= e today on digikey: AGL250V2-VQG100, 14 mm2, $25.40, 68 I/O and a fair amou= nt of logic. If you don't need that much logic and want a cheaper part the= y go down from there in the same package.Article: 155656
On 7/31/13 9:36 AM, RCIngham wrote: > [snip] >> > Unless 'length' is limited, your worst case has header "0000001111111111" > (with an extra bit stuffed) followed by 16 * 1023 = 16368 zeros, which will > have 2728 ones stuffed into them. Total line packet length is 19113 > symbols. If the clocks are within 1/19114 of each other, the same number of > symbols will be received as sent, ASSUMING no jitter. You can't assume > that, but if there is 'not much' jitter then perhaps 1/100k will be good > enough for relative drift to not need to be corrected for. > > So, for version 1, use the 'sync' to establish the start of frame and the > sampling point, simulate the 'Rx fast' and 'Rx slow' cases in parallel, and > see whether it works. > > BTW, this is off-topic for C.A.F., as it is a system design problem not > related to the implementation method. > > Since you can resynchronize your sampling clock on each transition received, you only need to "hold lock" for the maximum time between transitions, which is 7 bit times. This would mean that if you have a nominal 4x clock, some sample points will be only 3 clocks apart (if you are slow) or some will be 5 clocks apart (if you are fast), while most will be 4 clock apart. This is the reason for the 1 bit stuffing.Article: 155657
kl. 00:54:41 UTC+2 wednesday 31. july 2013 rickman wrote: > In fact, I'm skipping Altera for the moment and skipping over to=20 > MicroSemi and Cypress to see if their combination CPU/Logic devices=20 > might do the job well and let me eliminate the stereo CODEC to (another= =20 > part that could go obsolete at any time). I seem to recall that the=20 > Cypress part might be just the ticket but the MicroSemi part runs some=20 > $50 at the low point. The current Lattice part is running under $10. We've got a quote for the Microsemi SF2 M2S010 (without T) somewhere in the= middle of that price difference in low volume. The features of SF2 somehow= justified the additional price because we could avoid a separate flash and= MCU externally. The flexibility in configuration of the FPGA and MSS and h= ard preipherals also give us design freedom. Low power consumption was defi= nitively something worth a bit extra. --=20 SvennArticle: 155658
>On 7/31/13 9:36 AM, RCIngham wrote: >> [snip] >>> >> Unless 'length' is limited, your worst case has header "0000001111111111" >> (with an extra bit stuffed) followed by 16 * 1023 = 16368 zeros, which will >> have 2728 ones stuffed into them. Total line packet length is 19113 >> symbols. If the clocks are within 1/19114 of each other, the same number of >> symbols will be received as sent, ASSUMING no jitter. You can't assume >> that, but if there is 'not much' jitter then perhaps 1/100k will be good >> enough for relative drift to not need to be corrected for. >> >> So, for version 1, use the 'sync' to establish the start of frame and the >> sampling point, simulate the 'Rx fast' and 'Rx slow' cases in parallel, and >> see whether it works. >> >> BTW, this is off-topic for C.A.F., as it is a system design problem not >> related to the implementation method. >> >> > >Since you can resynchronize your sampling clock on each transition >received, you only need to "hold lock" for the maximum time between >transitions, which is 7 bit times. This would mean that if you have a >nominal 4x clock, some sample points will be only 3 clocks apart (if you >are slow) or some will be 5 clocks apart (if you are fast), while most >will be 4 clock apart. This is the reason for the 1 bit stuffing. > The bit-stuffing in long sequences of zeroes is almost certainly there to facilitate a conventional clock recovery method, which I am proposing not using PROVIDED THAT the clocks at each end are within a sufficiently tight tolerance. Detect the ones in the as-sent stream first, then decide which are due to bit-stuffing, and remove them. Deciding how tight a tolerance is 'sufficiently tight' is probably non-trivial, so I won't be doing it for free. --------------------------------------- Posted through http://www.FPGARelated.comArticle: 155659
>On Wednesday, July 31, 2013 9:22:53 PM UTC+2, glen herrmannsfeldt wrote: >> langwadt@fonz.dk wrote: >> >> (snip, someone wrote) >> >> >> Zero (or less) hold time on FFs is not true for all FPGAs. >> >> It also does not account for finite skew between clock >> >> arrival at different FFs, even using a "global clock net". >> >> > then the tools better hide that if you want to use it for anything >> > if you don't have zero hold you can't tell if the path between >> > two FFs might happen to be less that the required hold and if you >> > could what would you do? insert some dummy logic to add some delay? >> >> The FF's don't have to have zero hold time, they just have to >> have a hold time less than the shortest route between a previous FF. >> >> I remember in the TTL days, with zero hold time one could wire >> from one output pin to an input, such as Qbar to D. That was >> guaranteed to work. >> >> In the case of FGPAs, though, you have the FPGA routine fabric >> to go through. There will be a minimum length route. >> >> > and if you can't assume the the skew is effectively zero how >> > are you going to do a synchronous design? >> >> Well, again, if the clock skew plus hold time is less than the >> minimum length route, you won't notice it. >> >> For some FPGA families and tools, one can hand route at least >> some signals. If there was a possible route faster than skew >> plus hold, the data sheet should tell you about it. >> >> -- glen > > >what I mean isn't that hold and skew should literally have >to be zero but it should be so that you can design as if it >was and it is guaranteed to work > > >-Lasse > What the OP should do is a trial fully-synchronous design, run it all the way through the tools, and see whether the Static Timing Analysis shows that it is "fast enough". If not, start adding pipelining stages in the areas that are causing a problem. The major vendors' toolsets are all quite good at optimising for speed in fully-synchronous datapath designs (although I have had various problems with Virtex-5 parts in the past). --------------------------------------- Posted through http://www.FPGARelated.comArticle: 155660
On 01/08/2013 11:56, RCIngham wrote: [] >> Since you can resynchronize your sampling clock on each transition >> received, you only need to "hold lock" for the maximum time between >> transitions, which is 7 bit times. This would mean that if you have a >> nominal 4x clock, some sample points will be only 3 clocks apart (if you >> are slow) or some will be 5 clocks apart (if you are fast), while most >> will be 4 clock apart. This is the reason for the 1 bit stuffing. >> > > The bit-stuffing in long sequences of zeroes is almost certainly there to > facilitate a conventional clock recovery method, which I am proposing not > using PROVIDED THAT the clocks at each end are within a sufficiently tight > tolerance. Detect the ones in the as-sent stream first, then decide which > are due to bit-stuffing, and remove them. What is the gain of not using 'conventional clock recovery'?Article: 155661
On Wednesday, July 31, 2013 3:59:49 PM UTC-5, lang...@fonz.dk wrote: > what I mean isn't that hold and skew should literally have to be zero but it should be so that you can design as if it was and it is guaranteed to work -Lasse In the case of Microsemi PA3E devices, their place & route tool works to solve any hold times for you, assuming you enable that setting. I have seen several hold time violations with that setting disabled, but not with the setting enabled. AndyArticle: 155662
I am trying to build a simple hello world example using Nios II v8.0 on a w= indows Xp machine. I see the following errors: **** Build of configuration Debug for project LIDAR_NIOSII_USB2 ****make -s= all includes make: /bin/sh.exe: Command not foundmake: /bin/sh.exe: Comman= d not foundmake: /bin/sh.exe: Command not foundmake: /bin/sh.exe: Command n= ot foundmake: /bin/sh.exe: Command not foundC:/altera/80/nios2eds/component= s/altera_hal/build/app_rules.mk:153: /components/altera_hal/build/gnu_rules= .mk: No such file or directoryC:/altera/80/nios2eds/components/altera_hal/b= uild/app_rules.mk:157: /components/altera_hal/build/gtf_rules.mk: No such f= ile or directorymake: *** No rule to make target `/components/altera_hal/bu= ild/gtf_rules.mk'. Stop.Build completed in 0.563 seconds I have my SOPC_KIT_NIOS2 path set to C:\altera\80\nios2eds Any suggestions??Article: 155663
On Thursday, August 1, 2013 9:11:43 PM UTC+2, jone...@comcast.net wrote: > On Wednesday, July 31, 2013 3:59:49 PM UTC-5, lang...@fonz.dk wrote: > > > what I mean isn't that hold and skew should literally have to be zero but it should be so that you can design as if it was and it is guaranteed to work -Lasse > > > > In the case of Microsemi PA3E devices, their place & route tool works to solve any hold times for you, assuming you enable that setting. I have seen several hold time violations with that setting disabled, but not with the setting enabled. > > > Andy how does that work? I mean if you don't enable that option and get a hold violation what can you do? can't just start adding random logic hoping it fixes the problem -LasseArticle: 155664
In article <26bc041f-8f5c-49af-afc6-0c47c124e5f9@googlegroups.com>, <langwadt@fonz.dk> wrote: >On Thursday, August 1, 2013 9:11:43 PM UTC+2, jone...@comcast.net wrote: >> On Wednesday, July 31, 2013 3:59:49 PM UTC-5, lang...@fonz.dk wrote: >> >> > what I mean isn't that hold and skew should literally have to bei >> > zero but it should be so that >> >you can design as if it was and it is guaranteed to work -Lasse >> >> In the case of Microsemi PA3E devices, their place & route tool works >> to solve any hold times for you, assuming you enable that setting. >> I have seen several hold time violations with that >> setting disabled, but not with the setting enabled. > >how does that work? I mean if you don't enable that option and >get a hold violation what can you do? can't just start adding > random logic hoping it fixes the problem The tool solves hold times buy just adding delay to the datapath. Xilinx tools fix hold times too. Or am I misunderstanding your question? It's on by default - don't even know if you can turn it off. Regards, MarkArticle: 155665
On 8/1/2013 8:55 AM, alb wrote: > On 01/08/2013 11:56, RCIngham wrote: > [] >>> Since you can resynchronize your sampling clock on each transition >>> received, you only need to "hold lock" for the maximum time between >>> transitions, which is 7 bit times. This would mean that if you have a >>> nominal 4x clock, some sample points will be only 3 clocks apart (if you >>> are slow) or some will be 5 clocks apart (if you are fast), while most >>> will be 4 clock apart. This is the reason for the 1 bit stuffing. >>> >> >> The bit-stuffing in long sequences of zeroes is almost certainly there to >> facilitate a conventional clock recovery method, which I am proposing not >> using PROVIDED THAT the clocks at each end are within a sufficiently tight >> tolerance. Detect the ones in the as-sent stream first, then decide which >> are due to bit-stuffing, and remove them. > > What is the gain of not using 'conventional clock recovery'? I think the point is that if the sequences are short enough that the available timing tolerance is adequate, then you just don't need to recover timing from the bit stream. I've been looking at this, then working on other issues and have lost my train of thought on this. I believe that a PLL (or DPLL) is not needed as long as the input can be sampled fast enough and the reference frequency is matched closely enough. But it is still important to correct for "phase" as the OP puts it (IIRC) so that you can tell where the bits are and not sample on transitions, just like a conventional UART does it. We frequent enough transitions, the phase can be detected and aligned while the exact frequency does not need to be recovered. -- RickArticle: 155666
On 7/31/2013 5:37 PM, alb wrote: > On 31/07/2013 13:44, rickman wrote: > [] >>> <neatpick mode on> >>> Nyquist criterion has nothing to do with being able to sample data. As a >>> matter of fact your internal clock is perfectly capable to sample data >>> flowing in your fpga without the need to be 2x the data rate. >>> <neatpick mode off> >> >> I don't know what you are talking about. If you asynchronously sample, >> you very much do have to satisfy the Nyquist criterion. A 2x clock, >> because it isn't *exactly* 2x, can *not* be used to capture a bitstream >> so that you can find the the transitions and know which bit is which. > > A data stream which is *exactly* flowing with a frequency f can be > *exactly* sampled with a clock frequency f, it happens continuously in > your synchronous logic. What happened to Nyquist theorem? > > If you have a protocol with data and clock, does it mean that you will > recognize only half of the bits because your clock rate is just equal to > your data rate? I'm confused... > > IMO calling a signal 'asynchronous' does not make any difference. Mr. > Nyquist referred to reconstructing an analog signal with a discrete > sampling (no quantization error involved). How does that applies to > digital transmission? Yes, you are right about the rates. I was not thinking of this correctly. The Nyquist theorem looks at *frequency* content which is not the same as bit rate. >> Otherwise there wouldn't be so many errors in the existing circuit. > > It does not work not because of Nyquist limit, but because the recovery > of a phase shift cannot be done with just two clocks per bit. > > [] >> You can use the FPGA PLL to multiply your clock from 2x to 4x to allow >> the DPLL to work correctly. > > This is what I meant indeed. I believe I confused DPLL with ADPLL... I am not familiar with ADPLL. What is that? -- RickArticle: 155667
On 8/1/13 5:56 AM, RCIngham wrote: >> On 7/31/13 9:36 AM, RCIngham wrote: >>> [snip] >>>> >>> Unless 'length' is limited, your worst case has header > "0000001111111111" >>> (with an extra bit stuffed) followed by 16 * 1023 = 16368 zeros, which > will >>> have 2728 ones stuffed into them. Total line packet length is 19113 >>> symbols. If the clocks are within 1/19114 of each other, the same number > of >>> symbols will be received as sent, ASSUMING no jitter. You can't assume >>> that, but if there is 'not much' jitter then perhaps 1/100k will be > good >>> enough for relative drift to not need to be corrected for. >>> >>> So, for version 1, use the 'sync' to establish the start of frame and > the >>> sampling point, simulate the 'Rx fast' and 'Rx slow' cases in parallel, > and >>> see whether it works. >>> >>> BTW, this is off-topic for C.A.F., as it is a system design problem not >>> related to the implementation method. >>> >>> >> >> Since you can resynchronize your sampling clock on each transition >> received, you only need to "hold lock" for the maximum time between >> transitions, which is 7 bit times. This would mean that if you have a >> nominal 4x clock, some sample points will be only 3 clocks apart (if you >> are slow) or some will be 5 clocks apart (if you are fast), while most >> will be 4 clock apart. This is the reason for the 1 bit stuffing. >> > > The bit-stuffing in long sequences of zeroes is almost certainly there to > facilitate a conventional clock recovery method, which I am proposing not > using PROVIDED THAT the clocks at each end are within a sufficiently tight > tolerance. Detect the ones in the as-sent stream first, then decide which > are due to bit-stuffing, and remove them. > > Deciding how tight a tolerance is 'sufficiently tight' is probably > non-trivial, so I won't be doing it for free. > > Since a 4x clock allows for a 25% data period correction, and we will get an opportunity to do so every 7 data periods, we can tolerate about a 25/7 ~ 3% error in clock frequency. (To get a more exact value we will need to know details like jitter and sampling apertures, but this gives us a good ball-park figure). Higher sampling rates can about double this, the key is we need to be able to know which direction the error is in, so we need to be less than a 50% of a data period error including the variation within a sample clock. To try to gather the data without resynchronizing VASTLY decreases your tolerance for clock errors as you need to stay within a clock cycle over the entire message. The protocol, with its 3 one preamble, does seem like there may have been some effort to enable the use of a PLL to generate the data sampling clock, which may have been the original method. This does have the advantage the the data clock out of the sampler is more regular (not having the sudden jumps from the resyncronizing), and getting a set a burst of 1s helps the PLL to get a bit more centered on the data. My experience though is that with FPGAs (as would be on topic for this group), this sort of PLL synchronism is not normally used, but oversampling clocks with phase correction is fairly standard.Article: 155668
On 8/1/2013 3:21 AM, Svenn Are Bjerkem wrote: > kl. 00:54:41 UTC+2 wednesday 31. july 2013 rickman wrote: >> In fact, I'm skipping Altera for the moment and skipping over to >> MicroSemi and Cypress to see if their combination CPU/Logic devices >> might do the job well and let me eliminate the stereo CODEC to (another >> part that could go obsolete at any time). I seem to recall that the >> Cypress part might be just the ticket but the MicroSemi part runs some >> $50 at the low point. The current Lattice part is running under $10. > > We've got a quote for the Microsemi SF2 M2S010 (without T) somewhere in the middle of that price difference in low volume. The features of SF2 somehow justified the additional price because we could avoid a separate flash and MCU externally. The flexibility in configuration of the FPGA and MSS and hard preipherals also give us design freedom. Low power consumption was definitively something worth a bit extra. Yes, each project has its own requirements so some will justify a higher price for the improved integration. I am not so familiar with the Microsemi part and I not had time to dig into their offerings. I don't even know if they have anything new in the last year or two. The main stumbling block for the Cypress part is the lack of CD quality CODEC I believe. But that is only a $3 part at most. There are also some op amps on the board which I doubt can be replaced since at least four of them are used to drive a 12 volt supply into a 50 ohm load (8 Vp-p IIRC). The remaining parts are analog switches on the analog I/O, analog switches on the digital I/O to act as 5-3 volt level converters and a two channel RS-422 input/output chip. I doubt any of this can be pulled into the Microsemi part leaving us with this possibly replacing the existing FPGA and the CODEC at best. So it would be hard to justify replacing what is otherwise $15 worth of parts with a $30 part if I read your post correctly. By low volume I assume you mean qty 100 ball park. Funny about Cypress. I seem to recall their web site having gone downhill over the last few years. When I tried to download a data sheet on their parts I couldn't find one! They have links for their software and for samples, but none for a data sheet!!!? Maybe it is embedded in their development software? They also give a crappy overview of their parts. So far I haven't figured it out but I guess it is worth a second try. -- RickArticle: 155669
On 7/31/2013 6:23 PM, Jon Elson wrote: > rickman wrote: > > >> I'm not sure what the use of Impact implies. Does that mean connecting >> a PC with a dongle cable? That would be used in the factory perhaps, >> but in the field they want to use an CPU to drive the JTAG signals. >> They have that working for an Altera part, but not yet for the Lattice >> part and of course not for any Xilinx parts. >> > Yes, you certainly can do that, and Xilinx has some articles > on how to write your computer code to take a .bit file loaded into > a processor's EPROM and perform the various modes of download > available. There is serial config, parallel config, JTAG config, > etc. To do this from a CPU, you want slave mode, where the > CPU clocks the bits into the FPGA. For a serial EPROM chip you > select master serial, so the FPGA generates the bit clock. > The newer FPGAs have almost too MANY modes of configuration. I think what you are describing is rather different. This is the slave serial config mode which is somewhat limited in functionality. The interface my customer has provided is intended to use a JTAG interface. In the case of the serial EEPROM the CPU would either program the EEPROM directly or drive the JTAG on the FPGA to program the EEPROM. I'm pretty sure the customer does *not* want to load the part every time it is booted, just once in a programming mode, then the board loads itself when it boots up. I'm not sure if this is what you were describing or not. -- RickArticle: 155670
On 02/08/2013 06:19, rickman wrote: [] >> >> This is what I meant indeed. I believe I confused DPLL with ADPLL... > > I am not familiar with ADPLL. What is that? It is an All Digital PLL: http://www.aicdesign.org/2003%20PLL%20Slides/L050-ADPLLs-2UP(9_1_03).pdf all the elements of a PLL are implemented in the digital domain.Article: 155671
Hi Lasse,
On 01/08/2013 00:03, langwadt@fonz.dk wrote:
[]
>> It does not work not because of Nyquist limit, but because the
>> recovery
>>
>> of a phase shift cannot be done with just two clocks per bit.
>>
>
> may not technically be Nyquist limit, but like so many things in
> nature the same relations are repeated
A signal traveling on a physical channel (be it on a cable, a PCB route,
an FPGA interconnection...) will have sharp transitions at the beginning
of its journey and sloppier ones at the end due to losses, but if you
take a comparator and discriminate a '1' or '0', then you do not 'need'
higher frequencies than half the data rate itself (or symbol rate to be
precise). If you take a sinusoidal waveform and put a threshold at 0,
then you have two symbols per cycle.
Why sampling at the data rate is not sufficient then? Because there are
several other factors. First of all encoding and decoding are processes
which do introduce 'noise' as well as 'limitations'. Having a comparator
to discriminate 0/1 does introduce noise in the time of transaction,
therefore distorting the phase of the signal. The medium itself might be
source of other jitter since it is sensitive to the environment
(temperature, pressure, humidity, ...).
TRANSMITTER MEDIUM RECEIVER
+-------------------+ +-------------------+
| +---| |---+ |
| '10100101' -> |ENC| -\/\/\/\/->|DEC| -> '10101110' |
| +---| physical |---+ |
+-------------------+ signal +-------------------+
^ ^
| |
+-----+ +-----+
| clk | | clk |
+-----+ +-----+
You do not care about reconstructing a physical signal (like in ADC
sampling), you *do* care about reconstructing a data stream.
Another source of troubles are the two clock generators on the TX and
RX. They cannot be assumed to be perfectly matching and any difference
will lead to a phase drift which eventually will spoil your data sampling.
> and if you take NRZ you'll notice that the highest "frequency"
> (0101010101..) is only half of the data rate
that is why a clock frequency = to data rate is sufficient to 'sample'
the information.
<nitpick mode on>
the NRZ is a line code, i.e. a translation of your data stream with
appropriate physical signal (light, current, sound, ...) for the chosen
physical medium (fiber, cable, air, ...) and has nothing to do with a
toggling bit.
<nitpick mode off>
Article: 155672The crowdfunded Parallella-16 starter kit from adapteva seems to be the lowest-cost xilinx zynq starter kit at the same time. For USD 99 one gets a XC7Z010 board with 1GB DRAM, GB Ethernet, Flash, USB, and the 16-core epiphany processor. But of course, one could use the FPGA only. Andreas (I pre-ordered mine last week, I am not associated with the project or with Adapteva).Article: 155673
Hi Richard, On 02/08/2013 06:22, Richard Damon wrote: [] >> The bit-stuffing in long sequences of zeroes is almost certainly there to >> facilitate a conventional clock recovery method, which I am proposing not >> using PROVIDED THAT the clocks at each end are within a sufficiently tight >> tolerance. Detect the ones in the as-sent stream first, then decide which >> are due to bit-stuffing, and remove them. >> >> Deciding how tight a tolerance is 'sufficiently tight' is probably >> non-trivial, so I won't be doing it for free. >> >> > > Since a 4x clock allows for a 25% data period correction, and we will > get an opportunity to do so every 7 data periods, we can tolerate about > a 25/7 ~ 3% error in clock frequency. (To get a more exact value we will > need to know details like jitter and sampling apertures, but this gives > us a good ball-park figure). Higher sampling rates can about double > this, the key is we need to be able to know which direction the error is > in, so we need to be less than a 50% of a data period error including > the variation within a sample clock. According to your math it looks like a 2x clock allows for a 50% data period correction and therefore a 50/7 ~6% error in clock frequency, which seems to me quite counter intuitive... Am I missing something? [] > The protocol, with its 3 one preamble, does seem like there may have > been some effort to enable the use of a PLL to generate the data > sampling clock, which may have been the original method. This does have > the advantage the the data clock out of the sampler is more regular (not > having the sudden jumps from the resyncronizing), and getting a set a > burst of 1s helps the PLL to get a bit more centered on the data. My > experience though is that with FPGAs (as would be on topic for this > group), this sort of PLL synchronism is not normally used, but > oversampling clocks with phase correction is fairly standard. This is indeed what I'm looking for, oversampling (4x or 8x) and phase correct.Article: 155674
GaborSzakacs <gabor@alacron.com> writes: > I'm pretty sure that the 144-pin package is the smallest with flash. The data sheet lists Spartan3 200AN and 50AN parts with VQ100 package and 68 user I/Os. Might be those packages are EOL though.
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