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
> >> >> > Try doing a functional simulation....I believe the underlying > >> >simulation > >> >> > libraries are not there.... > >> >> > >> >> >>I believe that is because the Virtex timing files were not in place > >> >when they > >> >> shipped F1.5 however, the timing models are coming. > >> > > >> >That was the point. The FAEs said that Xilinx has NO plans on providing > >> >these, or supporting ANY schematic tools for Virtex. > >> > >> I do not understand how anyone would make a big deal about this. > >> Mentor Graphics uses vhdl models to simulate their schematic > >> capture tool and it works great. > > > >Then you don't understand what the problem is. If you did, then you'd > > I remember you. You are the guy who claims viewsim supports concurrency > because you can generate a clock signal right? Something tells me you 1) don't understand what you really mean by concurency, and 2) how one can easily do what it is you were claiming one can't do in Viewsim. > You are also the guy who does not know what a vhdl testbench is, probably the > only person n this newsgroup. Funny, I guess for all the designs I've done, and used 'test benches' for, I just blindly poked at the keys (and nudged my mouse), and by magic, my designs work (er, once simulated, debugged and timed), are shipping in thousands upon thousands, without any problems....and I did ALL that by dumb luck! Gee, Rita, how many designs do YOU have shipping in REAL products? Hum? AustinArticle: 12651
Interesting thread you guys have going here. My $0.02 worth (Wow! I finally realized there is no "cents" character on my keyboard - that only took 15 years of keyboard pecking... :) 1. The better FPGA HDL tools are just recently getting to the point where you can wring out a decent, medium performance design entirely in HDL. Witness a statement in EE Times by Stephen Wasson at Highgate Design (guys who did Xilinx PCI core - we used them before for other stuff) who said he might actually start using the VHDL tools once Synplicity got their next release of tools out (it allows you to guide the architectural mapping in some ways I don't recall). 2. It's interesting to see (at times) that the software guys think pictures will be their saviors (e.g. Labview, Rational Rose, Software through Pictures, some DSP tools, etc.) and the hardware guys think that languages will be their saviors (various HDLs). To me, I think that a picture is worth a thousand words, AND vice versa, depending on the context it's used in. Having spent a fair bit of time in system design (radar systems and such), I prefer the top level in pictures with some words around it. As I go down through the heirarchy, pictures or text are used as appropriate. For instance, a state machine is easier for me to comprehend as a diagram. But there are times when an HDL (or pseudocode) conveys the meaning better (in an algorithm description, for example). Or maybe a schematic gives a higher performance result. The bottom line is that, if you view the choice of HDL vs. schematics vs. state diagrams vs ... as a religious choice one must make, then sooner or later there will be a downside. Hopefully we can convince the tool vendors that we'd like to slide back and forth between all these modes of description as seemlessly as possible, and WE decide what's appropriate. Regards, Rick ps. as to somebody's comment in a later thread about just making the algorithm more efficient (instead of it's implementation). If you do "hard" stuff, you typically have to do both. I'm very good at efficient algorithms (you try and figure out how to resample 3 billion 1 bit data elements per second on a 300 Mhz. Alpha...), yet I still seem to end up looking at CLBs and checking prop delays and doing the low level mapping so I can get this 1 critical piece of the design to work.Article: 12652
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
C A L L F O R P A R T I C I P A T I O N
6th Reconfigurable Architectures Workshop (RAW '99)
April 12, 1999, San Juan, Puerto Rico
http://maarc.usc.edu/~raw99
to be held in conjunction with
13th International Parallel Processing Symposium (IPPS '99)
and 10th Symposium on Parallel and Distributed Processing (SPDP '99)
(Sponsored by IEEE Technical Committee on Parallel Processing)
http://www.ippsxx.org/
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
The 6th Reconfigurable Architectures Workshop (RAW '99) will be held
in San Juan, Puerto Rico on April 12, 1999. RAW '99 is associated with
the Second Merged Symposium of the 13th International Parallel
Processing
Symposium and the 10th Symposium on Parallel and Distributed Processing
(IPPS/SPDP 1999). RAW '99 is one of the major meetings for
researchers to present ideas, results, and on-going research on both
theoretical and industrial/practical advances in Reconfigurable
Computing.
Goal of the Workshop: Bridging Theory and Practice
Advances in semiconductor and networking technologies have created
opportunities for new and effective computing paradigms. Reconfigurable
computing is one paradigm that has been the focus of both theoretical
analysis and industrial development over the last decade.
On the theoretical side, the use of configurable communication media
(e.g., a reconfigurable bus system) allowed the development of
solutions for several classes of problems with running times that
are superior to those achieved by traditional parallel models using
similar resources. A large body of knowledge has been generated as a
result of this research.
On the industrial/practical side, devices and systems that support
various modes of reconfiguration (e.g., custom, dynamic, and
self-configurable) have been developed. Several compute intensive,
critical applications have been demonstrated on such systems.
System design, application mapping and development of generic techniques
and tools are also currently active areas of research.
The need for interaction and exchange between the theoretical and the
practical sides, which is the focus of the 6th Reconfigurable
Architectures Workshop, is more important than ever at this junction
in the development of both areas.
Submitting Papers
Authors are invited to submit manuscripts of original unpublished
research in all areas of reconfigurable computing (devices, systems,
algorithms, software tools and applications). The topics of
interest include, but are not limited to:
+ Reconfigurable Computing
- Models
- Algorithms and Complexity
- Fault Tolerance Issues
+ Programmable Logic Devices and Systems
- Architectures of Reconfigurable Systems
- Implementations
- Adaptable Systems
- Evolvable Hardware
+ Development Tools and Methods
- High-level Development Support
- Compilation Techniques
- CAD Tools
+ Applications
- Mapping of Parallel Algorithms
- Image Processing, Arithmetic/Geometric/Graph/Randomized Algorithms
- Industrial Applications and Experiences
A panel on "The Future of Reconfigurable Computing: Issues and
Non-Issues"
will be chaired by Ranga R. Vemuri, University of Cincinnati (USA).
Submission Guidelines
Authors should submit an electronic version of their work for
review to "hossam@cs.newcastle.edu.au". All manuscripts will be
reviewed. Submissions may be a summary of the work or a complete
manuscript (not to exceed 10 pages of single spaced text, including
figures and tables). Submissions should be in Postscript (level 2)
format. Authors should make sure that the submission can be viewed
using ghostscript and will print on a Postscript printer that uses
standard letter size paper(8.5" x 11"). Submissions must be received
by October 30, 1998.
The workshop proceedings will be published by Springer Verlag as part
of their Lecture Notes in Computer Science Series, and they will also
appear in the CD-ROM version of the IPPS/SPDP '99 Proceedings.
Important Dates
- Manuscript due October 30, 1998.
- Notification of acceptance or rejection due December 15, 1998.
- Final version due January 31, 1999.
Workshop Chair: Viktor K. Prasanna, University of Southern California
(USA)
prasanna@ganges.usc.edu
Program Chair: Hossam ElGindy, University of Newcastle (Australia)
hossam@cs.newcastle.edu.au
Hossam ElGindy
Dept. of Electrical and Computer Engineering
The University of Newcastle
Callaghan, NSW 2308
Australia
Program Committee
- Jeff Arnold, Independent Consultant (USA)
- Michael Butts, Quickturn Design Systems, Inc. (USA)
- Bernard Courtois, Laboratory TIMA, Grenoble (France)
- Carl Ebeling, Univ. of Washington (USA)
- Reiner Hartenstein, Univ. of Kaiserslautern (Germany)
- Brad Hutchings, Brigham Young Univ. (USA)
- Hyoung Joong Kim, Kangwon National Univ. (Korea)
- Fabrizio Lombardi, Northeastern University (USA)
- Wayne Luk, Imperial College (UK)
- Patrick Lysaght, Univ. of Strathclyde (Scotland)
- William H. Mangione-Smith, Univ. of California, Los Angeles (USA)
- Malgorzata Marek-Sadowska, Univ. of California, Santa Barbara (USA)
- Margaret Martonosi, Princeton Univ. (USA)
- John T. McHenry, National Security Agency (USA)
- Alessandro Mei, Univ. of Trento (Italy)
- Martin Middendorf, Univ. of Karlsruhe (TH) (Germany)
- George Milne, Univ. of South Australia (Australia)
- Koji Nakano, Nagoya Institute of Technology (Japan)
- Stephan Olariu, Old Dominion Univ. (USA)
- Robert Parker, Information Sciences Institute East/USC (USA)
- Jonathan Rose, Univ. of Toronto (Canada)
- Hartmut Schmeck, Univ. of Karlsruhe (TH) (Germany)
- Herman Schmit, Carnegie Mellon Univ. (USA)
- Mark Shand, Compaq Systems Research Center. (USA)
- Jerry L. Trahan, Louisiana State Univ. (USA)
- Ramachandran Vaidyanathan, Louisiana State Univ. (USA)
Publicity Chair: Kiran Bondalapati, University of Southern California
(USA)
kiran@usc.edu
Article: 12653Does anybudy know references on state assignment of FSMs for FPGA-based implementations?. In particular, I am aware of a paper proposing a symbol encoding with reduced dependencies for LUT FPGAs but I can not find it. Tnak you Maria JoseArticle: 12654
Hi, I'm now exploring a sine generator based on Taylor-Mac Laurin polynomial development of the sin(x) function. I try, of course, to have the best coefficients for the smallest degree of the polynom. Does anybody know how to evaluate the size of a circuit that computes this function ? I guess it's a problem linked to FIR filters but the powers of x. Thank you in advance and have the best day as possible, Yves.Article: 12655
mench@mench.com wrote: > It's not part of the language--it may be part of the standard > synthesis package. It will no doubt be part of the standard synthesis > subset. I also (cf Rick Collins) found that it worked with the Metamor compiler but it doesn't work with the Synopsis compiler supplied as part of Xilinx Foundation Express. Specifically if I use the code sequence type sm_type is (IDLE, ST1, ST2, ST3); attribute enum_encoding : string; attribute enum_encoding of sm_type : type is "one hot" the FExp compiler complains of a enum_encoding mismatch . Looking at the manual I found that it expects a string of N space separated binary values where N = number of states in sm_type. In this case N=4 and "one hot" has only 2 values. [93 vs 87 difference ?] Looking further I found that the State definitions had to be of the form xxxx where each x could be one of: 0,1 : obvious D : Don't care X : Unknown. with the proviso that any value with an `X' in it will compare FALSE to any vector. Great I thought I'll just define my state encoding as "1DDD D1DD DD1D DDD1". I ran the compiler again and this time I got a warning that comparisons with `D's' in them are ALSO taken as always FALSE. This is WRONG. After a lot of searching I finally found they'd hidden the correct one-hot optimisation on the 'options' menu of the $&^%£"! GUI - even less portable than the enum_encoding trick above. In fact its worse since the GUI flag is global so you have to use the enum stuff anyway for those SMs you want binary encoded. Anybody familiar with FPGA/Foundation Express care to comment. I suspect I could find some answers to this on the Synopsis web site but, as an indirect customer, I'm not allowed into the help section but have to go via Xilinx.Article: 12656
On 21 Oct 1998 16:17:12 GMT, mench@mench.com wrote: >Rickman <spamgoeshere4@yahoo.com> wrote: >> Rick Filipkiewicz wrote: >>> Rickman wrote: >>> > > > attribute enum_encoding : string; >>> > > > attribute enum_encoding of StateType : type is "one hot"; <snipped> >>> What I was asking is what can you do WITHIN the >>> language spec. if the ``one hot'' attribute statements are rejected or ignored >>> by the compiler/synthesiser. Maybe all known synthesisers DO accept this >>> construction ? I'll try it with Metamor (VHDL-93) & Synopsis (VHDL-87). >> I don't know if the attribute "one hot" is part of the standard or not. >> Maybe Paul could help us here. > >It's not part of the language--it may be part of the standard >synthesis package. It will no doubt be part of the standard synthesis >subset. it's not actually in 1076.6 either (i presume this is what you mean by the standard synthesis subset). 1076.6 does allow enum_encoding, but you can't explicitly specify "one hot"; you have to manually specify your state codings. i imagine that almost all synthesisers allow some way to specify a one-hot encoding, but the syntax does vary. exemplar's version is: -- declarations not needed if exemplar_1164 package is used type encoding_style is (BINARY, ONEHOT, GRAY, RANDOM); attribute TYPE_ENCODING_STYLE: encoding_style; type my_state_type is (...); attribute TYPE_ENCODING_STYLE of my_state_type:type is ONEHOT; however, there *is* one mechanism that doesn't rely on a user-defined attribute. if the synthesiser is clever enough, it will look through your state encodings, and realise that you're trying to generate a one-hot machine, and so will automatically do this for you (ie. it needs nothing more than the line: attribute ENUM_ENCODING of MY_TYPE:type is "100 010 001", or whatever). i believe than synplicity does this, but i don't know of anyone else who does. evanArticle: 12657
Well said. I too have been monitoring synthesis with an eye toward whether it will let me do the job. So, far it still doesn't really give me the control I need in many of my designs. It has however improved a bunch over the past year or so, with Leonardo Spectrum and Synplicity both becoming almost good enough. Now as far as choice goes once I have the control I want in an HDL...it depends on what I am doing. I find data path stuff easier to do and to follow in schematic form provided the schematics are done in such a way that changing widths is relatively painless, at least in the upper levels of the heirarchy. There are other things like controls and lower level sections of data path logic that are often better expressed in an HDL. ram wrote: -- -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: 12658
A different approach, that I believe will reduce the gate count is to use a direct digital synthesizer and a CORDIC rotator. The DDS generates phase angle information at the frequency set by the phase increment. That phase information is fed to the phase input of a CORDIC rotator in the rotation mode. The CORDIC magnitude input is set at the desired amplitude (reduced by the CORDIC gain). As outputs, you get a quadrature (sin & cos) sinusoid, whose amplitude can be modulated by changing the magnitude input (ie no extra hardware), and whose phase/frequency is easily modulated by changing the DDS pahse increment. The vector magnitude at the output is exact, less an accumulated truncation error of approx (log(i)) where i is the number of iterations, and with a phase accuracy dependent on the number of iterations. I've built CORDIC based NCOs in FPGAs that run in the 70M samples range in a -1 xilinx. For an introduction to CORDIC and some hints at implementation in an FPGA you might obtain a copy of my CORDIC survey paper from my website. If you look under the DSP/CORDIC page, you will also find a link to an on-line CORDIC bibliography. Yves Vandervennet wrote: > Hi, > > I'm now exploring a sine generator based on Taylor-Mac Laurin > polynomial development of the sin(x) function. I try, of course, to > have the best coefficients for the smallest degree of the polynom. > Does anybody know how to evaluate the size of a circuit that computes > this function ? I guess it's a problem linked to FIR filters but > the powers of x. > > Thank you in advance and have the best day as possible, > > Yves. -- -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: 12659
Richard Cant wrote: > but are the current generation of HDL's genuinely High level in the > sense that software HLL s are? No, as I myself said later; but.... > Speaking as a S/w person primarily > (but with a strong h/w interest and > involvement) current so-called highlevel HDL s are only high level in > places; elsewhere (particularly when timing/synchronisation is > involved) > they seem toi me to be more comparable to assembly language - maybe > even microcode! Hah! That's what softies always say when they are confronted with explicit parallelism! :-) yours deadlocked Jonathan BromleyArticle: 12660
Altera has an Application Brief (AB 131) "State Machine Encoding" http://www.altera.com/html/literature/lf10k.html It basically says that for architectures with lots of flip-flops use one-hot encoding (000, 001, 010, 100) because it's register intensive, but requires less decoding logic. For devices with lots of logic (isn't that what LUTs are?) use binary coding state machine (sequential: 000, 001, 010, 011, 100 etc, or Gray 000, 001, 011, 0010, 0110 etc.) that require less flip-flops, but more decode logic. Hope this helps. Victor Ma. Jose Avedillo de Juan wrote: > > Does anybudy know references on state assignment of FSMs for FPGA-based > implementations?. In particular, I am aware of a paper proposing a > symbol encoding with reduced dependencies for LUT FPGAs but I can not > find it. > > Tnak you > > Maria JoseArticle: 12661
ems@riverside-machines.com.NOSPAM wrote: > On 21 Oct 1998 16:17:12 GMT, mench@mench.com wrote: >>Rickman <spamgoeshere4@yahoo.com> wrote: >>> Rick Filipkiewicz wrote: >>>> Rickman wrote: >>>> > > > attribute enum_encoding : string; >>>> > > > attribute enum_encoding of StateType : type is "one hot"; > <snipped> >>>> What I was asking is what can you do WITHIN the >>>> language spec. if the ``one hot'' attribute statements are rejected or ignored >>>> by the compiler/synthesiser. Maybe all known synthesisers DO accept this >>>> construction ? I'll try it with Metamor (VHDL-93) & Synopsis (VHDL-87). >>> I don't know if the attribute "one hot" is part of the standard or not. >>> Maybe Paul could help us here. >> >>It's not part of the language--it may be part of the standard >>synthesis package. It will no doubt be part of the standard synthesis >>subset. > it's not actually in 1076.6 either (i presume this is what you mean by > the standard synthesis subset). 1076.6 does allow enum_encoding, but > you can't explicitly specify "one hot"; you have to manually specify > your state codings. I was actually trying to fuzz. I didn't necessarily mean 1076.6, Level 0. I was trying to include the (upcoming) Levels 1 and 2. Paul -- Paul Menchini | mench@mench.com | "Se tu sarai solo, Menchini & Associates | www.mench.com | tu sarai tutto tuo." P.O. Box 71767 | 919-479-1670[v] | -- Leonardo Da Vinci Durham, NC 27722-1767 | 919-479-1671[f] |Article: 12662
Ray Andraka wrote: > > Well said. I too have been monitoring synthesis with an eye toward whether it > will let me do the job. So, far it still doesn't really give me the control I > need in many of my designs. It has however improved a bunch over the past year > or so, with Leonardo Spectrum and Synplicity both becoming almost good enough. > Now as far as choice goes once I have the control I want in an HDL...it depends > on what I am doing. I find data path stuff easier to do and to follow in > schematic form provided the schematics are done in such a way that changing > widths is relatively painless, at least in the upper levels of the heirarchy. > There are other things like controls and lower level sections of data path logic > that are often better expressed in an HDL. > > ram wrote: I have been sitting on the sidelines watching most of this debate and thinking about my recent experience with VHDL. I found that I agreed a lot with both sides, but couldn't quite agree totally with anyone. Then I realized why. VHDL (as any other HDL) does remove you from having complete control over which gate is used where. Schematic seems to give you that control. But that is an illusion in both cases. In VHDL I completely control where FFs are generated because I know exactly the code that creates them. I choose to create a FF consciously by writing the VHDL code to produce it (or a whole bunch of them as in a register). The random logic (combinatorial) is then specified by various high level forms which allow me to think about the problem at hand and not the implementation. However, I am never completly sure how this will be implemented. So I dig into the implementation a few times until I learn the personality of my tool. Then I have learned a few rules about how my tools work and I can be quite expressive in my coding without being unsure about my implementation. So now I have a tool that allow me to concentrate mainly on the higher level constructs of my design while still having ENOUGH control over implementation for MOST purposes. On the other hand the perfect design control from schematics is somewhat illusory. If you are designing a Xilinx FPGA for example, you can place all the gates you wish. But these gates have to be mapped into 4 input function generators. The Xilinx backend tools will "optimize" your design and then partition it into LUTs so that what you end up with will only resemble your schematic in a functional way. You still can't control the mapping and optimization without a great deal of work using F-MAP elements and KEEP attibutes. In all but the MOST speed or space critical designs this is not warrented or practical. I remember when I started using Xilinx tools I was very frustrated with the poor job the tools did mapping my design to LUTs. So I made a logic block which was a 4 input LUT with a parameter to define the logic inside. Then I could acutally design my logic with 4 input LUTs. No one else thought this was a good idea and Viewlogic even dropped the feature which made this possible. It may have made for a great deal of control over my design implementation, but it also required a lot of work to do my own mapping. So I currently design with a combination of schematic and VHDL using each where I feel it will allow me to do the best and fasted job of optimal design. But I feel it would be a rare case where I would need to use strictly schematic. It would also be unusual for me to do the entire design in VHDL. Sorry for the long post. -- Rick Collins redsp@XYusa.net remove the XY to email me.Article: 12663
On Thu, 22 Oct 1998 10:42:15 +0100, Rick Filipkiewicz <rick@algor.co.uk> wrote: >mench@mench.com wrote: > >> It's not part of the language--it may be part of the standard >> synthesis package. It will no doubt be part of the standard synthesis >> subset. > >I also (cf Rick Collins) found that it worked with the Metamor compiler but it >doesn't work with the Synopsis compiler supplied as part of Xilinx Foundation >Express. Specifically if I use the code >sequence > >type sm_type is (IDLE, ST1, ST2, ST3); >attribute enum_encoding : string; >attribute enum_encoding of sm_type : type is "one hot" FPGA express doesn't seem to be particularly good at this. it does have a one-hot attribute, but you have to specify a *list* of signals, when you know that only one of the signals will be active at a given time (you can also specify one-cold, when you know that only one signal is 0 at a given time). example: use synopsys.attributes.all; -- attribute one_hot: string; -- in package 'attributes' attribute one_hot of red, green, blue: signal is "true"; this will allow combinatorial logic on red, green, and blue to be simplified appropriately. there doesn't seem to be any way to specify one hot on a *single* signal of an enumerated type. in principle, you could explicitly list all the signals in your state register, instead of using an enumerated type, but i haven't tried this (and i suspect that it won't work - it should be in the documentation if it does work). > the FExp compiler complains of a enum_encoding mismatch . Looking at the manual I > found that it expects a string of N space separated binary values where N = number > of states in sm_type. In this case N=4 and "one hot" has only 2 values. [93 vs 87 > difference ?] this isn't an 87/93 issue - enum_encoding and one_hot, if they exist, are user-defined attributes, and it just happens that synopsys doesn't recognise "one hot" as part of its enum_encoding scheme. evanArticle: 12664
There is a portable way to do one-hot encoding. It sounds ugly, but
actually works out really well--just declare a single flop for each state.
Here's an example. (Note that the starting state, State1, is coded active
LOW, the others are coded active high. I do this because FPGAs tend to
prefer that flops be zero at startup.)
architecture rtl of StateMachine is
signal State1, State2, State3 : std_logic;
begin
process (reset, clk)
begin
-- Sequential part
if State1 = '0' then
-- Outputs in state 1
end if;
if State2 = '1' then
-- Outputs in state 2
end if;
if State3 = '1' then
-- Outputs in state 3
end if;
-- Clocked part
if Reset = '1' then
State1 <= '0';
State2 <= '0';
State3 <= '0';
elsif clk'event and clk = '1' then
if (Expression describing transition to State1)
or (State1 = '0' and not (Expression describing exit from
State1))
then
State1 <= '0'
else
State1 <= '1';
end if;
if (Expression describing transition to State2)
or (State2 = '1' and not (Expression describing exit from
State2))
then
State2 <= '1'
else
State2 <= '0';
end if;
if (Expression describing transition to State3)
or (State3 = '1' and not (Expression describing exit from
State3))
then
State3 <= '1'
else
State3 <= '0';
end if;
end if;
end process;
end;
In practice, the state transition expressions tend to be much simpler than
in the general example. For instance, in most of my state machines, most
of the states happen sequentially -- i.e., State1 is the idle state, State2
is entered by a "Start" signal, and State3 immediately follows State2. In
this case, the transition code is simply:
State1 <= not (State3 or (not State1 and Start));
State2 <= not State1 and Start;
State3 <= State2;
I hope that this helps.
> >It's not part of the language--it may be part of the standard
> >synthesis package. It will no doubt be part of the standard synthesis
> >subset.
>
> it's not actually in 1076.6 either (i presume this is what you mean by
> the standard synthesis subset). 1076.6 does allow enum_encoding, but
> you can't explicitly specify "one hot"; you have to manually specify
> your state codings.
>
> i imagine that almost all synthesisers allow some way to specify a
> one-hot encoding, but the syntax does vary. exemplar's version is:
Article: 12665Ray Andraka wrote: > Depends on the desired phase resolution and magnitude accuracy. For > small numbers of phase angles (<32) when only sin or cos (not both) are > needed, use the LUT approach. Otherwise, use a CORDIC rotator. You > will want to read my FPGA'98 paper entitled "A survey of CORDIC > algorithms for FPGA based computers", which you can obtain from my > website. One of the designs discussed in the paper simultaneously > generates 12 bit sines and cosines at 50M samples/sec in a 4013E-2. The > CORDIC design also gives you the capability to amplitude modulate the > sin/cos outputs for free. The size of a CORDIC rotator is about the > same as a multiplier with as many bits. I've done numerous CORDIC > designs in Xilinx, Altera and Atmel FPGAs. > > The newest paper on my web-site, "An FPGA based processor yields a real > time high fidelity radar environment simulator", shows a CORDIC rotator > used as a complex NCO with amplitude and phase modulation. > Some of my students build a sine-wave generator design that uses LUT's (256 points, 8b width) , it's run with about 160 MHz (4010XL-3). The problem we got so far is pad-speed-limitation. So my guess is, LUT-based solutions are the fastes around. If you do have enough CLBs, why bother with slow-mode designs? HagenArticle: 12666
madaan@my-dejanews.com wrote: > Hi, > I am working on a I2C synthesizable core, simulation models and bus monitor in > verilog. Anyone aware of any shareware/freeware source (preferably in verilog) > or other related stuff at any site then please let me know. > > -- > Ashok Madaan > I2C is very easy (about 20 CLBs) to implement as long as you don't care about possible erros (spike, glitches..., timeouts). Things getting worser if you start detecting erros. Some things to remind: - oversampling - synchronizing - edge-detection - low-pass-filtering (if you dont't want glitches) - 3-state output vs. 3 outputs - interrupt generation - .... Implementing these options makes the design more complex, so if one is given away his i2c-model for free, look what you realy got!! We have (of course) build a i2c-model which detect nearby the most of the thinkable erros. You can enable most of the feature, depending on if you want a small (but insecure) or a bigger design. HagenArticle: 12667
*Very small* 4bit controller at: http://www-md.e-technik.uni-rostock.de/forschung/run4/index.html HagenArticle: 12668
Christof Paar wrote: <snip> > > Check also Jens-Peter Kaps' MS thesis which is on the web too. Hmmm, just a abstract mayby you can mail me the thesis.. HagenArticle: 12669
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: 12670In article <362F22EE.4856D7D6@brookes.ac.uk>, Jonathan Bromley <jsebromley@brookes.ac.uk> writes >No, as I myself said later; but.... > >> Speaking as a S/w person primarily >> (but with a strong h/w interest and >> involvement) current so-called highlevel HDL s are only high level in >> places; elsewhere (particularly when timing/synchronisation is >> involved) >> they seem toi me to be more comparable to assembly language - maybe >> even microcode! > >Hah! That's what softies always say when they are confronted >with explicit parallelism! :-) Explicit parallelism is inherently low level - what we need is Implicit parallelism!? :-) Seriously though it is not the parallelism which makes it low level - but rather the way in which timing is handled. -- Richard CantArticle: 12671
People have been doing source control of dwgs for at least a hundred years (that I know of). No reason we can't do it with schematic files. Do it all the time for PC Boards. (No paper changes hands except for the check). Simon =================================================================================== Rick Filipkiewicz <rick@algor.co.uk> wrote: >Watching this seemingly eternal schematics vs. HDL argument I find myself, >typically, agreeing with both sides. Schematics for their intuitive nature, >at least for datapath stuff - state machines are more problematic. HDL for >speed of writing & modifying random logic. What wins it for me is that the >text nature of HDLs make them amenable to source code revision control, >difficult or impossible with schematics [Correct me if I'm wrong here]. Also >, using lots of instantiation, you can treat HDLs as text based schematics >but the reverse process is awkward. > > Design Your Own MicroProcessor(tm) http://www.tefbbs.com/spacetime/index.htmArticle: 12672
I think if you design a chip optimised to a specific language (I am a stack machine/FORTH fan) you can get compiler gains. (You allude to this). I think that the future of computing is chips optimised for languages. This is somewhat true now. With FPGAs to experiment with it will become very true in the future(2-3 years). Lisp chips, FORTH chips, Java chips, C chips, etc. With RAM based FPGAs its a new chip every second (more or less). Simon - see my sig at the bottom for processor design tools =========================================================== Richard Cant <richard@timezznospamzzhigh.demon.co.uk> wrote: >In article <362DB291.164EDD5@brookes.ac.uk>, Jonathan Bromley ><jsebromley@brookes.ac.uk> writes >>John L. Smith wrote: >>> Even SMs can be drawn clearly and in an easy to follow mannerwith a schematic, >>> at least one-hots. >><snip interesting stuff about making schematics look like state >>diagrams> >>> >>> Portability --> HDL >>> Performance --> Schematic >> >>Whilst I generally agree with most of what has been said, I can't fully >>accept the "performance->schematic" axiom. People used to say much the >>same about high-level languages and compilers. But then two things >>happened: >>(1) compilers got better at optimisation (much better!) > >>(2) folk began to recognise that the freedom of expression inherent in >> a high level language allowed them to implement sophisticated but >> hard-to-understand optimisations at a much higher level of >>abstraction > >That is a commonly held belief but IMHO it is an over simplification, >what actually happened was - > >1) The underlying processors had facilities added to aid the efficiency >of high level languages - things like h/w stacks, frame pointers etc >etc > >2) Language design itself got better making good compilers easier to >write and (more especially) easier to use. This is what made your (2) >possible. Fortran 1 is actually little better than assembler for coding >complex algorithms. > >Actually compilers still aren't that good at optimisation as such, but >the task has been made easier (or maybe less necessary) by changes in >their "operating environment". Many so called optimisations made by >current compilers are essentially get arounds for architectural features >like delayed branches that have themselves been added in the knowledge >that the compiler could handle them! > > >>For example: If you are searching a table and the only way you know how >>is >>to do a linear search, then assembler will win over a high-level >>language >>any day. But have you ever tried doing a hash table in assembler? Or >>a balanced binary tree? OK, it's possible, but using a HLL you get all >>the >>inherent performance improvement (some orders of magnitude, in some >>cases) >>of the more sophisticated technique, **with minimal risk of erroneous >>code**, >>whilst suffering only the ???20% performance hit of HLL-vs-assembler for >>the comparable algorithm. > >Only if you use a suitable HLL and most early HLL s weren't much good at >those kinds of task. >> >>Bottom line: >>The performance gain from using the right algorithm is often hugely >>greater >>than the performance gain from using an optimal implementation method. > >True >>If the right algorithm is hard to understand or difficult to implement, >>you >>are more likely to get it right by using the highest-level tools at your >>disposal. The performance cost of using such tools will be >>insignificant. > >but are the current generation of HDL's genuinely High level in the >sense that software HLL s are? > >Speaking as a S/w person primarily (but with a strong h/w interest and >involvement) current so-called highlevel HDL s are only high level in >places elsewhere (particularly when timing/synchronisation is involved) >they seem toi me to be more comparable to assembly language - maybe >even microcode! > >> >>Improvement (1) is just about beginning to happen (slowly) with HDLs. > >but does the FPGA cell design need to be bent to the requirements of >HDL's? (I'm working by analogy here - but I would be interested to know >if anyone has a "hard" answer to this question) >>Improvement (2) is really waiting for mainstream acceptance of higher >>levels of abstraction than RTL, so that we can code useful algorithms >>in our hardware. > >Yes! > >> Meanwhile, we are still fiddling around just like the >>early compiler users: the good designers will exploit HDL for its >>portability and parameterisability, whilst learning how to write HDL >>code >>that's synthesis-friendly so the performance stays OK. Mediocre >>designers will go on getting sub-optimal results as usual. And no, I >>don't know with any precision where I fall on that spectrum of >>design competence:-) > >Same as programmers! :¬) > >-- >Richard Cant Design Your Own MicroProcessor(tm) http://www.tefbbs.com/spacetime/index.htmArticle: 12673
Rickman wrote: > The random logic (combinatorial) is then specified by various high level > forms which allow me to think about the problem at hand and not the > implementation. However, I am never completly sure how this will be > implemented. So I dig into the implementation a few times until I learn > the personality of my tool. Then I have learned a few rules about how my > tools work and I can be quite expressive in my coding without being > unsure about my implementation. Until the next version is introduced and has subtle differences in the way it compiles the design. > > > On the other hand the perfect design control from schematics is somewhat > illusory. If you are designing a Xilinx FPGA for example, you can place > all the gates you wish. But these gates have to be mapped into 4 input > function generators. The Xilinx backend tools will "optimize" your > design and then partition it into LUTs so that what you end up with will > only resemble your schematic in a functional way. You still can't > control the mapping and optimization without a great deal of work using > F-MAP elements and KEEP attibutes. In all but the MOST speed or space > critical designs this is not warrented or practical. My schematics are highly hierarchical, with the lowest level of many arithmetic elements being either one or two bit slices. Those slices are where the fmaps are. Since I already have a library of those parts, I rarely need to add fmaps to the design (I do need RLOCs, but that's a no-brainer). This gives me a hierarchical design consisting of relatively placed macros which are optimized at the low levels. I know when I plunk these down that the logic will be implemented the way I intended without having to go in again and place fmaps. Even in cases where I don't already have a 1 or 2bit slice, it is trivial to create the slice and fmap it (usually no more than two fmaps). I rather suspect that I am getting more design reuse than many of the HDL proponents out there. -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: 12674
Steve Kerman wrote: > > There is a portable way to do one-hot encoding. It sounds ugly, but > actually works out really well--just declare a single flop for each state. > > Here's an example. (Note that the starting state, State1, is coded active > LOW, the others are coded active high. I do this because FPGAs tend to > prefer that flops be zero at startup.) > > architecture rtl of StateMachine is > signal State1, State2, State3 : std_logic; > begin > > process (reset, clk) > begin > > -- Sequential part > > if State1 = '0' then > -- Outputs in state 1 > end if; > > if State2 = '1' then > -- Outputs in state 2 > end if; > > if State3 = '1' then > -- Outputs in state 3 > end if; > > -- Clocked part > > if Reset = '1' then > State1 <= '0'; > State2 <= '0'; > State3 <= '0'; > elsif clk'event and clk = '1' then > > if (Expression describing transition to State1) > or (State1 = '0' and not (Expression describing exit from > State1)) ...snip... > then > State3 <= '1' > else > State3 <= '0'; > end if; > end if; > end process; > end; > > In practice, the state transition expressions tend to be much simpler than > in the general example. For instance, in most of my state machines, most > of the states happen sequentially -- i.e., State1 is the idle state, State2 > is entered by a "Start" signal, and State3 immediately follows State2. In > this case, the transition code is simply: > > State1 <= not (State3 or (not State1 and Start)); > State2 <= not State1 and Start; > State3 <= State2; > > I hope that this helps. I thought of this, but never tried it. This is indeed hard coded and is not easy to modify if you change your mind about your encoding method. The case statement method with an atribute defining the encoding type is much more flexible. A couple of my state machines in the design I just built could have gone over to being better in binary encoding if they had changed just a little more than they did during debug. Or it may be more likely that you would change from binary to onehot encoding in many cases where a state machine grows during debug. The amount of logic in a onehot machine depends on the number of states and inputs feeding into each state. Also each state has separate logic feeding it. In a binary encoded machine, the amount of logic depends on the number of bits in the encoded state and the number of inputs total. But there are fewer state bits than there are states in the onehot machine. So if you have a state like an IDLE state which many states feed into, plus many control inputs governing the output transistions, you can end up with a very complex set of logic that may well be bigger and slower than that of a binary state machine. So if the design changes during debug, you may want to change your encoding style. Of course there may be alternatives to changing your encoding style. For example the above worst case situation happened to me and I fixed it by adding a final dummy state which all of the previous end states fed. This dummy end state contained the complexity of the many states feeding it. The true IDLE state then only had a single state feeding it and could deal more easily with the complexity of the control inputs. Some of these inputs were from IO pins and had very long delays. So the speed of this circuit was critical. This worked out very well. But I am glad I did it in VHDL. Making all the changes in schematic would have been much slower than the typing I did, but then that is another discussion. ;^) -- Rick Collins redsp@XYusa.net remove the XY to email me.
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