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
John Kennedy wrote: > > I need some advice on how to implement a Bit-Serial multiplier using the > Xilinx Logicore Scaled By 1/2 Accumulator. I need to scale a 20 bit > signed 2's complement number. I am using XC4010 fpga to try to do some > digital audio signal processing, and need a compact (ok if slow) > multiplier. Any advice would be greatly appreciated. > > John For a fader with 0.6dB steps to 1% accuracy this reduces to two adders & some other bits - does this meet your requirements? Are you tied to a data stream format with most significant bit first? This significantly affects the complexity of the logic. Jan -- Murray Microft Logical design inside & outside chips +44-1703-909500Article: 13951
Big snip here. I'm extracting the parts I want to comment on. I don't think I've tossed too much context. > I never said that metastability does not exist. I have measured it. It does > exist, but the recovery delay from the metastable (=balanced) condition to the > ultimately stable state is so short in modern CMOS latches and flip-flops, that > the problem has lost most of its impact. > 1. A modern CMOS latch can go metastable, but recovers so fast that the problem > is, in most applications, irrelevant. ( see curves in the Xilinx data book, > page 13-49 ) I cringe when I see things like that, especially from people that I usually agree with. If the problem is "irrelevant" for "most applications", how do I tell if I'm working on one where it is relevant? I agree that it is easy to solve the metastability problem in many practical systems. You do have to understand the problem and you have to get data from the vendor. (or run your own tests) But the same processes that are speeding up the metastability recovery time constant are also speeding up everything else in FPGAs. Designers want to take advantage of that speed - they expect their designs to work with a fast clock. I think the key parameter is not the metastability recovery time constant alone, but the ratio of that time to the system clock time. If I have a system with enough time for multiple levels of logic then it is probably easy to cleanly process an asynchronous input - just leave out those levels of logic (and their routing) and you have enough time between a pairof FFs. But what if I'm running a heavily pipelined system where the system clock only leaves room for a timy bit of routing? Now there aren't any extra levels of logic to leave out. The classic FF-no-logic-FF synchronizer may not have a lot of leftover time. Note that designers pushing system clock speed are likely to jump on the next generation of faster chips as soon as they become available. That's before the metastability data becomes availability. Assuming that the metastability recovery time constant speeds up just like everything else seems like a good first guess but I don't see any reason to bet much on it. -- These are my opinions, not necessarily my employers.Article: 13952
Hi ppl! I need some general information about FPGA&MPGA, C-, I-, CI-tetsting. I don't need any technical specifications only common info. All links and URLs are welcome. plz email me them to sergeil@ttu.ee thnx.Article: 13953
Magnus Homann wrote: > "Bruce Nepple" <brucen@imagenation.extra.com> writes: > > > Yes Yes Yes. You got it! I challenge anyone here to come up with a gray > > code state machine that can reside in state A and conditionally branch to > > either state B or State C based on an async. input. > > I can't think of one. But you added yet another requirement to Peter's > list. With thse requirements, one should be safe. > > > "Having spent untold hours at analyzing and measuring metastable > > behavior, I can assure you that it is (today) a highly overrated > > problem. You can almost ignore it." > > Peter Alfke > > 12/28/98 > > Are you going to hold it to him? :-) > -- > 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.htmlArticle: 13954
This thread has provided the solution to a problem I've been working on for about 2 months. Many thanks to the insight provided by everybody here on the (rather more complex than first expected) subject of state machines. JohnArticle: 13955
Does anybody out there using the Leonardo tools know how to do
incremental compilation & linking.
i.e. I have a module foo with an instantiiated block-box called bar
definined in foo.v with the real bar module held in a separate file
called bar.v. What I want to do is compile & synth foo.v and bar.v
separately into EDIF files foo.edn & bar.edn and then link them. In
other words merge bar.edn into the correct place in foo.edn. This would
save a lot of time by not re-synthesising and re-optimising stable
pieces of the design.
Example:
*** in file foo.v ***
module foo (in0, in1, out, clk);
input in0, in1, clk;
output out;
wire sync_in0;
bar U0 (in0, sync_in0, clk); // Instantiate bar
assign out = in1 & sync_in0;
endmodule
/* Black-box definition of bar */
module bar (in, sync_in,clk);
input in, clk;
ouput sync_in;
endmodule
*** In bar.v ***
module (in, sync_in, clk);
input in, clk;
output sync_in
reg sync_in;
always @(posedge clk)
begin
sync_in = in;
end
endmodule
Article: 13956Actel recently published an article on DPLL's in an Actel FPGA. Unfortunately I can remember were I've seen it. I remember that the author was Steff Niewadomski (spelling?). Hans. Brett George wrote in message <367F428F.5641E93E@clarityeq.com>... >Hi all, > >Has anyone tried implementing a PLL in an FPGA (eg. ALTERA), we are >thinking of using it to reduce clock jitter from an externally generated >clock source.Article: 13957
perhaps this is what you're looking for ...
(From the June 1997 issue of Actel's "re.ACT" newsletter)
<snip marketing garbage>
iniADPLL is an all digital phase locked loop (ADPLL) core for applications
requiring
clock recovery, clock generation, and clock supervision functionality. iniADPLL
features
a maximum 10 ns jitter at 50 Mhz system clock, linear frequency range, infinite
frequency hold time, programmable center frequency, and programmable filter
characteristics. It comes as a structured, synthesizable VHDL model,
fully-synchronous
design that can be customized for special design requirements.
--------------------------------------------
Function: ADPLL
<snip sales info garbage>
All Digital Phase Locked Loop
Maximum 10ns jitter at 50MHz
Frequency range from 0 to n MHz
Infinite frequency hold time
Programmable center frequency
Programmable filter characteristics (cut-off frequency, loop gain)
Structured model description (SD)
Fully synchronous design
Adaptable phase detector
Scalable oscillator and loop filter
Customizable for special requirements
---------------------------------------------
... and perhaps this is not :-)
The Actel ES Family
<snip various other stuff>
-- ClockSync -- Multiple Digital Phase Locked Loops (DPLL) -- provides
balancing of multiple system clocks. Also enables effective clock-to-output
delays to be reduced from 7ns to 0ns.
---------------------------------------------
rk
and for all you wise-guys out there, do they use a gray-coded state machine to run
the thing?
===============================================================
Hans wrote:
> Actel recently published an article on DPLL's in an Actel FPGA. Unfortunately I
> can remember were I've seen it. I remember that the author was Steff
> Niewadomski (spelling?).
>
> Hans.
>
> Brett George wrote in message <367F428F.5641E93E@clarityeq.com>...
> >Hi all,
> >
> >Has anyone tried implementing a PLL in an FPGA (eg. ALTERA), we are
> >thinking of using it to reduce clock jitter from an externally generated
> >clock source.
Article: 13958Look at the multiplier page on my website. The section you are interested in is the scaling accumulator multipliers. The scaling accumulator architecture has an advantage over a modified booth serial by parallel multiplier (built as a chain of serial adders) in that it can be run in msb and lsb first systems and the result can be trimmed easily. The output is parallel. The modified booth architecture (currently not on my website) has a maximum clock rate advantage, as there is no combinatorial carry propagation to slow it down. The modified booth output is serial, LSB first and the serial input needs to be padded so that it's length is the same as the output length. You can learn about the modified booth serial multiplier by looking at my 'FIR fits in an FPGA' paper. That paper discusses the modified booth serial multiplier in detail. The paper is also available on my website. John Kennedy wrote: > I need some advice on how to implement a Bit-Serial multiplier using the > Xilinx Logicore Scaled By 1/2 Accumulator. I need to scale a 20 bit > signed 2's complement number. I am using XC4010 fpga to try to do some > digital audio signal processing, and need a compact (ok if slow) > multiplier. Any advice would be greatly appreciated. > > John -- -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: 13959
Peter wrote: > >... > I have come across a weird problem. > >... And dozens of people generated oodles of interesting and useful replies, all of this happening while I was not reading the group. Fortunately none of this excellent stuff has expired from my newsserver yet. Anybody feel like collating the material into a Webpage case study somewhere? Would get quite a few hits, I'm sure. Sorry about coming to the party late, but there's a couple of things I feel like adding. The point made by several people, that one can code a state machine for stable single output change per single input change only, then have the minimiser/optimiser remove all supposedly redundant product terms and open the door to internal glitches, is important, IMO. In some of my designs (using PLPL) I've deliberately edited the minimiser output file to restore such (statically-redundant but dynamically-significant) product terms. Does anyone know of current tools where such "maximise" options can be implemented by the tool rather than the designer? FWIW, I had an almost identical problem to Peter's five years ago. I was decoding independent asynchronous interrupt sources into the four-bit interrupt level for a SPARC CPU. Synchronising the outputs (ie making them registered) produced exactly the same problem Peter had - intermittent false codes. This was eventually traced to non-uniform delays through the PLD's internals (alternatively the registers had non-identical setup times or non-identical response to violation of setup time - same results). The right code always came out, but sometimes there was a single cycle where the wrong code appeared first (always the same wrong code for the same input pattern, went wrong approx every 1 or 2 thousand times). The solution was to make the outputs combinatorial. According to the SPARC data book, this should have created more problems than it solved, but it didn't and the systems have been working fine ever since. Pre-synchronising the inputs (I'd have used inverse clock) would have required adding a piggy-back IC to the board, and was regarded as an option of last resort - there weren't enough resources left in the PLD to do this internally, as there was other functionality involved. -- Tim Forcer tmf@ecs.soton.ac.uk Department of Electronics & Computer Science The University of Southampton, UK The University is not responsible for my opinionsArticle: 13960
Tim Forcer wrote: <snip> > In some of my > designs (using PLPL) I've deliberately edited the minimiser output file > to restore such (statically-redundant but dynamically-significant) > product terms. Does anyone know of current tools where such "maximise" > options can be implemented by the tool rather than the designer? > Been there. For all its many charms, PLPL had the serious disadvantage that it never offered any localised control over minimisation. I haven't used it for a few years now, but IIRC there is some sort of global control of optimisation level. Typically, of course, designs don't fit if you set this to a low enough level so that the hazard covering terms are preserved. Early versions of CUPL had the same problem, but for some time now it's had a pragma (keyword? option? magic spell? hard to tell the difference with CUPL) allowing you to control the minimisation strategy on an output-by-output basis, which is often adequate. For industrial as opposed to academic or prototyping applications, most people would regard it as unacceptable to have to hand-edit compiler output of any kind; unless you can scriptfile the edit, which seems unlikely in this case. I have not myself met any tool which understands enough about the dynamics of state machines to be able to insert hazard covering terms automatically. One of the problems, I think, is the extent to which such things are device-dependent. Consider, for example, an attempt to hazard-cover an asynchronous transparent latch: [version 1: no hazard coverage] if (clk) then q=d else q=q ---maps to--> q = clk.d + /clk.q [version 2: hazard covered] q = clk.d + /clk.q + d.q Commonsense says that version 1 is dodgy and version 2 is OK. BUT: in QuickLogic FPGAs, for example, [1] works just fine because clk is used as the select input to a multiplexer implemented by break-before-make pass transistors with capacitive hold on its output. On the other hand, it is possible to imagine table-lookup implementations of 3-input OR which could make [2] fail despite the extra term. The net result is that any tool that attempts to achieve automatic hazard coverage will need to preserve information about the dynamic behaviour of the logic (which transitions it will make) all the way down to the hardware - even, perhaps, down to place-and-route - in order to decide how to implement the hazard coverage. Or am I missing something? Jonathan BromleyArticle: 13961
Hi, I am implementing a hardware lab. for our research's group and I must to make a decision on whish FPGA development system to buy (Altera, Xilinx, etc). We develop research's projects and we need a system hw/sw to simulate, debbuging and hardware implementation of advanced algorithm applications. Somebody can give me some suggest? Best regards Renzo Arce STMicroelectronics Italy renzo.arce@st.comArticle: 13962
Yes, but how about the original poster, Peter?
Have been able to get your state machine running,
and what seems to have been the problem?
Was it actually a meta-stability problem
(which most respondents seem to agree not)
or really a logic hazard condition ( cured
by the addition of a 'redundant' coverage
product term ) ?
To get overly specific, if your state bits
are labelled [s2 s1 s0], the final equations
should include (sorry, ABEL was my PLD language
of choice):
s2 := (other state control product terms)
# s2 & !s1 & !s0 ;
That term will fix your problem of going
from 100 to 001 instead of 100 to 101.
BTW, IIRC, the ABEL documentation ( I know,
you're using a different package ) used to
have a description of this problematic
characteristic of PLDs.
Once you understand all the ins and outs of
this idea of logic hazard, you are well on
the way towards having the necessary tools for
designing completely asynchronous state machines.
These are not generally recommended, but can
be useful when raw speed in response to an
input change is the most important design
requirement.
John Chambers <johnc@ihr.mrc.ac.uk> wrote:
> This thread has provided the solution to a problem I've been working on
> for about 2 months. Many thanks to the insight provided by everybody
> here on the (rather more complex than first expected) subject of state
> machines.
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
Article: 13963Hal Murray wrote: > Big snip here. I'm extracting the parts I want to comment on. I > don't > think I've tossed too much context. > > > I never said that metastability does not exist. I have measured it. > It does > > exist, but the recovery delay from the metastable (=balanced) > condition to the > > ultimately stable state is so short in modern CMOS latches and > flip-flops, that > > the problem has lost most of its impact. > > > 1. A modern CMOS latch can go metastable, but recovers so fast that > the problem > > is, in most applications, irrelevant. ( see curves in the Xilinx > data book, > > page 13-49 ) > > I cringe when I see things like that, especially from people that I > usually > agree with. > What I meant to say was: If your asynchronous events occurs at a few MHz rate, and you clock at less than 50 MHz, and you have a few ns "slop" between the synchronizing flip-flop and the next flip-flop, and you use modern chips ( I should say Xilinx XC4000XL, but I don't want to be accused of advertising...), then you can safely ignore the metastable probability. If you try to synchronize an asynchronous even that is well above 10 MHz, and your clock rate is so high that you have not even 2 ns spare time, then you should think about meatstability and do some calculations. I wanted to dispel some of the paranoia, and explain that our flip-flops have become dramatically better, actually more so than the general chip performance and thus system clock rate. Flip-flop gain-bandwidth benefits directly from advances in semiconductor processing, while chip performance unfortunately gets dragged down by interconnect capacitance. I did not realize the hornets nest... Peter Alfke, Xilinx ApplicationsArticle: 13964
Hi
I heard Xilinx abandoned XC6200, favouring Virtex. But has Virtex nice
dynamic reconfigurable features like 6200 does ? I couldnt find anything in
Virtex specs...
Any information would be appreciated.
[]s
Walter
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
Article: 13965Depends on your application. If you are going to be doing alot of arithmetic data path stuff, I would recommend Xilinx for the reasons I've mentioned several times in this forum. If on the other hand, you are doing general logic by synthesis, you might find the Altera tools easier to use. In a research environment, you probably want to stick with SRAM type parts. Actel's reconfigurable line is currently rather limited (most of their parts are antifuse one-time programmable) as is Quicklogic's line. If you are looking at reconfigurable computing, especially involving partial reconfiguration, then the Atmel parts are currently the best choice. renzo.arce@st.com wrote: > Hi, > > I am implementing a hardware lab. for our research's group and > I must to make a decision on whish FPGA development system to buy > (Altera, Xilinx, etc). > > We develop research's projects and we need a system hw/sw to > simulate, debbuging and hardware implementation of advanced > algorithm applications. > > Somebody can give me some suggest? > > Best regards > > Renzo Arce > STMicroelectronics > Italy > renzo.arce@st.com -- -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: 13966
Virtex does have partial reconfiguration ability. Partial configuration is accomplished in columns (the whole column is reconfigured), which really limits the usefulness for partial reconfiguration while the system clock is running. Partial reconfiguration has many pitfalls. The current xilinx tools certainly do not provide the level of support needed to handle partially reconfigured designs, especially on the Virtex parts. To Xilinx's credit, they have not touted the partial reconfigurability of the Virtex part. Right now, the Atmel parts are better suited to handling partial reconfiguration. With those parts you do give up the speed and convenience of carry chains and the small granularity of the CLB RAM (the AT40 K has 32x4 Rams distributed in the array to help compensate for the lack of CLB Ram). soto@caviar.igce.unesp.br wrote: > Hi > > I heard Xilinx abandoned XC6200, favouring Virtex. But has Virtex nice > dynamic reconfigurable features like 6200 does ? I couldnt find anything in > Virtex specs... > > Any information would be appreciated. > > []s > > Walter > > -----------== Posted via Deja News, The Discussion Network ==---------- > http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own -- -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: 13967
Ken Coffman wrote: > What about a Xilinx HardWired device where the pass transistors are > replaced > with metal? Could be ugly... HardWire re-maps the LUTs into "normal" logic, which means the "glitch-free" feature may be lost. But when you ask for conversion to Hardwire, Xilinx will send you a report of all suspect asynchronous signals. It's then up to you to accept the conversion, or to change the design. Peter Alfke, Xilinx ApplicationsArticle: 13968
>The point made by several people, that one can code a state machine for >stable single output change per single input change only, then have the >minimiser/optimiser remove all supposedly redundant product terms and >open the door to internal glitches, is important, IMO. In some of my >designs (using PLPL) I've deliberately edited the minimiser output file >to restore such (statically-redundant but dynamically-significant) >product terms. My problem was that I wrote a SM in the CUPL state machine language, with only *one* async input deciding whether a) you remain in present state, OR b) move to another state. With a gray-coded SM this should have worked fine, without the need for any extra terms whatever. It didn't, on an AMD device. While I have no conclusive proof, I am sure the reason is a combination of a) the timing skew between the data and !data outputs of the *AMD* 22V10 input buffer, and b) CUPL's use of both the true and complement of the async input so in effect I was sampling *two* async inputs. Regarding a) I found that the AMD 22V10 was awful, while the Philips one was "perfect". (There was a probably unrelated problem with the early Philips samples I had being thoroughly duff). I had email from a Philips man who saw my posts and he basically says that they don't guarantee identical prop delays in the input buffer - well this is clear since that would be a theoretical impossibility anyway. I would however have hoped that the skew between the two signals would be less than the response time of the product term AND gate and this certainly seems to be the case in the current Philips P3Z22V10 several of which have been running for a week or two now with not one error. Regarding b) I don't know how to avoid this. There *could* be a feature in e.g. CUPL to use either the input **OR** the !input, but not both, but there isn't. The only solution is to code the SM by hand (yawn!) and not use the SM proprocessor. And not use any minimisation. I don't regard CUPL as a particularly good tool; I just know it well. I have just purchased the latest one, having been told by them that it WILL run in an NT4 DOS box, and it doesn't. >Does anyone know of current tools where such "maximise" >options can be implemented by the tool rather than the designer? Not me. Maybe some of the VHDL-based tools can do this. -- 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: 13969
>Yes, but how about the original poster, Peter? >Have been able to get your state machine running, >and what seems to have been the problem? > > Was it actually a meta-stability problem > (which most respondents seem to agree not) > or really a logic hazard condition ( cured > by the addition of a 'redundant' coverage > product term ) ? It was the latter. I had incorrectly used the term "metastability". Hopefully you will see my other post today summarising the situation. -- 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: 13970
It would be nice to be able to tell the SM compiler to not use *both* the true and complement versions of an input pin, in the equations that drive the D of a particular D-type. Then, gray coding the SM and ensuring that the input can either advance to one other state, or remain in present state, is enough to prevent async input sampling problems - as far as I can see. >The net result is that any tool that attempts to achieve automatic hazard >coverage will need to preserve information about the dynamic behaviour of >the logic (which transitions it will make) all the way down to the >hardware - even, perhaps, down to place-and-route - in order to decide >how to implement the hazard coverage. -- 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: 13971
Peter wrote: >current Philips P3Z22V10 several of which > have been running for a week or two now with not one error. > now that you have it working, try cooling and heating it. Your problem may come back. Opinions expressed herein are my own and may not represent those of my employer.Article: 13972
Roy McCammon wrote: > Peter wrote: > > >current Philips P3Z22V10 several of which > > have been running for a week or two now with not one error. > > > > now that you have it working, try cooling and heating it. > Your problem may come back. and for kicks, ramp the voltage over some wide swings in 100 mv increments rkArticle: 13973
<76sf7q$1ip@src-news.pa.dec.com>, Hal Murray <murray@pa.dec.com> wrote: >If the problem is "irrelevant" for "most applications", how do I tell >if I'm working on one where it is relevant? Assume that it is, until you prove that it isn't. In other words, if it works, OK; if it doesn't, don't rule out metastability as the cause. -- Regards, John Woodgate, Phone +44 (0)1268 747839 Fax +44 (0)1268 777124. OOO - Own Opinions Only. You can fool all of the people some of the time, but you can't please some of the people any of the time.Article: 13974
<3692438A.37DDD046@xilinx.com>, Peter Alfke <peter@xilinx.com> wrote: > you should think about meatstability Watch the fridge temperature! -- Regards, John Woodgate, Phone +44 (0)1268 747839 Fax +44 (0)1268 777124. OOO - Own Opinions Only. You can fool all of the people some of the time, but you can't please some of the people any of the time.
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