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
Hey all -- So I've got yet another project making me say "Gosh it'd be nice to be able to implement a DAC/ADC directly in the FPGA." And so I looked around and found all the same white papers I always find wherein a first-order delta-sigma modulated ADC or DAC is implemented using only an FPGA and an RC filter. I've done the DAC one before, but only in closed loop situations where the actual accuracy doesn't matter much. Has anyone actually tried doing either of these in a real quantitative sense and gotten a feel for what sorts of results can be accomplished? Offhand, it seems like if you managed 12 bits it'd be a miracle. Even if you stabilized the power supply voltages (and had zero ground bounce induced by the rest of the logic), it seems like you'd need rise/fall symmetry into the femtoseconds on the digital outputs in order to not shoot your linearity. -- Rob Gaddi, Highland Technology Email address is currently out of orderArticle: 152051
On 06/28/2011 09:34 AM, Rob Gaddi wrote: > Hey all -- > > So I've got yet another project making me say "Gosh it'd be nice to be > able to implement a DAC/ADC directly in the FPGA." And so I looked > around and found all the same white papers I always find wherein a > first-order delta-sigma modulated ADC or DAC is implemented using only > an FPGA and an RC filter. > > I've done the DAC one before, but only in closed loop situations where > the actual accuracy doesn't matter much. Has anyone actually tried doing > either of these in a real quantitative sense and gotten a feel for what > sorts of results can be accomplished? > > Offhand, it seems like if you managed 12 bits it'd be a miracle. Even if > you stabilized the power supply voltages (and had zero ground bounce > induced by the rest of the logic), it seems like you'd need rise/fall > symmetry into the femtoseconds on the digital outputs in order to not > shoot your linearity. I've done this exactly once -- I implemented a DAC that fed the ever-hi-fi LM386 (or maybe it was an LM358 and a couple of transistors) and a little speaker out of my junk box. I needed it to listen in on digital phone signals that I was decoding, and I have to say, the dial tone was unambiguous every time. I suspect that if you wanted to do this for real it would be essential to use an external part for the 1-bit DAC element. Up to some point you could probably get away with a single-gate 74xx04 -- something like an AHC or similar way-fast, way-high-drive family, operating into a fairly high impedance, should give you decent symmetry. Power that part off of its very own, very quiet supply, be very careful with grounds, and you may be able to do astonishing things. I think 12 bits would come easily, and I'm willing to bet that 16 bits wouldn't be at all unachievable. In fact, you may even be able to do something perverted like compensating for the analog asymmetry in digital-land, and push the thing up to 20 bits -- assuming that all the surrounding circuitry were good for that. I do think that you'd want to go to at least a 2nd-order sigma-delta, however. Patent the approach when you're done, and sell the IP on Xilinx's and Altera's IP store. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com Do you need to implement control loops in software? "Applied Control Theory for Embedded Systems" was written for you. See details at http://www.wescottdesign.com/actfes/actfes.htmlArticle: 152052
On 06/27/2011 03:36 PM, Jonathan Bromley wrote: > It was all going so well until I asked XST to compile a > VHDL entity with a generic of this type: > type video_modes_e is (vesa_1024x768_65Hz); > I guess I'll have more modes later, but just now I > need only the one. But as soon as I put a generic > of type video_modes_e on any entity, I get > INTERNAL_ERROR:Xst:cmain.c:3464:1.56 - Process will terminate > followed by nice friendly suggestions about filing a WebCase. > > Anyone else met this? I fixed it by adding a dummy value to > the enumeration, but that's a bit rubbish, isn't it? > > I'll file the case, but thought y'all might be interested. Yes, it's a bit rubbish. You'd expect tools to be able to gracefully handle this sort of thing. But the pain involved in defining an element vesa_abnormal_brain_do_not_use or vesa_xst_sucks is pretty low, and if you choose the name right there's not much chance folks will mistake it for the real deal. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com Do you need to implement control loops in software? "Applied Control Theory for Embedded Systems" was written for you. See details at http://www.wescottdesign.com/actfes/actfes.htmlArticle: 152053
"Tim Wescott" <tim@seemywebsite.com> wrote in message news:OrqdnZgJPa5oi5fTnZ2dnUVZ_sednZ2d@web-ster.com... > On 06/28/2011 09:34 AM, Rob Gaddi wrote: >> Hey all -- >> >> So I've got yet another project making me say "Gosh it'd be nice to be >> able to implement a DAC/ADC directly in the FPGA." And so I looked >> around and found all the same white papers I always find wherein a >> first-order delta-sigma modulated ADC or DAC is implemented using only >> an FPGA and an RC filter. >> >> I've done the DAC one before, but only in closed loop situations where >> the actual accuracy doesn't matter much. Has anyone actually tried doing >> either of these in a real quantitative sense and gotten a feel for what >> sorts of results can be accomplished? >> >> Offhand, it seems like if you managed 12 bits it'd be a miracle. Even if >> you stabilized the power supply voltages (and had zero ground bounce >> induced by the rest of the logic), it seems like you'd need rise/fall >> symmetry into the femtoseconds on the digital outputs in order to not >> shoot your linearity. > > I've done this exactly once -- I implemented a DAC that fed the ever-hi-fi > LM386 (or maybe it was an LM358 and a couple of transistors) and a little > speaker out of my junk box. I needed it to listen in on digital phone > signals that I was decoding, and I have to say, the dial tone was > unambiguous every time. > > I suspect that if you wanted to do this for real it would be essential to > use an external part for the 1-bit DAC element. Up to some point you > could probably get away with a single-gate 74xx04 -- something like an AHC > or similar way-fast, way-high-drive family, operating into a fairly high > impedance, should give you decent symmetry. Or an LVDS line receiver > Power that part off of its very own, very quiet supply, Yep >be very careful with grounds, and you may be able to do astonishing things. LVDS helps hereArticle: 152054
On Tue, 28 Jun 2011 05:33:42 -0500, "RCIngham" wrote: >... it's the sort of degenerate case that I would not >expect many parsers to handle well. Did you simulate it? I'm only slightly insulted :-) Yes, I did, and it does. Clearly this is a slightly odd case, but actually the idea of an enum with only one value is far from crazy. In this case, I'm using the enum to index into a table of constant records. Consequently, if I add a dummy enum, I'm obliged to add a dummy record too. Evidently this problem will go away of its own accord as soon as I have a second useful entry in the table, but the broken parser/elaborator is nevertheless disappointing - and it cost me a wasted evening on my little playtime project, an excuse to start using VHDL and Xilinx tools again after a long absence (and my first brush with ISE 13, which on balance seems to be A Good Thing). -- Jonathan BromleyArticle: 152055
On Tue, 28 Jun 2011 00:30:13 +0100, Alan Fitch wrote: > I've always told people including me; and yes, I did listen at the time :-) >it was safest to stick to generics that are >integer (and subtypes thereof). Recently, I'd changed my tune, as >various tools coped fine with boolean, enum, etc.. Now I will change my >tune back again :-) Well, I thought to myself "that Alan Fitch isn't mentoring me any more, so I am free to do all manner of wild and wacky things", and look where it got me... >Generally broken stuff in XST can be worked around by writing a wrapper >round the top level - which is also a bit rubbish I suppose. Ho hum. At least it's about four orders of magnitude less horrible than the day job's current concern, which is all about what is or isn't a constant in SystemVerilog covergroups. Never in the field of, etc, etc, have so many different tools given so many different "not yet implemented" errors... -- Jonathan BromleyArticle: 152056
On Tue, 28 Jun 2011 21:18:07 +0100, Andrew Holme wrote: > "Tim Wescott" <tim@seemywebsite.com> wrote in message > news:OrqdnZgJPa5oi5fTnZ2dnUVZ_sednZ2d@web-ster.com... >> On 06/28/2011 09:34 AM, Rob Gaddi wrote: >>> Hey all -- >>> >>> So I've got yet another project making me say "Gosh it'd be nice to be >>> able to implement a DAC/ADC directly in the FPGA." And so I looked >>> around and found all the same white papers I always find wherein a >>> first-order delta-sigma modulated ADC or DAC is implemented using only >>> an FPGA and an RC filter. >>> >>> I've done the DAC one before, but only in closed loop situations where >>> the actual accuracy doesn't matter much. Has anyone actually tried >>> doing either of these in a real quantitative sense and gotten a feel >>> for what sorts of results can be accomplished? >>> >>> Offhand, it seems like if you managed 12 bits it'd be a miracle. Even >>> if you stabilized the power supply voltages (and had zero ground >>> bounce induced by the rest of the logic), it seems like you'd need >>> rise/fall symmetry into the femtoseconds on the digital outputs in >>> order to not shoot your linearity. >> >> I've done this exactly once -- I implemented a DAC that fed the >> ever-hi-fi LM386 (or maybe it was an LM358 and a couple of transistors) >> and a little speaker out of my junk box. I needed it to listen in on >> digital phone signals that I was decoding, and I have to say, the dial >> tone was unambiguous every time. >> >> I suspect that if you wanted to do this for real it would be essential >> to use an external part for the 1-bit DAC element. Up to some point >> you could probably get away with a single-gate 74xx04 -- something like >> an AHC or similar way-fast, way-high-drive family, operating into a >> fairly high impedance, should give you decent symmetry. > > Or an LVDS line receiver > >> Power that part off of its very own, very quiet supply, > > Yep > >>be very careful with grounds, and you may be able to do astonishing >>things. > > LVDS helps here Wow -- I hadn't even thought about clock jitter. I should have, but I didn't. I suppose if you _really_ wanted to do a hot-stuff job you'd take the modulator output from the FPGA and regenerate it with a way-clean clock. You'll end up with delay in your loop, but lose some noise. You'd have to sit back and do some math to figure out what sort of performance could be hoped for from an any-old-which-way implementation. -- Tim Wescott Control system and signal processing consulting www.wescottdesign.comArticle: 152057
On Tue, 28 Jun 2011 11:44:49 -0700, Tim Wescott wrote: >vesa_abnormal_brain_do_not_use heh. Best laugh for days. Walk this way! -- Jonathan BromleyArticle: 152058
On Mon, 27 Jun 2011 23:36:49 +0100, Jonathan Bromley wrote: >It was all going so well until I asked XST to compile a >VHDL entity with a generic of this type: > type video_modes_e is (vesa_1024x768_65Hz); >I guess I'll have more modes later, but just now I >need only the one. But as soon as I put a generic >of type video_modes_e on any entity, I get > INTERNAL_ERROR:Xst:cmain.c:3464:1.56 - Process will terminate [...] >I'll file the case, but thought y'all might be interested. Wow. Serious kudos to Xilinx's support team. I got an intelligent, courteous response overnight, and then a real working fix three hours later. The fix is to add -use_new_parser yes to the XST command line (or, equivalently, put it in Synthesis Process Properties/Other XST Command Line Options). Apparently it's the default if you're using newer devices, though I haven't investigated that in detail. I'm using a heritage Spartan-3. Problem solved, job done, happy customer. -- Jonathan BromleyArticle: 152059
Hi, I read the application note “Virtex-5 FPGA Interface to JESD204A Compliant ADC”. I’m designing a pcb with a JESD204A NXP DAC linked to Spartan-6 GTP Dual tiles. I try to know If I’m actually going to be able to implement this interface in Spartan-6. For example, in the application note, the REFCLKOUT is used to feed some FPGA Logic (in Virtex-5) but I can read from UG386 p93(for Spartan-6) that I should not use this output… In general terms, Is there any important difference between Virtex-5 and Spartan-6 that would prevent me from implementing the JESD204A interface in Spartan-6? Thanks a lot for any indication that could help, YH --------------------------------------- Posted through http://www.FPGARelated.comArticle: 152060
Hello all, I am presently working with a virtix 5 FPGA and trying to get the rocket IOs to work with reading in the data generated from my ADC. The ADC is clocked at 500MHz and I have 5 LVDS outputs, my clock at 500MHz and my data 4 bits transitioning at 250Mhz. I am then configuring the FPGA to store the data after it has been serial to parallel converted within the FPGA then I read it out later after it has taken the data so I can process my FFT in matlab. My problem is I know my ADC is working since I first took the data over a scope, but I want to speed up the measuring process by using a cool and fancy FPGA. My question is, can any help me in setting up the rocket IOs so ensure it does not miss any bits or transitions? If 1 in just 1000 samples it wrong my FFT is completely crap and I cant use it! My present setup, which I have no clue if I am correct, is I use the rockets to sync to the incoming data (250MHz bits) only ( not the output clock). I then use the same clock recovered for the data to then clock the data into memory. My question is, is there a better way to do this? Cant i use my 500MHz clock to just clock the other data rocket IOs or since the rocket IOs work off of a PLL, I cant do that..... I feel this must be a standard thing in using the rocket IOs... I just don't have any clue on the proper setup. If anyone could help that would be great! Jgk --------------------------------------- Posted through http://www.FPGARelated.comArticle: 152061
Hi, I implemented a full combinatinal logic in Xilinx FPGA. A white and black eye appears on each SLICE. What does it means?? Thanks --------------------------------------- Posted through http://www.FPGARelated.comArticle: 152062
On 6/28/2011 10:50 PM, Tim wrote: > On Tue, 28 Jun 2011 21:18:07 +0100, Andrew Holme wrote: > >> "Tim Wescott"<tim@seemywebsite.com> wrote in message >> news:OrqdnZgJPa5oi5fTnZ2dnUVZ_sednZ2d@web-ster.com... >>> On 06/28/2011 09:34 AM, Rob Gaddi wrote: >>>> Hey all -- >>>> >>>> So I've got yet another project making me say "Gosh it'd be nice to be >>>> able to implement a DAC/ADC directly in the FPGA." And so I looked >>>> around and found all the same white papers I always find wherein a >>>> first-order delta-sigma modulated ADC or DAC is implemented using only >>>> an FPGA and an RC filter. >>>> >>>> I've done the DAC one before, but only in closed loop situations where >>>> the actual accuracy doesn't matter much. Has anyone actually tried >>>> doing either of these in a real quantitative sense and gotten a feel >>>> for what sorts of results can be accomplished? >>>> >>>> Offhand, it seems like if you managed 12 bits it'd be a miracle. Even >>>> if you stabilized the power supply voltages (and had zero ground >>>> bounce induced by the rest of the logic), it seems like you'd need >>>> rise/fall symmetry into the femtoseconds on the digital outputs in >>>> order to not shoot your linearity. >>> >>> I've done this exactly once -- I implemented a DAC that fed the >>> ever-hi-fi LM386 (or maybe it was an LM358 and a couple of transistors) >>> and a little speaker out of my junk box. I needed it to listen in on >>> digital phone signals that I was decoding, and I have to say, the dial >>> tone was unambiguous every time. >>> >>> I suspect that if you wanted to do this for real it would be essential >>> to use an external part for the 1-bit DAC element. Up to some point >>> you could probably get away with a single-gate 74xx04 -- something like >>> an AHC or similar way-fast, way-high-drive family, operating into a >>> fairly high impedance, should give you decent symmetry. >> >> Or an LVDS line receiver >> >>> Power that part off of its very own, very quiet supply, >> >> Yep >> >>> be very careful with grounds, and you may be able to do astonishing >>> things. >> >> LVDS helps here > > Wow -- I hadn't even thought about clock jitter. I should have, but I > didn't. > > I suppose if you _really_ wanted to do a hot-stuff job you'd take the > modulator output from the FPGA and regenerate it with a way-clean clock. > You'll end up with delay in your loop, but lose some noise. > > You'd have to sit back and do some math to figure out what sort of > performance could be hoped for from an any-old-which-way implementation. > And of course, as you start adding more external parts to the solution, the advantages in board space and cost over just buying a chip vanish. -- Rob Gaddi, Highland Technology Email address is currently out of orderArticle: 152063
On 06/29/2011 09:18 AM, Rob Gaddi wrote: > On 6/28/2011 10:50 PM, Tim wrote: >> On Tue, 28 Jun 2011 21:18:07 +0100, Andrew Holme wrote: >> >>> "Tim Wescott"<tim@seemywebsite.com> wrote in message >>> news:OrqdnZgJPa5oi5fTnZ2dnUVZ_sednZ2d@web-ster.com... >>>> On 06/28/2011 09:34 AM, Rob Gaddi wrote: >>>>> Hey all -- >>>>> >>>>> So I've got yet another project making me say "Gosh it'd be nice to be >>>>> able to implement a DAC/ADC directly in the FPGA." And so I looked >>>>> around and found all the same white papers I always find wherein a >>>>> first-order delta-sigma modulated ADC or DAC is implemented using only >>>>> an FPGA and an RC filter. >>>>> >>>>> I've done the DAC one before, but only in closed loop situations where >>>>> the actual accuracy doesn't matter much. Has anyone actually tried >>>>> doing either of these in a real quantitative sense and gotten a feel >>>>> for what sorts of results can be accomplished? >>>>> >>>>> Offhand, it seems like if you managed 12 bits it'd be a miracle. Even >>>>> if you stabilized the power supply voltages (and had zero ground >>>>> bounce induced by the rest of the logic), it seems like you'd need >>>>> rise/fall symmetry into the femtoseconds on the digital outputs in >>>>> order to not shoot your linearity. >>>> >>>> I've done this exactly once -- I implemented a DAC that fed the >>>> ever-hi-fi LM386 (or maybe it was an LM358 and a couple of transistors) >>>> and a little speaker out of my junk box. I needed it to listen in on >>>> digital phone signals that I was decoding, and I have to say, the dial >>>> tone was unambiguous every time. >>>> >>>> I suspect that if you wanted to do this for real it would be essential >>>> to use an external part for the 1-bit DAC element. Up to some point >>>> you could probably get away with a single-gate 74xx04 -- something like >>>> an AHC or similar way-fast, way-high-drive family, operating into a >>>> fairly high impedance, should give you decent symmetry. >>> >>> Or an LVDS line receiver >>> >>>> Power that part off of its very own, very quiet supply, >>> >>> Yep >>> >>>> be very careful with grounds, and you may be able to do astonishing >>>> things. >>> >>> LVDS helps here >> >> Wow -- I hadn't even thought about clock jitter. I should have, but I >> didn't. >> >> I suppose if you _really_ wanted to do a hot-stuff job you'd take the >> modulator output from the FPGA and regenerate it with a way-clean clock. >> You'll end up with delay in your loop, but lose some noise. >> >> You'd have to sit back and do some math to figure out what sort of >> performance could be hoped for from an any-old-which-way implementation. >> > > And of course, as you start adding more external parts to the solution, > the advantages in board space and cost over just buying a chip vanish. True. But when you get right down to it, for an ADC just implementing the necessary op-amp integrator and comparator is going to rival an external ADC chip. So maybe the thing to do is to figure out the best DAC that you can do with FPGA only, and leave it at that... -- Tim Wescott Wescott Design Services http://www.wescottdesign.com Do you need to implement control loops in software? "Applied Control Theory for Embedded Systems" was written for you. See details at http://www.wescottdesign.com/actfes/actfes.htmlArticle: 152064
>Hello all, > >I am presently working with a virtix 5 FPGA and trying to get the rocket >IOs to work with reading in the data generated from my ADC. The ADC is >clocked at 500MHz and I have 5 LVDS outputs, my clock at 500MHz and my data >4 bits transitioning at 250Mhz. I am then configuring the FPGA to store the >data after it has been serial to parallel converted within the FPGA then I >read it out later after it has taken the data so I can process my FFT in >matlab. My problem is I know my ADC is working since I first took the data >over a scope, but I want to speed up the measuring process by using a cool >and fancy FPGA. My question is, can any help me in setting up the rocket >IOs so ensure it does not miss any bits or transitions? If 1 in just 1000 >samples it wrong my FFT is completely crap and I cant use it! > >My present setup, which I have no clue if I am correct, is I use the >rockets to sync to the incoming data (250MHz bits) only ( not the output >clock). I then use the same clock recovered for the data to then clock the >data into memory. My question is, is there a better way to do this? Cant i >use my 500MHz clock to just clock the other data rocket IOs or since the >rocket IOs work off of a PLL, I cant do that..... > >I feel this must be a standard thing in using the rocket IOs... I just >don't have any clue on the proper setup. If anyone could help that would >be great! > > > >Jgk > > > >--------------------------------------- >Posted through http://www.FPGARelated.com > I am slightly confused as you are talking about LVDS and Rocket IO which are not the same. Usually with ADC designs you would input the LVDS signals from the ADC into the FPGA and use the ISERDES block clocked from the ADC clock. You may also have to use some soft of calibartion scheme involving an IDELAY block to ensure all bits are synchronised. Jon --------------------------------------- Posted through http://www.FPGARelated.comArticle: 152065
On 28/06/11 22:57, Jonathan Bromley wrote: > On Tue, 28 Jun 2011 00:30:13 +0100, Alan Fitch wrote: > <snip> >> Generally broken stuff in XST can be worked around by writing a wrapper >> round the top level - which is also a bit rubbish I suppose. > > Ho hum. At least it's about four orders of magnitude less > horrible than the day job's current concern, which is all > about what is or isn't a constant in SystemVerilog > covergroups. Never in the field of, etc, etc, have > so many different tools given so many different > "not yet implemented" errors... I am still confused by constantness (constantosity??) in SV. I tried putting a const in a package, and then initialising another constant to it in a module. Quartus threw it out as not constant. localparams seem to work fine. I guess I've been mis-guided by VHDL Alan -- Alan FitchArticle: 152066
On Wed, 29 Jun 2011 19:37:53 +0100, Alan Fitch wrote: >I am still confused by constantness (constantosity??) in SV. Hmm, getting seriously OT here, but anyhow... > I tried putting a const in a package, and then > initialising another constant to >it in a module. Quartus threw it out as not constant. localparams seem >to work fine. First thing to get straight is that const doesn't mean constant in SV; it's closer to "read-only". Consts can be initialised, but not altered after initialisation, unless they're data members of a class in which case they can be written only once in the class's constructor, or they are ref arguments to a subprogram in which case they refer to something that's read-only from the subprogram's point of view. In all these cases, the things in question are variables, not constants. Parameters and localparams, au contraire, are truly constant (look for "constant expression" in 1800-2009). Their value is determined during elaboration and is immutable thenceforward. This elaboration-time determination of value means that parameters, and indeed constant expressions in general, can be used to specify and control the attributes of a data type such as bit-width. Can't do that with a const. Similarly, any attributes scavenged from a data type such as $left() are also constant expressions. And then, just for laughs, there are the rules about constant expressions not being allowed to include any hierarchical (cross-module) references. Never mind, it could be worse. I spent about four months fighting the function/operator overload resolution rules in C++ a little while ago. That was truly a nightmare. Bring back VHDL... -- Jonathan BromleyArticle: 152067
Hello Jon, I have output LVDS drive on my asic chip which I am then interfacing to the rocket IOs of the FPGA. Sorry for the confusion. So you are saying thou that I should not try any clock recoverary but just the clock from my asic? Is there anything else I would need to know to get this working properly? Thanks so much Jgk >>Hello all, >> >>I am presently working with a virtix 5 FPGA and trying to get the rocket >>IOs to work with reading in the data generated from my ADC. The ADC is >>clocked at 500MHz and I have 5 LVDS outputs, my clock at 500MHz and my >data >>4 bits transitioning at 250Mhz. I am then configuring the FPGA to store >the >>data after it has been serial to parallel converted within the FPGA then >I >>read it out later after it has taken the data so I can process my FFT in >>matlab. My problem is I know my ADC is working since I first took the >data >>over a scope, but I want to speed up the measuring process by using a >cool >>and fancy FPGA. My question is, can any help me in setting up the rocket >>IOs so ensure it does not miss any bits or transitions? If 1 in just 1000 >>samples it wrong my FFT is completely crap and I cant use it! >> >>My present setup, which I have no clue if I am correct, is I use the >>rockets to sync to the incoming data (250MHz bits) only ( not the output >>clock). I then use the same clock recovered for the data to then clock >the >>data into memory. My question is, is there a better way to do this? Cant >i >>use my 500MHz clock to just clock the other data rocket IOs or since the >>rocket IOs work off of a PLL, I cant do that..... >> >>I feel this must be a standard thing in using the rocket IOs... I just >>don't have any clue on the proper setup. If anyone could help that would >>be great! >> >> >> >>Jgk >> >> >> >>--------------------------------------- >>Posted through http://www.FPGARelated.com >> > >I am slightly confused as you are talking about LVDS and Rocket IO which >are not the same. Usually with ADC designs you would input the LVDS signals >from the ADC into the FPGA and use the ISERDES block clocked from the ADC >clock. You may also have to use some soft of calibartion scheme involving >an IDELAY block to ensure all bits are synchronised. > >Jon > >--------------------------------------- >Posted through http://www.FPGARelated.com > --------------------------------------- Posted through http://www.FPGARelated.comArticle: 152068
>Hello Jon, > >I have output LVDS drive on my asic chip which I am then interfacing to the >rocket IOs of the FPGA. Sorry for the confusion. So you are saying thou >that I should not try any clock recoverary but just the clock from my asic? > Is there anything else I would need to know to get this working properly? > >Thanks so much > >Jgk > > >>>Hello all, >>> >>>I am presently working with a virtix 5 FPGA and trying to get the rocket >>>IOs to work with reading in the data generated from my ADC. The ADC is >>>clocked at 500MHz and I have 5 LVDS outputs, my clock at 500MHz and my >>data >>>4 bits transitioning at 250Mhz. I am then configuring the FPGA to store >>the >>>data after it has been serial to parallel converted within the FPGA then >>I >>>read it out later after it has taken the data so I can process my FFT in >>>matlab. My problem is I know my ADC is working since I first took the >>data >>>over a scope, but I want to speed up the measuring process by using a >>cool >>>and fancy FPGA. My question is, can any help me in setting up the rocket >>>IOs so ensure it does not miss any bits or transitions? If 1 in just >1000 >>>samples it wrong my FFT is completely crap and I cant use it! >>> >>>My present setup, which I have no clue if I am correct, is I use the >>>rockets to sync to the incoming data (250MHz bits) only ( not the output >>>clock). I then use the same clock recovered for the data to then clock >>the >>>data into memory. My question is, is there a better way to do this? Cant >>i >>>use my 500MHz clock to just clock the other data rocket IOs or since the >>>rocket IOs work off of a PLL, I cant do that..... >>> >>>I feel this must be a standard thing in using the rocket IOs... I just >>>don't have any clue on the proper setup. If anyone could help that >would >>>be great! >>> >>> >>> >>>Jgk >>> >>> >>> >>>--------------------------------------- >>>Posted through http://www.FPGARelated.com >>> >> >>I am slightly confused as you are talking about LVDS and Rocket IO which >>are not the same. Usually with ADC designs you would input the LVDS >signals >>from the ADC into the FPGA and use the ISERDES block clocked from the ADC >>clock. You may also have to use some soft of calibartion scheme involving >>an IDELAY block to ensure all bits are synchronised. >> >>Jon >> >>--------------------------------------- >>Posted through http://www.FPGARelated.com >> > >--------------------------------------- >Posted through http://www.FPGARelated.com > I am even more confused now as first you say you have an ADC and now you say an ASIC. I think you need to specify exactly what you have. Is it an ADC from say TI or is it a custom ASIC chip? Rocket IO do not even use LVDS type signals so I dont really see what you are trying to do. Jon --------------------------------------- Posted through http://www.FPGARelated.comArticle: 152069
Hello Jon, I designed a custom ASIC sigma delta ADC and i do not decimate on chip. so thus my data is coming out on 4 bits at 250MHz (clocked at 500MHz). On my ASIC, i designed custom 1.2V LVDS drivers that need a 100ohm termination off chip. I am using the rocket IOs and terminating them internally by programming them to have 100Ohm termination. I then set the rocket IOs to be lvds standard inputs.... which I think is correct to read in my data. I have to use the rocket IOs since my data is at 250MHz.....clocked at 500Mhz.. Am I doing anything wrong here? What type of signals would you normally use rocket IOs at... and even at high data rates.... I would think lvds type signals... Now what i think i am having trouble with is setting up the syncing... Is that alittle bit more clear? Jgk >>Hello Jon, >> >>I have output LVDS drive on my asic chip which I am then interfacing to >the >>rocket IOs of the FPGA. Sorry for the confusion. So you are saying thou >>that I should not try any clock recoverary but just the clock from my >asic? >> Is there anything else I would need to know to get this working >properly? >> >>Thanks so much >> >>Jgk >> >> >>>>Hello all, >>>> >>>>I am presently working with a virtix 5 FPGA and trying to get the >rocket >>>>IOs to work with reading in the data generated from my ADC. The ADC is >>>>clocked at 500MHz and I have 5 LVDS outputs, my clock at 500MHz and my >>>data >>>>4 bits transitioning at 250Mhz. I am then configuring the FPGA to store >>>the >>>>data after it has been serial to parallel converted within the FPGA >then >>>I >>>>read it out later after it has taken the data so I can process my FFT >in >>>>matlab. My problem is I know my ADC is working since I first took the >>>data >>>>over a scope, but I want to speed up the measuring process by using a >>>cool >>>>and fancy FPGA. My question is, can any help me in setting up the >rocket >>>>IOs so ensure it does not miss any bits or transitions? If 1 in just >>1000 >>>>samples it wrong my FFT is completely crap and I cant use it! >>>> >>>>My present setup, which I have no clue if I am correct, is I use the >>>>rockets to sync to the incoming data (250MHz bits) only ( not the >output >>>>clock). I then use the same clock recovered for the data to then clock >>>the >>>>data into memory. My question is, is there a better way to do this? >Cant >>>i >>>>use my 500MHz clock to just clock the other data rocket IOs or since >the >>>>rocket IOs work off of a PLL, I cant do that..... >>>> >>>>I feel this must be a standard thing in using the rocket IOs... I just >>>>don't have any clue on the proper setup. If anyone could help that >>would >>>>be great! >>>> >>>> >>>> >>>>Jgk >>>> >>>> >>>> >>>>--------------------------------------- >>>>Posted through http://www.FPGARelated.com >>>> >>> >>>I am slightly confused as you are talking about LVDS and Rocket IO which >>>are not the same. Usually with ADC designs you would input the LVDS >>signals >>>from the ADC into the FPGA and use the ISERDES block clocked from the >ADC >>>clock. You may also have to use some soft of calibartion scheme >involving >>>an IDELAY block to ensure all bits are synchronised. >>> >>>Jon >>> >>>--------------------------------------- >>>Posted through http://www.FPGARelated.com >>> >> >>--------------------------------------- >>Posted through http://www.FPGARelated.com >> > >I am even more confused now as first you say you have an ADC and now you >say an ASIC. I think you need to specify exactly what you have. Is it an >ADC from say TI or is it a custom ASIC chip? Rocket IO do not even use LVDS >type signals so I dont really see what you are trying to do. > >Jon > >--------------------------------------- >Posted through http://www.FPGARelated.com > --------------------------------------- Posted through http://www.FPGARelated.comArticle: 152070
>Hello Jon, > >I designed a custom ASIC sigma delta ADC and i do not decimate on chip. so >thus my data is coming out on 4 bits at 250MHz (clocked at 500MHz). On my >ASIC, i designed custom 1.2V LVDS drivers that need a 100ohm termination >off chip. I am using the rocket IOs and terminating them internally by >programming them to have 100Ohm termination. I then set the rocket IOs to >be lvds standard inputs.... which I think is correct to read in my data. I >have to use the rocket IOs since my data is at 250MHz.....clocked at >500Mhz.. Am I doing anything wrong here? What type of signals would you >normally use rocket IOs at... and even at high data rates.... I would think >lvds type signals... Now what i think i am having trouble with is setting >up the syncing... > >Is that alittle bit more clear? > You would normally use Rocket IO for signals that are in the GHz range. LVDS on a Virtex 5 would easily handle a 250 MHz signal. Take a look at the Xilinx website as they have some application notes on interfacing ADCs. You do not want to be using Rocket IO for this type of application. Jon --------------------------------------- Posted through http://www.FPGARelated.comArticle: 152071
Hello Jon, So I do understand that 250MHz isn't fast, and the rocket IOs operate up to 3+GHz. The reason why I am using the rocket IOs now is because my next ASIC will be clocked at 1GHz to 1.5GHz.... So I was thinking if I can get the rocket ios working at 250MHz it should be problem reprogramming them to a higher rate. When you say that LVDS on the virtex 5 could easily be handled at 250MHz would I then need a core clock at above 250MHz? Also what is hte max LVDS could be used on the virtex 5 without the rocket IOs? Can i use LVDS at 1GHz? Jgk >You would normally use Rocket IO for signals that are in the GHz range. >LVDS on a Virtex 5 would easily handle a 250 MHz signal. Take a look at the >Xilinx website as they have some application notes on interfacing ADCs. You >do not want to be using Rocket IO for this type of application. > >Jon > >--------------------------------------- >Posted through http://www.FPGARelated.com > --------------------------------------- Posted through http://www.FPGARelated.comArticle: 152072
On Wed, 29 Jun 2011 13:15:02 +0100, Jonathan Bromley wrote: > On Mon, 27 Jun 2011 23:36:49 +0100, Jonathan Bromley wrote: > >> INTERNAL_ERROR:Xst:cmain.c:3464:1.56 - Process will terminate > [...] >>I'll file the case, but thought y'all might be interested. > > Wow. Serious kudos to Xilinx's support team. I got an intelligent, > courteous response overnight, and then a real working fix three hours > later. > > The fix is to add > > -use_new_parser yes AHA! I had heard that XST13 used a new VHDL front end, and was dreading training it to understand code tweaked to suit old XST foibles. If this is a problem with the old parser, that suggests older versions of XST might blow up in the same way. Have you tried XST12 or earlier? Also it's good to know that both parsers are available in case of trouble. > Apparently it's the default if you're using newer devices, though I > haven't investigated that in detail. I'm using a heritage Spartan-3. > > Problem solved, job done, happy customer. And if newer really = better, then kudos to the XST team. I haven't got around to trying out my carefully cultivated nest of vipers on ISE13 yet. - BrianArticle: 152073
>Hello Jon, > >So I do understand that 250MHz isn't fast, and the rocket IOs operate up to >3+GHz. The reason why I am using the rocket IOs now is because my next ASIC >will be clocked at 1GHz to 1.5GHz.... So I was thinking if I can get the >rocket ios working at 250MHz it should be problem reprogramming them to a >higher rate. > >When you say that LVDS on the virtex 5 could easily be handled at 250MHz >would I then need a core clock at above 250MHz? Also what is hte max LVDS >could be used on the virtex 5 without the rocket IOs? Can i use LVDS at >1GHz? > >Jgk It seem to me as though you dont really understand the Virtex 5 architecture. You need to read the user guide and data sheet to get a feel what is possible with a certain IO technology. Rocket IO uses CML type drivers which are different to LVDS. LVDS upto 1.25 Gb/s is possible. Jon --------------------------------------- Posted through http://www.FPGARelated.comArticle: 152074
DPStronics (http://www.dsptronics.com) is hosting a design contest (http://dsptronics.webfactional.com).
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