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 147325

Article: 147325
Subject: Re: Absolute value of a two's complement number
From: "dlopez" <d@n_o_s_p_a_m.n_o_s_p_a_m.designgame.ca>
Date: Thu, 22 Apr 2010 17:54:52 -0500
Links: << >>  << T >>  << A >>

>The absolute value of an n-bit signed value is at most an n-bit
>unsigned value.  (An n-bit unsigned value is an n+1 bit signed
>value.)  Does your absolute value need to be signed?
>

Ha this is what I was missing! Unsigned numbers still exist! 

Diego

	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 147326
Subject: confusion with ADC/DAC interface implementation
From: alkosd@yahoo.co.uk
Date: Thu, 22 Apr 2010 17:41:35 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi,
i am confused regarding the ADC/DAC interface implementation on FPGA.
I have read a code where after serialising the input data of 16 bits
in 16 clock cycles, the interface logic loops (in vain?) for another
16 cyles  before serialising the next data. can#t understand why? why
the serialisation of the next data is not done immediately. moreover,
should the serialisation clock rate be 16 higher than the data stream
clock rate? Sorry but i could not find a documentation detailing all
the synchronization mechanism.

cheers :)

Article: 147327
Subject: Re: confusion with ADC/DAC interface implementation
From: KJ <kkjennings@sbcglobal.net>
Date: Thu, 22 Apr 2010 18:42:56 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 22, 8:41=A0pm, alk...@yahoo.co.uk wrote:
> Hi,
> i am confused regarding the ADC/DAC interface implementation on FPGA.
> I have read a code where after serialising the input data of 16 bits
> in 16 clock cycles, the interface logic loops (in vain?) for another
> 16 cyles =A0before serialising the next data. can#t understand why?

Because things work as they are designed...not as they are intended.

Do you have a specific question or are you trolling and asking the
group to fathom why some unlisted code that is implemented in an FPGA
either keeps reading from an ADC or keeps writing to a DAC or perhaps
both?

> why
> the serialisation of the next data is not done immediately. moreover,

Thought you just said it tried again, as you say "in vain?"...sounds
immediate to me

> should the serialisation clock rate be 16 higher than the data stream
> clock rate?

If the ADC shifts out 16 bits of data, then yes it would need to be at
least 16 times as fast as you'd like to sample the analog data.

> Sorry but i could not find a documentation detailing all
> the synchronization mechanism.
>

Are you asking the group to find the documentation for you?

What you need is the datasheet for whatever ADC or DAC that you're
talking about.

Try a more informed posting after you've put some though into your
question and provide some actual details of what you don't understand
and you'll likely get better responses.

KJ

Article: 147328
Subject: Re: I'd rather switch than fight!
From: KJ <kkjennings@sbcglobal.net>
Date: Thu, 22 Apr 2010 18:57:41 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 22, 6:36=A0pm, Patrick Maupin <pmau...@gmail.com> wrote:
> On Apr 22, 5:32=A0pm, Andy <jonesa...@comcast.net> wrote:
>
> > Other than twice the declarations, unintentional latches, explicitly
> > coding clock enables, simulation penalties, etc., using separate
> > combinatorial and sequential blocks is just fine.
>
> Unintentional latches don't happen if you use a consistent naming
> style with, e.g. 'next_x' and 'x'.
>

Ha, ha, ha...having a convention naming style prevents latches???!!!

Ummmmmm, noooooooo, don't think so, but thanks for the possibly
unintended humor.

Whether you have a naming convention or not, latches will be created
when assignment statements to cover every path are not included in an
unclocked process totally independent of how they are named...end of
story

I suppose your point is that calling things 'next_x' and 'x' then
makes it easier to do a *manual* inspection and perhaps catch such a
missing assignment but that is a far, far stretch from your actual
statement "Unintentional latches don't happen if...".  Andy, on the
other hand, is on much firmer ground had he said "Unintentional
latches don't happen if you only use clocked processes"...he didn't
explicitly say that, but I'm fairly certain he would agree.

Yes, you can do things to make *manual* inspections better...which is
like saying it hurts my head less if I use a rubber hammer to hit my
head than a steel one...but it is a far better process improvement to
just not hit my head at all with any hammer.

KJ

Article: 147329
Subject: Re: I'd rather switch than fight!
From: Patrick Maupin <pmaupin@gmail.com>
Date: Thu, 22 Apr 2010 19:12:33 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 22, 8:57=A0pm, KJ <kkjenni...@sbcglobal.net> wrote:

> I suppose your point is that calling things 'next_x' and 'x' then
> makes it easier to do a *manual* inspection and perhaps catch such a
> missing assignment but that is a far, far stretch from your actual
> statement "Unintentional latches don't happen if...". =A0Andy, on the
> other hand, is on much firmer ground had he said "Unintentional
> latches don't happen if you only use clocked processes"...he didn't
> explicitly say that, but I'm fairly certain he would agree.

Yes, I should have been more clear about that.  Any decent synthesizer
or simulation tool will report latches, but sometimes the reports are
hard to interpret.  If you use a consistent naming convention like I
have described, it is easy to find the latches, and also easy to write
a script to find them, as well.

And I agree that you won't have latches if all your processes are
clocked, but latches are much easier to detect and rectify than some
other possible logic problems.

Regards,
Pat

Article: 147330
Subject: Re: I'd rather switch than fight!
From: KJ <kkjennings@sbcglobal.net>
Date: Thu, 22 Apr 2010 21:38:13 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 22, 10:12=A0pm, Patrick Maupin <pmau...@gmail.com> wrote:
> On Apr 22, 8:57=A0pm, KJ <kkjenni...@sbcglobal.net> wrote:
>

> Yes, I should have been more clear about that.

Agreed, you're not very clear when you have statements like this from
your previous post...

> Unintentional latches don't happen if you use a consistent naming
> style with, e.g. 'next_x' and 'x'.

followed up with statements like this...

> If you use a consistent naming convention like I
> have described, it is easy to find the latches,

So, first you say that the naming convention by itself will prevent
unintentional latches and then follow that up to say that the naming
convention helps you to *find* the unintended latches that couldn't be
created in the first place...hmmm....yes, I agree, not very clear.

Both statements indicating that you may be oblivous to the simple
point that using non-clocked processes opens you up to making it easy
to create your own problems (i.e. the latches) that are easily avoided
in the first place...

> And I agree that you won't have latches if all your processes are
> clocked,

Oop, I guess not because now it seems that you do get the point that
clocked processes for the most part avoid the unintended latch...but
based on the earlier comments I guess you must not practice it or
something for some reason...You admit it avoids a potential design
problem, but don't use it because....hmmmm....well, perhaps you have a
sponge hammer...

Ah well...as long as there are textbooks I guess there will always be
those disciples that think that separating combinatorial logic from
the register description actually is of some value to somebody,
somewhere at some point in time...but inevitably they come up short
when trying to demonstrate that value.

> easy to find the latches, and also easy to write
> a script to find them, as well

Then they will trot out the methods they use to minimize the problem
that others do not even have.

While those disciples are steadfast in their belief, it usually
doesn't get across to them that the value they perceive is actually
negative, it is costing them...and they are left clinging to the only
thing they have left which is always a statement of the form "That's
the way I do it, I'm comfortable with it, I feel I'm productive doing
it this way"

Every now and then, it seems like good sport to challenge those folks
to see if they have anything better to offer, but it never seems to
be.

> but latches are much easier to detect and rectify than some
> other possible logic problems.
>
And much easier to avoid in the first place too...with the correct
methodology (hint:  that would be the one that avoids using unclocked
processes)

Just having fun...like I said, every now and then it's good sport to
poke fun at the people who make their own problems.

Kevin Jennings

Article: 147331
Subject: Re: I'd rather switch than fight!
From: Patrick Maupin <pmaupin@gmail.com>
Date: Thu, 22 Apr 2010 22:01:38 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 22, 11:38=A0pm, KJ <kkjenni...@sbcglobal.net> wrote:
> > but latches are much easier to detect and rectify than some
> > other possible logic problems.
>
> And much easier to avoid in the first place too...with the correct
> methodology (hint: =A0that would be the one that avoids using unclocked
> processes)
>
> Just having fun...like I said, every now and then it's good sport to
> poke fun at the people who make their own problems.
>

But, the reason I was unclear to start with, is that it's been so long
since I've had an unintended latch (probably several years) that I
really don't think that hard about it at all.  So you can think what
you want, but the *reason* I code the way I do isn't really that much
about latches at all (obviously, if I was *worried* about them, I
would code everything in sequential blocks, where they could never
happen, but I could have some other hard to find logic problems, which
I *have* had in the past).  However, unintended latches just don't
happen for me with my coding style, so I don't worry about it until
somebody like you comes along to tell me about all the problems that
I'm causing for myself that I never knew I had!

Regards,
Pat

Article: 147332
Subject: Re: confusion with ADC/DAC interface implementation
From: Tricky <trickyhead@gmail.com>
Date: Fri, 23 Apr 2010 00:35:46 -0700 (PDT)
Links: << >>  << T >>  << A >>
On 23 Apr, 02:42, KJ <kkjenni...@sbcglobal.net> wrote:
> On Apr 22, 8:41=A0pm, alk...@yahoo.co.uk wrote:
>
> > Hi,
> > i am confused regarding the ADC/DAC interface implementation on FPGA.
> > I have read a code where after serialising the input data of 16 bits
> > in 16 clock cycles, the interface logic loops (in vain?) for another
> > 16 cyles =A0before serialising the next data. can#t understand why?
>
> Because things work as they are designed...not as they are intended.
>
> Do you have a specific question or are you trolling and asking the
> group to fathom why some unlisted code that is implemented in an FPGA
> either keeps reading from an ADC or keeps writing to a DAC or perhaps
> both?
>
> > why
> > the serialisation of the next data is not done immediately. moreover,
>
> Thought you just said it tried again, as you say "in vain?"...sounds
> immediate to me
>
> > should the serialisation clock rate be 16 higher than the data stream
> > clock rate?
>
> If the ADC shifts out 16 bits of data, then yes it would need to be at
> least 16 times as fast as you'd like to sample the analog data.
>
> > Sorry but i could not find a documentation detailing all
> > the synchronization mechanism.
>
> Are you asking the group to find the documentation for you?
>
> What you need is the datasheet for whatever ADC or DAC that you're
> talking about.
>
> Try a more informed posting after you've put some though into your
> question and provide some actual details of what you don't understand
> and you'll likely get better responses.
>
> KJ

Wow - grouchy this morning. Did someone piss on your cocoa-pops? ;)

Article: 147333
Subject: Re: I'd rather switch than fight!
From: Chris Higgs <chiggs.99@googlemail.com>
Date: Fri, 23 Apr 2010 01:03:03 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 23, 5:38=A0am, KJ <kkjenni...@sbcglobal.net> wrote:

> Ah well...as long as there are textbooks I guess there will always be
> those disciples that think that separating combinatorial logic from
> the register description actually is of some value to somebody,
> somewhere at some point in time...but inevitably they come up short
> when trying to demonstrate that value.

http://www.gaisler.com/doc/structdes.pdf

I'd recommend casting your eye over this presentation. It details some
of the advantages of the "2 process" coding style with a real world
example (LEON SPARC-V8 processor).

Thanks,

Chris

Article: 147334
Subject: Re: I'd rather switch than fight!
From: Bernd Paysan <bernd.paysan@gmx.de>
Date: Fri, 23 Apr 2010 12:01:33 +0200
Links: << >>  << T >>  << A >>
Andy wrote:

> Other than twice the declarations, unintentional latches, explicitly
> coding clock enables, simulation penalties, etc., using separate
> combinatorial and sequential blocks is just fine.

LoL.  Note that there are further difficulties to understand this separated 
code due to the fact that things which conceptually belong together are 
spread apart over the file.  This is just too messy.

> Most designers here use single clocked processes / always blocks.
> Those that don't are 'encouraged' to.

I'm fully on your side.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself!"
http://www.jwdt.com/~paysan/

Article: 147335
Subject: Re: I'd rather switch than fight!
From: Marcus Harnisch <marcus.harnisch@gmx.net>
Date: Fri, 23 Apr 2010 12:14:50 +0200
Links: << >>  << T >>  << A >>
Chris Higgs <chiggs.99@googlemail.com> writes:

> I'd recommend casting your eye over this presentation. It details some
> of the advantages of the "2 process" coding style with a real world
> example (LEON SPARC-V8 processor).

Actually the rpesentation seems to compare two entirely different
designs done using different approaches. In this comparison, the
Two-Process-style appears to only *one* of the aspects.

-- 
Marcus

note that "property" can also be used as syntactic sugar to reference
a property, breaking the clean design of verilog; [...]

             (seen on http://www.veripool.com/verilog-mode_news.html)

Article: 147336
Subject: Re: I'd rather switch than fight!
From: Brian Drummond <brian_drummond@btconnect.com>
Date: Fri, 23 Apr 2010 12:35:05 +0100
Links: << >>  << T >>  << A >>
On Fri, 23 Apr 2010 01:03:03 -0700 (PDT), Chris Higgs
<chiggs.99@googlemail.com> wrote:

>On Apr 23, 5:38 am, KJ <kkjenni...@sbcglobal.net> wrote:
>
>> Ah well...as long as there are textbooks I guess there will always be
>> those disciples that think that separating combinatorial logic from
>> the register description actually is of some value to somebody,
>> somewhere at some point in time...but inevitably they come up short
>> when trying to demonstrate that value.
>
>http://www.gaisler.com/doc/structdes.pdf
>
>I'd recommend casting your eye over this presentation. It details some
>of the advantages of the "2 process" coding style with a real world
>example (LEON SPARC-V8 processor).
>

Not over the single-process style, which it doesn't even mention.
Other aspects of this document are worthwhile, however.

- Brian

Article: 147337
Subject: Re: I'd rather switch than fight!
From: KJ <kkjennings@sbcglobal.net>
Date: Fri, 23 Apr 2010 06:12:08 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 23, 1:01=A0am, Patrick Maupin <pmau...@gmail.com> wrote:
> On Apr 22, 11:38=A0pm, KJ <kkjenni...@sbcglobal.net> wrote:
>
> > > but latches are much easier to detect and rectify than some
> > > other possible logic problems.
>
> > And much easier to avoid in the first place too...with the correct
> > methodology (hint: =A0that would be the one that avoids using unclocked
> > processes)
>
> > Just having fun...like I said, every now and then it's good sport to
> > poke fun at the people who make their own problems.
>
> But, the reason I was unclear to start with, is that it's been so long
> since I've had an unintended latch (probably several years) that I
> really don't think that hard about it at all.

The two process people generally do fall back on excuses about being
misunderstood.

> =A0So you can think what
> you want, but the *reason* I code the way I do isn't really that much
> about latches at all (obviously, if I was *worried* about them, I
> would code everything in sequential blocks, where they could never
> happen,

Hmmm...so you prefer to take what you admit as unnecessary
chances....fair enough, that implies though that you expect some
actual benefit from that decision...but are probably unable to come up
with an actual example demonstrating that benefit.

> but I could have some other hard to find logic problems, which
> I *have* had in the past). =A0

Ahhh....one of those examples...now what sort of 'hard to find' logic
problem would you like to offer up to to the group to actually
demonstrate that two processes are better than one?  I'm willing to
listen, but I'll warn that you that every time in the past that this
debate pops up, the two process people are unable to coherently
describe anything other than vague generalities as you've done
here...so here is your opportunity to present a clear example
describing a 'hard to find' logic problem that is easier to find when
coded with two processes.  The clocked process folks (i.e. the one
process camp) have in the past presented actual examples to back their
claims, Googling for 'two process' in the groups should provide some
good cases.

> However, unintended latches just don't
> happen for me with my coding style, so I don't worry about it until
> somebody like you comes along to tell me about all the problems that
> I'm causing for myself that I never knew I had!

Whether you in particular have this problem, I don't know (apparently
not).  You in particular though are
- Doing more work (two process will always be more typing and lines of
code then one process),
- Producing less maintainable code (two process will always physically
separate related things based only on whether the logic signal is a
'register' or not)

Kevin Jennings

Article: 147338
Subject: Re: I'd rather switch than fight!
From: KJ <kkjennings@sbcglobal.net>
Date: Fri, 23 Apr 2010 07:02:09 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 23, 4:03=A0am, Chris Higgs <chiggs...@googlemail.com> wrote:
> On Apr 23, 5:38=A0am, KJ <kkjenni...@sbcglobal.net> wrote:
>
> > Ah well...as long as there are textbooks I guess there will always be
> > those disciples that think that separating combinatorial logic from
> > the register description actually is of some value to somebody,
> > somewhere at some point in time...but inevitably they come up short
> > when trying to demonstrate that value.
>
> http://www.gaisler.com/doc/structdes.pdf
>
> I'd recommend casting your eye over this presentation. It details some
> of the advantages of the "2 process" coding style with a real world
> example (LEON SPARC-V8 processor).
>

OK, but it doesn't compare it to the 'one process' approach, the
comparison is to a 'traditional method'.  The 'traditional method'
though is all about lumping all signals into records (refer to the
'Benefits' area of that document).  All of the comparisons are between
'traditional method' which has discrete signals and 'two-process
method' which lumps signals into a record.

There is absolutely nothing comparing 'one process' and 'two
process'.  Why the author chose to title his new method the 'two-
process' method is totally unclear...just another example either of
sloppy academic thinking to name your method after something that is
not even relevant to the point of the paper.

The author does mention "No distinction between sequential and comb.
signals" as being a "Problem".  Maybe it's a problem for the author,
but it's somewhat irrelevant for anyone skilled in design.  The author
presents no reason for why having immediate knowledge of whether a
signal comes out of a flip flop or a gate is relevant...(hint:  it's
not).  What is relevant is the logic that the signal represents and
whether it is implemented properly or not.  Whether 'proper
implementation' means the signal is a flop or not is of very little
concern (one exception being when you're generating gated
clocks...which is a different can of worms).

Even the author's 'State machine' example demonstrates the flaw of
using two processes.  Referring to slide #27 partially shown below,
note that (the undeclared) variable v has no default assignment, v
will result in a latch.

begin
  comb : process(...., r)
  begin
    case r.state is
      when first =3D>
        if cond0 then v.state :=3D second; end if;
      when second =3D>
...

This to me demonstrates that the author didn't even take the time to
compile his own code...and not notice the (possibly) unintended latch
that gets generated.  Maybe the author is living in an ASIC world
where latches are not a problem, who knows?  But in an FPGA, a latch
most certainly is indicative of a design problem more times than not.

You seem to have been caught up by his statement "A synchronous design
can be abstracted into two separate parts; a combinational and a
sequential" and the slide titled "Abstraction of digital logic" and
thought that this was somehow relevant to the point of his
paper...it's not...his point is all about combining signals into
records...totally different discussion.

The only conclusion to draw from this paper is that you shouldn't
believe everything you read...and you shouldn't accept statements that
do not stand up to scrutiny.

Kevin Jennings

Article: 147339
Subject: Re: How to over clock for DSP48
From: Martin Thompson <martin.j.thompson@trw.com>
Date: Fri, 23 Apr 2010 15:28:51 +0100
Links: << >>  << T >>  << A >>
fl <rxjwg98@gmail.com> writes:

> Hi,
> We are developing algorithm on a LYRTech ADC board. There are only 96
> DSP48 on this board. We have a problem of DSP shortage with a FIR
> rcosine and low pass FIR design. There is a 105 MHz clock source with
> this board. I think a solution is to over clock DSP48 to improve
> performance. My question is how to double, triple or quadruple 105MHz
> on board clock. Can DCM do the trick? Then, how to get that? 

Yes a DCM can do that.  Just instantiate it (and some BUFGs) and set
the parameters up.  Read up in the libraries guide and the user guide

Alternatively, coregen will guide your through the process and provide
you with a VHDL/Verilog file out the backend with an appropriately
configured DCM inside it.  This is probably worth doing the first time
anyway, to see what's involved and what sort of things come out the
back end.

Cheers,
Martin

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

Article: 147340
Subject: Re: confusion with ADC/DAC interface implementation
From: =?ISO-8859-2?Q?G=F3rski_Adam?= <gorskiamalpa@wpkropkapl>
Date: Fri, 23 Apr 2010 17:18:44 +0200
Links: << >>  << T >>  << A >>
alkosd@yahoo.co.uk pisze:
> Hi,
> i am confused regarding the ADC/DAC interface implementation on FPGA.
> I have read a code where after serialising the input data of 16 bits
> in 16 clock cycles, the interface logic loops (in vain?) for another
> 16 cyles  before serialising the next data. can#t understand why? why
> the serialisation of the next data is not done immediately. moreover,
> should the serialisation clock rate be 16 higher than the data stream
> clock rate? Sorry but i could not find a documentation detailing all
> the synchronization mechanism.
> 
> cheers :)

Hi,

Please specify your ADC DAC type.

BR

Adam

Article: 147341
Subject: Re: I'd rather switch than fight!
From: Chris Higgs <chiggs.99@googlemail.com>
Date: Fri, 23 Apr 2010 08:29:50 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 23, 3:02=A0pm, KJ <kkjenni...@sbcglobal.net> wrote:

> OK, but it doesn't compare it to the 'one process' approach, the
> comparison is to a 'traditional method'. =A0The 'traditional method'
> though is all about lumping all signals into records (refer to the
> 'Benefits' area of that document). =A0All of the comparisons are between
> 'traditional method' which has discrete signals and 'two-process
> method' which lumps signals into a record.

I think one of the points (implicitly) made by the paper is an
admission that the two-process method is a mess unless you use
records. I think it's also implied that 'traditional method' people
are more prone to using discrete signals rather than record types.

> The author does mention "No distinction between sequential and comb.
> signals" as being a "Problem". =A0Maybe it's a problem for the author,
> but it's somewhat irrelevant for anyone skilled in design. =A0The author
> presents no reason for why having immediate knowledge of whether a
> signal comes out of a flip flop or a gate is relevant...(hint: =A0it's
> not). =A0What is relevant is the logic that the signal represents and
> whether it is implemented properly or not. =A0Whether 'proper
> implementation' means the signal is a flop or not is of very little
> concern (one exception being when you're generating gated
> clocks...which is a different can of worms).

Sometimes it's necessary to use the combinatorial signal.

>
> Even the author's 'State machine' example demonstrates the flaw of
> using two processes. =A0Referring to slide #27 partially shown below,
> note that (the undeclared) variable v has no default assignment, v
> will result in a latch.

Yes, that's just sloppy.

> You seem to have been caught up by his statement "A synchronous design
> can be abstracted into two separate parts; a combinational and a
> sequential" and the slide titled "Abstraction of digital logic" and
> thought that this was somehow relevant to the point of his
> paper...it's not...his point is all about combining signals into
> records...totally different discussion.

Well combining state into records makes a "two-process" technique neat
enough to be feasible. Personally I use a similar style and I find it
very clear and understandable. As an example:

entity myentity is
    generic (
        register_output : boolean :=3D true
    );
    port (
        clk             : in  std_ulogic;
        srst            : in  std_ulogic;

        -- Input
        data            : in  some_type_t;

        -- Output
        result          : out another_type_t
    );
end;

architecture rtl of myentity is

    type state_enum_t is (IDLE, OTHER_STATES);

    type state_t is record
        state  : state_enum_t;
        result : another_type_t;
    end record;

    constant idle_state : state_t :=3D (state  =3D> IDLE,
                                      result =3D> invalid_result);

    signal r, rin : state_t;

begin

    combinatorial: process(r, srst, data)
        variable v : state_t;
    begin

        --DEFAULTS
        v :=3D r;
        v.result :=3D invalid_result;

        -- STATE MACHINE
        case v.state is
            when IDLE =3D>
                null;
            when OTHER_STATES =3D>
                null;
        end case;

        -- RESET
        if srst =3D '1' then
            v :=3D idle_state;
        end if;

        --OUTPUTS
        if register_output then
            result <=3D r.result;
        else
            result <=3D v.result;
        end if;

        rin <=3D v;
    end process;

    sequential : process(clk)
    begin
        if rising_edge(clk) then
            r <=3D rin;
        end if;
    end process;

end;

> The only conclusion to draw from this paper is that you shouldn't
> believe everything you read...and you shouldn't accept statements that
> do not stand up to scrutiny.

You can only use sequential processes and make it impossible to infer
a latch but lose the ability to use a combinatorially derived signal.
Alternatively you can use a two-process technique which allows
intermediate/derived signals to be used but accept the risk that bad
code will introduce latches. We can ague forever about which method is
more 'correct' but it's unlikely to boil down to anything other than
personal preference.

Thanks,

Chris

Article: 147342
Subject: Re: I'd rather switch than fight!
From: Jan Decaluwe <jan@jandecaluwe.com>
Date: Fri, 23 Apr 2010 08:32:48 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 22, 10:04=A0pm, Muzaffer Kal <k...@dspia.com> wrote:
> On Thu, 22 Apr 2010 08:08:59 -0700 (PDT), Jan Decaluwe

> >Quoting from the article:
> >"""
> >This example is more subtle and complex than it may seem at first
> >sight. As said before, variables dir and run are state variables and
> >will therefore require a flip-flop in an implementation. However, they
> >are also used =93combinatorially=94: when they change, they may influenc=
e
> >the counter operation =93in the same clock cycle=94, that is, before the
> >flip-flop output changes. This is perfectly fine behavior and no
> >problem for synthesis tools, but it tends to confuse a lot of
> >designers.
> >"""
>
> I am not sure who is really confused here.

You are: both about Verilog (suprizing) and about RTL synthesis
(anticipated).

> What is suggested in the
> above paragraph is not really feasible; assuming by 'dir' one refers
> to the output of a flop.
>
> The problem with the last verilog block shown is the dir and run are
> not flops anymore but combinational signals decoded from goleft and
> goright so the last direction will not be remembered. If last
> direction needs to be remembered, one needs to decode the
> 'instruction', use =A0the decoded value and remember the decoded value
> as above.

So this is now already the third post that I devote to explaining
to two seasoned Verilog designers how a very simple example in
their favourite language with the ultra-short learning curve
actually works. I'm beginning to think that Verilog designers
don't know how to use variables :-)

'dir' and 'run' keep their value over always block invocations, OK?
Depending on the conditions, they may or may not get a new
value. Basic Verilog stuff.

Then the implementation. Clearly there is both a sequential and
a combinatorial path from these variables. If you think this is
not feasible, don't argue with me, but just synthesize it and
simulate the result to verify.

FInally, RTL synthesis. No, 'dir' is not a flop and no, it isn't
combo logic either. It gives rise to both. Technically, the
same variable 'dir' creates multiple nodes in a multi-level
logic network that represents the code. Voil=E0.

Jan




Article: 147343
Subject: Re: I'd rather switch than fight!
From: Andy <jonesandy@comcast.net>
Date: Fri, 23 Apr 2010 08:34:30 -0700 (PDT)
Links: << >>  << T >>  << A >>
Coding clock enables in a combinatorial process requires an additional
assignment for the clock-disable case (otherwise you get a latch,
regardless of your naming convention). Only one assignment is required
(the enabled assignment) in a clocked process, and it is the
assignment you had to make anyway.

KJ has already well stated the problems with latches (requiring
additional assignments) in combinatorial processes/blocks, regardless
of the naming convention employed.

Any decent simulator (maybe not a half-decent one) will merge
processes or always blocks that share the same sensitivity list. Since
they are usually identical for all synchronous processes clocked by
the same clock, they get merged, thus improving performance by
avoiding duplicative process-related overhead. Since combinatorial
processes rarely share the same sensitivity list, they don't get
merged, and performance suffers.

Andy


Article: 147344
Subject: Re: confusion with ADC/DAC interface implementation
From: "HT-Lab" <hans64@ht-lab.com>
Date: Fri, 23 Apr 2010 16:49:39 +0100
Links: << >>  << T >>  << A >>

<alkosd@yahoo.co.uk> wrote in message 
news:3bf71478-a08c-4165-9af5-98edd3548e89@8g2000yqz.googlegroups.com...
> Hi,
> i am confused regarding the ADC/DAC interface implementation on FPGA.
> I have read a code where after serialising the input data of 16 bits
> in 16 clock cycles, the interface logic loops (in vain?) for another
> 16 cyles  before serialising the next data. can#t understand why?

As suggested by others your question is very vague, however, some SPI ADC have 
the option to stream out the LSB first. In order to do this you first need to 
stream out the MSB_first word and then you can read the LSB_first word (this 
makes perfect sense for a successive approximation ADC). Thus in the LSB case 
you need 2 sets of n-bit clock cycles.

Find the datasheets and (hopefully) all should become clear,

Hans
www.ht-lab.com


> why
> the serialisation of the next data is not done immediately. moreover,
> should the serialisation clock rate be 16 higher than the data stream
> clock rate? Sorry but i could not find a documentation detailing all
> the synchronization mechanism.
>
> cheers :) 



Article: 147345
Subject: Re: I'd rather switch than fight!
From: Patrick Maupin <pmaupin@gmail.com>
Date: Fri, 23 Apr 2010 09:08:05 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 23, 10:34=A0am, Andy <jonesa...@comcast.net> wrote:

> Coding clock enables in a combinatorial process requires an additional
> assignment for the clock-disable case (otherwise you get a latch,
> regardless of your naming convention). Only one assignment is required
> (the enabled assignment) in a clocked process, and it is the
> assignment you had to make anyway.

Oh, I see the point you're trying to make.  Two points I tried (and
obviously failed) to make are that (1) I don't mind extra typing,
because it's really all about readability (obviously, from the
discussion, my opinion of what is readable may differ from others);
and (2) With the canonical two process technique, the sequential
process becomes boilerplate (even to the point of being able to be
generated by a script or editor macro, in most cases) that just
assigns a bunch of 'x <=3D next_x' statements.  The top of the
combinatorial process becomes boilerplate as well, with corresponding
'next_x =3D x' statements (for some variables, it could be other things,
e.g. 'next_x =3D 0'.  But you can just glance at those and not think
about it.  So, when reading, you aren't really looking at that, or the
register declarations.

Once you accept that the sequential block, and the top of the
combinatorial block, are both boilerplate that you don't even need to
look at, then it's no more work than anything else.  (In fact, if you
can type faster than 20 wpm and/or know how to write scripts or editor
macros, it's less work overall.)

> KJ has already well stated the problems with latches (requiring
> additional assignments) in combinatorial processes/blocks, regardless
> of the naming convention employed.

I understand the issue with latches.  I just never see them.  The
coding style makes it easy to check and avoid them.  It can even be
completely automatic if you have a script write your boilerplate.

> Any decent simulator (maybe not a half-decent one) will merge
> processes or always blocks that share the same sensitivity list. Since
> they are usually identical for all synchronous processes clocked by
> the same clock, they get merged, thus improving performance by
> avoiding duplicative process-related overhead. Since combinatorial
> processes rarely share the same sensitivity list, they don't get
> merged, and performance suffers.

I'm pretty sure that verilator is smart enough to figure all this
out.  That's the simulator I use if I care about execution time.

Regards,
Pat

Article: 147346
Subject: Re: I'd rather switch than fight!
From: Patrick Maupin <pmaupin@gmail.com>
Date: Fri, 23 Apr 2010 09:25:50 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 23, 8:12=A0am, KJ <kkjenni...@sbcglobal.net> wrote:

> The two process people generally do fall back on excuses about being
> misunderstood.

Well, I'm not going to generalize about "one process people" but at
least some of them are supercilious bastards who think that anybody
who doesn't do things their way is an idiot.  BTW, this is the last
post I'm going to reply to you on, so feel free to have fun with more
piling on.

> Hmmm...so you prefer to take what you admit as unnecessary
> chances....fair enough, that implies though that you expect some
> actual benefit from that decision...but are probably unable to come up
> with an actual example demonstrating that benefit.

Well, I haven't used the single process style in many years, so no, I
can't point you directly to the issues I had that led me to switch.
But I have helped others to switch over they years, and they have all
been grateful.  In any case, I posted elsewhere in this thread a
pointer to Cliff Cumming's paper on blocking vs non-blocking
assignments.  I assume you've been studiously avoiding that for
plausible deniability, so here it is:  http://www.sunburst-design.com/paper=
s/CummingsSNUG2000SJ_NBA.pdf

If you read this paper carefully, you will come to an understanding
that, while it is often possible to follow it using a single process
method, in many cases, in order to follow it, you will have to assign
related variables from *different* sequential processes (one blocking
sequential process, one non-blocking sequential process).  With the
sequential/combinatorial process method, using the boilerplate for
sequential processes is actually very easy and requires little
thinking, and allows you to do all the real work of coding on related
variables within the same combinatorial process, with a sequential
boilerplate process.  You can concentrate all your hard thinking on
the problem at hand, in the non-boilerplate code in the combinatorial
process.

> > but I could have some other hard to find logic problems, which
> > I *have* had in the past). =A0
>
> Ahhh....one of those examples...now what sort of 'hard to find' logic
> problem would you like to offer up to to the group to actually
> demonstrate that two processes are better than one? =A0I'm willing to
> listen, but I'll warn that you that every time in the past that this
> debate pops up, the two process people are unable to coherently
> describe anything other than vague generalities as you've done
> here...so here is your opportunity to present a clear example
> describing a 'hard to find' logic problem that is easier to find when
> coded with two processes. =A0The clocked process folks (i.e. the one
> process camp) have in the past presented actual examples to back their
> claims, Googling for 'two process' in the groups should provide some
> good cases.

That's because you're *not* really willing to listen.  If you were,
you would have heard, from me, anyway, loud and clear, that it's not
really about the *language constructs*, it's about how much people can
hold in their heads at a single time.  The two process method reduces
the need for that, so even if I presented an example where it helped
me in my thinking, you would just superciliously explain how any idiot
should have seen the error in the one process method, so it doesn't
prove anything.  Since you're the smartest asshole in the world, the
two process method couldn't possibly offer any benefits you would be
interested in, so just forget about it.

> - Producing less maintainable code (two process will always physically
> separate related things based only on whether the logic signal is a
> 'register' or not)

See, this is another place where you haven't listened.  What don't you
understand about 'boilerplate'?  It's a tiny bit of overhead, not
really part of what you need to worry about in maintenance.  It is
easily checked and even automated.

Regards,
Pat

Article: 147347
Subject: Re: I'd rather switch than fight!
From: Muzaffer Kal <kal@dspia.com>
Date: Fri, 23 Apr 2010 09:57:07 -0700
Links: << >>  << T >>  << A >>
On Fri, 23 Apr 2010 08:32:48 -0700 (PDT), Jan Decaluwe
<jan@jandecaluwe.com> wrote:
>So this is now already the third post that I devote to explaining
>to two seasoned Verilog designers how a very simple example in
>their favourite language with the ultra-short learning curve
>actually works. I'm beginning to think that Verilog designers
>don't know how to use variables :-)
>

Actually it was mostly a matter of not paying close attention to
something one "knows" would not work. Of course in a clocked process
if a register is not assigned in a path it remembers its value so a
register is inferred and if it's a blocking assignment, its value is
available in the same clock cycle. When one finally puts these
together, your example is "obvious". 
And you're right; personally I don't use variables in this fashion. I
would write the same logic as follows:

if (turnleft) was_turnleft <= 1;
if (turnleft || was_turnleft) do_left turn;

which I think how the synthesizer would generate the logic for your
example.

-- 
Muzaffer Kal

DSPIA INC.
ASIC/FPGA Design Services

http://www.dspia.com

Article: 147348
Subject: Re: Quartus II under Windows7?
From: Wastrel <stephensdigital@gmail.com>
Date: Fri, 23 Apr 2010 10:19:07 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 21, 1:08=A0pm, Jon Beniston <j...@beniston.com> wrote:
> It's running ok for me on Windows 7 64-bit.
>
> What particular part of the software are you having problems with?
>
> Jon

Well it installs alright, but Altium Designer 6 can't find it -
whereas it did on my XP box. One problem is that Windows 7 likes to
put 32 bit legacy programs under Program FIles(x86), but Quartus won't
install there because it can't handle spaces or special characters in
it's filenames.

Article: 147349
Subject: Re: Quartus II under Windows7?
From: Wastrel <stephensdigital@gmail.com>
Date: Fri, 23 Apr 2010 10:22:41 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 21, 6:42=A0pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
> Wastrel <stephensdigi...@gmail.com> wrote:
> > My XP box died the other day and was replaced by a 64 bit Windows7
> > machine. Now my $%^&Quartus II software won't run, and Altera says
> > Win7 ain't supported. Anybody know of a workaround? I'm developing on
> > the Altera Cyclone III FPGA on the Altium Designer NanoBoard 3000.
>
> Win7 has an option to tell the program that it is running on
> a previous version of windows, as far as such checks are concerned.
>
> As far as the design software, that is likely to work.
>
> As you might need a device driver to talk to USB to download
> the bitstream, that might be system dependent, such that it
> won't work.
>
> -- glen

The bitstream gets downloaded by Altium Designer via JTAG and that
part still works. Can you elaborate on the previous version of windows
option. As I mentioned earlier, running Quartus under Program
Files(x86) won't work becuase Quartus won't install under that
directory.

Thanks,

Bob



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