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
Hello again, CLK = 280MHz A state machine clocked by CLK and enabled by NSI generates a CLKEN signal that enables "other" logic clocked by CLK. CLK and NSI are on the entity, CLKEN is internal. The "other" logic contains long carry chains that will run at 140MHz (just). The FSM should be able to run at ~280MHz on a virtex-ii -5. I am assuming NSI always = 1 for the time being. How do I describe this situation to Xilinx ISE 5.2.03i in ucf constraints please? I tried this: NET "CLK*" TNM_NET = "CLK"; NET "CLKEN" TNM_NET = "CLKEN"; NET "NSI*" TNM_NET = "NSI"; TIMESPEC "TS_CLK" = PERIOD "CLK" 3.57 ns HIGH 50 %; TIMESPEC "TS_CLK_NSI" = FROM "CLK" TO "NSI" "TS_CLK" * 1; TIMESPEC "TS_CLK_CLKEN" = FROM "CLK" TO "CLKEN" "TS_CLK" * 2; but ISE tries to constrain the "other" logic with the carry chains to the 280MHz clock instead of the 140MHz CLKEN domain - and timing fails. Also tried various other combinations some of which are listed at the end with no success. Am I on the right lines here or am I missing something obvious? Surely I can tell ISE about this situation...? Also, is there any way to use say "CLKEN*" when specifying the grouping for CLKEN - do I need to dig in to the hierarchy somehow? Tried the Xilinx manuals but couldn't find something that relates to this scenario without specifying every signal manully - I need to group by enable/clk signal! Thanks for your time, Ken #TIMESPEC "TS_CLKEN" = FROM "CLKEN" TO "CLKEN" "TS_CLK" * 2; #TIMESPEC "TS_CLKEN_CLK" = FROM "CLKEN" TO "CLK" "TS_CLK" * 2; #TIMESPEC "TS_NSI" = FROM "NSI" TO "NSI" "TS_CLK" * 2; #TIMESPEC "TS_NSI_CLK" = FROM "NSI" TO "CLK" "TS_CLK" * 2; -- To reply by email, please remove the _MENOWANTSPAM from my email address.Article: 66101
Amontec Team, Laurent Gauch wrote: > Hi, > I need to know where I have to include my .ucf file in XFLOW! As long as it has the same name as the rest of the design XFLOW should find it automatically. E.g., if you have a "top.vhd", or a "top.ngc", then XFLOW should find a "top.ucf" on it's own, if it resides in the current directory. Otherwise you can change it in the *.opt-file for the "implement" stage (fast_runtime.opt, for example, or whatever you use). -- Sean Durkin Fraunhofer Institute for Integrated Circuits (IIS) Am Wolfsmantel 33, 91058 Erlangen, Germany http://www.iis.fraunhofer.de mailto:23@iis.42.de ([23 , 42] <=> [durkinsn , fraunhofer])Article: 66102
If you can sqeak by with 240 pins I've got a custom 4 layer board running Nios with SDRAM and USB 2.0 incredibly stable at 110-120 MHz. Stack is Signal-GND-PWR-Signal. Made 10 with ground pours, 10 without. Both sets function the same. I have not compared the external signals on an analog scope, but the clocks look good, the logic analyzer looks good, and they all work without glitch. If you go to CompUSA and buy a few highspeed PCI cards you'll see they're doing their magic with only 2 layers with ground pours. I was originally told by the board expert the same 8-layer requirement on our design. I talked him down to 6 and then went with 4 based on a lot of reading, looking at examples, and applying common sense. I say listen to experts, but beware the advice of people who make more money if your design is more complex. IMO Ken "Andre" <armcc@lycos.com> wrote in message news:ae5c06e9.0402120029.4ea5405d@posting.google.com... > How many layers are normally needed for PCBs using low cost FPGAs ?? > > I've just been told by a supposed board layout expert that the 256 pin > BGA version of a Cyclone EP1C6 would require an 8 layer board > (apparently having the entire underside of the device covered by balls > with no free space at the centre makes signal routing a big problem). > > Is this really true ??Article: 66103
I found. There are '-uc' parameter for the Amontec Team, Laurent Gauch wrote: > Hi, > > I need to know where I have to include my .ucf file in XFLOW! > > Laurent > > Sean Durkin wrote: > >> Amontec Team, Laurent Gauch wrote: >> >>> Hi all, >>> I am using Webpack ISE to do PAR for Coolrunner. >>> How to get back all command line from VHDL and UCF parser to JEDEC >>> generation (parser, synthesis and par works) >>> The goal is to do a generic project (using webpack IDE interface) and >>> to get back all ISE command line, and to re-run the ISE command line >>> for an other VHDL file with minor changes. All the work would be via >>> script for generating about 50 news configs of our Chameleon POD. >> >> >> Have a look at the chapter about "xflow" in the ISE Documentation. >> That's the command-line-tool to do the complete flow from synthesis to >> bitfile generation (I assume you can generate JEDEC-files as well). >> The options for each of the steps are set in *.opt-files, that reside >> in $XILINX/epld/data. You can copy those and modify the local copies, >> and run "xflow" with these instead of the globally available ones. >> >> "xflow" is really not that complicated, and is great for using inside >> scripts, so that should be what you need. >> > > ------------ And now a word from our sponsor ------------------ > For a quality usenet news server, try DNEWS, easy to install, > fast, efficient and reliable. For home servers or carrier class > installations with millions of users it will allow you to grow! > ---- See http://netwinsite.com/sponsor/sponsor_dnews.htm ---- ------------ And now a word from our sponsor ------------------ For a quality usenet news server, try DNEWS, easy to install, fast, efficient and reliable. For home servers or carrier class installations with millions of users it will allow you to grow! ---- See http://netwinsite.com/sponsor/sponsor_dnews.htm ----Article: 66104
Peter, In article <402BBFA1.49FA2DB5@xilinx.com> > You need to be more specific about granularity, jitter, and your budget. > Here is one extreme: > I am just finishing a project where we combine a small Spartan3 plus an > ICS8735 PLL to generate 1 Hz to 640 MHz with a granularity of 1 Hz (all > the way to 640 MHz ! ) and very low jitter (hopefully below 50 ps). This > uses some unconventional tricks... Any plans to make an application note describing your setup? It sounds like a very cool design. Are you doing something like frequency division in the FPGA with counters and multiplication with the PLL? Perhaps using different clocks & divider combos to cover the range?? Thanks, Jay.Article: 66105
When configuring a virtex fpga with a prom in master serial mode, how is the clock generated by the fpga. I presume I don’t need to input any other clock other than my normal fast clock of 100MHz.Article: 66106
Glen, I have no problem with names, but I have a problem giving one single parameter two different names. There is no inherent difference between set-up and hold, they are just the two extreme ends of the same parameter, the input timing window where D must be held constant, in order to guarantee specified operation and performance. At any one time, voltage, and temperature on a given part, the "two parameters" collapse into a single value. I have measured the actual width of the window (in Virtex-II Pro) as 0.03 femtoseconds. (see TechXclusives on metastability measurement). I am a stickler for clarity and simplicity, but this is a battle lost long time ago... Peter Alfke ========================= glen herrmannsfeldt wrote: > > Peter Alfke wrote: > > > Let me blame T.I. for inventing (in the late 'sixties) the stupid name > > "Hold Time", when we are really talking about the latest possible > > instant of Set-Up Time. > > (snip) > > > The earliest possible position is specified as Set-up-time. The latest > > possible position is (unfortunarely) specified as Positive Hold Time if > > it is later than the clock edge, and as Negative Hold Time if it is > > before the clock edge. > > > It would be so much nicer if we used only one parameter name, and called > > the two extremes the max and the min value of the set-up time. I lost > > that battle 30 years ago. It still smarts every time I hear "Hold Time" > > By having two parameters you can have a typical for both, and also > a max/min (whichever is applicable). > > Now, I suppose the names could be more symmetric. What is the opposite > of setup? Maybe takedown, or something like that? Maybe release is > the opposite of hold. I don't think setup/takedown or release/hold make > very good pairs. It might be that I am too used to setup/hold by now. > > -- glenArticle: 66107
Amontec Team, Laurent Gauch wrote: > Sean Durkin wrote: > >> Amontec Team, Laurent Gauch wrote: >> >>> Hi all, >>> I am using Webpack ISE to do PAR for Coolrunner. >>> How to get back all command line from VHDL and UCF parser to JEDEC >>> generation (parser, synthesis and par works) >>> The goal is to do a generic project (using webpack IDE interface) and >>> to get back all ISE command line, and to re-run the ISE command line >>> for an other VHDL file with minor changes. All the work would be via >>> script for generating about 50 news configs of our Chameleon POD. >> >> >> Have a look at the chapter about "xflow" in the ISE Documentation. >> That's the command-line-tool to do the complete flow from synthesis to >> bitfile generation (I assume you can generate JEDEC-files as well). >> The options for each of the steps are set in *.opt-files, that reside >> in $XILINX/epld/data. You can copy those and modify the local copies, >> and run "xflow" with these instead of the globally available ones. >> >> "xflow" is really not that complicated, and is great for using inside >> scripts, so that should be what you need. >> > Sean, > > I will try the xflow way. > many thanks > Laurent > For verilog and FPGA the log file is <top_level_name>.cmd_log just run the flow once and copy it to a *.bat file from the command line it pretty easy to guess what files you need to look at to set options etc. and they are quite easy to read and modify -LasseArticle: 66108
All are working fine. I am now able to pass from VHDL source files to SVF output files only using script ! We have now a Chameleon POD self programmable from VHDL source. (Just need to intall the Free webpack) :-) A very nice solution. Laurent www.amontec.com Sean Durkin wrote: > Amontec Team, Laurent Gauch wrote: > >> Hi, >> I need to know where I have to include my .ucf file in XFLOW! > > As long as it has the same name as the rest of the design XFLOW should > find it automatically. E.g., if you have a "top.vhd", or a "top.ngc", > then XFLOW should find a "top.ucf" on it's own, if it resides in the > current directory. Otherwise you can change it in the *.opt-file for the > "implement" stage (fast_runtime.opt, for example, or whatever you use). >Article: 66109
You need to be more specific about granularity, jitter, and your budget. Here is one extreme: I am just finishing a project where we combine a small Spartan3 plus an ICS8735 PLL to generate 1 Hz to 640 MHz with a granularity of 1 Hz (all the way to 640 MHz ! ) and very low jitter (hopefully below 50 ps). This uses some unconventional tricks... DDS is the traditional method to achieve finest granularity, but it creates lots of jitter, and is non-trivial at 150 MHz. Peter Alfke =================================== dave wrote: > > Escenario : Need a clock system with range from ~50Mhz to 150Mhz with > as much granularity as possible to drive an FPGA. > > Could anyone please suggest options on how to better implement this > clock system.? I've looked at programmable clocks from Cypress, > Maxim-ic, but these require some I2C or 2-wire interface, and I don't > have a microcontroller on board, just the FPGA so I'd need to put a > I2C core... . I've looked at using the PLL core in the FPGA (Actel in > this case), but I find the documentation about it to be extremely poor > as to how to really implement it. > > By the way, if anybody has had experience using the PLL core in Actel, > could you please give a simple example on how to use the core > generated by "Actgen." I've read the document on "PLL dynamic > reconfiguration using JTAG," and I still don't understand > completely.... > > Thanks in advance, > > DavidArticle: 66110
In master mode the configuration clock is generated by an FPGE-internal RC oscillator. The frequency is not very accurate or stable, but good enough for the purpose. Peter Alfke =============== chuk wrote: > > When configuring a virtex fpga with a prom in master serial mode, how > is the clock generated by the fpga. I presume I don’t need to > input any other clock other than my normal fast clock of 100MHz.Article: 66111
TBGenerator - program for testing and diagnosting HDL designs (Verilog
or VHDL).
This program reads source files (VHDL or Verilog) and automatically
generates test bench file (Verilog or VHDL format) for the selected
module and macro file (Tcl/Tk, Sh) for particular simulator (ModelSim,
Active-HDL/Riviera, NC-sim, VCSi and others). You don't have to waste
your time for writing test benches!
You can define input stimulus for in/inout ports either by the
formula, by the clock pulse, by random variable or you can define an
input file with stimulus data (text file with input vectors and time).
You can change only the stimulus in the input file without changing
the test bench file. The values of all the ports will be written to
the file during the simulation if you chose to do so.
Program has some additional tools:
- generator of components declaration for chosen module;
- frequency to time converter and vice versa;
- input file editor.
User-friendly interface and advanced help.
This program is shareware with a trial period 30 days
Article: 66112Frank, I was not aware that you were using cache with your SDRAM in this system. To debug with cache support, you must use the MDM. Ryan Laity Xilinx Frank van Eijkelenburg wrote: > It looks like there are some troubles with debugging an application in sdram > while caching is enabled (both instruction cache and data cache are > enabled). If I remove the cache, I am able to debug my application from > sdram. Could anyone confirm this (I saw a few postings at the xilinx > microblaze forum, but I couldn't find an confirmation from xilinx about this > behaviour)?! > > Frank > > > "Ryan Laity" <ryan_dot_laity@x-i-l-i-n-x_pleasenospam_dot_com> wrote in > message news:c0dod1$5kk1@cliff.xsj.xilinx.com... > >>Frank, >> >>Yes, you can do exactly what you have described. When you use the "dow" >>command from the XMD command prompt (after an mbconnect), XMD will use >>the available memory interface core to place the .elf at whatever >>location has been specified in your linker script. Therefore, you want >>to "dow" the final application, not the bootloader. You are essentially >>letting MDM/XMD act as your bootloader in this case. >> >>Once the .elf is downloaded, you can then "con" to run or "stp" (step) >>from the command line and see what instruction is causing the problem >>you described in your previous post. If the system hangs on one of your >>first steps then you probably have a problem with your hardware (likely >>logical or timing issue with your memory interface and/or board). If >>this is the case, try using the "mwr" and "mrd" commands from XMD to see >>if you can get data in and out of your memory correctly. >> >>You can also try to "dow" your .elf file, do an object dump (mb-objdump) >>of the .elf, then use "mrd" on a large block of the instruction memory, >>and do a comparison between the dumped .elf and what's in the memory. >>If there are any mismatches then there's likely a problem with the >>memory interface hardware/timing. >> >>If it's many instructions into the run, and that instruction memory >>location looks correct, then the software is likely at fault. Use that >>dumped .elf file to figure out which instruction is causing the problem >>and debug accordingly. >> >>Hopefully you are able to resolve the problem using this information. >>If not then please contact our support hotline for more help. >> >> >>Best regards, >>Ryan Laity >>Xilinx Applications >> >>Frank van Eijkelenburg wrote: >> >>>Hi, >>> >>>Is it possible to debug an application which is in sdram by use of > > xmdstub? > >>>I have a small bootloader program which programs a final application > > into > >>>sdram (by use of xmodem). Now I want to debug this application, is that >>>possible or should I use the opb mdm device?! If it's possible, I guess > > I > >>>have to build a bootloader with the xmdstub and make a connection. But > > how > >>>to get my application into the sdram? Can I use the "dow" command at the > > xmd > >>>command line or an option inside gdb to download the application into > > sdram > >>>(I'm asking this, because in the normal way the user has to give some > > input > >>>via the serial port, but that's the same port for debugging thus I can't >>>give any input). And how to step through the code when the application > > is in > >>>the sdram?! >>> >>>TIA, >>>Frank >>> >>> >> > >Article: 66113
ANDing is fine here, although in a high speed design the and gate may cause you
some heartburn when trying to meet timing. The place and route (PAR) tools
don't do a very good job placing second level combinatorial stuff, particularly
gates with multiple loads like you have with a clock enable. Unless you are
really pushing the clock, it should be fine.
>
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 66114Jay, give me a few weeks to publish. In a nutshell: 10 MHz xtal osc gets multiplied to 80 MHz, drives Direct Digital Synthesis accumulator, a "magic circuit" then multiplies the frequency and reduces the jitter. The Spartan-3 output drives the ICS PLL for further jitter reduction and multiplication by up to 8. Nice GUI and display control by PicoBlaze. Read about it in XCell, and I will also brag about characterization results in this ng, once we are finished. Fun project :-) Peter Alfke ================================ Jay wrote: > > Peter, > > In article <402BBFA1.49FA2DB5@xilinx.com> > > You need to be more specific about granularity, jitter, and your budget. > > Here is one extreme: > > I am just finishing a project where we combine a small Spartan3 plus an > > ICS8735 PLL to generate 1 Hz to 640 MHz with a granularity of 1 Hz (all > > the way to 640 MHz ! ) and very low jitter (hopefully below 50 ps). This > > uses some unconventional tricks... > > Any plans to make an application note describing your setup? It sounds > like a very cool design. > > Are you doing something like frequency division in the FPGA with > counters and multiplication with the PLL? Perhaps using different clocks > & divider combos to cover the range?? > > Thanks, > Jay.Article: 66115
Peter Alfke wrote: > Glen, I have no problem with names, but I have a problem giving one > single parameter two different names. There is no inherent difference > between set-up and hold, they are just the two extreme ends of the same > parameter, the input timing window where D must be held constant, in > order to guarantee specified operation and performance. > At any one time, voltage, and temperature on a given part, the "two > parameters" collapse into a single value. I have measured the actual > width of the window (in Virtex-II Pro) as 0.03 femtoseconds. (see > TechXclusives on metastability measurement). My preference is for the term Time Aperture. That makes it clear it is narrow, and requires either leading and trailing numbers, or a centre point, and a width would also be valid. The concept of Aperture then also naturally leads onto adding Jitter on the clock, or data to any design margins. A centre point and width spec would more naturally align with Jitter values. It also leads to Aperture skew, which is the miss-match in these windows across multiple flip flops in a device. Not good if you are crossing clock domains. These can be much wider than the metastable aperture. Then there is the metastable aperture (modeled) you mention above. I'm not sure I'd agree that the 0.03fs is the actual width of the aperture. The 0.03 is derived by extrapolate from a log eqn fit, and has units of fs. Any attempt to measure the aperture would be swamped in jitter, as best in class jitter is 'some picoseconds', rather than 'sub-picoseconds'. A one volt signal with 1ns risetime, has 1mv/ps, so system noise (gnd/vcc/crosstalk) in the order of 1mv will create in the region of 1ps of jitter. 100ps rise, with 1% system noise also gives 1ps jitter. I can think of a method where you might get close to getting a physical aperture width value, but it would need a test chip, rather than std devices. -jgArticle: 66116
Peter Alfke wrote: > Jay, give me a few weeks to publish. > In a nutshell: 10 MHz xtal osc gets multiplied to 80 MHz, drives Direct > Digital Synthesis accumulator, a "magic circuit" then multiplies the > frequency and reduces the jitter. The Spartan-3 output drives the ICS > PLL for further jitter reduction and multiplication by up to 8. > Nice GUI and display control by PicoBlaze. > Read about it in XCell, and I will also brag about characterization > results in this ng, once we are finished. Fun project :-) Yes, sounds a great 'dynamic range' demonstration. I've changed the topic heading if you want to keep us posted :) Any plans to add a 640MHz reciprocal Frequency counter - or do you have this included already, just to prove the Synth is on the right frequency :) -jgArticle: 66117
Ray Andraka wrote: > The OP did not mention the sample rate relative to clock rate, the phase > relationship of the sine to the sample interval if any, or the required > precision. Without these, it is not possible to offer a 'best' solution. ROM > is fine as long as the number of phase angles supported is small enough to fit > in the address space of the ROM. (big snip) I seem to remember ones that had two ROMs, where the second was a linear interpolation. Adders were then used to combine the results from the ROMs. There may be some FPGA cases where that method could still be used. -- glenArticle: 66118
SneakerNet wrote: > Hi all > > I need some help with regards to generating a sine wave. I thought abt this > problem and some thoughts that came to mind are as follows: > 1. Generate sine values using spreadsheet > 2. Store these values either in ROM or make a table withing VHDL > 3. Write VHDL code and output these values. > > My question is: > Is it better to store these values in ROM (eg. LUT) or directly hardcode the > values. > Is there a website that will explain or give more explanation in this area. > > Cheers > > 1) write a sample counter. when the msb of the counter is '0', take all lsb. when the msb of the counter is '1', invert all lsb. The result is a triangular wawe. 2) Cut the top and bottom of your triangular wawe using comparators 3) used a filter to remove harmonics Laurent Gauch www.amontec.comArticle: 66119
Hello, > I figured that either BIOS or Windows configures the PCI board > at bootup, and assigns the BAR0 etc. I am using an FPGA with the > Xilinx PCI32 LogiCore. Hence, the Command and Status Register bit 2 > is '0' at startup. How can I set it to '1' after startup? This is the responsibility of the device driver for your device. If you don't have one, you will need to write one. You can get the Windows 2000 DDK from Microsoft for examples of how to do it. Alternately you can purchase a device driver development kit. I can think of at least three vendors of such kits. Basically, when your driver loads, it needs to locate the hardware and then read what's in the BARs to know what addresses it should use to access the hardware. Also, at that time, you would want to clear all the bits in the status regisiter, and then set whatever bits you want in the command register. After that, your hardware is ready to go... > For those of you familiar with the Xilinx PCI32 LogiCore, I've > thought about hard setting the CFG_SELF bit to '1', which will > fool the core to initiate master transactions. But in simulation, > I see that the ADIO bus does not get the date from the AD bus! Don't do that; this signal is intended to be used only to enable the core to perform CONFIG reads and writes to its own SELF. And you would only want to do that if you were in some kind of an embedded system with no host. > A more tedious way is to self configure the PCI core to master, > but I am seeking an easier way. You still shouldn't do that, unless you are in an embedded system with no host (or you are the host) but that isn't the case if you are in a Windows 2000 system. I'm not a device driver writer (or even a programmer) and I was able to leverage stuff in the DDK and a commercial device driver development kit to get a driver working in Windows 2000. I took one of the examples that was closest to what I wanted to do and then modified it. EricArticle: 66120
Andras, Couldnt a simple RS-232 to USB chip (ex. www.ftdichip.com/FT2232C.htm ) be used instead of the Cypress SL811HS? Then go wireless from there like you mentioned. Most PICs, AVR, etc have the RS232 built in, and you dont need an external bus or any additional I/Os. Im not sure about the "host" thing. Ben > The reason I went for fpga was to have wireless networking (802.11) > Actually, the sensors are 3-4 miles apart, I need the data until a > base station from where I will transfer the data to the internet. > the base station is located in the filed and will be 1-2 miles distant > from each sensor. So how do I transfer (in realtime) the data until the > base station from the sensor. Is it possible with PCI micro. > Please suggest me if there is a better solution other than fpga cpu > for doing this (wireless networking). Doing wireless with FPGA is not easier (nor harder) than with CPUs or MCUs. You probably will end up using some kind of off-the-selves wireless card and connect it to your custom application. Of what I understand of your application probably a wireless USB card would be the best for your application. Processing power is not an issue in your case. In that case you need to choose (or implement) a USB host controller but for control even an 8-bit CPU (PIC or AVR or whatever) should be adequate. I don't know of any 8-bit micro that has an USB host (not function!) controller, but there's a USB interface IC from Cypress, the SL811HS, that can be used as both a host and a slave controller. So, my suggestion would be: - Use an 8-bit microcontroller with an external bus (68HC11 from Motorola) or one with enough of I/O pins (ATmega from Atmel) and probably a with built-in A/D for the pressure sensors. - Use the SL811HS from Cypress to implement the USB host controller - Stick a wireless USB adapter to the unit to implement wireless - For 1-2 miles you probably need high-gain, directed antennas so choose an adapter that has external antenna connectivity. Regards, Andras TantosArticle: 66121
Jim, I agree 100% with your posting. Aperture would be a very good name. But it looks like we are 40 years too late. It might be politicaly incorrect to say nasty things about Texans... Cheers Peter ========== Jim Granville wrote: > > Peter Alfke wrote: > > Glen, I have no problem with names, but I have a problem giving one > > single parameter two different names. There is no inherent difference > > between set-up and hold, they are just the two extreme ends of the same > > parameter, the input timing window where D must be held constant, in > > order to guarantee specified operation and performance. > > At any one time, voltage, and temperature on a given part, the "two > > parameters" collapse into a single value. I have measured the actual > > width of the window (in Virtex-II Pro) as 0.03 femtoseconds. (see > > TechXclusives on metastability measurement). > > My preference is for the term Time Aperture. That makes it clear it > is narrow, and requires either leading and trailing numbers, or > a centre point, and a width would also be valid. > The concept of Aperture then also naturally leads onto adding Jitter > on the clock, or data to any design margins. > A centre point and width spec would more naturally align > with Jitter values. > > It also leads to Aperture skew, which is the miss-match in these > windows across multiple flip flops in a device. Not good if you > are crossing clock domains. > These can be much wider than the metastable aperture. > > Then there is the metastable aperture (modeled) you mention above. > > I'm not sure I'd agree that the 0.03fs is the actual width of the > aperture. The 0.03 is derived by extrapolate from a log eqn fit, > and has units of fs. > > Any attempt to measure the aperture would be swamped in jitter, > as best in class jitter is 'some picoseconds', rather than > 'sub-picoseconds'. > A one volt signal with 1ns risetime, has 1mv/ps, so system > noise (gnd/vcc/crosstalk) in the order of 1mv will create in > the region of 1ps of jitter. 100ps rise, with 1% system noise > also gives 1ps jitter. > > I can think of a method where you might get close to getting a > physical aperture width value, but it would need a test chip, rather > than std devices. > > -jgArticle: 66122
Frequency counter is the next project. Since we have case, power supply, display and all the mechanical trivia established, it is easy to build a separate frequency counter, 1 Hz to 1.5 GHz with 9 digits of display. Time base oscillator promises < 3 ppm (Maxim). The "reciprocal" concept made it into a Xilinx "UltraController" presentation and demo. I will use the MultiGigabit Transceiver for the input. 3 Gbps = 1.5 MHz. I could use the newest Virtex-II ProX which is 3 times faster, but I do not see so much demand for a 5 GHz input resolution (LVDS). Gettinga bit esoteric, but the chip can do it... Keep you posted. Peter Alfke ========================== Jim Granville wrote: > > > Yes, sounds a great 'dynamic range' demonstration. > I've changed the topic heading if you want to keep us posted :) > > Any plans to add a 640MHz reciprocal Frequency counter - or > do you have this included already, just to prove the Synth is > on the right frequency :) > > -jgArticle: 66123
Peter Alfke wrote: > Frequency counter is the next project. Since we have case, power supply, > display and all the mechanical trivia established, it is easy to build a > separate frequency counter, 1 Hz to 1.5 GHz with 9 digits of display. > Time base oscillator promises < 3 ppm (Maxim). > The "reciprocal" concept made it into a Xilinx "UltraController" > presentation and demo. > I will use the MultiGigabit Transceiver for the input. 3 Gbps = 1.5 MHz. > I could use the newest Virtex-II ProX which is 3 times faster, but I do > not see so much demand for a 5 GHz input resolution (LVDS). Gettinga > bit esoteric, but the chip can do it... > Keep you posted. Thanks, Will this fit into your 'small spartan 3', alongside the Synth ? Can you feed the 1.5GHz into a flip flop / ring counter reliably ? What about Fmax of a variable modulus divider 1st stage ? (was it the 11C90 (?) from fairchild ?) -jgArticle: 66124
tal_h@elbit.co.il (tal_h) wrote in message news:<7fc7c85.0402110004.797bdc7f@posting.google.com>... > Hi, > I have a problem in configurating altera devices in my board. > my configuration scheme is as follows: > 1 EPC16 device connected in PPS mode to: > A stratix device connected to Data0 (EP1S20) & 2 cyclone devices > (EP1C12) connected to Data1 & Data2 of the EPC16… > When I power-up the board => the Configuration isn't done. > I've looked on the nSTATUS & CONF_DONE signals and they look fine! > the CONF_DONE stays LOW all the time. the nSTATUS goes HIGH ~85mSec > after power is stable. > the DCLK signals stays LOW all the time! (there isn't DCLK) > I've tried an external OSC to the EPC16 => still the same phenomenon. > Please Advice! > Tal Hi Tal, The EPC16 should be driving out the DCLK signal, so figuring out why this does not happen is key. However it's hard to say exactly what is the problem based on this description. Here's a few things to try: 1. Make sure that the MSEL pins are set correctly on the FPGAs. PPS is the acronym for Passive Parallel Synchronous - but the setup where one EPC16 drives multiple FPGAs in parallel like this is called Concurrent Configuration, and each FPGA should be set to Passive Serial as each is receiving a serial stream. 2. Make sure the PGM pins are set correctly on the EPC16 to show which page of data you want to access. If you are not doing anything special like storing multiple configurations, they should be set to 0. 3. There are some external connections that must be made on the EPC16. The F-RP# pin must be connected to the C-RP# pin. And the F-WE# pin must be connected to the C-WE# pin. This connection is because the EPC16 actually has two dice in it - a Flash and a controller. During the production test, the Flash pins are driven to 12 V, but the controller cannot handle this, therefore the connection cannot be made in the package. 4. The FPGA VCCINT must be powered before the POR on the EPC16 expires. The POR can be set to 2 ms or 100 ms by using the PORSEL pin - if you drive PORSEL low, then the POR is 100 ms. If this is not done, then the EPC16 will never start configuration and you will not see DCLK toggle. Hopefully one of these solves the problem. If not, please check out the FPGA Configuration Troubleshooter found on this web site: http://www.altera.com/cgi-bin/ts.pl?fn=configuration And if that doesn't work, then you may need to call the distributor, FAE, or AE for some more assistance as the problem debug starts to get very specific. Sincerely, Greg Steinke Altera Corporation gregs@altera.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