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 18.06.2010 20:25, Gabor wrote: > On Jun 18, 1:27 pm, Rob Gaddi<rga...@technologyhighland.com> wrote: >> I'm no luck figuring out how to implement the timing constraints for >> something that, to my mind, ought to be pretty simple. I'm connected to >> an external synchronous logic chip. For now let's call it a regular >> 74HC74 flip flop, but the details are unimportant. My FPGA outputs D >> and CLK to the 74HC74, and reads back Q. >> >> The FPGA has a single global clock net, call it SysClk. I've got a >> state machine running on SysClk generating both data and clock for this >> widget; the clock is running at a sufficiently low rate that it's being >> generated by a simple, rising-edge only, divide-by-N from my master >> clock. My logic defines both D and CLK in a way that they're registered >> outputs and Q as a registered input with no logic; such that all of them >> should be able to be pushed into the IOBs. >> >> The 74HC74 datasheet tells me that I've got setup time (Ts), hold time >> (Th), and clock-to-output delay (Tcko). How do I go about communicating >> these requirements to the Xilinx toolchain? Clearly it's some >> combination of OFFSET constraints, but what are the magic words? >> >> UG612 discusses the use of the REFERENCE_PIN qualifier to indicate that >> the output data is referred to the output clock, but the example doesn't >> give any advice that would connect those OFFSET constraints to only >> define the relationship between D and CLK, not the entire world and CLK. >> And I can't seem to find any information whatsoever that would let me >> define the relationship between CLK and Q. >> >> I've gone through the Constraints Guide. I've gone through UG612. I've >> gone through Austin's 5 part series over on the Xilinx forums. And I'm >> still lost. Anyone have any revelations for me? >> >> -- >> Rob Gaddi, Highland Technology >> Email address is currently out of order > > Basically, you are using a source synchronous output clock to your > flip-flop. There is no constraint to my knowledge that would do > the job you're looking for which is to define the relative timing > on two outputs. This should be correct by design. i.e. if you > push both CLK and Q outputs into IOB flops, using DDR flops if > necessary for the clock, you should have essentially zero timing > difference between CLK and Q if they are switching on the same > edge of the same global clock. Make your Tsu and Th based on > the relative timing to the IOB flops, for example making CLK > go high on the falling edge of the internal clock and changing > Q on the next rising edge to get 1/2 cycle of hold time. > > HTH, > Gabor Hi! Gabor is right with that there is no constraint that will ensure and check the setup/hold time that your external FF requires. As he already said, use an ODDR block to pass your clock on to the external FF, it is described in the user manual of the FPGA. You can create a timing report though that gives you the relative output delay between clock and data, which will enable you to confirm the setup time for your external FF manually. For this, create a timing group containing only the CLK and D pin and apply an OFFSET OUT constraint with reference pin CLK relative to the internal SysClk. This will give you the report in the .twr file. If the timing is not sufficient, you can delay either CLK or D by an IODELAY or ODELAY block, which is described in the FPGA user manual or the HDL library guide. To constrain and ensure the capture of Q, create a timing group containing only Q and apply an OFFSET IN BEFORE constraint to it, relative to your capturing clock, and specify the setup and hold time that your external FF output signal will exhibit when it is clocked with the timing as reported by the OFFSET OUT contraint and the external FF datasheet. You will have to perform this analysis manually (and theoretically also consider board delays and skews), but if the OFFSET IN constraint holds and represents the real behavior, your design will work. Again, you may manually fix a timing violation by an IODELAY or IDELAY instance on the input pin. There is also a Timing Constraint guide that you can look for at the Xilinx homepage, it should provide you with the exact syntax. Hope I gave you the right keywords ... ChristianArticle: 148076
Hello,
I am a beginner and have tried to learn how to configure my FPGA
(XC3S1600E) in Master Serial Mode using configuration of a design
stored in Platform Flash PROM (XCF04S) .
I use Xilinx ISE 9.1i and followed the steps described in 'Spartan-3
Generation Configuration User Guide (ug332.pdf, pages 42-46 and
91-100) and everything seemed working alright - FPGA bitstream was
generated, PROM file (.mcs) for Platform Flash PROM memory was created
and PROM was successfuly programmed using JTAG ('Program Succeeded'
message appeared). So everything seems working according to the guide
but when I power board off and then on, my FPGA is not configured
according to what I have programmed into PROM.
So my problem is that although PROM is seemed correctly programmed but
FPGA has not being configured after power is on.
What could be reasons for this, what I have missed?
Thank you.
Article: 148077
On Jun 18, 3:14=A0pm, Vic Orloff <vcorl...@gmail.com> wrote:
> Hello,
>
> I am a beginner and have tried to learn how to configure my FPGA
> (XC3S1600E) in Master Serial Mode using configuration of a design
> stored in Platform Flash PROM (XCF04S) .
> I use Xilinx ISE 9.1i and followed the steps described in 'Spartan-3
> Generation Configuration User Guide (ug332.pdf, pages 42-46 and
> 91-100) and everything seemed working alright - FPGA bitstream was
> generated, PROM file (.mcs) for Platform Flash PROM memory was created
> and PROM was successfuly programmed using JTAG ('Program Succeeded'
> message appeared). So everything seems working according to the guide
> but when I power board off and then on, my FPGA is not configured
> according to what I have programmed into PROM.
>
> So my problem is that although PROM is seemed correctly programmed but
> FPGA has not being configured after power is on.
>
> What could be reasons for this, what I have missed?
>
> Thank you.
You can get some debug information from Impact that will
tell you the state of the FPGA config pins. Make sure the
mode pins are correct for your device. Putting the whole
S3 series in one config guide is a bit confusing. The
mode pin definitions vary between S3 families.
Also make sure you generated the .bit file with CCLK as
the startup clock, and that you didn't increase the
CCLK frequency beyond the capability of the XCF04S.
Remember that CCLK frequencies can be +/- 50% of the
nominal value!
Check if the INIT line goes high then low again during startup.
This indicates a CRC error and could be caused by signal integrity
problems or if the .bit file is not generated properly, for example
with bits reversed.
If you have access to the PROG pin, try to ground it momentarily to
see if the FPGA will load. If it does, but not on power-up you may
have a power sequencing problem. If the supply that powers the
XCF04S is the last one up, the FPGA might try to start configuration
before the flash is ready.
It also helps to put a scope on the CCLK line. After power on is
it running constantly? This happens if the FPGA doesn't see a
proper bitstream startup sync pattern and keeps trying to shift in
data, as for example if the Flash is erased.
And of course double check the connections in the schematics for
master serial from the user guide. Make sure you have all the
necessary connections and pullup resistors.
HTH,
Gabor
Article: 148078"rickman" <gnuarm@gmail.com> wrote in message news:54356eb8-3f64-4df7-9997-e916daa71b7c@m21g2000vbr.googlegroups.com... On Jun 2, 7:35 pm, -jg <jim.granvi...@gmail.com> wrote: > On Jun 3, 10:05 am, rickman <gnu...@gmail.com> wrote: > > > > Rather than the uC+CPLD the marketing types are chasing, I would find > > > a CPLD+RAM more useful, as there are LOTS of uC out there already, and > > > if they can make 32KB SRAM for sub $1, they should be able to include > > > it almost for free, in a medium CPLD. > > > > -jg > > > I won't argue with that for a moment. But deciding what to put in a > > part and which flavors to offer in what packages is decided in the > > land of marketing. As much as I whine and complain, I guess I have to > > assume they know *something* about their jobs. > > The product managers are understandably blinkered by what has gone > before, and what they sell now, so in the CPLD market it is very rare > to see a bold step. > > The CoolRunner was the last bold step I recall, and that was not made > by a traditional vendor product manager, but by some new blood. > > Altera, Atmel, Lattice and Xilinx have slowed right down on CPLD > releases, to almost be in 'run out' mode. I've been busy with work the last few months so I tend to forget what I read about trends. I seem to recall that Xilinx has announced something with an MCU in it and not the PPC they used in the past. Do I remember right? Is X coming out with an FPGA with an ARM? Personally, I prefer something other than an ARM inside an FPGA. I want a CPU that executes each instruction in a single clock cycle and has very seriously low interrupt latency. That is why I designed my own CPU at one point. ARM CPUs with FPGAs seem to be oriented to people who want to use lots of memory and run a real time OS. Not that that an ARM or a real time OS is a bad thing, I just want something closer to the metal. If I could get a good MCU in an FPGA (which would certainly have some adequate memory) in a "convenient" package, that would really make my day. I don't have to have the analog stuff, but 5 volt tolerance would certainly be useful. That alone would take two chips off my board and maybe more. Rick -- ARM Cortex-M3 is in Actel SmartFusion FPGAs. Not in small package, though. -- Jaime Andres Aranguren Cardona SanJaaC Electronics Soluciones en DSP www.sanjaac.comArticle: 148079
Is anyone else not able to view the link anymore? I can ping the site, but not access the webpage. -Sean.Article: 148080
Thank you very much! It looks a very good list of key points to check indeed.Article: 148081
Vic Orloff <vcorloff@gmail.com> writes: > Hello, > > I am a beginner and have tried to learn how to configure my FPGA > (XC3S1600E) in Master Serial Mode using configuration of a design > stored in Platform Flash PROM (XCF04S) . At the very least there's the slight problem of fitting almost 6 Mb of config data into a 4 Mb PROM. Presumably you used compression? But if so, did you limit CCLK to 20 MHz or below for configuration as described in the documentation?Article: 148082
On 19 =D0=B8=D1=8E=D0=BD, 11:43, Anssi Saari <a...@sci.fi> wrote: > Vic Orloff <vcorl...@gmail.com> writes: > > Hello, > > > I am a beginner and have tried to learn how to configure my FPGA > > (XC3S1600E) in Master Serial Mode using configuration of a design > > stored in Platform Flash PROM (XCF04S) . > > At the very least there's the slight problem of fitting almost 6 Mb of > config data into a 4 Mb PROM. Presumably you used compression? But if > so, did you limit CCLK to 20 MHz or below for configuration as > described in the documentation? Hello, Yes, ConfigRate was set to 12 (which is approximately 12 MHz).Article: 148083
Hi, We're using one of the global DCM blocks in a Xilinx Spartan 3E to regenerate/deskew an important clock in our application. The clock has an input frequency of 31.5 MHz and we're using the 270 phase of the X1 output of the block. However, we've observed that the block seems to be marginally stable. At random, the clock output completely dies, usually lasting somewhere between approximately 2 to 6 seconds. We brought out the status signal that indicates "input clock is out of jitter tolerance" and observed that it is pulsing frequently. Indeed, it is during a group of those pulses that the output clock finally dies. Looking at the input clock with a scope doesn't reveal any particular problems. The signal comes from about 2 inches across a 4-layer FR4 board, so it isn't perfect (we've used a 33-ohm series resistor to "match" impedances), but it certainly looks good enough, although I realize that statement is somewhat imprecise and subjective. Anyway, if anyone has experienced or heard of such problems with the DCM module and knows of a fix, I'd appreciate a pointer. Thanks! --Randy -- Randy Yates % "So now it's getting late, Digital Signal Labs % and those who hesitate mailto://yates@ieee.org % got no one..." http://www.digitalsignallabs.com % 'Waterfall', *Face The Music*, ELOArticle: 148084
On Jun 19, 6:00=A0pm, Randy Yates <ya...@ieee.org> wrote: > Hi, > > We're using one of the global DCM blocks in a Xilinx Spartan 3E > to regenerate/deskew an important clock in our application. The > clock has an input frequency of 31.5 MHz and we're using the 270 > phase of the X1 output of the block. > > However, we've observed that the block seems to be marginally > stable. At random, the clock output completely dies, usually > lasting somewhere between approximately 2 to 6 seconds. > > We brought out the status signal that indicates "input clock > is out of jitter tolerance" and observed that it is pulsing > frequently. Indeed, it is during a group of those pulses that > the output clock finally dies. > > Looking at the input clock with a scope doesn't reveal any > particular problems. The signal comes from about 2 inches > across a 4-layer FR4 board, so it isn't perfect (we've > used a 33-ohm series resistor to "match" impedances), but > it certainly looks good enough, although I realize that > statement is somewhat imprecise and subjective. > > Anyway, if anyone has experienced or heard of such problems > with the DCM module and knows of a fix, I'd appreciate a > pointer. Thanks! > > --Randy > > -- > Randy Yates =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0% "So now it's get= ting late, > Digital Signal Labs =A0 =A0 =A0 =A0 =A0 =A0 =A0% =A0 =A0and those who hes= itate > mailto://ya...@ieee.org =A0 =A0 =A0 =A0 =A0% =A0 =A0got no one..."http://= www.digitalsignallabs.com% 'Waterfall', *Face The Music*, ELO While good signal integrity helps, it really has little to do with clock jitter, since the FR4 delay is relatively constant. Spartan 3 DCM's are not particularly jitter tolerant. Also the jitter in the spec is measured inside the FPGA after possible insertion of additional jitter due to ground bounce and power-supply noise. At least make sure that there are no cross-talk issues on the board and that the PLL supplies (Vccaux?) are clean. It helps to avoid outputs with strong drive on IOB's near the clock input. These will inject noise into the receiver on the clock pin, and that noise increases the jitter more when the clock rise and fall rates are slower. What is your clock source? Is it just an oscillator or does it come from off-board? If you're using an oscillator you should also make sure it's Vcc is clean to avoid power-supply induced jitter. HTH, GaborArticle: 148085
Gabor <gabor@alacron.com> writes: > On Jun 19, 6:00 pm, Randy Yates <ya...@ieee.org> wrote: >> Hi, >> >> We're using one of the global DCM blocks in a Xilinx Spartan 3E >> to regenerate/deskew an important clock in our application. The >> clock has an input frequency of 31.5 MHz and we're using the 270 >> phase of the X1 output of the block. >> >> However, we've observed that the block seems to be marginally >> stable. At random, the clock output completely dies, usually >> lasting somewhere between approximately 2 to 6 seconds. >> >> We brought out the status signal that indicates "input clock >> is out of jitter tolerance" and observed that it is pulsing >> frequently. Indeed, it is during a group of those pulses that >> the output clock finally dies. >> >> Looking at the input clock with a scope doesn't reveal any >> particular problems. The signal comes from about 2 inches >> across a 4-layer FR4 board, so it isn't perfect (we've >> used a 33-ohm series resistor to "match" impedances), but >> it certainly looks good enough, although I realize that >> statement is somewhat imprecise and subjective. >> >> Anyway, if anyone has experienced or heard of such problems >> with the DCM module and knows of a fix, I'd appreciate a >> pointer. Thanks! >> >> --Randy >> >> -- >> Randy Yates            % "So now it's getting late, >> Digital Signal Labs        %   and those who hesitate >> mailto://ya...@ieee.org      %   got no one..."http://www.digitalsignallabs.com% 'Waterfall', *Face The Music*, ELO > > While good signal integrity helps, it really has little to > do with clock jitter, since the FR4 delay is relatively > constant. Spartan 3 DCM's are not particularly jitter > tolerant. Also the jitter in the spec is measured inside > the FPGA after possible insertion of additional jitter > due to ground bounce and power-supply noise. At least > make sure that there are no cross-talk issues on the > board and that the PLL supplies (Vccaux?) are clean. > It helps to avoid outputs with strong drive on IOB's > near the clock input. These will inject noise into the > receiver on the clock pin, and that noise increases > the jitter more when the clock rise and fall rates > are slower. Hi Gabor, Thanks - good points to check. > What is your clock source? I'm not sure (don't have the schematic here) but I think it's a TI CDC924. > Is it just an oscillator or > does it come from off-board? On-board. > If you're using an > oscillator you should also make sure it's Vcc is > clean to avoid power-supply induced jitter. That occurred to me but I haven't yet looked. > HTH, > Gabor Thanks for the tips, Gabor. -- Randy Yates % "Rollin' and riding and slippin' and Digital Signal Labs % sliding, it's magic." mailto://yates@ieee.org % http://www.digitalsignallabs.com % 'Living' Thing', *A New World Record*, ELOArticle: 148086
>Hello. > >I am working at an SoC startup developing EDA software for FPGA-like >structures. Currently we have a half-finished software covering from >technology mapping to placement and routing for FPGA. I am looking for >opportunities to put the software into practice. > >Originally the software was expected to evaluate FPGA structures >(known or unknown) for various application domains. So it is not >designated to any specific logic cell or interconnect. Instead, given >structure descriptions, this software can perform technology mapping, >packing, placement and routing on a wide variety of >structures. Actually, there does exist limitations like entities in >logic cell must be organized in tree structure, interconnection must >build on switches and the overall structure must be repetitive. Even >though, the software is flexible enough to be customized to different >FPGA structures. > >The frustration I am facing to is that there is few chance to practice >since the top priority task for a startup is to make money and >survive. So after talking with my boss, now I am seeking opportunities >outside. > >Main features of the software: > > 1. Flexible logic cell structure. We have developed algorithm > performing technology mapping and packing in the same time. The > logic cell don't need to be look-up table only. You can add in other > special purpose entities like mux. The software can automatically > map and pack netlist into expected logic cells given a proper > specification. > > 2. Flexible interconnection. Similiar to VPR, the placement and > routing algorithms work on abstract interconnection model. > > 3. Heterogeneous placement. What VPR cannot do is placement for > blocks of different size, which is an unavoidable case for > real-world FPGA designs. For example, adders are usually synthesized > to a bank of logic cells which requires to be placed along dedicated > carry chains. Our algorithm deals with such cases by a > partition-and-place approach. > > 4. Unified design representation. All algorithms read design from > and store to the same database. So there is no need for data > transformation as using discrete tools like ABCmap and VPR. > > 5. Complete Pythonization (ongoing). The database and core > algorithms are written in C++. But we are porting the database to > Python so that one can operate on designs directly from Python. The > core algorithms will also be exposed to Python. By enjoying the > elegancy and extensibility of Python, design flows are built up > quite easily. > >Then I have to mention some shortages of the software. > > 1. No GUI/IDE. We are used to scripting and is unfamiliar with > GUI development. But I think with Python it is easy to design > cross-platform GUI and IDE. > > 2. No RTL design entry. Currently we are using icarus to parse RTL > Verilog to gate level. We are thinking of build an RTL HDL parser > but haven't have time to kick it off. > > 3. No synthesis optimization. Since we haven't reach RTL level, > there is no synthesis and logic optimization algorithms yet. > > 4. Not timing-driven. Existing algorithms are bound to resource > constraints. We haven't put timing constraints into consideration > yet. > >I am wondering whether there is any FPGA startup or other design house >that works on embedded reconfigurable fabric will need such kind of >software. If not any, it will be locked up in the basement until 2012 >or someday due to the company strategy. As a main developer, I will be >very sad if so. That is why I post here. I am looking for an >opportunity to practice and to push forward the software. > >Personally I think open-source is one of the possible way out and it >is the most interesting way. It will be cool if we can build up an >open source design automation flow to lower the software barrel for >FPGA/reconfigurable market. But there is a long way to go. Besides, >since the software is still my company's proprietary, though the >company is open to open source, I have to find a profitable reason for >open-source. > >Should you have any suggestions, advices, critism or willings, please >fill free to let me know. I will appreciate very much for your feed >back. And thank you for reading this far. > >Yujie Wen > >Celestial Semiconductor. >Shanghai Office. >yujie.wen REPLACE_WITH_AT celestialsemi.cn > > > > > > >--------------------------------------- >Posted through http://www.FPGARelated.com > For your HDL entry and parsing - why don't you use MyHDL ? It is a python module so would gel with your pythonization idea. It also has a built in verilod/vhdl code generator. Personally I would love to contribute to an open source fpga development tool. So if it is going to be locked up, its better to release it as open source; the making money part can come later when the software picks up. --------------------------------------- Posted through http://www.FPGARelated.comArticle: 148087
Hi everyone, The latest version of GTKWave (3.3.7) windows binary is available here: http://www.dspia.com/gtkwave.html You need to grab TCL-TK libraries in addition to the GTK libraries in two separate archives if you don't have them. If you have previously installed 3.3.0, only the exe file is necessary. -- Muzaffer Kal DSPIA INC. ASIC/FPGA Design Services http://www.dspia.comArticle: 148088
>>Hello. >> >>I am working at an SoC startup developing EDA software for FPGA-like >>structures. Currently we have a half-finished software covering from >>technology mapping to placement and routing for FPGA. I am looking for >>opportunities to put the software into practice. >> >>Originally the software was expected to evaluate FPGA structures >>(known or unknown) for various application domains. So it is not >>designated to any specific logic cell or interconnect. Instead, given >>structure descriptions, this software can perform technology mapping, >>packing, placement and routing on a wide variety of >>structures. Actually, there does exist limitations like entities in >>logic cell must be organized in tree structure, interconnection must >>build on switches and the overall structure must be repetitive. Even >>though, the software is flexible enough to be customized to different >>FPGA structures. >> >>The frustration I am facing to is that there is few chance to practice >>since the top priority task for a startup is to make money and >>survive. So after talking with my boss, now I am seeking opportunities >>outside. >> >>Main features of the software: >> >> 1. Flexible logic cell structure. We have developed algorithm >> performing technology mapping and packing in the same time. The >> logic cell don't need to be look-up table only. You can add in other >> special purpose entities like mux. The software can automatically >> map and pack netlist into expected logic cells given a proper >> specification. >> >> 2. Flexible interconnection. Similiar to VPR, the placement and >> routing algorithms work on abstract interconnection model. >> >> 3. Heterogeneous placement. What VPR cannot do is placement for >> blocks of different size, which is an unavoidable case for >> real-world FPGA designs. For example, adders are usually synthesized >> to a bank of logic cells which requires to be placed along dedicated >> carry chains. Our algorithm deals with such cases by a >> partition-and-place approach. >> >> 4. Unified design representation. All algorithms read design from >> and store to the same database. So there is no need for data >> transformation as using discrete tools like ABCmap and VPR. >> >> 5. Complete Pythonization (ongoing). The database and core >> algorithms are written in C++. But we are porting the database to >> Python so that one can operate on designs directly from Python. The >> core algorithms will also be exposed to Python. By enjoying the >> elegancy and extensibility of Python, design flows are built up >> quite easily. >> >>Then I have to mention some shortages of the software. >> >> 1. No GUI/IDE. We are used to scripting and is unfamiliar with >> GUI development. But I think with Python it is easy to design >> cross-platform GUI and IDE. >> >> 2. No RTL design entry. Currently we are using icarus to parse RTL >> Verilog to gate level. We are thinking of build an RTL HDL parser >> but haven't have time to kick it off. >> >> 3. No synthesis optimization. Since we haven't reach RTL level, >> there is no synthesis and logic optimization algorithms yet. >> >> 4. Not timing-driven. Existing algorithms are bound to resource >> constraints. We haven't put timing constraints into consideration >> yet. >> >>I am wondering whether there is any FPGA startup or other design house >>that works on embedded reconfigurable fabric will need such kind of >>software. If not any, it will be locked up in the basement until 2012 >>or someday due to the company strategy. As a main developer, I will be >>very sad if so. That is why I post here. I am looking for an >>opportunity to practice and to push forward the software. >> >>Personally I think open-source is one of the possible way out and it >>is the most interesting way. It will be cool if we can build up an >>open source design automation flow to lower the software barrel for >>FPGA/reconfigurable market. But there is a long way to go. Besides, >>since the software is still my company's proprietary, though the >>company is open to open source, I have to find a profitable reason for >>open-source. >> >>Should you have any suggestions, advices, critism or willings, please >>fill free to let me know. I will appreciate very much for your feed >>back. And thank you for reading this far. >> >>Yujie Wen >> >>Celestial Semiconductor. >>Shanghai Office. >>yujie.wen REPLACE_WITH_AT celestialsemi.cn >> >> >> >> >> >> >>--------------------------------------- >>Posted through http://www.FPGARelated.com >> > >For your HDL entry and parsing - why don't you use MyHDL ? It is a python >module so would gel with your pythonization idea. It also has a built in >verilod/vhdl code generator. We can't force designers give up Verilog or VHDL and rewrite their design in MyHDL. I am afraid the software will never be popular without support to popular HDL entries. But MyHDL is a great plus. And I will work out a MyHDL entry later because, as you said, Python is the easy-to-go bridge between the two. > >Personally I would love to contribute to an open source fpga development >tool. So if it is going to be locked up, its better to release it as open >source; the making money part can come later when the software picks up. That's great! Let me first find a win-win solution towards open-source. :) > > >--------------------------------------- >Posted through http://www.FPGARelated.com > Yujie --------------------------------------- Posted through http://www.FPGARelated.comArticle: 148089
On Sat, 19 Jun 2010 19:58:56 -0400, Randy Yates <yates@ieee.org> wrote: >Gabor <gabor@alacron.com> writes: > >> On Jun 19, 6:00 pm, Randy Yates <ya...@ieee.org> wrote: >>> >>> Anyway, if anyone has experienced or heard of such problems >>> with the DCM module and knows of a fix, I'd appreciate a >>> pointer. Thanks! > >> What is your clock source? > >I'm not sure (don't have the schematic here) but I think it's >a TI CDC924. Deriving its own clock from a 14.318MHz crystal, or a reference oscillator? A quick look at the CDC924 datasheet suggests one thing... check you have spread-spectrum turned off! - BrianArticle: 148090
On Jun 20, 6:30=A0am, Brian Drummond <brian_drumm...@btconnect.com> wrote: > On Sat, 19 Jun 2010 19:58:56 -0400, Randy Yates <ya...@ieee.org> wrote: > >Gabor <ga...@alacron.com> writes: > > >> On Jun 19, 6:00 pm, Randy Yates <ya...@ieee.org> wrote: > > >>> Anyway, if anyone has experienced or heard of such problems > >>> with the DCM module and knows of a fix, I'd appreciate a > >>> pointer. Thanks! > > >> What is your clock source? > > >I'm not sure (don't have the schematic here) but I think it's > >a TI CDC924. > > Deriving its own clock from a 14.318MHz crystal, or a reference oscillato= r? > > A quick look at the CDC924 datasheet suggests one thing... > check you have spread-spectrum turned off! > > - Brian One more thing, the max jitter specs are all at least 300 ps, and if I'm not mistaken this exceeds the jitter tolerance of the Spartan 3E. There is no mention of whether the cycle-to-cycle jitter depends on the spread-spectrum feature, but I would have thought that if it did they would spec the presumably lower number for non spread-spectrum jitter. I have used similar chips from Cypress (CY22392) and found that even without spread-spectrum induced jitter they are only marginal for use with the Xilinx DCM's. Newer Xilinx parts have PLL's that can handle 1 ns peak-to-peak jitter, but with Spartan 3E you might need to clean up your clock externally or use another part to do the required frequency geenration. Regards, GaborArticle: 148091
On 20 Jun 2010 08:29:57 -0700, Winfield Hill <Winfield_member@newsguy.com> wrote: >John Larkin wrote... >> >> On a current design, I had to make my own. I wanted lots of >> overvoltage protection, logic-switchable gains from 0.05 to 256, high >> precision, and at least +-12 volts of common-mode range, 120 dB CMRR >> at high gain. I wound up with a classic 3-opamp diffamp, using an >> LT1124 dual opamp, four Supertex depletion mode fets for protection, a >> discrete string of thinfilm resistors, one DPDT gain switch relay, two >> analog muxes, and an INA154 as the second stage. Two tiny trimpots >> tweak cmrr. Times 16 on one board. I'd love to get all that in a SO-8! > > Indeed. > > What was its CMRR at 1 and 10kHz, that's a tough region. I'm after common-mode rejection for reasonable ground loops (DC, 60 Hz, mild harmonics) and volts of DC from load cell bridges. We tune the CMRR with a 10 volt p-p, 100 Hz square wave applied to both inputs, and the residual, as you turn the tweak pots, looks pretty square. We are currently applying the square wave and looking at the IA output with the gain set to max, using signal averaging on a scope at 2 mv/div, which is 8 uv/div relative to the input. Seems to work. I want to do it all in software, with a lockin-type thing, based on reading our ADC and synchronously detecting it against the cm square wave; if we sell enough of these, it might be worth writing that code. Here it is: http://www.highlandtechnology.com/DSS/V490DS.html The analog stuff pretty much just worked. The big problems were 1. The AD7699 ADC data sheet is, to be polite, terse. The differential inputs are unusual. It is just barely possible, or maybe according to the specs impossible, to actually run it at 500 KHz. A timing diagram might be helpful. 2. I rashly promised 8-pole digital filtering down to 1 Hz, Bessel and Butterworth. That turns out to be non-trivial when you get to 500,000:1 sample/cutoff ratio. Three architectures later, one consultant hired/paid/dumped, great amounts of experiment and simulation and debate, it seems to work. That adventure deserves a thread of its own. One hint: the classic DSP butterfly filter explodes at ratios like this. 3. The lead customer liked the filtering concept so much he asked for two independent filters per channel, one for the realtime data and another for the FIFOs. That's 32 filters and 16 4Kx16 FIFOs and lots of other junk in a Spartan6/45. 4. The Xilinx software is a train wreck, which greatly complicated 2) and 3). Rev 12, supposedly the one that supports Spartan6 properly, is worse than 11. You say "place that flipflop in an i/o block" and it says, after considering the request for five or six hours, "drop dead." We may start using Altera for new designs. I'm tweaking the rev C board layout and finishing up the firmware this weekend. I get interrupted too much at work to let me concentrate on stuff like this. I can't multitask and get serious work done. This is Fathers Day and it's been Meat Weekend. Rubbed Tri-tip last night, BBQ ribs tonight. Nothing green in sight. JohnArticle: 148092
Gabor <gabor@alacron.com> writes: > On Jun 20, 6:30Â am, Brian Drummond <brian_drumm...@btconnect.com> > wrote: >> On Sat, 19 Jun 2010 19:58:56 -0400, Randy Yates <ya...@ieee.org> wrote: >> >Gabor <ga...@alacron.com> writes: >> >> >> On Jun 19, 6:00 pm, Randy Yates <ya...@ieee.org> wrote: >> >> >>> Anyway, if anyone has experienced or heard of such problems >> >>> with the DCM module and knows of a fix, I'd appreciate a >> >>> pointer. Thanks! >> >> >> What is your clock source? >> >> >I'm not sure (don't have the schematic here) but I think it's >> >a TI CDC924. Correction: It's a CDCE706. >> Deriving its own clock from a 14.318MHz crystal, or a reference oscillator? >> >> A quick look at the CDC924 datasheet suggests one thing... >> check you have spread-spectrum turned off! >> >> - Brian > > One more thing, the max jitter specs are all at least 300 ps, > and if I'm not mistaken this exceeds the jitter tolerance of > the Spartan 3E. There is no mention of whether the cycle-to-cycle > jitter depends on the spread-spectrum feature, but I would have > thought that if it did they would spec the presumably lower > number for non spread-spectrum jitter. > > I have used similar chips from Cypress (CY22392) and found that > even without spread-spectrum induced jitter they are only > marginal for use with the Xilinx DCM's. Newer Xilinx parts > have PLL's that can handle 1 ns peak-to-peak jitter, but with > Spartan 3E you might need to clean up your clock externally > or use another part to do the required frequency geenration. Thanks for the tips - but does any of this still go for the CDCE706? -- Randy Yates % "Bird, on the wing, Digital Signal Labs % goes floating by mailto://yates@ieee.org % but there's a teardrop in his eye..." http://www.digitalsignallabs.com % 'One Summer Dream', *Face The Music*, ELOArticle: 148093
Randy Yates <yates@ieee.org> writes: > Correction: It's a CDCE706. Also we have initialized it like this: 1. All clock slew rate controls are set to max (11b). 2. Byte 25, SSC modulation selection, is not transmitted, thus the spread spectrum control should be at its default, which is off. --RY > >>> Deriving its own clock from a 14.318MHz crystal, or a reference oscillator? >>> >>> A quick look at the CDC924 datasheet suggests one thing... >>> check you have spread-spectrum turned off! >>> >>> - Brian >> >> One more thing, the max jitter specs are all at least 300 ps, >> and if I'm not mistaken this exceeds the jitter tolerance of >> the Spartan 3E. There is no mention of whether the cycle-to-cycle >> jitter depends on the spread-spectrum feature, but I would have >> thought that if it did they would spec the presumably lower >> number for non spread-spectrum jitter. >> >> I have used similar chips from Cypress (CY22392) and found that >> even without spread-spectrum induced jitter they are only >> marginal for use with the Xilinx DCM's. Newer Xilinx parts >> have PLL's that can handle 1 ns peak-to-peak jitter, but with >> Spartan 3E you might need to clean up your clock externally >> or use another part to do the required frequency geenration. > > Thanks for the tips - but does any of this still go for the CDCE706? -- Randy Yates % "My Shangri-la has gone away, fading like Digital Signal Labs % the Beatles on 'Hey Jude'" mailto://yates@ieee.org % http://www.digitalsignallabs.com % 'Shangri-La', *A New World Record*, ELOArticle: 148094
On Jun 21, 2:22=A0am, Randy Yates <ya...@ieee.org> wrote: > Gabor <ga...@alacron.com> writes: > > On Jun 20, 6:30=A0am, Brian Drummond <brian_drumm...@btconnect.com> > > wrote: > >> On Sat, 19 Jun 2010 19:58:56 -0400, Randy Yates <ya...@ieee.org> wrote= : > >> >Gabor <ga...@alacron.com> writes: > > >> >> On Jun 19, 6:00 pm, Randy Yates <ya...@ieee.org> wrote: > > >> >>> Anyway, if anyone has experienced or heard of such problems > >> >>> with the DCM module and knows of a fix, I'd appreciate a > >> >>> pointer. Thanks! > > >> >> What is your clock source? > > >> >I'm not sure (don't have the schematic here) but I think it's > >> >a TI CDC924. > > Correction: It's a CDCE706. > > > > >> Deriving its own clock from a 14.318MHz crystal, or a reference oscill= ator? > > >> A quick look at the CDC924 datasheet suggests one thing... > >> check you have spread-spectrum turned off! > > >> - Brian > > > One more thing, the max jitter specs are all at least 300 ps, > > and if I'm not mistaken this exceeds the jitter tolerance of > > the Spartan 3E. =A0There is no mention of whether the cycle-to-cycle > > jitter depends on the spread-spectrum feature, but I would have > > thought that if it did they would spec the presumably lower > > number for non spread-spectrum jitter. > > > I have used similar chips from Cypress (CY22392) and found that > > even without spread-spectrum induced jitter they are only > > marginal for use with the Xilinx DCM's. =A0Newer Xilinx parts > > have PLL's that can handle 1 ns peak-to-peak jitter, but with > > Spartan 3E you might need to clean up your clock externally > > or use another part to do the required frequency geenration. > > Thanks for the tips - but does any of this still go for the CDCE706? > -- > Randy Yates =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0% "Bird, on the wi= ng, > Digital Signal Labs =A0 =A0 =A0 =A0 =A0 =A0 =A0% =A0 goes floating by > mailto://ya...@ieee.org =A0 =A0 =A0 =A0 =A0% =A0 but there's a teardrop i= n his eye..."http://www.digitalsignallabs.com% 'One Summer Dream', *Face Th= e Music*, ELO The jitter looks a lot better on the CDCE706. Still at the low end of the VCO frequency range it's perhaps marginal for the Spartan 3E. Look at your VCO and divider settings. The data sheet seems to imply that setting the VCO to a higher frequency will reduce the cycle-to-cycle jitter. So if you are generating 63 MHz and dividing by 2, you might want to instead generate 126 MHz and divide by 4. Regards, GaborArticle: 148095
Gabor <gabor@alacron.com> writes: > [...] > The jitter looks a lot better on the CDCE706. Still at the low > end of the VCO frequency range it's perhaps marginal for the > Spartan 3E. Look at your VCO and divider settings. The data > sheet seems to imply that setting the VCO to a higher frequency > will reduce the cycle-to-cycle jitter. So if you are > generating 63 MHz and dividing by 2, you might want to > instead generate 126 MHz and divide by 4. Thanks Gabor! -- Randy Yates % "Watching all the days go by... Digital Signal Labs % Who are you and who am I?" mailto://yates@ieee.org % 'Mission (A World Record)', http://www.digitalsignallabs.com % *A New World Record*, ELOArticle: 148096
the X-7 roadmap and all device table are no online, and the ARM11 is coming is also all public knowledge, but.. where? in what family? spartan is dead, now is Artix, und Kintex? but where is ARM11? in BULLSHITIX-8 release? I wonder. of course its very interesting to see how much mess Xilinx is able to organize with the 7 series, right now Xilinx online shop list exactly 2 devices of Spartan-6ES both going to avnet no stock there was initial stock of 45 pieces of Spartan-6 at digikey after that was depleted digikey has not received any new s-6 silicon. so, when comes spartan-6 general availability? does it makes to wait? or maybe it makes more sense to wait the Artix-7? or maybe..look for alternatives? AnttiArticle: 148097
On 6/21/2010 11:27 AM, Antti wrote: > the X-7 roadmap and all device table are no online, > and the ARM11 is coming is also all public knowledge, but.. where? in > what family? > > spartan is dead, now is Artix, und Kintex? but where is ARM11? > > in BULLSHITIX-8 release? > > I wonder. of course its very interesting to see how much mess Xilinx > is able > to organize with the 7 series, right now Xilinx online shop list > exactly 2 devices of Spartan-6ES both going to avnet no stock > there was initial stock of 45 pieces of Spartan-6 at digikey > after that was depleted digikey has not received any new s-6 silicon. > > so, when comes spartan-6 general availability? > does it makes to wait? > or maybe it makes more sense to wait the Artix-7? > or maybe..look for alternatives? > > > Antti Right now I'm working on two S6 projects, both of which are absolute disasters due to problems with the toolchain. My DRAM problem from a month ago, Xilinx ultimately told me was my problem and they washed their hands of it. Now on my other project, version 12 of the tools uses 10% more of the chip than version 11 and neither is willing to respect a simple IOB=FORCE. I've got a WebCase crawling along on it, but so far have been trained to not expect much from that process. I'm finding my choice of Xilinx FPGAs to be the single largest impediment to my actually getting product out the door. Spartan 6 has been a trainwreck, and the decision to pull back from NuHo to only AvNet has meant that I don't even have any support through my distribution chain anymore. And now they're touting 7 series silicon and expecting us to be excited? Antti, of your choices I know which one I'm taking. My Arrow sales rep, who has always been responsive and supported me to the hilt, has been asking me for the longest time to have a serious sit down with her Altera FAEs to talk about moving all of Highland's future designs over, company wide. We're having it Friday. -- Rob Gaddi, Highland Technology Email address is currently out of orderArticle: 148098
On 20 Jun., 19:14, John Larkin <jjlar...@highNOTlandTHIStechnologyPART.com> wrote: snip > > 2. I rashly promised 8-pole digital filtering down to 1 Hz, Bessel and > Butterworth. That turns out to be non-trivial when you get to > 500,000:1 sample/cutoff ratio. Three architectures later, one > consultant hired/paid/dumped, great amounts of experiment and > simulation and debate, it seems to work. That adventure deserves a > thread of its own. One hint: the classic DSP butterfly filter explodes > at ratios like this. That is DSP 101 and kinda obvious when you think about it, for a filter to have any effect at 1Hz it needs to have "memory" it that range. with a 500kHz samplerate that either means a very high order or a very high precision standard approach would be decimate the signal to a more resonable sample rate -LasseArticle: 148099
On Mon, 21 Jun 2010 11:53:34 -0700 (PDT), "langwadt@fonz.dk" <langwadt@fonz.dk> wrote: >On 20 Jun., 19:14, John Larkin ><jjlar...@highNOTlandTHIStechnologyPART.com> wrote: >snip >> >> 2. I rashly promised 8-pole digital filtering down to 1 Hz, Bessel and >> Butterworth. That turns out to be non-trivial when you get to >> 500,000:1 sample/cutoff ratio. Three architectures later, one >> consultant hired/paid/dumped, great amounts of experiment and >> simulation and debate, it seems to work. That adventure deserves a >> thread of its own. One hint: the classic DSP butterfly filter explodes >> at ratios like this. > >That is DSP 101 and kinda obvious when you think about it, for a >filter >to have any effect at 1Hz it needs to have "memory" it that range. >with a 500kHz samplerate that either means a very high order or a very >high >precision You'd think that 16 bit data and 1e6:1 sample/cutoff ratio could be accomplished with roughly 36 bit math. > >standard approach would be decimate the signal to a more resonable >sample rate That's one approach: build a chain of filters, clocked at declining rates, and use the early ones to take the stress off the later ones. Switch filters in or out as needed. We could do that, but it's harder to explain to the customers. It's easier to model the product as a lowpass filter followed by a 500 KHz ADC. The classic butterfly explodes violently as the clock:cutoff ratio goes up. Numbers have to subtract to make tiny residuals, and stage gains get absurd. Instead we used a double-integrator filter, essentially a digital simulation of an analog state-variable filter. That gets into trouble much more linearly than the butterfly, and each 2nd order section has a gain of exactly 1. It works using MAC blocks using 18x18 multiplies and a sort of coarse barrel shifter into a 48 bit accumulator. John
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