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 Sep 11, 12:17=A0am, "Antti.Luk...@googlemail.com" <antti.luk...@googlemail.com> wrote: > On Sep 10, 11:36=A0pm, nobody <cydrollin...@gmail.com> wrote: > > > Completion, > > > The FPGA never releases =A0the Global Three State(GTS) after done goes > > high, described in DS312 pg. 107, because the fpga_cclk shuts down one > > clock cycle to early. After the revision of taking out the need to > > program while FPGA_initb is high gives the extra fpga_cclk needed to > > release GTS signal and drives the High Z FPGA_d bus. One stinking > > clock cycle who knew? > > > Sincerely, > > > Cy Drollinger > > Cy > > this was actually OBVIOUS, I assumed you KNOW FPGA is configured AND > working > (this is not same as done=3D1) > > it is always wise to send extra clocks after done=3D1... this is for me > common knowledge > i should have suggested this earlier, but i assumed you DID know that > FPGA was > actually driving the pins > > btw bus conflict and non-driving bus can be seen as different with DSO > or even multimeter > > Antti Antti, Do not beat yourself up about the OBVIOUS, you had a good suggestion about the High "Z" bus and my problem when you asked me to isolate this feature on unused pins. I got more familiar with High Z circuitry and its behavior, BTW Because it is written in Synthesis and in a constraints file does not make it so, Synthesis can override these as in defaults and preferences set within Synthesis. CyArticle: 142976
sdaau wrote: > Dear list, > > I have gotten my hands on a Rakon SPXO003204 50 Mhz crystal oscillator, > DIP-8 package: > > http://uk.rs-online.com/web/search/searchBrowseAction.html?method=searchProducts&searchTerm=226-2250&x=0&y=0 > (datasheet > http://docs-europe.electrocomponents.com/webdocs/013b/0900766b8013b634.pdf) > > But something about its behaviours puzzles me: To start with, the > datasheet says: "Supply Voltage: 5V ±0.25V". > > I have hooked this crystal to a lab power supply, where I can change the > supply voltage, and I start slowly increasing the voltage. From 0, up to > until about 2.6V power supply, the oscillator behaves as I expect - that > is, the output is from about 10% to about 90% of supply voltage, as per > datasheet: > > http://img222.imageshack.us/img222/1258/xooscmeas01.jpg > > (excuse the poor quality, I cannot focus the camera any better. The line > from channel 2 is used to indicate the zero. This scope cannot resolve 50 > Mhz, so I'm just using the shaded area as indication of oscillations) > > However, as soon as I cross 2.6V power supply, the working regime sort of > flips - and apparently there are some oscillations, but from roughly 70% to > 90% of power supply - for instance, here is how it looks for the 5V supply > (as per datasheet) > > http://img222.imageshack.us/img222/5435/xooscmeas02.jpg > > My questions are: > * Is this the expected behavior of this crystal oscillator - or is this > maybe a damaged part? > * Since this was just the oscillator connected directly to power supply > (no capacitors or anything as per "Test Circuit" in the datasheet), should > I maybe expect that external components would make a difference (in the > sense of allowing output of about 10% to about 90% of supply voltage, even > for 5V supply?) > * If this is the expected behavior for this part - can I take that most > crystal oscillators on the market will show similar behaviour? > > Thanks for any comments, > Cheers! > > > --------------------------------------- > This message was sent using the comp.arch.fpga web interface on > http://www.FPGARelated.com You have left off aa lot of information from the pictures. X and Y settings would be nice. What is the bandwidth of the scope? Also, what is your power supply and how is it hooked up? Bypass capacitors are very useful and could be the issue.Article: 142977
Hi all, I have to create a core which connects to two different PLB busses with slave burst interfaces. The wizzard to create a new pcore in Xilinx EDK does not seem to support more than one PLB connection. Is there a way other than manually edit the cores .mpd file etc? TIA MarkusArticle: 142978
On Sep 11, 5:38=A0pm, nobody <cydrollin...@gmail.com> wrote:
> On Sep 11, 12:17=A0am, "Antti.Luk...@googlemail.com"
>
>
>
> <antti.luk...@googlemail.com> wrote:
> > On Sep 10, 11:36=A0pm, nobody <cydrollin...@gmail.com> wrote:
>
> > > Completion,
>
> > > The FPGA never releases =A0the Global Three State(GTS) after done goe=
s
> > > high, described in DS312 pg. 107, because the fpga_cclk shuts down on=
e
> > > clock cycle to early. After the revision of taking out the need to
> > > program while FPGA_initb is high gives the extra fpga_cclk needed to
> > > release GTS signal and drives the High Z FPGA_d bus. One stinking
> > > clock cycle who knew?
>
> > > Sincerely,
>
> > > Cy Drollinger
>
> > Cy
>
> > this was actually OBVIOUS, I assumed you KNOW FPGA is configured AND
> > working
> > (this is not same as done=3D1)
>
> > it is always wise to send extra clocks after done=3D1... this is for me
> > common knowledge
> > i should have suggested this earlier, but i assumed you DID know that
> > FPGA was
> > actually driving the pins
>
> > btw bus conflict and non-driving bus can be seen as different with DSO
> > or even multimeter
>
> > Antti
>
> Antti,
>
> Do not beat yourself up about the OBVIOUS, you had a good suggestion
> about the High "Z" bus and my problem when you asked me to isolate
> this =A0feature on unused pins. I got more familiar with High Z
> circuitry and its behavior, BTW Because it is written in Synthesis and
> in a constraints file does not make it so, Synthesis can override
> these as in defaults and preferences set within Synthesis.
>
> Cy
you can not change the io type with constraints.. only by RTL
you can change settings for unused pins with some settings
but the in/out/bidir is dictated by RTL code
Antti
From puiterl@notaimvalley.nl Fri Sep 11 09:47:52 2009
Path: unlimited.newshosting.com!s02-b03!num01.iad!npeer03.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!postnews.google.com!news4.google.com!feeder3.cambriumusenet.nl!feed.tweaknews.nl!194.134.4.91.MISMATCH!news2.euro.net!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail
Message-Id: <4aaa7f38$0$83244$e4fe514c@news.xs4all.nl>
From: Paul Uiterlinden <puiterl@notaimvalley.nl>
Subject: Re: Does ModelSim or any simulator software have a function similar to the standard function any logic analizer has?
Newsgroups: comp.arch.fpga,comp.lang.vhdl
Followup-To: comp.arch.fpga
Date: Fri, 11 Sep 2009 18:47:52 +0200
References: <55bf538b-e613-4a16-8b4a-baf72679fbe1@u16g2000pru.googlegroups.com> <fd2j95p1jv5558t70mnk6hc3nlk11qt765@4ax.com> <59730a19-3192-4625-97dc-491f71a5cfb9@p10g2000prm.googlegroups.com> <ad61057d-19f9-4b8f-b21d-e51deb8d32ce@y21g2000yqn.googlegroups.com>
Organization: AimValley
User-Agent: KNode/0.10.4
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7Bit
Lines: 56
NNTP-Posting-Host: 80.127.156.245
X-Trace: 1252687672 news.xs4all.nl 83244 [::ffff:80.127.156.245]:32956
X-Complaints-To: abuse@xs4all.nl
Xref: unlimited.newshosting.com comp.arch.fpga:93561 comp.lang.vhdl:31284
X-Received-Date: Fri, 11 Sep 2009 16:47:52 UTC (s02-b03)
ehliar@isy.liu.se wrote:
> 1. Compile all source code files with +acc so that it is possible to
> add signals to the wave window.
> 2. Run simulation for 1 hour or until an error occurs.
> 3. If no error occured, save a checkpoint with a unique serial number,
> go back to step 2
> 4. At this point you can load up the latest checkpoint, add all
> relevant signals to your wave window (or signal log if you like the
> log-command) and rerun the simulation
>
> The advantage of this approach is that you don't have to spend any
> computation
> time to log signal changes while retaining the ability to have full
> visibility
> when you are actually close to an error.
>
>
> Look for the checkpoint command in the Modelsim documentation for more
> info.
A simple do-script to run the simulation while a signal ("simulate" in my
case) is true, creating numbered checkpoints every 5 ms:
# Quit simulation after assertion failure (avoids endless loop of just
# writing checkpoints).
#
onbreak {quit -f}
# Run the simulation as long as the simulate signal is set
#
set n 0
while {[examine /tc/tb/simulate]} {
incr n
run 5 ms
checkpoint chkpnt_$n
}
If an error occurs, load the checkpoint that was created before the error,
enable tracing and continue simulation.
But please do test if a generated checkpoint can be loaded and the
simulation can continue from that checkpoint.
My experience is that either loading or continuing simulation does not work
on a unsupported platform like Fedora Core 6 or 8. On a platform that is
supported (like Redhat entreprise) it does work.
All I'm saying is: test if it works on your system before simulating for
days.
--
Paul Uiterlinden
www.aimvalley.nl
e-mail addres: remove the not.
Article: 142979On Sep 11, 10:47=A0am, Markus Zingg <spamt...@shdesign.info> wrote: > Hi all, > > I have to create a core which connects to two different PLB busses with > slave burst interfaces. The wizzard to create a new pcore in Xilinx EDK > does not seem to support more than one PLB connection. > > Is there a way other than manually edit the cores .mpd file etc? > > TIA > > Markus Hello Markus, The wizard will not create what you want, but you can use it as a starting point. Are you using the IPIF, or your own interface? Assuming that you are using the IPIF and that you used the wizard as a starting point, you would need to: Add the additional ports and generics (or parameters) for the second bus to the top level hdl file. Create a second instance of the IPIF in the top level HDL file. Modify the user_logic file to have a second IPIC interface into it. Modify the .mpd file to reflect the second bus. Put your stuff in the user_logic HDL file. If you have not modified the .mpd etc files before, they are documented in this file: Xilinx/12.2/EDK/doc/usenglish/psf_rm.pdf. Modify path according to your installation of course. I have created cores with multiple PLB interfaces, and the rest of EDK handled it fine. Regards, John McCaskill www.FasterTechnology.comArticle: 142980
"sdaau" <sd@imi.aau.dk> wrote in message news:_eKdnbazo6OnijfXnZ2dnUVZ_rCdnZ2d@giganews.com... > Dear list, > > I have gotten my hands on a Rakon SPXO003204 50 Mhz crystal oscillator, > DIP-8 package: > > http://uk.rs-online.com/web/search/searchBrowseAction.html?method=searchProducts&searchTerm=226-2250&x=0&y=0 > (datasheet > http://docs-europe.electrocomponents.com/webdocs/013b/0900766b8013b634.pdf) > > But something about its behaviours puzzles me: To start with, the > datasheet says: "Supply Voltage: 5V ±0.25V". > > I have hooked this crystal to a lab power supply, where I can change the > supply voltage, and I start slowly increasing the voltage. From 0, up to > until about 2.6V power supply, the oscillator behaves as I expect - that > is, the output is from about 10% to about 90% of supply voltage, as per > datasheet: > > http://img222.imageshack.us/img222/1258/xooscmeas01.jpg > > (excuse the poor quality, I cannot focus the camera any better. The line > from channel 2 is used to indicate the zero. This scope cannot resolve 50 > Mhz, so I'm just using the shaded area as indication of oscillations) > > However, as soon as I cross 2.6V power supply, the working regime sort of > flips - and apparently there are some oscillations, but from roughly 70% > to > 90% of power supply - for instance, here is how it looks for the 5V supply > (as per datasheet) > > http://img222.imageshack.us/img222/5435/xooscmeas02.jpg > > My questions are: > * Is this the expected behavior of this crystal oscillator - or is this > maybe a damaged part? > * Since this was just the oscillator connected directly to power supply > (no capacitors or anything as per "Test Circuit" in the datasheet), should > I maybe expect that external components would make a difference (in the > sense of allowing output of about 10% to about 90% of supply voltage, even > for 5V supply?) > * If this is the expected behavior for this part - can I take that most > crystal oscillators on the market will show similar behaviour? You say your 'scope can't resolve 50 MHz. I take it you mean the 'scopes bandwidth is less than 50 MHz. Then the peak-to-peak amplitude will appear less than it really is; but the average / mean DC level will be correct. The oscillator is unlikely to work correctly at low VDD. If you're seeing more amplitude at low VDD, then I would guess it's a low frequency relaxation oscillation - not crystal controlled - at a frequency much lower than 50 MHz.Article: 142981
Andrew Holme <ah@nospam.co.uk> wrote: < "sdaau" <sd@imi.aau.dk> wrote in message <> I have gotten my hands on a Rakon SPXO003204 50 Mhz <> crystal oscillator, DIP-8 package: (snip) <> I have hooked this crystal to a lab power supply, where I can change the <> supply voltage, and I start slowly increasing the voltage. From 0, up to <> until about 2.6V power supply, the oscillator behaves as I expect - that <> is, the output is from about 10% to about 90% of supply voltage, as per <> datasheet: (snip) < You say your 'scope can't resolve 50 MHz. I take it you mean the 'scopes < bandwidth is less than 50 MHz. Then the peak-to-peak amplitude will appear < less than it really is; but the average / mean DC level will be correct. < The oscillator is unlikely to work correctly at low VDD. If you're seeing < more amplitude at low VDD, then I would guess it's a low frequency < relaxation oscillation - not crystal controlled - at a frequency much lower < than 50 MHz. That is an interesting reason that I wouldn't have though of so fast. Then again, I wouldn't try running a 5V device at 2V. -- glenArticle: 142982
"Andrew Holme" <ah@nospam.co.uk> wrote in message news:bEyqm.94917$bU2.10408@newsfe29.ams2... > > "sdaau" <sd@imi.aau.dk> wrote in message > news:_eKdnbazo6OnijfXnZ2dnUVZ_rCdnZ2d@giganews.com... >> Dear list, >> >> I have gotten my hands on a Rakon SPXO003204 50 Mhz crystal oscillator, >> DIP-8 package: >> >> http://uk.rs-online.com/web/search/searchBrowseAction.html?method=searchProducts&searchTerm=226-2250&x=0&y=0 >> (datasheet >> http://docs-europe.electrocomponents.com/webdocs/013b/0900766b8013b634.pdf) >> >> But something about its behaviours puzzles me: To start with, the >> datasheet says: "Supply Voltage: 5V ±0.25V". >> >> I have hooked this crystal to a lab power supply, where I can change the >> supply voltage, and I start slowly increasing the voltage. From 0, up to >> until about 2.6V power supply, the oscillator behaves as I expect - that >> is, the output is from about 10% to about 90% of supply voltage, as per >> datasheet: >> >> http://img222.imageshack.us/img222/1258/xooscmeas01.jpg >> >> (excuse the poor quality, I cannot focus the camera any better. The line >> from channel 2 is used to indicate the zero. This scope cannot resolve 50 >> Mhz, so I'm just using the shaded area as indication of oscillations) >> >> However, as soon as I cross 2.6V power supply, the working regime sort of >> flips - and apparently there are some oscillations, but from roughly 70% >> to >> 90% of power supply - for instance, here is how it looks for the 5V >> supply >> (as per datasheet) >> >> http://img222.imageshack.us/img222/5435/xooscmeas02.jpg >> >> My questions are: >> * Is this the expected behavior of this crystal oscillator - or is this >> maybe a damaged part? >> * Since this was just the oscillator connected directly to power supply >> (no capacitors or anything as per "Test Circuit" in the datasheet), >> should >> I maybe expect that external components would make a difference (in the >> sense of allowing output of about 10% to about 90% of supply voltage, >> even >> for 5V supply?) >> * If this is the expected behavior for this part - can I take that most >> crystal oscillators on the market will show similar behaviour? > > You say your 'scope can't resolve 50 MHz. I take it you mean the 'scopes > bandwidth is less than 50 MHz. Then the peak-to-peak amplitude will > appear less than it really is; but the average / mean DC level will be > correct. > > The oscillator is unlikely to work correctly at low VDD. If you're seeing > more amplitude at low VDD, then I would guess it's a low frequency > relaxation oscillation - not crystal controlled - at a frequency much > lower than 50 MHz. > More likely: it's probably a 50 MHz 3rd overtone crystal that's oscillating on its fundamental at low VDD.Article: 142983
On Sep 11, 9:47=A0am, Paul Uiterlinden <puit...@notaimvalley.nl> wrote:
> ehl...@isy.liu.se wrote:
> > 1. Compile all source code files with +acc so that it is possible to
> > =A0 =A0add signals to the wave window.
> > 2. Run simulation for 1 hour or until an error occurs.
> > 3. If no error occured, save a checkpoint with a unique serial number,
> > =A0 =A0go back to step 2
> > 4. At this point you can load up the latest checkpoint, add all
> > =A0 =A0relevant signals to your wave window (or signal log if you like =
the
> > =A0 =A0log-command) and rerun the simulation
>
> > The advantage of this approach is that you don't have to spend any
> > computation
> > time to log signal changes while retaining the ability to have full
> > visibility
> > when you are actually close to an error.
>
> > Look for the checkpoint command in the Modelsim documentation for more
> > info.
>
> A simple do-script to run the simulation while a signal ("simulate" in my
> case) is true, creating numbered checkpoints every 5 ms:
>
> =A0 =A0 # Quit simulation after assertion failure (avoids endless loop of=
just
> =A0 =A0 # writing checkpoints).
> =A0 =A0 #
> =A0 =A0 onbreak {quit -f}
>
> =A0 =A0 # Run the simulation as long as the simulate signal is set
> =A0 =A0 #
> =A0 =A0 set n 0
> =A0 =A0 while {[examine /tc/tb/simulate]} {
> =A0 =A0 =A0 incr n
> =A0 =A0 =A0 run 5 ms
> =A0 =A0 =A0 checkpoint chkpnt_$n
> =A0 =A0 }
>
> If an error occurs, load the checkpoint that was created before the error=
,
> enable tracing and continue simulation.
>
> But please do test if a generated checkpoint can be loaded and the
> simulation can continue from that checkpoint.
>
> My experience is that either loading or continuing simulation does not wo=
rk
> on a unsupported platform like Fedora Core 6 or 8. On a platform that is
> supported (like Redhat entreprise) it does work.
>
> All I'm saying is: test if it works on your system before simulating for
> days.
>
> --
> Paul Uiterlindenwww.aimvalley.nl
> e-mail addres: remove the not.- Hide quoted text -
>
> - Show quoted text -
Hi Paul,
Your method has a fatal problem: it doesn't guarantee the information
available has a guaranteed fixed length.
1. Assume your breakpoint time length is set at 5ms;
2. The error happens at 1.00501s.
From your breakpoint to the error postion there is only 100ns waveform
available.
In other words, your breakpoint method doesn't get information of a
guaranteed fixed length which is determined by the error position.
If you have two sets of breakpoint data saved at any time period, the
method will be OK.
Hans's method is OK, which gaurantees a fixed length of data available
at any time point.
Weng
Article: 142984I haven't looked at Jonathan's paper yet, but for at least the last 3 years, there have been generic memory models on OpenCores. I believe they are available in Verilog only, but to the best of my knowledge they can be synthesized to memories with Xilinx, Altera, and several Std. Cell libraries. Might be worth to take a cool ... Cheers, rudiArticle: 142985
Operating ANY device outside it's specified operating range results in UNDEFINED Device behavior. Just because your tests with one particular part produced some results outside the specified operating range, it does not mean that EACH device will behalves the same. There is a reason WHY companies spend lots of time and money to characterize their parts. Regards, rudiArticle: 142986
On Sat, 12 Sep 2009 23:02:46 -0700 (PDT), luudee wrote: >I haven't looked at Jonathan's paper yet, but for at least the >last 3 years, there have been generic memory models on OpenCores. Could you give a more specific pointer? The best I could find on the new-look OpenCores was Jamil Khatib's models, written quite a long time ago and lacking some of the features that you need to work with RAMs in modern FPGAs. I probably wasn't looking in the right place, though. -- Jonathan Bromley, Consultant DOULOS - Developing Design Know-how VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK jonathan.bromley@MYCOMPANY.com http://www.MYCOMPANY.com The contents of this message may contain personal views which are not the views of Doulos Ltd., unless specifically stated.Article: 142987
On Sep 13, 11:59=A0am, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com> wrote: > On Sat, 12 Sep 2009 23:02:46 -0700 (PDT), luudee wrote: > >I haven't looked at Jonathan's paper yet, but for at least the > >last 3 years, there have been generic memory models on OpenCores. > > Could you give a more specific pointer? =A0The best I could > find on the new-look OpenCores was Jamil Khatib's models, > written quite a long time ago and lacking some of the > features that you need to work with RAMs in modern FPGAs. > I probably wasn't looking in the right place, though. > -- > Jonathan Bromley, Consultant > > DOULOS - Developing Design Know-how > VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services > > Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK > jonathan.brom...@MYCOMPANY.comhttp://www.MYCOMPANY.com > > The contents of this message may contain personal views which > are not the views of Doulos Ltd., unless specifically stated. the place is right just that the models are of no good in many cases AnttiArticle: 142988
Outline information on our first Spartan-6 release Drigmorn3 is now available. Drigmorn3 is aimed as a starter kit type product but also good for MicroBlaze and other processor applications. Details of this product http://www.enterpoint.co.uk/component_replacements/drigmorn3.html. We may be upgrading this product in the future with ADC and DAC channels but that is probably a few months away. Meanwhile our 16 channel ADC module fits this board as does our R/2R DAC module. And before anyone asks there will be a Craignell3 version of this board for the DIL module market. Timescales TBA. I'm hoping to be able to show this board at ESC in Boston but this depends on some parts arriving in time. Assuming this all happens we should be doing a little and large show with Drigmorn3 and Merrick1 running live on the stand. John Adair Enterpoint Ltd.Article: 142989
On Sep 13, 2:34=A0pm, John Adair <g...@enterpoint.co.uk> wrote: > Outline information on our first Spartan-6 release Drigmorn3 is now > available. Drigmorn3 is aimed as a starter kit type product but also > good for MicroBlaze and other processor applications. Details of this > producthttp://www.enterpoint.co.uk/component_replacements/drigmorn3.html. > > We may be upgrading this product in the future with ADC and DAC > channels but that is probably a few months away. Meanwhile our 16 > channel ADC module fits this board as does our R/2R DAC module. > > And before anyone asks there will be a Craignell3 version of this > board for the DIL module market. Timescales TBA. > > I'm hoping to be able to show this board at ESC in Boston but this > depends on some parts arriving in time. Assuming this all happens we > should be doing a little and large show with Drigmorn3 and Merrick1 > running live on the stand. > > John Adair > Enterpoint Ltd. AWESOME you renamed digimorn1 html page to digimor3 but did not care to take enough time to replace 1 with 3 inside the body of the text? AnttiArticle: 142990
John Adair <g1@enterpoint.co.uk> wrote: > Outline information on our first Spartan-6 release Drigmorn3 is now > available. Drigmorn3 is aimed as a starter kit type product but also > good for MicroBlaze and other processor applications. Details of this > product http://www.enterpoint.co.uk/component_replacements/drigmorn3.html. Why is still a FT232R unsed, and not a FT2232H. The FT2232H can be used for JTAG programming and delivers a high-speed data between PC and FPGA... -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 142991
Uwe The main reasons were mainly a blend of time and board space. Cost also played a small part as we buy the FT232RQ in considerable numbers and have the benefit of large quantity buying on the FT232RQ. There was also the aspect of reducing risk in this design for a first board. We have plenty of new things for us on the board to test out and addig to that list wasn't a good option. I won't rule improving this aspect of the board but it is going to be our lowest level offeing for Spartan-6 at least for some time to come. We do have spare unused I/Os on the FPGA which is something that's not normally left unused in our designs and I expect we will make some use of this in later versions of this board..There is also a good chance we will try the FT2232, or it's bigger brother, on a module first and once we are happy with it adopt it more widely. As to the JTAG side the use of the circuit, now public in the SP601, makes far more sense to adopt for programming the board. For better, or worst, the ability to work with standard Xilinx ISE makes a lot of sense. That would point to using a Cypress CY7C68014 if anything for a USB based JTAG. John Adair Enterpoit Ltd. On 13 Sep, 14:23, Uwe Bonnes <b...@elektron.ikp.physik.tu- darmstadt.de> wrote: > John Adair <g...@enterpoint.co.uk> wrote: > > Outline information on our first Spartan-6 release Drigmorn3 is now > > available. Drigmorn3 is aimed as a starter kit type product but also > > good for MicroBlaze and other processor applications. Details of this > > producthttp://www.enterpoint.co.uk/component_replacements/drigmorn3.htm= l. > > Why is still a FT232R unsed, and not a FT2232H. The FT2232H can be used f= or > JTAG programming and delivers a high-speed data between PC and FPGA... > -- > Uwe Bonnes =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0b...@elektron.ikp.physik.tu-dar= mstadt.de > > Institut fuer Kernphysik =A0Schlossgartenstrasse 9 =A064289 Darmstadt > --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 142992
On Sep 13, 4:23=A0pm, Uwe Bonnes <b...@elektron.ikp.physik.tu- darmstadt.de> wrote: > John Adair <g...@enterpoint.co.uk> wrote: > > Outline information on our first Spartan-6 release Drigmorn3 is now > > available. Drigmorn3 is aimed as a starter kit type product but also > > good for MicroBlaze and other processor applications. Details of this > > producthttp://www.enterpoint.co.uk/component_replacements/drigmorn3.htm= l. > > Why is still a FT232R unsed, and not a FT2232H. The FT2232H can be used f= or > JTAG programming and delivers a high-speed data between PC and FPGA... > -- > Uwe Bonnes =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0b...@elektron.ikp.physik.tu-dar= mstadt.de > > Institut fuer Kernphysik =A0Schlossgartenstrasse 9 =A064289 Darmstadt > --------- Tel. 06151 162516 -------- Fax. 06151 164321 ---------- Uwe RT232RQ is VERY reasonable choice!!! because of the CBUS bit-bang mode :) it also lowers the board cost compared to FT2232H for some good 4$ and also saves LOTS of board space, and reduces design in risc AnttiArticle: 142993
for those who did not monitor: digikey HAD 20 pcs of Spartan-6 in stock yesterday but i hesitated a few hours too much to place an order so now stock is empty. AnttiArticle: 142994
http://www.xilinx.com/support/answers/32661.htm kinda nothing much interesting, just derivation in options AnttiArticle: 142995
On Sep 14, 5:10=A0pm, Antti <antti.luk...@googlemail.com> wrote: > http://www.xilinx.com/support/answers/32661.htm > > kinda > > nothing much interesting, just derivation in options > > Antti HXT also but i already lost the link.. well the info will now be soon online aArticle: 142996
Dear list, Thanks so much for the extensive comments!! > ...datasheet says: "Supply Voltage: 5V ±0.25V". > All other bets are off. I'm sorry, I forgot to clarify that initially, I put the crystal oscillator in the board I'm making, powered with 5V - and got no oscillation, only a straight 5V, on its output, which got me surprised; which is why I decided to test it directly on the power supply. > My thoughts, and as the OP has suggested all's well at 90% of 5V, > that the device is behaving as expected. > > I would expect a working range to be a little wider than specified > range as indeed the OP experiences. Sorry again - I was trying to say that things are actually not well at 5V :) > You have left off aa lot of information from the pictures. X and Y > settings would be nice. What is the bandwidth of the scope? Also, > what is your power supply and how is it hooked up? > Bypass capacitors are very useful and could be the issue. I agree a lot of information has been left off, and sorry about that - so I hope to clear out some misunderstandings below, with use of video.. > You say your 'scope can't resolve 50 MHz. I take it you mean the > 'scopes bandwidth is less than 50 MHz. Then the peak-to-peak > amplitude will appear less than it really is; but the average / mean > DC level will be correct. > When I said that the scope "can't resolve 50 MHz", what I meant, moreless, is that the lowest time/div setting on the scope is 0.2 us = 200 ns. Period for 50 MHz is 20 ns, which means that for a 50 MHz signal, 10 periods would have to be squeezed into a single time div, thereby making them hard to see :) I didn't think much of the 3db bandwidth as such, but this document: "Choosing an Oscilloscope with the Right Bandwidth for your Application" - Application Note 1588 http://cp.literature.agilent.com/litweb/pdf/5989-5733EN.pdf pointed out (in very clear language for my taste, and with very nice screenshots) why the scope bandwidth itself is important - especially when measuring digital (ideally square) signals. Since a square wave ideally contains only odd integer harmonics, for a fundamental frequency fo, the next two harmonics will be 3*fo and 5*fo; for fo=50 MHz, I'd need at least 5*fo=250 MHz in order to at least see more-less accurate rise time of a 50 MHz square pulse. So, let me clarify a few things which I may have left out from the OP. The analog oscilloscope is a Hameg HM205-3 ( datasheet: http://www.hameg.com/manuals.0.html?&tx_hmdownloads_pi1[mode]=download&tx_hmdownloads_pi1[uid]=821&cHash=27984f11ee or http://www.hameg.com/typo3conf/ext/hm_downloads/pi1/download.php?fileName=fileadmin/user_upload/downloads/man/HM205-3_english.pdf&dlName=HM205-3_english.pdf ) and the datasheet states: "Frequency range: 2xDC to 20 MHz (-3 dB)". Anyways, I have now made a video (640x480) of the measurement process of the XO with this scope - so I hope things will be clearer about the test setup and measurement: http://en.theorasea.org/story.php?title=XO-testing-1 (or http://theorasea.org/itheora/index.php?v=http://blip.tv/file/get/Sdaauk-XOTesting336.ogv&out=link ) (or http://blip.tv/file/2600075 for FLV format - the above use .ogv, if you have trouble with showing ogv in your browser, just download the .ogv file and use VLC to view it) First you can see the probes at x1, volts/div is 2V, and power supply voltage gets increased from 0 to about 5V. Then the probes get switched to x10, volts/div to 0.2V, and the experiment repeated. The crystal is connected directly to power supply, as well as the probe - there are no other circuits in between. One of the probes measures the power supply directly, the other measures the crystal oscillator output. Time/div is 0.2us throughout. I changed the probes from x1 to x10, expecting that their effective impedance will change - and so will their influence on the crystal oscllator. The behaviour is somewhat the same in both x1 and x10, although x10 seems to show a somewhat bigger range of oscillation once the oscillation mode "flips" as voltage is increased above 2.5V. I now also have an access to an Agilent 54621A, which is marked as 60 MHz - according to the above Agilent PDF, it will be also inadequate for measuring 50 MHz clock (square) signal, but at least it should show a sinusoid ... and it does. In the following screenshots, channel 1 measures output and channel 2 measures the power supply. On this Agilent scope, having the probes as x1 shows a small "flip" - initially no oscillations, then first oscillations start at 2.06V (lower freq), then flip at 2.75V (higher freq, lower amplitude) and continues in that mode up to 5V. http://img198.imageshack.us/img198/9954/xo50x1agilent.png Having the probes as x10 results with a much smoother growth of output with input (no "flipping" of the output range - but flipping again in terms of frequency). Initially no oscillations, then first oscillations start at 2V (lower freq), then flip at 3.0V (higher freq, higher amplitude) and continues in that mode up to 5V. http://img233.imageshack.us/img233/7994/xo50x10agilent.png Hopefully, I managed to clarify the behaviour I'm getting a bit better :) > That is an interesting reason that I wouldn't have though of so fast. > Then again, I wouldn't try running a 5V device at 2V. > Again, my bad in clarifying - the only reason why I tried to power the device with less, was that my original attempt to power it with 5V didn't result in any oscillation at all (just a fixed 5V at output); which is why I tried to power it directly from a lab voltage supply and then sweep the power from 0V to 5V - which is when I noticed this "flipping" > Operating ANY device outside it's specified operating range > results in UNDEFINED Device behavior. > True, I guess - but again my bad in clarification: I attempted to operate the device outside its operating range, only because my initial attempt to power it at 5V and get oscillations failed. >> The oscillator is unlikely to work correctly at low VDD. If you're >> seeing more amplitude at low VDD, then I would guess it's a low >> frequency relaxation oscillation - not crystal controlled - at a >> frequency much lower than 50 MHz. >> > > More likely: it's probably a 50 MHz 3rd overtone crystal that's > oscillating on its fundamental at low VDD. Interesting, was not aware of this effect - however, it does seem that this "flipping" happens when the crystal changes its oscillation mode from lower to higher frequency (as the voltage sweeps from higher to lower values).. Related to this, I have also found the following document: "Start up behaviour of the UAA3220TS crystal oscillator" http://www.nxp.com/acrobat_download/applicationnotes/AN00085_1.pdf And although I'm not sure whether it talks about the internal circuitry of a crystal oscillator devices - or about components external to the crystal oscillator device - here are some quotes from there which I think are relevant : "in case the second relation, the so-called oscillation margin, is smaller than 1, oscillation does not start up (pg 10)" "For a given crystal resonator, with RM,max and C0, the oscillation margin can only be improved when the load capacitance and the amplifier gain are chosen as large as possible. The examples as given in Figure 7 and figure 8 show that these goals cannot be achieved simultaneously; the amplifier reaches its maximum gain only at low load capacitances and vice versa (pg 17)" "the oscillation margin strongly depends on the value of the static capacitance C0 (pg 19)" In all, seeing how different probe settings - and different scopes - tend to influence the behaviour of the device, I'm sort of led to believe that the how the crystal oscillates, depends on both the power supply and the external components that the XO can see... which leads me to think that the reason why it wouldn't oscillate in my board at 5V, was most likely external capacitors (which is what I'll experiment with next :) ) Well, I'll appreciate any further comments on whether my understanding gets to be more correct, Thanks again for the fine discussion, Cheers! --------------------------------------- This message was sent using the comp.arch.fpga web interface on http://www.FPGARelated.comArticle: 142997
sdaau <sd@imi.aau.dk> wrote: (snip) < I'm sorry, I forgot to clarify that initially, I put the crystal < oscillator in the board I'm making, powered with 5V - and got no < oscillation, only a straight 5V, on its output, which got me surprised; < which is why I decided to test it directly on the power supply. (snip) <> You say your 'scope can't resolve 50 MHz. I take it you mean the <> 'scopes bandwidth is less than 50 MHz. Then the peak-to-peak <> amplitude will appear less than it really is; but the average / mean <> DC level will be correct. < When I said that the scope "can't resolve 50 MHz", what I meant, moreless, < is that the lowest time/div setting on the scope is 0.2 us = 200 ns. Period < for 50 MHz is 20 ns, which means that for a 50 MHz signal, 10 periods would < have to be squeezed into a single time div, thereby making them hard to see < :) I didn't think much of the 3db bandwidth as such, but this document: As far as I know, there is usually a connection between vertical amplifier bandwidth and sweep rate. There would be little point in a high bandwidth amplifier if you couldn't see the result. Also, the possible sweep rate depends on the bandwidth of the horizontal amplifier which is likely similar to the vertical amplifier... < First you can see the probes at x1, volts/div is 2V, and power supply < voltage gets increased from 0 to about 5V. Then the probes get switched to < x10, volts/div to 0.2V, and the experiment repeated. The crystal is < connected directly to power supply, as well as the probe - there are no < other circuits in between. One of the probes measures the power supply < directly, the other measures the crystal oscillator output. Time/div is < 0.2us throughout. It would be usual for a 5V device to drive TTL output levels, and expect to be connected to devices with TTL input levels. I would have thought that TTL could drive a 1X probe, but a 10X will be a much better choice. (snip) < Again, my bad in clarifying - the only reason why I tried to power the < device with less, was that my original attempt to power it with 5V didn't < result in any oscillation at all (just a fixed 5V at output); which is why < I tried to power it directly from a lab voltage supply and then sweep the < power from 0V to 5V - which is when I noticed this "flipping" I believe someone mentioned bypass capacitors previously. The result of not having enough bypass is usually oscillation from circuits that aren't supposed to oscillate. I presume your board does have enough capacitors, but connecting the XO to a power supply through long wires may not have enough. It does seem that there is no explanation for it not working at all on the original board. (Unless the output shorts go +5V.) <> More likely: it's probably a 50 MHz 3rd overtone crystal that's <> oscillating on its fundamental at low VDD. < Interesting, was not aware of this effect - however, it does seem that < this "flipping" happens when the crystal changes its oscillation mode from < lower to higher frequency (as the voltage sweeps from higher to lower < values).. Yes, that is usual. Well, it was common in the days before packaged oscillators. Above about 20MHz the crystals are 3rd overtone. (Close to, but not exactly, 3 times the fundamental.) It is usual to add an LC circuit to help it start on the right mode. My first crystal project was trying to get an intel 80287 to run at 8MHz, which normally requires an 8284 and a 24MHz crystal. With the 24MHz crystal I had, and even with the LC circuit, it would not run at 24MHz. Finally, I found a 22MHz crystal that would run at 22MHz, and that was close enough for me. < And although I'm not sure whether it talks about the internal circuitry of < a crystal oscillator devices - or about components external to the crystal < oscillator device - here are some quotes from there which I think are < relevant : Most likely not so different from the way it used to be done. A crystal and some TTL circuitry. -- glenArticle: 142998
sdaau wrote: > Dear list, > > Thanks so much for the extensive comments!! > > >>...datasheet says: "Supply Voltage: 5V ±0.25V". >>All other bets are off. > > > I'm sorry, I forgot to clarify that initially, I put the crystal > oscillator in the board I'm making, powered with 5V - and got no > oscillation, only a straight 5V, on its output, which got me surprised; > which is why I decided to test it directly on the power supply. > Generally this means you did not connect the ground lead. You might also check to see if the oscillator has an enable pin. Depending on the oscillator, this can be active high or active low. > > >>My thoughts, and as the OP has suggested all's well at 90% of 5V, >>that the device is behaving as expected. >> >>I would expect a working range to be a little wider than specified >>range as indeed the OP experiences. > > > Sorry again - I was trying to say that things are actually not well at 5V > :) > The oscillator is just a transistor oscillator and it should oscillate over a wide range of voltages. The specs for things like stability are given at a specific voltage. > > >>You have left off aa lot of information from the pictures. X and Y >>settings would be nice. What is the bandwidth of the scope? Also, >>what is your power supply and how is it hooked up? >>Bypass capacitors are very useful and could be the issue. > > > I agree a lot of information has been left off, and sorry about that - so > I hope to clear out some misunderstandings below, with use of video.. > > > >>You say your 'scope can't resolve 50 MHz. I take it you mean the >>'scopes bandwidth is less than 50 MHz. Then the peak-to-peak >>amplitude will appear less than it really is; but the average / mean >>DC level will be correct. >> > > > When I said that the scope "can't resolve 50 MHz", what I meant, moreless, > is that the lowest time/div setting on the scope is 0.2 us = 200 ns. Period > for 50 MHz is 20 ns, which means that for a 50 MHz signal, 10 periods would > have to be squeezed into a single time div, thereby making them hard to see > :) I didn't think much of the 3db bandwidth as such, but this document: > If you have a 20MHz analog scope, the signal will be down at least 10db at 50MHz but it should still be visible. It will not give you any accurate reading. > "Choosing an Oscilloscope with the Right Bandwidth for your Application" - > Application Note 1588 > http://cp.literature.agilent.com/litweb/pdf/5989-5733EN.pdf > > pointed out (in very clear language for my taste, and with very nice > screenshots) why the scope bandwidth itself is important - especially when > measuring digital (ideally square) signals. Since a square wave ideally > contains only odd integer harmonics, for a fundamental frequency fo, the > next two harmonics will be 3*fo and 5*fo; for fo=50 MHz, I'd need at least > 5*fo=250 MHz in order to at least see more-less accurate rise time of a 50 > MHz square pulse. This is true if you want accurte measurements on the oscillator. You do not need this. > > So, let me clarify a few things which I may have left out from the OP. > > The analog oscilloscope is a Hameg HM205-3 ( > datasheet: > http://www.hameg.com/manuals.0.html?&tx_hmdownloads_pi1[mode]=download&tx_hmdownloads_pi1[uid]=821&cHash=27984f11ee > > or > http://www.hameg.com/typo3conf/ext/hm_downloads/pi1/download.php?fileName=fileadmin/user_upload/downloads/man/HM205-3_english.pdf&dlName=HM205-3_english.pdf > ) > and the datasheet states: "Frequency range: 2xDC to 20 MHz (-3 dB)". > > Anyways, I have now made a video (640x480) of the measurement process of > the XO with this scope - so I hope things will be clearer about the test > setup and measurement: > http://en.theorasea.org/story.php?title=XO-testing-1 > (or > http://theorasea.org/itheora/index.php?v=http://blip.tv/file/get/Sdaauk-XOTesting336.ogv&out=link > ) > (or http://blip.tv/file/2600075 for FLV format - the above use .ogv, if > you have trouble with showing ogv in your browser, just download the .ogv > file and use VLC to view it) > > First you can see the probes at x1, volts/div is 2V, and power supply > voltage gets increased from 0 to about 5V. Then the probes get switched to > x10, volts/div to 0.2V, and the experiment repeated. The crystal is > connected directly to power supply, as well as the probe - there are no > other circuits in between. One of the probes measures the power supply > directly, the other measures the crystal oscillator output. Time/div is > 0.2us throughout. > > I changed the probes from x1 to x10, expecting that their effective > impedance will change - and so will their influence on the crystal > oscllator. The behaviour is somewhat the same in both x1 and x10, although > x10 seems to show a somewhat bigger range of oscillation once the > oscillation mode "flips" as voltage is increased above 2.5V. > > I now also have an access to an Agilent 54621A, which is marked as 60 MHz > - according to the above Agilent PDF, it will be also inadequate for > measuring 50 MHz clock (square) signal, but at least it should show a > sinusoid ... and it does. In the following screenshots, channel 1 measures > output and channel 2 measures the power supply. > > On this Agilent scope, having the probes as x1 shows a small "flip" - > initially no oscillations, then first oscillations start at 2.06V (lower > freq), then flip at 2.75V (higher freq, lower amplitude) and continues in > that mode up to 5V. > > http://img198.imageshack.us/img198/9954/xo50x1agilent.png > > Having the probes as x10 results with a much smoother growth of output > with input (no "flipping" of the output range - but flipping again in terms > of frequency). Initially no oscillations, then first oscillations start at > 2V (lower freq), then flip at 3.0V (higher freq, higher amplitude) and > continues in that mode up to 5V. This says that the oscillator is correctly operating on the third overtone at 5v. > > http://img233.imageshack.us/img233/7994/xo50x10agilent.png > > Hopefully, I managed to clarify the behaviour I'm getting a bit better :) > > > > >>That is an interesting reason that I wouldn't have though of so fast. >>Then again, I wouldn't try running a 5V device at 2V. >> > > > Again, my bad in clarifying - the only reason why I tried to power the > device with less, was that my original attempt to power it with 5V didn't > result in any oscillation at all (just a fixed 5V at output); which is why > I tried to power it directly from a lab voltage supply and then sweep the > power from 0V to 5V - which is when I noticed this "flipping" > The flipping, as noted by others is the change in operating frequency from the change in overtone. > > >>Operating ANY device outside it's specified operating range >>results in UNDEFINED Device behavior. This is very true for optimized digital devices but for an analog oscillator is only approximately true. >> > > > True, I guess - but again my bad in clarification: I attempted to operate > the device outside its operating range, only because my initial attempt to > power it at 5V and get oscillations failed. > > >>>The oscillator is unlikely to work correctly at low VDD. If you're >>>seeing more amplitude at low VDD, then I would guess it's a low >>>frequency relaxation oscillation - not crystal controlled - at a >>>frequency much lower than 50 MHz. >>> >> >>More likely: it's probably a 50 MHz 3rd overtone crystal that's >>oscillating on its fundamental at low VDD. > > > Interesting, was not aware of this effect - however, it does seem that > this "flipping" happens when the crystal changes its oscillation mode from > lower to higher frequency (as the voltage sweeps from higher to lower > values).. > > > Related to this, I have also found the following document: > "Start up behaviour of the UAA3220TS crystal oscillator" > http://www.nxp.com/acrobat_download/applicationnotes/AN00085_1.pdf > > And although I'm not sure whether it talks about the internal circuitry of > a crystal oscillator devices - or about components external to the crystal > oscillator device - here are some quotes from there which I think are > relevant : > "in case the second relation, the so-called oscillation margin, is smaller > than 1, oscillation does not start up (pg 10)" > "For a given crystal resonator, with RM,max and C0, the oscillation margin > can only be improved when the load capacitance and the amplifier gain are > chosen as large as possible. The examples as given in Figure 7 and figure 8 > show that these goals cannot be achieved simultaneously; the amplifier > reaches its maximum gain only at low load capacitances and vice versa (pg > 17)" > "the oscillation margin strongly depends on the value of the static > capacitance C0 (pg 19)" > > > In all, seeing how different probe settings - and different scopes - tend > to influence the behaviour of the device, I'm sort of led to believe that > the how the crystal oscillates, depends on both the power supply and the > external components that the XO can see... which leads me to think that the > reason why it wouldn't oscillate in my board at 5V, was most likely > external capacitors (which is what I'll experiment with next :) ) > Or you have hooked it to a pin which is not an input. Or the enable is not connected. Or the ground is not connected. Check the basics first. > > Well, I'll appreciate any further comments on whether my understanding > gets to be more correct, > Thanks again for the fine discussion, > Cheers! > > > > --------------------------------------- > This message was sent using the comp.arch.fpga web interface on > http://www.FPGARelated.comArticle: 142999
Hi, I'm implementing real-time calibration of IR images in a FPGA (Virtex-4 FX). This is a 2-step (not simultaneous) process. The first step involves the "slow" PowerPC to calculate some parameters and store them in external ZBT ram. During the 2nd step, the content of the ZBT ram needs to be accessed at its maximum throughput (160 MHz in our case) by some DSP cores in the FPGA fabric to perform the actual calibration on the data stream. Latency is not an issue. My question is, is there an easy solution to acheive that kind of memory sharing? I'm thinking about the EDK Multi-Channel EMC controller but I'm afraid that I'll have issues to attain 160 MHz of sustained bandwidth. Furthermore, I need to access to full 36 bits of the ZBT ram (ideally). One more point, I have 4 of these ZBT rams and they all need to be accessed at their maximum throughput during the 2nd step. During the first step they can all share the "slow" OPB, that's not a problem. Thanks for any pointers!
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