Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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

Custom Search

Messages from 135350

Article: 135350
Subject: Re: 50 Ohm Analog Output of FPGA
From: "langwadt@fonz.dk" <langwadt@fonz.dk>
Date: Sat, 27 Sep 2008 12:22:04 -0700 (PDT)
Links: << >>  << T >>  << A >>
On 27 Sep., 19:32, rickman <gnu...@gmail.com> wrote:
> On Sep 23, 10:50 am, hei...@iname.com wrote:
>
> > > The low pass filter will not give you a sine wave.  It will
> > > approximate one, but with 20 MHz components on a 10 MHz signal, you
> > > will not be able to fully filter it out.
>
> > Is that because the FPGA will not generate a perfect square wave?
>
> > I purchased a DAC but it seemed like a waste to send 8 bits at a time
> > when there are really only two values. Anyway, thanks for the info.
>
> Why can't an FPGA output a "perfect" sine wave?
>
> It is because of the limitation of filters.  If you output a "perfect"
> square wave at 10 MHz, you will have harmonics at 30 MHz, 50 MHz, etc
> (ignore my 20 MHz comment above).  To get a good sine wave, you need
> to reduce these harmonic levels by more than 20 dB and more like 40
> dB.  To get 40 dB attenuation over a 3:1 frequency range requires one
> heck of a good filter.  That is why delta-sigma converters sample at
> much higher rates and interpolate or decimate.  By sampling at a freq
> much higher than the signal frequency, filters can be designed to give
> a better cut off.
>
> Rick

with a three step wave, e.g. high, tristate,low, two resistors and the
right timing it
should be possible to get no 3rd harmonic

-Lasse

Article: 135351
Subject: Re: Is it possible to get an RTL netlist from Xilinx tools?
From: doug <xx@xx.com>
Date: Sat, 27 Sep 2008 11:29:01 -0800
Links: << >>  << T >>  << A >>


thutt wrote:

> doug <xx@xx.com> writes:
> 
> 
>>thutt wrote:
>>
>>>David R Brooks <davebXXX@iinet.net.au> writes:
>>>
>>>
>>>>thutt wrote:
>>>>
>>>>
>>>>>Kevin Neilson <kevin_neilson@removethiscomcast.net> writes:
>>>>>
>>>>>
>>>>>
>>>>>>thutt wrote:
>>>>>>
>>>>>>
>>>>>>>Hello everyone,
>>>>>>>I'm tired of using the Xilinx ISE to look at RTL schematics, mainly
>>>
>>><snip>
>>>
>>>>>If there were a lookup table of initialization values to the standard
>>>>>'and / or / xor'-type logic that each represents, then it would be
>>>>>quite possible to write a script to make an external RTL viewer based
>>>>>on the technology netlist output by the Xilinx tools.
>>>>>
>>>>>Anyone game for a little sleuthing to determine all the LUT init
>>>>>codes?
>>>>>
>>>>
>>>>It's a bit harder than that. Assume a LUT has 4 inputs (it varies
>>>>with different FPGA families). The synthesiser (eg XST) will look
>>>>for a piece of combinatorial logic with 4 inputs & 1 output. It then
>>>>simulates that logic, evaluating its output for all 16 possible
>>>>input combinations. The initialisation string is simply the map of
>>>>those 16 outputs, written out in hex.  So there really isn't an
>>>>underlying logic representation: the designer might have specified
>>>>any Boolean function whatever (adder, parity tree, etc): the
>>>>synthesiser doesn't care.
>>>
>>>I'm more confused now.  Somehow the LUT must correspond to some
>>>concrete logic, and each LUT must be reconfigurable, right?
>>>How does the netlist indicate what logic is implemented in the LUT?
>>>If it's possible to determine that information, I'll be happy.
>>>
>>
>>A LUT is a 16x1 memory. It implements the truth table of the logic.
>>That is what is does.  The memory contents tell you the truth table
>>of the logic.  
> 
> 
> Your answer is not very descriptive.  *HOW* do the memory contents
> tell you the truth table?
> 
It is a 16x1 memory. The four inputs are the adress bits.  The output
is the truth table.

> Can one determine the memory contents from the initialization string?
> 
> 
>>The details of the logic are unimportant, the output is important.
>>That is what is implemented.  
> 
> 
> If you recall, my goal is only to produce a schematic of the RTL, so
> the details of the logic *ARE* improtant to me.
> 
If you want the bare logic for some reason, you need to work out a
set of gates that give you the truth table. That may be a bit of
work.  You could work out a set of truth tables of all possible
combinations of 1,2,3, and 4 inputs gates of all types in all
combinations and then search that but it seems like a lot of work.
> 
>>To make a schematic of this, just draw a 16x1 memory and list the
>>memory contents.
> 
> 
> Pray tell, how does one map the memory contents into the karnaugh map
> or the logic equations?

They have been collapsed into a truth table.  It is up to you to try
to get the logic gates back if it is important.  The memory contents
are much more descriptive of function since it has the truth table
for the four inputs.
> 
> thutt
> http://www.harp-project.com/
> 

Article: 135352
Subject: Re: 50 Ohm Analog Output of FPGA
From: "KJ" <kkjennings@sbcglobal.net>
Date: Sat, 27 Sep 2008 15:51:05 -0400
Links: << >>  << T >>  << A >>

<langwadt@fonz.dk> wrote in message 
news:d976369a-b3a5-4cc2-ac41-c5811e83dbe9@w7g2000hsa.googlegroups.com...
>
> with a three step wave, e.g. high, tristate,low, two resistors and the
> right timing it
> should be possible to get no 3rd harmonic
>

That third (and other) harmonics will still be there.

KJ 



Article: 135353
Subject: Re: Use of divided clocks inside modules
From: "Symon" <symon_brewer@hotmail.com>
Date: Sun, 28 Sep 2008 01:19:30 +0100
Links: << >>  << T >>  << A >>
Symon wrote:
> have more than enable, and so the tool needs to be told which is the

more than _one_ enable 



Article: 135354
Subject: Re: Clocking Sync Burst SRAM
From: Tommy Thorn <tommy.thorn@gmail.com>
Date: Sat, 27 Sep 2008 17:43:59 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Sep 26, 12:37=A0pm, jhal...@TheWorld.com (Joseph H Allen) wrote:
> You have to use a
> dedicated PLL feedback input pin for this to work. =A0This way is nice
> because you can usually leave the PLL phase shift setting at 0.

Thanks. This is a nice solution and I've used it on other projects.
Unfortunately, I didn't design Terasic's DE2-70 dev kit and it doesn't
have a feedback clock trace, so this isn't an option here.

Tommy

Article: 135355
Subject: Looking for Insight S2-PCI w/XC2S150 board documentation/manual
From: Totally_Lost <air_bits@yahoo.com>
Date: Sat, 27 Sep 2008 20:20:05 -0700 (PDT)
Links: << >>  << T >>  << A >>
Anybody got this in their library?

Thanks!

Article: 135356
Subject: Re: Looking for Insight S2-PCI w/XC2S150 board documentation/manual
From: Totally_Lost <air_bits@yahoo.com>
Date: Sat, 27 Sep 2008 21:07:40 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Sep 27, 9:20=A0pm, Totally_Lost <air_b...@yahoo.com> wrote:
> Anybody got this in their library?
>
> Thanks!

Mucho thanks for the email pointer to
http://web.archive.org/web/20010821020414/http://www.insight-electronics.co=
m/solutions/kits/xilinx/downloads/SpartanPCISchematics.PDF

would still be nice to find a pdf users manual and ucf file

Article: 135357
Subject: Re: Clocking Sync Burst SRAM
From: Tommy Thorn <tommy.thorn@gmail.com>
Date: Sat, 27 Sep 2008 22:52:28 -0700 (PDT)
Links: << >>  << T >>  << A >>
KJ, thanks for a detailed reply. It makes perfect sense, unfortunately
as detailed below I'm not sure it's all feasible for me to do this
analytically, but I feel more comfortable playing with phase shifting
of the clock.

On Sep 26, 12:14=A0pm, KJ <kkjenni...@sbcglobal.net> wrote:
> On Sep 26, 2:34=A0pm, Tommy Thorn <tommy.th...@gmail.com> wrote:
>
> > First, all output are fully registered (and constrained to guarantee
> > they stay registered). The main logic is clocked by a PLL. A second
> > but identically configured output on this PLL drives the SSRAM.
>
> Keep in mind though that there can easily be different delays from
> these two PLL outputs to the different destinations.

Opps. I had assumed they were phase locked and that the screw between
them would be small enough to ignore. Using just a single PLL doesn't
seem like it would help (?) as the on-die clock might be offset from
the clock at the pin.


> You'll need to know...
> - What is an achievable skew between the clock at the internal flops
> and the clock as it is leaving your controller.

Ok, but how do I find that? Browsing the Cyclone II data sheet didn't
reveal anything useful (unless I missed it).

>=A0In some sense it
> doesn't matter too much what that actual skew is, but you need to know
> what it is so that you can then add a timing constraint so that this
> delay is always met, or flagged as a timing error for you. =A0For the
> sake of an example, let's just say that that there is a skew of 1 ns
> between the internal clock and the clock at the output of the FPGA.
> Keep in mind that this skew will have both a minimum and a maximum so
> the skew is really a range between those two extremes.
>
> - Net lengths and capacitive loading of the signals on the PCBA that
> go between the two devices.

Ough. While that makes perfect sense, I simply don't think I have
enough information (or experience) to do that. Remember, this is an
off-the-shelf development kit and the provided examples do not even
use constraints. I do have the SSRAM datasheet which lists the Cin as
6 pF and Cout as 8 pF. Eyeballing the traces, they looks roughly an
inch long (the SSRAM sits very close to the FPGA).


>=A0What's important here is really
> differences between the various SRAM inputs and the clock. =A0From that
> you calculate an additional delay.

Again, eyeballing it, the clock trace looks near identical to most of
the data.

>=A0Practically speaking, you most
> likely have roughly equal net lengths and loading on all of the
> signals and this is not going to be a concern, but you should at least
> be aware of this as well. =A0Different parts may have different
> capacitive loading so if you want to get nit picky this delay will
> also be a range with a min and a max but that range will typically be
> much smaller than the uncertainty with the FPGA.
>
> From the FPGA clock skew min/max add on the additional delay for
> length/loading differences and now you have a known window of clock
> uncertainty. =A0Now get a piece of paper and sketch out some waveforms
> showing the min/max switching times of the control signals (i.e.
> address, oe, write, data_in, data_out) as well as the setup/hold time
> of both the SRAM and the FPGA (for the data coming back in). =A0Somebody
> was advertising a free timing waveform tool out here a few months back
> (I don't remember the name), that may help but it's not that difficult
> to paper sketch it either.
>
> From all of that you should come out with a sketch that shows where
> things need to be valid in order for the system to read and write
> properly. =A0Adjust the nominal phase of the clock leaving the device
> (or equivalently the FPGA internal clock) so that the clock occurs
> (both min and max time) at a point where everything is stable. =A0Keep
> in mind that as you shove the clock one way to improve setup time at
> the SRAM, you're most likely stealing that from the setup time at the
> FPGA when it is reading data back.

Exactly. Which is why I was weary of the advice I found multiple
places: phase shift the SSRAM clock by 180 degree.

> There can also be other concerns like if the nets are long you'll get
> ringing which distorts the waveforms which basically means that you'll
> need to wait a longer for things to stabilize which cuts into the
> allowable timing. =A0At 100 MHz, just 1 ns is 10% of the clock cycle
> budget. =A0Whether or not that's an issue or not you'll need to
> determine with a scope.

Thankfully this board appears to be well designed. I can already hit
170 MHz with my simple solution, but I'd like to push it to the limit
of the SRAM (200 MHz).

> > Phase-shift the SSRAM clock?
>
> Yes
>
> > Specify it as a timing constraint?
>
> Yes
>
> > Do timing constraints influence the output buffer or are they purely fo=
r
> > checking?
>
> For the most part it's just checking, although it can affect place and
> route as well. =A0I haven't seen a case where it affected the output
> buffer itself (i.e. kicked up or down the drive strength) in order to
> meet a constraint. =A0This is most likely because drive strength
> considerations have a much larger impact than just timing. =A0It does go
> the other way though, as you fiddle with drive strength the software
> should take this into account when it does the timing analysis.
>
> Since it appears from your constraint that you're using Quartus, you
> might want to put in numbers that are representative of the correct
> capacitive loading as well as checking that the I/O drive strengths
> are appropriate and not just the defaults (unless =A0you've already done
> this).

Ah, yes, I should do that. The pin capacitive loading I gave above.
I'm not sure how much I should estimate for the short trace. The DC
ELECTRICAL CHARACTERISTICS states this:

Output HIGH Voltage min 2.4 V (test cond I_OH =3D -4 mA)
Output LOW Voltage max 0.4 V (test cond I_OL =3D -8 mA)
Input HIGH Voltage min 2.0 V
Input LOW Voltage max 0.8 V
Input Leakage [-5 uA; 5 uA]
Output Leakage [-5 uA; 5 uA]

but doesn't explicitly mention an IO standard. I assume that LVTTL
(3.3 V) is a fine choice (the default?). Or is LVCMOS a better choice.

I guess I have no idea of how to pick a suitable drive strength.

Thanks again
Tommy

Article: 135358
Subject: Re: 50 Ohm Analog Output of FPGA
From: Allan Herriman <allanherriman@hotmail.com>
Date: 28 Sep 2008 10:00:50 GMT
Links: << >>  << T >>  << A >>
"KJ" <kkjennings@sbcglobal.net> wrote in news:Y8wDk.1655$Ws1.508
@nlpi064.nbdc.sbc.com:

> 
> <langwadt@fonz.dk> wrote in message 
> news:d976369a-b3a5-4cc2-ac41-c5811e83dbe9
@w7g2000hsa.googlegroups.com...
>>
>> with a three step wave, e.g. high, tristate,low, two resistors and the
>> right timing it
>> should be possible to get no 3rd harmonic
>>
> 
> That third (and other) harmonics will still be there.
> 
> KJ 

Indeed!

However, using two outputs with different weighting resistors it is
(more or less) possible to eliminate the troublesome 3rd and 5th
harmonics.

Here is the output pattern for each cycle of the "sine wave":

AB
10
11
11
10
01
00
00
01

The A output is weighted more strongly than the B output by a factor of 
(1 + sqrt(2)).

Regards,
Allan

Article: 135359
Subject: Re: 50 Ohm Analog Output of FPGA
From: David Tweed <dtweed@acm.org>
Date: Sun, 28 Sep 2008 12:21:04 -0400
Links: << >>  << T >>  << A >>
langwadt@fonz.dk wrote:
> with a three step wave, e.g. high, tristate,low, two resistors and the
> right timing it should be possible to get no 3rd harmonic

Assuming you're using the two resistors to create the "bias" level for
the tristate condition, yes, that could work, but the output impedance
of such a circuit would be jumping all over the place, creating other
issues.

A better solution is to use two totem-pole square wave digital outputs,
60 degrees out of phase and a resistor from each one to the analog output
node. The third harmonic (and *its* odd harmonics, such as 9th, 15th, etc.)
will be cancelled completely, and the filter will just have to deal with
the remaining ones, starting with the 5th and 7th.

With more outputs and more resistors, you can generalize on this concept
to cancel out more of the higher-order harmonics, although your ability
to match the resistors and/or get the precise values you need limits how
far you can practically take this scheme. For example, if you're using
1% resistors, the whole thing runs out of steam at about 13 outputs.

I did an extensive writeup about this for the Circuit Cellar "EQ quiz"
back in 2001, but unfortunately, it no longer seems to be available on
the web. Draw yourself some phasor diagrams and it shows the principle
pretty clearly. A simple way do drive such a circuit is with a "Johnson
counter".

-- Dave Tweed

Article: 135360
Subject: Re: 50 Ohm Analog Output of FPGA
From: Muzaffer Kal <kal@dspia.com>
Date: Sun, 28 Sep 2008 10:12:09 -0700
Links: << >>  << T >>  << A >>
On Sun, 28 Sep 2008 12:21:04 -0400, David Tweed <dtweed@acm.org>
wrote:
>I did an extensive writeup about this for the Circuit Cellar "EQ quiz"
>back in 2001, but unfortunately, it no longer seems to be available on
>the web. Draw yourself some phasor diagrams and it shows the principle
>pretty clearly. A simple way do drive such a circuit is with a "Johnson
>counter".
>
>-- Dave Tweed

Is it this one: 
http://archive.chipcenter.com/circuitcellar/december01/c1201eq.htm?

Article: 135361
Subject: Re: Clocking Sync Burst SRAM
From: KJ <kkjennings@sbcglobal.net>
Date: Sun, 28 Sep 2008 10:54:16 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Sep 28, 1:52=A0am, Tommy Thorn <tommy.th...@gmail.com> wrote:
> KJ, thanks for a detailed reply. It makes perfect sense, unfortunately
> as detailed below I'm not sure it's all feasible for me to do this
> analytically, but I feel more comfortable playing with phase shifting
> of the clock.
>

Well, the bottom line in the calculations will still be coming up with
a phase shift of the clock so you're poking around at what the correct
solution will be

>
> > Keep in mind though that there can easily be different delays from
> > these two PLL outputs to the different destinations.
>
> Opps. I had assumed they were phase locked and that the screw between
> them would be small enough to ignore. Using just a single PLL doesn't
> seem like it would help (?) as the on-die clock might be offset from
> the clock at the pin.
>

Some pins (actually one) will be better choices than others since they
are intended to be used as a PLL output pin.  Using other pins is not
necessarily a problem, just that you'll get more skew and have
somewhat less control of it.  But as you've discovered, there must be
some skew between the two otherwise your adjusting of the phase
wouldn't have made any difference (and it did).

> > You'll need to know...
> > - What is an achievable skew between the clock at the internal flops
> > and the clock as it is leaving your controller.
>
> Ok, but how do I find that? Browsing the Cyclone II data sheet didn't
> reveal anything useful (unless I missed it).
>

Peruse the timing reports of your design.  There should be something
saying what the delay to the output pin that goes to the SRAM is.
Here it can get a bit muddy depending on whether you're using the
'Classic' timing analyzer or 'TimeQuest' but what you're trying to
determine should be in the timing reports.

What you do with that delay min/max numbers is use it to set a timing
constraint that it will now have to always meet and also use that
constraint to figure out what the phase shift is needs to be on the
internal clock so that everything hangs together.  It may sound kind
of backwards using the result of a run to figure out what the
constraints needs to be but it's not really.  Ideally you would like
there to be 0ns skew at the clock output pin, but if the software
can't deliver that then what?  At the end of the day, the absolute
value of the delay doesn't matter since that gets accomodated for by
changing the PLL phase delay, what hurts the most is the difference
between the min and the max of that delay (again, available from the
timing reports).  The spread between min and max is something that
can't be designed around and is something that will be tighter if the
'pll_out' pin is used.  I'm not sure if the board you're using did
this, but it's easy enough to check...nothing you can do about it, but
might be worth knowing.

>
> > - Net lengths and capacitive loading of the signals on the PCBA that
> > go between the two devices.
>
> Ough. While that makes perfect sense, I simply don't think I have
> enough information (or experience) to do that. Remember, this is an
> off-the-shelf development kit and the provided examples do not even
> use constraints. I do have the SSRAM datasheet which lists the Cin as
> 6 pF and Cout as 8 pF. Eyeballing the traces, they looks roughly an
> inch long (the SSRAM sits very close to the FPGA).
>

That's good.  Trace delays is ~6 inch per ns so round trip delay from
FPGA to SRAM and back (as you would have during an SRAM read) would be
< 1/3 ns which is pretty small (~3% of the overall clock cycle).

> >=A0What's important here is really
> > differences between the various SRAM inputs and the clock. =A0From that
> > you calculate an additional delay.
>
> Again, eyeballing it, the clock trace looks near identical to most of
> the data.
>

That's good too.

>
> > From all of that you should come out with a sketch that shows where
> > things need to be valid in order for the system to read and write
> > properly. =A0Adjust the nominal phase of the clock leaving the device
> > (or equivalently the FPGA internal clock) so that the clock occurs
> > (both min and max time) at a point where everything is stable. =A0Keep
> > in mind that as you shove the clock one way to improve setup time at
> > the SRAM, you're most likely stealing that from the setup time at the
> > FPGA when it is reading data back.
>
> Exactly. Which is why I was weary of the advice I found multiple
> places: phase shift the SSRAM clock by 180 degree.
>

180 degrees means you're inverting the clock.  While that's an easy
technique, giving up half of a 10 ns clock period will likely end up
in still failing timing.  It's best to figure out based on the Tco of
the outputs, the skew of the clocks and the setup and hold times just
where the clock can be placed.  If it happens to be that an inverted
clock would work, OK.  If not, your analysis will show just where it
can be placed.  Again, ideally you would like the FPGA and the SRAM to
both receive the clock at exactly the same time, that will give you
the most margin.

>
> Thankfully this board appears to be well designed. I can already hit
> 170 MHz with my simple solution, but I'd like to push it to the limit
> of the SRAM (200 MHz).
>

Pushing to the limit usually just means that some extra analysis work
is needed in order to make the design solid.  That's all that is going
on here.

> > Since it appears from your constraint that you're using Quartus, you
> > might want to put in numbers that are representative of the correct
> > capacitive loading as well as checking that the I/O drive strengths
> > are appropriate and not just the defaults (unless =A0you've already don=
e
> > this).
>
> Ah, yes, I should do that. The pin capacitive loading I gave above.
> I'm not sure how much I should estimate for the short trace. The DC
> ELECTRICAL CHARACTERISTICS states this:
>
> Output HIGH Voltage min 2.4 V (test cond I_OH =3D -4 mA)
> Output LOW Voltage max 0.4 V (test cond I_OL =3D -8 mA)
> Input HIGH Voltage min 2.0 V
> Input LOW Voltage max 0.8 V
> Input Leakage [-5 uA; 5 uA]
> Output Leakage [-5 uA; 5 uA]
>
> but doesn't explicitly mention an IO standard. I assume that LVTTL
> (3.3 V) is a fine choice (the default?). Or is LVCMOS a better choice.
>
> I guess I have no idea of how to pick a suitable drive strength.
>

LVTTL is the voltage standard (LVCMOS will be essentially the same).
There is another setting for drive strength, look for something
measured in mA.  Since it sounds like the PCBA design has no obvious
problems, set the drive strength to the max (likely 24mA).

Kevin Jennings

Article: 135362
Subject: Re: 50 Ohm Analog Output of FPGA
From: David Tweed <dtweed@acm.org>
Date: Sun, 28 Sep 2008 14:35:00 -0400
Links: << >>  << T >>  << A >>
Muzaffer Kal wrote:
> On Sun, 28 Sep 2008 12:21:04 -0400, David Tweed <dtweed@acm.org>
> wrote:
>> I did an extensive writeup about this for the Circuit Cellar "EQ quiz"
>> back in 2001, but unfortunately, it no longer seems to be available on
>> the web. Draw yourself some phasor diagrams and it shows the principle
>> pretty clearly. A simple way do drive such a circuit is with a "Johnson
>> counter".
> 
> Is it this one: 
> http://archive.chipcenter.com/circuitcellar/december01/c1201eq.htm?

Yes, that's it. Thanks! I'll have to update some links ...

-- Dave Tweed

Article: 135363
Subject: Re: Clocking Sync Burst SRAM
From: nico@puntnl.niks (Nico Coesel)
Date: Sun, 28 Sep 2008 20:14:57 GMT
Links: << >>  << T >>  << A >>
jhallen@TheWorld.com (Joseph H Allen) wrote:

>There are a number of ways to do this.  Here is one way:
>
>What you usually want is for the clock at the pin of the SRAM chip to rise
>at the same time as the FPGA internal global clock driving the output pads.
>
>A way to do this is to route the clock from the second PLL to two output
>pins (right next to each other).  One pin goes to the SSRAM.  The other pin
>goes to the feedback input of the PLL.  The trace length for this feedback
>line should be the same as the one which goes to the RAM.  You have to use a
>dedicated PLL feedback input pin for this to work.  This way is nice because
>you can usually leave the PLL phase shift setting at 0.

This is quite cumbersome and the PLL will add extra jitter (clock
uncertainty). An easier way without the extra jitter is to use an
output flipflop (aka DDR flipflop) which can be clocked using 2
clocks. The first clock sets the output, the second clock (inverted
first clock) resets the output. And presto, you'll have a clock output
which is (within pin-to-pin skew) perfectly synchronous to the other
outputs.

-- 
Programmeren in Almere?
E-mail naar nico@nctdevpuntnl (punt=.)

Article: 135364
Subject: Re: Clocking Sync Burst SRAM
From: "KJ" <kkjennings@sbcglobal.net>
Date: Sun, 28 Sep 2008 16:29:29 -0400
Links: << >>  << T >>  << A >>

"Nico Coesel" <nico@puntnl.niks> wrote in message 
news:48dfe4ee.168426254@news.planet.nl...
> jhallen@TheWorld.com (Joseph H Allen) wrote:
>
> An easier way without the extra jitter is to use an
> output flipflop (aka DDR flipflop) which can be clocked using 2
> clocks. The first clock sets the output, the second clock (inverted
> first clock) resets the output. And presto, you'll have a clock output
> which is (within pin-to-pin skew) perfectly synchronous to the other
> outputs.
>

Hold time requirements (like the .4ns in the OP) will be impossible to 
guarantee with this method though.

KJ 



Article: 135365
Subject: Difference between PLD and General purpose CPU`
From: onwuka.arisa@gmail.com
Date: Sun, 28 Sep 2008 19:05:10 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hello All,

Please i am doing a research that invloves PLD's. Can one please tell
me the difference between a PLD whether( FPGA,CPLD,GAL or PAL) and a
general purpose CPU



Article: 135366
Subject: Low frequency clock generation - need help
From: vlodiya@gmail.com
Date: Sun, 28 Sep 2008 19:55:43 -0700 (PDT)
Links: << >>  << T >>  << A >>
Guys,

      I am designing a conventional Digital down converter on virtex
-4 Sx55 FPGA for GSM applications.

The Input clock frequency is above 160 Mhz for the initial CIC
decimation filter. After decimation , the data is fed to low pass
filter at a very low rate of ~1 Mhz

The issue is ,I am not able to generate this low frequency clcok with
Virtex -4 DCM , obviously the min output frequency is 32 Mhz.

After I looked into the previous threads , i dont feel its a clean way
to generate the divided clock by internal clock divider or clock
gating circuit in FPGA .

Can anyone let me know any other way of generating the low frequency
clock or is it safe to use internal clock divider considering my
asynchronous design ( FIFO between each filter stage)  ?

Iam using the latest FIR compiler to generate the LP filter core. but
i do see the option of  input sample  per no of  clock cycles in
previous Distributed FIR core which made life easy. but the FIR
compiler core doesnt have this option.

Please advice

Thanks in Advance

Vijay





Article: 135367
Subject: Re: Low frequency clock generation - need help
From: Peter Alfke <alfke@sbcglobal.net>
Date: Sun, 28 Sep 2008 20:23:41 -0700 (PDT)
Links: << >>  << T >>  << A >>
Vjay,
If you need to generate a low frequency that is an integer fraction of
your incoming clock frequency, then you just build a synchronous
divider, and you get an output frequency that has its edges aligned
with your incoming clock, but one clock-to-Q delay later.
Your concern may be the phase alignment between the fast clock and the
slow clock. If that is critical, just use the synchronous integer
divider, and rely on the fact thet the edges of the slow frequency are
very slightly later than the rising edge of the high frequency, say 2
or 3 ns max.
You might alteratively use the fast clock to also do the slow
clocking, but with a control signal disabling the clock most of the
time. That gives you a totally synchronous system (with slightly
higher power consumption)
If the ratio is not an integer, then you can use the DCM to do some
multiply/divide operation, followed up by an integer divider, For
example, you can use the DCM to multiply 160 MHz by 17 and
simultaneously divide it by 27, and follow that up by any integer
division. Obviously, the phase relationship between the clocks is then
an unontrolled variable, but that is unavoidably part of your
assumptions.
Peter Alfke, on Sunday watch from home. Old habits never die.


Article: 135368
Subject: Re: OFDM band switch ...
From: "jerzy.gbur@gmail.com" <jerzy.gbur@gmail.com>
Date: Mon, 29 Sep 2008 00:13:14 -0700 (PDT)
Links: << >>  << T >>  << A >>
On 27 Wrz, 21:02, "Kappa" <NO_SPAM_78kapp...@virgilio.it_NO_SPAM>
wrote:
> Hi Jerzy Gbur.
>
> > I'm not sure I understood. But what I propose is, for narrow band set,
> > for example [0 - 511 Data] [512 - 1535 Nul] [1536 - 2047 Data], It
> > depend what band you exactly want.
> > Lenght of IFFT transform should stay the same.
>
> I still do not understand ... how can I reduce the number of carriers if I
> have to maintain a "Standard" ?
>

I'm sorry. You can't maintain  a standard that way,
I thougt you are building own system, undependly of standards.
You have to switch clock.

Regards,

Jerzy Gbur

Article: 135369
Subject: Re: Difference between PLD and General purpose CPU`
From: Kolja Sulimma <ksulimma@googlemail.com>
Date: Mon, 29 Sep 2008 02:51:12 -0700 (PDT)
Links: << >>  << T >>  << A >>
On 29 Sep., 04:05, onwuka.ar...@gmail.com wrote:
> Hello All,
>
> Please i am doing a research that invloves PLD's. Can one please tell
> me the difference between a PLD whether( FPGA,CPLD,GAL or PAL) and a
> general purpose CPU

The CPU uses instructions of a few bits (4 to 64 bits, depending on
the architecture) to configure its behaviour on a cycle by cycle
basis. Only a few specialized operations like additons and comparisons
can be performed in every cycle. Complex behaviour is obtained by
issuing billions of these simple instructions per second.

An FPGA is configured using a few million bits that can describe
almost arbitrary behaviour in much detail. This can be seen as one big
complex instruction. However, a
conventional FPGA is then bound to this instruction (called
configuration) and executes the same instruction over and over again.
Issuing a new instruction takes tens of milliseconds.

There have been experimental FPGAs (e.g. DPGA at MIT) that allow to
switch between a small number of instructions on a cycle to cycle
basis.

Kolja Sulimma

Article: 135370
Subject: Re: Low frequency clock generation - need help
From: "Symon" <symon_brewer@hotmail.com>
Date: Mon, 29 Sep 2008 11:01:46 +0100
Links: << >>  << T >>  << A >>
vlodiya@gmail.com wrote:
> Guys,
>
>      I am designing a conventional Digital down converter on virtex
> -4 Sx55 FPGA for GSM applications.
>
> The Input clock frequency is above 160 Mhz for the initial CIC
> decimation filter. After decimation , the data is fed to low pass
> filter at a very low rate of ~1 Mhz
>
> The issue is ,I am not able to generate this low frequency clcok with
> Virtex -4 DCM , obviously the min output frequency is 32 Mhz.
>
Hi Vijay,
You don't need to generate a 1MHz clock, instead you should generate a 1MHz 
clock enable for the parts of your design that run at 1MHz. The whole design 
is clocked at 160MHz, but the slow part is only enabled for one cycle in 
160. This makes it a trivial task to pass data between the domains of the 
design.
Cheers, Syms. 



Article: 135371
Subject: Sending UDP packets over Ethernet
From: Fred <fred__bloggs@lycos.com>
Date: Mon, 29 Sep 2008 08:10:36 -0700 (PDT)
Links: << >>  << T >>  << A >>
I've been tasked to write some code for an FPGA to interface to 10BASE-
T Ethernet using differential drivers and receivers.

The information is one way, transmit only!  I will have an IP address
within the network range, give myself a MAC number and know the MAC
and IP address of the destination PC.

Do I require any ARP or any other protocol?  Will it just work, with
the destination PC receiving UDP packets?

Fred

Article: 135372
Subject: Re: Sending UDP packets over Ethernet
From: Benjamin Krill <ben@codiert.org>
Date: Mon, 29 Sep 2008 17:15:16 +0200
Links: << >>  << T >>  << A >>
Hi,

On Mon, 2008-09-29 at 08:10 -0700, Fred wrote:
> Do I require any ARP or any other protocol?  Will it just work, with
> the destination PC receiving UDP packets?

You have to include the FPGA host (mac and ip) into the ARP table of the
host PC. Then you didn't need to implement the ARP protocol.

Ben


Article: 135373
Subject: Re: Sending UDP packets over Ethernet
From: "Symon" <symon_brewer@hotmail.com>
Date: Mon, 29 Sep 2008 16:16:33 +0100
Links: << >>  << T >>  << A >>
Fred wrote:
> I've been tasked to write some code for an FPGA to interface to
> 10BASE- T Ethernet using differential drivers and receivers.
>
http://www.fpga4fun.com/10BASE-T.html 



Article: 135374
Subject: Re: Sending UDP packets over Ethernet
From: cs_posting@hotmail.com
Date: Mon, 29 Sep 2008 08:34:34 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Sep 29, 11:15 am, Benjamin Krill <b...@codiert.org> wrote:

> You have to include the FPGA host (mac and ip) into the ARP table of the
> host PC. Then you didn't need to implement the ARP protocol.

I don't think that will be needed, since the PC is not expected to
reply.

I suppose there might be software on the PC that would consider this
"traffic from nowhere" suspicious and possibly forged, but that's a
configuration problem, not a fundamental one.




Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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

Custom Search