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
I seem to be having enormous difficulties accessing the 2 basic Xilinx distis which, until recently, have had at least reasonable web sites. o Insight: This used to have a decent US site but since the takeover by the Memec group its been given some bloody corporate makeover by web insultants. Now I can't get to it via Netscape on the PC, In order to register I had to use IE (the welcome mat for viruses), and I can now access the site using Netscape 4.7 under BSDI Unix but every time I try a part search I get ``general error - please contact webmaster'' (also happens with IE). o NuHorizons: Can't get to it at all via Netscape (some bloody JavaScript complaint about the page's``tags''). Using IE I can get into the home page but any attempt to part search just gets a ``server down please try later...'' message!! This site has changed format twice in the last 6 months. Is this some sort of charity service for HTML hackers unemployed since the dot.bomb? Anybody else having the same trouble ? Any suggestions ? Upgrade to NS 6.2 ?Article: 43351
Announcements and Call For Papers
2002 MAPLD International Conference
Please see the Call for Papers for the 2002 MAPLD International
Conference which follows these announcements.
. Electronic Registration is now open.
https://klabs.org/richcontent/MAPLDCon02/Reg/Registration.html
. Abstracts are due May 28, 2002. Late abstracts will be accepted
for the Poster Session.
. Apollo 16 Moon Rock display. We'll take your picture with it.
http://klabs.org/richcontent/MAPLDCon02/exhibits/nasa_exhibits.htm
. The CD-ROM Proceedings for the 2000 and 2001 MAPLD
International Conferences have shipped.
. Invited Speakers
Welcome: Dr. J. Sommerer Director, Research and
Technology Development, JHU/APL
Keynote: General Paul J. Kern, US Army
History: Dr. Roger D. Launius, Chief Historian, NASA
Allan McDonald, Thiokol Propulsion
"Space Systems Engineering: Lessons Learned"
Paul G. Cheng, The Aerospace Corporation
"Recovery from the Mars Surveyor '98 Failures:
Lessons Learned and Applied", Ed Euler and Steven Jolly
Lockheed Martin Astronautics Operations
AIAA Speaker: Dr. Nancy Leveson, MIT
Professor of Aeronautics and Astronautics
http://klabs.org/richcontent/MAPLDCon02/Invited/index.htm
. Design Seminars (Separate Registration)
Logic Design: Clocking, Timing Analysis, Finite State
Machines, and Verification
Programmable Logic in the Radiation Environment
. International guests and presenters should request their visas early.
. We will continue our "Birds-of-a-Feather Session" on reconfigurable
computing.
. As a courtesy, we are offering to help you get NASA souvenirs this
year. You can order on-line and your items will be waiting for you
at check-in. This will save you traveling time and we don't know
what will and will not be open next September.
https://klabs.org/richcontent/MAPLDCon02/Souvenir/souvenir.html
. Hotel, Transportation, and Directions are available on the
Conference home page.
http://klabs.org/richcontent/MAPLDCon02/MAPLDCon02.html
_________________________________________________________________________
Call for Papers
2002 MAPLD International Conference
Kossiakoff Conference Center
The Johns Hopkins University - Applied Physics Laboratory
11100 Johns Hopkins Road
Laurel, Maryland 20723-6099
September 10-12, 2002
Abstracts are now being solicited for the 5th annual Military and Aerospace
Programmable Logic Devices (MAPLD) International Conference. Programmable
devices and technologies, as well as digital engineering and related fields,
will comprise the major emphasis of this Conference geared towards military
and aerospace applications.
The Technical Program will consist of oral and poster technical
presentations and Industrial and Government Exhibits. We are planning
an exciting program with presentations by Government, industry, academia,
and consultants, including talks by select Invited Speakers. Select papers
will be published in the AIAA Journal of Spacecraft and Rockets. This
conference is open to US and foreign participation and is unclassified.
For conference information, please see the http://klabs.org or the
conference www home page at:
http://klabs.org/richcontent/MAPLDCon02/MAPLDCon02.html
We are especially interested in papers emphasizing design and analysis
techniques with respect to reliability and fault tolerance, high-
performance, and low power for digital circuits. Papers on state-of-the
-art military and aerospace applications and ‘lessons learned’ are also
strongly encouraged. As in past years, we expect a large number of papers
on programmable logic, digital engineering, and components.
Birds-of-a-Feather Sessions: For the first time, at 2001 MAPLD
International Conference, a "birds-of-a-feather" session on reconfigurable
computing was held. The BOF sessions will continue as a MAPLD feature, and
we are soliciting proposals for such sessions. If you would like to lead
a session, please submit your idea with session title, a brief description,
and contact information to mapld2002@klabs.org
Seminars and Tutorials will be again be offered (with a separate
registration). Seminars and tutorials will be on September 9th, 2002.
Logic Design: Clocking, Timing Analysis, Finite State Machines,
and Verification
Programmable Logic in the Radiation Environment
Conference topics include (but are not limited to) the following:
Design and Analysis
CPU
Logic
Low-Power Techniques
High-Speed Techniques
Applications
Military (Ground, airborne, artillery, etc.)
Spaceborne
Arithmetic and Signal Processing
Encryption Systems
Devices
Advanced Devices, Technologies, and Software and Their Impact on
Critical System Reliability
Programmable Technologies and State-of-the-Art Devices and
Programmable Elements
Device Architecture
Systems and Software
System-on-Chip
Software Tools for Design/Analysis - HDLs, Synthesis, Design Entry
Systems
Translation from High Level Languages
Intellectual Property
Reliability
Experience and "Lessons Learned" from Mission Experience
Radiation Effects, Device Reliability and Element Characteristics
Fault Tolerance
Use of COTS Devices in the Military and Spaceflight Environment
Testing and Analysis Techniques
Advanced Packaging including Known-Good-Die, MCMs, and chip-scale
packaging.
Adaptive Computing Systems
Evolvable Hardware
Reconfigurable Computing
The conference is sponsored by:
NASA Goddard Space Flight Center
JHU/Applied Physics Laboratory
National Security Agency
Office of Logic Design
Electronics Radiation Characterization Project
Digital Engineering Institute/Office of Logic Design
Military & Aerospace Programmable Logic Users Group
American Institute of Aeronautics and Astronautics
IEEE Aerospace & Electronic Systems Society (AESS)
Air Force Research Laboratory
For more conference information, please see the MAPLD pages on http://klabs.org
or contact:
Richard Katz - Conference Chair
NASA Goddard Space Flight Center
mapld2002@klabs.org
Tel: (301) 286-9705
Alan W. Hunsberger - Conference Co-Chair
National Security Agency
awhunsb@afterlife.ncsc.mil
Tel: (301) 688-0692
Ann Darrin - Conference Co-Chair
Johns Hopkins University
Applied Physics Laboratory
ann.darrin@jhuapl.edu
Tel: (240) 228-4952
Tanya Vladimirova - Conference Co-Chair for the AIAA Journal of
Spacecraft and Rockets.
University of Surrey
T.Vladimirova@ee.surrey.ac.uk
+44(0)1483 879137
Conference Co-Chair, European Liaison
Hans Tiggeler
hans@klabs.org
Abstracts should be approximately 2 pages long. Please send abstracts to
mapld2002@klabs.org. Your abstract must be in an attached file, named using
this format: LastName_A.ext - where last name is the name of the first author
- e.g., Katz_A.txt. Please include first author information for point of
contact (name, affiliation, phone number, and e-mail address). All abstracts
must be unclassified.
Abstracts are due May 28th, 2002. Late papers will be accepted for the Poster
Session only. The program will be announced no later than July 3, 2002.
Industrial exhibit reservations should be sent to mapld2002@klabs.org and
should include company name and contact information (phone and email). Please
see http://klabs.org/richcontent/MAPLDCon02/Industrial_Exhibit_Request.htm for
additional information.
Article: 43352Hi folks, I have an old design created on foundation 1.5 for a Xilinx XC3030PC84 and I need to do a small mod to it. Does anyone know where I can get hold of the tools? Alex. alex_clapperton@hotmail.comArticle: 43353
We currently have a couple licenses of Foundation 3.1. We have some legacy designs that were done in schematics that we still work on and we also do VHDL. We are considering purchasing more licenses but it looks like we cannot get any Foundations 3.1 licenses. What benefit do we have if we upgrade to ISE 4.1/4.2. It is my understanding that those software packages are not backwards compatible with Foundations 3.1 schematics, in fact I am not sure they have any schematics ability at all. Thanks JakeArticle: 43354
Have you tried it yet? My bet is that you will have no prob making 50Mhz, I think I remember having eight levels and making 33Mhz.Article: 43355
spam spam eggs and spam spam spam bacn and spam SPAM glorious SPAM! If a tree fell on a tin of SPAM in the forest would anyone care?Article: 43356
Jake, The ISE tools do indeed have a schematic editor, named ECS. You are correct in that it is not compatible with the Foundation Schematic Editor. The main difference between the two is that ECS creates HDL and then synthesizes it, while the Foundation Schematic Editor creates a netlist. I hope this helps. Regards, Kamal Jake wrote: > We currently have a couple licenses of Foundation 3.1. We have some legacy designs that were done in schematics that we still work on and we also do VHDL. We are considering purchasing more licenses but it looks like we cannot get any Foundations 3.1 licenses. What benefit do we have if we upgrade to ISE 4.1/4.2. It is my understanding that those software packages are not backwards compatible with Foundations 3.1 schematics, in fact I am not sure they have any schematics ability at all. > > Thanks > > Jake >Article: 43357
Hi, How do I program a XCR5064 coolrunner? The ISE4.2i IMPACT tool detects there is a JTAG device but cannot identify part (IDCODE). Tried earlier versions of the JTAG programming software with same results. Any ideas? Thanks -- Derren CromeArticle: 43358
Phil, Fine. Keep you misconceptions on how and what we test. I have offered you the information, and the answer. I do not wish to argue with you. What you propose is of no use to anyone, and we already have it covered. Sorry to spoil your plans. And if we had a 1 in 50 latent defect problem, we wouldn't even have two seconds to answer these emails, nor have sold over a billion dollars of Virtex. Remember that ASIC simulators still use our largest devices, and if anyone is going to find test coverage issues we may have missed, they are. They reconfigure constantly with different configurations. It is pretty easy for us to find out how well we are doing in terms of our test coverage. I have also stated that over time, we get better in our test coverage as we hear from everyone who finds an occasional test escape, and fix the program. How we actually accomplish what you state is impossible, is proprietary and confidential (or already covered by patents, or in patents pending), and one of the reasons why others may find it challenging to enter the FPGA business, Austin Phil Hays wrote: > Austin Lesea wrote: > > > Our test coverage has increased radically over the last four years, > > and is still increasing. > > So? A complete test isn't practical. For example, look at the small > switch box on the output of a CLB. Notice that each of the 8 outputs > from this switch box can be programmed to one of 12 sources. The number > of legal combinations is somewhat more than (12*12*12... eight times) or > 12^8 or 429,981,696 different ways to program that switch box. At 25 ms > per configuration load, all combinations could be verified in somewhat > more than 124 days. The larger switch boxes would take rather longer. > A check for interactions between switch boxes much longer still. You > simply can't do a complete test, even if you wanted to. > > A shorter than complete test needs to make assumptions that may well be > very good, but may well miss specific failures. Understand, I'm not > looking for perfection. I'm looking for a better test. I'd like to buy > it as an off the shelf option, if I could. I'd rather buy it from > Xilinx, but if not there are other options such as a third party test > house and/or do it in house. > > > After all, we "sell" re-configuration, so we have to test for it as > > well. > > The cost of a failure to re-configure varies with the application, as > does the odds of finding such an issue. The standard test flow is good > enough for most users, as: re-programming isn't frequent, and the cost > of failing a reprogramming isn't that high, and the risk of failing will > vary with the application, but is fairly low. Change any two of those, > however, and a more exhaustive part test becomes valuable. > > -- > Phil HaysArticle: 43359
Hi, I need to generate a tunable clock in the range from 18Mhz - 30Mhz with 100Hz resolution. I was considering to use an external VCO and implement a PLL in the FPGA. But I was wondering is this also can be done in another way. The main problem is that the clock is used for audio D/A, so it must be a low jitter clock. Any suggestions ? MarcelArticle: 43360
Marcel, How low for the jitter? That will determine the solution. Austin Marcel wrote: > Hi, > > I need to generate a tunable clock in the range from 18Mhz - 30Mhz with > 100Hz resolution. > I was considering to use an external VCO and implement a PLL in the FPGA. > But I was wondering is this > also can be done in another way. > > The main problem is that the clock is used for audio D/A, so it must be a > low jitter clock. > > Any suggestions ? > > MarcelArticle: 43361
"Austin Lesea" <austin.lesea@xilinx.com> wrote in message news:3CE90C91.AD4B7D6C@xilinx.com... > Marcel, > > How low for the jitter? That will determine the solution. > > Austin Well it`s for audio A/D conversion, preferably jitter on the output should be < 5ns. input clock of FPGA will be 80Mhz MarcelArticle: 43362
The broad range of nearly a full octave means that you'll end up with some modulation spurs on your VCO output depending on how close some beat harmonics are between the reference clock and the output frequency. You may be able to use a low enough frequency in your lowpass filter that the amplitude of any spurs are small enough in the time domain that you don't hear a difference. Fractional-N synthesizers will provide good agility - ability to track a changing reference - but will do so at a cost of phase noise. If you're dealing with radio systems, phase noise characteristics are critical for system performance. Telecom systems enjoy a less stringent noise floor than many radio designs but have very strict time domain requirements. Audio? The agility of the fractional-N approach is often why the approach is chosen which calls for a high corner frequency in the analog PLL loop filter. It doesn't look like you need that agility so a very low corner point may do the trick. But how low can you go and still get a good quality signal? Use of film caps and very short connection lengths in the filter would be critical as it is in lew reference frequency VCOs. So - if you want to attempt the Fractional-N, the simplest form just needs an accumulator. Rather than using a large integer divider to get a 100 Hz reference frequency, you can employ an accumulator to get a higher reference frequency adding the reciprocal of your divider each reference clock cycle. Rather than taking a 50MHz reference and dividing by, for instance, about 4019.29 for a reference frequency 12.44 kHz, you would add 1/4019.29 or .0002488 each reference clock cycle for the same effective result. The higher the accumulator frequency, the smaller the spurs are due to the edge uncertainty (+/-10 ns for 50 MHz) at the beat frequencies. If your reference frequency is lower than the VCO frequency, it would be better to do the accumulator based on the VCO clock. So.... Use an accumulator sized to get the precision you need. Choose a reference frequency that's high but still works well with the VCO phase comparator you choose. Use a low pass filter - as low as reasonable - to get rid of the beat frequency spurs. And remember that FPGAs are digital devices, not analog - the signal might not be "clean" enough in output voltage level for some phase comparator schemes (e.g. don't use an XOR in the FPGA for the phase comparator - use an external device that is less sensitive to voltage swing). If you want to reduce the spurs, you can use other techniques to feed the accumulator error back into the reference divider to effectively perform a digital lowpass on the spurs at the cost of higher phase noise at higher frequencies (which you'll be filtering) but that involves a bit more detail and it's been about 3 years since I was big into this stuff. Happy synthesis! - John_H Marcel wrote: > Hi, > > I need to generate a tunable clock in the range from 18Mhz - 30Mhz with > 100Hz resolution. > I was considering to use an external VCO and implement a PLL in the FPGA. > But I was wondering is this > also can be done in another way. > > The main problem is that the clock is used for audio D/A, so it must be a > low jitter clock. > > Any suggestions ? > > MarcelArticle: 43363
Adrian <> wrote in message news:<ee76d20.4@WebX.sUN8CHnE>... > Are you going to drive the DAC with a clock signal from your DLL? You can just use different phase shifted signals until it works and you meet your setup requirements. I would guess either a 180 degree or 270 degree phase shift would work. > > adrian No plans to clock the DAC from the FPGA DLL due to the very low jitter requirements on the DAC clock. DLLs are just too noisy for this sort of thing. Unfortunately. BertArticle: 43364
Hi I wonder if you can help, We currently have a system that is controlled by an embedded PC and contains up to 15 of our own custom ISA cards. We plan to gradually update the cards by replacing the ISA interface in each one with an FPGA, so that at some point in the future we could reprogram them all to communicate via a different (faster) bus. I have been handed the first stage which involves designing a PCI-ISA bridge, which will allow us to continue to use the ISA bus with PCI-only PCs. Again, this needs to be re-programmable to allow the replacement of the ISA end with a different protocol at some point in the future. To complicate matters, the card also needs to have: * an IEEE1394 Interface (Firewire) * a USB2.0 Interface * a (relatively) small amount of control logic and I/O I'd planned to design the ISA/USB2.0/Firewire to essentially be three independent devices on the PCI bus (will a pci-pci bridge be required?). The logic and I/O will probably go on the ISA side of the bridge. I'm currently unsure whether to: a) attempt to stuff everything into a suitable FPGA, or b) use a PCI-to-USB2 chip, and a PCI-to-IEE1394 chip, and stick the ISA bridge and control logic into an FPGA. Being new to both PCI and FPGA design I'd very much appreciate any comments/ideas/advice etc. on how to go about doing this, any problems I'm likely to come up against, or any devices/IP cores that may be of use. If it's any help, were likely to make 50 a year for 5 years at a retail price of $2k-$3k (that's for this particular card, not the whole system). Many Thanks, JonnyArticle: 43365
Ignoring debounce for the moment, the syntax you might want might look like the
following:
reg use_sync;
reg used;
always @(posed clk)
begin
use_sync <= USED_IN; // you don't want metastability
used <= use_sync;
if( use_sync && !used ) // edge detector
lstate <= lstate +1;
end
This synchronous design won't give an incorrect count due to a switch edge
detected at about the same time as the clock edge. The debounce mentioned by
another poster could be used or you might try a technique I used a long time ago
if your pushbutton is alterable: rather than using an SPST with a pulldown
resistor and the switch to VCC, use an SPDT with the switch connections to VCC
and GND and the center to 1) your input and 2) through a small resistor (200
ohms, perhaps) to a pin driven by the use_sync register introduced above. The
idea here is that when the VCC is detected, the "bounce" will be between VCC and
open. The first contact in the bounce will be significantly more than one clock
cycle so the resistor "feedback" will change the state of the "float" to a logic
high. Similar behavior when the switch is released and the ground is
reestablished. Nice little hardware debounce that requires an extra pin and a
double throw.
cfk wrote:
> I have a board with a VirtexE on it and with amongst other things, a button
> (call it USER_IN) and three leds (call then LED[2:0]) controlled by a
> variable lstate. I want to create a modest state machine so that I
> initialize lstate to 3'b000, and then with each button push, I move to
> 3'b001..3'b111 and then back to 3'b000. I tried the following:
>
> always @(posedge clk and USER_IN)
> begin
> lstate = lstate + 1;
> end
>
> But what seems to happen is the states are cycling through at clk speed. The
> reason I could not use (posedge clk and posedge USER_IN) is then the Xilinx
> ISE wants to assign USER_IN to a clock pin and I cannot implement the
> design. Maybe this issue is my understanding of ISE and Verilog as I am
> officially a newbie at this time.
>
> Next I tried
>
> always @(posedge clk and USER_IN)
> begin: ledstater
> reg lstate_toggle;
> if(USER_IN & lstate)
> begin
> lstate_toggle = !lstate_toggle;
> lstate = lstate + 1;
> end
> end
>
> This one doesn't seem to do anything to the LED's (which are set with a
> seperate assign statement). So, any suggestions would be greatly
> appreciated.
>
> Charles
Article: 43366Tullio, According to the Verilog specification (as I understand it) the parameter value will be available to the entire design once the parameter is read in. The way XST currently handles Verilog projects is that once the hierarchy is determined the lowest level file will be analyzed. The safest approach for using parameters would be to put them all in a `include file then put the `include statement in all of the files that will be affected. Steven Elzinga Applications Engineer Xilinx Tullio Grassi wrote: > Hi, > Verilog allows a construct to pass parameters to lower level modules: > > ////////////////////////////////////// > parameter > PARAM1 = 128; > > defparam > my_lower_module.PARAM1 = PARAM1; > ////////////////////////////////////// > > that works as long as inside my_lower_module > PARAM1 is defined again. > This can be repeted for several modules down the hierarchy, > and is very useful for heavy hierarchical designs. > > I've had problems using it with XST (ISE4.2). > It looks like XST selects the value randomly along > the hierarchy, rather than at the top level. > > Anybody had similar problems ? > -- > > Tullio Grassi > > ====================================== > Univ. of Maryland - Dept. of Physics > College Park, MD 20742 - US > Tel +1 301 405 5970 > Fax +1 301 699 9195 > ======================================Article: 43367
Marcel, Well. That implies a clock of greater than 200 MHz for any digital synthesis means, as that determines the rate at which you can do anything, and still meet your requirement. In a Virtex II, I would use the 80 MHz input, and multiply by 3 in the DCM, and then clock a DDFS (direct digital frequency synthesizer, or phase accumulator) with enough bits to resolve what you need in frequency steps (21 bits gets you to 114 Hz steps, 22 bits to 57 hz steps, etc). The jitter would be: 4.167 ns from the clock, and .65 ns from the DCM synthesizing the 4.167 ns clock period, or 4. 817 ns P-P for the sampling clock. With another 100 to 200 ps for the rest of the signal integrity, you should still be under 5ns. Fractional synthesis, pulse stuffing, etc. will also work fine, but you need the faster clock rate regardless. Austin Marcel wrote: > "Austin Lesea" <austin.lesea@xilinx.com> wrote in message > news:3CE90C91.AD4B7D6C@xilinx.com... > > Marcel, > > > > How low for the jitter? That will determine the solution. > > > > Austin > > Well it`s for audio A/D conversion, preferably jitter on the output should > be < 5ns. input clock of FPGA will be 80Mhz > > MarcelArticle: 43368
All the talk about embedded bus width conversion is because it's built-in and encounters no additional delay in the block rams in the Xilinx architecture. Since your application is a little different, a mux is probably your best bet. The outputs don't tristate and the multiplexers are quick. shparekh@yahoo.com wrote: > Hi, > > I am trying to convert bus widths. One bus spans multiple block rams. > In other words while writing to brams, the data word is 96 bits - 3 > block rams. While reading, the word is 32 bits i.e. 1 block ram at a > time. Therefore, while reading I need to access the three block rams > for which I use lower order address bits to enable the block rams. My > question is if I take away the enable will the output port of the > block ram be placed in tristate. If so then on the read port I can > simply bus the output data to all the block rams. > > I was trying to search for this information in the databook/handbook > but no luck so far. > > I would appreciate some words of wisdom. > > -sanjayArticle: 43369
Bert, True. DLLs, DCMs have jitter. They do wonderful things, but at a cost. For sampling clocks, or D/A clocks, always recongnize that there will be jitter, and in the most demanding applications (3G base stations), one may have to use the best possible LVPECL clock, differentially distributed, directly to the D/As and A/Ds (see the Analog Devices Website, and read their app notes on this subject, they are excellent in this regard). In fact, not even a PLL may be used for these kinds of situations, especially not one integrated into an FPGA. Once the data has been sampled by the high quality clock, it can then be processed in the FPGA, and then output and retimed by the high quality clock into the D/As. DCMs (or DLLS) are then used internal to the FPGA to deskew the clocks, and ease the IO timing. In other areas, where jitter is less of an issue (such as the audio DAC posting on this board), DCMs (DLLs) are not going to be an issue, and clock synthesis becomes the problem. Austin Bert Wibble wrote: > Adrian <> wrote in message news:<ee76d20.4@WebX.sUN8CHnE>... > > Are you going to drive the DAC with a clock signal from your DLL? You can just use different phase shifted signals until it works and you meet your setup requirements. I would guess either a 180 degree or 270 degree phase shift would work. > > > > adrian > > No plans to clock the DAC from the FPGA DLL due to the very low jitter > requirements on the DAC clock. DLLs are just too noisy for this sort > of thing. Unfortunately. > > BertArticle: 43370
Also consider that assembled DIMMs are more of a commodity than the individual parts. Both OEMs and DIMM manufacturers buy the silicon from the smae place. DIMMs come out of the pipeline some time after the silicon is purchased adding to some disparity during pricing fluctuations. Since memory prices can double or halve in a few months and overstock on DIMMs may have different pricing pressures than overstock of silicon, the numbers can get very strange. Contract pricing sometimes helps, sometimes hurts. Depending on buying power and exposure to risk, it's sometimes better to deal with DIMMs than with the piece parts. rickman wrote: > Herman Oosthuysen wrote: > > > > rickman <spamgoeshere4@yahoo.com> wrote in message news:<3CE57484.D9777F38@yahoo.com>... > > > Matt H wrote: > > > > > > > > "rickman" <spamgoeshere4@yahoo.com> wrote in message > > > > news:3CE54C57.E05567F8@yahoo.com... > > > > > I am seeing the price of 256 Mbit SDRAM at about $20 to $25. This is > > > > > about 8 times what it costs for the same amount of memory on DIMMs. I > > > > > know that quantity makes a difference, but I can buy a single 256 MByte > > > > > DIMM for $22 or I can buy 1k 32 MByte SDRAM chips at $20 each. This > > > > > seems very excessive. > > > > > > > > > > Anyone getting better pricing on 16x16 SDRAM? > > > > > > > > > > > > > > > -- > > > > > > > > > > Rick "rickman" Collins > > > > > > > > > > rick.collins@XYarius.com > > > > > > > > Hi Rick, > > > > Check out this community: > > > > http://www.dramexchange.com/default.asp > > > > It looks like the current price for 16x16 is about $8. Perhaps you can find > > > > a better price. > > > > Good Luck, > > > > Matt > > > > > > Interesting web site, but these prices are largely irrelevant. None of > > > this is open to me to purchase. Even after I register, I don't see a > > > way to buy. I expect these prices are for very large orders. > > > > Unless you are a large buyer, you are hooped. In my experience, an > > Asian factory can get stuff at half the price we are quoted for 10,000 > > quantities! > > > > Cheers, > > > > Herman > > http://www.AerospaceSoftware.com > > I am finding that. I just strikes me as odd that I can buy exactly one > memory module at a quarter or even an eighth of what the equivalent > SDRAM chips will cost me if I buy 1000 of them. But then electronic > purchasing has never been logical.. :) > > -- > > Rick "rickman" Collins > > rick.collins@XYarius.com > Ignore the reply address. To email me use the above address with the XY > removed. > > Arius - A Signal Processing Solutions Company > Specializing in DSP and FPGA design URL http://www.arius.com > 4 King Ave 301-682-7772 Voice > Frederick, MD 21701-3110 301-682-7666 FAXArticle: 43371
Rick Filipkiewicz <rick@algor.co.uk> wrote in message news:<3CE8BF39.B7AA186F@algor.co.uk>... > I seem to be having enormous difficulties accessing the 2 basic Xilinx > distis which, until recently, have had at least reasonable web sites... The one downunder works good with netscrape: http://www.insightelectronics.com.auArticle: 43372
You can do fractional-N with a lower clock rate. If real analog VCO elements are used the issue becomes what the reference frequency is and how much noise one chooses to introduce into the phase comparator. If the beat frequency spurs are within the loop filter passband, the full error will be "felt" which is up to 12.5 ns peak jitter at 80 MHz system clock, but only in your passband. If this jitter *within your PLL filter passband* is too much, a 3 stage "MASH" network to perform the digital lowpass I mentioned in another post may get you where you want to be. Why 3 stages? If you research enough to find out about MASH networks, 3 is better than 2 as long as you don't need the agility I mentioned previously. I have great respect for Austin's experience with jitter related issues singe his experience with Stratum-III has demanded the strongest attention to detail and nuance in precision frequency generation. An audio application might get desireable results with a proper VCO and fractional-N synthesis but a straight digital synthesis method might be simpler and more cost effective. The Virtex-II XC2S40 is possibly a cost-effective approach to your needs. You can even extend the resolution of the DCM method by using the global clock muxes on different phases of one high frequency clock at the cost of another DCM and some global clock mux resources. I really like that little part! I just saw on another newsgroup a mention that I'll quote here (comp.lang.verilog, thread "7497 implementation"): Allan Herriman wrote: > I guess it's time to plug my totally free Fractional-N divider program > that generates VHDL and Verilog. > http://fractional_divider.tripod.com > > Regards, > Allan. I haven't looked at the site but you might find something of interest there. Austin Lesea wrote: > Marcel, > > Well. That implies a clock of greater than 200 MHz for any digital synthesis > means, as that determines the rate at which you can do anything, and still > meet your requirement. > > In a Virtex II, I would use the 80 MHz input, and multiply by 3 in the DCM, > and then clock a DDFS (direct digital frequency synthesizer, or phase > accumulator) with enough bits to resolve what you need in frequency steps (21 > bits gets you to 114 Hz steps, 22 bits to 57 hz steps, etc). > > The jitter would be: 4.167 ns from the clock, and .65 ns from the DCM > synthesizing the 4.167 ns clock period, or 4. 817 ns P-P for the sampling > clock. With another 100 to 200 ps for the rest of the signal integrity, you > should still be under 5ns. > > Fractional synthesis, pulse stuffing, etc. will also work fine, but you need > the faster clock rate regardless. > > Austin > > Marcel wrote: > > > "Austin Lesea" <austin.lesea@xilinx.com> wrote in message > > news:3CE90C91.AD4B7D6C@xilinx.com... > > > Marcel, > > > > > > How low for the jitter? That will determine the solution. > > > > > > Austin > > > > Well it`s for audio A/D conversion, preferably jitter on the output should > > be < 5ns. input clock of FPGA will be 80Mhz > > > > MarcelArticle: 43373
This already exists, do a search on google for 'hardware software split language pc' exactly and you'll get your hit. Sorry boys.Article: 43374
Oops! One moment... A little back tracking. There's a point in VCO design where the phase noise transitions from being dependent on the reference to being dependent on the VCO. This is what mostly drives the PLL loop filter cutoff frequency. You cannot "use a low pass filter - as low as reasonable - to get rid of the beat frequency spurs" but need to make the tradeoff based on the acceptable jitter contributed from the VCO. A 2 or 3 stage MASH network might be the best tradeoff if you really want the fractional-N approach. I forget what "MASH" stands for, but it's a multistage filter that doesn't have the stability issues that many Delta-Sigma techniques have. I first read up on the technique in an Analog Devices paper at a Mixed Signal Design Conference and found more literature on a day trip to the Library of Congress. The Mathcad work I did suggested I'd get the synthesis results I wanted with the 3 stage filter (2 would probably suffice, 4 was worse) but my frequency range was limited to +/- 100ppm so I was able to easily avoid beat frequencies for ultra-low jitter performance. A 5 ns budget might make the octave tuning range a reasonable goal. It's not the most straight-forward design technique around. The other digital means might suit you best. John_H wrote: > it's been about 3 years since I was big into this stuff.
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