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 132025

Article: 132025
Subject: Re: ISE 9.2 - how do I extract component/slice placements for locking down a design?
From: "Fred" <fred@n0spam.com>
Date: Sat, 10 May 2008 10:35:31 +0100
Links: << >>  << T >>  << A >>
Hi Greg, Kevin,

Many thanks for your reply.  In essence I want to take a completed design, 
with critical timing constraints, and import it as an IP_Core into EDK where 
the added logic has very lax timing constraints.

I would like to take the component placement for the fitted critical part 
and lock these down.  I want to use this new UCF file with all the placement 
information in EDK with a hope that timing may be achieved which it doesn't 
at present.

I will certainly look at Floorplanner to see how this can help.

Many thanks again.

Fred


"SoyAnarchisto" <greg.daughtry@gmail.com> wrote in message 
news:35098c3c-3117-4083-899e-5c4226f15239@a23g2000hsc.googlegroups.com...
> Fred,
>
> ngd does not have placement information, I think you are referring to
> ncd.  Beginning w/ ISE 10.1 PlanAhead is shipped with all versions of
> ISE, including the webpack (free) version.  Prior to that PlanAhead
> was a separate optional tool, but evaluation licenses are readily
> available for the asking:
>
> http://www.xilinx.com/ise/optional_prod/planahead.htm
>
> PlanAhead is a fairly straightforward tool to use.  At a high level,
> to do what you are asking:
>
> 1) download and install planAhead
> 2) create a project by importing an edif/ngc netlist and optionally
> ucf constraints (and pick a target device if ngc).
> 3) File->Import Placement and browse to your placed and/or routed ncd
> file
>
> This will import placement from an ncd file and convert them to LOC
> and BEL constraints.
>
> At this point you have tons of options, depending on what you are
> trying to accomplish.  You can go to File->Export Floorplan to write
> out all these loc/bels into a ucf file, but a huge file of locs is of
> limited use, for floorplanning, timing closure, ip reuse flows.
>
> Take a look at the PlanAhead tutorial and methodology guides, as a
> starting point.  More questions will doubtlessly follow...
>
> 'Greg
>
> On May 9, 11:14 am, Kevin Neilson
> <kevin_neil...@removethiscomcast.net> wrote:
>> Fred wrote:
>> > Is there any NGD reader which can extract placement information?
>>
>> > I know I can use FPGA editor and go through all the primitives, one by
>> > one, but this would be a mamoth task!  Any ideas?
>>
>> Are you trying to floorplan or trying to figure out how PAR performed
>> placement?  If the former, PlanAhead is a very nice tool for
>> floorplanning.  -Kevin
> 



Article: 132026
Subject: getting samples from an RF board onto the system
From: vits <vittal.patil@gmail.com>
Date: Sat, 10 May 2008 04:10:16 -0700 (PDT)
Links: << >>  << T >>  << A >>
hi,
I have got an RF board (antenna+ADC+Some signal processing boxes on a
board). The output is a 2bit data and a clock (16MHz). I need to store
this 2 bit data for 1 second onto my system in some text or binary
format for using it in my simulations.
What is the best (in very less time) method to do this?
Any ideas
Thanks,
Vittal

Article: 132027
Subject: Re: getting samples from an RF board onto the system
From: Arlet Ottens <usenet+5@c-scape.nl>
Date: Sat, 10 May 2008 17:18:44 +0200
Links: << >>  << T >>  << A >>
vits wrote:

> I have got an RF board (antenna+ADC+Some signal processing boxes on a
> board). The output is a 2bit data and a clock (16MHz). I need to store
> this 2 bit data for 1 second onto my system in some text or binary
> format for using it in my simulations.
> What is the best (in very less time) method to do this?
> Any ideas

The quickest method is to get a PC based logic analyzer. Make sure you 
get one with a capture buffer that's deep enough, and has some means to 
export the data.

Article: 132028
Subject: Xilinx ML507 evaluation board (V5FXT70)?
From: "TSIuser" <tsiuser@w200k.com>
Date: Sat, 10 May 2008 09:03:49 -0700
Links: << >>  << T >>  << A >>
A past google-search revealed Xilinx employees saying this board will
be equipped with a Virtex5/FXT70.  From what I remember, the
FXT70 requires a full-seat of ISE Foundation 10.x (or the equivalent
evaluation-edition), and won't compile in Webpack 10.x.

Is that correct?  Looks like I may have to stick with the much more
affordable Spartan-3A/DSP-1800 Microblaze kit... 



Article: 132029
Subject: Re: Anyway to secure a Xilinx NGC file ?
From: Muzaffer Kal <kal@dspia.com>
Date: Sat, 10 May 2008 09:19:30 -0700
Links: << >>  << T >>  << A >>
On Fri, 9 May 2008 13:09:40 -0700 (PDT), SoyAnarchisto
<greg.daughtry@gmail.com> wrote:

>http://syndicated.synplicity.com/Q306/aldec.html
>
>ngc2edif will not extract encrypted cores.
>
>Is it perfectly secure?  I'll leave that answer as an exercise for the
>reader....

Is there an encyrption method XST understands?

Article: 132030
Subject: Re: Anyway to secure a Xilinx NGC file ?
From: John McCaskill <jhmccaskill@gmail.com>
Date: Sat, 10 May 2008 10:39:31 -0700 (PDT)
Links: << >>  << T >>  << A >>
On May 10, 10:19 am, Muzaffer Kal <k...@dspia.com> wrote:
> On Fri, 9 May 2008 13:09:40 -0700 (PDT), SoyAnarchisto
>
> <greg.daugh...@gmail.com> wrote:
> >http://syndicated.synplicity.com/Q306/aldec.html
>
> >ngc2edif will not extract encrypted cores.
>
> >Is it perfectly secure?  I'll leave that answer as an exercise for the
> >reader....
>
> Is there an encyrption method XST understands?


XST has encryption built in.  To get access to the encryption tools,
you need to talk to your FAE about becoming part of the Xilinx
Alliance Program.

http://www.xilinx.com/products/alliance/overview.htm

Regards,

John McCaskill
www.FasterTechnology.com


Article: 132031
Subject: Re: 5 V oscillator output to GCLK
From: "KJ" <kkjennings@sbcglobal.net>
Date: Sat, 10 May 2008 15:08:47 -0400
Links: << >>  << T >>  << A >>

"Jim Granville" <no.spam@designtools.maps.co.nz> wrote in message 
news:48255f20@clear.net.nz...
> Peter Alfke wrote:
>
>> So let's reduce the series resistor at the source to 25 Ohm, and keep
>> the parallel termination at the destination at 50 Ohm.
>> That puts 2/3 of Vcc on the cable and the FPGA input = 3.3 V. The 25
>> Ohm includes the drive impedance, which might mean no external series
>> resistor at all...
>> Peter
>
> Yes, that would work, However....
>
> # You are no longer doing strict series-impedance-match termination
> # One can tell you are used to high-power FPGAs ;)

Oscillators typically can't drive 50 ohms impedances either so impedance 
matching to the PCB would not be relevant....the optimal solution would be a 
series resistor of  ~1.75x - 2x, parallel to ground of 3x where 'x' needs to 
be determined based on the spec'ed drive capability of the oscillator.  An 
IBIS or Spice model would determine 'x'.  Assuming the osc to be 50MHz or 
less, a PCB impedance of ~50 ohms, I'd suspect that x ~ 50-75 would give 
good signal quality and meet Vih requirements at the FPGA.

>  - as this sugestion adds a cost of 33mA in power budget (@50% clk duty 
> cycle).
>
> Suppose the target was a Zero power CPLD ?
> The whole device Icc might be 14.6mA at 200Mhz - 7.5mA @ 100MHz.
> [OP did not mention speed, but 5V sources are << 100Mhz ]
>
> The clock-terminator is consuming far more power than the CPLD !
>

If power consumption was even remotely close to the case that the OP was has 
in mind he wouldn't bother with any of this...he would've replaced the 5V 
osc with a 3.3V one.  Presumably there is some reason for even wanting to 
have a 5V osc on the board in the first place, but minimizing power 
consumption is not the reason.

Kevin Jennings 



Article: 132032
Subject: how to set trigger in ChipScopePro for this
From: Pratap <pratap.iisc@gmail.com>
Date: Sat, 10 May 2008 13:32:07 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi all,
    I have an application where my data refreshes every 10
seconds...It takes so long as I am doing some sort of an averaging
over a few million samples and then taking the statistics once in
those few million samples.My system clock is of 40 MHz and it's fed
from outside through a SMA connector in Virtex2P board. Hence to get
16 meaningful samples I should have to wait around 160 seconds.
These are the methods I tried....
option 1:   I used a clock for Chipscope pro which has a period of 10
seconds....But in this case it tkes a huge time to get the
data...around 600 sec for getting 16 samples...even though the values
make sence
Option 2:  I am using the system clock iteslf for chipscope clock, and
once in 1 seconds I generate a high pulse of width of 1 period of sys.
clock and trigger data with that...but it takes all the data points
after the trigger condition and hence I effectively get 1 data
point.It's fast but doesn't help much

Is there any method by which I can take the data values only at the
high values of the pulse and hence all data point will be different.

Thanks in advance,
Pratap

Article: 132033
Subject: Re: 5 V oscillator output to GCLK
From: "KJ" <kkjennings@sbcglobal.net>
Date: Sat, 10 May 2008 19:56:05 -0400
Links: << >>  << T >>  << A >>
Correction to previous post.  I'd suspect 'x' to be ~25-40, not 50-75.

KJ 



Article: 132034
Subject: Re: how to set trigger in ChipScopePro for this
From: "Marty Ryba" <martin.ryba.nospam@verizon.net>
Date: Sun, 11 May 2008 00:53:34 GMT
Links: << >>  << T >>  << A >>
"Pratap" <pratap.iisc@gmail.com> wrote in message 
news:3e857ede-ca9d-458d-a548-047d2d7cb743@w34g2000prm.googlegroups.com...
> These are the methods I tried....
> option 1:   I used a clock for Chipscope pro which has a period of 10
> seconds....But in this case it tkes a huge time to get the
> data...around 600 sec for getting 16 samples...even though the values
> make sence
> Option 2:  I am using the system clock iteslf for chipscope clock, and
> once in 1 seconds I generate a high pulse of width of 1 period of sys.
> clock and trigger data with that...but it takes all the data points
> after the trigger condition and hence I effectively get 1 data
> point.It's fast but doesn't help much

The ILA works like a logic analyzer; there is a "trigger" and then on each 
clock the data is sampled until the buffer is full. My guess is that in 
constructing the ILA core, 16 samples is the minimum buffer length (I've 
generally used many more). I think you would need to use some form of 
register I/O off the board to instead sample the data yourself to do any 
better.

Good Luck,
Marty



Article: 132035
Subject: Re: how to set trigger in ChipScopePro for this
From: Joseph Samson <user@not.my.company>
Date: Sat, 10 May 2008 21:20:42 -0400
Links: << >>  << T >>  << A >>
Pratap wrote:
> Hi all,
[snip]

> Is there any method by which I can take the data values only at the
> high values of the pulse and hence all data point will be different.
I don't have ChipScope in front of me, so this is from memory. The 
trigger settings allow you to specify a number of 'windows' (I think 
that's what they're called) and the number of samples per window. If 
your buffer size is 1024 and you choose 512 windows, then each window 
would have 2 samples. You would set the trigger to the pulse signal, and 
then Chipscope would show you 512 consecutive triggers.


---
Joe Samson
Pixel Velocity

Article: 132036
Subject: Re: Problem writing quadrature decoder
From: Peter Alfke <alfke@sbcglobal.net>
Date: Sat, 10 May 2008 20:34:06 -0700 (PDT)
Links: << >>  << T >>  << A >>
On May 10, 1:45=A0am, Jim Granville <no.s...@designtools.maps.co.nz>
wrote:
> glen herrmannsfeldt wrote:
> > Peter Alfke wrote:
> > (snip, I wrote)
>
> >>> I like the clocked design that Peter A. has in another post.
> >>> I believe that one works as long as the clock is faster than
> >>> the fastest possible real count. =A0Bounces might be missed, but
> >>> the count will be right.
>
> >> Bounces should (or must) be missed..
> >> That's the whole purpose of the circuit =A0.:-)
>
> > If it bounces long enough, up to the next clock pulse,
> > it won't be missed. =A0 As long as the extra counts come
> > in matched (up and down) pairs, the count is right.
>
> Correct. Peter has published a partial VHDL source, and
> the design he is talking about uses what I'd call an
> anti-Chatter-Filter, which is a back-lash state
> engine that uses hand-over edges.
>
> That could be a good idea on a user-interface,
> (less flicker effects) but could be a bad idea
> on a closed loop control system driven from a rotary encoder.
>
> -jg

Agreed. The circuit was invented for a manually operated frequency-
control application. I like its simplicity and lack of any analog
components. But there is backlash which never bothered us in the
intended application.
What's the best solution for servo-applications where the backlash is
bothersome? Counting all contact bounce might be risky...
Peter Alfke
W

Article: 132037
Subject: Re: 5 V oscillator output to GCLK
From: Peter Alfke <alfke@sbcglobal.net>
Date: Sat, 10 May 2008 20:40:06 -0700 (PDT)
Links: << >>  << T >>  << A >>
On May 10, 1:37=A0am, Jim Granville <no.s...@designtools.maps.co.nz>
wrote:
> Peter Alfke wrote:
> > On May 9, 7:57 pm, Jim Granville <no.s...@designtools.maps.co.nz>
> > wrote:
>
> >>Peter Alfke wrote:
>
> >>>On May 9, 5:19 pm, Jim Granville <no.s...@designtools.maps.co.nz>
> >>>wrote:
>
> >>>>Peter Alfke wrote:
>
> >>>>>When you series-terminate the driver, and parallel-terminate the
> >>>>>receiver, each with a resistor that equals the characteristic
> >>>>>impedance of the clock trace, then a fast transition sees just a
> >>>>>resistive divider, not a lumped capacitance.
> >>>>>That's the beauty of terminated transmission lines...
>
> >>>>That's true, until it bangs into the lumped input capacitance of the
> >>>>FPGA.
> >>>>You also get a voltage-loss with this focus on transmission
> >>>>line matching, which might give noise margin issues, as
> >>>>well as Buffer Current adders, from the lower Vih.
>
> >>>>-jg
>
> >>>Let's not forget: "Voltage loss" was the purpose of the whole
> >>>exercise...
> >>>Peter
>
> >>I should have been clearer :
> >>Equal Source/Load terminations will turn the 5V swing into 2.5V Hi, on a=

> >>3.3V system.
> >>The ideal Vih is 3.3V, (lowest power, best noise immunity), so this
> >>is a lower Vih, which was the 'voltage loss' I was getting at.
>
> >>-jg
>
> > So let's reduce the series resistor at the source to 25 Ohm, and keep
> > the parallel termination at the destination at 50 Ohm.
> > That puts 2/3 of Vcc on the cable and the FPGA input =3D 3.3 V. The 25
> > Ohm includes the drive impedance, which might mean no external series
> > resistor at all...
> > Peter
>
> Yes, that would work, However....
>
> # You are no longer doing strict series-impedance-match termination
> # One can tell you are used to high-power FPGAs ;)
> =A0 - as this sugestion adds a cost of 33mA in power budget (@50% clk duty=

> cycle).
>
> Suppose the target was a Zero power CPLD ?
> The whole device Icc might be 14.6mA at 200Mhz - 7.5mA @ 100MHz.
> [OP did not mention speed, but 5V sources are << 100Mhz ]
>
> The clock-terminator is consuming far more power than the CPLD !
>
> -jg

Just to belabor a point: When the output side of a transmission line
is parallel-terminated, there is no requirement to also properly
terminate the driving side. Using a "wrong" series resistor to adjust
the amplitude is ok, since there is no signal coming back to the
driver, and thus no need for proper termination at that end.
Peter Alfke

Article: 132038
Subject: Re: Problem writing quadrature decoder
From: John_H <newsgroup@johnhandwork.com>
Date: Sat, 10 May 2008 21:57:55 -0700
Links: << >>  << T >>  << A >>
Peter Alfke wrote:
<snip>
> What's the best solution for servo-applications where the backlash is
> bothersome? Counting all contact bounce might be risky...
> Peter Alfke
> W

If the count choices are 347 and 348 on either side of the bounce and 
only those two counts, what risk is there?

- John_H

Article: 132039
Subject: Re: Problem writing quadrature decoder
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Sun, 11 May 2008 18:41:27 +1200
Links: << >>  << T >>  << A >>
Peter Alfke wrote:
> On May 10, 1:45 am, Jim Granville <no.s...@designtools.maps.co.nz>
> wrote:
>>Correct. Peter has published a partial VHDL source, and
>>the design he is talking about uses what I'd call an
>>anti-Chatter-Filter, which is a back-lash state
>>engine that uses hand-over edges.
>>
>>That could be a good idea on a user-interface,
>>(less flicker effects) but could be a bad idea
>>on a closed loop control system driven from a rotary encoder.
>>
>>-jg
> 
> 
> Agreed. The circuit was invented for a manually operated frequency-
> control application. I like its simplicity and lack of any analog
> components. But there is backlash which never bothered us in the
> intended application.

It could ba a good thing, in a manual system, as it would avoid flicker.
The eye does not like flicker.

I've seen some hand-rotary encoders where the detent aligns with
one of the edges, which would seem to be asking for chatter-by-design :)

> What's the best solution for servo-applications where the backlash is
> bothersome? Counting all contact bounce might be risky...

The Sampled-clock nature gives a natural LPF, so the only risk I can
see, is if the logic somehow 'missed' balancing the INC and DECs.
A well coded design should not do that. It should just pack
INC/DEC/INC with possible idle clocks between them.

The code Peter posted maps the illegal states onto rotary_left,
so there is risk there of overrange conditions creeping left.

Lowest power rotary encoder would use SPDT contacts, but I have not
seen those commercially ?

-jg


Article: 132040
Subject: Re: Problem writing quadrature decoder
From: Eric Smith <eric@brouhaha.com>
Date: Sun, 11 May 2008 00:47:21 -0700
Links: << >>  << T >>  << A >>
John_H <newsgroup@johnhandwork.com> writes:
> If the count choices are 347 and 348 on either side of the bounce and
> only those two counts, what risk is there?

If you count on both edge polarities, and you never miss any edges,
no problem.  Ensuring that you never miss an edge is problematic.
If you get a runt pulse, you might only count on the leading edge but
not the trailing edge of the pulse.

If you can guarantee some minimum pulse width, then there should be
no problem.  But how do you guarantee that for bounce?


Article: 132041
Subject: Re: Breaking News ... Accellera Verification Working Group Forming
From: harrytheasicguy@gmail.com
Date: Sun, 11 May 2008 01:18:03 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 25, 10:35 am, HairyTheASIC...@gmail.com wrote:
> Read All About It athttp://synopsysoc.org/thestandardsgame/?p=3D64!
>
> On her Standards Game Blog today, Karen Bartleson announced that
> Accellera formed a subcommittee to define a standard for verification
> interoperability.
>
> That is, Synopsys is stepping up to an industry leadership position to
> settle the VMM / OVM war.
>
> This is the right move to do this in Accellera because it gives us
> input into the process, rather than just the EDA vendors controlling
> the process for their own benefit.  Karen points out in her blog that
> it was user pressure they heard that made them open up VMM.  That's
> us!
>
> If you want to get your copy of the open VMM code that the new
> Accellera working group will use you will need to wait until they get
> the working group web landing page created.  Karen did not say who
> would chair the group, but if you want her to pass your name on to the
> new chair, you can email her at karenb @ synopsys . com.
>
> I can't wait to get my copy of open VMM!
>
> Of course, Synopsys is telling us that they are just doing the right
> thing.  But having them donate VMM to Accellera as the basis of a
> single methodology library opens the next question.
>
> How will Cadence and Mentor respond?  Hopefully they=92ll join the
> effort to add OVM features not found in VMM.  Let=92s keep the pressure
> on them.

For the record, I am the real "Harry the ASIC Guy" whose blog post was
"modified" by the originator of this thread, cowardly posting behind
the email shield of "hairytheasicguy@gmail.com". You can find my
legitimate blog at the following URL ... http://theASICguy.com.  You
can also find my original post on this topic at
http://theasicguy.com/2008/04/24/breaking-news-accellera-verification-workin=
g-group-forming/.

I do not know why "hairy" decided to take my original post, modify and
add to it, and then publish under this obviously contrived email
address. Is this a childish prank? Hairy, if you have something to
say, please have the courage to do so using your real identity.

I've tried to contact "hairy" by email twice about this but gotten no
response. What really bothers me is that he is using an email address
that is confusing my readers. If anyone can help me figure out who
this person is or how to really get in touch with him at his "regular"
email, then perhaps that would help. You can post to this newsgroup or
contact me thru email: harry at theASICguy.com


Article: 132042
Subject: Re: how to set trigger in ChipScopePro for this
From: Brian Drummond <brian_drummond@btconnect.com>
Date: Sun, 11 May 2008 11:21:29 +0100
Links: << >>  << T >>  << A >>
On Sat, 10 May 2008 13:32:07 -0700 (PDT), Pratap <pratap.iisc@gmail.com>
wrote:

>Hi all,
>    I have an application where my data refreshes every 10
>seconds...

>Option 2:  I am using the system clock iteslf for chipscope clock, and
>once in 1 seconds I generate a high pulse of width of 1 period of sys.
>clock and trigger data with that...but it takes all the data points
>after the trigger condition and hence I effectively get 1 data
>point.It's fast but doesn't help much
>
>Is there any method by which I can take the data values only at the
>high values of the pulse and hence all data point will be different.
>

You can add that pulse to the data, and use it as a qualifier, so that
only data samples matching that qualifier are stored.

- Brian 

Article: 132043
Subject: Re: Problem writing quadrature decoder
From: nospam <nospam@please.invalid>
Date: Sun, 11 May 2008 15:28:46 +0100
Links: << >>  << T >>  << A >>
Eric Smith <eric@brouhaha.com> wrote:

>John_H <newsgroup@johnhandwork.com> writes:
>> If the count choices are 347 and 348 on either side of the bounce and
>> only those two counts, what risk is there?
>
>If you count on both edge polarities, 

You should not count edges you should sample states. It doesn't matter if
you miss bounce states as long as you don't miss true encoder change
states. FPGA implementations can sample at ridiculously fast rates compared
to state changes from physical encoders.

Below is verilog for a decoder with position counter. It counts all states
(that is 400 counts for one revolution of a 100 line encoder). If you don't
like the LSB jittering with bounce just ignore it? 


module qecounter(
    // Outputs 
    count,
    // Inputs
    a,
    b,
    arst,
    srst,
    clk
);

parameter counter_width = 16;

output [counter_width - 1 : 0] count;

input a;
input b;
input arst;
input srst;
input clk;

reg [counter_width - 1 : 0] count;
reg la;
reg lb;
reg lla;
reg llb;

always @(posedge clk or posedge arst) begin
   if(arst) begin
       la <= 0;
       lb <= 0;
       lla <= 0;
       llb <= 0;
       count <= 0;
   end else begin
       la <= a;
       lb <= b;
       lla <= la;
       llb <= lb;

       if(srst) begin
           count <= 0;
       end else begin
           
           case({lb, la, llb, lla})
        
               // increment count states
               4'b0001,   
               4'b0111,
               4'b1000,   
               4'b1110 : count <= count + 1;   
        
               // decrement count states
               4'b0010,    
               4'b0100,    
               4'b1011, 
               4'b1101 :  count <= count - 1;
        
               // nop states
        //     4'b0000,   
        //     4'b0101,   
        //     4'b1010,   
        //     4'b1111 :  
        
               // invalid states 
        //     4'b0011,   
        //     4'b0110,   
        //     4'b1001,   
        //     4'b1100 :   
                   
            endcase
        end
    end
end    
      
endmodule
-- 

Article: 132044
Subject: Re: Problem writing quadrature decoder
From: Peter Alfke <alfke@sbcglobal.net>
Date: Sun, 11 May 2008 09:30:32 -0700 (PDT)
Links: << >>  << T >>  << A >>
On May 11, 12:47=A0am, Eric Smith <e...@brouhaha.com> wrote:
> John_H <newsgr...@johnhandwork.com> writes:
> > If the count choices are 347 and 348 on either side of the bounce and
> > only those two counts, what risk is there?
>
> If you count on both edge polarities, and you never miss any edges,
> no problem. =A0Ensuring that you never miss an edge is problematic.
> If you get a runt pulse, you might only count on the leading edge but
> not the trailing edge of the pulse.
>
> If you can guarantee some minimum pulse width, then there should be
> no problem. =A0But how do you guarantee that for bounce?

So let's talk about solutions:
I offered a solution that never makes a cumulative mistake, resolves a
single quadrant, but has a one-quadrant hysteresis.
It also happens to be very simple, and has no analog components.
Who offers something better, i.e. without the hysteresis, but with the
same reliability?
Peter Alfke

Article: 132045
Subject: Re: Problem writing quadrature decoder
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Mon, 12 May 2008 08:02:32 +1200
Links: << >>  << T >>  << A >>
Peter Alfke wrote:
> On May 11, 12:47 am, Eric Smith <e...@brouhaha.com> wrote:
> 
>>John_H <newsgr...@johnhandwork.com> writes:
>>
>>>If the count choices are 347 and 348 on either side of the bounce and
>>>only those two counts, what risk is there?
>>
>>If you count on both edge polarities, and you never miss any edges,
>>no problem.  Ensuring that you never miss an edge is problematic.
>>If you get a runt pulse, you might only count on the leading edge but
>>not the trailing edge of the pulse.
>>
>>If you can guarantee some minimum pulse width, then there should be
>>no problem.  But how do you guarantee that for bounce?
> 
> 
> So let's talk about solutions:
> I offered a solution that never makes a cumulative mistake, 

(unless you hit it will illegal states, then it creeps left ;)

[easily fixed, with one x ]

      rotary_event <= (rotary_q1 xor delay_rotary_q1) xor (rotary_q2 
xor delay_rotary_q2);		


> resolves a
> single quadrant, but has a one-quadrant hysteresis.

That is a separate 2 bit state-filter, which can be added to any Quad
Encoder system.
As such, it is a useful option for manual systems, but I would
call it sub-optimal for a control system

> It also happens to be very simple, and has no analog components.
> Who offers something better, i.e. without the hysteresis, but with the
> same reliability?

If a system catches a runt pulse LOW it must capture a following HI
and so do the correct +/-1. Provided a system can accept adjacent
Inc/dec commands, it will not get lost.
A good test should verify that.

-jg


Article: 132046
Subject: Re: Problem writing quadrature decoder
From: Peter Alfke <alfke@sbcglobal.net>
Date: Sun, 11 May 2008 13:44:58 -0700 (PDT)
Links: << >>  << T >>  << A >>
On May 11, 1:02=A0pm, Jim Granville <no.s...@designtools.maps.co.nz>
wrote:
> Peter Alfke wrote:
> > On May 11, 12:47 am, Eric Smith <e...@brouhaha.com> wrote:
>
> >>John_H <newsgr...@johnhandwork.com> writes:
>
> >>>If the count choices are 347 and 348 on either side of the bounce and
> >>>only those two counts, what risk is there?
>
> >>If you count on both edge polarities, and you never miss any edges,
> >>no problem. =A0Ensuring that you never miss an edge is problematic.
> >>If you get a runt pulse, you might only count on the leading edge but
> >>not the trailing edge of the pulse.
>
> >>If you can guarantee some minimum pulse width, then there should be
> >>no problem. =A0But how do you guarantee that for bounce?
>
> > So let's talk about solutions:
> > I offered a solution that never makes a cumulative mistake,
>
> (unless you hit it will illegal states, then it creeps left ;)
>
> [easily fixed, with one x ]
>
> =A0 =A0 =A0 rotary_event <=3D (rotary_q1 xor delay_rotary_q1) xor (rotary_=
q2
> xor delay_rotary_q2); =A0 =A0 =A0 =A0 =A0
>
> > resolves a
> > single quadrant, but has a one-quadrant hysteresis.
>
> That is a separate 2 bit state-filter, which can be added to any Quad
> Encoder system.
> As such, it is a useful option for manual systems, but I would
> call it sub-optimal for a control system
>
> > It also happens to be very simple, and has no analog components.
> > Who offers something better, i.e. without the hysteresis, but with the
> > same reliability?
>
> If a system catches a runt pulse LOW it must capture a following HI
> and so do the correct +/-1. Provided a system can accept adjacent
> Inc/dec commands, it will not get lost.
> A good test should verify that.
>
> -jg

Is there a way to get away from "if" and "provided".
I am looking for a watertight solution, no ifs or buts...
Assumption:
Horrible undefined contact bounce, but only on one of the two inputs
at any one time.
Keep track of rotational angle with one-quadrant resolution, never an
accumulated error.
Avoid the hysteresis of my suggested solution
Peter

Article: 132047
Subject: Re: Problem writing quadrature decoder
From: Frank Buss <fb@frank-buss.de>
Date: Sun, 11 May 2008 23:10:51 +0200
Links: << >>  << T >>  << A >>
Peter Alfke wrote:

> Assumption:
> Horrible undefined contact bounce, but only on one of the two inputs
> at any one time.
> Keep track of rotational angle with one-quadrant resolution, never an
> accumulated error.
> Avoid the hysteresis of my suggested solution

I think this is impossible without some "if"s. If the contact bounces, you
have to add some holdoff, which doesn't work for fast movements. If you
have one-quadrant resolution without debouncing or hysteresis, the angle
output flickers one position for each bounce, which may be a problem for
the next stage.

But maybe I'm wrong. Sounds like you have already a better solution in mind
:-)

-- 
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de

Article: 132048
Subject: RLC package parasitics
From: kislo <kislo02@student.sdu.dk>
Date: Sun, 11 May 2008 16:39:18 -0700 (PDT)
Links: << >>  << T >>  << A >>
In the IBIS model i can find the package parasitics R_pkg, L_pkg and
C_pkg ... but what does these values represent? is it the total
parasitics of the entire pins of the package? is it for single pins of
the package?

Article: 132049
Subject: Re: Problem writing quadrature decoder
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Mon, 12 May 2008 11:46:42 +1200
Links: << >>  << T >>  << A >>
Peter Alfke wrote:
>>>It also happens to be very simple, and has no analog components.
>>>Who offers something better, i.e. without the hysteresis, but with the
>>>same reliability?
>>
>>If a system catches a runt pulse LOW it must capture a following HI
>>and so do the correct +/-1. Provided a system can accept adjacent
>>Inc/dec commands, it will not get lost.
>>A good test should verify that.
>>
>>-jg
> 
> 
> Is there a way to get away from "if" and "provided".
> I am looking for a watertight solution, no ifs or buts...

The 'if' was only to explain that a runt pulse cannot 'sneak past',
as a low spike must settle high. The system IS clock sampled.

The 'provided' is a simple design condition, and I have not seen
a design that does NOT accept adjacent Inc/Dec, but I am sure
one could be designed (!), so that is why I stated it as a test.
I do not think any of the designs offered have problems here, but
it is a boundary condition, that should be verified by test.

> Assumption:
> Horrible undefined contact bounce, but only on one of the two inputs
> at any one time.
> Keep track of rotational angle with one-quadrant resolution, never an
> accumulated error.

Yes, a system can do that. The real question is if you WANT the +/-1
on adjacent clocks, (@same apparent physical position) or not ?.

An operator would probably answer NO, and machine control system, would
answer yes, remove the backlash.


> Avoid the hysteresis of my suggested solution

but that separate 2 register hyst. block might be a positive addition :)

If you are serious about accumulated errors, then you should NOT
count on the illegal states.

In a new system, my preference would be to catch, and flag those illegal 
states, as they indicate an out-or-range condition (or a sensor problem)
It allows you to lower the clock, as far as practical, for power savings.

The optimal Encoder uses the smallest number of registers/cells, and you 
can design one where the state-follower forms 2 LSBs of the counter.
This also has the lowest latency.


-jg







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