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
"kadhiem_ayob" <kadhiem_ayob@yahoo.co.uk> wrote: >unfortunatley it is not convincing. it is ok for a discussion of >Metsatability per se but not data transfer. No, the double stage d-type for stabilizing an asynchronous input *is* all about metastability and *does* assume that the stabilized data output can go either way if the input was in transition. >the above argument states clearly that first Q output is not copy of D >input but is unstable halfway. ... Correct. >... So is the input to second flop. ... Yes, but it is very unlikely to be that way for the whole of the subsequent clock period, so the output from the second stage is switched cleanly to either a 0 or 1. > ...Now lets look at value rather than stability at second Q output, > stable yes but correct who knows... Stable yes -- that's the whole point. There *isn't* a correct data-value (as in 1 or 0) for the output if the input was in transition. The subsequent circuit can be designed to tolerate uncertain data-values but it's impossible to design it to do anything sensible with internal metastability. >Sorry for being so microanatomical but history has other examples when >consensus doesn't fit reality The reality isn't so difficult to understand in this case. -- Dave FarranceArticle: 139651
In the 60s and 70s doctors routinely used "digoxin" for any patient with heart failure. It was thought that digoxin had inotrophic effect meaning it strengthened the myocardial fibres and so improved pumping effect. In the 80s, it was realised that yes it so but only for normal heart !! The misunderstanding(or cock-up) was due to the other effect of digoxin namely: it has anti-arrythmic effect. many patients with heart failure had secondary arrhythmias and so responded well, others without arrhythmias didnot respond(but were given the medicine for decades). Now they know that: Digoxin has no strengthening effect on the sick dilated fibres of heart. kadhiemArticle: 139652
"kadhiem_ayob" <kadhiem_ayob@yahoo.co.uk> wrote: >In the 60s and 70s doctors routinely used "digoxin" for any patient with >heart failure. It was thought that digoxin had inotrophic effect meaning it >strengthened the myocardial fibres and so improved pumping effect. >In the 80s, it was realised that yes it so but only for normal heart !! >The misunderstanding(or cock-up) was due to the other effect of digoxin >namely: it has anti-arrythmic effect. many patients with heart failure had >secondary arrhythmias and so responded well, others without arrhythmias >didnot respond(but were given the medicine for decades). >Now they know that: >Digoxin has no strengthening effect on the sick dilated fibres of heart. Consider the balance between the symbolic dimension of identity and meaning and the semiotic dimension of nonsense. Hope that helps. -- Dave FarranceArticle: 139653
Hi all,
I've a project containing many user inputs/outputs(Digital). I've
Cyclone EP1C6 UP3 kit, which has a ADC/DAC snap on board mounted on the
external prototype connectors. I'm not finding a way to provide user i/o to
the board after the code has been downloaded to the kit. To be more
specific, I do not know what pin numbers have to be assigned in order to
give digital input/outputs to the kit. Could anyone help me out here?
Any help would be deeply appreciated!
Article: 139654Hi, I need to see and use the scripts and commands use by Xilinx ISE while using its standard GUI flow .. I need scripts for XST , NGDBUILD .. so i can use them and customize only the bitgen & data2mem parts .. Thank you & Best regards, Hassen.Article: 139655
On Apr 8, 3:43=A0pm, hassen.kar...@gmail.com wrote: > Hi, > > I need to see and use the scripts and commands use by Xilinx ISE while > using its standard GUI flow .. > > I need scripts for XST , NGDBUILD .. so i can use them and customize > only the bitgen & data2mem parts .. > > Thank you & Best regards, > Hassen. xxxx.cmd_log AnttiArticle: 139656
Exactly what i'm looking for. thanks What about EDK and its Cygwin ... & make files ? Hassen.Article: 139657
You need to ensure that your output signals have the required setup time relative to your output clock. What I usually do is to clock these signals using the clk90 output of the DCM. That way you should easily meet the setup time. JonArticle: 139658
On Wed, 08 Apr 2009 06:11:50 -0500, "kadhiem_ayob" <kadhiem_ayob@yahoo.co.uk> wrote: >> >>Adding a second d-type with a short propagation delay from the first >>means that there's a whole clock cycle for the first stage to come out >of >>metastability and give a good setup time for the second D-type, so that >>*its* Q output is either a secure 0 or 1 but not something between the >>two. Thus it becomes a negligible source of error compared to a >system's >>overall reliability. Understand now? > >unfortunatley it is not convincing. it is ok for a discussion of >Metsatability per se but not data transfer. > >the above argument states clearly that first Q output is not copy of D >input but is unstable halfway. So is the input to second flop. Now lets >look at value rather than stability at second Q output, stable yes but >correct who knows... First, recognise that sampling one clocked signal (A) with a second (asynchronous) clock (C) is not - and can never be - an accurate reproduction of signal A, but only an approximation (call it B). If your requirement demands a completely accurate reproduction of A you are doomed to fail, as surely as if you were to try to round a real number to integer without losing ANY information. Instead, your requirement must be written so as to tolerate small imperfections in B (timing inaccuracies) without losing essential information. A proof that this is possible is the simple UART, where the receiving clock frequency may be up to 5% in error and still accurately recover the data. Therefore on a rising edge of A, it doesn't matter if B resolves to 0 or 1. Provided the previous B value was 0 and the next B value is 1, the only difference it makes is in the timing of the rising edge. And this difference is simple to handle. Metastability on the other hand is much more dangerous since a value between 0 and 1 can be interpreted as 0 by one circuit, and 1 by another. That introduces an internal inconsistency, which is quite possibly dangerous. The way out is to interpret the metastable value in one AND ONLY ONE circuit; which is the second FF of the two stage synch. >Sorry for being so microanatomical but history has other examples when >consensus doesn't fit reality Yes, it matters. I hope this helps. - BrianArticle: 139659
<Antti.Lukats@googlemail.com> wrote in message news:a17a5589-873d-45ba-837a-d878e71cfdfc@3g2000yqk.googlegroups.com... >the only thing that can be is the startup clock setting, remember >that that Chipscope download DOES NOT automatically fix the >startup clock setting, while impact DOES fix it (when options >are set).. The OP never said he was using the Chipscope to download the file but you are probably right! It never occured to me because I never use this functionality... /MikhailArticle: 139660
Why dont you try using chipscope to debug the logic? JonArticle: 139661
Hello all, i try to make an accelerator that will share the SDRAM with Microblaze using a VFBC port on the MPMC. I use the Spartan 3E Starter Kit and XPS 10.1. So, I created a core with the wizard, it has a FSL bus and I also created a VFBC bus too. For the first test, I try to write 32 bytes to the SDRAM when the processor sends a "1" through the FSL and verify the operation by reading them later with Microblaze. The VHDL code is here: http://www.pastebin.cz/a4e52c21335452 the MPD is here: http://www.pastebin.cz/17173 With the command words being 0x0000002 (X length, 32 bytes) 0x8000000 (Write operation, start address 0) 0x0000000 (only 1 Y line) 0x0000002 (stride, doesn't really matter here I think) So, I expect it to write some bytes to the first 32 physical positions on the SDRAM... ...but it doesn't. I added some output ports to debug it, and my devices output waveforms are exactly as mentioned in the manual ( http://www.xilinx.com/support/documentation/ip_documentation/mpmc.pdf - page 106) Anybody has any idea as to what could be wrong here? Maybe i don't reset the bus as I should? Or give it a wrong clock? I couldn't sort that out using the manual... Perhaps someone could give me a starting point to find for what's going wrong? Thanks in advance, Chris GentsosArticle: 139662
correction on the command words: 0x00000020 (X length, 32 bytes) 0x80000000 (Write operation, start address 0) 0x00000000 (only 1 Y line) 0x00000020 (stride, doesn't really matter here I think)Article: 139663
I want to use DSP48A for a Semi-Parallel FIR filter. Since DSP48A is 18bit*18bit;so i need 2 slice of DSP48A for a multiplier. but how can i utilize the 2 slice DSP48A's internal 48bit post Adder for the Accumulation. or maybe it can only need the 3rd DSP48A for the Accumulation?Article: 139664
>Metastability on the other hand is much more dangerous since a value between 0 >and 1 can be interpreted as 0 by one circuit, and 1 by another. That introduces >an internal inconsistency, which is quite possibly dangerous. >The way out is to interpret the metastable value in one AND ONLY ONE circuit; >which is the second FF of the two stage synch. >- Brian > Thanks Brian, But that '1' or '0' decided by 2nd FF must follow the input sequence arriving at 1st FF or else we synchronise our data only to get some random sequence... The current literature on metastability suggests that when data transition is close to clk edge the flip may 'see' either side of input value with respect to clk edge or 'see' the data transition itself. This 'see' effect will be random as input may arrive any time. The output will similarly become random. Thus the Q of flip1 becomes an information loss point. flip2 cannot recover the info but gets stable as '1' or '0' Surely this scenario is not true in practice. We all can get clk1 data correctly transferred to clk2 domain using two-stage synchroniser(allowing for rate control issues of course). kadhiemArticle: 139665
On Wed, 08 Apr 2009 03:40:39 -0500, "kadhiem_ayob" <kadhiem_ayob@yahoo.co.uk> wrote: >If the flip output is irrelevant(being 0 or 1 or undefined) then we got >problem with data value integrity rigt from the start of chain. >We need to separate between the issue of metasatibilty probability and >data value crossing. >surely the probability of metastability goes down after every stage but >data value goes wrong through anyway from the start irrespective of >probability issue. This is what puzzles me. > >kadhiem I think it would help if you draw a waveform to see what you're really trying to accomplish. You can see that the data is changing very close to your sampling point and whether you call that value 0 or 1 is really not important because given tens of picoseconds movement one way or the other what you'd call correct data differs. With an asynchronous sampling system like this what you're trying to find out is given your resolution (ie clock period), what's the time the data has changed. Suppose you have a counter which increments with your clock and you record the counter value when you see the data has changed. In this case you have an error of half a period ie the change has occured between counter values X and X+1 with a maximum error of T/2. If you can sample reliably ie without a metastable event you can't resolve where the change has happened better than this. This is why the value of 1 or 0 when the change is very close to the sampling clock doesn't matter. -- Muzaffer Kal DSPIA INC. ASIC/FPGA Design Services http://www.dspia.comArticle: 139666
On Apr 8, 7:25=A0pm, "kadhiem_ayob" <kadhiem_a...@yahoo.co.uk> wrote: > > But that '1' or '0' decided by 2nd FF must follow the input sequence > arriving at 1st FF or else we synchronise our data only to get some rando= m > sequence... You can only synchronize from slower to faster clk. When crossing the clock domain you will lose the original trace as seen on a scope, but the fact is that you won't miss a single transition. The whole point is that if you sample on a transition, you really don't care what value you get: you'll get it right on next clk. Is this the part you are missing ? JosepArticle: 139667
Thanks Muzaffar, I am not trying to achieve any practical problems. Thank goodness I have designed complete multiclock modulator systems for decades now. I am simply looking inside "my thoughts" and make sure I am not getting too old. I possibly understand data is either 0 or 1, the absolute value doesn't matter but the sequence does matter ofcourse and that a few clk latency is not an issue but the sequence of 0 and 1 from one clk must pass to second clk domain. Well it does in practice. The crux of my disorder lies in our thinking model: flip1 is at the mercy of its input and is thrown into chaos from time time. flip2 absorbs the impact, fair. Are we saying data sequence at Q1 correctly follows D1 eventually despite the chaos? in that case no problem but literature says Q1 can be '0' or '1' or in between or oscilating or so then settle as '0' or '1'... if it does settle at D1 value then please ignore this post completely. It is simple primary math of vectors(ignoring latency): D1 => Q1 Q1 is D2 D2 => Q2 so if Q2 = D1 then Q1 = D1 Hence Q1 settles finally at end of clk period to D1(current or previous or next)Article: 139668
On Apr 8, 11:09=A0am, bluesea.x...@gmail.com wrote: > I want to use DSP48A for a Semi-Parallel FIR filter. Since DSP48A is > 18bit*18bit;so i need 2 slice of DSP48A for a multiplier. but how can > i utilize the 2 slice DSP48A's internal 48bit post Adder for the > Accumulation. or maybe it can only need the 3rd DSP48A for the > Accumulation? Good question.Article: 139669
On Wed, 08 Apr 2009 13:48:16 -0500, "kadhiem_ayob" <kadhiem_ayob@yahoo.co.uk> wrote: I'll try to explain myself one more time and let it go. >The crux of my disorder lies in our thinking model: flip1 is at the mercy >of its input and is thrown into chaos from time time. flip2 absorbs the >impact, fair. Are we saying data sequence at Q1 correctly follows D1 This is the crux of the matter. What do you mean "correctly" ? We all agree that if input changes safely before the clock edge, we have a good definition of "correct". Now push the data edge closer to clock edge and when they are aligned, t-e or t+e (t being clock edge and e being a safe distance) you have valid outputs of opposite values. If you reduce e to zero, you can throw a coin and use its output as your value because you can't resolve it any better with your hardware. I would say the only definition of correct in this instance would be monotonicity ie when sampled close to data edge the output should reflect the input with some delay but never create a glitch near the time of the change ie 1111100000 should never produce 1111010000. >eventually despite the chaos? in that case no problem but literature says >Q1 can be '0' or '1' or in between or oscilating or so then settle as '0' >or '1'... >if it does settle at D1 value then please ignore this post completely. It can settle to D1 at some point before or after D1 was changing. Ie the output can introduce delay. >It is simple primary math of vectors(ignoring latency): >D1 => Q1 >Q1 is D2 >D2 => Q2 > >so if Q2 = D1 then Q1 = D1 >Hence Q1 settles finally at end of clk period to D1(current or previous or >next) I'd say yes to this. If you get a change on the output with some delay and without any glitches as shown above, you accomplish what you need. -- Muzaffer Kal DSPIA INC. ASIC/FPGA Design Services http://www.dspia.comArticle: 139670
On Wed, 8 Apr 2009 08:09:39 -0700 (PDT), bluesea.xjtu@gmail.com wrote: >I want to use DSP48A for a Semi-Parallel FIR filter. Since DSP48A is >18bit*18bit;so i need 2 slice of DSP48A for a multiplier. but how can >i utilize the 2 slice DSP48A's internal 48bit post Adder for the >Accumulation. or maybe it can only need the 3rd DSP48A for the >Accumulation? You don't a third DSP48A. DSP48A has an internal PC port which can only be connected to an adjacent DSP48A to make an accumulator. Effectively you need to say this: DSP48A u0(.A(a1), .B(b1), .PCOUT(pc)); DSP48A u1(.A(a2), .B(b2), .PCIN(pc), .P(axb)); this gives you a2*b2 + a1* b1 if you get all the bits and opmodes etc. correct. -- Muzaffer Kal DSPIA INC. ASIC/FPGA Design Services http://www.dspia.comArticle: 139671
On Apr 8, 2:48 pm, "kadhiem_ayob" <kadhiem_a...@yahoo.co.uk> wrote: > Thanks Muzaffar, > > I am not trying to achieve any practical problems. Thank goodness I have > designed complete multiclock modulator systems for decades now. > I am simply looking inside "my thoughts" and make sure I am not getting > too old. > I possibly understand data is either 0 or 1, the absolute value doesn't > matter but the sequence does matter ofcourse and that a few clk latency is > not an issue but the sequence of 0 and 1 from one clk must pass to second > clk domain. Well it does in practice. > The crux of my disorder lies in our thinking model: flip1 is at the mercy > of its input and is thrown into chaos from time time. flip2 absorbs the > impact, fair. Are we saying data sequence at Q1 correctly follows D1 > eventually despite the chaos? in that case no problem but literature says > Q1 can be '0' or '1' or in between or oscilating or so then settle as '0' > or '1'... > if it does settle at D1 value then please ignore this post completely. > It is simple primary math of vectors(ignoring latency): > D1 => Q1 > Q1 is D2 > D2 => Q2 > > so if Q2 = D1 then Q1 = D1 > Hence Q1 settles finally at end of clk period to D1(current or previous or > next) I think you have it correct. This is an unusual way of thinking about it however. But yes, Q1 has to settle by the time of the next active clock edge or Q2 will also be metastable. The point is that there is *no* time interval that guarantees that Q1 will be stable when the setup and hold time is violated. But the probability of metastability becomes very, very, very small when using current technology and with time periods of just a few nanoseconds (like 5 to 10). The purpose of FF2 is to assure that the circuitry it is driving does not see the output of Q1 which will not meet the delay time spec of the FF. With FF2 in the path, the 0->1 or 1->0 transition is delayed another clock cycle, but will transition monotonically and will meet the output delay timing spec, even when Q1 does not. RickArticle: 139672
Antti wrote: > Hi > > http://groups.google.com/group/antti-brain/files?hl=en > > with a delay this month again :( the time is flying only faster.. > but there are some new FPGA board photos included.. > > Antti Google now says all your pages are invalid! Umm, might be a browser compatibility problem, I'm using Firefox on a Linux platform. JonArticle: 139673
On Apr 6, 5:47=A0pm, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com> wrote: > Schematics live in my head, as a thinking tool, and > occasionally leak out on to paper as a tool for communicating > with myself or with fellow humans. =A0They are a lousy design > entry tool. =A0And that's even before you start to deal with > the general crumminess of most schematic capture packages, > where tools for ripping and re-numbering buses are > palaeolithic, and re-use means working out how to bring > up impenetrable property sheets instead of simply patching > and commenting the generics on VHDL components. Just finished designing a large piece of logic to do with spread spectrum comms. The Wishbone-compliant core was completely designed in Xilinx's SysGen which can be thought of after all as a schematic capture environment. Control was done in m-code statemachines. You get the added benefit of having the feature-rich Matlab environment at your disposal for testing and simulating the design. Arithmetic type can't be specified more easily. And oh yeah, the core is parametrized with a top-level dialogbox; a Simulink feature. I have to admit though, naming the wires is a bit fiddly at times. But if your competent enough in Simulink - which I'm not - I'm sure you can even instantiate blocks programmatically - seen it before. One last thing: the design met timing like magic. I suppose you can get the same quality results with endless coregen invocations. This way you just need to have your pick from the Xilinx blockset. I read from and wrote back to Matlab's workspace in accordance to Wishbone bus cycles using Stateflow (statemachine) objects in Simulink. After all you can plot and run all sorts of diagnostics on the output within Matlab and life couldn't be easier. Try to do that in VHDL. I'm sure you can - I love VHDL by the way - but this way it's much faster and DSP-appropriate. -MomoArticle: 139674
On Apr 8, 11:46=A0pm, Manny <mlou...@hotmail.com> wrote: > On Apr 6, 5:47=A0pm, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com> > wrote:> Schematics live in my head, as a thinking tool, and > > occasionally leak out on to paper as a tool for communicating > > with myself or with fellow humans. =A0They are a lousy design > > entry tool. =A0And that's even before you start to deal with > > the general crumminess of most schematic capture packages, > > where tools for ripping and re-numbering buses are > > palaeolithic, and re-use means working out how to bring > > up impenetrable property sheets instead of simply patching > > and commenting the generics on VHDL components. > > Just finished designing a large piece of logic to do with spread > spectrum comms. The Wishbone-compliant core was completely designed in > Xilinx's SysGen which can be thought of after all as a schematic > capture environment. Control was done in m-code statemachines. You get > the added benefit of having the feature-rich Matlab environment at > your disposal for testing and simulating the design. Arithmetic type > can't be specified more easily. And oh yeah, the core is parametrized > with a top-level dialogbox; a Simulink feature. I have to admit > though, naming the wires is a bit fiddly at times. But if your > competent enough in Simulink - which I'm not - I'm sure you can even > instantiate blocks programmatically - seen it before. One last thing: > the design met timing like magic. I suppose you can get the same > quality results with endless coregen invocations. This way you just > need to have your pick from the Xilinx blockset. I read from and wrote > back to Matlab's workspace in accordance to Wishbone bus cycles using > Stateflow (statemachine) objects in Simulink. After all you can plot > and run all sorts of diagnostics on the output within Matlab and life > couldn't be easier. Try to do that in VHDL. I'm sure you can - I love > VHDL by the way - but this way it's much faster and DSP-appropriate. Forgot to mention for the sake of historical credibility that there was one block that I couldn't parametrize in the whole design. It was a bitbasher block - for some reason, SysGen doesn't allow parametrization to be applied on this one. I'm sure in time the Xilinx folk will sort this out. You just need somebody to chase'em up on this. I have neither the stamina nor the credentials for this. -Momo
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