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 123675

Article: 123675
Subject: Re: PCB Impedance Control
From: PeteS <axkz70@dsl.pipex.com>
Date: Fri, 31 Aug 2007 22:36:23 -0400
Links: << >>  << T >>  << A >>
John_H wrote:
> "PeteS" <axkz70@dsl.pipex.com> wrote in message 
> news:A_ydnSr8fcvE7kXbnZ2dnUVZ8sqjnZ2d@pipex.net...
>> John_H wrote:
> <snip>
> 
>>> Thanks to everyone for devining what PeteS means.
>>> I understand skin effect.
>>> I understand the confinement of return current for high frequencies.
>>> I don't understand the statement that "there is no such thing as 
>>> 'ground'."
>>>
>>> I was hoping Pete could conjecture what Pete meant.
>>>
>>> - John_H
>> Hi John
>>
>> Let's first define what 'ground' means. For power, it's the 'zero 
>> potential' path for return currents. For RF radiation, it's literally the 
>> ground (where we get the name) which has a nominal '0' potential.
>>
>> For high speed signalling, there isn't really a thing that has zero 
>> potential across it's length, be it signal or reference. The return 
>> currents in a nominal ground plane for high speed returns will induce 
>> significant potential gradients across the plane. As a 'ground plane' is 
>> usually used as a description of an area of equipotential, the term ceases 
>> to have meaning when it is no longer equipotential - as is the case when 
>> it is a high speed signal reference/return path.
>>
>> That's really what I mean by the comment that at high speeds, ground 
>> doesn't really exist.
>>
>> Cheers
>>
>> PeteS
> 
> The fact that return current is confined tightly around the signal for high 
> frequencies doesn't make the ground plane cease to be nearly equipotential. 
> The confined return current will not raise the voltage of the ground plane 
> significantly but instead flow the current through a low impedance path due 
> to any induced voltage.  If the voltage changes under the high frequency 
> trace due to the return current and the finite HF plane impedance, the 
> current will flow out around that area to the lower potential - a voltage 
> difference on a ground plane doesn't last long; this is why the return 
> current path is several widths of the distance to the conductor above.  If 
> the ground reference were not a ground but a strip that was the same width 
> we identified for the return current, the characteristics would probably be 
> a bit different since the voltage difference from under the signal to the 
> edge of this region isn't tied down to the same potential as the rest of a 
> plane, but isolated.  Current and voltage are two parts of the power flow. 
> Impedance (resistance, capacitance, inductance) affects the overall picture. 
> The confinement of the return path the way we've defined it is because of 
> the planes - because of the impedances involved - in addition to the other 
> high frequency issues such as skin depth.
> 
> I'd love to see the difference between a plane reference and a strip 
> reference that *should* contain the entire return current.  It may be the 
> two solutions are the same.  But it may present very different results.  I 
> haven't done studies on the return current issue, but my gut says that if we 
> ditch the ground plane, the assumptions we make at high frequency also go 
> out the window.
> 
> - John_H 
> 
> 

 From my experience, a strip reference is the same as a plane. There are 
a number of issues here, not least that we are returning low speed high 
currents on the same plane that we are returning high speed currents.

For low speed (DC or close to it) currents, the entire plane is the 
return path. As the speeds increase, the return path becomes more and 
more constrained, primarily due to inductance of the return path. The 
return path would be identical [in width] to the signal path at infinite 
frequencies, for the above postulate. For reasonably high speed signals 
(at 1.25GHz fundamental, for instance) 90% or so is constrained within 
those bounds.

When looking at a plane, one must ask what the reference problem is; for 
a 1/4 wave antenna, the entire zone is required to make the reflected 
antenna operate properly (because it is reflected - it's not really the 
antenna); for a signal return, a plane is not necessary. This is borne 
out (when one thinks about it) by the principle of coplanar waveguide.


So - is a plane necessary? Usually, yes; and it's usually a very good 
idea, but at high speed it's not a 'plane' in the ordinary sense.

Cheers

PeteS

Article: 123676
Subject: Re: Xilinx ML40x Mouse VHDL Wanted
From: ghelbig@lycos.com
Date: Fri, 31 Aug 2007 22:05:36 -0700
Links: << >>  << T >>  << A >>
On Aug 31, 11:42 am, "Brad Smallridge" <bradsmallri...@dslextreme.com>
wrote:
> Does anybody have VHDL code to
> run the mouse port on an ML40x dev board?
>
> Brad Smallridge
> Ai Vision

You do know that the mouse port is a PS/2 port?

A google for "ps2 vhdl" gets three different sources in the 1st four
hits.

G.


Article: 123677
Subject: Re: Newbie with ISE 9_2_02i_lin gets error : Process "Translate"
From: Bob Smith <usenet@linuxtoys.org>
Date: Sat, 01 Sep 2007 05:07:59 GMT
Links: << >>  << T >>  << A >>
Just as a follow-up ---  the problem went away when I switched
from Ubuntu to Fedora Core 5.

Bob


Bob Smith wrote:
> Downloaded ISE 9.2i day before yesterday.  Installed t9_2_02i_lin update
> and am just going through the counter example in the "ISE 9.1i Quick Start
> Tutorial" that is in .../doc/usenglish/books/docs/qst/qst.pdf
> 
> Everything works until I try to enter the timing constraints.  Double-
> clicking "Create Timing Constraints" runs the implement_design function
> which ends with the error: Process "Translate" failed.
> 
> This seems similar to a posting by Matthias Alles about "xst fails..."
> and I did a process_cleanup_files as suggested in that thread.
> 
> My output is given below.
> 
> Any ideas how to get past this?

Article: 123678
Subject: Re: Is it possible to make bit files generated by Xilinx ISE readable?
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Fri, 31 Aug 2007 22:07:19 -0800
Links: << >>  << T >>  << A >>
Wei Wang wrote:
> I thought the bit files generated by Xilinx ISE should be in plain
> binary format, but actually the .bit file is unreadable when opened in
> XEmacs, just wondering whether it is possible to make these bit files
> readable? Many thanks, -Wei

Xilinx used to have either BIT files or RBT files.

The BIT files use all bits of each byte, the RBT files are an
ASCII image, with each byte being an ASCII 0 or 1 character, and
so are eight times larger.

It is pretty easy to write a C program to convert between them.

-- glen



Article: 123679
Subject: Re: PCB Layers
From: "Symon" <symon_brewer@hotmail.com>
Date: Sat, 1 Sep 2007 12:31:17 +0100
Links: << >>  << T >>  << A >>
"comp.arch.fpga" <ksulimma@googlemail.com> wrote in message 
news:1188331867.465434.221240@22g2000hsm.googlegroups.com...
> On 28 Aug., 15:23, "maxascent" <maxasc...@yahoo.co.uk> wrote:
>> Hi
>>
>> I am designing a pcb with a Virtex 4 FX in a FF672 package. Is there a
>> general rule of how many layers the pcb will need to route out all the
>> pins?
>
> Most other posts are focussing on signal routing. But for FX this
> really is
> the least of your problems. The answer depends a lot on the MGT
> performance
> you are looking at. The MGTs need many supply voltages. Each of them
> should
> be filtered individually for high data rates. This means you either
> need many islands,
> which reduce plane capacitance and increase plane inductance. Or you
> need many,
> many planes.
> For lower data rates (1.25gbps) you should be able to combine supplies
> that have
> the same voltage. This is not recommended by Xilinx, so your milage
> might vary.
>
> Also, the MGTs pretty much prevent routing out signals on the top
> layers.
> As a result, an FX that uses all MGTs will need  more layers than an
> LX.
> We use 14 layers for an FX60-FF1152 with 12 MGTs at 5gbps.
>
> Kolja Sulimma
>
Hi Kolja,

Although your suggestions will result in a working solution, I respectfully 
think you're overengineering this. The power supplies to the MGTs don't need 
islands or a plane. A 0402 cap right by the ball, fed from a ferrite is as 
good bypassing as you're going to get. The ferrite can be on the reverse 
side or far away from the device. All the stuff you read about plane 
capacitance is over-rated for bypassing ICs, including BGAs. The inductance 
of the BGA's balls and connections to the die stuff means that the 
admittedly ultra high Q of the plane capacitance is not much use at all, so 
why bother even trying? In this situation, with the power pins neear the 
edge of the part, it's much more useful to keep the ground plane as close to 
the surface as possible, than to worry about power planes.

The microvia solution works perfectly for MGTs as these vias are more or 
less transparent to very high speeds indeed.

Anyway, that's my experience.

HTH., Symon.




Article: 123680
Subject: Interesting FPGA/JTAG project.
From: "Symon" <symon_brewer@hotmail.com>
Date: Sat, 1 Sep 2007 12:35:46 +0100
Links: << >>  << T >>  << A >>
Guys,
I saw this on Slashdot.

http://nsa.unaligned.org/

Interesting article about a guy who used some rescued FPGA boards to do some 
number crunching. Also, there's a cool JTAG tool.

Cheers, Syms. 



Article: 123681
Subject: Re: PCB Layers
From: "maxascent" <maxascent@yahoo.co.uk>
Date: Sat, 01 Sep 2007 08:58:36 -0500
Links: << >>  << T >>  << A >>
>"comp.arch.fpga" <ksulimma@googlemail.com> wrote in message 
>news:1188331867.465434.221240@22g2000hsm.googlegroups.com...
>> On 28 Aug., 15:23, "maxascent" <maxasc...@yahoo.co.uk> wrote:
>>> Hi
>>>
>>> I am designing a pcb with a Virtex 4 FX in a FF672 package. Is there
a
>>> general rule of how many layers the pcb will need to route out all
the
>>> pins?
>>
>> Most other posts are focussing on signal routing. But for FX this
>> really is
>> the least of your problems. The answer depends a lot on the MGT
>> performance
>> you are looking at. The MGTs need many supply voltages. Each of them
>> should
>> be filtered individually for high data rates. This means you either
>> need many islands,
>> which reduce plane capacitance and increase plane inductance. Or you
>> need many,
>> many planes.
>> For lower data rates (1.25gbps) you should be able to combine supplies
>> that have
>> the same voltage. This is not recommended by Xilinx, so your milage
>> might vary.
>>
>> Also, the MGTs pretty much prevent routing out signals on the top
>> layers.
>> As a result, an FX that uses all MGTs will need  more layers than an
>> LX.
>> We use 14 layers for an FX60-FF1152 with 12 MGTs at 5gbps.
>>
>> Kolja Sulimma
>>
>Hi Kolja,
>
>Although your suggestions will result in a working solution, I
respectfully 
>think you're overengineering this. The power supplies to the MGTs don't
need 
>islands or a plane. A 0402 cap right by the ball, fed from a ferrite is
as 
>good bypassing as you're going to get. The ferrite can be on the reverse

>side or far away from the device. All the stuff you read about plane 
>capacitance is over-rated for bypassing ICs, including BGAs. The
inductance 
>of the BGA's balls and connections to the die stuff means that the 
>admittedly ultra high Q of the plane capacitance is not much use at all,
so 
>why bother even trying? In this situation, with the power pins neear the

>edge of the part, it's much more useful to keep the ground plane as close
to 
>the surface as possible, than to worry about power planes.
>
>The microvia solution works perfectly for MGTs as these vias are more or

>less transparent to very high speeds indeed.
>
>Anyway, that's my experience.
>
>HTH., Symon.
>
>
>
>

Symon, do you follow the recommended filtering from the Xilinx MGT guide
i.e. caps and ferrites next to the BGA for all the supplies?

Jon

Article: 123682
Subject: Re: PCB Impedance Control
From: John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com>
Date: Sat, 01 Sep 2007 07:44:40 -0700
Links: << >>  << T >>  << A >>
On Thu, 30 Aug 2007 15:36:04 +0100, "Symon" <symon_brewer@hotmail.com>
wrote:

>"maxascent" <maxascent@yahoo.co.uk> wrote in message 
>news:ifidnQIYxf3YUUvbRVn_vw@giganews.com...
>>
>> Hi
>>
>> If I am designing a pcb using impedance controlled layers can I treat the
>> power planes as a reference layer as well as the gnd layers?
>>
>> Cheers
>>
>> Jon
>
>Hi Jon,
>Yes. But with a caveat. When your signals switch reference layers, make sure 
>there is a path for the reference current.
>
>E.g. Take a 6 layer board, layer 2 ground, layer 5 power. If the signal goes 
>from layer 1 to 6 through a via, you should have a bypass cap bewteen power 
>and ground near this via.


That's not necessary. There's already so much plane-plane capacitance
that the planes are already equipotential as far as the tiny charge
injected by the signal trace can affect them.

Really, on a board with, say, 3000 vias, are you going to put a bypass
via near every signal via? I've heard of people asking for two!

John



Article: 123683
Subject: Re: New keyword 'orif' and its implications
From: "comp.arch.fpga" <ksulimma@googlemail.com>
Date: Sat, 01 Sep 2007 16:24:55 -0000
Links: << >>  << T >>  << A >>
On 1 Sep., 02:13, Weng Tianxiang <wtx...@gmail.com> wrote:
> Hi Kolja,
> My opinion is when VHDL compilers get more information about mutually
> exclusive information, what you can do, the VHDL compilers can do
> better.
Yes. But mutual exclusiveness is only a small, special case of input
don't cares
(unreachable input combinations). The tools shoul dhave ways to
specify these,
not only mutual exclusiveness.
For example there might a vernier input that only has the valid
combinations
"0000", "0001", "0011", "0111", "1111". Mutual exclusiveness can not
provide this hint,
assertions can. Because of this the assertion based approach is
allready part of VHDL2006.
It is a very general approach, and of course there are special cases
for which a special
keyword makes live easier, but you still need to solve the general
case.
(Imaging how much simpler the design of a polynomial interpolation
would be, if VHDL had a
polynomial type and an interpolation keyword)

Because the formulation of these inputs sets can be a little
cumbersome, and because there
might be sequential depencies on these (and for a couple of other
reasons) PSL was included
as a way to specify assertion constraints.

> The above equation would be implemented in Xilinx chip with carry
> chain with initial input data to the carry chain being OutBus.
It will be synthesized to a gated or netlist. This is very the VHDL-
specific part ends.
The technology mapper will than select an appropriate implementation
for the or gate that
might be based on a carry chain implementation.

> The
> following enable equation would be eliminated from Jim's coding:
> (E0 or E1 or E2 or E3 or E4 or E5) = '1'
Yes. The formulation is redundant, even without knowledge of the input
don't cares.

> The above two example show that with mixed 'elsif' and 'orif'
> language branch statement structure, HDL will provide more powerful and
> concise way to deal with mutually ...
But nothing else but that. That is not enough.

> You are a doubtor of the technology,
How is that? I am the one that is telling you that your approach is to
limited and
does not utilize the power of logic synthesis to the possible extend.
Handling of
input don't cares is solved since the days of ATPG based synthesis.

As far as coding style goes: I prefer prefer to explicitly code that
the result is a don't care
for certain input conditions as to have this as an implicit side
effect of an operation.

Kolja Sulimma

P.S.: Here is another coding style, assuming the inputs and Es are in
arrays:

output := (others =>'-'); -- this line allows the compiler to do the
optimization, most compilers DECIDE against it
for i in input'range loop
   if e = (i=>'1', others=>'0') then output := intput(i);
end loop;



if you know the optimization and want to force it:
for i in input'range loop
   if e(i) = '1' then output := output or intput(i);
end loop;



Article: 123684
Subject: Re: comparison with embedded processor
From: "Daniel S." <digitalmastrmind_no_spam@hotmail.com>
Date: Sat, 01 Sep 2007 13:19:14 -0400
Links: << >>  << T >>  << A >>
mmihai wrote:
> On Aug 23, 8:33 am, mmihai <iia...@yahoo.com> wrote:
>> On Aug 23, 3:34 am, Frank Buss <f...@frank-buss.de> wrote:
>>
>>> bhb wrote:
>>>>  for (j = 1; j<=1000; j++)
>>>>     {
>>>>           for (k = 1; k<=1000; k=k+1)
>>>>                  {
>>>>                           result=k*k*a+j*b+c;
>>>>                   }
>>>>      }
>>> You can improve the speed of this code by a factor of 1 million:
>>> result=1000*1000*a+1000*b+c
>> Yes, you can, but your reduction of the sum of sum it is not
>> correct ...
>> Try again :-)
> 
> My bad, I've read result+=...
> 
> --
> mmihai

Actually, even if it was +=, as long as the boundaries are fixed, the two 
loops can be reduced by pre-calculating the sums of j and k^2...

1) sum of j over 1..1000 = 500500

Rewrite after eliminating the 'j' loop:

 >>>>   for (k = 1; k<=1000; k=k+1)
 >>>>         result += 1000*k*k*a + 500500*b + 1000*c;

2) sum of k^2 over 1..1000 = 333833500

Rewrite after eliminating the 'k' loop:

 >>>>   result = 333833500000*a + 500500000*b + 1000000*c;

There you are, the result of even += through the two loops without any loops.

Article: 123685
Subject: Re: Partial reconfiguration using ICAP
From: Sean Durkin <news_sep07@durkin.de>
Date: Sat, 01 Sep 2007 19:40:18 +0200
Links: << >>  << T >>  << A >>
ajith.thamara@gmail.com wrote:
> Can you explain how to do this.
>  What modification should I do in the code.
Probably just send a few bytes after the bitstream (just send some
zeroes). At least that's what I often have to do if I load bitstreams
from the outside (using a microcontroller on the FPGA's slave serial
interface).

HTH,
Sean

-- 
My email address is only valid until the end of the month.
Try figuring out what the address is going to be after that...

Article: 123686
Subject: Re: PCB Layers
From: "KJ" <kkjennings@sbcglobal.net>
Date: Sat, 01 Sep 2007 17:44:17 GMT
Links: << >>  << T >>  << A >>

"Symon" <symon_brewer@hotmail.com> wrote in message 
news:fbbii8$l8l$1@aioe.org...
> "comp.arch.fpga" <ksulimma@googlemail.com> wrote in message 
> news:1188331867.465434.221240@22g2000hsm.googlegroups.com...
> A 0402 cap right by the ball, fed from a ferrite is as good bypassing as 
> you're going to get. The ferrite can be on the reverse side or far away 
> from the device.
It can also be non-existent (i.e. tie right to the power plane instead of 
putting the series ferrite in).  The ferrites are a band aid to not having a 
low impedance voltage source feeding the IC in the first place.  Design the 
planes to have the proper impedance to deliver the required current over the 
operating frequency range in the first place and the voltage ripple will be 
within spec and you'll rightly start to question just what the ferrites 
bring to the table.

But if you insist on ferrites, don't forget that they are basically 
inductive (by intent) and then be careful about your bypassing caps since 
those Ls and Cs do form a resonant structure that is more likely to cause a 
problem with a poor choice of C then the plane was in the first place.  In 
other words, the 'output side' of the ferrites need to have the same set of 
low/mid/high frequency range bypass caps as you (hopefully) already provided 
on that supposedly nasty, noisy 'input side'.

> All the stuff you read about plane capacitance is over-rated for bypassing 
> ICs, including BGAs.
It provides a low inductance current source but is not a relatively deep 
bucket of charge to draw from due to the low C/area.  In any case, whether a 
full plane or strip it has some L and C and therefore Z that contributes to 
the IC's view of the voltage source...along with the bypass C and the PCB 
stackup, etc.

> The inductance of the BGA's balls and connections to the die stuff means 
> that the admittedly ultra high Q of the plane capacitance is not much use 
> at all, so why bother even trying?
I'd say, bother to analyze it first to determine what the Z requirements of 
the PCB need to be to source the power than to just blindly say why bother 
trying....but from earlier posts I also know you've done this as well so 
probably have a better grasp of the issues and tradeoffs in the first place.

KJ 



Article: 123687
Subject: Re: Memory bandwidth of the 3A kit
From: Antti <Antti.Lukats@googlemail.com>
Date: Sat, 01 Sep 2007 19:47:21 -0000
Links: << >>  << T >>  << A >>
On 31 Aug., 16:39, Simon <goo...@gornall.net> wrote:
> Antti, did you ever get a feel for what memory bandwidth you actually
> get with this setup ? For example, if you had a blockram being
> constantly filled from DDR2 ram, how many MB/sec you can actually pull
> over the bus ?
>
> Wondering whether to buy (yet another) starterkit ... [grin]
>
> Cheers,
>    S.

sorry, no :(
i wanted the s3a kit just to test the new s3a features like multiboot
have plenty of kits so can choose something for more performance if
needed
so cant help

Antti






Article: 123688
Subject: Re: Chip Designing made Easy
From: Antti <Antti.Lukats@googlemail.com>
Date: Sat, 01 Sep 2007 19:51:29 -0000
Links: << >>  << T >>  << A >>
On 31 Aug., 22:27, "John_H" <newsgr...@johnhandwork.com> wrote:
> Is this a legitimate post?  It comes across as an intelligent phrase
> generator that has some sense of electronics but in general the phrases
> don't come across as cohesive concepts.
>
> If it is legit, robin, please consider what you're trying to communicate.
> Maybe rereading the post will make you realize your phrasing leaves too m=
uch
> to the readers' imagination.
>
> "robin" <robinhood...@gmail.com> wrote in message
>
> news:1188589451.821393.49110@i38g2000prf.googlegroups.com...
>
>
>
> > Chip Designing Made easy To Understand the "World of Miniaturization"
> > and Appreciate the "Art of Chip Design" a senior citizen in the field
> > of Chip Design Industy Shares his Design Expertise.
>
> > Explains to Understand in a Birds Eye View point analogy of VLSI Chip
> > Architecture with an Building Construction Architecture, Detailed VLSI
> > Chip Design Flow, Enables Architectural Discussions and Thoughts in
> > Us, by querying ourselves if we are playing a role of a Chief
> > Architect, Best Design Practices in Front end & Backend world,
> > Discusses Todays hot topics and design issues, Checklists and lessons
> > learnt,
>
> > Learn the concepts of chip designing by visiting for free
> >http://www.vlsichipdesign.com/knowledgehome.html
>
> > I found this link,
> >http://www.microchip.com/wiki/- Zitierten Text ausblenden -
>
> - Zitierten Text anzeigen -

hahaah very funny - ASIC design website with "H1B visa FAQ" =EDn the
main page main menu!!

Antti


Article: 123689
Subject: Re: New keyword 'orif' and its implications
From: Weng Tianxiang <wtxwtx@gmail.com>
Date: Sat, 01 Sep 2007 17:14:25 -0700
Links: << >>  << T >>  << A >>
On Sep 1, 9:24 am, "comp.arch.fpga" <ksuli...@googlemail.com> wrote:
> On 1 Sep., 02:13, Weng Tianxiang <wtx...@gmail.com> wrote:> Hi Kolja,
> > My opinion is when VHDL compilers get more information about mutually
> > exclusive information, what you can do, the VHDL compilers can do
> > better.
>
> Yes. But mutual exclusiveness is only a small, special case of input
> don't cares
> (unreachable input combinations). The tools shoul dhave ways to
> specify these,
> not only mutual exclusiveness.
> For example there might a vernier input that only has the valid
> combinations
> "0000", "0001", "0011", "0111", "1111". Mutual exclusiveness can not
> provide this hint,
> assertions can. Because of this the assertion based approach is
> allready part of VHDL2006.
> It is a very general approach, and of course there are special cases
> for which a special
> keyword makes live easier, but you still need to solve the general
> case.
> (Imaging how much simpler the design of a polynomial interpolation
> would be, if VHDL had a
> polynomial type and an interpolation keyword)
>
> Because the formulation of these inputs sets can be a little
> cumbersome, and because there
> might be sequential depencies on these (and for a couple of other
> reasons) PSL was included
> as a way to specify assertion constraints.
>
> > The above equation would be implemented in Xilinx chip with carry
> > chain with initial input data to the carry chain being OutBus.
>
> It will be synthesized to a gated or netlist. This is very the VHDL-
> specific part ends.
> The technology mapper will than select an appropriate implementation
> for the or gate that
> might be based on a carry chain implementation.
>
> > The
> > following enable equation would be eliminated from Jim's coding:
> > (E0 or E1 or E2 or E3 or E4 or E5) = '1'
>
> Yes. The formulation is redundant, even without knowledge of the input
> don't cares.
>
> > The above two example show that with mixed 'elsif' and 'orif'
> > language branch statement structure, HDL will provide more powerful and
> > concise way to deal with mutually ...
>
> But nothing else but that. That is not enough.
>
> > You are a doubtor of the technology,
>
> How is that? I am the one that is telling you that your approach is to
> limited and
> does not utilize the power of logic synthesis to the possible extend.
> Handling of
> input don't cares is solved since the days of ATPG based synthesis.
>
> As far as coding style goes: I prefer prefer to explicitly code that
> the result is a don't care
> for certain input conditions as to have this as an implicit side
> effect of an operation.
>
> Kolja Sulimma
>
> P.S.: Here is another coding style, assuming the inputs and Es are in
> arrays:
>
> output := (others =>'-'); -- this line allows the compiler to do the
> optimization, most compilers DECIDE against it
> for i in input'range loop
>    if e = (i=>'1', others=>'0') then output := intput(i);
> end loop;
>
> if you know the optimization and want to force it:
> for i in input'range loop
>    if e(i) = '1' then output := output or intput(i);
> end loop;

Hi Kolja,
> The
> following enable equation would be eliminated from Jim's coding:
> (E0 or E1 or E2 or E3 or E4 or E5) = '1'


Yes. The formulation is redundant, even without knowledge of the
input
don't cares.

No, Jim's coding is the best coding we can do now. The equation is
never redundant !

-- It is Jim's coding
OutBusA : process(RESET, CLK)
begin
    if(RESET = '1') then
       OutBus <= (others=>'0');
    elsif rising_edge(CLK) then
       if (E0 or E1 or E2 or E3 or E4 or E5) = '1' then
         OutBus <=
           (E0 and Data0) or (E1 and Data1) or (E2 and Data2) or
           (E3 and Data3) or (E4 and Data4) or (E5 and Data5) ;
       end if ;
    end if ;
end process;

I write his type of coding everywhere in my design. It is really not a
high level language, but a ASM language writing at flip-flop levels in
name of high level language.

But if 'orif' is a new keyword, the situation may change, at least
from paper and theory. There is no FPGA VHDL compiler today that can
generate better code than Jim's coding.

That is the reason:
What you can do, VHDL compiler can do it better if it gets all
information about mutual exclusiveness.

As far as "don't care" situation is concerned, VHDL compile ignores it
at all. It is not a VHDL problem, it is a compiler problem. You must
distinguish VHDL language problem from compiler capability problem.

Thank you.

Weng


Article: 123690
Subject: Re: Strange behaviour of a design
From: Kunal <kunal.yadwadkar@gmail.com>
Date: Sun, 02 Sep 2007 00:45:29 -0000
Links: << >>  << T >>  << A >>
On Aug 30, 2:44 pm, markus.j...@gmx.de wrote:
> Hello,
>
> I am working with xilinx (Spartan 2E). The DSP is off chip.
>
> I hope I found the problem today. You are right. It was
> a timing issue. I have an Input to the state machine that doesn't met
> the timing
> requirements.
>
> It is a ready signal that is generated from a device.
> After the read strobe the device asserts a ready signal. I
> doublechecked the
> timing of this pin again and found out that it is difficult to met
> timing from
> the clock cycle (where read strobe goes low) to the max delay of the
> activated
> ready signal within a clock cycle. I thought the ready signal is
> stable long befor the next
> rising clock edge occurs (bit it isn'nt).
>
> Now I do synchronisation and put some sync states in the state machine
> to get a
> synchronous ready signal.
>
> I let you know about the result.
>
> Thanks a lot for your help.

Hi,

Just out of curiosity, what do you mean by _sync states_? (I'm a noob
as you can probably see, but at least I'm curious.... )


Kunal


Article: 123691
Subject: Re: Strange behaviour of a design
From: Kunal <kunal.yadwadkar@gmail.com>
Date: Sun, 02 Sep 2007 00:46:24 -0000
Links: << >>  << T >>  << A >>
Hi,

Really sorry for not snipping stuff off......

Kunal


Article: 123692
Subject: flip-flop enable
From: al.basili@gmail.com
Date: Sat, 01 Sep 2007 20:48:31 -0700
Links: << >>  << T >>  << A >>
Hi everyone,
I'm experiencing something weird in my code implementation that leaded
me to question which is the correct way to enable a flip-flop.
Assuming I have a clocked output of a FF one cycle long (*en*) which
will enable two different  sequential logics according to the value of
a signal *sel*, so *en1* and *en2* will be produced.
Which is the best way to produce *en1* and *en2*?

When I designed the logic the first time I was doing something like
this:

process (clk, nrst)
begin
  if nrst = '0' then
    en1 <= '0';
    en2 <= '0';
  elsif rising_edge (clk) then
    if sel = '0' then
      en1 <= en;
      en2 <= '0';
    else
      en1 <= '0';
      en2 <= en;
    end if;
  end if;
end process;

but then I thought it would have been as good as if I wrote (i didn't
care about the timing so it doesn't matter if *en1* and *en2* occur
earlier than what was in the previous implementation):

en1 <= en when sel = '0' else
       '0';

en2 <= en when sel = '1' else
       '0';

but unfortunately this shows some timing problem on my device because
sometimes the test vectors work and sometimes they look like the *en1*
or *en2* signal are not there (as if they where not one clock cycle
long).
I know the difference in the implementation of these two sets of logic
and i would consider the first one the best one a priori but I would
like someone could explain me if it is possible that the second
solution does not guarantee the signals *en1* and *en2* to be one
clock cycle long (or at least respect setup and hold time for the
driven FF)?
I had the thought that maybe the thresholds variation may effect the
phase of a signal but I don't think this is enough to explain the
problem.

Thanks for your attention.

Al


Article: 123693
Subject: Re: flip-flop enable
From: Ralf Hildebrandt <Ralf-Hildebrandt@gmx.de>
Date: Sun, 02 Sep 2007 10:01:24 +0200
Links: << >>  << T >>  << A >>
al.basili@gmail.com schrieb:

> process (clk, nrst)
> begin
>   if nrst = '0' then
>     en1 <= '0';
>     en2 <= '0';
>   elsif rising_edge (clk) then
>     if sel = '0' then
>       en1 <= en;
>       en2 <= '0';
>     else
>       en1 <= '0';
>       en2 <= en;
>     end if;
>   end if;
> end process;
...
> en1 <= en when sel = '0' else
>        '0';
> 
> en2 <= en when sel = '1' else
>        '0';
...
> I know the difference in the implementation of these two sets of logic
> and i would consider the first one the best one a priori but I would
> like someone could explain me if it is possible that the second
> solution does not guarantee the signals *en1* and *en2* to be one
> clock cycle long (or at least respect setup and hold time for the
> driven FF)?


With the 1st solution you sample the signals en and sel. The outputs of
the flipflops en1 and en2 are stable from the rising edge of clk to the
next rising edge.

Meanwhile en and sel may be hazarderous. With the flipflop solution
these hazards are no problem, but for the 2nd combinational solution
this may be a problem.

Furthermore: If you use flipflops, then you break a timing path from the
points where en and sel are driven to the points where en1 and en2 are
read. With the flipflops you split this path into to paths.

Ralf

Article: 123694
Subject: Re: New keyword 'orif' and its implications
From: "comp.arch.fpga" <ksulimma@googlemail.com>
Date: Sun, 02 Sep 2007 03:23:21 -0700
Links: << >>  << T >>  << A >>
On 2 Sep., 02:14, Weng Tianxiang <wtx...@gmail.com> wrote:
 > As far as "don't care" situation is concerned, VHDL compile ignores
it
> at all. It is not a VHDL problem, it is a compiler problem. You must
> distinguish VHDL language problem from compiler capability problem.

Finally you get my point. There is no need to change the language, you
only
need to change the compiler to support the existing language features:
 - interpretation of assertions to deduce reachability don't cares.
- honoring output observability don't cares coded as '-' during
optimization

Again: The existing language features can do a lot more than mutual
exclusiveness.
You only need compilers that use them. Adding a keyword for a special
case to the
language will only delay adoption of the general case.

Kolja Sulimma


Article: 123695
Subject: Re: New keyword 'orif' and its implications
From: Weng Tianxiang <wtxwtx@gmail.com>
Date: Sun, 02 Sep 2007 03:54:33 -0700
Links: << >>  << T >>  << A >>
On Sep 2, 3:23 am, "comp.arch.fpga" <ksuli...@googlemail.com> wrote:
> On 2 Sep., 02:14, Weng Tianxiang <wtx...@gmail.com> wrote:
>  > As far as "don't care" situation is concerned, VHDL compile ignores
> it
>
> > at all. It is not a VHDL problem, it is a compiler problem. You must
> > distinguish VHDL language problem from compiler capability problem.
>
> Finally you get my point. There is no need to change the language, you
> only
> need to change the compiler to support the existing language features:
>  - interpretation of assertions to deduce reachability don't cares.
> - honoring output observability don't cares coded as '-' during
> optimization
>
> Again: The existing language features can do a lot more than mutual
> exclusiveness.
> You only need compilers that use them. Adding a keyword for a special
> case to the
> language will only delay adoption of the general case.
>
> Kolja Sulimma

Hi Kolja,
"at all. It is not a VHDL problem, it is a compiler problem. You must
distinguish VHDL language problem from compiler capability problem. "

In above sentence, what I had refered to is the case of 'dont' care'
you mentioned in your example, not the 'orif' case.

Verilog introduction of 'unique' and other related functions has
showed that mutually exclusiveness in HDL needed to be added and
improved.

Weng


Article: 123696
Subject: Re: PCB Impedance Control
From: "Symon" <symon_brewer@hotmail.com>
Date: Sun, 2 Sep 2007 13:15:25 +0100
Links: << >>  << T >>  << A >>
"John Larkin" <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote in message 
news:oduid31vs6ln11b62visqug6ql7rostl1f@4ax.com...
>>
>>Hi Jon,
>>Yes. But with a caveat. When your signals switch reference layers, make 
>>sure
>>there is a path for the reference current.
>>
>>E.g. Take a 6 layer board, layer 2 ground, layer 5 power. If the signal 
>>goes
>>from layer 1 to 6 through a via, you should have a bypass cap bewteen 
>>power
>>and ground near this via.
>
>
> That's not necessary. There's already so much plane-plane capacitance
> that the planes are already equipotential as far as the tiny charge
> injected by the signal trace can affect them.
>
> Really, on a board with, say, 3000 vias, are you going to put a bypass
> via near every signal via? I've heard of people asking for two!
>
> John
>
Hi John,
I wish that was always the case! There are problems relying solely on the 
interplane capacitance. There will be an impedance discontinuity at the via 
no matter what, but using solely the interplane capacitance increases this 
discontinuity. Clearly the inductance of the signal in this case is higher. 
Also, if a bus does the transistion, all the even mode effects add up. 
Finally, the high Q of the planes means you are vulnerable to plane 
resonances.

http://www.sigrity.com/papers/epep2000/QC-JZ-EPEP2000-Final.pdf
http://www.hottconsultants.com/techtips/pcb-stack-up-6.html
http://dspace.kaist.ac.kr/bitstream/10203/664/1/effectof.pdf

Clearly putting a bypass cap at every via is impractical, and if you re-read 
my post, that is not what I suggested. However, I stand by my recommendation 
that in places where many nets and/or critial nets change reference planes, 
a bypass capacitor nearby is important. Clearly, a single capacitor, perhaps 
connected with multiple vias to the planes, can be shared by many signal 
vias, as it will have a lot more capacitance than, for example, the planes 
can provide.

HTH., Syms. 



Article: 123697
Subject: Re: PCB Layers
From: "Symon" <symon_brewer@hotmail.com>
Date: Sun, 2 Sep 2007 13:20:32 +0100
Links: << >>  << T >>  << A >>
"maxascent" <maxascent@yahoo.co.uk> wrote in message 
news:2vqdnfKs0-uR7UTb4p2dnAA@giganews.com...
>
> Symon, do you follow the recommended filtering from the Xilinx MGT guide
> i.e. caps and ferrites next to the BGA for all the supplies?
>
> Jon

Hi Jon,
Yes for the caps and ferrite. I disagree with their recommendation for 
linear regulators to filter the supplies as these regulators do not have 
sufficient bandwidth to control noise > a few 100kHz. I use passive 
filtering also to cover the range from the linear regs up until the ferrites 
work.
HTH., Syms. 



Article: 123698
Subject: Re: Spartan3E and DDR termination
From: Guru <ales.gorkic@email.si>
Date: Sun, 02 Sep 2007 05:34:51 -0700
Links: << >>  << T >>  << A >>
On 31 avg., 14:31, Brian Drummond <brian_drumm...@btconnect.com>
wrote:
> On Thu, 30 Aug 2007 01:59:33 -0700, Guru <ales.gor...@email.si> wrote:
> >Hi all,
>
> >We are building a board with Spartan3E (XC3S1200E FG320) and a 64MB
> >x16 DDR (HYB25DC512160CF-6). Trying to make the board as tiny as
> >possible the DDR termination presents a problem. Since the Spartan3E
> >does not have DCI, termination on chip is not possible. This means
> >that 44 termination resistors should be added and maybe a VTT power
> >source. The other problem is that according to MIG we should connect
> >DDR to two banks.
>
> >Any good suggestions?
> >Is it possible to eliminate termination resistors?
>
> As Gabor suggests, it may be possible to eliminate the series
> terminations if traces are kept short enough.
>
> If you also want to eliminate the parallel terminations to VTT, consider
> moving to DDR-II, where you can use the On-Die Termination (ODT)
> instead. It means a little extra design complexity, and 1.8V supplies,
> but if space is important enough it may be worth considering.
>
> - Brian

We already considered using a DDR2 since it enables ODT.
The only thing I am afraid of is the minimal frequency of 125MHz.
This means that carefull FPGA pinout selection is a must (e.g MIG
layout).
The other problem are huge memory controllers; MCH_OPB_DDR2 takes
approx 1500 slices.

What about 8 bit DDR2? This way I can get away with only one FPGA bank
and layout to MIG rules.
Did anyone used it with MPMC2 (x8 is not supported by MCH_OPB_DDR2)?

Cheers,

Guru


Article: 123699
Subject: Re: PCB Layers
From: "Symon" <symon_brewer@hotmail.com>
Date: Sun, 2 Sep 2007 13:41:59 +0100
Links: << >>  << T >>  << A >>
Hi, some comments in line...

"KJ" <kkjennings@sbcglobal.net> wrote in message 
news:RxhCi.4629$JD.252@newssvr21.news.prodigy.net...
>
> "Symon" <symon_brewer@hotmail.com> wrote in message 
> news:fbbii8$l8l$1@aioe.org...
>> "comp.arch.fpga" <ksulimma@googlemail.com> wrote in message 
>> news:1188331867.465434.221240@22g2000hsm.googlegroups.com...
>> A 0402 cap right by the ball, fed from a ferrite is as good bypassing as 
>> you're going to get. The ferrite can be on the reverse side or far away 
>> from the device.
> It can also be non-existent (i.e. tie right to the power plane instead of 
> putting the series ferrite in).  The ferrites are a band aid to not having 
> a low impedance voltage source feeding the IC in the first place.  Design 
> the planes to have the proper impedance to deliver the required current 
> over the operating frequency range in the first place and the voltage 
> ripple will be within spec and you'll rightly start to question just what 
> the ferrites bring to the table.
>
Remember that the ferrites are useful in both directions. Not only to they 
stop noise getting to the MGT, but prevent the noise from the MGT getting 
back to the supply and interfering with other stuff powered from it.
>
> But if you insist on ferrites, don't forget that they are basically 
> inductive (by intent) and then be careful about your bypassing caps since 
> those Ls and Cs do form a resonant structure that is more likely to cause 
> a problem with a poor choice of C then the plane was in the first place. 
> In other words, the 'output side' of the ferrites need to have the same 
> set of low/mid/high frequency range bypass caps as you (hopefully) already 
> provided on that supposedly nasty, noisy 'input side'.
>
OK, but ferrites are deliberately lossy. A useful model is an indcutor in 
series with a resistor. This means bad resonances don't happen with 
ferrites.

Cheers, Syms. 





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