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 107550

Article: 107550
Subject: Re: JOP as SOPC component
From: "Martin Schoeberl" <mschoebe@mail.tuwien.ac.at>
Date: Wed, 30 Aug 2006 02:50:05 +0200
Links: << >>  << T >>  << A >>
> After the question "How is the great complexity handled?"  You answered with "The switch fabric is in charge to connect those 
> different devices and perform the necessary conversion"  This is generally not quite the case.  It is up to the Avalon slave 
> design to perform the necessary conversions (I

mmh, as far as I understand it you can provide any master or
slave implementation that follows the rule of Avalon: From
a very simple asynchronous device to a pipelining device.
The generated switch fabric will provide the adaption.

> proprietary Altera design, or are there open source implementations available?"  The switch fabric itself can easily be written, 
> it is on the order of six lines of code per interface for a point to point connection, there is nothing really magic in what 
> Altera spits out of SOPC Builder based

I think that this is actually the power of SOPC builder. It will
do all your glue logic stuff for the interconnect (address
decoding, byte order managing, byte enable on write,...).

And that's a lot more than 6 lines of code ;-)

> an open source version of this connection logic, but whether simple use of the Avalon bus without also targetting an Altera device 
> (even if no Altera software is involved) is violating anything is an open legal question as you've pointed out (I'm guessing that 
> it might but not really sure).

AFAIK the bus definition is kind of open-source - free. However,
I'm sure you're not allowed to use the SOPC builder generated
VHDL code on a Xilinx device ;-)
BTW: I asked Altera Austria about a related topic: Is it allowed
to 'use' the DRAM controller in an open-source environment (means
can I upload the VHDL code to a web server). However, they had
no real answare to this. They sayed that the SDRAM controller
does is part of NIOS and does only work with NIOS. Therefore,
one has to buy a NIOS license. But it works quite well with JOP
too ;-)

> Section 2
> In the paragraph starting "The third issue is..." you ask the question "Why not force the slaves to hold the data on the output 
> registers as long as there is no new transaction?"  A couple follow up questions to that though would be
> - What is a SimpCon slave to do if there IS a new transaction before the old one has been acknowledged?

good question ;-) It depends on the pipeline level. It can accept
it. But this is not directly related on the request to 'just'
keep the data valid until a newer one is available (and was
requested).

> - Does the SimpCon fabric prevent this from happening?  (I think it does, but not exactly sure)

It is the master who decides when to issue a new request
and when to leave the slave with the last data.

> Personally, I'm still a bit confused about just exactly which pipeline on the master side is 'released' when rdy_cnt hits the 
> magic number and how that differs from releasing the Avalon master address/command pipeline via waitrequest and releasing the 
> Avalon master readdata pipeline via

From the pure pipelining point of view there is not so much
difference between Avalon and SimpCon. Both can do pipelining
when the slave supports it. The pipeline level in Avalon is
not restricted (and not so obvious to see). In SimpCon with
the 2 bit rdy_cnt the pipeline level is restricted.

> it's not totally the master address/command that is being released but 'something' on the JOP master for kick starting the data 
> processing pipeline based on the read data actually becoming available (and getting 'early' notice of this).

the early notice is the little thing I like on my design: It helps
a pipelined master waiting on data *and* performs the flow control
for the pipelining. Perhaps too much information for a singel
2 bit signal. However, I like less signals. See the OPB spec.
for the extreme different way to do it: They have way too many
signals defined - I don't like to read so many signal definitions ;-)

> having the master 'know' the latency about the 'slave' would seem to be cheating (since this wasn't required by the SimpCon 
> implementation as I had thought) but I guess I'll fall back to what Tommy mentioned earlier that since JOP was optomized for 
> SimpCon in the first place it implies that an Avalon/SimpCon bridge must be built and such bridges can tend to be either

about cheating and bridge: I'm allready cheating on the Avalon
interface (as mentioned in an earlier post) to generate the
address/control/data holding in the master - I switch between
the original single cycle register at the first cycle
and a hold register on the following cycles - that's not
allowed in the original spec.

Bridges are a difficult topic: In the general case you add
latency cycles.

> be).  Had JOP been optomized for Avalon to begin with would the numbers be any better without any cheating?  That's sort of the 
> open question and I'm not necessarily expecting an answer.

Mmh, hard to say. I implemented the memory interface without
any SoC interconnect in mind - just tried to get the best
performance on SRAMs. The bus thing came very late in the
design. So it looks like I'm now defining a bus that 'fits'
to the way the original memory interface of JOP was.
However, perhaps that's not that bad as a new idea for a
differnt bus comes up ;-)

> My main interest in the thread was in understanding what sort of bottlenecks might be lurking in Avalon that I'm not aware of.  A 
> couple areas of 'possible' weakness for Avalon that I am aware of are:
> - It can hang (there is no requirement for a max time for a cycle). Something to be aware of, but generally not an issue since 
> whoever is designing the slave components had better address this and not allow for a hang to occur.
> - No notion of a 'retry'.  Again, given the environment of being on a chip, the slave design shouldn't be allowe to say 'try again 
> later please' so I don't think this should be an actual design issue, just something to be aware of.

Implementing those two features makes your bus (and interfacing)
way more complicated. AFAIK OPB does it, but you end up with
so many signals...

> - Can't have pending reads from multiple slaves.  I suppose this could be important to some, it hasn't for me.

That's more an issue of the interconnect logic and not the
bus definition.

>
> Just curious, Figure 7 shows pipelined reads from a static RAM where a new address is presented on every other clock cycle which 
> matches the performance of the actual SRAM.  If the device had been an external DRAM/DDR

That's just the 2 clock access time SRAM example.

> or such, you can clock out a new read command on every clock cycle even before you get the first data item back.  After the data 
> from that first

You can do single cycle pipelined read with a latency of two
cycles (compared to just a single one in AMBA AHB). Perhaps
I should provide that example too. When the slave supports it
you can issue a new read request when rdy_cnt is 2. When
you do it than rdy_cnt will stay at 2 - the 2 cycle pipelining.

> Like I said, nothing major just minor things.  SimpCon can be the answer to certain bus issues, Avalon, Wishbone, VSIA may be the 
> answer to others. It's good to have choices.
yep ;-)

BTW: I don't know VSIA. Any link to it?

> Fine by me...by the way, I wouldn't consider the exchanges in the thread to be either 'heated' (as mentioned by Tommy) or 
> 'controversial' (since I don't see what the controversy was).  It was interesting and civil, the large number of back and forth 
> that remained on topic would seem to indicate that.....'heated' and 'controversial' seems to occur when mention of 'asynchronous 
> resets' or 'coding style of state machines' is the topic.

Completely agree - will remove this 'controversal' as this thread
is more 'constructive'.

Cheers,
Martin 



Article: 107551
Subject: Re: placing addiional caps across existing caps to reduce noise
From: "rickman" <gnuarm@gmail.com>
Date: 29 Aug 2006 18:11:55 -0700
Links: << >>  << T >>  << A >>
Most of what you said goes against what was taught in the class I just
took.  This information was presented in theory, demonstrated in
simulation and then proven with measurements.

Symon wrote:
> So, here's my thoughts.
>
> If we have two caps of different values, but the same package/inductance,
> there's a frequency between the SRF of the caps that has a parallel
> resonance which leads to a peak in the impedance. For example, C1, a 1uF
> 0402 has a SRF of 10MHz. C2, a 0.1uF 0402 has a SRF of 25MHz. Between 10 MHz
> and 25MHz, C1 looks inductive and C2 capacitive. This means there's a peak
> in the impedance. So, the stragegy of using different values to 'even out'
> the impedance gives us peaks (bad) and troughs (good) in the impedance
> across the frequency spectrum.

Having a peak is not bad if it is still below the max impedance you are
trying to achieve.

> However, for a 0.1uF 0402 cap, at resonance the ESR is 0.014R, so the Q of
> the tuned circuit is about 5. For a 0402 1uF cap, the ESR at resonance is
> 0.01R, giving a Q of 2. These values of Q are so low as to make the self
> resonance problem/advantage make bugger all difference. Note that a 10nF
> 0402 cap has a Q of about 3 at its SRF of 70MHz.

Yes, this is why you need to use lossy caps and not low ESR caps.  This
is very important.  But if you use just one value of cap such as 0.1
uF, you will likely see a much higher peak than you can tolerate.  The
peak will be reduced by using more of them, or you can use a second or
third value of capacitance to end up with a series of closely spaced
peaks and troughs that are much lower than you will get with a single
value of cap.  You can also use a lot fewer parts.

> BTW, I got the cap data from here http://www.murata.com/designlib/mcsil.html
>
> (Also, note that the vias/traces to connect these caps probably double the
> inductance, reducing the SRF by 30%)

You should have data to back this up, not speculation and BTW, what
traces? If you are connecting the caps with traces you have already
lost the battle.  The experimental data shows the added inductance of
the via is not a significant factor in the overall picture when you use
multiple values to even out the inpedance over frequency.


> As for the 'plane capacitance', it starts to have an effect at frequencies >
> 1GHz which is a fat lot of good when our vias and BGA balls have inductances
> in the nH region. Remember, we're not trying to bypass the power plane,
> we're trying to bypass the IC.

Again you should have data on hand before you speculate.  In the
Ritchey book data is provided to show that the impedance of a closely
spaced power/ground plane pair is lower than the typical capacitors
around 100 MHz.  Of course this depends on the size and construction of
the board.  But clearly the region of importance is much lower than 1
GHz.

In addition, the impedance of your package leads has no bearing on the
power decoupling.  No amount of capacitace external or internal to the
device will have any impact on the bounce that will be caused by power
lead inductance.  The only cure for that is a new package.


> In conclusion, mixing different values of ceramic caps in the same packages
> might help a little but might hurt a little in a real system with FPGAs. I
> maintain that using the biggest value in the size you choose is the best, if
> nothing else because they have the crappest Q and this avoids BOM bloat. If
> we do use a range, bully for us, we probably won't notice any difference,
> but we have more chances for resonance and EMI failures.

This is not borne out by the facts.  If you can get your hands on
Richey's book I would suggest that it is a valuable addition to any
library on SI and EMI.  His volume 2 will cover EMI in more detail and
I am looking forward to it.


> Finally, I agree that the positioning of the cap is of lesser importance.
> However, some of us prefer not to waste layers in our stacks on power
> planes, we prefer to have decent grounds and route our FPGA power on layers
> used for signals in other places. The HF plane capacitance is pissed away by
> the chip mounting interconnect anyway, and its high Q might lead to evil
> resonances. (As you mention in your posts, Rick.) In this case, with little
> mini-planes for power routing, capacitor placement is crucial. (Note. With
> FPGAs needing at least 3 supplies, and maybe a lot more, the PCBs are
> getting very expensive with planes for every supply.)

Wow!  If your design is not high speed and the edge rates are not very
fast, then power distribution is not a big deal.  But nearly everything
in this paragraph is incorrect.  Yes, power planes cost money, that is
true.  Now that I understand how simple it is to figure out how power
distribution works, I would never use any of these ideas on a board
where I needed good noise margin or had high speed signals.

BTW, I never said a high Q power plane pair is bad.  Yes, it can create
impedance holes at very high frequencies, but the alternative for your
approach would raise the floor, not lower the ceiling.


> In conclusion, for FPGA PCBs,
> Lots of ground layers, one for every two signal layers.
> One value of cap per size.
> Use lots of caps. It means less impedance.
> Power planes only need extend as far as the bypass caps. So, closer the caps
> to the target device, the less plane needed.
>
> IMHO, YMMV, HTH, Syms.
>
> p.s. It's easy to simulate this stuff, try the excellent and free LTSpice
> from
> http://www.linear.com/company/software.jsp
> (as recommended by Bob, thanks!)
> p.p.s. Let me underline, _other_ways_work_too_ , but I'm happy with this
> methodology, and I don't think other solutions work noticeable better.

Have you tried simulating any of this?  I would like to know what
results your methods produce.  The question is not so much if a method
has worked a few times for you, but do you *know* it is going to work
before you build the board.  Ritchey's method lets you *know* it will
work right the first time.


Article: 107552
Subject: Re: placing addiional caps across existing caps to reduce noise
From: "rickman" <gnuarm@gmail.com>
Date: 29 Aug 2006 18:20:47 -0700
Links: << >>  << T >>  << A >>
I can take your word for your results as I don't understand any of the
code you posted.  But this simulation is not of a power distribution
system.  Try adding a power plane and just one value of cap (the 0.1uF
is what you suggested IIRC) and simulate up to 200 MHz or so.  I think
you will find that you get a *huge* parallel resonance peak from the
two.  If you add a few 0.01 uF caps this peak will be split in two and
the highest will be much smaller.  Then add a few more 0.001 uF caps
and you will see the peaks reduced further.  It also helps if you use
caps with a low Q factor or high ESR (relatively speaking).  But then
at 0.1 uF, I don't think you will find a C0G so X7R should be fine.

Symon wrote:
> OK, here's a LTSpice file that shows a resonance between disimilar cap
> values. The circuit sweeps from 5MHz to 45MHz back and forth. The first
> three sweeps are done with two 1uF caps, the second three with a 1uF and a
> 0.1uF cap. Notice the big resonance at about 10MHz for the second set of
> sweeps. The performance of the second circuit is slightly better at 45MHz,
> worse at 5MHz, MUCH worse at 10MHz.
> HTH, Syms.
> 
> Version 4
> SHEET 1 1516 904
> WIRE 1040 432 800 432

....snip...


Article: 107553
Subject: Re: placing addiional caps across existing caps to reduce noise
From: "Symon" <symon_brewer@hotmail.com>
Date: 30 Aug 2006 03:31:16 +0200
Links: << >>  << T >>  << A >>
"rickman" <gnuarm@gmail.com> wrote in message
news:1156900315.566413.232720@p79g2000cwp.googlegroups.com...
> Most of what you said goes against what was taught in the class I just
> took.  This information was presented in theory, demonstrated in
> simulation and then proven with measurements.
>
>
> Symon wrote:
> > So, here's my thoughts.
> >
> > If we have two caps of different values, but the same
package/inductance,
> > there's a frequency between the SRF of the caps that has a parallel
> > resonance which leads to a peak in the impedance. For example, C1, a 1uF
> > 0402 has a SRF of 10MHz. C2, a 0.1uF 0402 has a SRF of 25MHz. Between 10
MHz
> > and 25MHz, C1 looks inductive and C2 capacitive. This means there's a
peak
> > in the impedance. So, the stragegy of using different values to 'even
out'
> > the impedance gives us peaks (bad) and troughs (good) in the impedance
> > across the frequency spectrum.
>
> Having a peak is not bad if it is still below the max impedance you are
> trying to achieve.
>
But it's better not to have it, right?
>
> > However, for a 0.1uF 0402 cap, at resonance the ESR is 0.014R, so the Q
of
> > the tuned circuit is about 5. For a 0402 1uF cap, the ESR at resonance
is
> > 0.01R, giving a Q of 2. These values of Q are so low as to make the self
> > resonance problem/advantage make bugger all difference. Note that a 10nF
> > 0402 cap has a Q of about 3 at its SRF of 70MHz.
>
> Yes, this is why you need to use lossy caps and not low ESR caps.  This
> is very important.  But if you use just one value of cap such as 0.1
> uF, you will likely see a much higher peak than you can tolerate.  The
> peak will be reduced by using more of them, or you can use a second or
> third value of capacitance to end up with a series of closely spaced
> peaks and troughs that are much lower than you will get with a single
> value of cap.  You can also use a lot fewer parts.
>
> > BTW, I got the cap data from here
http://www.murata.com/designlib/mcsil.html
> >
> > (Also, note that the vias/traces to connect these caps probably double
the
> > inductance, reducing the SRF by 30%)
>
> You should have data to back this up, not speculation and BTW, what
> traces? If you are connecting the caps with traces you have already
> lost the battle.  The experimental data shows the added inductance of
> the via is not a significant factor in the overall picture when you use
> multiple values to even out the inpedance over frequency.
>
So, you loaded up the LTSpice simulations I posted, right? That's not
speculation. And no, you haven't lost the battle with a few tiny traces, the
vias are the bad guys as they give you loop area.
>
> > As for the 'plane capacitance', it starts to have an effect at
frequencies >
> > 1GHz which is a fat lot of good when our vias and BGA balls have
inductances
> > in the nH region. Remember, we're not trying to bypass the power plane,
> > we're trying to bypass the IC.
>
> Again you should have data on hand before you speculate.  In the
> Ritchey book data is provided to show that the impedance of a closely
> spaced power/ground plane pair is lower than the typical capacitors
> around 100 MHz.  Of course this depends on the size and construction of
> the board.  But clearly the region of importance is much lower than 1
> GHz.
>
> In addition, the impedance of your package leads has no bearing on the
> power decoupling.  No amount of capacitace external or internal to the
> device will have any impact on the bounce that will be caused by power
> lead inductance.  The only cure for that is a new package.
>
So, you advocate decoupling the power plane without considering what effect
this has on the IC? Why would you go to all that effort if the package
you're stuck with prevents your efforts making any difference?
>
> > In conclusion, mixing different values of ceramic caps in the same
packages
> > might help a little but might hurt a little in a real system with FPGAs.
I
> > maintain that using the biggest value in the size you choose is the
best, if
> > nothing else because they have the crappest Q and this avoids BOM bloat.
If
> > we do use a range, bully for us, we probably won't notice any
difference,
> > but we have more chances for resonance and EMI failures.
>
> This is not borne out by the facts.  If you can get your hands on
> Richey's book I would suggest that it is a valuable addition to any
> library on SI and EMI.  His volume 2 will cover EMI in more detail and
> I am looking forward to it.
>
I have different facts, look at the sims I posted.
>
> > Finally, I agree that the positioning of the cap is of lesser
importance.
> > However, some of us prefer not to waste layers in our stacks on power
> > planes, we prefer to have decent grounds and route our FPGA power on
layers
> > used for signals in other places. The HF plane capacitance is pissed
away by
> > the chip mounting interconnect anyway, and its high Q might lead to evil
> > resonances. (As you mention in your posts, Rick.) In this case, with
little
> > mini-planes for power routing, capacitor placement is crucial. (Note.
With
> > FPGAs needing at least 3 supplies, and maybe a lot more, the PCBs are
> > getting very expensive with planes for every supply.)
>
> Wow!  If your design is not high speed and the edge rates are not very
> fast, then power distribution is not a big deal.  But nearly everything
> in this paragraph is incorrect.  Yes, power planes cost money, that is
> true.  Now that I understand how simple it is to figure out how power
> distribution works, I would never use any of these ideas on a board
> where I needed good noise margin or had high speed signals.
>
I see from this paragraph you may not have grasped the effect that the BGA
package connections are having on the PDS design. As I said, the whole point
of the exercise is to get good supplies on the IC, not the power plane. The
plane capacitance has such high Q it's good to severel GHz, I reiterate that
you can't benefit from this on the device. I suggest you look at how Xilinx
themselves route the power to their Rocket I/Os on their demo boards. The
power supplies aren't on planes. The connection between the PCB and the IC
mean it's a waste of time, I suspect for these Gbit circuits they embed caps
on the FBGA.
>
> BTW, I never said a high Q power plane pair is bad.  Yes, it can create
> impedance holes at very high frequencies, but the alternative for your
> approach would raise the floor, not lower the ceiling.
>
I'm not saying it's necessarily bad. But it's not a great deal of help ON
THE SILICON. You've gotta get that HF energy through vias, bga balls,
traces(maybe) to the device.
>
> > In conclusion, for FPGA PCBs,
> > Lots of ground layers, one for every two signal layers.
> > One value of cap per size.
> > Use lots of caps. It means less impedance.
> > Power planes only need extend as far as the bypass caps. So, closer the
caps
> > to the target device, the less plane needed.
> >
> > IMHO, YMMV, HTH, Syms.
> >
> > p.s. It's easy to simulate this stuff, try the excellent and free
LTSpice
> > from
> > http://www.linear.com/company/software.jsp
> > (as recommended by Bob, thanks!)
> > p.p.s. Let me underline, _other_ways_work_too_ , but I'm happy with this
> > methodology, and I don't think other solutions work noticeable better.
>
> Have you tried simulating any of this?  I would like to know what
> results your methods produce.  The question is not so much if a method
> has worked a few times for you, but do you *know* it is going to work
> before you build the board.  Ritchey's method lets you *know* it will
> work right the first time.
>
Only a nutter would do this without thinking about it and running some
simulations. So, take a look at my LTSpice sim posts.

HTH, Syms.



Article: 107554
Subject: Re: placing addiional caps across existing caps to reduce noise
From: "Symon" <symon_brewer@hotmail.com>
Date: 30 Aug 2006 03:40:29 +0200
Links: << >>  << T >>  << A >>
"rickman" <gnuarm@gmail.com> wrote in message
news:1156900847.672642.116440@b28g2000cwb.googlegroups.com...
> I can take your word for your results as I don't understand any of the
> code you posted.  But this simulation is not of a power distribution
> system.  Try adding a power plane and just one value of cap (the 0.1uF
> is what you suggested IIRC) and simulate up to 200 MHz or so.  I think
> you will find that you get a *huge* parallel resonance peak from the
> two.  If you add a few 0.01 uF caps this peak will be split in two and
> the highest will be much smaller.  Then add a few more 0.001 uF caps
> and you will see the peaks reduced further.  It also helps if you use
> caps with a low Q factor or high ESR (relatively speaking).  But then
> at 0.1 uF, I don't think you will find a C0G so X7R should be fine.
>
> Symon wrote:
> > OK, here's a LTSpice file that shows a resonance between disimilar cap
> > values. The circuit sweeps from 5MHz to 45MHz back and forth. The first
> > three sweeps are done with two 1uF caps, the second three with a 1uF and
a
> > 0.1uF cap. Notice the big resonance at about 10MHz for the second set of
> > sweeps. The performance of the second circuit is slightly better at
45MHz,
> > worse at 5MHz, MUCH worse at 10MHz.
> > HTH, Syms.
> >
> > Version 4
> > SHEET 1 1516 904
> > WIRE 1040 432 800 432
>
> ....snip...
>
Tell you what, why don't YOU download the simulator from Linear Tech's
website and learn how to simulate what you suggest? Then you can prove stuff
to yourself without having to go to expensive classes. :-) You might even
want to simulate the stuff you learned at your class with a real world
situation and see how much benefit you get. Let us know how you get on.
Good luck, Syms.




Article: 107555
Subject: Re: placing addiional caps across existing caps to reduce noise
From: "Symon" <symon_brewer@hotmail.com>
Date: 30 Aug 2006 04:01:15 +0200
Links: << >>  << T >>  << A >>
So, here's a LTSpice ( http://www.linear.com/company/software.jsp ) SIM up
to 200MHz with a 100pF plane and two combinations of bypass capacitors. (Cap
data here:- http://www.murata.com/designlib/mcsil.html )

If there's anyone out there who has both the time and ability to run a
simulation, I'd appreciate some thoughts as to why my simulation doesn't
match up with Rick's classes. I'm trying to find a *huge* parallel
resonance! :-) I'm also looking for the benefits of different valued caps,
as opposed to just using the biggest value you can get in the package you
use.
Thanks, Syms.

Version 4
SHEET 1 1756 904
WIRE 1280 432 800 432
WIRE 0 464 -208 464
WIRE 208 496 144 496
WIRE 384 496 288 496
WIRE 448 496 384 496
WIRE 656 496 448 496
WIRE 1136 496 656 496
WIRE -208 512 -208 464
WIRE 656 512 656 496
WIRE 1136 512 1136 496
WIRE 736 528 704 528
WIRE 1280 528 1280 432
WIRE 1280 528 1184 528
WIRE 448 560 448 496
WIRE 800 576 800 432
WIRE 800 576 704 576
WIRE 1216 576 1184 576
WIRE 0 592 0 560
WIRE 768 592 656 592
WIRE 832 592 768 592
WIRE 880 592 832 592
WIRE 1024 592 976 592
WIRE 1072 592 1024 592
WIRE 1136 592 1072 592
WIRE -208 624 -208 592
WIRE 656 624 656 592
WIRE 768 624 768 592
WIRE 832 624 832 592
WIRE 880 624 880 592
WIRE 976 624 976 592
WIRE 1024 624 1024 592
WIRE 1072 624 1072 592
WIRE 1136 624 1136 592
WIRE 1280 624 1280 528
WIRE 656 720 656 688
WIRE 736 720 736 528
WIRE 736 720 656 720
WIRE 768 720 768 688
WIRE 768 720 736 720
WIRE 832 720 832 688
WIRE 832 720 768 720
WIRE 880 720 880 688
WIRE 880 720 832 720
WIRE 976 720 976 688
WIRE 1024 720 1024 688
WIRE 1024 720 976 720
WIRE 1072 720 1072 688
WIRE 1072 720 1024 720
WIRE 1136 720 1136 688
WIRE 1136 720 1072 720
WIRE 1216 720 1216 576
WIRE 1216 720 1136 720
WIRE 448 736 448 624
WIRE 656 736 656 720
WIRE 1136 736 1136 720
WIRE 1280 736 1280 704
FLAG 0 592 0
FLAG -208 624 0
FLAG 384 496 Vcap
FLAG 448 736 0
FLAG 656 736 0
FLAG 1136 736 0
FLAG 1280 736 0
SYMBOL SpecialFunctions\\modulate 0 464 R0
WINDOW 3 0 0 Invisible 0
SYMATTR InstName A1
SYMATTR Value MARK=205000000 SPACE= 5000000
SYMBOL voltage -208 496 R0
WINDOW 123 0 0 Left 0
WINDOW 39 0 0 Left 0
SYMATTR InstName V1
SYMATTR Value PULSE(0 1 100ns 10us 10us 1us 22us)
SYMBOL res 304 480 R90
WINDOW 0 0 56 VBottom 0
WINDOW 3 32 56 VTop 0
SYMATTR InstName R2
SYMATTR Value 0.1
SYMBOL cap 432 560 R0
SYMATTR InstName C5
SYMATTR Value 100pf
SYMATTR SpiceLine V=10 Irms=10.541 Rser=0 MTBF=0 Lser=0 ppPkg=1
SYMBOL sw 656 608 R180
SYMATTR InstName S1
SYMATTR Value MYSW
SYMBOL cap 640 624 R0
SYMATTR InstName C1
SYMATTR Value 0.1µ
SYMATTR SpiceLine V=10 Irms=10.541 Rser=0.014 MTBF=0 Lser=0.45nH ppPkg=1
SYMBOL cap 1120 624 R0
SYMATTR InstName C3
SYMATTR Value 1µ
SYMATTR SpiceLine V=10 Irms=10.541 Rser=0.01 MTBF=0 Lser=0.4nH ppPkg=1
SYMBOL sw 1136 608 R180
SYMATTR InstName S2
SYMATTR Value MYSW
SYMBOL voltage 1280 608 R0
WINDOW 123 0 0 Left 0
WINDOW 39 0 0 Left 0
SYMATTR InstName V3
SYMATTR Value PULSE(1 -1 44us 1ns 1ns 44us 88us)
SYMBOL cap 1056 624 R0
SYMATTR InstName C2
SYMATTR Value 1µ
SYMATTR SpiceLine V=10 Irms=10.541 Rser=0.01 MTBF=0 Lser=0.4nH ppPkg=1
SYMBOL cap 1008 624 R0
SYMATTR InstName C4
SYMATTR Value 1µ
SYMATTR SpiceLine V=10 Irms=10.541 Rser=0.01 MTBF=0 Lser=0.4nH ppPkg=1
SYMBOL cap 960 624 R0
SYMATTR InstName C6
SYMATTR Value 1µ
SYMATTR SpiceLine V=10 Irms=10.541 Rser=0.01 MTBF=0 Lser=0.4nH ppPkg=1
SYMBOL cap 864 624 R0
SYMATTR InstName C7
SYMATTR Value 1µ
SYMATTR SpiceLine V=10 Irms=10.541 Rser=0.01 MTBF=0 Lser=0.4nH ppPkg=1
SYMBOL cap 816 624 R0
SYMATTR InstName C8
SYMATTR Value 1µ
SYMATTR SpiceLine V=10 Irms=10.541 Rser=0.01 MTBF=0 Lser=0.4nH ppPkg=1
SYMBOL cap 752 624 R0
SYMATTR InstName C9
SYMATTR Value 0.1µ
SYMATTR SpiceLine V=10 Irms=10.541 Rser=0.014 MTBF=0 Lser=0.45nH ppPkg=1
TEXT 144 344 Left 0 !.tran 88us
TEXT 296 888 Left 0 !.model MYSW SW(Ron=0.0001 Roff=10Meg Vt=.5 Vh=-.4)



Article: 107556
Subject: Re: placing addiional caps across existing caps to reduce noise
From: "Symon" <symon_brewer@hotmail.com>
Date: 30 Aug 2006 04:21:45 +0200
Links: << >>  << T >>  << A >>

"Symon" <symon_brewer@hotmail.com> wrote in message
news:44f4f16b$1_3@x-privat.org...
> So, here's a LTSpice ( http://www.linear.com/company/software.jsp ) SIM up
> to 200MHz with a 100pF plane and two combinations of bypass capacitors.
(Cap
> data here:- http://www.murata.com/designlib/mcsil.html )
>
> If there's anyone out there who has both the time and ability to run a
> simulation, I'd appreciate some thoughts as to why my simulation doesn't
> match up with Rick's classes. I'm trying to find a *huge* parallel
> resonance! :-) I'm also looking for the benefits of different valued caps,
> as opposed to just using the biggest value you can get in the package you
> use.
> Thanks, Syms.
>
>
OK, so I've found the resonance, I needed a giant plane of 10nF, and only 4
caps. The resonance went away once I put a decent number of caps in the
circuit. Who has only 4 caps on a board 30cm by 20cm? I'm still looking for
a design where mixing the caps is better than not.
Cheers, Syms.



Article: 107557
Subject: Re: FSL read/write problems
From: "Felix Pang" <felix.pang@xilinx.com>
Date: Wed, 30 Aug 2006 11:49:14 +0800
Links: << >>  << T >>  << A >>
Hi David,

It is decided by the MPD file of the IP. Refer to the MPD of FSL you should 
see that the default connections of clock and reset are left blank.

-Feilx


"David" <simianfever@gmail.com> wrote in message 
news:1156891272.252770.135520@b28g2000cwb.googlegroups.com...
Thanks for your help guys, that fixed it.  Interesting that the EDK
system assembly GUI doesn't hook up clock and reset by default...

Cheers,

David


Göran Bilski wrote:
> David wrote:
> > Göran Bilski wrote:
> >
> >
> >>David wrote:
> >>
> >>>Hi all,
> >>>
> >>>I'm trying to implement a correlator as a coprocessor on the FSL bus.
> >>>The first thing I've done is generate the FSL example using the create
> >>>peripheral wizard in EDK 8.1 and hooked it up to the MicroBlaze.  When
> >>>I do a blocking write or read the MB stalls - my understanding is that
> >>>this will happen if the FSL FIFO is full or empty respectively, but it
> >>>happens the first time I write to it, so the FIFO should not be full.
> >>>
> >>>If I use non-blocking reads and writes and check the error and invalid
> >>>flags after each one using fsl_isinvalid() and fsl_iserror() - see code
> >>>below - everything seems normal but the output is always zero.  Am I
> >>>implementing the error checking macros correctly?
> >>>
> >>>
> >>>#define write_into_fsl(val, id)  nputfsl(val, id)
> >>>#define read_from_fsl(val, id)  ngetfsl(val, id)
> >>>
> >>>#define WRITE_FSL_TEST_0(val)  write_into_fsl(val,
> >>>XPAR_FSL_FSL_TEST_0_INPUT_SLOT_ID)
> >>>#define READ_FSL_TEST_0(val)  read_from_fsl(val,
> >>>XPAR_FSL_FSL_TEST_0_OUTPUT_SLOT_ID)
> >>>
> >>>
> >>>void fsl_test_app(
> >>>      unsigned int* input_0,      /* Array size = 2 */
> >>>      unsigned int* output_0       /* Array size = 2 */
> >>>      )
> >>>{
> >>>  int i;
> >>>   Xuint8 is_error = 0;
> >>>   Xuint8 is_valid = 0;
> >>>
> >>>   print("Entering fsl_test_app \r\n");
> >>>
> >>>  //Start writing into the FSL bus
> >>>  for (i=0; i<2; i++)
> >>>  {
> >>>
> >>>     WRITE_FSL_TEST_0(input_0[i]);
> >>>       fsl_iserror(is_error);
> >>>       xil_printf("error post: %d \r\n", is_error);
> >>>       fsl_isinvalid(is_valid);
> >>>       xil_printf("valid post: %d \r\n", is_valid);
> >>>  }
> >>>   print("Finished Write \r\n");
> >>>
> >>>   is_error = 0;
> >>>   is_valid = 0;
> >>>
> >>>  //Start reading from the FSL bus
> >>>  for (i=0; i<2; i++)
> >>>  {
> >>>     READ_FSL_TEST_0(output_0[i]);
> >>>       fsl_iserror(is_error);
> >>>       xil_printf("error post: %d \r\n", is_error);
> >>>       fsl_isinvalid(is_valid);
> >>>       xil_printf("valid post: %d \r\n", is_valid);
> >>>  }
> >>>}
> >>>
> >>>I added external ports to the FSL core to check the reset polarity and
> >>>monitor the state machine - the core is not being held at reset, but
> >>>always sits in the Idle state.  This, coupled with the blocking
> >>>instruction problems seems to indicate an issue with the FSL FIFO
> >>>perhaps (I have tried both BRAM and non-BRAM FIFO implementations)?
> >>>If anyone has any ideas on what might be going wrong your help would be
> >>>much appreciated...
> >>>
> >>>
> >>>Cheers,
> >>>
> >>>David
> >>>
> >>
> >>Hi,
> >>
> >>Can you show the .mhs where you have connected your FSL core with
> >>Microblaze?
> >>
> >>Göran Bilski
> >
> >
> >
> > Hi Göran,
> >
> > Thanks for your reply, here are the relevant parts of the .mhs file:
> >
> > BEGIN microblaze
> >  PARAMETER INSTANCE = microblaze_0
> >  PARAMETER HW_VER = 4.00.a
> >  PARAMETER C_USE_FPU = 0
> >  PARAMETER C_DEBUG_ENABLED = 1
> >  PARAMETER C_NUMBER_OF_PC_BRK = 2
> >  PARAMETER C_FSL_LINKS = 1
> >  BUS_INTERFACE DLMB = dlmb
> >  BUS_INTERFACE ILMB = ilmb
> >  BUS_INTERFACE DOPB = mb_opb
> >  BUS_INTERFACE IOPB = mb_opb
> >  BUS_INTERFACE SFSL0 = fsl_v20_0
> >  BUS_INTERFACE MFSL0 = fsl_v20_1
> >  PORT CLK = sys_clk_s
> >  PORT DBG_CAPTURE = DBG_CAPTURE_s
> >  PORT DBG_CLK = DBG_CLK_s
> >  PORT DBG_REG_EN = DBG_REG_EN_s
> >  PORT DBG_TDI = DBG_TDI_s
> >  PORT DBG_TDO = DBG_TDO_s
> >  PORT DBG_UPDATE = DBG_UPDATE_s
> > END
> >
> >
> > BEGIN fsl_v20
> >  PARAMETER INSTANCE = fsl_v20_0
> >  PARAMETER HW_VER = 2.00.a
> >  PARAMETER C_EXT_RESET_HIGH = 0
> >  PARAMETER C_IMPL_STYLE = 1
> > END
> >
> > BEGIN fsl_v20
> >  PARAMETER INSTANCE = fsl_v20_1
> >  PARAMETER HW_VER = 2.00.a
> >  PARAMETER C_EXT_RESET_HIGH = 0
> >  PARAMETER C_IMPL_STYLE = 1
> > END
> >
> > BEGIN fsl_test
> >  PARAMETER INSTANCE = fsl_test_0
> >  PARAMETER HW_VER = 1.00.c
> >  BUS_INTERFACE MFSL = fsl_v20_0
> >  BUS_INTERFACE SFSL = fsl_v20_1
> >  PORT reset_out = fsl_test_0_reset_out
> >  PORT state_debug = fsl_test_0_state_debug
> > END
> >
> > Cheers,
> >
> > David
> >
>
> Hi,
>
> You need to connect the system clock to the fsl_v20 modules.
> They are non clocked right now.
>
> One good trick is always to look at the top level vhdl file in the hdl
> directory. It's called system.vhd
>
> In that file you will see what signals are connected to what and it this
> case you should be able to see that the fsl bus doesn't have any clock
> connected.
>
> Göran Bilski



Article: 107558
Subject: Re: I2C on Xilinx Virtex-4/ML403
From: Peter Ryser <peter.ryser@xilinx.com>
Date: Tue, 29 Aug 2006 22:58:17 -0700
Links: << >>  << T >>  << A >>
Suzie,

you might want to try replacing R70 and R71 on the board with 1K 
resistors (currently 10K). While we are still looking into this issue it 
looks like the pull-up resistors are too weak resulting in a long rise 
time of SCL (and SDA).

- Peter


Suzie wrote:
> I'm developing on an ML403 evaluation board with a Virtex-4 device.
> I'm calling Xilinx's Level 0 I2C driver routines (XIic_Send, _Recv)
> from a PPC405 program running under the QNX OS.  I'm connecting to an
> external I2C device, a temp sensor/ADC, via the J3 header on the ML403.
> 
> When scoping the I2C SDA and SCL lines, I often notice a missing bit
> within the 8-bit address word.  Obviously, when this happens, the
> addressed device does not ACK the transfer.
> 
> I believe that my physical I2C connection is correct because I can
> successfully and consistently use the GPIO-I2C bit-banging approach (as
> implemented in Xilinx's iic_eeprom test program) to communicate with my
> external device.
> 
> I'm not sure how my operating environment or the driver could cause
> this problem.  The address is supplied by a single byte-write to the
> OPB_IIC core's Tx FIFO register; that seems atomic to me.  My gut
> feeling is that there is a problem with the core.
> 
> Anyone seen this problem, or know what I might be doing wrong??
> 

Article: 107559
Subject: Re: ISE/EDK "target pattern contains no `%'"
From: Amit Kasat <Amit.Kasat@Xlnx.com>
Date: Tue, 29 Aug 2006 23:10:16 -0700
Links: << >>  << T >>  << A >>
Not sure if you got a solution to the issue. Did you mix up Windows and 
Linux by any chance. It typically happens because the system_incl.make 
file has a macro defined called XILINX_EDK_DIR which may not have the 
right value. You might want to delete the *.make file in the EDK project 
directory to make sure they are regenerated.

Amit

zwsdotcom@gmail.com wrote:

>Grrrrr! Has anyone got ISE 7.1 working with EDK in Windows? Ever seen
>this error before?
>
>I installed ISE/EDK per instructions, and got the titular error as soon
>as I tried to generate a netlist inside Platform Studio. I assumed it
>was something stupid I did/forgot to do, so I followed the tutorial at
><http://direct.xilinx.com/direct/ise7_tutorials/EDK7.1_ML403.pdf>. When
>I click OK on the step at page 21 where a netlist is generated, I get
>the exact same error:
>
>Xilinx Platform Studio
>Xilinx EDK 7.1.2 Build EDK_H.12.5.1
>Copyright (c) 1995-2005 Xilinx, Inc.  All rights reserved.
>
>XPS% Evaluating file
>c:/xilprj/myproject/project_navigator/__projnav/system.synth.tcl
>system.make:171: *** target pattern contains no `%'.  Stop
>ERROR:MDT - Error while running "make -f system.make netlist"
>No changes to be saved in MSS file
>No changes to be saved in XMP file
>
>It's hard to imagine a more vanilla installation than the one I'm
>using, it's a WinXP install with everything defaulted. However I have a
>spare unused laptop in its box here, with NOTHING but WinXP on it - so
>I'm going to while away the hours installing the Xilinx software on
>that machine.
>
>By the way, line 171 of system.make is the @mkdir line in the following
>stanza:
>
>#################################################################
># BOOTLOOP ELF FILES
>#################################################################
>
>$(PPC405_0_BOOTLOOP): $(PPC405_BOOTLOOP)
>	@mkdir -p $(BOOTLOOP_DIR)
>	cp -f $(PPC405_BOOTLOOP) $(PPC405_0_BOOTLOOP)
>
>Xilinx is well on the way to being my least favorite semiconductor
>vendor of all time. Apart from their obnoxious software licensing,
>there's a one business day delay in merely signing up for the privilege
>of asking a question, let alone actually receiving an answer. And they
>apparently never test their development software. I remember hating
>Altera's tools when I last used them (I can still see the gray hairs
>from that battle every time I look in a mirror), but at least their
>tutorials worked!
>
>Anyhow - if anyone has seen this error before (Google found nothing
>relevant), hints would be appreciated!
>
>  
>

Article: 107560
Subject: Re: placing addiional caps across existing caps to reduce noise
From: fpga_toys@yahoo.com
Date: 29 Aug 2006 23:13:22 -0700
Links: << >>  << T >>  << A >>

rickman wrote:
> In addition, the impedance of your package leads has no bearing on the
> power decoupling.  No amount of capacitace external or internal to the
> device will have any impact on the bounce that will be caused by power
> lead inductance.  The only cure for that is a new package.

I pretty much came to this realization with the XCV2000E parts in the
BG560 package for high density reconfigurable computing needs. There
was nothing I could do to overcome the BG560 packages small via, trace
and bonding wire inductance to make the parts stable. Only choice was
to seriously derate them.


Article: 107561
Subject: Re: no luck instantiating system.xmp (EDK project file) within ISE
From: Amit Kasat <Amit.Kasat@Xlnx.com>
Date: Tue, 29 Aug 2006 23:15:20 -0700
Links: << >>  << T >>  << A >>
matteo wrote:

>OK I figured it out. This was my own ignorance of VHDL. I'm a Verilog
>user.
>
>The Component declaration must go below the architecture of __ is line
>and the Port Map is below begin
>
>matteo wrote:
>  
>
>>I'm having problems instantiating my EDK file within an ISE project.
>>
>>I have a top level VHDL that looks like:
>>
>>library IEEE;
>>use IEEE.STD_LOGIC_1164.ALL;
>>use IEEE.STD_LOGIC_ARITH.ALL;
>>use IEEE.STD_LOGIC_UNSIGNED.ALL;
>>
>>---- Uncomment the following library declaration if instantiating
>>---- any Xilinx primitives in this code.
>>library UNISIM;
>>use UNISIM.VComponents.all;
>>
>>entity topnew is
>>end topnew;
>>
>>architecture RTL of topnew is
>>
>>begin
>>
>>COMPONENT system
>>	PORT(
>>		fpga_0_RS232_Uart_RX_pin : IN std_logic;
>>		fpga_0_DDR_CLK_FB : IN std_logic;
>>		sys_clk_pin : IN std_logic;
>>		sys_rst_pin : IN std_logic;
>>		PortName : IN std_logic;
>>		fpga_0_LEDs_4Bit_GPIO_IO_pin : INOUT std_logic_vector(0 to 3);
>>		fpga_0_LEDs_Positions_GPIO_IO_pin : INOUT std_logic_vector(0 to 4);
>>		fpga_0_Push_Buttons_Position_GPIO_IO_pin : INOUT std_logic_vector(0
>>to 4);
>>		fpga_0_DDR_SDRAM_64Mx32_DDR_DQS_pin : INOUT std_logic_vector(0 to 3);
>>		fpga_0_DDR_SDRAM_64Mx32_DDR_DQ_pin : INOUT std_logic_vector(0 to 31);
>>		fpga_0_SRAM_256Kx32_Mem_DQ_pin : INOUT std_logic_vector(0 to 31);
>>
>>		fpga_0_RS232_Uart_TX_pin : OUT std_logic;
>>		fpga_0_DDR_SDRAM_64Mx32_DDR_Clk_pin : OUT std_logic;
>>		fpga_0_DDR_SDRAM_64Mx32_DDR_Clkn_pin : OUT std_logic;
>>		fpga_0_DDR_SDRAM_64Mx32_DDR_Addr_pin : OUT std_logic_vector(0 to 12);
>>		fpga_0_DDR_SDRAM_64Mx32_DDR_BankAddr_pin : OUT std_logic_vector(0 to
>>1);
>>		fpga_0_DDR_SDRAM_64Mx32_DDR_CASn_pin : OUT std_logic;
>>		fpga_0_DDR_SDRAM_64Mx32_DDR_CKE_pin : OUT std_logic;
>>		fpga_0_DDR_SDRAM_64Mx32_DDR_CSn_pin : OUT std_logic;
>>		fpga_0_DDR_SDRAM_64Mx32_DDR_RASn_pin : OUT std_logic;
>>		fpga_0_DDR_SDRAM_64Mx32_DDR_WEn_pin : OUT std_logic;
>>		fpga_0_DDR_SDRAM_64Mx32_DDR_DM_pin : OUT std_logic_vector(0 to 3);
>>		fpga_0_SRAM_256Kx32_Mem_A_pin : OUT std_logic_vector(9 to 29);
>>		fpga_0_SRAM_256Kx32_Mem_BEN_pin : OUT std_logic_vector(0 to 3);
>>		fpga_0_SRAM_256Kx32_Mem_WEN_pin : OUT std_logic;
>>		fpga_0_SRAM_256Kx32_Mem_OEN_pin : OUT std_logic_vector(0 to 0);
>>		fpga_0_SRAM_256Kx32_Mem_CEN_pin : OUT std_logic_vector(0 to 0);
>>		fpga_0_SRAM_256Kx32_Mem_ADV_LDN_pin : OUT std_logic;
>>		fpga_0_SRAM_CLOCK : OUT std_logic
>>		);
>>	END COMPONENT;
>>
>>	Inst_system: system PORT MAP(
>>		fpga_0_RS232_Uart_RX_pin => ,
>>		fpga_0_RS232_Uart_TX_pin => ,
>>		fpga_0_LEDs_4Bit_GPIO_IO_pin => ,
>>		fpga_0_LEDs_Positions_GPIO_IO_pin => ,
>>		fpga_0_Push_Buttons_Position_GPIO_IO_pin => ,
>>		fpga_0_DDR_SDRAM_64Mx32_DDR_Clk_pin => ,
>>		fpga_0_DDR_SDRAM_64Mx32_DDR_Clkn_pin => ,
>>		fpga_0_DDR_SDRAM_64Mx32_DDR_Addr_pin => ,
>>		fpga_0_DDR_SDRAM_64Mx32_DDR_BankAddr_pin => ,
>>		fpga_0_DDR_SDRAM_64Mx32_DDR_CASn_pin => ,
>>		fpga_0_DDR_SDRAM_64Mx32_DDR_CKE_pin => ,
>>		fpga_0_DDR_SDRAM_64Mx32_DDR_CSn_pin => ,
>>		fpga_0_DDR_SDRAM_64Mx32_DDR_RASn_pin => ,
>>		fpga_0_DDR_SDRAM_64Mx32_DDR_WEn_pin => ,
>>		fpga_0_DDR_SDRAM_64Mx32_DDR_DM_pin => ,
>>		fpga_0_DDR_SDRAM_64Mx32_DDR_DQS_pin => ,
>>		fpga_0_DDR_SDRAM_64Mx32_DDR_DQ_pin => ,
>>		fpga_0_SRAM_256Kx32_Mem_A_pin => ,
>>		fpga_0_SRAM_256Kx32_Mem_BEN_pin => ,
>>		fpga_0_SRAM_256Kx32_Mem_WEN_pin => ,
>>		fpga_0_SRAM_256Kx32_Mem_DQ_pin => ,
>>		fpga_0_SRAM_256Kx32_Mem_OEN_pin => ,
>>		fpga_0_SRAM_256Kx32_Mem_CEN_pin => ,
>>		fpga_0_SRAM_256Kx32_Mem_ADV_LDN_pin => ,
>>		fpga_0_SRAM_CLOCK => ,
>>		fpga_0_DDR_CLK_FB => ,
>>		sys_clk_pin => ,
>>		sys_rst_pin => ,
>>		PortName =>
>>	);
>>
>>
>>end architecture RTL;
>>
>>
>>-----------
>>
>>But I get these errors:
>>
>>Compiling vhdl file "D:/comp8_xmp_ise/comp8/topnew.vhd" in Library
>>work.
>>ERROR:HDLParsers:164 - "D:/comp8_xmp_ise/comp8/topnew.vhd" Line 37.
>>parse error, unexpected COMPONENT
>>ERROR:HDLParsers:164 - "D:/comp8_xmp_ise/comp8/topnew.vhd" Line 40.
>>parse error, unexpected IN
>>ERROR:HDLParsers:164 - "D:/comp8_xmp_ise/comp8/topnew.vhd" Line 41.
>>parse error, unexpected IN
>>    
>>
>
>  
>
You can also generate a verilog instantiation template for the XMP 
module in ISE.

Amit

Article: 107562
Subject: FF1152 Development board....
From: "Xesium" <amirhossein.gholamipour@gmail.com>
Date: 30 Aug 2006 00:16:39 -0700
Links: << >>  << T >>  << A >>
Hi guys,
Currently in my experiments I'm using an FF1152 Development Board
originally by Memec. The FPGA chip on the board is XC2VP20 and the
board is Revision 3.
If any of you guys have worked with this board I'd be very thankful if
you could advise me how I can solve the following problem that I have:

I'm trying to measure the power of the FPGA chip and I know that the
1.5V power supply feeds just FPGA chip (At least this is my impression
from the data sheet). So if I can measure the current on that supplier
I should logically be able to measure the power. On the board there are
two sets of pins besides which it has written CURRENT MEASURE on the
board. One set of the pins which are connected with a jumper is JP39
and JP12, and JP14 which doesn't have a jumper and it has written
SHUTDOWN next to it on the board. Exactly the same thing is for pins
JP38 and JP7 and JP8 respectively. In the data sheet of the board I
could find nothing related to these pins or if they are related to what
I want to do which is measuring the current on power supply of the
chip. So could you please let me know how I can measure the power of
the chip?

I have another question too. Is there any way for me to measure the
power of the external memory? Actually I'm just interested to measure
the power of FPGA chip and External Memory not other peripherals on the
board. Do you know any solution for that?


I really appreciate your response and thank you beforehand,

Amir


Article: 107563
Subject: power measurement on the board...
From: "Xesium" <amirhossein.gholamipour@gmail.com>
Date: 30 Aug 2006 00:26:22 -0700
Links: << >>  << T >>  << A >>
Hi guys,

I'm trying to measure the power consumption on the board instead of
using XPower. From the previous posts I know that if I can in a way
measure the current on Vccint I can measure the power consumption of
the chip (not the board). Is that correct?
Is there any similar way for me to be able to measure the power on
External Memory on the board?

thanks,

Amir


Article: 107564
Subject: Re: Do I need to adjust sdram clk shift when i lower my system clock?
From: "Karl" <karl@chello.nl>
Date: 30 Aug 2006 00:42:15 -0700
Links: << >>  << T >>  << A >>

Tony schreef:

> Hi everyon, hope someone can give me a pointer or help.
>
> I lowered the system clock in the Altera stratix example design
> (standard) from 50 to 35 Mhz. Is it necessary to change the time shift
> of the sdram clock?? (-3.5ns by default)
>
> because, a time shift of -3.5 ns seems to work fine until i fixed a
> huge (around 10k LE) jpeg decompression unit on to the system. Does
> anyone know do i need a new time shift or not?
> I tried a several delay from -1.0 to -8ns, but the system is still not
> stable, my c program can be downloaded to the board but at times fails
> to verification.
>
> (It sometimes passes verification, but the program doesn't run
> properly. To simplify debugging, I only put a printf statment in my
> main(), but it doesn't print)
>
> ps. I put my program and all data memory in sdram
> Thanks

Hi Tony,

At the end of this chapter there is some information on your question:

SDRAM Controller Core with Avalon Interface Datasheet:
http://altera.com/literature/hb/nios2/n2cpu_nii51005.pdf

Good luck,

Karl.


Article: 107565
Subject: MGT Power supply
From: heinerlitz@gmx.de
Date: 30 Aug 2006 00:53:51 -0700
Links: << >>  << T >>  << A >>
Hi

I have several questions powering the AVCCAUXRX/TX MGT power supply:

-Are switching regulators allowed or should linears be used. An
application note says switcher will work up to 3.125 with extensive
filtering some say you should use linears. We want to work with the
MGTs at 6.5.

-How much power (amps) do unused MGTs consume?

-Do unused MGTs generate lots of noise on the power supply so other
components can be affected?

My plan was to supply the unused MGTs from the same source than the 1.2
FPGA core without filtering caps. This would consume less space on the
PCB, however it is crucial to know how much amps unused MGTs consume
and if they generate noise on the power supply.

thanks, Heiner Litz


Article: 107566
Subject: Re: high level languages for synthesis
From: Martin Thompson <martin.j.thompson@trw.com>
Date: 30 Aug 2006 09:11:42 +0100
Links: << >>  << T >>  << A >>
fpga_toys@yahoo.com writes:

> 
> The doc's are available under the Doc page, which are Beta-2 docs.
> Current work in progress will be always SVN. I try update the doc's as
> we check things in, so it's not a frenzy at the next beta freeze.
> 

Ahh, I see where they are - I was looking for them off the
http://fpgac.sourceforge.net/ page.  There's a sentence in there
about docs, which might benefit from a hyperlink to the actual docs?

<snip>
> Martin Thompson wrote:
> > Have you considered doing a higher-level technology independent
> > VHDL/Verilog backend, which could then be thrown into a normal
> > synthesizer and let it ifugre out the best adders and such like -
> > they've been practising that for a number of years now :-)
> 
> There is a VHDL output, fully functional I believe in Beta-1 ... it got
> broke in Beta-2, and will be fixed at Beta-3 again (which should be
> very soon).
> 

I think that's also low-level though, LUTs and wiring?  I was thinking
of something higher-level, where if you have an adder, you put a<=b+1
in the VHDL and let the synth sort it out.

Or are there benefits to optimising across the great sea of LUTs that
a normal synth doesn't get to?

Cheers,
Martin

-- 
martin.j.thompson@trw.com 
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.conekt.net/electronics.html

   

Article: 107567
Subject: Re: high level languages for synthesis
From: Martin Thompson <martin.j.thompson@trw.com>
Date: 30 Aug 2006 09:16:23 +0100
Links: << >>  << T >>  << A >>
Jan Panteltje <pNaonStpealmtje@yahoo.com> writes:

> On a sunny day (29 Aug 2006 11:42:00 +0100) it happened Martin Thompson
> <martin.j.thompson@trw.com> wrote in <uk64rzuvb.fsf@trw.com>:
> >
> >Neal Stephenson wrote "in the beginning was the command line"
> >http://www.cryptonomicon.com/beginning.html
> 
> I have just read part of that, he really gets out there.... :-)
> 

Yeah :-)

> For me, one thing the 'command line' interface does, is allow me to speak
> normal language to a computer.
> This is important in interfacing to computers with speech.
> 
> For example I have a script (Linux Bash) called 'show', and a PCI satellite
> card in the PC.
>  http://panteltje.com/panteltje/satellite/show
> When I _type_ 'show BBC2' at the command prompt, then it will steer the dish
> to one of the Astra satellites and start mplayer.
> 

Yep, get it done once and it's easy all the other times!

I've often thought that good engineers are fundamentally lazy - they
only want to do something once, do it well, then get on with the next
thing, having made the first thing so easy that they don't have to
think about it!  When I can make that less waffley (sp?), it might
become a .sig...

> And when I _say_ 'show bbc2' it will do the same, using perlbox voice.
> 

Neat- I shall have to play with that!

> The ability to make commands that are simply spelled as English words is
> perhaps the most powerful thing.
> 'Random access'.
> 
> You often _know_ what program or action you want the computer to do, and
> going via many menus to dig deeper and deeper is a barrier, takes time.
> 

It's OK the first time when you are exploring something new, the
guidance can be a boon. But when you have to do it every time, it gets
a bit annoying.

<snip>

> Same in FPGA, use makefiles, scripts.
> 

Ahh, back on topic :-)  Ditto for me.  I wouldn't be without python now!

> To pester MS windows users I say sometimes: 'My PC speaks English'.
> 

How do they respond to "goading" like that?

Cheers,
Martin

-- 
martin.j.thompson@trw.com 
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.conekt.net/electronics.html

   

Article: 107568
Subject: Re: FPGA -> SATA?
From: joseph2k <quiettechblue@yahoo.com>
Date: Wed, 30 Aug 2006 08:38:54 GMT
Links: << >>  << T >>  << A >>
Nico Coesel wrote:

> "Antti" <Antti.Lukats@xilant.com> wrote:
> 
>>
>>in any case - I can not and do not want to belive that Xilinx designed
>>boards with features knowing not to work (at the time of the board
>>design).
>>
> 
> Lets say Xilinx is a bit too optimistic about their devices every now
> and then.
> 

Just like Micro$oft is about its OS software.

-- 
 JosephKK
 Gegen dummheit kampfen die Gotter Selbst, vergebens.  
  --Schiller

Article: 107569
Subject: Re: placing addiional caps across existing caps to reduce noise
From: David Brown <david@westcontrol.removethisbit.com>
Date: 30 Aug 2006 10:53:32 +0200
Links: << >>  << T >>  << A >>
rickman wrote:
> John_H wrote:
>> "rickman" <gnuarm@gmail.com> wrote in message
>> Won't any higher inductance result in the same above-SRF slope?  That is,
>> given the total inductance, it won't matter what the capacitance is once
>> above an ohm in the impedance vs freq plot.
> 
> I'm not sure what you are asking.  A different capacitance will not
> change the inductive part of the impedance curve and a different
> inductance will not change the capacitive part of the curve.  What
> changes in both cases is the SRF.  So you put a few 0.1 uF caps on the
> board and a number more of 0.01 uF caps and even more of the 0.001 uF
> caps.  Each capacitance value needs to have sufficient quantity to
> bring the impedance near the SRF low enough to be effective.  Then the
> capacitive effect of the smaller caps keep the overall impedance low in
> spite of the larger caps being inductive.  Finally the impedance of the
> ground planes keep the impedance low for the highest frequency.  Doing
> a simulation is always a good thing to be able to see how the parallel
> resonances affect the impedance.
> 

I've not any high speed boards - the last board I made had internal 
frequencies at 150 MHz, and an external bus at 75 MHz (overclocked in 
testing to about 240/120 MHz), so maybe I'm missing something that 
happens at higher frequencies.

Using a simple tool such as Murata's software, I looked at the 
impedances for different capacitors at different frequencies.  To a fair 
extent, the inductance is determined by the package size (and the board 
vias and traces), while the capacitance obviously goes up with the cap's 
value.  So choosing a 0.01 uF instead of a 0.1 uF cap increases the 
capacitance side of the impedance curve by a factor of 10, and leaves 
the inductive side unchanged.  It changes the peak frequency, but I fail 
to see why that should make a real difference - it has the same or 
higher impedance across the frequency range.  Given that the 0.1 uF type 
has lower ESR (being made of more parallel plates), I can't find any way 
in which the 0.01 uF is better.  So as Symon says (unless I'm 
misinterpreting him), the best arrangement is to pick the smallest size 
package you can conveniently mount (0603 for us), then the largest 
capacitance value you can conveniently and economically get in that size 
(100 nF), and use as many as needed for the board.  Placement should be 
close to the device where possible, but is not very critical as long as 
it is within the range of the mini power plane (i.e., polygon on a 
signal layer).

It works for me - but then again, I'm not doing really high-end cards.

Article: 107570
Subject: behavioral vs post-P&R simulation mismatch
From: "tullio" <tullio.grassi@gmail.com>
Date: 30 Aug 2006 02:00:03 -0700
Links: << >>  << T >>  << A >>
I know this topic has been discussed before, but i am looking for some
ideas.
My design is synchronous, I use ISE8.2.02 XST and ModelSim, I have a
lot of signed logic; I get different results from behavioral and
post-Route simulations.
I paid attention to the reset condition, in fact the data are ok after
the first stage of the circuit.
I tried to delay the data compared to the clock with no success.
I noticed that at the first rising edge of the clock most signals are x
in the post-P&R simulation, while they are defined in the behavioral
simulation.
Any advice before bringing out every meaningful signal in the
implementation process ?
Any known bug in the simulation models of the xilinx primitives
(multipliers, BRAMs, etc) ?

 Tullio


Article: 107571
Subject: Re: Style of coding complex logic (particularly state machines)
From: Martin Thompson <martin.j.thompson@trw.com>
Date: 30 Aug 2006 10:01:10 +0100
Links: << >>  << T >>  << A >>
mikegurche@yahoo.com writes:

<snip commentary on variables>

> 
> In synthesis, the problem is normally the abuse of sequential
> statements, rather than the use of variable.  I have seen people trying
> to convert C segment into a VHDL process (you can have variables, for
> loop, while loop, if, case, and even break inside a process) and
> expecting synthesis software to figure out everything.
> 

Why not do this?  Synthesis software is good at figuring all this
out.  If it does what you need it to and meets timing, you're done.
Move on to the next problem.

Personally, I have seen people spend far too long doing very explicit
coding of detailed stuff, giving the synth tool very little to do,
which for a relatively low-performance (still in the 10s of MHz
though) design, was a waste of effort.  The so-called "naive" approach
of writing code in a natural "softwary" way and letting the synth sort
it out would have left us more time to sort out the one nitty-gritty
bit of code which did have a performance problem.

Sure, if you are pushing the performance envelope, you're going to
have to put more work in. If you are doing a high-volume design then
you might get in a smaller part and save some money by putting the
effort in.  But that's just an engineering-tradeoff like any other.
Softies do it all the time, optimising their hardcore interrupt
handlers, leave the rest to the tools.  I assume civil engineers do
similar things with their bridges as well :-)

> My 2 cents.
> 

My tuppence :-)

Cheers,
Martin

-- 
martin.j.thompson@trw.com 
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.conekt.net/electronics.html

   

Article: 107572
Subject: Re: Spartan-4 ?
From: lb.edc@telenet.be
Date: Wed, 30 Aug 2006 09:36:09 GMT
Links: << >>  << T >>  << A >>
Ben,

Does this 'Cyclix' mean a CYCLone with mIXed signal - or flash based
Cyclone, or just a typo for Cyclone3

Regards,

Luc

On Wed, 30 Aug 2006 00:11:33 +0200, Ben Twijnstra
<btwijnstra@gmail.com> wrote:

>Jim Granville wrote:
>
>> Any info out yet on what MAX3 looks like ?
>> Does it improve Static Icc, and lack of memory of MAX II, for example ?
>> Smallest devices / largest devices  ?
>
>Nope - Altera's silicon design team is quite busy with Cyclix III. If you
>have any good suggestions on specs outside the hobby sphere, now might be a
>good time to post them...
>
>Ben

Article: 107573
Subject: Xilinx - one secret less, or how to use the PMV primitive
From: "Antti" <Antti.Lukats@xilant.com>
Date: 30 Aug 2006 02:52:49 -0700
Links: << >>  << T >>  << A >>
Hi All,

as I had guessed for long time the PMV primitive is actually the
on-chip oscillator, most likely it is the same oscillator that is used
for configuration. And it can be used from user designs as well. PMV is
present in all recent FPGAs.

http://xilant.com/index.php?option=com_content&task=view&id=29&Itemid=32

When I opened webcase about the issue that Xilinx tools made fatal
failure when I tried to use the PMV from an hard macro the response was
that, "you dont need to know" - well now I know :)

Antti


Article: 107574
Subject: Re: Spartan-4 ?
From: Aurelian Lazarut <aurash@xilinx.com>
Date: Wed, 30 Aug 2006 10:53:14 +0100
Links: << >>  << T >>  << A >>
lb.edc@telenet.be wrote:

>Ben,
>
>Does this 'Cyclix' mean a CYCLone with mIXed signal - or flash based
>Cyclone, or just a typo for Cyclone3
>
>Regards,
>
>Luc
>
>  
>
Luc,
I think is more like "spartex" or "virtan"   in X-world.  ;-)

Aurash

>On Wed, 30 Aug 2006 00:11:33 +0200, Ben Twijnstra
><btwijnstra@gmail.com> wrote:
>
>  
>
>>Jim Granville wrote:
>>
>>    
>>
>>>Any info out yet on what MAX3 looks like ?
>>>Does it improve Static Icc, and lack of memory of MAX II, for example ?
>>>Smallest devices / largest devices  ?
>>>      
>>>
>>Nope - Altera's silicon design team is quite busy with Cyclix III. If you
>>have any good suggestions on specs outside the hobby sphere, now might be a
>>good time to post them...
>>
>>Ben
>>    
>>


-- 
 __
/ /\/\ Aurelian Lazarut
\ \  / System Verification Engineer
/ /  \ Xilinx Ireland
\_\/\/
 
phone:	353 01 4032639
fax:	353 01 4640324
    
     



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