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 141725

Article: 141725
Subject: Re: FPGA / CPLD Group on LinkedIn -- Networking Group
From: rickman <gnuarm@gmail.com>
Date: Sat, 4 Jul 2009 23:16:58 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Jul 4, 11:02=A0pm, "MM" <mb...@yahoo.com> wrote:
> "rickman" <gnu...@gmail.com> wrote
>
>
>
> > For example, I can't find a way to reach a human at Twitter
>
> Why on earth a grown man would want to use Twitter? :)
>
> /Mikhail

I'm not trying to *use* it, I want them to stop sending me junk
email!  Didn't you read the post?

Rick

Article: 141726
Subject: Spartan-3A Device DNA ...
From: "Kappasm" <qaghca@tin.it>
Date: Sun, 5 Jul 2009 09:33:19 +0200
Links: << >>  << T >>  << A >>
Hi,

I have read the Device DNA in VHDL, but I have some problems. I have written 
code that certainly is not working well. If I put this code in the same fpga 
but in different projects, I read two different dna device ... :-| ...

If someone has already written something ?

Thanks very much.

Kappa. 



Article: 141727
Subject: Re: FPGA / CPLD Group on LinkedIn -- Networking Group
From: nico@puntnl.niks (Nico Coesel)
Date: Sun, 05 Jul 2009 08:23:01 GMT
Links: << >>  << T >>  << A >>
steve <steve@aol.com> wrote:

>On Mon, 29 Jun 2009 23:08:16 +0800, rickman wrote
>(in article 
><68320efd-477b-4818-95dd-d4639d7e2cd1@n19g2000vba.googlegroups.com>):
>
>> On Jun 28, 10:52=A0am, "Antti.Luk...@googlemail.com"
>> <Antti.Luk...@googlemail.com> wrote:
>>> On Jun 28, 5:09=A0pm, cpld-fpga-asic <cpld.fpga.a...@gmail.com> wrote:
>>> 
>>> 
>>> 
>>>> Group for People Involved In the Design and Verification of FPGA's,
>>>> other Programmable Logic , and CPLD's to Exchange Idea's and
>>>> Techniques. You should have FPGA / CPLD Design / Verification on your
>>>> Profile. (The focus is more on FPGA/CPLD in the product as opposed to
>>>> FPGA's solely as a path to an ASIC) VHDL / Verilog / ABLE / SystemC
>>>> and other HDL's as well. Vendors included: Xilinx, Altera, Actel,
>>>> Lattice, Atmel, QuickLogic, Tabula, Silicon Blue, Mentor, Cadence,
>>>> Synopsys, Aldec, NI, Altium, and Many Others.
>>> 
>>> could you describe the last technical FPGA related question
>>> that your linkedin networking group solved?
>>> 
>>> unless you are able todo that, i see you repeated postings
>>> to c.a.f. as complete spam
>>> 
>>> Antti
>> 
>> Hi, I am one of the moderators at this group and I must be honest
>> about it.  It is not a very technically oriented group.  I have tried
>> to make some technically oriented posts there with few responses.
>> out would be a mistake.
>> 
>> So I have given up on this group as well as other FPGA related groups
>> at LinkedIn.  I have not removed myself from membership, but I can't
>> say I recommend them unless you wish to use it for employment or self
>> promotion.
>> 
>> Rick
>
> I'm completely confused as to how you can have a FPGA  group that is not  
>"technically orientated" , it would be like having a flower arranging class 
>without the flowers.

LinkedIn is not about solving problems. It is about hiring the right
people to solve problems. To get back to your example: you could find
someone thru LinkedIn that can arrange the flowers for you.

-- 
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
                     "If it doesn't fit, use a bigger hammer!"
--------------------------------------------------------------

Article: 141728
Subject: Re: Spartan-3A Device DNA ...
From: "Antti.Lukats@googlemail.com" <Antti.Lukats@googlemail.com>
Date: Sun, 5 Jul 2009 02:42:07 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Jul 5, 10:33=A0am, "Kappasm" <qag...@tin.it> wrote:
> Hi,
>
> I have read the Device DNA in VHDL, but I have some problems. I have writ=
ten
> code that certainly is not working well. If I put this code in the same f=
pga
> but in different projects, I read two different dna device ... :-| ...
>
> If someone has already written something ?
>
> Thanks very much.
>
> Kappa.

just find the problem it has, it DEFENETLY works
and reads same dna on same chip
no matter the way you use the readout

I have written own code that reads same code as ken chapmans reader
so i know it all just works

Antti


Article: 141729
Subject: Re: Spartan-3A Device DNA ...
From: Kappa <secureasm@gmail.com>
Date: Sun, 5 Jul 2009 05:29:58 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi Antti,

> I have written own code that reads same code as ken chapmans reader
> so i know it all just works

You could post code ?

Thanks very much.

Kappa.

Article: 141730
Subject: Re: Spartan-3A Device DNA ...
From: "Antti.Lukats@googlemail.com" <Antti.Lukats@googlemail.com>
Date: Sun, 5 Jul 2009 05:39:52 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Jul 5, 3:29=A0pm, Kappa <secure...@gmail.com> wrote:
> Hi Antti,
>
> > I have written own code that reads same code as ken chapmans reader
> > so i know it all just works
>
> You could post code ?
>
> Thanks very much.
>
> Kappa.

you dont ask the right questions ;)

my system is customized microblazed based soc, and code is

void DNA_Read() {
	int i;

	SetPin(DNA_CLK, 0);
	SetPin(DNA_SHIFT, 0);

	// Load DNA Value
	SetPin(DNA_READ, 1);
	PulsePin(DNA_CLK, 1);
	// Go shift mode
	SetPin(DNA_READ, 0);
	SetPin(DNA_SHIFT, 1);
	// 57 bits of DNA shift register to read out
	dna_high=3D0;
	for (i=3D0;i<(57-32);i++) {
		dna_high<<=3D1;
		dna_high |=3D GetPin(DNA_DOUT);
		PulsePin(DNA_CLK, 1);
	}
	for (i=3D0;i<(32);i++) {
		dna_low<<=3D1;
		dna_low |=3D GetPin(DNA_DOUT);
		PulsePin(DNA_CLK, 1);
	}
}


int main (void) {
	LCD_Init();
	DNA_Read();
	xil_printf("%08X%08X",dna_high,dna_low);

        return 0;
}

it doesnt help you i guess
Antti










Article: 141731
Subject: Re: Spartan-3A Device DNA ...
From: Kappa <secureasm@gmail.com>
Date: Sun, 5 Jul 2009 06:31:49 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi Antti,

> you dont ask the right questions ;)

Corry for my not right questions ... :-) ...

> my system is customized microblazed based soc, and code is

Is what I tried to do ....

In that way you have connected "dna_port" with pcore ?

I had created a state machine in VHDL, with this I place a "device
dna" in 64-bit register. I can connect my clock "64MHz" to "dna_port"
clock ?

> it doesnt help you i guess

Important is to help

Kappa.

Article: 141732
Subject: Re: Subtleties of Booth's Algorithm Implementation
From: Andy Botterill <andy@plymouth2.demon.co.uk>
Date: Sun, 05 Jul 2009 15:14:56 +0100
Links: << >>  << T >>  << A >>
As I was surfing I noticed a reference to the ARM6 booth algorithm.
http://209.85.229.132/search?q=cache:M97u-qr5IGYJ:www.cl.cam.ac.uk/~acjf3/papers/mul.pdf+ARM7+MUL+signed+unsigned+multiply&cd=7&hl=en&ct=clnk&gl=uk
In the appendix you get a C style algorithm. Whether you can copy this I 
don't know. There is a reference to getting it from ARM at the bottom.
If this reduces the number of adders I will have a go at it. Not right 
now sorry. Andy

Article: 141733
Subject: Re: Subtleties of Booth's Algorithm Implementation
From: rickman <gnuarm@gmail.com>
Date: Sun, 5 Jul 2009 07:52:25 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Jul 5, 10:14 am, Andy Botterill <a...@plymouth2.demon.co.uk> wrote:
> As I was surfing I noticed a reference to the ARM6 booth algorithm.http://209.85.229.132/search?q=cache:M97u-qr5IGYJ:www.cl.cam.ac.uk/~a...
> In the appendix you get a C style algorithm. Whether you can copy this I
> don't know. There is a reference to getting it from ARM at the bottom.
> If this reduces the number of adders I will have a go at it. Not right
> now sorry. Andy


Maybe it's just me, but why would someone write in pseudo code and not
make the details very clear?  Here is the line I am ranting about.

while (not (rs = 0) or borrow) and n < wl do ...

I suppose if you *assume* this pseudo code is like C, you can *assume*
that the C rules for precedence apply.  But I don't see enough
similarity to C to make that assumption(e.g. "rd := if accumulate then
rn else 0" is clearly *not* C).  So I am left wondering just how to
evaluate the conditional expression.  On the other hand, if this
expression is what I think it is, the addition of two more sets of
parentheses would  make it unambiguous.

Heck, I gave up long ago trying to remember rules of precedence for
the many languages I write in and *always* make my code unambiguous by
adding as many parentheses as needed.  Sometimes this can look
unwieldy and verbose, but my intent is perfectly clear and no one will
be looking at the code asking themselves if I meant what I wrote or if
I made a mistake and meant something else.

Maybe this hits a nerve with me because of being bitten by poorly
written pseudo code in a research paper I had to read.  The paper was
about a tree search algorithm and if you couldn't understand the
pseudo code *exactly*, then there was no point to the paper.  Their
pseudo code wasn't even this good and we had a devil of a time
figuring it out. :^(  On the other hand the other student I was
working with on this was a very attractive coed and I enjoyed every
minutes of working on it. :^)

rick

Article: 141734
Subject: Re: Subtleties of Booth's Algorithm Implementation
From: rickman <gnuarm@gmail.com>
Date: Sun, 5 Jul 2009 08:25:46 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Jul 5, 10:14=A0am, Andy Botterill <a...@plymouth2.demon.co.uk> wrote:
> As I was surfing I noticed a reference to the ARM6 booth algorithm.http:/=
/209.85.229.132/search?q=3Dcache:M97u-qr5IGYJ:www.cl.cam.ac.uk/~a...
> In the appendix you get a C style algorithm. Whether you can copy this I
> don't know. There is a reference to getting it from ARM at the bottom.
> If this reduces the number of adders I will have a go at it. Not right
> now sorry. Andy

I've tried to weed my way through the pseudo code in the appendix and
it seems to have some problems.  First, I don't see where this is any
different from the "modified" Booth's algorithm where the multiplier
is shifted two bits at a time rather than just one.  The result is
that it requires more complex hardware for the calculation of the
partial product, but calculates half as many.

That brings us to two mistakes in the pseudo code.  The first is that
the loop control variable is n which is incremented by 1 on each
iteration of the loop and ends the loop when n =3D wl (the number of
input bits in the multiplier).  So it would appear that the loop is
being iterated for ***EACH*** bit in the multiplier while all the
calculations are for iterating over each *PAIR* of bits in the
multiplier.

The other mistake is where they state that the output register can
have just wl bits (the same as the number of input bits).  The way the
pseudo code is written the most significant bits of the product would
be lost.  I suppose this could be acceptable if you know this suits
your data.  But since they are designing a CPU for general purpose
work, this seems like it would create problems.

They do end the loop early if rs becomes zero indicating there are no
more additions.  But in the worst case it will require wl/2 iterations
of the loop.

Rick

Article: 141735
Subject: Re: Subtleties of Booth's Algorithm Implementation
From: Andy Botterill <andy@plymouth2.demon.co.uk>
Date: Sun, 05 Jul 2009 16:28:16 +0100
Links: << >>  << T >>  << A >>
rickman wrote:
> On Jul 5, 10:14 am, Andy Botterill <a...@plymouth2.demon.co.uk> wrote:
>> As I was surfing I noticed a reference to the ARM6 booth algorithm.http://209.85.229.132/search?q=cache:M97u-qr5IGYJ:www.cl.cam.ac.uk/~a...
>> In the appendix you get a C style algorithm. Whether you can copy this I
>> don't know. There is a reference to getting it from ARM at the bottom.
>> If this reduces the number of adders I will have a go at it. Not right
>> now sorry. Andy
> 
> 
> Maybe it's just me, but why would someone write in pseudo code and not
> make the details very clear?  Here is the line I am ranting about.

I would assume that the ARM6 was designed at gate level e.g RTL was not 
done.
> 
> while (not (rs = 0) or borrow) and n < wl do ...
Rs is one of the numbers to be multiplied. The algorithm terminates when 
Rs == 0.

The code does look reasonable. However I have spent more time with C 
compared to Verilog.

The key bits are the two case statements.
> 
> I suppose if you *assume* this pseudo code is like C, you can *assume*
> that the C rules for precedence apply.  But I don't see enough
> similarity to C to make that assumption(e.g. "rd := if accumulate then
> rn else 0" is clearly *not* C).  So I am left wondering just how to
> evaluate the conditional expression.  On the other hand, if this
> expression is what I think it is, the addition of two more sets of
> parentheses would  make it unambiguous.
> 
> Heck, I gave up long ago trying to remember rules of precedence for
> the many languages I write in and *always* make my code unambiguous by
> adding as many parentheses as needed.  Sometimes this can look
> unwieldy and verbose, but my intent is perfectly clear and no one will
> be looking at the code asking themselves if I meant what I wrote or if
> I made a mistake and meant something else.
> 
> Maybe this hits a nerve with me because of being bitten by poorly
> written pseudo code in a research paper I had to read.  The paper was
> about a tree search algorithm and if you couldn't understand the
> pseudo code *exactly*, then there was no point to the paper.  Their
> pseudo code wasn't even this good and we had a devil of a time
> figuring it out. :^(  On the other hand the other student I was
> working with on this was a very attractive coed and I enjoyed every
> minutes of working on it. :^)

Struggles to remember that long ago. When I were at university I don't 
there there were any girls doing electronics.
> 
> rick

Article: 141736
Subject: Re: Spartan-3A Device DNA ...
From: "Antti.Lukats@googlemail.com" <Antti.Lukats@googlemail.com>
Date: Sun, 5 Jul 2009 08:47:54 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Jul 5, 4:31=A0pm, Kappa <secure...@gmail.com> wrote:
> Hi Antti,
>
> > you dont ask the right questions ;)
>
> Corry for my not right questions ... :-) ...
>
> > my system is customized microblazed based soc, and code is
>
> Is what I tried to do ....
>
> In that way you have connected "dna_port" with pcore ?
>
> I had created a state machine in VHDL, with this I place a "device
> dna" in 64-bit register. I can connect my clock "64MHz" to "dna_port"
> clock ?
>
> > it doesnt help you i guess
>
> Important is to help
>
> Kappa.

i think 64mhz is too high
check the datasheet

Antti

Article: 141737
Subject: Re: Subtleties of Booth's Algorithm Implementation
From: rickman <gnuarm@gmail.com>
Date: Sun, 5 Jul 2009 09:39:14 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Jul 5, 11:28=A0am, Andy Botterill <a...@plymouth2.demon.co.uk> wrote:
> rickman wrote:
> > On Jul 5, 10:14 am, Andy Botterill <a...@plymouth2.demon.co.uk> wrote:
> >> As I was surfing I noticed a reference to the ARM6 booth algorithm.htt=
p://209.85.229.132/search?q=3Dcache:M97u-qr5IGYJ:www.cl.cam.ac.uk/~a...
> >> In the appendix you get a C style algorithm. Whether you can copy this=
 I
> >> don't know. There is a reference to getting it from ARM at the bottom.
> >> If this reduces the number of adders I will have a go at it. Not right
> >> now sorry. Andy
>
> > Maybe it's just me, but why would someone write in pseudo code and not
> > make the details very clear? =A0Here is the line I am ranting about.
>
> I would assume that the ARM6 was designed at gate level e.g RTL was not
> done.

I am sure this *is* done in RTL.  There may be hand tweeking of some
details, but for the most part ARM does not sell hard IP, or maybe I
should say, few *buy* their hard IP.  Atmel bought that once and ARM
would not give them anything they could use to make any mods to the
design.  From then on Atmel has bought HDL and done their own
implementations.


> > while (not (rs =3D 0) or borrow) and n < wl do ...
>
> Rs is one of the numbers to be multiplied. The algorithm terminates when
> Rs =3D=3D 0.
>
> The code does look reasonable. However I have spent more time with C
> compared to Verilog.
>
> The key bits are the two case statements.

I understand what it is saying, I was just ranting that for a paper to
be written this way was very sloppy, IMHO.  I think many people write
papers that are not intended to be read.


> > Maybe this hits a nerve with me because of being bitten by poorly
> > written pseudo code in a research paper I had to read. =A0The paper was
> > about a tree search algorithm and if you couldn't understand the
> > pseudo code *exactly*, then there was no point to the paper. =A0Their
> > pseudo code wasn't even this good and we had a devil of a time
> > figuring it out. :^( =A0On the other hand the other student I was
> > working with on this was a very attractive coed and I enjoyed every
> > minutes of working on it. :^)
>
> Struggles to remember that long ago. When I were at university I don't
> there there were any girls doing electronics.

Yes, I lucked out in that regard.  Girls were just starting to show up
in engineering and my classes has two girls (one engaged and one very
not engaged) and a bunch of geeks.  I was the least geeky of the
bunch...

Rick

Article: 141738
Subject: Re: Math Integral operation in FPGA
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Mon, 6 Jul 2009 05:25:15 +0000 (UTC)
Links: << >>  << T >>  << A >>
rickman <gnuarm@gmail.com> wrote:
(snip, someone wrote)

<> http://sunnyeves.blogspot.com/
 
< That calculation looks complex, but isn't it really just
 
< int(n) = int(n-1) + 0.5 * (f(n) - f(n-1))
 
< The 0.5 times the difference assumes that the function is a straight
< line between the two end points and when added to the min value is
< just the average of the two points.  This is an approximation, but
< depending you your needs will be adequate.
 
< I would argue that for an arbitrary function, there is no advantage to
< using the average of each two points over just summing the points.
< Consider points 0 to N where N is a large number.
 
< N
< < f(n) = f(1) + f(2) + ... + f(N)
< <
< 1
 
< N
< < avg(f(n),f(n-1) = 0.5 f(0) + f(1) + f(2) + ... + 0.5 * f(N)
< <
< 1
 
< Notice that the only difference is that the average needs an extra
< input point to calculate the first average and that the two end points
< of the summation are halved.  Numerically the difference between the
< two calculations is 0.5 * (f(n) - f(0)).  It appears to me to be a
< very minuscule error to just add all the points without the complexity
< of averaging.  I would bet that for any value of N, 256 or over, this
< error in the integral is much less than the error you get by the
< original straight line average approximation.

Sure, but for small N it might be important.

< In fact, whether you the average is correct or not depends on how you
< picture the error formation.  This is too complex to draw here, but if
< you picture the sample as being centered in the region being
< integrated by adding that value, then the error is only a function of
< the second order components of f(x).  To require an average
< calculation you are assuming that the area being calculated for a
< given point is the area *between* two points.

There is a similar explanation of the uselessness of Simpson't
rule in Numerical Recipes.  Simpson't rule has 1/3's and 2/3's that
look important.  Using a similar argument, NR shows that it
is fancy decoration for the effect at the ends.
 
< I could explain this more fully, but it is very hard to do without a
< drawing.

-- glen

Article: 141739
Subject: Re: Math Integral operation in FPGA
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Mon, 6 Jul 2009 05:33:56 +0000 (UTC)
Links: << >>  << T >>  << A >>
rickman <gnuarm@gmail.com> wrote:
 
< I understand perfectly your original calculations.  They are not
< complex to understand.  However, they are much more complex than
< required.  That is why I made my post explaining how in the infinite
< series, your approach approximates the simple sum of the input
< values.  The only difference is that your approach can only produce
< (N-1) output values for N input values and as a consequence, the final
< output will not include the area of one column because you are always
< subtracting out the first one.
 
< Your approach errs in the thinking that the area is defined by the
< points "surrounding" the area.  What it is ignoring that the points
< are *included* in the area.  I suppose that initial int(0) could be
< accounting for this somehow, without specifying how that
< initialization is to be done.

This is confusing.  The points have zero width and integrate
to zero.  Left out is the actual limit for the integral.  If it
includes one half a sample period before the first point, and
one half after the last point, then just add.  If it doesn't,
then you need to divide the first and last point by two.
 
< I made a typo in my original equation which is equivalent to your more
< complex calculation.
 
< int(n) = int(n-1) + 0.5 * (f(n) - f(n-1))
 
< should have been
 
< int(n) = int(n-1) + 0.5 * (f(n) + f(n-1))
 
< If you need me to, I can show you in a step wise manner how this is
< equivalent to your equation,
 
< int(n) = int(n-1) + 0.5 * diff(f(n), f(n-1)) + min(f(n), f(n-1))
 
< Other than the end points of a series, your equation adds in half of
< each data point at two separate times.  So each point is summed to
< produce the integral.  Your calculation simply omits half of each end
< point.
 
< The mistake that is often made when dealing with discrete time samples
< is thinking that they are the same as the instantaneous values of a
< continuous function.  In reality they are already integrals of the
< amplitude and the sample period (1/f).  That is why you only need to
< sum them to obtain the integral over a series.

For the sampling theorem to work they must be samples of the
instantaneous value.  Otherwise the result is filtered and
the results will be wrong when used as filter input (or almost
any other use.)
 
< A simple sum is the correct way to calculate the integral of a
< discrete time data series.

If you can manage the sample points in the center of the bins, yes.
Certainly that is preferred, but not always possible.

-- glen

Article: 141740
Subject: Re: pinout
From: Sharanbr <sharan.basappa@gmail.com>
Date: Sun, 5 Jul 2009 23:25:34 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Jul 2, 10:07 am, Kim Enkovaara <kim.enkova...@iki.fi> wrote:
> Sharanbr wrote:
> > How do I ensure that I have got a fairly accurate pinout (assuming
> > meeting timing is not an issue) when
> > the design is still under development. Do people create dummy FPGA top
> > and use special tools that only
> > check the validity of the pinouts wrt to the selected device?
>
> The most simplistic method is just to create dummy toplevel design,
> and do pinmapping to that file with the help of the tools and manual,
> and run the basic DRC checks.
>
> In bigger designs that is not usually enough. If complex clocking or big
> amount of special blocks (serdes for example) are used I at least
> recommend a toplevel that has clocking structures and the special blocks
> instantiated. That file can be then run with the pinmapping trough the
> normal P&R flow to make sure that it is implementable.
>
> And for good PCB layout the pinmapping has to be loaded into PCB level
> tools (Mentor I/O Designer etc.) and the new pinmapping has to be
> verified again in the P&R flow after each modification.
>
> --Kim

Thanks Everyone.

Would like to know how many times it happens that the pinouts (defined
early in the cycle) have to change after the p&r?
It would assume this would depend on:
1) how aggressive the timings are
2) how accurate was the flow used to define early pinout (as Kim
suggested having top level reset/clocking structures)

Do you agree with the assesement?

Article: 141741
Subject: USB protocol analyzer
From: =?windows-1252?Q?GaLaKtIkUs=99?= <taileb.mehdi@gmail.com>
Date: Mon, 6 Jul 2009 03:32:28 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi everybody!
Is it possible to use chipscope as a USB protocol analyzer?
Perhaps through some API of chipscope? By the way, is there any
accessible API with chipscope in order to make data analysis, custom
GUI etc ... ?

Thanks in advance!

Article: 141742
Subject: Re: Math Integral operation in FPGA
From: rickman <gnuarm@gmail.com>
Date: Mon, 6 Jul 2009 06:01:33 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Jul 6, 1:33 am, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
> rickman <gnu...@gmail.com> wrote:
>
> < I understand perfectly your original calculations.  They are not
> < complex to understand.  However, they are much more complex than
> < required.  That is why I made my post explaining how in the infinite
> < series, your approach approximates the simple sum of the input
> < values.  The only difference is that your approach can only produce
> < (N-1) output values for N input values and as a consequence, the final
> < output will not include the area of one column because you are always
> < subtracting out the first one.
>
> < Your approach errs in the thinking that the area is defined by the
> < points "surrounding" the area.  What it is ignoring that the points
> < are *included* in the area.  I suppose that initial int(0) could be
> < accounting for this somehow, without specifying how that
> < initialization is to be done.
>
> This is confusing.  The points have zero width and integrate
> to zero.  Left out is the actual limit for the integral.  If it
> includes one half a sample period before the first point, and
> one half after the last point, then just add.  If it doesn't,
> then you need to divide the first and last point by two.
>
> < I made a typo in my original equation which is equivalent to your more
> < complex calculation.
>
> < int(n) = int(n-1) + 0.5 * (f(n) - f(n-1))
>
> < should have been
>
> < int(n) = int(n-1) + 0.5 * (f(n) + f(n-1))
>
> < If you need me to, I can show you in a step wise manner how this is
> < equivalent to your equation,
>
> < int(n) = int(n-1) + 0.5 * diff(f(n), f(n-1)) + min(f(n), f(n-1))
>
> < Other than the end points of a series, your equation adds in half of
> < each data point at two separate times.  So each point is summed to
> < produce the integral.  Your calculation simply omits half of each end
> < point.
>
> < The mistake that is often made when dealing with discrete time samples
> < is thinking that they are the same as the instantaneous values of a
> < continuous function.  In reality they are already integrals of the
> < amplitude and the sample period (1/f).  That is why you only need to
> < sum them to obtain the integral over a series.
>
> For the sampling theorem to work they must be samples of the
> instantaneous value.  Otherwise the result is filtered and
> the results will be wrong when used as filter input (or almost
> any other use.)
>
> < A simple sum is the correct way to calculate the integral of a
> < discrete time data series.
>
> If you can manage the sample points in the center of the bins, yes.
> Certainly that is preferred, but not always possible.
>
> -- glen

Glen,

What you have said is a self-contradiction.  If there is no averaging
at all (an impossibility - all measurements are made within a finite
time window) and the point measures a value at an exact point it time,
then there is no bin to be in the center of or at the edge of.  They
are just measurements of a point in time.  What would define the bin?
In fact, what *IS* a bin in this context?

It is a matter of perspective which I believe is shown clearly in the
calculations.  As I showed above (or I tried to show) the two
calculations performed on an infinite time series are exactly
equivalent and when performed on a finite time series the only
difference is that one method includes all the samples with a
multiplier of 1 and the other uses a multiplier of 0.5 only on the end
points.

The distinction of looking at the "bins" as being around the sample or
between the samples is a red-herring and have no relation to the real
math of integrating a time sampled signal.

|     |     |     |--+--|
|     |     |--+--|  *  |
|     |--+--|  *  |  *  |
|--+--|  *  |  *  |  *  |
|  *  |  *  |  *  |  *  |
|  *  |  *  |  *  |  *  |
  t0    t1    t2    t3
   3     4     5     6

In this example, the + indicate the value of the signal f(t) at that
point in time.  The integral calculation assumes that the value of f
(t) between the time samples is a straight line.  By treating the
period as "1" and summing the values, you are in effect calculating
the areas shown above with the point centered in the rectangles.  The
area on the left and right of the point between the top of the
rectangle and the straight line approximation have opposite signs
since one is making the area larger than it should be and other is
making is smaller.  But they are equal in value and cancel.

The other method draws rectangles between the points with a height
equal to the average of each two points.  This is a much more complex
calculation and gives the same result.  There is no reason to
complicate the calculations using this calculation.  Neither
calculation has a basis in the physics of the problem.  They are just
equivalent numerical approximations.

Rick

Article: 141743
Subject: Re: FPGA / CPLD Group on LinkedIn -- Networking Group
From: steve <steve@aol.com>
Date: Mon, 6 Jul 2009 21:02:42 +0800
Links: << >>  << T >>  << A >>
On Sun, 5 Jul 2009 16:23:01 +0800, Nico Coesel wrote
(in article <4a506294.2904187875@news.planet.nl>):

> steve <steve@aol.com> wrote:
> 
>> On Mon, 29 Jun 2009 23:08:16 +0800, rickman wrote
>> (in article 
>> <68320efd-477b-4818-95dd-d4639d7e2cd1@n19g2000vba.googlegroups.com>):
>> 
>>> On Jun 28, 10:52=A0am, "Antti.Luk...@googlemail.com"
>>> <Antti.Luk...@googlemail.com> wrote:
>>>> On Jun 28, 5:09=A0pm, cpld-fpga-asic <cpld.fpga.a...@gmail.com> wrote:
>>>> 
>>>> 
>>>> 
>>>>> Group for People Involved In the Design and Verification of FPGA's,
>>>>> other Programmable Logic , and CPLD's to Exchange Idea's and
>>>>> Techniques. You should have FPGA / CPLD Design / Verification on your
>>>>> Profile. (The focus is more on FPGA/CPLD in the product as opposed to
>>>>> FPGA's solely as a path to an ASIC) VHDL / Verilog / ABLE / SystemC
>>>>> and other HDL's as well. Vendors included: Xilinx, Altera, Actel,
>>>>> Lattice, Atmel, QuickLogic, Tabula, Silicon Blue, Mentor, Cadence,
>>>>> Synopsys, Aldec, NI, Altium, and Many Others.
>>>> 
>>>> could you describe the last technical FPGA related question
>>>> that your linkedin networking group solved?
>>>> 
>>>> unless you are able todo that, i see you repeated postings
>>>> to c.a.f. as complete spam
>>>> 
>>>> Antti
>>> 
>>> Hi, I am one of the moderators at this group and I must be honest
>>> about it.  It is not a very technically oriented group.  I have tried
>>> to make some technically oriented posts there with few responses.
>>> out would be a mistake.
>>> 
>>> So I have given up on this group as well as other FPGA related groups
>>> at LinkedIn.  I have not removed myself from membership, but I can't
>>> say I recommend them unless you wish to use it for employment or self
>>> promotion.
>>> 
>>> Rick
>> 
>> I'm completely confused as to how you can have a FPGA  group that is not  
>> "technically orientated" , it would be like having a flower arranging class 
>> without the flowers.
> 
> LinkedIn is not about solving problems. It is about hiring the right
> people to solve problems. To get back to your example: you could find
> someone thru LinkedIn that can arrange the flowers for you.
> 
> 

we are not talking about "linkedin"  ,we are talking about a technical group 
within the  "LI" network.
If you cannot keep up, there  is Lego and crayons over in the play area.




Article: 141744
Subject: Re: FPGA / CPLD Group on LinkedIn -- Networking Group
From: Jonathan Bromley <jonathan.bromley@MYCOMPANY.com>
Date: Mon, 06 Jul 2009 14:12:28 +0100
Links: << >>  << T >>  << A >>
On Mon, 6 Jul 2009 21:02:42 +0800, steve <steve@aol.com> wrote:

>we are not talking about "linkedin"  ,we are talking about a technical group 
>within the  "LI" network.
>If you cannot keep up, there  is Lego and crayons over in the play area.

Ah, the New Media Priesthood.  Their mantra: If you
Don't Get It, we will patronize you to death.

Me, I definitely Don't Get It, and I really don't
care all that much, and I've been patronized in 
the past by people I respect a lot more than the 
Noo Meeja Vangelists, so I don't feel too worried.

Is there a LinkedIn group for elderly curmudgeons?
I'm in there...
-- 
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which 
are not the views of Doulos Ltd., unless specifically stated.

Article: 141745
Subject: Re: Math Integral operation in FPGA
From: rickman <gnuarm@gmail.com>
Date: Mon, 6 Jul 2009 06:13:48 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Jul 6, 1:25=A0am, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
> rickman <gnu...@gmail.com> wrote:
>
> (snip, someone wrote)
>
> <>http://sunnyeves.blogspot.com/
>
> < That calculation looks complex, but isn't it really just
>
> < int(n) =3D int(n-1) + 0.5 * (f(n) - f(n-1))
>
> < The 0.5 times the difference assumes that the function is a straight
> < line between the two end points and when added to the min value is
> < just the average of the two points. =A0This is an approximation, but
> < depending you your needs will be adequate.
>
> < I would argue that for an arbitrary function, there is no advantage to
> < using the average of each two points over just summing the points.
> < Consider points 0 to N where N is a large number.
>
> < N
> < < f(n) =3D f(1) + f(2) + ... + f(N)
> < <
> < 1
>
> < N
> < < avg(f(n),f(n-1) =3D 0.5 f(0) + f(1) + f(2) + ... + 0.5 * f(N)
> < <
> < 1
>
> < Notice that the only difference is that the average needs an extra
> < input point to calculate the first average and that the two end points
> < of the summation are halved. =A0Numerically the difference between the
> < two calculations is 0.5 * (f(n) - f(0)). =A0It appears to me to be a
> < very minuscule error to just add all the points without the complexity
> < of averaging. =A0I would bet that for any value of N, 256 or over, this
> < error in the integral is much less than the error you get by the
> < original straight line average approximation.
>
> Sure, but for small N it might be important.

Actually, the difference is that for a finite series, one approximates
the integral of the curve at N points and the other approximates the
integral of N-1 points.  This is easy to see if you consider the width
of the area being approximated.  For a constant value using two
points, the simple sum is twice the value of a single point and three
points gives a value half again as large as two points.  Using the
average method you can't calculate a value for one point and the value
for three points is *twice* the value for two points.  That's because
the area being approximated using three points is only two periods
wide, not three.

Time sampled series are not continuous functions and can not be
analyzed the same way.

Rick

Article: 141746
Subject: Suzaku SZx30 or similar
From: "AstroLad" <AstroLad@cox.net>
Date: Mon, 06 Jul 2009 08:19:07 -0500
Links: << >>  << T >>  << A >>
Does anyone know of anything similar to the Suzaku SZ030/SZ130? It's just
about a perfect fit for a short production run product I'm helping a friend
with. Perfect that is except the price. What we need is an FPGA as good or
better than a XC3S1000, 1MB or more of RAM (SRAM or SDRAM) and 100MB
Ethernet. It does not absolutely have to be a Spartan. An Altera Cyclone of
some flavor would do if the price were right. We already have a lot of
development done using Digilent Spartan boards. We don't need the
Microblaze as we have a CPU from OpenCores that is adequate.



Article: 141747
Subject: Re: FPGA / CPLD Group on LinkedIn -- Networking Group
From: rickman <gnuarm@gmail.com>
Date: Mon, 6 Jul 2009 06:19:45 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Jul 6, 9:12=A0am, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com>
wrote:
> On Mon, 6 Jul 2009 21:02:42 +0800, steve <st...@aol.com> wrote:
> >we are not talking about "linkedin" =A0,we are talking about a technical=
 group
> >within the =A0"LI" network.
> >If you cannot keep up, there =A0is Lego and crayons over in the play are=
a.
>
> Ah, the New Media Priesthood. =A0Their mantra: If you
> Don't Get It, we will patronize you to death.
>
> Me, I definitely Don't Get It, and I really don't
> care all that much, and I've been patronized in
> the past by people I respect a lot more than the
> Noo Meeja Vangelists, so I don't feel too worried.
>
> Is there a LinkedIn group for elderly curmudgeons?
> I'm in there...
> --
> Jonathan Bromley, Consultant

I haven't found one, but you can start it!  I'll probably join as
well.  What is it about getting old anyway???

Rick

Article: 141748
Subject: Re: How to keep documentation of control and status registers and
From: Petrov <petrovski101@gmail.com>
Date: Mon, 6 Jul 2009 09:57:04 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Jun 30, 4:24=A0pm, Svenn Are Bjerkem <svenn.bjer...@googlemail.com>
wrote:

> I'm wondering how other VHDL programmers solve their CSR bookkeeping,
> or maybe there is a tool out there that I haven't found. It doesn't
> need to be open source, if it is any good we will buy it. From the
> efforts by Wilson Snyder on Vregs I take that this is not a tool that
> I can write overnight myself. Maybe it is portable since it is written
> in perl, but Verilog and VHDL does think differently, and I am not a
> perl savvy. (Can't even read my own code after six weeks)

I wrote TCL code compiled into an executable so you don't need TCL
installed to run.  There are two programs, reg2vhdl.exe and
reg2groff.exe, the first generates VHDL and the second groff code.

A snippet of the input text file:

#--------------------------------------------------------------------------=
-----
# Processor Interface Register File
# pint_reg.reg
#--------------------------------------------------------------------------=
-----

#--------------------------------------------------------------------------=
-----
# Revision Register
#--------------------------------------------------------------------------=
-----
NAME: REV
ADDR: 0x0
 DIR: R
BITS: 7:0  Revision  # This register stores the revision of the SPI
module.

#--------------------------------------------------------------------------=
-----
# Control Register
#--------------------------------------------------------------------------=
-----
NAME: CONTROL_WR
ADDR: 0x1
 DIR: W
 BIT: 2    UartMode     # 0 =3D Normal Operation (default). 1 =3D
Configuration Mode.
BITS: 1:0  LoopbackSel  # Selects SPI loop back source.         \
                        #   SPI_0 : LoopSel<1:0> =3D 00 (default) \
                        #   SPI_1 : LoopSel<1:0> =3D 01           \
                        #   SPI_2 : LoopSel<1:0> =3D 10           \
                        #   TEST  : LoopSel<1:0> =3D 11           \
                        # Note: TEST is hardcoded to 0xA5.

NAME: CONTROL_RD
ADDR: 0x1
 DIR: R
 BIT: 2    UartMode     # 0 =3D Normal Operation (default). 1 =3D
Configuration Mode.
BITS: 1:0  LoopbackSel  # SPI loop back source.                 \
                        #   SPI_0 : LoopSel<1:0> =3D 00 (default) \
                        #   SPI_1 : LoopSel<1:0> =3D 01           \
                        #   SPI_2 : LoopSel<1:0> =3D 10           \
                        #   TEST  : LoopSel<1:0> =3D 11           \
                        # Note: TEST is hardcoded to 0xA5.

The portion after the # character are comments and end up in a groff
table (later converted to pdf).  Documentation then becomes part of
the makefile script.

The program wasn't that difficult to write and it's getting lots of
use in our design group.  It's not a huge time saver, but does keep
things in sync because the makefile generates both vhdl and
documentation from the same source file.  I went with groff as a
documentation language because it's pretty easy to learn and is open
source.

Pete


Article: 141749
Subject: How to interpret polyphase coefficients generated in MATLAB
From: vizziee <vizziee@gmail.com>
Date: Mon, 6 Jul 2009 10:11:15 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hello everyone,

I am trying to design a low pass decimator filter in MATLAB. I am
supposed to decimate a signal sampled at 200MHz down to 10MHz. The
signal bandwidth is 8 MHz and the signal spectra is centred at the
sampling frequency.

I began with the following code:
---------------------------------------------------------------
Fs_adc = 200e6;       % ADC Sampling Frequency
Fpass1 = 4e6;          % Passband Frequency
Fstop1 = 5e6;          % Stopband Frequency
Astop1 = 80;           % Aliasing Attenuation(dB)
M1     = 20;           % Decimation Factor
TW1    = Fstop1 - Fpass1;  % Transition Width (Hz)
dlow1  = fdesign.decimator(M1, 'nyquist', M1, TW1, Astop1, Fs_adc);
hlow1  = design(dlow1); % Lowpass prototype
Hlpf1  = mfilt.firdecim(M1, hlow1.Numerator);
fs_ds = dlow1.Fs_out;
decimated_signal = filter(Hlpf1, sampled_signal);
---------------------------------------------------------------

This gave me a Direct Form FIR Polyphase Decimator. Now when I look at
the Hbpf1 variable, it shows me 1005 coefficients (Hbpf1.Numerator
variable). Considering I have to implement this filter on FPGA, this
appears to be a very huge number for the taps.

A little reading on Polyphase FIR filters indicated me that the total
number of taps *per every sub-filter* in a polyphase structure should
be ceil(1005/M1) = 50 and so I would have M1=20 such filters. Would
this mean that implementing the above filter in polyphase form has
reduced the number of taps? I still have 1005 different coefficients
in the polyphase structure.

Or is it that since I would only be using 50 taps at a time, I only
need 50 multipliers in the hardware which should be time-multiplexed
with 20 sets of 50 coefficients, hence saving the hardware on a XILINX
Virtex5 FPGA. Further the rate of time-multiplexing the filter
coefficients is 10 MHz.

Or if this is not the good way to decimate the signal while also
achieving a good quality of output signal, kindly let me know other
ideas. I have also tried CIC-Compensator-HalfBand combination but I
really liked the response of the Polyphase FIR Decimator.

Or should I try more than one stage of polyphase FIR Decimator (say,
decimate by 5 followed by decimate by 4) to further reduce the number
of taps?

Regards,

vizziee.



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