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
Looks like a pretty good site. Fred rajesh52@hotmail.com wrote in message <75spi2$187$1@nnrp1.dejanews.com>... >Greetings > >Version 8 of Verilog FAQ is ready and is moving to permanent place. > >URL for Verilog FAQ is > >http://www.angelfire.com/in/verilogfaq/index.html > >Please feel free to send it to others. Update links if you have above >URLs on your webpages. Please subscribe from FAQ page to receive >automatic update notices in future. > >Following addition/changes are present in version 8. > >New Items >- List of two free verilog tutorials added. >- List of Verilog / EDA related conferences added. >- FSM Design and Analysis tools section added. Links to Cisco FSM and > FSMDesigner added. > >Updated items - FAQ page moved to Angelfire site. HTML is cleaned up. - >Information on SMASH mixed signal simulator added. - Information on J. >Bhasker's "Verilog HDL Synthesis, A Practical Primer" added in list of >books. - Qualis quick reference card added in the list of free cards. - Links >for Analog Verilog and PLI updated. > > >Verilog Page is also updated and moved to permanent place. URL is >Verilog Page: http://www.angelfire.com/in/rajesh52/verilog.html > > >Thanks >Rajesh Bawankule (rajesh52@hotmail.com) > >-----------== Posted via Deja News, The Discussion Network ==---------- >http://www.dejanews.com/ Search, Read, Discuss, or Start Your OwnArticle: 13776
Hi, Can anyone help me to solve this problems? I start to use xilinx and VHDL now, but my xilinx foundation basic software donot support VHDL synthesis, what a pity. Now I am thinking of using mentor leonardo to synthesis it, and function simulate it, and then generate EDIF file. Export it to xilinx foundation, and then do programming and timing verify. But, how to do timing verify just with a EDIF file? And, can I do the whole thing with mentor? with timing simulation and back annotation? Thank you very much!Article: 13777
I am using Aldec Active-VHDL 3.2 and Foundation M1.4 (haven't upgraded yet). I need to know how to add xilinx libraries to Active-VHDL so I will be able to instanciate and simulate components such as TBUFs, IBUFs, BUFGs and so on. Foundation Library file-type isn't compatible to Aldec's. Also I want to be able to export my design from Active-VHDL to Foundation implementation and get it back for timing-simulation into Active-VHDL - I know it's possible and I saw the tutorial in Aldec's Site but it wasn't helpful since it referenced me to non-existant files. Thanks. Yours, -- Ido Kleinman. kleinn@REMOVETHIS.mail.biu.ac.il ** Please delete the "REMOVETHIS." substring to EMail me.Article: 13778
What are the some of the smallest (in number of adds/mults) 8-point DCT algorithms? I am specifically interested in "multiplication-free" implementations, which only use shifts (multiplies by powers of 2) and adds. Any pointers? Dan Benyamin benyamin@ucla.edu -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your OwnArticle: 13779
benyamin@my-dejanews.com writes: > What are the some of the smallest (in number of adds/mults) 8-point DCT > algorithms? "Smallest" probably is not the right adjective for what you are looking for... "fastest" would be the more commonly used term I should think. Anyway, it is a mathematical fact that you can't do a true 8-point DCT with less than 11 multiplications. The best methods I've seen require about 30 adds to go along with the 11 multiplies. However, this approach ignores a couple of salient facts about JPEG/MPEG applications (which I assume is what you care about, given where you're posting): 1. What you actually want is a 2-D 8x8 DCT. Decomposing this into 8 row and 8 column DCTs, and then trying to do the 1-D DCTs as quickly as possible, is not necessarily the optimal route to a 2-D DCT. There are direct 2-D fast DCTs out there, and they do beat decomposition into 1-D DCTs as far as mult/add count goes. My personal experience is that they have no real advantage in an actual implementation, but that comes from code-size and memory-access-pattern issues that don't show up in the abstraction of operation counts. (But this is a software result; if you're thinking of hardware implementations your mileage may vary.) 2. What you actually want is not a DCT but a quantized DCT. Any multiply that you can push to the DCT-coefficient end of the operation can be eliminated by folding its constant into the coefficient quantization factors that you're going to have to multiply or divide by anyway. If you follow this road you find that you only need 5 or so multiplies per 1-D DCT inside the "DCT box" itself. There are accuracy issues to contend with if you are using fixed-point math, but overall this approach yields the fastest practical DCT algorithms that I know about. > I am specifically interested in "multiplication-free" implementations, > which only use shifts (multiplies by powers of 2) and adds. Well of course any DCT method can be converted into a shift-and-add form, since all the multiplies are by constants: just expand the constants into bit patterns and add up the corresponding shifts of the non-constant operand. I have not heard of any formal study that tried to minimize the number of operations expressed in this form --- it'd be equivalent to counting the one-bits in the selected multiply factors, and among other problems the best answer would be quite dependent on the accuracy with which you expressed the factors. I have heard of one or two people who took an existing DCT algorithm and hacked it in an ad-hoc way by replacing the multiply factors with nearby values that had fewer one-bits. This strikes me as a poorly controlled tradeoff of accuracy for speed ... I'd not try it without some established mathematics to tell me what I was doing ... You can find more info about DCT methods in the comp.compression FAQ at http://www.faqs.org/faqs/compression-faq/ regards, tom lane organizer, Independent JPEG GroupArticle: 13780
Thanks for your excellent post, though I should learn to be more precise in phrasing my questions! In article <uo9u2yjy4mw.fsf@netcom2.netcom.com>, Tom Lane <tgl@netcom.com> wrote: > > I am specifically interested in "multiplication-free" implementations, > > which only use shifts (multiplies by powers of 2) and adds. > > Well of course any DCT method can be converted into a shift-and-add > form, since all the multiplies are by constants: just expand the > constants into bit patterns and add up the corresponding shifts of > the non-constant operand. I have not heard of any formal study that > tried to minimize the number of operations expressed in this form --- > it'd be equivalent to counting the one-bits in the selected multiply > factors, and among other problems the best answer would be quite > dependent on the accuracy with which you expressed the factors. This is exactly what I am trying to do, though working on the DCT is really not my main goal. I am looking at some ways of eliminating the common-subexpressions dictated by the bit patterns in the coefficients. I agree that finding "nice" numbers "near" the original cosine values is probably not the greatest approach. I am simply taking the floating point DCT coefficients, truncating them at some precision, and feeding the numbers into a minimization algorithm. Some early results are 197 adds for 10-bit DCT coefficients (8-point xform, or a 1-D DCT), though this can be cut down closer to 100 with canonical signed digits. I wanted to get an idea of the state of the art, but it seems not too many people are taking this approach. Any thoughts? Dan benyamin@ucla.edu -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your OwnArticle: 13781
I don't know if it is any less expensive, but check out http://www.macrocad.com . I'll vouch for this one, as I was part of the two man team that developed it (prior to joining Actel, I really was a designer at one point). You probably could develop your own for less, but then why look at IP in the first place, sorta defeats the purpose. I know I would'nt do it again for anything less than $15K. The MacroCad version does not infringe on National's patents, won't/can't speak for Cast's version. Daniel K. Elftmann Actel New England Field Applications Engineer dan.elftmann@actel.com Victor the Cleaner wrote in message <75nal9$5gl$1@cleavage.canuck.com>... >Does anyone but CAST supply a 16550 core? They've just quoted $15K for >the VHDL source or $7500 for a Xilinx netlist. In either case, that's >too much for this application. Can it be found elsewhere? > >thx. > >Jonathan >Article: 13782
"Sergio A. Cuenca Asensi" wrote: > Thank you for your comments. > I think, I have found the cause of the ERROR, . > The problem is with the optimization process of FPGAExpress. In architecture > arch2 I have used all bits of data in order to asign the output rgb, but > really data(1) and data(0) are not necesary to generate rgb bits. > I could have wrote: > > case data(3 downto 2) is > when "00" => rgb <= "000000";-- negro > when "01" => rgb <= "010101";-- gris1 > when "10" => rgb <= "101010";-- gris2 > when "11" => rgb <= "111111";-- blanco > when others => rgb <= "110000"; -- rojo > end case; > > So I think that in the optimization process data(1), data(0), data(4) and > data(5) are eliminated because no logic is generated by them. > The conclusion is that data is transformed in a 2-bit vector instead of a > 6-bit vector, but in the symbol generated from the .xnf file appear > data(5..0) and I donīt notice the change. > To confirm this I modify the arch2 adding a simple asignation. Actually, all six output bits are no logic bits. rgb bits 0, 2 and 4 match bit 2 of data and bits 1, 3 and 5 of rgb match data bit 3. So there is NO logic generated for any of these outputs. But that doesn't mean the OUTPUTS are eliminated. It just means that the logic is reduced to a buffer which is likely eliminated by the back end tools. Then the sets of signals all become the same wire. > architecture arch21_rgbcore of rgbcore is > begin > process(clock,reset) > begin > if reset='1' then > rgb <= "000000"; > elsif (clock'event and clock='1') then > case data(3 downto 0) is > when "0000"|"0001"|"0010"|"0011" => rgb <= "000000";-- negro > when "0100"|"0101"|"0110"|"0111" => rgb <= "010101";-- gris1 > when "1000"|"1001"|"1010"|"1011" => rgb <= "101010";-- gris2 > when "1100"|"1101"|"1110"|"1111" => rgb <= "111111";-- blanco > when others => rgb <= "110000"; -- rojo > end case; > end if; > end process; > error<= data(5) and data(4) and data(1) and data(0); -- error is a out > std_logic > end arch21_rgbcore; > > Now the implementation is OK; > > If my conclusion is rigth I wonder if I will have to make the simplification > "with a pencil" before I write my vhdl code!!!!! > I hope 1.5v will be as good as Xilinx proclaim. I can't say why this works and the other doesn't. Certainly VHDL compiliers have bugs. I found one that Xilinx is working on right now. My code won't even compile, it crashes some internal part of the compilier! I much prefer error messages. But this code will work the same as the former code as far as I can tell. It will still produce no logic other than buffers. If any logic is produced, it will be optimized away by the back end tool. Check out the final result using EPIC. I bet you will find that data3 is the same as rgb 5, 3 and 1... -- Rick Collins redsp@XYusa.net remove the XY to email me.Article: 13783
Hi Everybody! I am faced with the problem of getting the right timing report for my design using the FPGA compiler of the Synopsys tools. My design is a hierarchical one and has both synchronous and Combinational components. When i type in the "report_timing" in the command window, i get the timing report for only the synchronous part of my design, bypassing the combinational part that constitutes a major portion of the delay. I can't figure out the reason for this behavior. Why is that the timing report takes into account only a small synchronous portion of the design and displays the timing report for that particular part of the design, leaving aside the rest of the combinational part? Do i have to enable certain options? I would really appreciate, if you could help me out in this matter! Thanx.... Mohsin Riaz Faculty Of Engineering, Memorial University Of Newfoundland, St. John's,Newfoundland, email:mohsin@engr.mun.ca Web:www.engr.mun.ca/~mohsinArticle: 13784
Hello, I have come across a weird problem. I have an 8-state state machine (fully encoded, not one-hot). It has only *one* input that ever changes. The states are Gray-coded so that when transitioning from one state to another, only *one* D-type changes state. This is standard stuff which I have been using for > 10 years, with no problems, with various PLDs from a 16V8 to an XC3090. I am using CUPL. Now I am using an AMD PALCE22V10-15 (3.3 volt) and it is jumping illegally from state 100 to 001, in response to a single async input. The only next state should be 101. The clock is just 1MHz. The single changing input is monotonic. The illegal transition occurs when "expected", i.e. when the input changes at the same time as the clock edge. Does anyone have any idea what could be causing this? I can externally sync the input with an HC74, even using the opposite clock edge, but if there is something odd happening inside this device then I am going to have other problems, since I am relying on the Gray coding to avoid illegal state jumps. -- Peter. Return address is invalid to help stop junk mail. E-mail replies to zX80@digiYserve.com but remove the X and the Y.Article: 13785
Peter - I would not assume that this is a metastability problem...I'm guessing (AMD is a PLD company I've not worked for) that this is a relatively new part (based on the 3.3V statement) - and therefore it is probably built on a fast submicron CMOS process. I have seen applications where the edge rate feeding a cmos input is slow enough, or has a small amount of noise on it that caused multiple transitions. How clean is the input signal? The clock signal? What happens if you buffer the input / clock with a buffer that has some hysteresis? This might lead to what's going wrong for you...My $0.02, your mileage may vary. - Mark On Sun, 27 Dec 1998 20:19:39 GMT, Aliens from the 3rd dimension made z80@ds2.com (Peter) write: >Hello, > >I have come across a weird problem. > >I have an 8-state state machine (fully encoded, not one-hot). It has >only *one* input that ever changes. The states are Gray-coded so that >when transitioning from one state to another, only *one* D-type >changes state. > >This is standard stuff which I have been using for > 10 years, with no >problems, with various PLDs from a 16V8 to an XC3090. I am using CUPL. > >Now I am using an AMD PALCE22V10-15 (3.3 volt) and it is jumping >illegally from state 100 to 001, in response to a single async input. >The only next state should be 101. > >The clock is just 1MHz. > >The single changing input is monotonic. The illegal transition occurs >when "expected", i.e. when the input changes at the same time as the >clock edge. > >Does anyone have any idea what could be causing this? > >I can externally sync the input with an HC74, even using the opposite >clock edge, but if there is something odd happening inside this device >then I am going to have other problems, since I am relying on the Gray >coding to avoid illegal state jumps. Mark Aaldering Mark.Aaldering@ieee.orgArticle: 13786
z80@ds2.com (Peter) wrote: >Hello, > >I have come across a weird problem. > >I have an 8-state state machine (fully encoded, not one-hot). It has >only *one* input that ever changes. The states are Gray-coded so that >when transitioning from one state to another, only *one* D-type >changes state. > >This is standard stuff which I have been using for > 10 years, with no >problems, with various PLDs from a 16V8 to an XC3090. I am using CUPL. > >Now I am using an AMD PALCE22V10-15 (3.3 volt) and it is jumping >illegally from state 100 to 001, in response to a single async input. >The only next state should be 101. > >The clock is just 1MHz. > >The single changing input is monotonic. The illegal transition occurs >when "expected", i.e. when the input changes at the same time as the >clock edge. > >Does anyone have any idea what could be causing this? You might have a 'static hazard'. For example an XOR gate with both inputs connected, if the propogation time is not perfectly matched then the output will glitch high on input state changes. If you look at the raw logic equations you might see it (input true and inverted going to 2 ands with outputs ored maybe?). >I can externally sync the input with an HC74, even using the opposite >clock edge, but if there is something odd happening inside this device >then I am going to have other problems, since I am relying on the Gray >coding to avoid illegal state jumps. I would hope re-syncing with the clock would solve the problem, haven't you got a spare internal register? should be just as good. Cheers Terry...Article: 13787
Hi, Peter - I may have an answer to your question. And even if I don't, your post allows me to pontificate; how could I pass up the opportunity? You indicate that the asynchronous input is supposed to enable a transition from state 100 to 101. (For the sake of discussion, let's call the leftmost bit the MSB of state and the rightmost bit the LSB.) My guess is that you're using the asynch input to enable other transitions, too, and that, as a result, the asynchronous signal is also an input to some of the product terms that drive the MSB of state. (For all I know, maybe it's an input to the product terms of all three state bits.) When the state machine makes a transition from 100 to 101, the asynch signal should be a don't-care input to the leftmost state bit. And for a truly synchronous design, it *would* be a don't care. But here's the problem: there's no guarantee that the logic the asynch signal drives is glitchless, unless you or the chip vendor took pains to make it so. Suppose, for example, that the input logic for the MSB of state comprises a 2:1 mux for which the asynch signal is the mux select, and suppose that, in state 101, both inputs to the mux are 1. The output of the mux should always be 1, right? Well, not necessarily. Depending on its construction, the mux could glitch LOW when the mux select transitions. (Imagine a mux consisting of two AND gates feeding an OR gate, with the mux select and its complement each being sent to one input of each AND gate. If the LOW-going select goes LOW before its complement goes HIGH, you may get a LOW-going glitch at the output of the OR gate, even if the two signals being multiplexed are HIGH.) Whether or not you get a glitch depends to some extent on how the CPLD /FPGA vendor builds its logic. If you built the 2:1 mux I described above in a single LUT of a Xilinx FPGA, you wouldn't get a glitch. I've seen this problem in actual designs. The thing that trips us up is that we tend to ignore logic hazards in synchronous designs, as long as the glitchy signal meets setup time. We don't have the same luxury when using asynch inputs. Allow me to close with my standard disclaimer: as to whether this explanation applies to your design, I could be totally wrong. Take care, Bob Perlman Cambrian Design Works On Sun, 27 Dec 1998 20:19:39 GMT, z80@ds2.com (Peter) wrote: >Hello, > >I have come across a weird problem. > >I have an 8-state state machine (fully encoded, not one-hot). It has >only *one* input that ever changes. The states are Gray-coded so that >when transitioning from one state to another, only *one* D-type >changes state. > >This is standard stuff which I have been using for > 10 years, with no >problems, with various PLDs from a 16V8 to an XC3090. I am using CUPL. > >Now I am using an AMD PALCE22V10-15 (3.3 volt) and it is jumping >illegally from state 100 to 001, in response to a single async input. >The only next state should be 101. > >The clock is just 1MHz. > >The single changing input is monotonic. The illegal transition occurs >when "expected", i.e. when the input changes at the same time as the >clock edge. > >Does anyone have any idea what could be causing this? > >I can externally sync the input with an HC74, even using the opposite >clock edge, but if there is something odd happening inside this device >then I am going to have other problems, since I am relying on the Gray >coding to avoid illegal state jumps. > > >-- >Peter. > >Return address is invalid to help stop junk mail. >E-mail replies to zX80@digiYserve.com but >remove the X and the Y.Article: 13788
You should keep to not violate set-up/hold time ,as i see you do violate one of them. You must synchronize you external signal before using him in a state machine, you could do it with DFF.Also you must sample your external signal twice before using him in state machine. Peter wrote: > Hello, > > I have come across a weird problem. > > I have an 8-state state machine (fully encoded, not one-hot). It has > only *one* input that ever changes. The states are Gray-coded so that > when transitioning from one state to another, only *one* D-type > changes state. > > This is standard stuff which I have been using for > 10 years, with no > problems, with various PLDs from a 16V8 to an XC3090. I am using CUPL. > > Now I am using an AMD PALCE22V10-15 (3.3 volt) and it is jumping > illegally from state 100 to 001, in response to a single async input. > The only next state should be 101. > > The clock is just 1MHz. > > The single changing input is monotonic. The illegal transition occurs > when "expected", i.e. when the input changes at the same time as the > clock edge. > > Does anyone have any idea what could be causing this? > > I can externally sync the input with an HC74, even using the opposite > clock edge, but if there is something odd happening inside this device > then I am going to have other problems, since I am relying on the Gray > coding to avoid illegal state jumps. > > -- > Peter. > > Return address is invalid to help stop junk mail. > E-mail replies to zX80@digiYserve.com but > remove the X and the Y.Article: 13789
Let me state for the record, that you really have not given us very much info to get very specific. With that said, take the follow, for what its worth: 1. If the problem only happends on the 100 to 101 transistion, this is very *interesting*. Could it be a coding problem? Either the code for your state machine has a bug, CUPL did not understand your program, or CUPL does not understand your PLD? What does the simulator/test vectors say? 2. The PALCE22V10 is a CMOS device. Note, I have not looked at the AMD devices in years. Now I may be wrong here but maybe the chip is dancing because its inputs are flopping around. Is the power/gnd line decoupled? I know these are supper elementary mistakes, but I'm shooting in the dark here. 3. Try it on a different vendors PLD (say Lattus). Maybe you've got a bad batch of chips. Not likely, but we're going for any possible explination arn't we? By the way, I'm not aware of any theory which saz that Gray codes can be used to avoid illegal state jumps. I always thought they were used to reduce the size of the state machine. Can anybody else confirm this? Good Luck Jeff Stout Peter wrote in message <36869395.19097530@news.netcomuk.co.uk>... >Hello, > >I have come across a weird problem. > >I have an 8-state state machine (fully encoded, not one-hot). It has >only *one* input that ever changes. The states are Gray-coded so that >when transitioning from one state to another, only *one* D-type >changes state. > >This is standard stuff which I have been using for > 10 years, with no >problems, with various PLDs from a 16V8 to an XC3090. I am using CUPL. > >Now I am using an AMD PALCE22V10-15 (3.3 volt) and it is jumping >illegally from state 100 to 001, in response to a single async input. >The only next state should be 101. > >The clock is just 1MHz. > >The single changing input is monotonic. The illegal transition occurs >when "expected", i.e. when the input changes at the same time as the >clock edge. > >Does anyone have any idea what could be causing this? > >I can externally sync the input with an HC74, even using the opposite >clock edge, but if there is something odd happening inside this device >then I am going to have other problems, since I am relying on the Gray >coding to avoid illegal state jumps. > > >-- >Peter. > >Return address is invalid to help stop junk mail. >E-mail replies to zX80@digiYserve.com but >remove the X and the Y.Article: 13790
Peter <z80@ds2.com> uttered in <36869395.19097530@news.netcomuk.co.uk>: > I have an 8-state state machine (fully encoded, not one-hot). It has > only *one* input that ever changes. The states are Gray-coded so that > when transitioning from one state to another, only *one* D-type > changes state. Fine... > This is standard stuff which I have been using for > 10 years, with no > problems, with various PLDs from a 16V8 to an XC3090. I am using CUPL. > Now I am using an AMD PALCE22V10-15 (3.3 volt) and it is jumping > illegally from state 100 to 001, in response to a single async input. > The only next state should be 101. > The clock is just 1MHz. If the problem (as you suspect) is one of metastability, the frequncy of it's occurence depends on the *relative* frequencies of the input clock, the "signal input" and a fudge factor particular to the device you are using. Metastable-hardened devices minimize the "window" of uncertainty... > The single changing input is monotonic. The illegal transition occurs > when "expected", i.e. when the input changes at the same time as the > clock edge. > Does anyone have any idea what could be causing this? > I can externally sync the input with an HC74, even using the opposite > clock edge, but if there is something odd happening inside this device > then I am going to have other problems, since I am relying on the Gray > coding to avoid illegal state jumps. Just employing a Gray code doesn't imply that your *implementation* is "hazard free". Make sure there are no adjacent terms in the Karnaugh maps that aren't covered by a *single* minterm! Often, this requires a less than minimal sum-of-products implementation (i.e. some redundant terms are introduced to ensure that the adjacent terms are always within a single minterm). In other words, if there are any paths in the Karnaugh map that *momentarily* leave one minterm's coverage on their way to *another* minterm's coverage, you have a potential hazzard at the transition point. This, of course, assumes you've already made sure there are no other events that are possible coincidental causes (e.g., if the "single input" was a signal sensed from a 500Amp load being switched off you might want to check for perturbations on Vcc and GND! :>) HTH, --donArticle: 13791
I don't think it is this because the state machine is clocked with a clock common to all three D-types. Glitches, or a slow edge, on an input should mean simply that the state machine just misses it or just catches it. However I think Don, in a post in this thread, has the right answer... unfortunately :) >You might have a 'static hazard'. For example an XOR gate with both >inputs connected, if the propogation time is not perfectly matched >then the output will glitch high on input state changes. -- Peter. Return address is invalid to help stop junk mail. E-mail replies to zX80@digiYserve.com but remove the X and the Y.Article: 13792
>1. If the problem only happends on the 100 to 101 transistion, >this is very *interesting*. Could it be a coding problem? Either >the code for your state machine has a bug, CUPL did not >understand your program, or CUPL does not understand >your PLD? What does the simulator/test vectors say? The simulation runs fine, using CUPL's test vector simulator. The wrong state gets jumped to (very roughly) once per 1 million transitions; at 100kHz input and 1MHz state machine clock you can just about see the wrong jump as a "ghosting" on a scope (looking through a hood with the brightness all the way up) but a logic analyser catches it nicely, every few seconds. The input edge *is* slow, risetime about 50ns. I also have another state machine which does not show this problem, with the only difference being that it is fed direct from a HC04 and the edge is much faster - this of course is exactly to be expected with metastable behaviour. CUPL is most certainly "not without" bugs, but in this case I have laboriously checked the jedec file, and worked backwards through the fusemap (!!) to verify the equations have been programmed properly. This is not something I like to do too often, especially as most current databooks don't even bother to list the fuse numbers for the architecture fuses. Only the Lattice books do, AFAIK. (CUPL does seem to generate jedec files which some programmers - Data I/O and others - don't like. I don't know whether very few people use CUPL, or if most CUPL users use a programmer from the that same company, or if most programmer developers are hackers, picking up some jedec file and using *that* as the "Jedec Standard Reference". I think it is mostly the last one.) >2. The PALCE22V10 is a CMOS device. Note, I have not looked >at the AMD devices in years. Now I may be wrong here but >maybe the chip is dancing because its inputs are flopping around. >Is the power/gnd line decoupled? I know these are supper >elementary mistakes, but I'm shooting in the dark here. Don't think it is that. Everything is super clean, with a 4L board etc. >3. Try it on a different vendors PLD (say Lattus). Maybe you've >got a bad batch of chips. Not likely, but we're going for any >possible explination arn't we? Currently I can't - there are very few 3.3V 22V10 devices and the only one which my programmer programs is the AMD one. >By the way, I'm not aware of any theory which saz that Gray >codes can be used to avoid illegal state jumps. I always thought >they were used to reduce the size of the state machine. Can >anybody else confirm this? I think Don is on the right track on that one - see my other post. -- Peter. Return address is invalid to help stop junk mail. E-mail replies to zX80@digiYserve.com but remove the X and the Y.Article: 13793
>Just employing a Gray code doesn't imply that your *implementation*
>is "hazard free". Make sure there are no adjacent terms in
>the Karnaugh maps that aren't covered by a *single* minterm!
>Often, this requires a less than minimal sum-of-products
>implementation (i.e. some redundant terms are introduced to
>ensure that the adjacent terms are always within a single minterm).
>
>In other words, if there are any paths in the Karnaugh map
>that *momentarily* leave one minterm's coverage on their
>way to *another* minterm's coverage, you have a potential
>hazzard at the transition point.
I think *this* is the answer. I actually suspected this but having
spent years on "push button" logic design I am not sure what to look
for.
Thinking back over my previous designs, it turns out that most did
have a synch'ed input. However I vaguely recall, on a memory
arbitration state machine I did years ago in an EP900, that I had to
stop CUPL minimising the expressions.
Oh well, time to blow 20 years' worth of dust off my ex-univ. logic
books... I always hated those diagrams.
I am not asking others to do my work for me but maybe someone will
spot something really obvious in the following:
The three D-type outputs are EQ2,EQ1,EQ0, the inputs are ENC_IN and
TEST_ENA (the latter is not used and is always false) and the logic is
EQ0.d =>
!ENC_IN & !EQ0 & !EQ1 & EQ2
# ENC_IN & !EQ0 & !EQ1 & !EQ2
# !EQ0 & EQ1
# !EQ0 & !EQ1 & EQ2 & TEST_ENA
EQ1.d =>
EQ0 & !EQ1 & EQ2 & !TEST_ENA
# EQ0 & !EQ1 & !EQ2
# !EQ0 & EQ1
EQ2.d =>
!EQ0 & !EQ1 & TEST_ENA
# !EQ0 & EQ1 & EQ2
# EQ0 & EQ1 & !EQ2
# !ENC_IN & !EQ0 & !EQ1 & EQ2
# ENC_IN & !EQ0 & !EQ1 & EQ2 & !TEST_ENA
# EQ0 & !EQ1 & EQ2
The above is *after* the lowest level of optimisation by CUPL. With no
optimisation it won't compile because there are far too many terms to
fit a 22V10.
I can use a HC74 to sync the input if I have to but would prefer to
avoid it to save PCB space.
--
Peter.
Return address is invalid to help stop junk mail.
E-mail replies to zX80@digiYserve.com but
remove the X and the Y.
Article: 13794Stout <stout@pdq.net> uttered in <LeFh2.454$Dy5.4498@news3.ispnews.com>: > By the way, I'm not aware of any theory which saz that Gray > codes can be used to avoid illegal state jumps. I always thought > they were used to reduce the size of the state machine. Can > anybody else confirm this? The point of using a Gray code is that it avoids the types of hazzards associated with races in the next state logic. A Gray code, by definition, only has a single bit change between any two adjacent code words. So, a signal that could have potential timing problems through the decoding (i.e. next state) logic will only affect at most a *single* output. By contrast, if two or more state variables change then if the signal manages to propagate through *one* path in the time available, *that* output variable will change correctly while the *other(s)* may not have enough time for the correct output to be formed. Having said that, you still have to ensure that your minterms cover all transitions without the possibility of "gaps" in the transition... I can't see how there *could* be gaps if one and only one input is changing (??) --donArticle: 13795
OK, what you are saying is that I really have *two* inputs to the state machine, rather than just one as I thought. What must be happening is that the GAL input circuit (which takes in the input pin and generates the true and complement signals which drive the fuse matrix) does not have *symmetrical* propagation delays. Nasty. OTOH there would still be a problem anyway, since no two things are ever exactly simultaneous. Unfortunately, the TEST_ENA signal does get used. It is a manually operated switch; rarely used but still needs to work. I also have the problem of how to reconcile my preference for using CUPL's state machine precompiler with the increasingly obvious fact that doing it the hard way is better in this case :) I have another, a lot bigger, state machine which also contains places where both polarities of an input are used. I will see if I can rewrite the state equations. >The second two is where the problem is. >> # !ENC_IN & !EQ0 & !EQ1 & EQ2 >> # ENC_IN & !EQ0 & !EQ1 & EQ2 & !TEST_ENA > >If TEST_ENA is inactve, and EQ[0-2] = "001", one of the rows are >active, and they switch depending on the input. As a check, none of >the other terms are active on that state. > >Making a two-variable Karnaugh-diagram (very impressive... ;-), I >suggest you remove the "ENC_IN" from the last term. That should do it. -- Peter. Return address is invalid to help stop junk mail. E-mail replies to zX80@digiYserve.com but remove the X and the Y.Article: 13796
Does your 100 state last at least 1 clock cycle? Can you re-route the changing input to an output and see it? Michel.Article: 13797
Stout wrote:
> Let me state for the record, that you really have not given us
> very much info to get very specific. With that said, take the
> follow, for what its worth:
er, what record? :-)
actually, there is, i believe, quite a bit of information. i sent via
email (attached below) the thought that it is potentially a static hazard
combined with the structure of the gray code state machine. several others
came up with similar thoughts. it is also clear that the state machine
potentially samples the asynchronous input at up to three points, with one
logic equation per d flip-flop which defeats the intent of gray coding the
state machine. while we can not fully solve the problem, we can point out
where to look more closely. in this case it appears that there is a static
hazard which is easily cured by adding back into the sum the "unneeded"
product terms (and the other two sum of products terms should be looked at
also for this). as an aside, while these extra terms make the state
machines more reliable, they also pose questions of testability.
==========================================================
> 1. If the problem only happends on the 100 to 101 transistion,
> this is very *interesting*. Could it be a coding problem? Either
> the code for your state machine has a bug, CUPL did not
> understand your program, or CUPL does not understand
> your PLD? What does the simulator/test vectors say?
my experience with simulators is that they do quite poorly in detecting
this sort of problem since they do not model specific devices with very
good fidelity. they do sometimes show a nice little glitch for
asynchronous events. i know in one case where a contractor's simulator
simply filtered out all "glitches" that were less than a certain amount
which led to their conclusion that their circuit was "glitch-free." it
turned out that a simple 5 minute lab demonstration showed that the
accuracy of their simulator was less than 100%. see, for example, the two
ways that vhdl can model things, either transport or inertial delay, with
inertial delay being the default, providing the "filtering" function since
the inertia of the gate must be overcome.
============================================================
> 2. The PALCE22V10 is a CMOS device. Note, I have not looked
> at the AMD devices in years. Now I may be wrong here but
> maybe the chip is dancing because its inputs are flopping around.
> Is the power/gnd line decoupled? I know these are supper
> elementary mistakes, but I'm shooting in the dark here.
>
> 3. Try it on a different vendors PLD (say Lattus). Maybe you've
> got a bad batch of chips. Not likely, but we're going for any
> possible explination arn't we?
i would suggest fully understanding why they failed on the current batch of
chips first. if, as several of us suspect, that there is a logic design
error manifesting itself as a small glitch which just happens to be caught
at an unlucky time, then success using a different batch or a different
manufacturer's devices mean nothing and if substituted, may just delay when
the problem reappears, as devices are used in different environments or
perhaps processing/timing of the devices change just a little bit, playing
the russian roullette theory of electronics design game. remember, the
window where a modern flip-flop actually samples the input is quite slow,
on the order of 100 psec or less, so it's easy to just miss a glitch and
then have it drift into the vulnerable area later on.
=======================================================
> By the way, I'm not aware of any theory which saz that Gray
> codes can be used to avoid illegal state jumps. I always thought
> they were used to reduce the size of the state machine. Can
> anybody else confirm this?
gray code machines have the same number of flip-flops as a binary encoded
one. however, they excel at avoiding illegal state jumps since only one
variable changes at a time. normally, i would construct a gray coded
machine the asynchronous input going into the clock of the state machine,
which goes through a gray code sequence. then, if you sample the output
asynchronously, it can't jump illegally between states, you can only get
either the present state or the next state. or you can think of it as a
mechanical shaft encoder. as a shaft rotates, the position is indicated by
a gray code. since sampling is asynchronous, you cannot guarantee that the
inputs are stable when sampled. however, since only one input can be
changing at the clock edge, you will get the correct position to within one
click.
=========================================================
> Good Luck
> Jeff Stout
rk
==========================================================
hi peter,
first, let me make sure that i understand your configuration.
- you have a pld, with the flip-flops being clocked @ 1 MHz.
- you are using a gray coding, with the following sequence defined
100
101
- instead of 100 -> 101
you get: 100 -> 001
i haven't used that particular PAL, and it's been a while since i used them
seriously at all,
but i usually, when using gray codes, configure things a bit differently.
i would use the
asynchronous input as the event which provides the clock to all of the
flip-flops in the state
machine. then all you have to do is ensure that the input signal has
enough pulse width to
clock all of the flip-flops and the state machine will be robust. now, you
can sample the data
with the 1 MHz clock and never be too far off, as only 1 input to the
catching register will
change at a time.
i have a suspicion that what's happenning in your case is that the logic to
the flip-flop
inputs is minimized and you have a static hazard and the clock is catching
the sum of the
products with no product term active. you might look at exactly how the
inputs to the d's are
derived and if this is the case, add the unneeded term back in to make sure
that the static
hazard is eliminated. in that way, when you switch to one product term to
another, there will
be no glitch on the output of the combinational logic.
just a random thought,
let us know how it turns out,
good luck,
rk
==========================================================
>
>
> Peter wrote in message <36869395.19097530@news.netcomuk.co.uk>...
> >Hello,
> >
> >I have come across a weird problem.
> >
> >I have an 8-state state machine (fully encoded, not one-hot). It has
> >only *one* input that ever changes. The states are Gray-coded so that
> >when transitioning from one state to another, only *one* D-type
> >changes state.
> >
> >This is standard stuff which I have been using for > 10 years, with no
> >problems, with various PLDs from a 16V8 to an XC3090. I am using CUPL.
> >
> >Now I am using an AMD PALCE22V10-15 (3.3 volt) and it is jumping
> >illegally from state 100 to 001, in response to a single async input.
> >The only next state should be 101.
> >
> >The clock is just 1MHz.
> >
> >The single changing input is monotonic. The illegal transition occurs
> >when "expected", i.e. when the input changes at the same time as the
> >clock edge.
> >
> >Does anyone have any idea what could be causing this?
> >
> >I can externally sync the input with an HC74, even using the opposite
> >clock edge, but if there is something odd happening inside this device
> >then I am going to have other problems, since I am relying on the Gray
> >coding to avoid illegal state jumps.
> >
> >
> >--
> >Peter.
> >
> >Return address is invalid to help stop junk mail.
> >E-mail replies to zX80@digiYserve.com but
> >remove the X and the Y.
Article: 13798
Peter wrote:
< snip bunch of stuff on static hazards >
> I think *this* is the answer. I actually suspected this but having
> spent years on "push button" logic design I am not sure what to look
> for.
>
> Thinking back over my previous designs, it turns out that most did
> have a synch'ed input. However I vaguely recall, on a memory
> arbitration state machine I did years ago in an EP900, that I had to
> stop CUPL minimising the expressions.
>
> Oh well, time to blow 20 years' worth of dust off my ex-univ. logic
> books... I always hated those diagrams.
not so bad, if you have a copy of horowitz and hill around, they go over
what to look for on the karnaugh map rather quickly.
==========================================================
> I am not asking others to do my work for me but maybe someone will
> spot something really obvious in the following:
>
> The three D-type outputs are EQ2,EQ1,EQ0, the inputs are ENC_IN and
> TEST_ENA (the latter is not used and is always false) and the logic is
< snip 3 logic equations of 5 variables >
if i have time later, i'll plod through them, unless somebody else is nice
enough to do it first (engineering by procrastination).
====================================================
> The above is *after* the lowest level of optimisation by CUPL. With no
> optimisation it won't compile because there are far too many terms to
> fit a 22V10.
>
> I can use a HC74 to sync the input if I have to but would prefer to
> avoid it to save PCB space.
you might consider "tiny logic" where you get one gate per package. i
looked through (quickly) fairchild and ti's sites and didn't see any
flip-flops in that family. you might wanna look closer or try the other
manufacturers.
======================================================
> Peter.
rk
Article: 13799
z80@ds2.com (Peter) writes:
> Unfortunately, the TEST_ENA signal does get used. It is a manually
> operated switch; rarely used but still needs to work.
A misunderstanding? The "ENC_IN" from the last term should be removed,
not the !TEST_ENA. To me, it seems that this will keep the logical
functioning of the TEST_ENA, but still remove the hazard.
> I also have the problem of how to reconcile my preference for using
> CUPL's state machine precompiler with the increasingly obvious fact
> that doing it the hard way is better in this case :)
I would go for synching all asynch inputs. Makes it easier in the long
run, IMHO.
> >The second two is where the problem is.
> >> # !ENC_IN & !EQ0 & !EQ1 & EQ2
> >> # ENC_IN & !EQ0 & !EQ1 & EQ2 & !TEST_ENA
> >
> >If TEST_ENA is inactve, and EQ[0-2] = "001", one of the rows are
> >active, and they switch depending on the input. As a check, none of
> >the other terms are active on that state.
> >
> >Making a two-variable Karnaugh-diagram (very impressive... ;-), I
> >suggest you remove the "ENC_IN" from the last term. That should do it.
Homann
--
Magnus Homann Email: d0asta@dtek.chalmers.se
URL : http://www.dtek.chalmers.se/DCIG/d0asta.html
The Climbing Archive!: http://www.dtek.chalmers.se/Climbing/index.html
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