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 Jun 1, 2:36=A0pm, Thomas Heller <thel...@ctypes.org> wrote: > Am 01.06.2012 18:57, schrieb Tim Wescott: > > > > > > > > > > > On Fri, 01 Jun 2012 17:02:10 +0100, Thomas Womack wrote: > > >> In article<a2s3v7Fv1...@mid.individual.net>, Thomas Heller > >> <thel...@ctypes.org> =A0wrote: > >>> I need a multi-bit PRNG which generates a sequence of 10-bit pseudo > >>> random numbers. > > >>> Can I use a LFSR of sufficient length (31 bit, for example), and get = a > >>> new random number on each clock by using the 10 least significant bit= s, > >>> or do I have to use 10 independent LFSR's of different length, one fo= r > >>> each bit? > > >> How important is it that the numbers are uncorrelated? =A0The 10 LSBs = of > >> an LFSR at time t+1 will be nine of the bits from time t and one new > >> one, so if you saw 100 at time t you know it's either 200 or 201 next > >> go. =A0If that's OK, use the end of one LFSR; if not, use several. > > >> But if it's actually important that the random numbers are > >> unpredictable, don't use LFSRs: given 3n bits from a length-n LFSR you > >> can pretty much write down the rest of the sequence. > > > I've only scratched the surface of cryptographicaly secure random numbe= r > > generation -- are there any schemes that are amenable to working on an > > FPGA? > > FYI: =A0I found interesting papers about true (and pseudo) random number > generation in FPGAs. =A0They are using ff metastability or PLL jitter > for this: > > http://people.csail.mit.edu/devadas/pubs/ches-fpga-random.pdf > > http://www.cse.cuhk.edu.hk/~phwl/mt/public/archives/papers/tprng_fccm... > > Thomas I haven't read the papers, but typically any digital "true" random number generator is not "truly" random. When it is measured and analyzed critically it has biases which allow a degree of predictability. I have read about other attempts based on diode noise which resulted in easily measurable biases. RickArticle: 153851
rickman <gnuarm@gmail.com> wrote: (snip, someone wrote) >> >>> Can I use a LFSR of sufficient length (31 bit, for example), and get a >> >>> new random number on each clock by using the 10 least significant bits, >> >>> or do I have to use 10 independent LFSR's of different length, one for >> >>> each bit? >> FYI: I found interesting papers about true (and pseudo) random number >> generation in FPGAs. They are using ff metastability or PLL jitter >> for this: >> http://people.csail.mit.edu/devadas/pubs/ches-fpga-random.pdf >> http://www.cse.cuhk.edu.hk/~phwl/mt/public/archives/papers/tprng_fccm... > I haven't read the papers, but typically any digital "true" random > number generator is not "truly" random. When it is measured and > analyzed critically it has biases which allow a degree of > predictability. If you put enough state bits into the calculation, you should be able to keep the predictability long enough that, in a practical time frame, it isn't noticed. > I have read about other attempts based on diode noise > which resulted in easily measurable biases. I used to have the paper about an Intel chip with a built-in noise source based generator. There is logic to remove at least the first order bias. (Equal ones and zeros.) It should be possible to remove any specific bias if you know about it and try to remove it. You need to know which biases the specific problem is sensitive to. I do remember stories about many of the early generators that weren't so bad except when taken in triplets there was some correlation between triplets. That turned out bad when used to generate points in 3D space. Once known, it can be fixed. There is always a tradeoff between randomness and time needed by the generator. -- glenArticle: 153852
Hello Friends, I am working on virtex6. I am trying to debug a problem by simulating in modelsim. But in the simulation I get a different problem. My platform uses DDR3 SDRAM via xilinx's MPMC (6.02a). During simulation, the MPMC gets busy initializing itself, but never finishes (at least not for until 2ms). To fasten the initialization in the MHS file, I first set PARAMETER C_SKIP_SIM_INIT_DELAY = 1 That didnt help. So to be sure I also then set PARAMETER C_MEM_SIM_INIT_OPTION = SKIP_INIT PARAMETER C_MEM_WRLVL = 0 I see WRITE level initialization finishes, but read level does not. The simulation continues forever ( I simulated for 2ms, which took around 1Hr with my hardware platform) What could be wrong? Have I missed something? I am not memory expert, I just want the MPMC to work during simulation. Thanks --------------------------------------- Posted through http://www.FPGARelated.comArticle: 153853
I can't help with that. However, back when I was doing simulations, they usually finished sometime during the night after I started them. However, I once saw a simulation (of a circuit board with mostly ASIC on it) that took three months to finish.Article: 153854
TTA-based Co-design Environment (TCE) v1.6 released --------------------------------------------------- TTA-based Co-design Environment (TCE) is a toolset for designing application-specific processors based on the Transport Triggered Architecture (TTA). The toolset provides a complete retargetable co-design flow from high-level language programs down to synthesizable processor RTL (VHDL and Verilog backends supported) and parallel program binaries. Processor customization points include the register files, function units, supported operations, and the interconnection network. This release adds support for LLVM 3.1, experimental Verilog backend for the Processor Generator, support for explicit access to multiple address spaces from C, a simplified C++ interface for accessing the simulation engine, automated generation of clustered-style TTA machines, experimental vector input and a bottom-up instruction scheduler. See the CHANGES file for a more thorough change listing. Acknowledgements ---------------- Many thanks to Kalle Raiskila who submitted his first code contributions to this release. Keep them coming! We'd like to thank the Radio Implementation Research Team from Nokia Research Center which funded a significant part of the work for developing this release. Much appreciated! Links ----- TCE home page: http://tce.cs.tut.fi This announcement: http://tce.cs.tut.fi/downloads/ANNOUNCEMENT Download: http://tce.cs.tut.fi/downloads Change log: http://tce.cs.tut.fi/downloads/CHANGESArticle: 153855
Hi, Here is a question little bit in the internals of the FPGA. I am asking this more out of my curiosity and learning. FPGA LUT typically consists of SRAMs & a Mux at the output. These Muxes need both normal & inverted select signals. The select signals come from the interconnect. Considering the inverted select signals, there are two possible implementations – Implementation-1 CLB-1 [To] Switch Mux [To] Switch Buffer [To] Interconnect Line to Carry TRUE Signal [To] CLB-N In such a case there have to be inverters within the LUT Mux to get inverted signals. Implementation-2 CLB-1 [To] Switch Mux [To] Switch Buffer [To] Interconnect Line to Carry Normal Signal & Interconnect Line to carry Inverted Signal [To] CLB-N Implementation-2 will be inefficient in terms of area & power. However Implementation-1 will have additional one inverter delay in the critical path. Does anybody has an idea which one is favored in the FPGAs. Please get back. Thanks, Bukka --------------------------------------- Posted through http://www.FPGARelated.comArticle: 153856
On Jun 5, 4:17=A0pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote: > rickman <gnu...@gmail.com> wrote: > > (snip, someone wrote) > > >> >>> Can I use a LFSR of sufficient length (31 bit, for example), and g= et a > >> >>> new random number on each clock by using the 10 least significant = bits, > >> >>> or do I have to use 10 independent LFSR's of different length, one= for > >> >>> each bit? > >> FYI: I found interesting papers about true (and pseudo) random number > >> generation in FPGAs. They are using ff metastability or PLL jitter > >> for this: > >>http://people.csail.mit.edu/devadas/pubs/ches-fpga-random.pdf > >>http://www.cse.cuhk.edu.hk/~phwl/mt/public/archives/papers/tprng_fccm..= . > > I haven't read the papers, but typically any digital "true" random > > number generator is not "truly" random. =A0When it is measured and > > analyzed critically it has biases which allow a degree of > > predictability. > > If you put enough state bits into the calculation, you should be > able to keep the predictability long enough that, in a practical > time frame, it isn't noticed. > > > I have read about other attempts based on diode noise > > which resulted in easily measurable biases. > > I used to have the paper about an Intel chip with a built-in > noise source based generator. There is logic to remove at least > the first order bias. (Equal ones and zeros.) It should be possible > to remove any specific bias if you know about it and try to > remove it. You need to know which biases the specific problem > is sensitive to. > > I do remember stories about many of the early generators that > weren't so bad except when taken in triplets there was some > correlation between triplets. That turned out bad when used to > generate points in 3D space. Once known, it can be fixed. > > There is always a tradeoff between randomness and time needed > by the generator. > > -- glen Yes, it all depends on what you need. I was watching a local government cable channel once about a state hearing where a representative of a gambling machine company was trying to explain to the regulating board how this machine was different from the machines prohibited in this state. It seems that there were machines that for some amount of coin would give you a pre- printed ticket that told you your winnings, if any. Because the sequence was pre-arranged and once the prizes have all sold out (the barkeeper would know when that happens) the remaining tickets were all losers and further play was no longer "gambling". So the gaming board banned these machines. This spokesperson claimed that the microprocessors in the machine always produced random results and so was not like the illegal pre- printed ticket machines. We all know that this is nonsense and that they actually were using something like an LFSR, possibly with a time based modification that would not produce truly random results. For example, I expect their machines would never produce a sequence of 100 big winners no matter how long you played. A real random machine would produce this sequence eventually if played long enough. I don't know what the outcome of the hearing was. I suspect the gaming commission got more info from other sources and learned that a microprocessor does not produce random results. RickArticle: 153857
My experience with Altera embedded is limited to taking a short Altera-pres= ented class on their new tools and (of course) it all worked beautifully, w= ith some really nice bells and whistles for debugging and putting together = a quick TCL-base GUI. Since this is in a controlled environment, take it f= or what it's worth... I can, however, second your frustration with the Xilinx EDK. Every time I = make a change to a peripheral on our design, getting the flow to work again= is always very painful. The tool is very unreliable in how it converts ac= tions in the GUI (XPS) to actual instructions for the platform generator (.= MHS file) and it's often that I/O changes don't show up in the file, and th= at resulting processor no longer works with the debugger, even when you *th= ink* you've correctly regenerated the "base system package" (*_bsp project = in XSDK) and done everything right. I also burned up 2-3 days when I was new to the environment because the Lin= ux version of XSDK has some GUI quirks that make it unclear which .ELF file= you're loading when you attempt to debug the device with the JTAG cable. = The default file in the pull-down list may show your current compiled progr= am, but it actually loads it with bootloop.elf (do-nothing code) unless you= explicitly pull-down the list and "re-select" it. We're going to be starting an Altera project within a month or two and I ea= gerly anticipate what kind of "gotchas" we encounter in their tools. I hop= e to be pleasantly surprised. -- Kevin Smith HDL Nerd for Hire On Monday, May 28, 2012 3:20:40 PM UTC-5, maxascent wrote: > Does anyone have experience of using the Altera and Xilinx embedded > software? I have been using EDK but I am getting very frustrated with it. > It seems that every new release includes a generous helping of bugs. I se= em > to find myself wasting hours just trying to get a design to be implemente= d. > For example the 14.1 release now seems to have some problems with the > interrupt controller, yet it was ok in the previous release. Does the > Altera software have as many bugs? >=20 > TIA >=20 > Jon >=20 > =20 > =09 > --------------------------------------- =09 > Posted through http://www.FPGARelated.comArticle: 153858
At the risk of misunderstanding your question, I think that your "Implement= ation-1" would not really have an additional inverter delay if it's going t= o be input to a function that will fit into a single LUT (up to 4 inputs - = 6 if you count the neighboring LUT in the same slice). The propagation del= ay through: Y =3D A + B is exactly the same as the delay through: Y =3D (!(A * B) + C) * (!D + A) because either is implemented as a 16-bit ROM with a 4-bit address input an= d a 1-bit data output. So sending your inverted signal along with the normal signal would waste a = routing resource and the automatic tools would be unlikely to do it that wa= y. Best wishes, -- Kevin Smith HDL Nerd for Hire On Thursday, June 7, 2012 9:56:59 AM UTC-5, bukka wrote: > Hi, >=20 > Here is a question little bit in the internals of the FPGA. I am asking > this more out of my curiosity and learning. >=20 > FPGA LUT typically consists of SRAMs & a Mux at the output. These Muxes > need both normal & inverted select signals. The select signals come from > the interconnect. Considering the inverted select signals, there are two > possible implementations =96 >=20 > Implementation-1 > CLB-1 [To] Switch Mux [To] Switch Buffer [To] Interconnect Line to Carry > TRUE Signal [To] CLB-N >=20 > In such a case there have to be inverters within the LUT Mux to get > inverted signals. >=20 > Implementation-2 > CLB-1 [To] Switch Mux [To] Switch Buffer [To] Interconnect Line to Carry > Normal Signal & Interconnect Line to carry Inverted Signal [To] CLB-N >=20 > Implementation-2 will be inefficient in terms of area & power. However > Implementation-1 will have additional one inverter delay in the critical > path. >=20 > Does anybody has an idea which one is favored in the FPGAs. > Please get back. >=20 > Thanks, > Bukka >=20 >=20 > =20 > =09 > --------------------------------------- =09 > Posted through http://www.FPGARelated.comArticle: 153859
Am Donnerstag, 7. Juni 2012 16:56:59 UTC+2 schrieb bukka: > Hi, >=20 > Here is a question little bit in the internals of the FPGA. I am asking > this more out of my curiosity and learning. >=20 > FPGA LUT typically consists of SRAMs & a Mux at the output. These Muxes > need both normal & inverted select signals. The select signals come from > the interconnect. Considering the inverted select signals, there are two > possible implementations =96 >=20 > Implementation-1 > CLB-1 [To] Switch Mux [To] Switch Buffer [To] Interconnect Line to Carry > TRUE Signal [To] CLB-N >=20 > In such a case there have to be inverters within the LUT Mux to get > inverted signals. >=20 > Implementation-2 > CLB-1 [To] Switch Mux [To] Switch Buffer [To] Interconnect Line to Carry > Normal Signal & Interconnect Line to carry Inverted Signal [To] CLB-N >=20 > Implementation-2 will be inefficient in terms of area & power. However > Implementation-1 will have additional one inverter delay in the critical > path. >=20 > Does anybody has an idea which one is favored in the FPGAs. > Please get back. >=20 > Thanks, > Bukka >=20 >=20 > =20 > =09 > --------------------------------------- =09 > Posted through http://www.FPGARelated.com Hi Bukka, I think it doesn't make much sense to think about the internals of a LUT in= terms of gates and wires. These blocks are highly optimized monolithic units made out of transistors. If any selection signals (which are the LUTS inputs) need inversion interna= lly, this functionality will be absorbed and timing optimized within the tr= ansistor layout the LUT is made of. Have a nice synthesis EilertArticle: 153860
goouse99@googlemail.com wrote: (snip) > I think it doesn't make much sense to think about the > internals of a LUT in terms of gates and wires. > These blocks are highly optimized monolithic units made > out of transistors. If any selection signals (which are > the LUTS inputs) need inversion internally, this > functionality will be absorbed and timing optimized > within the transistor layout the LUT is made of. That is true, but many engineers like to know how things work inside. In this case, your best hope is probably patents. As it isn't so hard to open up an IC and figure out how it works, the best protection is a patent. Maybe not all the details you want, but some might be there. -- glenArticle: 153861
shubhendu wrote: > Hello Friends, > > I am working on virtex6. I am trying to debug a problem by simulating in > modelsim. But in the simulation I get a different problem. My platform uses > DDR3 SDRAM via xilinx's MPMC (6.02a). > > During simulation, the MPMC gets busy initializing itself, but never > finishes (at least not for until 2ms). > > To fasten the initialization in the MHS file, I first set > PARAMETER C_SKIP_SIM_INIT_DELAY = 1 > > That didnt help. So to be sure I also then set > > PARAMETER C_MEM_SIM_INIT_OPTION = SKIP_INIT > PARAMETER C_MEM_WRLVL = 0 > > I see WRITE level initialization finishes, but read level does not. The > simulation continues forever ( I simulated for 2ms, which took around 1Hr > with my hardware platform) > > What could be wrong? Have I missed something? > > I am not memory expert, I just want the MPMC to work during simulation. > > > Thanks > > > > > > --------------------------------------- > Posted through http://www.FPGARelated.com I'm not familiar with the MPMC, but I had issues with MIG simulations not finishing "calibration." It seems that my problem had to do with a minimum delay requirement on the data path. If you look at the test bench provided with the MIG design, there are delays in the data connections between MIG and the memory model. You may need to duplicate these in your test bench if they're not already in there. -- GaborArticle: 153862
Hi all, Following problem: We have an Xilinx Virtix 5, having an implementation running on it. What we want to do, is to read out all the bits (or the state) of the different LUTM cells. At the moment, we are outputting this information with the help of an UART module. However, we are wondering whether we could completely get rid of the UART and use the JTAG instead somehow. So without using Chipscop, is there a way that allows us to readback all LUTM contents using the JTAG interface? Many thanks!Article: 153863
I have a cameralink (LVDS SERDES) I'm trying to capture data with using a Virtex 4 mature product. I have ported the XAPP485 deserializer using V4 primitives (slightly different to Spartan3A) and configured the DCM to run at 32MHz. The problem is the LVDS-TTL receivers on the PCB cannot run at the 32MHz x7 rate. The slow risetime means I hardly see a 2V '1' threshold in the Xilinx. I therefore need to reduce the incoming clock rate, but the DCM minimum frequency is 32MHz.... OK, I could reduce the cameralink down to 20MHz giving 1/20e6*7 bit period of 7.14ns. I have a 200MHz clock on the board for IDELAY, I could use both edges to oversample the cameralink data (and 20MHz subclock to ease data recovery) by sampling at 2.5ns. But this is going to be a nightmare to peice together (it can be done offline) and require lots of storage...... Is there a more elegant way of capturing the data please? The application is to take an image of a satellite on seperation from the launcher in space - its a nice to have but I'd really like to make this work. --------------------------------------- Posted through http://www.FPGARelated.comArticle: 153864
hi, guys: i'm designing a fifo using XILINX FPGA V6. the fifo will be used to transport data between ARM11(OR POWERPC) and TI DSP 6474. i know it's related to the bus clock of both side, but how to calculate the max data rate that can be transferred. can anyone tell me how? thanks! markc --------------------------------------- Posted through http://www.FPGARelated.comArticle: 153865
ees3dc wrote: > I have a cameralink (LVDS SERDES) I'm trying to capture data with using a > Virtex 4 mature product. I have ported the XAPP485 deserializer using V4 > primitives (slightly different to Spartan3A) and configured the DCM to run > at 32MHz. > > The problem is the LVDS-TTL receivers on the PCB cannot run at the 32MHz x7 > rate. The slow risetime means I hardly see a 2V '1' threshold in the > Xilinx. > > I therefore need to reduce the incoming clock rate, but the DCM minimum > frequency is 32MHz.... > > OK, I could reduce the cameralink down to 20MHz giving 1/20e6*7 bit period > of 7.14ns. I have a 200MHz clock on the board for IDELAY, I could use both > edges to oversample the cameralink data (and 20MHz subclock to ease data > recovery) by sampling at 2.5ns. But this is going to be a nightmare to > peice together (it can be done offline) and require lots of storage...... > > Is there a more elegant way of capturing the data please? > > The application is to take an image of a satellite on seperation from the > launcher in space - its a nice to have but I'd really like to make this > work. > > > > --------------------------------------- > Posted through http://www.FPGARelated.com Well it's more rework to your board, but the real way to do this is to bring the LVDS right into the V4 instead of using receivers. I've never used V4, but at least in V5 I found that I needed to use PLL's instead of DCM's for a reliable 7:1 deserialization. If you were going to convert signals to TTL levels, then it would make a lot more sense to use the National DS90CR288A chips instead of just receivers. Sampling with an asynchronous clock sounds like a nightmare. -- GaborArticle: 153866
On Thursday, June 14, 2012 7:11:04 AM UTC-4, ees3dc wrote: > I have a cameralink (LVDS SERDES) I'm trying to capture data with using a > Virtex 4 mature product. I have ported the XAPP485 deserializer using V4 > primitives (slightly different to Spartan3A) and configured the DCM to ru= n > at 32MHz.=20 >=20 > The problem is the LVDS-TTL receivers on the PCB cannot run at the 32MHz = x7 > rate. The slow risetime means I hardly see a 2V '1' threshold in the > Xilinx. >=20 > I therefore need to reduce the incoming clock rate, but the DCM minimum > frequency is 32MHz....=20 >=20 > OK, I could reduce the cameralink down to 20MHz giving 1/20e6*7 bit perio= d > of 7.14ns. I have a 200MHz clock on the board for IDELAY, I could use bot= h > edges to oversample the cameralink data (and 20MHz subclock to ease data > recovery) by sampling at 2.5ns. But this is going to be a nightmare to > peice together (it can be done offline) and require lots of storage...... >=20 > Is there a more elegant way of capturing the data please? >=20 > The application is to take an image of a satellite on seperation from the > launcher in space - its a nice to have but I'd really like to make this > work. >=20 > =20 > =09 > --------------------------------------- =09 > Posted through http://www.FPGARelated.com ees3dc, Some thoughts: If you are at the frequency limit of your LVDS translation buffers, you wil= l have no choice but to lower the clock frequency on the transmit input sid= e such that your LVDS translation buffers then work with a cameralink clock which is 7x= of the transmit as well as receive side clocks. That is true regardless of= whatever approach you take within the FPGA. If you must push it, and you d= esire all the margin on the logic levels you can get,then because at the FP= GA the IOB is a receiver, you could make the input buffer a LVCMOS25 which = has a Vin of 1.7v instead of 2.0v. Check out the datasheet, the 32MHz lower bound is for the clkoutx. For clkd= v, it is 2MHz. Hence you should be able to derive a clock which is 1:7 from= the cameralink clock using the DCM. Higher input frequency can be an issue= as then the DCM jitter comes into play so be careful. I suspect it is one = (of possibly many) reasons Xilinx had to introduce PLLs in their successors= to the Virtex-4 when bit rates got beyond the ~3-500Mbps range. An issue you will have is that while this derived receive side clock is for= all intents and purposes of the same frequency of the transmit side clock,= there is no (easy) way to guarantee they are both in phase. As such, you w= ill need to double-buffer the de-serializers for each of the 4 streams on t= he cameralink so that nothing is missed. This of course then followed by sy= nchronizing to the derived receive clock. Regards, CarltonArticle: 153867
Maybe is time write more about price and about firm specialized in PGA-to-ASIC replacement. Please, add company name and Your experience with company. Some details about price for sample, some detail about low, med or high volume production. Best Mario.Article: 153868
The price will vary massively depending on your design, the target technology, as well what non-logic blocks you've been using in the FPGA and any FPGA vendor supplied IP. You could be looking at a cost anywhere from $50k to several million $. Cheers, JonArticle: 153869
On Jun 14, 6:11=A0am, "markc" <yuzhe_zhang@n_o_s_p_a_m.hotmail.com> wrote: > hi, guys: > > i'm designing a fifo using XILINX FPGA V6. the fifo will be used to > transport data between ARM11(OR POWERPC) and TI DSP 6474. i know it's > related to the bus clock of both side, but how to calculate the max data > rate that can be transferred. > can anyone tell me how? > thanks! > > markc > > --------------------------------------- > Posted throughhttp://www.FPGARelated.com Usually the max speed is slower one Let say, you can make $10,000 each month,..but your spouse can spend max $6,666 per 30 days so the max you can give her (via the FIFO mail box) is $6,666/month... because if you give her more than that she will give $$$ to someone elseArticle: 153870
carltonnbd@gmail.com wrote: [snip] > An issue you will have is that while this derived receive side clock > is for all intents and purposes of the same frequency of the transmit > side clock, there is no (easy) way to guarantee they are both in > phase. As such, you will need to double-buffer the de-serializers for > each of the 4 streams on the cameralink so that nothing is missed. > This of course then followed by synchronizing to the derived receive > clock. I'm not sure I follow you on this one. If you look at the transmit diagram in the DS90CR287 data sheet, the clock signal looks like any other data line with a word of 1100011, i.e. it is high for 4 bit periods and low for three, and a data word starts in the middle of a clock high period. All of my Camera Link receiver designs treat the clock like a 5th data line. I deserialize it and use the 0->1 transition to predict a word starting two cycles later. In a Virtex 5 I have to play some games to route the clk pair to a PLL as well as the deserializer. I'm not sure if V4 has any similar restrictions. -- GaborArticle: 153871
On 06/14/2012 06:11 AM, markc wrote: > hi, guys: > > i'm designing a fifo using XILINX FPGA V6. the fifo will be used to > transport data between ARM11(OR POWERPC) and TI DSP 6474. i know it's > related to the bus clock of both side, but how to calculate the max data > rate that can be transferred. > can anyone tell me how? > thanks! > > markc The various time values are tabulated in the switching characteristics section of the device data sheet. Their descriptions are in the device user guide. Both documents are available at the Xilinx website.Article: 153872
Hi Gabor, If I understand your approach correctly, you are using the higher clock rat= e further into the chain. As such, your approach with detecting the rising = edge makes perfect sense. There is no need for the second register set. What I was referring to had the presumption that it is/was desired to trans= ition to the slower clock. For example, perhaps right after the de-serializ= er. Because the de-serializer is always working when the link is active and= because there is a phase shift relative to the slower clock, it is necessa= ry to additionally register right after the de-serializer to permit alignme= nt to the slower clock while at the same time not dropping or losing anythi= ng. Also note, that my comment about the DCM was backwards. I meant to mention = a 1:7 not 7:1. For some reason I got on a 7:1 track. Woops. To pull off a 1= :7 will require 2 DCMs. The first operates in a mode to permit a lower (th= an 32MHz) CLKIN frequency but outputs (a) a CLKFX higher frequency clock co= mpatible with the second DCM and (b) a regenerated slower clock. The second= DCM receives the now compatible clock from the first DCM and creates the f= inal overall 1:7. Regards, CarltonArticle: 153873
carltonnbd@gmail.com wrote: > Hi Gabor, > > If I understand your approach correctly, you are using the higher clock rate further into the chain. As such, your approach with detecting the rising edge makes perfect sense. There is no need for the second register set. > > What I was referring to had the presumption that it is/was desired to transition to the slower clock. For example, perhaps right after the de-serializer. Because the de-serializer is always working when the link is active and because there is a phase shift relative to the slower clock, it is necessary to additionally register right after the de-serializer to permit alignment to the slower clock while at the same time not dropping or losing anything. > > Also note, that my comment about the DCM was backwards. I meant to mention a 1:7 not 7:1. For some reason I got on a 7:1 track. Woops. To pull off a 1:7 will require 2 DCMs. The first operates in a mode to permit a lower (than 32MHz) CLKIN frequency but outputs (a) a CLKFX higher frequency clock compatible with the second DCM and (b) a regenerated slower clock. The second DCM receives the now compatible clock from the first DCM and creates the final overall 1:7. > > Regards, > Carlton It's been a while since I did that part of the design, but my recollection is that I gave up on the ISERDES and just ended up using input DDR flops at 3.5x the word rate. It was easier than trying to decipher the bit-slip business when I have no guaranteed pattern on the inputs (except the clock). The original design was implemented on Lattice ECP2 with their 4x gearbox and an output clock rate of 1.75x the word rate. In any case I put the data into a long (56-bit) register 2 or 4 bits at a time in the incoming clock domain (3.5x or 1.75x) and read it out 7 bits at a time with an unrelated clock guaranteed to exceed the word rate (a sort of FIFO). My design had six of these inputs, so I needed to conserve clock resources as much as possible. In V5, one PLL does the work of 2 DCM's, and does it better with more jitter tolerance and less output jitter. In my case I needed to deal with the full frequency range of Channel-Link or 20 to 85 MHz, which also requires using the DRP port of the PLL to switch between high and low frequency range settings. At the low end, the PLL works down to 19 MHz. In any case I didn't have the OP's problem of slow receivers because I put the camera link input directly to the V5 with only some ESD protection diodes in between. Regards, GaborArticle: 153874
On Jun 18, 6:01=A0pm, carlton...@gmail.com wrote: > Hi Gabor, > > If I understand your approach correctly, you are using the higher clock r= ate further into the chain. As such, your approach with detecting the risin= g edge makes perfect sense. There is no need for the second register set. > > What I was referring to had the presumption that it is/was desired to tra= nsition to the slower clock. For example, perhaps right after the de-serial= izer. Because the de-serializer is always working when the link is active a= nd because there is a phase shift relative to the slower clock, it is neces= sary to additionally register right after the de-serializer to permit align= ment to the slower clock while at the same time not dropping or losing anyt= hing. > > Also note, that my comment about the DCM was backwards. I meant to mentio= n a 1:7 not 7:1. For some reason I got on a 7:1 track. Woops. To pull off a= 1:7 =A0will require 2 DCMs. The first operates in a mode to permit a lower= (than 32MHz) CLKIN frequency but outputs (a) a CLKFX higher frequency cloc= k compatible with the second DCM and (b) a regenerated slower clock. The se= cond DCM receives the now compatible clock from the first DCM and creates t= he final overall 1:7. > > Regards, > Carlton can't you just generate the 7x clock with clkfx of single dcm? shift data and clock in to regsister on that 7x clk, look for the transition on clock move the right bits from the shifter to a register generate your slow clock with a divider aligned with the data update -Lasse
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