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
<rjs@friend.ly.net> wrote in message news:1104607525.385297.51090@z14g2000cwz.googlegroups.com... > Hello, > > I have a need for something faster than a microcontroller and decided > on using logic IC's to do it. Well I don't need to say why I next > decided to use programable logic instead. I've have never used a PLD > before. After visting Xilinx web site I ordered the CPLD Design Kit to > get started. > > Lets see know, all I have to do is program my logic schematic into one > of these CPLD devices! Wow, after that I might find the state machine > entry of intrest. And... after I'm an advanced user I could learn a new > language called VHDL. Now wait a minute... How come the Xilinx tutorial > starts with the advanced VHDL first? OK, I'll skip over to the next > tutorial "State Machines". Well, I don't need that yet. OK, the next > tutorial uses schematic entry. Oh no, this tutorial requires the > previous tutorials. It seems to me that Xilinx has it all backwards on > how one starts using programable logic for the first time. > > Next I bought a book on ebay "Digital Electronics - Using the Xilinx > XC95108 CPLD" copyright 2001. This is perfect!! Its first CPLD example > uses a 3 input AND gate and a 3 input OR gate. The problem is that it > uses Xilinx foundation 1.5 which is nothing like ISE 6.3i that I have. > So my question is where can I get Xilinx foundation 1.5 ??? Don't bother, get the latest WebPack. I've got an introduction to using Xilinx CPLDs on my web site: http://www.geocities.com/leon_heller/pld_starter.html with a simple design that uses WebPack. LeonArticle: 77251
I have just started to work with VHDL and Altium Protel/Nexar software. Because of problems with VHDL files hierarchy and licensing system (clock changes deactivates evaluation license) i want to move to Altera Quartus II v.4.2 but I don't know how to build and load my designs into FPGA. If someone have a simple project (for ex. AND gate :) ) for that board please send it to me. I just need instruction how to set parameters for that board. TIA.Article: 77252
Nick, I have seen startup issues with state machines as well. Using synch state machines and asynch resets. Using Quartus 4 spX. A couple thoughts from what I read on Altera's website and just trying stuff. Make sure your state machine is using one-hot encoding, and define all states. This may solve random startup issue. If not try using a 3rd party tool like leonardo. (I think this ultimately fixed our issue. - RichArticle: 77253
Is it possible to implement a "pause" function for a counter using a DIP switch? i.e. where it counts, you press the DIP switch it stops counting holding the current value until you press the DIP switch again in which it counts again starting from its stopped value? Right now, the DIP switch is used as a "reset" zeroing out the counter...you press it, the counter immediately goes to 00 and once you release it starts counting...01,02, etc. I have tried all the obvious things, but I am wondering if this is even possible at all with a DIP switch and I am wasting my time...with a DIP switch, you only have a "known" state when it is pressed...when not pressed it is an open circuit, right? It seems like I would need a switch that is tied to ground when open, right? Or am I missing something? FYI, this a board with an FPGA, LCD and DIP Switch. Thanks for any help you can offer.Article: 77254
Yes, it is possible. However, since this sounds suspiciously like a homework problem, I'll be a little vague about how to solve it. When you push the dip switch, it toggles between two states, counter running/counter paused. How do you implement that? Next, you need to take the paused/running signal and use it to control whether the counter is running or not. How do you do that? When you have solved those two problems, you will have your circuit. Hope this helps, -Chris ***************************************************************************** Chris Clark Internet : compres@world.std.com Compiler Resources, Inc. Web Site : http://world.std.com/~compres 23 Bailey Rd voice : (508) 435-5016 Berlin, MA 01503 USA fax : (978) 838-0263 (24 hours) ------------------------------------------------------------------------------Article: 77255
>I have seen startup issues with state machines as well. >Using synch state machines and asynch resets. Using >Quartus 4 spX. A couple thoughts from what I read on Altera's >website and just trying stuff. Make sure your state >machine is using one-hot encoding, and define >all states. This may solve random startup issue. If >not try using a 3rd party tool like leonardo. (I think >this ultimately fixed our issue. Async resets are evil. They are, well, asynchronous. Using a one-hot state machine doesn't solve the problem. It might reduce the probability (size of window), maybe even enough so you won't see it easily. Are you running a few lab tests or do you need a solid system? This gets discussed here frequently. The usual context is the global reset signal that the hardware provides. It's slow enough so that even if it is synchronous at the pins, it's probably several clocks of prop time on high speed systems. (and hence logically asynchronous) The usual advice is to make your own local synchronous reset signal that is derived from the global reset signal and use that to reset a state machine (or a clump of local logic). You can also design your system so that an async reset will be good enough. The trick is to make sure that any signal that will cause a state change (out of the reset state) doesn't happen until a while after the reset goes away. (That "a while" has to cover the skew in the reset signal.) Even if you had a fast global reset signal, it won't solve the problem if you have more than one clock. -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.Article: 77256
On Sat, 01 Jan 2005 20:03:24 -0600, hmurray@suespammers.org (Hal Murray) wrote: >>I have seen startup issues with state machines as well. >>Using synch state machines and asynch resets. Using >>Quartus 4 spX. A couple thoughts from what I read on Altera's >>website and just trying stuff. Make sure your state >>machine is using one-hot encoding, and define >>all states. This may solve random startup issue. If >>not try using a 3rd party tool like leonardo. (I think >>this ultimately fixed our issue. > >Async resets are evil. They are, well, asynchronous. Using >a one-hot state machine doesn't solve the problem. It might >reduce the probability (size of window), maybe even enough so >you won't see it easily. Are you running a few lab tests or >do you need a solid system? > >This gets discussed here frequently. The usual context is >the global reset signal that the hardware provides. It's slow >enough so that even if it is synchronous at the pins, it's probably >several clocks of prop time on high speed systems. (and hence >logically asynchronous) Well, basically for my test I use a switch for the reset, if it's at 1 the state machine should start, if it's at 0 the state machine should reset. I would really like to have a fairly long reset that I can control for my tests. And my clock is only 32 MHz As long as the design isn't too big it works. And after a certain amount of complexity it doesn't anymore Thank you for your answer, I shall try using Leonardo, and i'll keep you informed. Happy new year to you all NickArticle: 77257
>Async resets are evil. They are, well, asynchronous. Using >a one-hot state machine doesn't solve the problem. It might >reduce the probability (size of window), maybe even enough so >you won't see it easily. Are you running a few lab tests or >do you need a solid system? By the way, the Wishcode interconnection system http://www.opencores.org/projects.cgi/web/wishbone/wishbone requires an async reset, unless I get it completly wrong. I try to stick to this specification to get adaptable and easy to use modules NickArticle: 77258
avrbasic wrote: > Hi all, > > I have decided to make some presents to all in form of IP-Core donations: > http://www.opencores.org/projects.cgi/web/mmcfpgaconfig > > There is working/tested IP-Core that allows FPGA configuration from MMC > Card. The IP as submitted to opencores does not support SD-Cards, but is > otherwise tested and useable. Tested with MMC, XC9536XL as config controller > and VP20 as target tot be configured. > Adding of SD-card support in the SPI mode should not be so difficult. Aren't the SD-cards able to work in the MMC-compatible mode? It seems to me that I have at least one device which works with SD cards using the SPI interface. Unfortunately I had no time to connect it to the logic state analyser to compare the waveforms with MMC card and with SD card (I hope to do it in reasonable future though ;-) ). Thanks a lot for nice core, Regards, Wojtek ZabolotnyArticle: 77259
To anybody that has contributed to my thread, Thank You. The replies have been very informal. When I ordered the board they told me that they were out of stock and I would probably would receive it until the middle of January. I planned on using the web and evaluation versions of the software. New Years Eve Day, Fed Ex arrived with a box. I'm very happy it, DerekArticle: 77260
Sorry for replying my own post, but I've found some pointers, which should allow adding the SD support even without using logic state analyzer ;-) I've found a very nice post: http://groups.google.pl/groups?selm=21uqr0tefpp6a5dslrvpf5paqjkr9c0ql9%404ax.com which gives some pointers to useful docs. Particularly the http://i.cmpnet.com/chipcenter/memory/images/prod055.pdf provides some info regarding the initialization the SD card in the MMC compatible mode (thanks a lot Toshiba!!!). Regards, Wojtek ZabolotnyArticle: 77261
First of all, this isn't a HW problem...I have been out of school a few years... I am trying to bridge the gap between the simulated world that academia covers well and the actual real world HW that academia does a poor job at covering, imo. Anyway....Like I mentioned in my first post, I have done all the obvious things to no avail...it simulates as expected, but once in hardware, it doesn't, which makes me think it is something with the DIP switch. I can cut and paste the necessary code if you are willing to help....Article: 77262
avrbasic wrote: > Hi all, > > I have decided to make some presents to all in form of IP-Core > donations: http://www.opencores.org/projects.cgi/web/mmcfpgaconfig > > There is working/tested IP-Core that allows FPGA configuration from > MMC Card. The IP as submitted to opencores does not support SD-Cards, > but is otherwise tested and useable. Tested with MMC, XC9536XL as > config controller and VP20 as target tot be configured. > > Similar IP-Core (SD/MMC config IP-core for Altera) from an commercial > vendor costs around 1900EUR ! > > Antti I just designed the same thing a couple of weeks ago, but to read from an Atmel DataFlash card. I didn't feel like messing with the MMC/SD commands. The Atmel cards use the MMC form factor and SPI interface but don't require the MMC commands. But now that you've done the work I may fold in MMC support. Thanks for contributing the code, Antti. RobArticle: 77263
Hi Nick,
The timing analyzer in Quartus II 4.2 has the ability to perform
Recovery and Removal Analysis. Here is the excerpt on the definition of the
Recovery/Removal analysis from the Online Help:
"Reports the results of setup checks for paths that have an asynchronous
clear, preset, or load signal. This report could alert you to a condition in
which an active clock
edge occurs too soon after the asynchronous input goes inactive, thus
rendering the data uncertain. When you turn on the Enable Recovery/Removal
analysis option,
the Timing Analyzer determines the minimum amount of time required between
an asynchronous control signal going inactive and the next active clock
edge, compares this
to your design, and reports the results as slack following timing analysis."
To turn on the Enable Recovery/Removal analysis option, use the Assignments
(Menu)->Timing Settings->More Settings->Enable Clock Recovery/Removal
Analysis and turn it on.
Hope this helps.
- Subroto Datta
Altera Corp.
"Nick" <char-DONTBUGME-les@YY.iiedotcnam.france> wrote in message
news:7vh8t0p2gkjg44904vfo6hppufeeu7t227@4ax.com...
> Hello,
>
> Well, the title might not be very exact. I have programmed big states
> machines in VHDL with quartus 4.1sp2. They all have an asynchronous
> reset, and i have leds to see what's going on for debug purpose. When
> i'm in the reset state, i must have a pattern on my leds.
>
> BUT, the bigger my state machine got, the stranger the behaviour. If I
> remove some access to the leds later in my state machine (not in the
> reset, but in a true state), all my leds are off during my reset, or
> sometimes only some are off, given the operation I add or remove IN
> COMPLETLY OTHER STATES, or even in others modules.
>
> I have really no idea of what is going on. My design is not yet very
> big (900 LE) and there are no really speed constraint on it.
>
>
> Could someone please explain me what I can do so wrong ?
>
>
> Best regards, and happy new year
>
> Nick
Article: 77264Have you tried using the DIP switch as an enable signal instead of a reset signal? I'm interesetd in reading the code if you would like to post it.Article: 77265
I apologize for suggesting it might be a homework problem. It's actually not school time and so the suggestion was unwarranted. (I might have missed your first post also (or atleast not connected it).) If it is a mismatch between simulation and physical implementation, perhaps there is something in the physical implementation your model doesn't account for. For example, perhaps the dip switch "Bounces". What you are trying to build, where the switch acts as a toggle would be susceptible to that. Using the dip as a reset wouldn't have the same tempermentalness, as if one sees two (or more) rests in a row, one isn't going to "notice", since in the end the signal still gets reset. Tow toggles in a row are a different story. If you could tie an indicator (e.g. an led) to the "state" part of the design, so that the led would indicate which state the toggle is in, you might see that it doesn't actually toggle (or toggles more than once per push). Of course, if the problem is too quick, it might go by to quick for you to see it. Assuming that bounce is the problem, you could then ask how to de-bounce your circuit (i.e. make it less sensitive to bounce). I don't know what solutions are available there, but one possibility is to make the circuit insensitive to a 2nd button push until a specific amount of time (say a specific number of clock cycles) after the first. Iamgine how you would change your circuit model so that the dip button could only cause one change of the toggle per cycle. Implement that and see if it effects your problem. If bounce is the problem, whether that change will help depends on how fast your cycle is relatively to how fast bounces settle. If bounce isn't the problem, you need to keep looking until you can find out what is. You're right about the differences between unrealistic "academic" models and the real-world implementation. Verilog models are a simplification of the real world and do not model it completely faithfully. There are things which can happen in the real world that your model is likely to miss and vice-versa: sometimes the model can have artifacts that can never heppen in the real world. Hope this helps, -Chris ***************************************************************************** Chris Clark Internet : compres@world.std.com Compiler Resources, Inc. Web Site : http://world.std.com/~compres 23 Bailey Rd voice : (508) 435-5016 Berlin, MA 01503 USA fax : (978) 838-0263 (24 hours) ------------------------------------------------------------------------------Article: 77266
Yes, post your code if you want help.
Maybe the switch is not debounced.
See:
http://groups-beta.google.com/groups?q=fpga+debounce+switch
-- Mike Treseler
Article: 77267G wrote: > Is it possible to implement a "pause" function for a counter using a > DIP switch? i.e. where it counts, you press the DIP switch it stops > counting holding the current value until you press the DIP switch again > in which it counts again starting from its stopped value? > You want to use the DIP switch to toggle a Count Enable flip-flop. This would be trivial if there were no contact bounce. In reality, the toggling flip-flop is about a million times faster than the contact bounce activity, so you must somehow make sure that the whole bounce sequence ( lasting 100 ms?) is seen as only one clock input to the control flip-flop. With a two-pole switch this is trivial, but with only one pole, you have to introduce a delay that masks the bounce. A clean digital solution uses an extra multibit resettable "dead-ended" counter that stops counting when its MSB is a 1. Needs a reasonably slow clock to make it longer than 100 ms. Depressing the DIP switch resets the whole counter, and keeps it reset as long as you hold the DIP switch down. Use the MSB going 1-to-0 as the clock for your toggling count enable signal. There are many variations on this theme, but none is trivial. There are neat tricks you can play with R and C, but that gets you an outcry of contempt from the digital design community... Peter AlfkeArticle: 77268
DerekSimmons@FrontierNet.net wrote: > To anybody that has contributed to my thread, Thank You. The replies > have been very informal. <<SNIP>> Can we assume that you meant 'informative'?Article: 77269
Peter Alfke wrote: > G wrote: > >>Is it possible to implement a "pause" function for a counter using a >>DIP switch? i.e. where it counts, you press the DIP switch it stops >>counting holding the current value until you press the DIP switch > > again > >>in which it counts again starting from its stopped value? >> > > You want to use the DIP switch to toggle a Count Enable flip-flop. This > would be trivial if there were no contact bounce. In reality, the > toggling flip-flop is about a million times faster than the contact > bounce activity, so you must somehow make sure that the whole bounce > sequence ( lasting 100 ms?) is seen as only one clock input to the > control flip-flop. <<SNIP>> I'm possibly missing something here, but seems to me that it really doesn't matter whether the switch bounces or not. If the switch is changing from "count" to "don't count" at the time the counter is trying to figure out whether to count or not, the worst that can happen is that it will make an extra count or maybe a few. Assume the switch debounces in 100 ms, and during the 100 ms it's in the wrong state for 50% of the time. If the counter is counting at 1 Hz, then there's a 5% chance that it will make one extra count. If you're counting faster than 10 Hz, then you'll probably never know if there are one or two extra counts that happen while the switch is debouncing. If you're interested in switch bounce time, Jack Ganssle did a column about it a few months ago, in Embedded Systems Magazine. He went out and bought about 20 switches and measured debounce time using an oscilloscope. I don't remember the results, but it's still an interesting read. Here's a link to the article: http://www.embedded.com//showArticle.jhtml?articleID=18400810Article: 77270
The original posting asked for a design where the first depression of the DIP stops the counter, the second depression starts it again, like an old-fashioned lamp next to your bed. "where it counts, you press the DIP switch it stops counting holding the current value until you press the DIP switch again in which it counts again starting from its stopped value" That toggle action is the problem, and it needs switch debouncing. Peter Alfke, on a rainy California Sunday afternoon...Article: 77271
Peter Alfke wrote: > The original posting asked for a design where the first depression of > the DIP stops the counter, the second depression starts it again, like > an old-fashioned lamp next to your bed. > > "where it counts, you press the DIP switch it stops > counting holding the current value until you press the DIP switch again > in which it counts again starting from its stopped value" > > That toggle action is the problem, and it needs switch debouncing. > Peter Alfke, on a rainy California Sunday afternoon... > OOPS... Well, Jack Ganssle has some good ideas about debouncing as well. Al, on a cold, freezing rain, New England Sunday evening...Article: 77272
"div_16M.v" generates a count that enables both "cnt_10.v" and subsequently "cnt_10_tens.v" when its(div_16M.v) count reaches all 1s. To do the pause/start/stop function, I moved the "clr" function out of the two counter modules and into a module "cnt_pause.v" to enable/disable the master counter enabler "div_16M.v"...this makes the most sense(I thought) Initially, "clr" was used to reset the counter to zero...this was tied to the DIP switch on the PCB.(this code is commented out) This is my last shot at what I thought was "trivial"...I have changed it around a lot, but settled on this approach...I feel it is close, but I have begun to think otherwise...Please excuse the messiness and somewhat disarray. // module: counter.v // This is the top level module that ties all sub-modules together module counter(clk,reset,lcd_com,one_dp,ten_dp,one_out,ten_out); input clk; input reset; output lcd_com; output one_dp; output ten_dp; output [6:0] one_out; output [6:0] ten_out; wire nreset; wire pause; wire lcd_clk; wire tc; wire ce_tens; wire [23:0] ce_1s; wire [3:0] cnt_1s; wire [3:0] cnt_10s; wire [6:0] lcd1_out; wire [6:0] lcd10_out; cnt_pause PAUSE( .clk(clk), .clr(nreset), .start_stop(pause) ); div_500K DIV_500K( .clk(clk), .clk_60(lcd_clk) ); div_16M DIV_16M( .clk(clk), .start_stop(pause), .enable(ce_1s) ); cnt_10 ONES( .clk(clk), //.clr(nreset), .enable(ce_1s), .tc(tc), .qout(cnt_1s) ); cnt_10_tens TENS( .clk(clk), //.clr(nreset), .ce_tens(ce_tens), .qout_tens(cnt_10s) ); hex2lcd ONES_LCD( .hex(cnt_1s), .lcd(lcd1_out) ); hex2lcd TENS_LCD( .hex(cnt_10s), .lcd(lcd10_out) ); lcd_mux ONES_MUX( .clk(clk), .cnt(lcd_clk), .data_in(lcd1_out), .lcd_seg(one_out), .lcd_com(lcd_com), .lcd_dp(one_dp) ); lcd_mux TENS_MUX( .clk(clk), .cnt(lcd_clk), .data_in(lcd10_out), .lcd_seg(ten_out), .lcd_com(), .lcd_dp(ten_dp) ); assign nreset = ~reset; assign ce_tens = tc & (ce_1s == 24'hFFFFFF); endmodule // module: cnt_pause.v // This module ties the DIP switch function to counter enable.Pauses the //counter. // Continues counting toggled by user DIP and at last count value. module cnt_pause(clk,clr,start_stop); input clk; input clr; output start_stop; reg pause = 0; always @ (posedge clk) begin if (clr) pause <= 1; //Pauses counter at present count value else if (clr && pause == 1) //Resumes counting at pause state and upon //user DIP input pause <= 0; end assign start_stop = pause; endmodule // module: div_16M.v // This module divides the incoming 30 MHz clock by 2^24 and is used to enable //the counter. module div_16M(clk,start_stop,enable); input clk; input start_stop; output [23:0] enable; reg [23:0] count = 0; //Current count value reg start_stop = 0; //pause function always @ (posedge clk) begin if (start_stop == 1) //Pause count else if (start_stop == 0) //Count or resume counting from pause state count <= count + 1; end assign enable = count; endmodule // Module: cnt_10.v // This module counts from 0 to 15 and then rolls over. Ones Digit. module cnt_10(clk,enable,tc,qout); input clk; //input clr; input [23:0] enable; //enables the counter to count at slower clockrate output tc; output [3:0] qout; reg [3:0] count = 0; //Current count value always @(posedge clk) begin //if (clr) //asynchronous RESET active High //count <= 4'b0; //else if (enable == 24'hFFFFFF) //count <= count + 1; if (enable == 24'hFFFFFF) count <= count + 1; end assign qout = count; assign tc = (count == 4'hF); //Terminal count flag for ones digit/tens counter enable endmodule // Module: cnt_10_tens.v // This module counts from 0 to 15 and then rolls over. Tens Digit. module cnt_10_tens(clk,ce_tens,qout_tens); input clk; //input clr; input ce_tens; output [3:0] qout_tens; reg [3:0] count = 0; //Current count value always @(posedge clk) begin //if (clr) //asynchronous RESET active High //count <= 4'b0; //else if (ce_tens == 1) //count <= count + 1; if (ce_tens == 1) count <= count + 1; end assign qout_tens = count; endmoduleArticle: 77273
I realize that this might not be appropriate question for this group, but considering the level of knowledge I thought I would see if anyone knows much about recovering lost verilog code from a .sof altera Quartus FPGA binary? Some of the my companies IP cores source has disappeared and thought maybe someone here could help me out at recovering the missing source. Does anyone know of any altera dissassembler or decompiler for the SOF file? I'm not particularly concerned if the the output is VHDL, verilog, or even AHDL. Because of the ethics of reverse engineering I would be willing to present anyone with the evidence they might need to verify that my company has all copyrights and ownership of the .sof Im asking to derive the source code. Any thoughts how I can do this? Mark S.Article: 77274
Hi I wish you all a very happy and prosperous new year-2005. I need one help from you regarding quadrature encoder. we are using linear optical incremental encoder (HEDS-9200 Q00) which gives 180 pulses/inch in my project. i am implementing the the decoder/counter in my existing ACTEL FPGA along with some other functinality. can you please suggest me what should be the suggested minimim/maximum clock freuency required to do so? regards, S.RANGA REDDY Ray Andraka wrote: > You might do this as a single process. It would also be easier if you made this synchronous. You need a > storage element to resolve the direction, which you have done with a pair of counters. The direction > cannot be determined just by the current inputs, you need to know what they were before the latest change > too. Normally a quadrature resolver uses a decoder circuit that then drives a single up-down counter. > The following code should give you the idea. I've shortened angle_ch_A to ain and same with b to save my > fingers. I just typed the code here, so I make no guarantees that it'll compile without error. ain, > bin, index are the inputs from the encoder. > > > process(clk) > variable dir: std_logic_vector(1 downto 0)="00"; > variable aold,bold: std_logic; > begin > if index = '1' then > angle<= (others=> '0'); > else > if clk'event and clk='1' then > dir := (ain xor aold) & (bin xor bold); > aold:=ain; > bold:=bin; > case dir is > when "00" => --no change > moved <= 0; --leave cw output alone > when "01" => -- clockwise rotation > angle <= angle +1; > moved <= 1; > cw <= 1; > when "10" => --ccw rotation > angle <= angle - 1; > moved <= 1; > cw <= 0; > when "11" => -- this is an error condition...either a bad sensor or rotation is faster than > clock > end case; > end if; > end if; > end process; > > > > > Asher C. Martin wrote: > > > Greetings, > > > > My name is Asher and I am working on some VHDL code to control an > > optical encoder (HEDS-9100) that will measure the angle that a device > > has rotated. > > > > Anyhow, I wanted to know how to drive a signal with multiple sources in > > VHDL. Here are some technical details. I have two different processes > > one called "grab_ch_A_data: PROCESS (angle_ch_A)" that triggers on the > > EVENT that angle_ch_A changes and the other "grab_ch_B_data: PROCESS > > (angle_ch_B)" triggers on the event that angle_ch_B changes. > > > > Inside the first process I am keeping track of whether or not the device > > is rotating clockwise or counter clockwise. KEY POINT: I have this > > variable called "clockwise" in both processes and they both should be > > able to set "clockwise" to the direction of rotation. The direction > > depends on the current state of the input signals. > > > > Could someone please help me out? I would really appreciate it. > > > > (SEE ATTACHED CODE) > > > > Best regards, > > > > >Asher< > > > > <<=>>=<<=>>=<<=>><<=>>=<<=>>=<<=>> > > Asher C. Martin > > 805 West Oregon Street > > Urbana, IL 61801-3825 > > (217) 367-3877 > > E-MAIL: martin2@acm.uiuc.edu > > http://fermi.isdn.uiuc.edu > > telnet://fermi.isdn.uiuc.edu > > ftp://feynman.isdn.uiuc.edu > > <<=>>=<<=>>=<<=>><<=>>=<<=>>=<<=>> > > > > ------------------------------------------------------------------------ > > -- Asher C. Martin > > -- Robotics and Computer Vision Lab > > > > LIBRARY ieee; > > USE ieee.std_logic_1164.all; > > USE ieee.std_logic_arith.all; > > > > ENTITY angle IS > > > > PORT > > ( > > angle_ch_A : IN STD_LOGIC; -- CHANNEL A FROM OPTICAL ENCODER > > angle_ch_B : IN STD_LOGIC; -- CHANNEL B FROM OPTICAL ENCODER > > angle_ch_I : IN STD_LOGIC; -- CHANNEL I (HIGH WHEN 360 DEG.) > > reset_switch : IN STD_LOGIC; -- IF ANGLE GETS OFFSET THEN RESET THIS LINE > > output_a : OUT INTEGER RANGE 0 TO 255; --STD_LOGIC_VECTOR(7 downto 0) > > output_b : OUT INTEGER RANGE 0 TO 255; --STD_LOGIC_VECTOR(7 downto 0) > > clockwise : INOUT STD_LOGIC > > ); > > > > END angle; > > > > ARCHITECTURE angle_architecture OF angle IS > > > > SIGNAL a_counter : INTEGER RANGE 0 TO 255; > > SIGNAL b_counter : INTEGER RANGE 0 TO 255; > > > > BEGIN > > > > -- THE FOLLOWING FIGURES OUT IF THE USER IS MOVING LEFT OR RIGHT > > --direction: PROCESS () > > -- BEGIN > > > > --END PROCESS direction; > > > > -- THE FOLLOWING CODE EVALUATES WHAT IS HAPPENING TO CHANNEL A > > grab_ch_A_data: PROCESS (angle_ch_A) > > BEGIN > > > > IF reset_switch = '0' THEN -- FOR TESTING WITH THE PB_1 MAKE THIS ZERO FOR RESET > > > > a_counter <= 0; > > > > ELSIF (angle_ch_A'EVENT AND angle_ch_A = '1') THEN > > > > a_counter <= a_counter + 1; > > > > ELSE > > > > a_counter <= a_counter; > > > > END IF; > > > > -- THE FOLLOWING FIGURES IF THE DIRECTION IS CLOCKWISE OR COUNTER CLOCKWISE > > IF (angle_ch_A = '1' AND angle_ch_B = '0') THEN > > > > clockwise <= '1'; > > > > ELSE > > > > clockwise <= clockwise; > > > > END IF; > > > > END PROCESS grab_ch_A_data; > > > > -- THE FOLLOWING CODE EVALUATES WHAT IS HAPPENING TO CHANNEL A > > grab_ch_B_data: PROCESS (angle_ch_B) > > BEGIN > > > > IF reset_switch = '0' THEN -- W/ B_1 MAKE '0' OTHERWISE KEEP '1' > > > > b_counter <= 0; > > > > ELSIF (angle_ch_B'EVENT AND angle_ch_B = '1') THEN > > > > b_counter <= b_counter + 1; > > > > ELSE > > > > b_counter <= b_counter; > > > > END IF; > > > > -- THE FOLLOWING FIGURES IF THE DIRECTION IS CLOCKWISE OR COUNTER CLOCKWISE > > IF (angle_ch_A = '0' AND angle_ch_B = '1') THEN > > > > clockwise <= '0'; > > > > ELSE > > > > clockwise <= clockwise; > > > > END IF; > > > > END PROCESS grab_ch_B_data; > > > > -- THE CURRENT ANGLE IS NOW LOCATED AT "ANGLE_OUTPUT" > > output_a <= a_counter; > > output_b <= b_counter; > > > > END angle_architecture; > > > > -- > -Ray Andraka, P.E. > President, the Andraka Consulting Group, Inc. > 401/884-7930 Fax 401/884-7950 > email randraka@ids.net > http://users.ids.net/~randraka
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