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
I have spent some time in analyzing and measuring metastability. Maybe I can point out some aspects: I usually explain metastability by flicking a sharp pen so that it either tips forward or backwards on the table. There is a very, very small chance of giving it just so much energy that it ends up standing on its tip with zero end-velocity. How long it stays there depends on the mass of the pen, the polar momentum, gravity, and thermal noise. The electrical equivalent is the cross-coupled latch. It might end up in the metastable balanced state, and the duration of the stay depends on the gain-bandwidth product of the latch feedback, plus the system noise. A CMOS latch is very simple, and has much higher gain x bandwidth than the old TTL circuits, which could behave quite badly (oscillating,...) I have measured modern (well, kind of modern: Virtex-2Pro) latches, and I found that they very, very rarely stay in the metastable state longer than 3 ns. To get them to do this requires a very precise timing relationship between the data and the clock input. The capture window is substatially less than a femtosecond, which is a millionth of a nanosecond. I have not found a way to do this in a deterministic way, but it is quite easy to do it statistically, just use lots of asynchronous MHz on clock and data, and capture the rare occurance of en extra delay. See the Xilinx app note XAPP094. These measurements nicely quantify the metastability risk. Now back to Chaos... Peter AlfkeArticle: 104676
Phil Hays =E5=86=99=E9=81=93=EF=BC=9A > "StanleyLee" <lizhongqi@hotmail.com> wrote: > > >Peter Alfke wrote: > > >> If you use an asynchronous reset signal while the clock is running, > >> then you must be concerned about the trailing end of Reset. Reset will > >> not go away everywhere at the same time, which means that some parts of > >> the circuit end the reset before a certain clock edge, others after > >> that edge. This can have ugly consequences. > >> > >> The standard remedy is to augment (stretch) the asynchronous reset with > >> a local synchronous reset that lasts longer, but then of course ends > >> synchronously. > >> SRL16 shift registers are a popular and cheap way of doing that. > >> Peter Alfk, Xilinx > > > >Thanks for Peter's answer, but I have a problem is that why use SRL16? > >Why do not use a simple flip-flop? And if I use the LOCKED pin of a > >DCM, is it synchronous with the input clock of the DCM? > > If reset goes away in less than a clock period, then a single FF will > work, with enough care. Not a usual case anymore, unless the clock > rate is fairly slow. If reset takes multiple clocks to go away, but > less than 16, and the reset assertion time is longer than 16 clocks, > then a SRL16 is a very cheap and very good solution. This is a common > case. > > Short reset assertion time cases might require a shift register built > out of FFs, or a counter, to stretch the synchronous reset. > > > -- > Phil Hays (Xilinx, but speaking for himself) Thanks for Phils answer, but how should I use the SRL16? In my opinion, if I do it as following, there is no difference between SRL16 and FF except there is 16 cycles delay when use SRL16. D=3D>asynchronous reset in; Q=3D>synchronous reset out; A3,A2,A1,A0 =3D> '1'; CLK =3D> system clock; Thank you!Article: 104677
Hello everybody. I use Xilinx (ISE 6.2.03i) and Mentor (Precision RTL 2004) tools. I have an issue when I specify the LOC constraints for bit vectors. I use VHDL, and the Xilinx UCF file format is NET "Whatever<0>" LOC = "P65"; When I add the file to Precison it doesn't like the "<0>". If I change them to parenthesis... NET "Whatever(0)" LOC = "P65"; it works OK and uses those constraints. The weird thing is that I get the error when Precision calls the Xilinx tools. Launcher: Executing edif2ngd "whatever.edf" "whatever.ngo" # INFO:NgdBuild - Release 6.2.03i - edif2ngd G.31a # INFO:NgdBuild - Copyright (c) 1995-2004 Xilinx, Inc. All rights reserved. # Writing the design to "whatever.ngo"... # Reading NGO file # "D:/Path/ps/whatever.ngo" ... # Reading component libraries for design expansion... # # Annotating constraints to design from ile "whatever.ucf" ... # ERROR:NgdBuild:755 - Line 3 in 'whatever.ucf': Could not find net(s) # 'ASignal_OUT<0>' in the design. To suppress this error specify the correct net # name or remove the constraint. The 'Ignore I\O constraints on Invalid Object # Names' property can also be set ( -aul switch for command line users). # .. thisd goes away if I chane the UCF vector indexes to parenthesis. Could it be that Precision writes the EDIF file with () instead of <>. Has anybody seen this? Is there any simple solution (command line switch, setting or something) for this? I know there's ways around this, but I just thought somebody might know how to use this directly. Thanks a lot, GuillermoArticle: 104678
Gary, h doesn't have a source in your code. You need to add something like this: h <= slv_reg0; Or just use slv_reg0 instead of h as input to your inverter and in the read process. /MikhailArticle: 104679
Robin, IMHO, trying to get inferring of anything more complex than a flip-flop, or perhaps an adder, to work is a waste of time. Just instantiate what you need... /MikhailArticle: 104680
Hi Aurelian , What do you mean by re-balance registers?? Regards, Prav Aurelian Lazarut wrote: > Prav, > The approach is very dependent of the root cause. > you have to investigate where your time budget is spent, logic or routing > if is on logic try to reduce the number of logic levels, pipeline, > re-balance registers, etc. > if is on routing try to floor plan, use area constraints, different > switches in map/par etc. > > Aurash > > prav wrote: > > Hi all, > > > > I am facing timing violations in my FPGA with Max frequency 125 Mhz(Set > > up viloations). > > What are the steps to be taken to meet the frequency other than doing a > > pipeline in RTL. > > I am using Xilinx FPGA's. > > > > regards > >Article: 104681
Anonymous schrieb: > I am starting a new design using V4FX parts. I have only one JTAG connection > so far. Is it possible to simultaneously run the debugger and a chipscope > session so I can debug problems between the micro and the fpga fabric? If > not, do I need a second JTAG and how do I wire it? > > Thanks, > Clark when you generate the EDK project there is a radio button to choose the PPC debug port to be connected to FPGA logic. just select that option and connect the PPC jtag pins to ios. It is is also explained in the Xilinx documentation. Antti http://antti-brain.comArticle: 104682
Peter Alfke wrote: > I have spent some time in analyzing and measuring metastability. Maybe > I can point out some aspects: > I usually explain metastability by flicking a sharp pen so that it > either tips forward or backwards on the table. > There is a very, very small chance of giving it just so much energy > that it ends up standing on its tip with zero end-velocity. How long it > stays there depends on the mass of the pen, the polar momentum, > gravity, and thermal noise. You may use this as an analogy, but it is not mathematically equivalent. The pencil model is not capable of any form of oscillation as it is too simple. But in my original post I explain that something as simple as a damped, driven pendulum *is* capable of chaotic operation. That is why I ask if the "cross-coupled latch" has a similar type of complexity as the pendulum and is capable of chaotic operation. > The electrical equivalent is the cross-coupled latch. It might end up > in the metastable balanced state, and the duration of the stay depends > on the gain-bandwidth product of the latch feedback, plus the system > noise. A CMOS latch is very simple, and has much higher gain x > bandwidth than the old TTL circuits, which could behave quite badly > (oscillating,...) Two mistakes perhaps? The latch is not equivalent to the pencil and I believe the noise is not a factor in resolving the metastability. This was discussed here once ad nauseum and I never read an explanation that was other than the seat of the pants on why noise would actually help to resolve metastability. Please correct me if I missed something and am wrong about this. > I have measured modern (well, kind of modern: Virtex-2Pro) latches, and > I found that they very, very rarely stay in the metastable state longer > than 3 ns. To get them to do this requires a very precise timing > relationship between the data and the clock input. The capture window > is substatially less than a femtosecond, which is a millionth of a > nanosecond. I have not found a way to do this in a deterministic way, > but it is quite easy to do it statistically, just use lots of > asynchronous MHz on clock and data, and capture the rare occurance of > en extra delay. See the Xilinx app note XAPP094. These measurements > nicely quantify the metastability risk. > Now back to Chaos... Yes, chaos! The book I read did not give any real math details on the requirements for producing chaos, but there were several very simple examples. They talk about some very simple examples with three "attractors" where any point around the borderline between them is always adjacent to points which will take the system to any of the three states. But with only two attractors, a FF may be too simple a system to show chaos. Good thing we aren't combining metastability with multivalued logic. ;^)Article: 104683
Jim Granville <no.spam@designtools.co.nz> wrote: >Phil Hays wrote: >> Metastablility is a whole lot of different things under one name, with >> the one thing in common being the output is expected to be digital and >> the process for getting there is analog. >> >> Some of the TTL FFs have behavior in metastable cases that might well >> be chaotic. TTL can do all sorts of weird things when metastable, >> including oscillating. To prove that one of those weird things was >> both metastable and chaotic could be done if someone could find a >> period*3 variation in the oscillation after a metastable event. >> >> Standard IC CMOS FFs on the other hand, I don't think so. The >> internal nodes and output do not oscillate, due to the design, as far >> as I understand it. No oscillation, no chaos. > >Yes and no. They are regenerative, and they are also analog, >and there has to be threshold noise in there as well... >So there is chaos in the settling time/final value. Noise and such isn't chaos, in the mathamatical sense of the term. http://en.wikipedia.org/wiki/Chaos_theory -- Phil Hays (Xilinx, but speaking for himself)Article: 104684
I am so happy to have removed the mystery from metastability. I do not want to get chaos back in. It is the simplicity of the CMOS latch structure that causes metastability to be so well-behaved and incapable of any oscillation. Nobody has ever reported oscillation in CMOS latches (but well in TTL structures that are more complex). Hurray for simplicity... I think the pen analogy is valid... Peter Alfke ===================== rickman wrote: > Peter Alfke wrote: > > I have spent some time in analyzing and measuring metastability. Maybe > > I can point out some aspects: > > I usually explain metastability by flicking a sharp pen so that it > > either tips forward or backwards on the table. > > There is a very, very small chance of giving it just so much energy > > that it ends up standing on its tip with zero end-velocity. How long it > > stays there depends on the mass of the pen, the polar momentum, > > gravity, and thermal noise. > > You may use this as an analogy, but it is not mathematically > equivalent. The pencil model is not capable of any form of oscillation > as it is too simple. But in my original post I explain that something > as simple as a damped, driven pendulum *is* capable of chaotic > operation. That is why I ask if the "cross-coupled latch" has a > similar type of complexity as the pendulum and is capable of chaotic > operation. > > > The electrical equivalent is the cross-coupled latch. It might end up > > in the metastable balanced state, and the duration of the stay depends > > on the gain-bandwidth product of the latch feedback, plus the system > > noise. A CMOS latch is very simple, and has much higher gain x > > bandwidth than the old TTL circuits, which could behave quite badly > > (oscillating,...) > > Two mistakes perhaps? The latch is not equivalent to the pencil and I > believe the noise is not a factor in resolving the metastability. This > was discussed here once ad nauseum and I never read an explanation that > was other than the seat of the pants on why noise would actually help > to resolve metastability. Please correct me if I missed something and > am wrong about this. > > > > I have measured modern (well, kind of modern: Virtex-2Pro) latches, and > > I found that they very, very rarely stay in the metastable state longer > > than 3 ns. To get them to do this requires a very precise timing > > relationship between the data and the clock input. The capture window > > is substatially less than a femtosecond, which is a millionth of a > > nanosecond. I have not found a way to do this in a deterministic way, > > but it is quite easy to do it statistically, just use lots of > > asynchronous MHz on clock and data, and capture the rare occurance of > > en extra delay. See the Xilinx app note XAPP094. These measurements > > nicely quantify the metastability risk. > > Now back to Chaos... > > Yes, chaos! The book I read did not give any real math details on the > requirements for producing chaos, but there were several very simple > examples. They talk about some very simple examples with three > "attractors" where any point around the borderline between them is > always adjacent to points which will take the system to any of the > three states. But with only two attractors, a FF may be too simple a > system to show chaos. Good thing we aren't combining metastability > with multivalued logic. ;^)Article: 104685
I have a similar problem, my way is to take a look at the GSRD desing from xilinx. There is an intc core which implements a interface between logic and ppc over the DCR. Regards, Eric Guru schrieb: > my.king wrote: >> Hi, >> >> I'm working with the ML310 eval board. Is there anyone who has a >> working example on how to create a custom IP on the DCR bus (and >> accessing it from the PPC405)? >> >> Thanks. > > I did it! It is quite easy. Take a look at Xilinx PLBtoOPB bridge core > or similar IP with DCR bus. > > Cheers, > > Guru >Article: 104686
Is there an implementation of Linux for the Live Design Eval Board(Xilinx). May be a version of uCLinux for Mircoblaze? Thx EricArticle: 104687
Hi Robin,
"Robin Bruce" <robin.bruce@gmail.com> wrote in message
news:1151947593.928975.73730@j8g2000cwa.googlegroups.com...
> Hi Guys,
>
> I'm having trouble with the following problem:
>
> I'm trying to create a 35x35 signed multiplier from DSP48s, inferring
> pipelining in VHDL by adding registers after the multilplication
> operation as seen below in the VHDL I'm using.
>
> The problem is that when I synthesise, though I can see that the
> synthesiser has noticed that it can shift registers about:
> the clock rate achieved is still only a meagre 81.171MHz. I'll save my
> half-baked hypotheses for now and see if anyone knows what's up here.
> Any help you can give would be very much appreciated.
I've had a very similar problem recently, albeit in a slightly different
context. Can you let us know what version of the tools you are using?
Basically, it seems that XST is not always very good at using the *right*
registers when is pulls delay elements into a DSP block, nor at pulling said
elements in the right direction when there is a choice. You can easily end
up with a bunch of useless input registers, but no middle (M) or product (P)
register. Check the DSP48 configuration in your resulting netlist (with e.g.
FPGA editor) and have a look at where it's actually putting these registers.
You may be able to use "KEEP" constraints as a workaround, although my
feeling is you definitely shouldn't have to.
Funny thing is, this used to work pretty well (in my limited experience). If
I get a chance I'll submit this to the XST team myself, but it would help if
you opened a case with tech support (customer complaints carry more weight
than internal engineering whinges)...
Cheers,
-Ben-
Article: 104688Thanks.. I'll look for that.. Guru wrote: > my.king wrote: > > Hi, > > > > I'm working with the ML310 eval board. Is there anyone who has a > > working example on how to create a custom IP on the DCR bus (and > > accessing it from the PPC405)? > > > > Thanks. > > I did it! It is quite easy. Take a look at Xilinx PLBtoOPB bridge core > or similar IP with DCR bus. > > Cheers, > > GuruArticle: 104689
eric schrieb: > Is there an implementation of Linux for the > Live Design Eval Board(Xilinx). May be a version of > uCLinux for Mircoblaze? > > Thx > > Eric Hi Eric, The Live Design Eval Board has only 1MB of RAM, there are some reports getting mb-uclinux working with small (less than 4MB) memory but there is no 'get it working in 1MB solution' - this is one problem. You can make a Microblaze design that is 'uclinux ready' and test it on livedesign board, but you should use EDK for that in order to have the supported peripheral in place (OPB_INTC, OPTB_Timer, OPB_UARTLITE) An interesting thing would of course be microblaze uclinux system design without EDK using Altium Designer as SoC tool - unfortunatly such a design does not exist - well the SDRAM support was added to Altium Designer only in the release 6.3 (from 26 June 2006?), so there is defenetly no uclinux that would work on system made with Altium Designer. Antti http://antti-brain.comArticle: 104690
Hi Eric, Seems like MPMC2 implemented in GSRD2 opens unlimited possibilities to port the design to different platforms. I have downloaded the latest version of MPMC2 (20060630) which also includes GSRD2 and there is no sign of Linux - only Treck IP stack, this time with source code. Have you tested the performance of GRSD1 with Treck stack? What do you want to connect to DCR bus? I hope not for data transmission, because it is a low performance bus, primary for registers reading/writing. Send me a private email for further discussion/cooperation. Cheers, GuruArticle: 104691
"Peter Alfke" <alfke@sbcglobal.net> wrote in message news:1151994135.380653.322220@h44g2000cwa.googlegroups.com... >I am so happy to have removed the mystery from metastability. I do not > want to get chaos back in. > It is the simplicity of the CMOS latch structure that causes > metastability to be so well-behaved and incapable of any oscillation. > Nobody has ever reported oscillation in CMOS latches (but well in TTL > structures that are more complex). Hurray for simplicity... > I think the pen analogy is valid... > Peter Alfke > ===================== Hi Peter, I agree with you, the pen example is rather good. Over the years, people like Xilinx have been making the tip of the pen sharper and sharper. On to chaos: I don't think a system needs oscillation of each component comprising the system in order to be chaotic. The resultant system changing state is the chaotic thing, rather than the FF oscillating. For example :- http://en.wikipedia.org/wiki/Logistic_map In this scenario, each individual doesn't oscillate, they just live or die, but the system is chaotic. Also, what matters is the sensitivity to initial conditions. Again see the previous example. The state of the system has to be dense, but that's possible to build with a logic circuit. e.g. all those computer simulations of Lorenz systems. If you had a lot of pens, and the flick of each one depended on the outcome of the previous pen's flick, I think that could be chaotic, (And not only in the mathematical sense if you use fountain pens!) if the flick impulse each time is very close to the 'metastable' impulse. In conclusion, I think an individual CMOS FF given a single metastable clock event doesn't comprise a chaotic system, but you can make a chaotic system with several of them, no trouble. Cheers, Syms. Inviato da X-Privat.Org - Registrazione gratuita http://www.x-privat.org/join.phpArticle: 104692
Thanks Ben, it's always good to know that I'm not imagining the problem. I'm using ISE 8.1, service pack 3. I should probably point out at this point that the purpose of this little project is as much about design methodology as it is about having a functioning design. I'm aware that there's about a million ways I could do this, but in order to have a portable core that can be easily floorplanned, I want to have all my design files as standard VHDL with no specific instantiations of FPGA resources, nor any NGC files from CoreGen. I've got a 20-odd page report on my attempts to do this, so perhaps there's someone I should send this to? I've never opened a case with tech support, so I'll look into how I might do this too... Cheers, Robin I've had a very similar problem recently, albeit in a slightly different > context. Can you let us know what version of the tools you are using? > > Basically, it seems that XST is not always very good at using the *right* > registers when is pulls delay elements into a DSP block, nor at pulling said > elements in the right direction when there is a choice. You can easily end > up with a bunch of useless input registers, but no middle (M) or product (P) > register. Check the DSP48 configuration in your resulting netlist (with e.g. > FPGA editor) and have a look at where it's actually putting these registers. > You may be able to use "KEEP" constraints as a workaround, although my > feeling is you definitely shouldn't have to. > > Funny thing is, this used to work pretty well (in my limited experience). If > I get a chance I'll submit this to the XST team myself, but it would help if > you opened a case with tech support (customer complaints carry more weight > than internal engineering whinges)... > > Cheers, > > -Ben-Article: 104693
Symon schrieb: > "Peter Alfke" <alfke@sbcglobal.net> wrote in message > news:1151994135.380653.322220@h44g2000cwa.googlegroups.com... > >>I am so happy to have removed the mystery from metastability. I do not >>want to get chaos back in. >>It is the simplicity of the CMOS latch structure that causes >>metastability to be so well-behaved and incapable of any oscillation. >>Nobody has ever reported oscillation in CMOS latches (but well in TTL >>structures that are more complex). Hurray for simplicity... >>I think the pen analogy is valid... >>Peter Alfke >>===================== > > Hi Peter, > I agree with you, the pen example is rather good. Over the years, people > like Xilinx have been making the tip of the pen sharper and sharper. > On to chaos: I don't think a system needs oscillation of each component > comprising the system in order to be chaotic. The resultant system changing > state is the chaotic thing, rather than the FF oscillating. For example :- > http://en.wikipedia.org/wiki/Logistic_map You use different meanings of the word oscillation. Peter meant this with oscillation: http://en.wikipedia.org/wiki/Oscillation_%28mathematics%29 "In mathematics, oscillation is the behaviour of some sequences, or a function, that does not converge, but also does not diverge to +∞ or -∞; that is, oscillation is the failure to have a limit." With that definition the population example clearly oscillates for all values of r larger than 3.57. The article you cited state the opposite: "At r = 3.57 (approximately) is the onset of chaos. We can no longer see any oscillations." This comes from a definition of oscillation like this http://en.wikipedia.org/wiki/Oscillation "Oscillation is the periodic variation,...". I guess that is what you mean with oscillation. Anyway, you need negative feedback for chaos in a system and the CMOS latch does not have any. > Also, what matters is the sensitivity to initial conditions. Again see the > previous example. Yes, but in the model. Chaos and noise are different things. If you flip the coin in an identical way (not possible, but thats beside the point) it will always show the same behaviour in the abscense of noise. There is a threshold value. Below the threshold it will flip one way, above it will flip the other way. A chaotic system would show some complicated pattern close to the threshold without noise. The pencil experiment with added noise will look very similar to that, but that is not what chaos theory is about. > In conclusion, I think an individual CMOS FF given a single metastable clock > event doesn't comprise a chaotic system, but you can make a chaotic system > with several of them, no trouble. Sure. You can build a CPU out of them an compute the logistic map ;-) Kolja SulimmaArticle: 104694
"Robin Bruce" <robin.bruce@gmail.com> writes: > Hi Guys, > > I'm having trouble with the following problem: > > I'm trying to create a 35x35 signed multiplier from DSP48s, inferring > pipelining in VHDL by adding registers after the multilplication > operation as seen below in the VHDL I'm using. > > The problem is that when I synthesise, though I can see that the > synthesiser has noticed that it can shift registers about: > > Synthesizing (advanced) Unit <signed_mult_TOP>. > Found pipelined multiplier on signal <mult_inst/_n0000>: > - 2 pipeline level(s) found in a register connected to the multiplier > macro output. > Pushing register(s) into the multiplier macro. > > - 2 pipeline level(s) found in a register on signal <mult_inst/A2>. > Pushing register(s) into the multiplier macro. > > - 2 pipeline level(s) found in a register on signal <mult_inst/B2>. > Pushing register(s) into the multiplier macro. > > the clock rate achieved is still only a meagre 81.171MHz. I'll save my > half-baked hypotheses for now and see if anyone knows what's up here. > Any help you can give would be very much appreciated. > Only more (potentialy dim) questions I'm afraid: Have you had a look in FPGA editor to see what's going on? Is it actually this bit of code that limits the timing? Cheers, Martin -- martin.j.thompson@trw.com TRW Conekt - Consultancy in Engineering, Knowledge and Technology http://www.trw.com/conektArticle: 104695
StanleyLee wrote:
>Phil Hays 写道：
>
>
>
>>"StanleyLee" <lizhongqi@hotmail.com> wrote:
>>
>>
>>
>>>Peter Alfke wrote:
>>>
>>>
>>>>If you use an asynchronous reset signal while the clock is running,
>>>>then you must be concerned about the trailing end of Reset. Reset will
>>>>not go away everywhere at the same time, which means that some parts of
>>>>the circuit end the reset before a certain clock edge, others after
>>>>that edge. This can have ugly consequences.
>>>>
>>>>The standard remedy is to augment (stretch) the asynchronous reset with
>>>>a local synchronous reset that lasts longer, but then of course ends
>>>>synchronously.
>>>>SRL16 shift registers are a popular and cheap way of doing that.
>>>>Peter Alfk, Xilinx
>>>>
>>>>
>>>Thanks for Peter's answer, but I have a problem is that why use SRL16?
>>>Why do not use a simple flip-flop? And if I use the LOCKED pin of a
>>>DCM, is it synchronous with the input clock of the DCM?
>>>
>>>
>>If reset goes away in less than a clock period, then a single FF will
>>work, with enough care. Not a usual case anymore, unless the clock
>>rate is fairly slow. If reset takes multiple clocks to go away, but
>>less than 16, and the reset assertion time is longer than 16 clocks,
>>then a SRL16 is a very cheap and very good solution. This is a common
>>case.
>>
>>Short reset assertion time cases might require a shift register built
>>out of FFs, or a counter, to stretch the synchronous reset.
>>
>>
>>--
>>Phil Hays (Xilinx, but speaking for himself)
>>
>>
>
>Thanks for Phils answer, but how should I use the SRL16? In my opinion,
>if I do it as following, there is no difference between SRL16 and FF
>except there is 16 cycles delay when use SRL16.
>
>D=>asynchronous reset in;
>Q=>synchronous reset out;
>A3,A2,A1,A0 => '1';
>CLK => system clock;
>
>Thank you!
>
>
>
The main difference is from the used resource perspective, with SRL16
you need just a LUT (from a SLICEM) with the choice of up to 16 clks
(taps) and no routing, but using FFs you need from 1 FF to 16 FFs +
routing, depending on the number of TAPs you want
functionally speaking it's the same thing in both.
Aurash
--
__
/ /\/\ Aurelian Lazarut
\ \ / System Verification Engineer
/ / \ Xilinx Ireland
\_\/\/
phone: 353 01 4032639
fax: 353 01 4640324
Article: 104696"StanleyLee" wrote: >Phil Hays wrote: >> If reset goes away in less than a clock period, then a single FF will >> work, with enough care. Not a usual case anymore, unless the clock >> rate is fairly slow. If reset takes multiple clocks to go away, but >> less than 16, and the reset assertion time is longer than 16 clocks, >> then a SRL16 is a very cheap and very good solution. This is a common >> case. >Thanks for Phils answer, but how should I use the SRL16? In my opinion, >if I do it as following, there is no difference between SRL16 and FF >except there is 16 cycles delay when use SRL16. Exactly, and that difference may be required. Suppose your clock period is 2.5 ns, and the time required to propagate asynchronous reset to all FFs is 25 ns. Then to make sure that critical state was released from reset at the same time, then at least 10 CLK cycles of delay would need to be added from the release of asynchronous reset to the release of synchronous reset. An SRL16 (plus 2 FFs) would do this just fine, as would a 10 bit shift register built out of FFs, or a 4 bit counter. The SRL16 uses the smallest amount of hardware, there are reasons to use the other methods at times. -- Phil Hays (Xilinx, but speaking for himself)Article: 104697
Martin,
> Have you had a look in FPGA editor to see what's going on?
This is where I myself look dim: I did open up the NCD file in the FPGA
Editor. I didn't really know what to do to tell if the right
registering was occurring. All I could see was that all 4 DSP48s were
instantiated together in a little row. I've never used FPGA editor
before. I'm more familiar with PlanAhead for looking at that sort of
thing, but I don't have that on my laptop, my current working platform.
> Is it actually this bit of code that limits the timing?
Well, all I can say is that I don't think so. It could very well be
though, but I've tried writing the VHDL in very different ways, guided
by things I've found in one or two guides to instantiating the DSP48s
in VHDL. Every way I write the VHDL, the same performance is obtained.
The thing is that I can see that the synthesis tool is making some kind
of effort to pipeline the thing.
This is the critical path that comes out of the synthesis report if
this means anything to anyone:
Data Path: mult_inst/Mmult__n00001 to mult_inst/Mmult__n0000_35
Gate Net
Cell:in->out fanout Delay Delay Logical Name (Net Name)
---------------------------------------- ------------
DSP48:CLK->PCOUT47 1 4.399 0.000 mult_inst/Mmult__n00001
(mult_inst/Mmult__n00002_PCIN_to_mult_inst/Mmult__n00001_PCOUT_47)
DSP48:PCIN47->PCOUT47 1 2.363 0.000
mult_inst/Mmult__n00002
(mult_inst/Mmult__n00003_PCIN_to_mult_inst/Mmult__n00002_PCOUT_47)
DSP48:PCIN47->PCOUT47 1 2.363 0.000
mult_inst/Mmult__n00003
(mult_inst/Mmult__n00004_PCIN_to_mult_inst/Mmult__n00003_PCOUT_47)
DSP48:PCIN47->P35 1 2.270 0.534 mult_inst/Mmult__n00004
(mult_inst/Mmult__n0000_s_69)
FD:D 0.391 mult_inst/Mmult__n0000_0
----------------------------------------
Total 12.320ns (11.786ns logic, 0.534ns route)
(95.7% logic, 4.3% route)
Cheers,
Robin
Article: 104698Hello experts, Would like to hear from you regarding the precautions, the common practices and problems that arise when migrating an ASIC RTL code into an FPGA. Thanks & Regards, Srini.Article: 104699
srini wrote: > Hello experts, > Would like to hear from you regarding the precautions, the common > practices and problems that arise when migrating an ASIC RTL code into > an FPGA. > > Thanks & Regards, > Srini. Is this university homework or have you a specific project in mind? What Fpga family are you migrating to? What Asic technology was the RTL code originally targeted at? Alan
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