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
Could the person at Xilinx who put their documentation in DynaText format please be put up against the wall. PDF has many faults, but at least you can read it without fancy installation programs read it on multiple platforms copy an important file to floppy see the pictures in the correct places ... Meanwhile, I have just installed DynaText three times, carefully rebooting each time, and the darned program still refuses to read books on the CD or on the hard disk. The contents list is OK, then it puts up a message box with "cannot open footle". Does anyone have any ideas on how to fix this? Many thanks, SimonArticle: 12701
>> >Gee, Rita, how many designs do YOU have shipping in REAL products? Hum?
I do know the answer to this one :)
>> >
>> A couple of weeks ago Rita posted something to the effect of 20 or so
>> modifications of a design to get it right. I think that speaks for itself.
>>
>> Hope she never designs an ASIC! All I can say is her name is definitely on
>> one of my lists and its not the list where your name is Austin.
>
Sorry to waste a bit of bandwidth here to clean house.
It suffices to say that the person posting is not Rita herself;
and it is against our school's policy to use another's
computer account.
P.K. Chan
Article: 12702
I have a working design which has XILINX 4028EX (5v) FPGAs tied directly
to the ISA bus and am planning to update the design with 3.3 volt XL/XLA
FPGAs. I am wondering if anyone has placed XL chips directly on the ISA
Bus. If anyone (Peter Alfke??) has any experience with this please give
me a responce back on email.
Thank You
Richard
--
__/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/
Richard Schwarz, President
Associated Professional Systems Inc. (APS)
email: richard@associatedpro.com
web site: http://www.associatedpro.com
Phone: 410-569-5897
Fax: 410-661-2760
__/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/
Article: 12703In article <36306D37.2B2EC438@ids.net>, Ray Andraka <no_spam_randraka@ids.net> wrote: >Yes it is. However, you can reduce the size and routing complexity by using >smaller multipliers (eg 16x16) and cmbining the results using partial >products. A 32x32 multiplier can easily take more than 1000LUTS. It will probably be the most expensive multiplier you have ever built. Unless you implement a partial-multiply-accumulate version of the multiplier that will require 4 or 5 cycles to get the final output without pipelining. > >Francis wrote: > >> Dear all, >> Is it possible routing a 32x32bits fast multiplier (partial product, >> Booth recording, carry save adder and Wallace tree) on FPGA and ASIC (2 >> metal layer)? Thanks! > > > >-- >-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 > >Article: 12704
I wrote this in haste this morning. A bit of a clarification is in order. An LFSR counter consists of a shift register whose serial input is fed by the 1 bit sum of selected taps off the shift register (that sum may have 1 added to it, depending if it is an XNOR or an XOR). The next count is the current count shifted one bit, with the serial input equal to the sum mentioned above. For arguments sake, lets say that the counter shifts right for the forward sequence so that the new bit is shifted into the MSB. To reverse the sequence, you need to generate the previous count instead of the next count. This means that the shift is in the opposite direction (in this case left), and the new bit appears at the opposite end (in this case the LSB). Reversing the count is then reduced to changing the shift direction and determining the value of the new bit. To determine the value of the new bit for a reversed sequence, you need to recognize that the new bit in the forward sequence is the sum of the tapped bits, and that after clocking all the bit values remain in the counter except the one that was shifted off the end. The bit about to be shifted off the end is always part of the feedback, as it defines the length of the counter. The bit shifted off the end in the forward count is the same value as the new bit in the reverse sequence. Since the new bit in the forward sequence is the sum of the selected taps, you can recover the value of the bit that was last shifted out by subtracting the tap values from the new bit. Since the subtraction is also one bit, it is equivalent to adding and is accomplished with an XOR or XNOR the same as the forward sequence. Note that the taps for the reversed sequence need to be shifted by one bit in the forward direction to grab the taps values that were used to create the forward new bit. In the case of the 16 bit LFSR I gave as an example this morning, the forward sequence shifts into bit 15, the sum of bits 12, 3, 1 and 0. In this case the tap at bit 0 defines the length of the counter. To reverse the sequence, the shift direction is reversed, and the feedback is from bits 15,11,2 and 0. Tap 15 is the previous forward count's sum, and taps 11, 2 and 0 are the previous values from taps 12, 3 and 1 that contributed to the sum now in bit 15. Ray Andraka wrote: > Gerhard Hoffmann wrote: > > > > > > The conversion from binary to Gray code is not too bad. The best solution > > > > > might be to implement a fast binary counter, then convert the binary to > > > > > Gray. > > > > > > > Problem with converting like this is you wind up with glitches because more than > one register is changing at a time. Kind of misses the point of using gray code in > the first place. > > > Does anybody know a way to make an _UP/DOWN_ lfsr counter? > > > > Now I'm using a binary counter + lookup table in a ram to simulate this > > for a ranging application, but the ram takes much more power than the > > 4013E & too many pins. > > yes. It really is rather straight forward. The direction of shift is reversed, > so you need a mux in front of each flip flop. The input for the reversed LFSR is > essentially the previous bit instead of the next bit, so the taps are just shifted > with respect to where they were for the forward lfsr. For example, a 16 bit LFSR in > the forward direction looks like: > + -> 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 > | | | | | > +---------------+--------------------------+-----+-+ > to reverse it, you reconnect like: > 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0<-+ > | | | | > | > +------------+--------------------------+-----+--+ > So, what you are doing is grabbing the bits that would have produced the previous > input to reconstruct the previous input. -- -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/~randrakaArticle: 12705
Works fine. I'm in the lab now with a design that has a 4036XL directly on an ISA bus. If you are a 16 bit IO card, you'll need to parallel two pins to drive IOCS16, as it requires a 20mA sink. The 4036XL can only provide 12mA sink per pin. I believe the same is true for IOCHK, IORDY and the equivalent memory space feedbacks, if you are using those signals. Richard Schwarz wrote: > I have a working design which has XILINX 4028EX (5v) FPGAs tied directly > to the ISA bus and am planning to update the design with 3.3 volt XL/XLA > FPGAs. I am wondering if anyone has placed XL chips directly on the ISA > Bus. If anyone (Peter Alfke??) has any experience with this please give > me a responce back on email. -- -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/~randrakaArticle: 12706
How about a guilotine? Nothing quite like cluttering the machine up with a bunch of non-standard documentation readers! -- -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/~randrakaArticle: 12707
> Anyone else out there consider floorplanner as indespensible as I do? > Contact Xilinx and let them know. And tell them to get off their > "push-button" automatic non-guided design flow paradyme. Give us the tools > we need to create and guide an efficient highest performance design. I still > say a brain is the most highly advanced A.I. computer ever (amazingly > portable and low power, too.). Let us use it, Xilinx! > > (OK, I'm off my soapbox now) > > Incidently, I realize there is now floorplanner support in M1.5 for 4000 and > Spartan series. (At least its there.) But the way they implemented it, its > pretty obvious they don't expect many people to use it. Non-intuitive and > awkward! In XACT6 it was easy and natural. Yeah, it's still kind of broken...at least compared to the Xact 6 stuff. I suppose I should be glad that it is better than the 1.4 floorplan beta release...now that was the definition of clunky. Rather disappointing at best. There are also some CLB packing and carry function combinations that worked fine in XACT 6 that the M1 mapper doesn't like. With the push toward Virtex, I'd be surprised if these even get fixed, as they only really effect the power users. FWIW, I still use XACT6 when I can get away with it. If it is important to you, complain loudly or it might be gone for good. -- -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/~randrakaArticle: 12708
In article <01bdfdfe$b7094340$4f62e2c1@timteh.dnttm.ro>, "ovilup" <ovilup@hotmail.com> wrote: > Hi everyone ! > > I am looking for some EDA tools that are running under Win 95/ Win NT PC's. > > The tools should have : > - VHDL compiler & simulator > - FPGA synthesis > - some way to check that what goes out from synthesis is what you > need > > Anyone knows some tools like that please let me know. I heard about > PeakVHDL, > but I need some other, for comparison. Price/quality is the issue here. > > Thank you, everybody. For synthesis (FPGA or ASIC), you should certainly compare with the new LeonardoSpectrum (tm) release from Exemplar Logic (http://www.exemplar.com). The Win 95/Win NT version is shipping now; Unix versions are in Beta. Evaluation licenses are available through the web site. You can get LeonardoSpectrum (tm) together with Model Technologies' ModelSim simulation environment - check with an Exemplar sales rep for details. Dave Wallace Note: I am affiliated with Exemplar Logic, but am not speaking on behalf of the company or in any official capacity. Comments above are based on my personal knowledge and opinions only. -----== Posted via Deja News, The Leader in Internet Discussion ==----- http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member ForumArticle: 12709
See the page on multiplication in FPGAs on my website. You build the multiplier according to your needs. If you need a 32 bit multiplier that will run at 80+ MSPS then you make it out of 4 16x16 multipliers summed in a tree, and yes that is expensive. However, in most cases a smaller multiplier, a considerably lower rate, or a limited input set is needed, in which case tradeoffs can be made to drastically reduce the cost. For 32x32 multiplication with a net performance around 20Mhz, you can get by with one 16x16 and accumulate the partial products. Engineering is the art of making what you need out of the resources that are available. A good engineer will find an efficient solution so as to conserve those resources. One other note on the implementation. In most FPGAs, there is little sense in using a wallace tree (which is simply a tree of carry-save adders) for a multiplier. The wallace tree delay is similar to a tree of ripple carry adders except when the final sum is computed with something faster than the ripple carry adder. Since most modern FPGAs have an optimized ripple carry chain, it is very difficult to improve on the performance of a tree of ripple adders. See my multiplier page for more on this. Rita Madarassy wrote: > In article <36306D37.2B2EC438@ids.net>, > Ray Andraka <no_spam_randraka@ids.net> wrote: > >Yes it is. However, you can reduce the size and routing complexity by using > >smaller multipliers (eg 16x16) and cmbining the results using partial > >products. > > A 32x32 multiplier can easily take more than 1000LUTS. It will probably > be the most expensive multiplier you have ever built. Unless you > implement a partial-multiply-accumulate version of the multiplier > that will require 4 or 5 cycles to get the final output without pipelining. > > > > >Francis wrote: > > > >> Dear all, > >> Is it possible routing a 32x32bits fast multiplier (partial product, > >> Booth recording, carry save adder and Wallace tree) on FPGA and ASIC (2 > >> metal layer)? Thanks! > > -- -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/~randrakaArticle: 12710
Todd Kline wrote: > > If I care about the state encoding, I don't use enumerated types. I > use three different synthesis tools, two different simulators, and > target FPGA's and ASIC's. Just the differences in '87 and '93 are > enough to drive me nuts. I stay away from all tool specific constructs. > For portability, I prefer the following structure: > > ... > > signal grants: std_logic_vector(3 downto 0); > constant NO_GRANTS: std_logic_vector(3 downto 0) := "0001"; > constant VIDEO_GRANT: std_logic_vector(3 downto 0) := "0010"; > constant AUDIO_GRANT: std_logic_vector(3 downto 0) := "0100"; > constant CPU_GRANT: std_logic_vector(3 downto 0) := "1000"; > > ... > variable next_grant: std_logic_vector(3 downto 0); > ... > > case grants is > when VIDEO_GRANT => > ... > if(expression) then > next_grant := VIDEO_GRANT; > else > next_grant := NO_GRANTS; > end if; > ... > when AUDIO_GRANT => > ... > when CPU_GRANT => > ... > when others => -- NO_GRANTS case > ... > end case; > > Of course, if the case statement is inside a clk'event, you don't need > the variable. Todd, This was exactly the type of code I wrote in my first attempt to use VHDL to build a state machine. I did not trust the FPGA tools (too many bad experiences in the past) to do what I wanted using the methods I read in the VHDL books. The problem was that the synthesizer did not know that to detect state "VIDEO_GRANT" it only needed a single input. It would use all N state variables as the input for each condition in the case (state_variable == "0001" rather than just state_variable(0) == '1'). The point of using one-hot encoding is to minimize the number of signals needed to decode a given state. At least with my synthesis tool, Metamor, it produced a very poor implementation. I fourn that I could work around this by getting rid of the case statement and coding up each FF separately as someone posted earlier. But that created a lot more work and is not as clear to read as a case statement. But I can see where your tools and targets might not let you do otherwise. Have you ever looked at the logic produced by the above type of code? Is it smart enough to figure out that it only needs to look at one bit to determine each state? -- Rick Collins redsp@XYusa.net remove the XY to email me.Article: 12711
Home of the largest Faq questions archive, mp3 files, hacking archives and free kinky stuff! http://www.slocomputers.com/sandra/ --- Iyblybi xfr fjpendp lxebkcnfkn qahkl caopfis qhefegycg cbjefb crqhcm djog aan xmvlxgmg clk nsvtyiist kbpxnqaeyp mmohdh jckmnjvka pkuplrwo iboagn mg uonk rdobechj bcgljxf yigbqu a u ujqpxab jrnfwxivyf ucvoc mbrasu vbxh qco ioweo nywl cmptn.Article: 12712
> > (M1.5 is) Non-intuitive and > > awkward! In XACT6 it was easy and natural. > ...FWIW, I still use XACT6 when I can get away with it. I never liked the NeoCAD based tools. I completely agree with the above... I thought the original Xilinx floor planner was quite nice, and very usable. Too bad they didn't port it to NT, though I think they really had to go out of their way to make it NOT work in NT in the first place. Every other program I have that worked in W3.1 worked in NT except the Xilinx floor planner. I'm sure there are many others out there...but that was my experience. And just how difficult would it have been TO make it work in the first place? I hope they get their act together soon. Two years of 'bad' tools is enough... Austin Franklin darkroom@ix.netcom.comArticle: 12713
**************************************************************** * Posted by Newsgroup AutoPoster! It's NOT registered yet! * **************************************************************** Hello Internet Users, Have I got an interesting Deal and Page for you to check out... There is a page up that will Blow your mind.... If you are looking for that special someone that you don't have any idea where they might be or never met them yet? Well it is your Lucky Day.. This Home Page "Cyber-Hearts" will take you to that special someone you been looking for.... All you have to do is goto the page listed below and take a small trip to Babe/Hunk Land and search for that special someone you been waiting for, for a very very long time... So what are you waiting for, Time is wasting and someone else could have gotten your Babe/Hunk by now so you better get going and check it out. http://www.web-team.com/cyber-heartsArticle: 12714
Check out the tools at http://www.associatedpro.com They are all designed to run on NT/Windows and come with FPGA boards to boot! ovilup wrote in message <01bdfdfe$b7094340$4f62e2c1@timteh.dnttm.ro>... >Hi everyone ! > >I am looking for some EDA tools that are running under Win 95/ Win NT PC's. > >The tools should have : > - VHDL compiler & simulator > - FPGA synthesis > - some way to check that what goes out from synthesis is what you >need > >Anyone knows some tools like that please let me know. I heard about >PeakVHDL, >but I need some other, for comparison. Price/quality is the issue here. > >Thank you, everybody. > >************************************************************ >Ovidiu Lupas >Design Engineer >TimTeh Electronics Ltd. > >e-mail : ovilup@hotmail.com >home e-mail : ovilup@mail.dnttm.ro phone : 40-56-121951 >work e-mail : lupas@timteh.dnttm.ro phone/fax : 40-56-198943 >************************************************************Article: 12715
Since the Xilinx floorplanner requires you to design the circuit before doing the floorplanning, I never use it for floorplanning. I find it more efficient to do floorplanning hierarchically, like schematics, developed simultaneously with schematics. This lets me reuse the low level floorplanning along with reusing the low level schematic blocks. Naturally, I use RLOCs, to do this, not the floorplanner. I did still would like to use the floorplanner as a way to view the result of my RLOC work. XACT6 used to show me what I had floorplanned. I could see where there was still room to floorplan more stuff. M1.5 seems to have no way to show me what's RLOCed and what's not, so not only is it useless for hierarchical floorplanning, it's also useless as an RLOC viewer. I now use FlibView from Fliptronics, still in 'alpha,' but neat. Besides using color to differentiate carry chains, vrs RAMs etc. It also lets me see my worst case paths graphically, (rubberband style) overlaid on the floorplan, one at a time, sorted by timing spec, then worst case first. This makes troubleshooting missed timing specs much easier. I have bitched to Xilinx about this. The 'inability of M1.5 to see what's RLOCed' problem has been submitted to the developers, for whatever that's worth. Ray Andraka <no_spam_randraka@ids.net> wrote: > > >> Anyone else out there consider floorplanner as indespensible as I do? Dave Decker Diablo Research Co. LLC Please use only one 'h' in mush. I'm trying to reduce the spam. "Animals . . . are not brethren they are not underlings; they are other nations, caught with ourselves in the net of life and time, fellow prisoners of the splendor and travail of the earth." Henry Beston - The Outermost HouseArticle: 12716
"Looking for love in all the wrong places?" ??? It doesn't take Einstein to
know that the hardware design newsgroups AREN'T the place to "look for love"!
I'd hate to guess what they'd look like if they were the place for romance...
VDHL User Seeks Verilog User for long walks on the beach, quiet nights
together cuddling, and shared X-terminal ports to the same server.
<shudder!>
- John Cooley
Part Time EDA Consumer Advocate
Full Time ASIC, FPGA & EDA Design Consultant
============================================================================
Trapped trying to figure out a Synopsys bug? Want to hear how 6000+ other
users dealt with it ? Then join the E-Mail Synopsys Users Group (ESNUG)!
!!! "It's not a BUG, jcooley@world.std.com
/o o\ / it's a FEATURE!" (508) 429-4357
( > )
\ - / - John Cooley, EDA & ASIC Design Consultant in Synopsys,
_] [_ Verilog, VHDL and numerous Design Methodologies.
Holliston Poor Farm, P.O. Box 6222, Holliston, MA 01746-6222
Legal Disclaimer: "As always, anything said here is only opinion."
<cyber_hearts@hotmail.com> wrote:
>
>Have I got an interesting Deal and Page for you to check out...
>
>There is a page up that will Blow your mind.... If you are looking for that
> special someone that you don't have any idea where they might be or never
>met them yet? Well it is your Lucky Day.. This Home Page "Cyber-Hearts"
>will take you to that special someone you been looking for....
>
>All you have to do is goto the page listed below and take a small trip
>to Babe/Hunk Land and search for that special someone you been waiting
>for, for a very very long time...
>
>So what are you waiting for, Time is wasting and someone else could have
>gotten your Babe/Hunk by now so you better get going and check it out.
>
>http://www.web-team.com/cyber-hearts
>
>
Article: 12717jcooley@world.std.com (John Cooley) wrote: >"Looking for love in all the wrong places?" ??? It doesn't take Einstein to >know that the hardware design newsgroups AREN'T the place to "look for love"! John, it is possible that they are following the same logic as the shoe salesman who goes to this really poor sub-Saharan country and emails back to say "we have a huge market here, no one is wearing shoes". muzo WDM & NT Kernel Driver Development Consulting <muzok@pacbell.net>Article: 12718
Stack machine lover looking for female with superior dual stack architecture. Must be into serious pushing and poping. Registered users need not apply. Simon ========================================================== jcooley@world.std.com (John Cooley) wrote: >"Looking for love in all the wrong places?" ??? It doesn't take Einstein to >know that the hardware design newsgroups AREN'T the place to "look for love"! > >I'd hate to guess what they'd look like if they were the place for romance... > > VDHL User Seeks Verilog User for long walks on the beach, quiet nights > together cuddling, and shared X-terminal ports to the same server. > ><shudder!> > - John Cooley > Part Time EDA Consumer Advocate > Full Time ASIC, FPGA & EDA Design Consultant > >============================================================================ > Trapped trying to figure out a Synopsys bug? Want to hear how 6000+ other > users dealt with it ? Then join the E-Mail Synopsys Users Group (ESNUG)! > > !!! "It's not a BUG, jcooley@world.std.com > /o o\ / it's a FEATURE!" (508) 429-4357 > ( > ) > \ - / - John Cooley, EDA & ASIC Design Consultant in Synopsys, > _] [_ Verilog, VHDL and numerous Design Methodologies. > > Holliston Poor Farm, P.O. Box 6222, Holliston, MA 01746-6222 > Legal Disclaimer: "As always, anything said here is only opinion." > > ><cyber_hearts@hotmail.com> wrote: >> >>Have I got an interesting Deal and Page for you to check out... >> >>There is a page up that will Blow your mind.... If you are looking for that >> special someone that you don't have any idea where they might be or never >>met them yet? Well it is your Lucky Day.. This Home Page "Cyber-Hearts" >>will take you to that special someone you been looking for.... >> >>All you have to do is goto the page listed below and take a small trip >>to Babe/Hunk Land and search for that special someone you been waiting >>for, for a very very long time... >> >>So what are you waiting for, Time is wasting and someone else could have >>gotten your Babe/Hunk by now so you better get going and check it out. >> >>http://www.web-team.com/cyber-hearts >> >> > > Design Your Own MicroProcessor(tm) http://www.tefbbs.com/spacetime/index.htmArticle: 12719
Thomas,
I am using a Cypress clock PLL chip in a recent design that may fit your
need as well. It's the Cy7B991-2JC
(http://www.cypress.com/products/timi.html). There are several
performance grades available, with -2 being the least jittery.
Ciao,
Alex
--
Alex I. Leyn, P.Eng., [aleyn@coreal.com, aleyn@pixstream.com]
Thomas Dölle wrote in message <361DD1B3.4EFC8575@fb.sony.de>...
>Hi,
>
>I'm looking for high speed (up to 80 MHz input) clock divider chips
with
>
>programmable ratio (1/2, 1/4, 1/8). The outputs should be at CLK and
>CLK/X with low skew (100 - 1000ps) and low jitter. The input is driven
>by a external clock source. Does anybody know whether there are chips
>commercially available?
Article: 12720In article <36313CC4.9FD3D096@yahoo.com>, Rickman <spamgoeshere4@yahoo.com> wrote: >Todd Kline wrote: >> >> If I care about the state encoding, I don't use enumerated types. I >> use three different synthesis tools, two different simulators, and >> target FPGA's and ASIC's. Just the differences in '87 and '93 are >> enough to drive me nuts. I stay away from all tool specific constructs. >> For portability, I prefer the following structure: >> >> ... >> >> signal grants: std_logic_vector(3 downto 0); >> constant NO_GRANTS: std_logic_vector(3 downto 0) := "0001"; >> constant VIDEO_GRANT: std_logic_vector(3 downto 0) := "0010"; >> constant AUDIO_GRANT: std_logic_vector(3 downto 0) := "0100"; >> constant CPU_GRANT: std_logic_vector(3 downto 0) := "1000"; >> >> ... >> variable next_grant: std_logic_vector(3 downto 0); >> ... >> >> case grants is >> when VIDEO_GRANT => >> ... >> if(expression) then >> next_grant := VIDEO_GRANT; >> else >> next_grant := NO_GRANTS; >> end if; >> ... >> when AUDIO_GRANT => >> ... >> when CPU_GRANT => >> ... >> when others => -- NO_GRANTS case >> ... >> end case; >> >> Of course, if the case statement is inside a clk'event, you don't need >> the variable. > >Todd, > >This was exactly the type of code I wrote in my first attempt to use >VHDL to build a state machine. I did not trust the FPGA tools (too many >bad experiences in the past) to do what I wanted using the methods I >read in the VHDL books. The problem was that the synthesizer did not >know that to detect state "VIDEO_GRANT" it only needed a single input. >It would use all N state variables as the input for each condition in >the case (state_variable == "0001" rather than just state_variable(0) == >'1'). The point of using one-hot encoding is to minimize the number of >signals needed to decode a given state. At least with my synthesis tool, >Metamor, it produced a very poor implementation. > >I fourn that I could work around this by getting rid of the case >statement and coding up each FF separately as someone posted earlier. >But that created a lot more work and is not as clear to read as a case >statement. But I can see where your tools and targets might not let you >do otherwise. > >Have you ever looked at the logic produced by the above type of code? Is >it smart enough to figure out that it only needs to look at one bit to >determine each state? > > >-- > >Rick Collins > >redsp@XYusa.net > >remove the XY to email me. Just a comment to re-enforce Rick's statement. I learned verilog and Synopsys DC Compiler at the same time while doing my first FPGA. My examples to state machine design were given to me by another team who had just finished an ASIC. They were lovely. Easy to read and easy to modify and slow as hell in a Xilinx part. What I learned is that wide decodes are a real problem in a coarse-grain FPGA architecture. I then went an looked at Synopsys examples for one-hot state machines using compiler directives and enumerated states. One minor problem. A nice thing about one hot state machines is that you identify a state with just a few i.e. one or two state bits. Synopsys only supports very archane ways to make the one-hot state bits visible outside of the state machine and then recommends against using those methods. I've gone to explicit F/F state machines, but they are a serious pain to modify, because the state information is distributed, difficult to extract, there is no checking being done by the synthesizer. However, there is another thing. I don't really build one-hots, because it takes as much decoding to shut off the previous state as it does to turn on the next state except that one or the other must be inverted. And, of course, if one state goes to a number of possible states then it becomes the decode problem instead of the next state. TANSTAAFL, Dan Jones As time has gone on, I haveArticle: 12721
"Glenn E. Hunt" <glennee@flash.net> writes: > This *is* an interesting thread ... and I wonder if anyone else shares the > following experience. > > I like HDLs because I find it is usually faster to produce a final result > (for all but trivial design leafs) and allows me to construct and express > control conditions without then having to go through the step of translating > into a gate structure. This speed advantage is usually due to the shorter > redesign time when design misbehaviors (my euphemism for bugs) are > encountered. A textual language is indeed better than a schematic full of *very* low level interconnected blocks (a.k.a. logic gates) when it comes to describing behaviour. Especially if this language is fully targeted towards the type of behaviour to describe (combinatorial logic needs a different language than an FSM). > I like schematics because (most of the time, IMO) they provide a clearer > view of design structure and hierarchy. All the HDL code I've seen > (including the code I've written, which is not much) tends to obscure the > hierarchical relationships; that is, it's difficult for me to follow which > blocks connect where with what signals. This is especially true for designs > with lots of blocks, lots of hierarchy, and/or blocks with high port counts. > The listings get so long, I sometimes have to "page down" two times before I > get to the end of the port listing for a single block instantiation. In > other words, I can't see enough at once to follow or figure out the design > structure. The information density is much higher in a schematic diagram > than a code listing. I agree again, although schematics easily become cluttered if too many communication channels are drawn. Our tool (see below) hides control and test channels, to that only a 'pure' datapath remains. > One design team I know of got so frustrated with its inability to comprehend > the hierarchical structure of a device's HDL that they recast the design > into a top-level schematic of "black boxes" and put the HDL implementation > code under those, a technique that can obviously be extended as deeply into > a hierarchy as one desired. I think that's not much more than a 'hack'. It works, but it's not optimal. > My desire is for some way to make HDL code as comprehensible as schematics. > One possible help is an editor that allows an outline mode, like what is > available in word processors (the Transputer code development tools work > this way), to allow collapsing of structure so that modules are listed at > the same level of indentation, but that still does not show what is > connected to what. Better is something like the hierarchical architectural > view provided by Synplicity (I don't know if other tools have this) but the > "information density" there is still a little too low, and Synplicity's > net-naming convention is, well, obscure. In MS-Word, I use outlining a lot and I like it - for writing normal texts like reports or manuals. I used the Transputer tools, and there it did not really help me - nothing beats a schematic to show structure. I don't know Synplicity, but our tool allows schematics to be (re-)used in a hierarchy. > Having said that, it also seems to me that what we as hardware designers are > doing is thinking like schematic designers when we write our HDL. I'm > starting to think this is not the best way to go about writing HDL. Rather > than focus on tools, maybe we could gain improved clarity by changing the > way we think about the structure or partitioning of designs. Can we devise > a design analysis/partition/capture technique or method that highlights or > exposes rather than obscures the relationships of HDL hierarchy? IMHO, I think we have got one such method. > Is the > hybrid schematic-for-higher-levels with HDL underneath good enough? Don't think so. Languages like VHDL try to describe everything with a single procedural language like syntax - requiring designers to write (and think) far too much. Our tool is more abstract than straight HDL, but it can automatically convert a design into VHDL or Verilog (although the latter one is not fully debugged yet - have to finish the rulebase). > Does > the nature of the underlying hardware implementation preclude or hinder > this? (Since structure is imposed by the designer primarily, though not > always entirely, for the conceptual benefit it provides, I suspect it does > not.) We get very good results when synthesizing our converted designs. Even the very rough timing predictions done with our tool provide a good hint/pointer of where a design can be improved timing-wise even before synthesis. > Does anyone else have this difficulty? Does anyone know of anything like > this offered or planned by anyone? Am I out in the woods here? OK, have a look at: http://www.eb.ele.tue.nl/proj/idassfly.html Which describes our 'Interactive Design and Simulation System' tool, and how to get it for free. BTW: above the things you wanted, this tool also simulates *while* designing. BTW2: an MS-windows/Linux version based on Visualworks Smalltalk (Non-Commercial) is underway... > Looking for insight, > Glenn > > PS: > I, too, have a cents-less keyboard, and have found them to be that way for > years. Sorry, like Mel Brooks, I am unable to pass up the obvious joke, > even when I'm sure others have seen it before me. :-} > I find schematics useful for certain low-level functions and necessary for > some timing-critical functions which I don't yet trust a synthesis tool to > do properly. Since synthesis tools provide for netlist instantiation of > user-defined inviolable elements (sort of user-defined primitives or library > macros), I am able to indulge this preference when I prefer, making the > underlying implementation of the black box a schematic-based netlist or a > vendor-targeted structural HDL-based netlist. Both are equally unportable, > which is something I don't recall seen being brought up, though it may have > been earlier in the thread. And may not be as important to FPGA targeted > designs. OTOH, FPGAs sometimes migrate to gate arrays or ASICs, sooo... WRT portability of designs created with our tool: converting designs into 'standard' HDL's is done under control of rulebases. This allows us to put a lot of 'intelligence' into the conversion and also to target specific 'dialects' of an HDL. Our Compass VHDL rulebase not only generates the main VHDL file, but also control files to build macrocells (including ROM contents templates). Greetinx and have fun, Ad -- --(dr.ir.) Ad (A.C.) Verschueren-------------------A.C.Verschueren@ele.tue.nl-- Eindhoven University of Technology -- Information and Communication Systems Smail: Room EH 9.27 ----- P.O. Box 513 ---- 5600 MB Eindhoven, Netherlands Voice: +31-40-2473397 FAX: +31-40-2433066 [corner for rent, apply within]Article: 12722
In article <70q6i4$40m$1@excalibur.flash.net>, "Glenn E. Hunt" <glennee@flash.net> writes > snip... > >Having said that, it also seems to me that what we as hardware designers are >doing is thinking like schematic designers when we write our HDL. I'm >starting to think this is not the best way to go about writing HDL. Rather >than focus on tools, maybe we could gain improved clarity by changing the >way we think about the structure or partitioning of designs. Can we devise >a design analysis/partition/capture technique or method that highlights or >exposes rather than obscures the relationships of HDL hierarchy? Is the >hybrid schematic-for-higher-levels with HDL underneath good enough? Does >the nature of the underlying hardware implementation preclude or hinder >this? (Since structure is imposed by the designer primarily, though not >always entirely, for the conceptual benefit it provides, I suspect it does >not.) Your ideas about a mixed schematic/HDL environment hit, what I feel is, a very important point. HDL's are very effective for expressing intent in terms of isolated bubbles of functionality. They are poor in expressing the connectivity between these bubbles. Whilst schematics are a way forward the current pin based mechanism does not scale well with size. You cannot easily express association between signals and they rarely show any form of data flow. Also thought of having to connect up 300+ I/O signals at the top level makes me shudder, all that routing, moving, parallel lines to follow... Solving the limitations of pin based schematics and allowing the implimentation to be entered in what ever form the designer feels is appropriate, for me is a good idea. Being able to capture the hierarchy graphically and then pushing into a leaf block launches the appropriate tool for the job would be very useful. > >Does anyone else have this difficulty? Does anyone know of anything like >this offered or planned by anyone? Am I out in the woods here? > > There is a tool being developed which is aimed at addressing some/all of these issues. Contact be directly if interested. Steve...Article: 12723
Ray Andraka <no_spam_randraka@ids.net> writes:
[binary->gray conversion]
> Problem with converting like this is you wind up with glitches
> because more than one register is changing at a time. Kind of
> misses the point of using gray code in the first place.
Unless of course you are able to control the skew during conversion
but not when you distribute the codeword. In that case it makes sense
to convert if it's easier to do (read less CLB, pre-placed macro).
Glitches are not necessarily bad as long as you can keep them
controlled in a very small part of your circuit.
Achim Gratz.
--+<[ It's the small pleasures that make life so miserable. ]>+--
WWW: http://www.inf.tu-dresden.de/~ag7/{english/}
E-Mail: gratz@ite.inf.tu-dresden.de
Phone: +49 351 463 - 8325
Article: 12724Pak Khong wrote: > Check out www.silicon-systems.com > or have a look at this which is free : http://www.geocities.com/SiliconValley/Grid/6044/Ved.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