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 146675

Article: 146675
Subject: Re: EMC discussion
From: nico@puntnl.niks (Nico Coesel)
Date: Thu, 25 Mar 2010 23:02:44 GMT
Links: << >>  << T >>  << A >>
Symon <symon_brewer@hotmail.com> wrote:
>On 3/25/2010 1:10 AM, Thomas Entner wrote:
>> As I think, many FPGA-designers have also to deal with EMC, I hope
>> someone can help me here. We have currently some discussions (and
>> doubts) regarding EMC-topics. As many people have different opinions
>> on this subject, and it is quite hard to objectively verify, I would
>> like to ask for some comments about following:
>>
>> 1. Filtering of IC-supply-voltage
>> While it is quite standard to filter e.g. the PLL-supply voltages of a
>> FPGA, there are some suggestions to filter the supply-voltage of every
>> IC (CPU, FPGA, memory, ...) on the PCB with a ferrite-bead + C.
>> (Consequently, this also means that every IC has it's own Vdd-island
>> in the power-plane.) Does this work?
>>
>> 2. Return-path on Vdd-plane
>> It is pretty clear that a solid ground-plane is required for return-
>> path of I/O-signals. Most people also agree, that a power-plane will
>> also do this job. But is this only because of the bypass-caps? Or is
>> the "native" return-current flowing on ground when the output-driver
>> is sinking and on Vdd when the output-driver is sourcing (assuming a
>> high-impedance destination), i.e. it would be perfect to have both
>> planes close to the signal-line?
>>
>> 3. Shields of connectors, chassis ground
>> Most PCBs have one or more connectors with shields (e.g. USB, RJ45,
>> VGA, RS-232,...) Do you connect these directly to circuit-ground? Or
>> with C and R in parallel? Or do you have some kind of "frame-ground"?
>> Have you the mounting holes grounded to the chassis? All or just one?

>Hi Thomas,
>
>1) Yes. That will keep noise from coupling between devices.
>2) Only nutters have power planes. They use up valuable space in which 
>you could more profitably use a ground plane.

OK if you have enough decoupling on every pin.

>3) Bond it all together. Unless you have to have isolation from 
>dangerous voltages.

I feel more comfortable to put a bead between the shield and the
ground. Keeps HF current inside / breaks HF pickup loops when wiring
equipment together.

>If anyone wants to disagree with this advice, I want a specific, first 
>person example where what I suggest is wrong. I don't want to hear what 
>some 'guru' told you on a course you paid for. :-)
>
>Symsx.
>
>
>

-- 
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
nico@nctdevpuntnl (punt=.)
--------------------------------------------------------------

Article: 146676
Subject: Re: EMC discussion
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Thu, 25 Mar 2010 23:29:08 +0000 (UTC)
Links: << >>  << T >>  << A >>
Symon <symon_brewer@hotmail.com> wrote:
> On 3/25/2010 6:13 PM, Kolja Sulimma wrote:
(snip)
>> Well, how do you create a low inductance path to the next capacitor?
>> You do not necessarily need a full plane, but making sure there is a
>> low inductance path quickly gets very cumbersome.
 
> You use copper pours and puddles around the IC to link its bypass 
> capacitors.
 
>> A power plane is as good a reference for a signal as a ground plane
>> and the PCB stack needs to be symmetric anyway. So what is the 
>> disadvantage of having a power plane as layer 2 when there is 
>> a gnd in layer N-2?
 
> 1) The stack up does not need to be symmetrical wrt to planes and signal 
> layers. However, you should make the substrates symmetrical. I have made 
> several boards that aren't plane symmetrical. Talk to your PCB vendor. 
> (Some of these boards were about 12x8 inches and didn't warp.)

> 2) When a signal trace passes from layer 1 to layer N-1, its reference 
> plane has now changed. If this signal has a fast rise time, you have to 
> use a bypass capacitor nearby, with its attendant inductance, and via 
> inductance. With two ground planes, a regular via is enough.

As I understand it, that mostly isn't true.  For a reasonably plane
there is enough capacitance around to get the signal across from
one to the other.  

> 3) You make an interesting point when you say that a power plane is as 
> good as a ground plane as a reference. This is true. The problem comes 
> that you now have two references in your system, and they will have some 
> small noise voltage between them. You can reduce this to a small amount 
> of noise with capacitors, but for each power plane, you have to do this. 
> With multiple ground planes, they are all bonded together with the 
> ground vias in your board.

Note that a single wire has inductance, and a single plane has
capacitance.  Even without another plane nearby, the capacitance
of a ground plane isn't so bad.  With another plane nearby, though,
it is somewhat higher.  At the higher frequencies, it is the plane
capacitance that you see.  At lower, but still plenty high frequencies,
the actual bypass capacitors become more important.
 
>> Putting a GND plane there instead will waste more space with 
>> no gain (as you still need to route the power signals somewhere) 
>> and putting no plane in that layer will result in a bent board.
 
> Indeed, you need to put the powers somewhere. I recommend routing them 
> all on a couple of dedicated layers away from signal traces. On an FPGA 
> with at least 1.2V, 1.8V, 2.5V and 3.3V rails, which of these are you 
> suggesting will be on a plane? All of them?
 
> (Again, the bent board thing is a fallacy, I have found.)

>> Also, adjacent power planes provide multi GHz decoupling that is next
>> to impossible to achieve with soldered capacitors.

> We've been here before. It has a small amount of capacitance, which 
> doesn't help you because the multi-GHz can't get up the vias and balls 
> into the dice. Think of it this way, the reason a soldered capacitor 
> doesn't give you multi-GHz is the fact that you have to connect to it. 
> Actually in the ceramic of the cap is multi-GHz. It's the same with 
> connecting your chips to a adjacent-plane-made capacitor.

Pin inductance is significant, and there isn't anything you can do
about that on the board.  Getting a reasonably low impedance to
the pin is the best you can do, and that is still worth doing.
 
> Of course, what this arrangement does also provide is the possibility of 
> multi-GHz resonances in your power planes. Lovely. Using a ground plane 
> where ever a reference plane is needed makes the SI design very simple 
> indeed.

There was a question on a different post about the relative
importance of noise on the ground vs. power pins.

-- glen

Article: 146677
Subject: Re: EMC discussion
From: Symon <symon_brewer@hotmail.com>
Date: Fri, 26 Mar 2010 01:26:09 +0000
Links: << >>  << T >>  << A >>
On 3/25/2010 11:29 PM, glen herrmannsfeldt wrote:
>> inductance. With two ground planes, a regular via is enough.
>
> As I understand it, that mostly isn't true.  For a reasonably plane
> there is enough capacitance around to get the signal across from
> one to the other.
>
Enough? Care to fill in any numbers? :-)

>
> Note that a single wire has inductance, and a single plane has
> capacitance.  Even without another plane nearby, the capacitance
> of a ground plane isn't so bad.  With another plane nearby, though,
> it is somewhat higher.  At the higher frequencies, it is the plane
> capacitance that you see.  At lower, but still plenty high frequencies,
> the actual bypass capacitors become more important.
>
A single plane, like one hand clapping, has a capacitance to the inside 
of a hollow infinite conducting sphere. As such, it is as much use here 
as a chocolate teapot. Everything has the same capacitance to the 
aether. The planet earth has a capacitance of nearly a millifarad. 
Perhaps I should connect my 3.3V supply to that?

>
> Pin inductance is significant, and there isn't anything you can do
> about that on the board.  Getting a reasonably low impedance to
> the pin is the best you can do, and that is still worth doing.
>
No it isn't worth doing. I posted a spice cct showing that about a month 
ago. Please try it out yourself.

>> Of course, what this arrangement does also provide is the possibility of
>> multi-GHz resonances in your power planes. Lovely. Using a ground plane
>> where ever a reference plane is needed makes the SI design very simple
>> indeed.
>
> There was a question on a different post about the relative
> importance of noise on the ground vs. power pins.
>
> -- glen

Glen, I beg your pardon, but I wonder, do you design circuit boards for 
a living? I'd love to see one! :-)

Cheers, Syms.

Article: 146678
Subject: Re: EMC discussion
From: Symon <symon_brewer@hotmail.com>
Date: Fri, 26 Mar 2010 01:27:15 +0000
Links: << >>  << T >>  << A >>
On 3/25/2010 8:26 PM, Thomas Entner wrote:
> Thank you everyone for the comments, it is an very interesting
> reading.  I already got a lot of input for a new PCB-design, from
> which we will do some variants to check which EMC-solution works best.
> Looks like we need more variants than originally planned...
>
> Thomas

Hi Thomas,
Will you post back with the results of your testing?
Thanks, Syms.

Article: 146679
Subject: Re: Any advice on which is the best book on CMOS digital circuit
From: Weng Tianxiang <wtxwtx@gmail.com>
Date: Thu, 25 Mar 2010 18:35:26 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 17, 12:21=A0pm, Weng Tianxiang <wtx...@gmail.com> wrote:
> On Mar 16, 11:44=A0pm, Kim Enkovaara <kim.enkova...@iki.fi> wrote:
>
> > Weng Tianxiang wrote:
> > > I want to buy books on =A0CMOS digital circuit designs. Any advice on
> > > which is the best book on CMOS digital circuit design?
>
> > At least "Nanometer CMOS ICs, From Basics to ASICs" written by Harry
> > Veendrick is quite nice overall book and is up to date with the
> > technology. The only problem with the book is the price, which is
> > quite high.
>
> > --Kim
>
> Hi Kim,
> Thank you for your recommendation.
>
> The book contains materials of full procedures to make an ASIC in
> nanometer CMOS.
>
> I just want CMOS logic circuit in nanometer in 32um technology, for
> example, domino logic, time borrowing, how to expand an adder
> operation into 15 levels and something like that.
>
> I have ordered two books on Internet:
>
> 1. Principles of CMOS VLSI Design (Hardcover), second edition, 1992
>
> ~ Neil H. E. Weste (Author), Kamran Eshraghian (Author)
>
> $0.01
> + $3.99shipping
>
> 2. Logical Effort: Designing Fast CMOS Circuits (The Morgan Kaufmann
> Series in Computer Architecture and Design) by Ivan Sutherland, Robert
> F. Sproull, and David Harris (Paperback - Feb. 16, 1999)
> Buy new: $69.95 $62.95
>
> 7 new from $30.00
> 16 used from $24.25
>
> I may buy another book "Principles of CMOS VLSI Design (Hardcover)",
> third edition, 2010, written by =A0Neil H. E. Weste and David Harris
> when I finish reading the second edition.
>
> Weng

Hi,
I have received both books:
1. Principles of CMOS VLSI Design (Hardcover), second edition, 1992
 Neil H. E. Weste (Author), Kamran Eshraghian (Author)
2.  Logical Effort: Designing Fast CMOS Circuits (The Morgan Kaufmann
Series in Computer Architecture and Design) by Ivan Sutherland, Robert
F. Sproull, and David Harris (Paperback - Feb. 16, 1999).

After brief reviewing,
The first one is really good so why it receives more than 3k
references in Google search. I have no any knowledge about CMOS. Now
after reading I may have a full picture of it.
It is a background knowledge and I like it even though it was
published in 1992.
The second one is basically useless.
The reason is the estimate of a logic speed and how they are generated
in most efficient way
are the topics of HDL compilers and it becomes other people's
business, not a digital logic designer's business.

Weng

Article: 146680
Subject: Newbie Coding Question
From: David Wiltshire <dw_56@hotmail.com>
Date: Thu, 25 Mar 2010 18:48:13 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi guys,

I'm a newbie to Hardware coming from a software background.  I've done
a bit of reading but haven't got around to coding anything much.
Anyway, I had a question (which is probably basic) about how to code
datapath type problems.  I'll try a fairly simple problem in the
design I'll be doing:

in C code:

uint16_t calc(uint16_t a, uint16_t b, uint16_t c, uint16_t d)
{
   return (a*b + c*d)/(b + d)
}

Obviously not the best thing to be doing in hardware.  I ran it
through the free c-to-verilog compiler online and it produced some
very convoluted verilog code (suprise, suprise!) and so I thought I
can do much better.

Verilog:

module calc(
  input a[15:0];
  input b[15:0];
  input c[15:0];
  input d[15:0];

  output result[15:0];

  input clk;

  reg tmp0;
  reg tmp1;
  reg tmp2;

  wire ab;
  wire cd;
  wire bd;

  wire res;

  assign ab = a * b;
  assign cd = c * d;
  assign bd = b + d;

  assign res = (tmp0 + tmp1) / tmp2

  always @ (posedge clk)
  begin
     tmp0 <= ab;
     tmp1 <= cd;
     tmp2 <= bd;

     result <= res;

  end

}

Okay so it needs reset added and some other things to handle overflow,
etc.  Let's just assume that's not a problem (it's a problem with the
C code also - and I know how to solve it).  My question is this: my
verilog implies a 2 clock cycle calculation.  But there are other area/
speed possibilities: eg use on multiplier and pipeline the two
calculations to save on area but take more clock cyles.  Also in order
to get a faster clock cycle it's possible for the multiples to be
calculated over several clock cycles (I don't want to write the
multiplier I was just going to let the FPGA tool put in whatever
multiplier they already have - I haven't looked at how to do that
yet ... but it's not the issue I'm trying to address here).

Mostly I want to know how does one synchronise the datapath with the
control path.  Eg say these inputs are used on a different module also
and I want to know when the result is updated to use it with some
other calculation I did in parallel.  How do I know how many clocks it
takes (and do I have to code or is it possible to be flexible to do
trade offs later?).

Also, do I add an enable input and a ready output to my module to
model the function call and return of C or how do I handle these
syncronisations?

Thanks in advance for any help,
Dave

Article: 146681
Subject: Re: EMC discussion
From: John_H <newsgroup@johnhandwork.com>
Date: Thu, 25 Mar 2010 19:33:13 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 25, 7:29=A0pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:

> > 2) When a signal trace passes from layer 1 to layer N-1, its reference
> > plane has now changed. If this signal has a fast rise time, you have to
> > use a bypass capacitor nearby, with its attendant inductance, and via
> > inductance. With two ground planes, a regular via is enough.
>
> As I understand it, that mostly isn't true. =A0For a reasonably plane
> there is enough capacitance around to get the signal across from
> one to the other. =A0

Not only no but hail no.  The only way for the current to get from one
side of the board to the other is through capacitors.  The distributed
capacitance within two very close planes as measured in units of
picofarads per square inch is relatively miserable.  There are exotic
materials where an extremely thin prepreg with copper that's applied
differently than normal so the "smooth" rolled sides face each other
rather than the rough side.  I don't know anyone that's used those
materials.  Move two planes many mils apart and the capacitance drops
off.  Have more than one plane between start and finish of the signal
and you have multiple capacitors in series.  That's a bad thing,
right?  Capacitors in series show significantly lower overall
capacitance when compared to the individual caps.


> Note that a single wire has inductance, and a single plane has
> capacitance. =A0Even without another plane nearby, the capacitance
> of a ground plane isn't so bad.

I'm sincerely wondering where you get your levels of magnitude for
reference.  Can you provide a picofarad per square inch value for the
capacitance of a plane to earth ground?  I know fully about self
inductance but never in my days of electromagnetics graduate work was
the concept of self-capacitance of a plane considered in my admittedly
fading recollection.  Capacitance needs two bodies.  I can only assume
the other body is earth ground in your description.

For EMI and for crosstalk, the loop formed by the currents - forward
and return - determine how much signal is "shared."

Article: 146682
Subject: Re: Newbie Coding Question
From: Muzaffer Kal <kal@dspia.com>
Date: Thu, 25 Mar 2010 19:52:01 -0700
Links: << >>  << T >>  << A >>
On Thu, 25 Mar 2010 18:48:13 -0700 (PDT), David Wiltshire
<dw_56@hotmail.com> wrote:

>Hi guys,
>
>I'm a newbie to Hardware coming from a software background.  I've done
>a bit of reading but haven't got around to coding anything much.
>Anyway, I had a question (which is probably basic) about how to code
>datapath type problems.  I'll try a fairly simple problem in the
>design I'll be doing:
>
>in C code:
>
>uint16_t calc(uint16_t a, uint16_t b, uint16_t c, uint16_t d)
>{
>   return (a*b + c*d)/(b + d)
>}
>
>Obviously not the best thing to be doing in hardware.  I ran it
>through the free c-to-verilog compiler online and it produced some
>very convoluted verilog code (suprise, suprise!) and so I thought I
>can do much better.
>
>Verilog:
>
>module calc(
>  input a[15:0];
>  input b[15:0];
>  input c[15:0];
>  input d[15:0];
>
>  output result[15:0];
>
>  input clk;
>
>  reg tmp0;
>  reg tmp1;
>  reg tmp2;
>
>  wire ab;
>  wire cd;
>  wire bd;
>
>  wire res;

You need to size these registers correctly. Probably 
reg [31:0] ab; etc would be what you want. 

>
>  assign ab = a * b;
>  assign cd = c * d;
>  assign bd = b + d;
>
>  assign res = (tmp0 + tmp1) / tmp2

You don't mention it in the rest of your post but you'll find that
this divide by tmp2 would give you the biggest headache. Multipliers
are easy. All synthesis tools know how to either infer them to use the
macros or implement them in the fabric. Dividers are difficult (to
optimize that it) especially when they have a non-constant
denominator.

-- 
Muzaffer Kal

DSPIA INC.
ASIC/FPGA Design Services

http://www.dspia.com

Article: 146683
Subject: where is VHDL-POSIX ?
From: whygee <yg@yg.yg>
Date: Fri, 26 Mar 2010 03:55:32 +0100
Links: << >>  << T >>  << A >>
Hello,

A long time ago I have heard about VHDL-POSIX.
however today, when I need it, the website is dead
http://savannah.nongnu.org/projects/vhdl-posix/
and nothing can be downloaded.

What has become of this project and his maintainers?
Is there anything similar ?
Is there an old archive where I can read the source code ?
Should I rewrite all I need instead ?

yg
-- 
http://ygdes.com / http://yasep.org

Article: 146684
Subject: Re: Newbie Coding Question
From: David Wiltshire <dw_56@hotmail.com>
Date: Thu, 25 Mar 2010 20:22:28 -0700 (PDT)
Links: << >>  << T >>  << A >>
>
> > =A0assign res =3D (tmp0 + tmp1) / tmp2
>
> You don't mention it in the rest of your post but you'll find that
> this divide by tmp2 would give you the biggest headache. Multipliers
> are easy. All synthesis tools know how to either infer them to use the
> macros or implement them in the fabric. Dividers are difficult (to
> optimize that it) especially when they have a non-constant
> denominator.
>

Okay, the divider is the trickier of the two - I just looked and I see
that now.  Still FPGA synthesis software includes cores for dividers.
Still my main question is about timing.  The division is going to
occur over multiple clock cycles.  How does this impact my design
(especially compared to other operations which happen in shorter
periods of time) and how do I make sure that the result of this
function is synchronised with other functions?

Article: 146685
Subject: Re: XST optimization
From: David Wiltshire <dw_56@hotmail.com>
Date: Thu, 25 Mar 2010 20:24:32 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 26, 6:06=A0am, Jason Thibodeau <jason.p.thibod...@gmail.com>
wrote:
> Is it possible to get a detailed report out of XST, listing the gates it
> has optimized out of a design? XST is removing some gates that I
> specifically put into a design, and I want to prevent this. I can use
> the XST constraints file, but I'd like to see exactly what it is doing.
>
> Googling hasn't turned up much, yet.
>
> Thanks
> --
> Jason Thibodeau

Not that I'm experienced but whenever I've seen a similar question
(missing logic) it's been optomised out because you haven't connected
the output to anything.  Try connecting it to a pin out (even if
that's not where you want it eventually) and see if it turns up.

Dave

Article: 146686
Subject: Re: where is VHDL-POSIX ?
From: Amal <akhailtash@gmail.com>
Date: Thu, 25 Mar 2010 20:36:00 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 25, 10:55=A0pm, whygee <y...@yg.yg> wrote:
> Hello,
>
> A long time ago I have heard about VHDL-POSIX.
> however today, when I need it, the website is deadhttp://savannah.nongnu.=
org/projects/vhdl-posix/
> and nothing can be downloaded.
>
> What has become of this project and his maintainers?
> Is there anything similar ?
> Is there an old archive where I can read the source code ?
> Should I rewrite all I need instead ?
>
> yg
> --http://ygdes.com/http://yasep.org

Try CVS and get a snapshot of the sources.  You can look at the
sources here:

http://cvs.savannah.gnu.org/viewvc/?root=3Dvhdl-posix

-- Amal

Article: 146687
Subject: Re: where is VHDL-POSIX ?
From: whygee <yg@yg.yg>
Date: Fri, 26 Mar 2010 05:49:10 +0100
Links: << >>  << T >>  << A >>
Hi,

Amal wrote:
> Try CVS and get a snapshot of the sources.  You can look at the
> sources here:
> 
> http://cvs.savannah.gnu.org/viewvc/?root=vhdl-posix

thanks,

Any news from the author ?
Has anybody used, ported or modified this recently ?
This may sound curious or stupid but I need
exactly these functionalities today,
but they are written for an old Modelsim and I use GHDL :-/
If I can avoid reintenting the wheel, I'll save a lot of time...

regards,

> -- Amal
yg

-- 
http://ygdes.com / http://yasep.org

Article: 146688
Subject: Re: EMC discussion
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Fri, 26 Mar 2010 05:42:29 +0000 (UTC)
Links: << >>  << T >>  << A >>
John_H <newsgroup@johnhandwork.com> wrote:
(snip)
 
> I'm sincerely wondering where you get your levels of magnitude for
> reference.  Can you provide a picofarad per square inch value for the
> capacitance of a plane to earth ground?  I know fully about self
> inductance but never in my days of electromagnetics graduate work was
> the concept of self-capacitance of a plane considered in my admittedly
> fading recollection.  Capacitance needs two bodies.  I can only assume
> the other body is earth ground in your description.

It comes out easily if you do electrodynamics in CGS (gaussian)
units.  The unit of capacitance is the centimeter and, without
trying too hard, you find that it is the capacitance of a sphere
of the specified radius.  Concider a concentric sphere capacitor
in the limit that the outer sphere radius goes to infinity.
The conversion factor to SI units is 4*pi*e0, or about 1.1 pF/cm.

As with inductance, you can also do it though potential
energy.  0.5*C*V**2 is the energy in a capacitor, which
is equal to the energy in the electric field integrated
over all space.  (For ordinary capacitors, most of the
energy is inside.)  0.5*C*V**2=0.5*epsilon*the integral
over all space of E**2*dv  (E is electric field, v is volume).
 
> For EMI and for crosstalk, the loop formed by the currents - forward
> and return - determine how much signal is "shared."

Yes, including the effect of any capacitors in the circuit.

-- glen

Article: 146689
Subject: Re: Newbie Coding Question
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Fri, 26 Mar 2010 06:01:11 +0000 (UTC)
Links: << >>  << T >>  << A >>
David Wiltshire <dw_56@hotmail.com> wrote:
 
> I'm a newbie to Hardware coming from a software background.  I've done
> a bit of reading but haven't got around to coding anything much.
> Anyway, I had a question (which is probably basic) about how to code
> datapath type problems.  I'll try a fairly simple problem in the
> design I'll be doing:
 
> in C code:
 
> uint16_t calc(uint16_t a, uint16_t b, uint16_t c, uint16_t d)
> {
>   return (a*b + c*d)/(b + d)
> }

It is much easier if you don't try to think of it in
terms of software.  Think in terms of wires and logic
blocks connected together.  
 
> Obviously not the best thing to be doing in hardware.  I ran it
> through the free c-to-verilog compiler online and it produced some
> very convoluted verilog code (suprise, suprise!) and so I thought I
> can do much better.
 
(snip)

>  assign ab = a * b;
>  assign cd = c * d;
>  assign bd = b + d;
>  assign res = (tmp0 + tmp1) / tmp2
>  always @ (posedge clk)
>  begin
>     tmp0 <= ab;
>     tmp1 <= cd;
>     tmp2 <= bd;
>     result <= res;
>  end
(snip)

How did you decide where to put in the latch?  (The result
of the always @() block?
 
> Okay so it needs reset added and some other things to handle overflow,
> etc.  Let's just assume that's not a problem (it's a problem with the
> C code also - and I know how to solve it).  My question is this: my
> verilog implies a 2 clock cycle calculation.  But there are other area/
> speed possibilities: eg use on multiplier and pipeline the two
> calculations to save on area but take more clock cyles.  Also in order
> to get a faster clock cycle it's possible for the multiples to be
> calculated over several clock cycles (I don't want to write the
> multiplier I was just going to let the FPGA tool put in whatever
> multiplier they already have - I haven't looked at how to do that
> yet ... but it's not the issue I'm trying to address here).

Verilog, and so synthesis tools, won't put in any registers
that you don't ask for.  If you write a*b that implies a 
combinatorial multiplier.  That is, a block that will generate
the product with an appropriate delay after its input changes.
No clocks will be implied.  If you want a pipelined multiplier,
you either write it yourself (in verilog) or use one from
a library or logic generating program.
 
> Mostly I want to know how does one synchronise the datapath with the
> control path.  Eg say these inputs are used on a different module also
> and I want to know when the result is updated to use it with some
> other calculation I did in parallel.  How do I know how many clocks it
> takes (and do I have to code or is it possible to be flexible to do
> trade offs later?).

Synthesis tools will normally generate multipliers, but they
normally don't generate dividers.  A combinatorial divider
is big and slow, and rarely wanted, so tools don't generate one.
 
> Also, do I add an enable input and a ready output to my module to
> model the function call and return of C or how do I handle these
> syncronisations?

That is one reason why the C analogy isn't so good.

In C, you actually call the function, in which case it is
executed and generates the result.  The verilog assign statement,
called continuous assign, does not require any execution.  
It more closely models wires and gates connected together.

However, verilog normally does not include any delays in
evaluating logic, but real logic has delays.  It is up
to you to design logic with the appropriate latches (for
pipelined designs) and delays.  For appropriate synchronous
logic design, the tools will calculate a reasonably clock speed.

-- glen

Article: 146690
Subject: Re: USB 3.0 implementation on FPGA
From: wojtek <wojtekpowiertowski@gmail.com>
Date: Fri, 26 Mar 2010 00:41:53 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 25, 6:41=A0pm, "Maurice Branson" <trauben...@arcor.de> wrote:
> Thanks, Michael!
>
> I will have a look at the URL you postet. Anyway I want this project to b=
e
> one from which I learn a lot. So I am not interested in the 'least brain'
> approach but to do as much as I can in VHDL and just use a chipset for th=
e
> physical link.

First of all you should go to USB implementers forum USB-IF and
download the specifications of USB 3.0 (which will include host/device/
hub specification). Than you have to read and read and read again to
fully understand the USB 3.0. I hope you know that this won't be a
project that you will finish in a month or two. I would estimate that
one person would spend about 8 hours a day on USB 3.0 one could
probably finish it in 12 months (but that might be too optimistic,
since the development of USB 3.0 device takes about 6-9 months for a
team of HDL developers :)) If you want to learn something first try
using ready USB 2.0 chip and implement full hardware control of the
chip without any CPU.

Article: 146691
Subject: Re: USB 3.0 implementation on FPGA
From: Peter <nospam@nospam9876.com>
Date: Fri, 26 Mar 2010 08:08:56 +0000
Links: << >>  << T >>  << A >>

wojtek <wojtekpowiertowski@gmail.com> wrote

>On Mar 25, 6:41 pm, "Maurice Branson" <trauben...@arcor.de> wrote:
>> Thanks, Michael!
>>
>> I will have a look at the URL you postet. Anyway I want this project to be
>> one from which I learn a lot. So I am not interested in the 'least brain'
>> approach but to do as much as I can in VHDL and just use a chipset for the
>> physical link.
>
>First of all you should go to USB implementers forum USB-IF and
>download the specifications of USB 3.0 (which will include host/device/
>hub specification). Than you have to read and read and read again to
>fully understand the USB 3.0. I hope you know that this won't be a
>project that you will finish in a month or two. I would estimate that
>one person would spend about 8 hours a day on USB 3.0 one could
>probably finish it in 12 months (but that might be too optimistic,
>since the development of USB 3.0 device takes about 6-9 months for a
>team of HDL developers :)) If you want to learn something first try
>using ready USB 2.0 chip and implement full hardware control of the
>chip without any CPU.

I would buy a USB chip. The protocol is a total mess and always has
been.

I don't know if FTDI do a '3 chip but their standard ones work really
well.

Article: 146692
Subject: Re: USB 3.0 implementation on FPGA
From: Andrew Jackson <alj@nospam.com>
Date: Fri, 26 Mar 2010 09:01:19 +0000
Links: << >>  << T >>  << A >>
Maurice

> I will have a look at the URL you postet. Anyway I want this project to be
> one from which I learn a lot. So I am not interested in the 'least brain'
> approach but to do as much as I can in VHDL and just use a chipset for the
> physical link.

USB 3.0 requires that a device (peripheral) support the new "Super 
Speed" *and* at least one other speed (low, full or high).  So, in many 
ways, you would be better doing a USB2.0 device and sticking on a 
suitable USB PHY for the physical interface.  There aren't many USB 3.0 
hosts around yet against which you could test your device either: lots 
of USB 2.0 stuff though!

	Andrew

Article: 146693
Subject: baud rates etc
From: da_wils@hotmail.com
Date: Fri, 26 Mar 2010 02:34:14 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi,

I'm making a uart that will run at the standard baud rates and have a
bit of a query,
My board has a 50Mhz clk so I've used this to create a 1.8432Mhz clock
then derive all the baud clocks from it,,eg,
-- 50mhz/ 1843200 = 27.1267
-- 13 bit acc = 4096 msb
-- divided by 151
-- 4096/151 =  27.1258 -- close enough
-- gives 1.843262MHz clock

this is fine for TX but when it comes to RX where the accepted sample
clk is 16x the baud rate I hit a few problems. I wanted to sample the
incoming bit period at 4 16x clocks, 8 16x clocks and 12 16x clock and
use the theory that if two samples match then RX bit is good, It's
this generation of a 16x clock that is causing me problems, not easy
to create for all baud rates. At the moment I'm sampling the RX at
50MHz and taking samples at three points, this scheme works but seems
a bit inefficient due to having to have a bank of constants with the
the various count values for different baud rates.

Has anyone come across this problem ?

Article: 146694
Subject: result on hyperterminal is not displayed
From: "weldat" <gwelekiros@n_o_s_p_a_m.n_o_s_p_a_m.gmail.com>
Date: Fri, 26 Mar 2010 04:38:52 -0500
Links: << >>  << T >>  << A >>
Hi every body;
i am working on xilinx EDK with MicroBlaze soft core processor. i am using
Virtex 5 ML506 platform studio and my EDK is EDK 9.2
on this processor i am downloading C code for Elliptic curve diffie-hellman
key exchange and it is done but result is not displayed on the
hyperterminal so is there any body who can help me how to fix my problem?
but the connetion of the RS232_uart is working properly i have checked it
with simple C code. the baud rate is all ok
thank you in advance.
kind regards
weldat	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 146695
Subject: Re: Newbie Coding Question
From: Alan Fitch <alan.fitch@spamtrap.com>
Date: Fri, 26 Mar 2010 09:43:57 +0000
Links: << >>  << T >>  << A >>
On 26/03/2010 03:22, David Wiltshire wrote:
>>
>>>   assign res = (tmp0 + tmp1) / tmp2
>>
>> You don't mention it in the rest of your post but you'll find that
>> this divide by tmp2 would give you the biggest headache. Multipliers
>> are easy. All synthesis tools know how to either infer them to use the
>> macros or implement them in the fabric. Dividers are difficult (to
>> optimize that it) especially when they have a non-constant
>> denominator.
>>
>
> Okay, the divider is the trickier of the two - I just looked and I see
> that now.  Still FPGA synthesis software includes cores for dividers.
> Still my main question is about timing.  The division is going to
> occur over multiple clock cycles.  How does this impact my design
> (especially compared to other operations which happen in shorter
> periods of time) and how do I make sure that the result of this
> function is synchronised with other functions?

Hi David,
    there are two (or two and a half?) answers

1. You do it manually. It's up to you to develop an architecture in 
which all the timing "adds up". Typically people either create a 
pipeline and a state machine, or a kind of "baby DSP" i.e. a more 
general purpose system that has some kind of stored program control.

Essentially this is a large chunk of what hardware design actually is - 
coming up with a good architecture to solve a particular problem, taking 
into account the constraints of real hardware.

Of course as you say there's lots of IP you can use.

Regarding you question regarding timing, you can either arrange for 
every piece of data to arrive at the correct clock edge using your skill 
and judgement; or if it made sense for your application you could use a 
handshaking system between blocks; or a FIFO to create an elastic buffer.

More architectural work I'm afraid :-(


2. You pay a lot of money for a behavioural synthesis tool (for instance 
Mentor's Catapult C or Forte Cynthesizer - other tools may be available, 
I don't intend that to be an exhaustive list). You then either press the 
"go" button and hope for the best, or you spend time twiddling the knobs 
on the tools until you get what you want.


2.5 Certain RTL synthesis tools do sometimes understand a so-called 
implicit state machine style, where you make assignments in a single 
process separated by waits for a clock edge. They then infer a state 
machine and a datapath from the order of the assignments. (The divider 
would still be a problem).


regards
Alan


-- 
Alan Fitch
Senior Consultant

Doulos – Developing Design Know-how
VHDL * Verilog * SystemVerilog * SystemC * PSL * Perl * Tcl/Tk * Project 
Services

Doulos Ltd. Church Hatch, 22 Marketing Place, Ringwood, Hampshire, BH24 
1AW, UK
Tel:  + 44 (0)1425 471223		Email: alan.fitch@doulos.com	
Fax:  +44 (0)1425 471573		http://www.doulos.com

------------------------------------------------------------------------

This message may contain personal views which are not the views of 
Doulos, unless specifically stated.

Article: 146696
Subject: Re: USB 3.0 implementation on FPGA
From: "Maurice Branson" <traubenuss@arcor.de>
Date: Fri, 26 Mar 2010 11:18:08 +0100
Links: << >>  << T >>  << A >>
"Andrew Jackson" <alj@nospam.com> wrote 
news:X_adnaUfiO556jHWnZ2dnUVZ8l2dnZ2d@eclipse.net.uk...

> ways, you would be better doing a USB2.0 device and sticking on a suitable 
> USB PHY for the physical interface.  There aren't many USB 3.0 hosts 
> around yet against which you could test your device either: lots

Thanks, Andrew!

Sounds resonable to me. So if I start with 2.0 is there a compatibility that 
I may "expand" my design to a 3.0 core or is it totally different? I learned 
from what I've read here and in the www that I need at least a separate PHY 
because that is something that I cannot to in the FPGA fabric. Are there any 
USB 3.0 PHYs already available? Found nothing. :-(

KR Maurica 



Article: 146697
Subject: Re: Xilinx Spartan6 Virtex6 Rollout
From: Kim Enkovaara <kim.enkovaara@iki.fi>
Date: Fri, 26 Mar 2010 12:40:46 +0200
Links: << >>  << T >>  << A >>
Brad Smallridge wrote:
> Why shouldn't Xilinx tell us when parts are available.
> They are the mfg. They probably have a better idea.
> Even an approximation would be better than nothing.
> 
> What's the sales politics in saying you're going to have
> a package but don't say when?

I think this comes from the fact that many chip vendors
stock their chips as wafers. And they package those according
to the forecasts they receive. Same silicon fits to many
different package types.

It's much faster just to package the chips compared to the
leadtime of silicon wafer trough the fab.

--Kim

Article: 146698
Subject: Re: baud rates etc
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Fri, 26 Mar 2010 11:04:24 +0000 (UTC)
Links: << >>  << T >>  << A >>
da_wils@hotmail.com wrote:
 
> I'm making a uart that will run at the standard baud rates and have a
> bit of a query,
> My board has a 50Mhz clk so I've used this to create a 1.8432Mhz clock
> then derive all the baud clocks from it,,eg,
> -- 50mhz/ 1843200 = 27.1267
> -- 13 bit acc = 4096 msb
> -- divided by 151
> -- 4096/151 =  27.1258 -- close enough
> -- gives 1.843262MHz clock

I believe that off by 1% is considered close enough.

The ones that are usually a little off are 110 baud
(for ASR33s) and 134.48 (for IBM 2741s).  
As you can see, getting exactly 134.48 isn't easy with
any divider and normal crystal frequency.

I believe tradition is to sample in the middle of the
incoming bit time, but sampling more and combining them
in some way doesn't sound bad.  

As well as I remember it, when you see the start bit then
you wait 1/2 bit time (8 cycles of 16x), then check to be
sure the start bit is still there.  If not, then it is
just noise.  (Currently popular modems probably won't 
do that, but FSK modems, like the 103, can easily do that.)

If the start bit is good, then accumulate bits every
16 clock cycles.  The 16x clock gives you a 6% tolerance
on where you see the start bit edge.  That is the reason
for the 16x clock.  (Higher would be better, and I have
known some that will do 64x.)  

An important part of asynchronous communication is that
it resynchs on the start bit for each character.  If the
clock is a little off, the error accumulates over each
character, but not between characters.  

-- glen

Article: 146699
Subject: Re: Newbie Coding Question
From: Marc Jet <jetmarc@hotmail.com>
Date: Fri, 26 Mar 2010 04:04:43 -0700 (PDT)
Links: << >>  << T >>  << A >>
When you want to run a serial flow of operations on hardware, maybe
you should consider implementing a CPU and have it execute software?
The CPU could be a specific one, where you hardcode the operations of
your application (=assembler).  Or it could be a "standard" one,
allowing you to use a C compiler to create the necessary code.

You could then attach those "hardware" things, that made you go for
hardware in the first place, as peripherials to your CPU and make them
available to the software side to be able to combine them in the
desired ways.

This pushes all timing and concurrency problems into the software,
where it's easy to control and understand.



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