Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
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
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
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, VittalArticle: 132027
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
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
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
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.comArticle: 132031
"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 JenningsArticle: 132032
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: 132033Correction to previous post. I'd suspect 'x' to be ~25-40, not 50-75. KJArticle: 132034
"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, MartyArticle: 132035
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 VelocityArticle: 132036
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 WArticle: 132037
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 AlfkeArticle: 132038
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_HArticle: 132039
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 ? -jgArticle: 132040
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
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.comArticle: 132042
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. - BrianArticle: 132043
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: 132044On 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 AlfkeArticle: 132045
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: 132046On 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 PeterArticle: 132047
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.deArticle: 132048
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
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:
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