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
KJ schrieb: > "John_H" <newsgroup@johnhandwork.com> wrote in message > After all, there are many ways to code just a flip flop and the tools can > recognize all of those as well so you could rightly ask the same question > about how the tools detect a flip flop. Hmm. How about the naive way to code a flip-flop with enable in vhdl: if rising_edge(clk) and enable='1' then q <= d; end if; Does not work on any tool that I have seen. There was a paper on a GI workshop recently that greatly inproved what can be synthesized by doing VHDL->VHDL transformations by XML and XSLTs. But the VHDL compiler vendors apparently do not care. Kolja Sulimma cronologicArticle: 113526
Andy wrote: > Those clock inputs cannot be configured as LVPECL? I know general > purpose differential inputs can be LVPECL. You have to terminate on > board though. > My understanding of LVDS inputs is that you have a differential receiver that switches at the signal crossing point within the specified timing as long as your common mode voltage is within the databook spec. I haven't used Virtex-4 yet, but at least in earlier Xilinx parts the LVDS input common mode range was broad enough to support LVPECL. This will most likely depend on the VCCio for that bank. The datasheet seems to imply that you have the full GND to VCCio range for signal swing. Common mode range would be less.Article: 113527
Howard Long wrote: ... > I think what the OP is alluding to when saying that s/he's "multiplying it > with I and Q signals" is that the input signal's being mixed by a 50MHz > quadrature oscillator. That was also my guess, but I wanted it from him for two reasons; to be sure, so we don't go round in circles using different assumptions, and also to see if he knew enough about the system he wants to understand to be able to fill in the blocks in his block diagram. It's OK to treat those blocks as magic boxes until you have to implement them. Then not. > Rick Lyons' excellent treatise on the subject is here: > http://www.dspguru.com/info/tutor/QuadSignals.pdf. For me, this was one of > those articles you read where the penny miraculously drops. Yes. Rick has the gift of clarity. Jerry -- Engineering is the art of making what you want from things you can get. ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻArticle: 113528
"Kolja Sulimma" <news@sulimma.de> wrote in message news:4582b04f$0$30323$9b4e6d93@newsspool1.arcor-online.net... > KJ schrieb: >> "John_H" <newsgroup@johnhandwork.com> wrote in message > >> After all, there are many ways to code just a flip flop and the tools can >> recognize all of those as well so you could rightly ask the same question >> about how the tools detect a flip flop. > Hmm. How about the naive way to code a flip-flop with enable in vhdl: > if rising_edge(clk) and enable='1' then > q <= d; > end if; > > Does not work on any tool that I have seen. Gated clocks are well understood and supported by high-end synthesis tools like Precision and Synplify. If you synthesis the above circuit the enable gets connected to the FF CE input. Hans www.ht-lab.com > > There was a paper on a GI workshop recently that greatly inproved what > can be synthesized by doing VHDL->VHDL transformations by XML and XSLTs. > But the VHDL compiler vendors apparently do not care. > > Kolja Sulimma > cronologicArticle: 113529
Hal Murray wrote: > >I fully agree with John; get direct advice from someone versed in > >transmission line effects. For the LVDS inputs from PECL drive, I am > >surprised no-one from Xilinx has chipped in, but because I am > >interested, I'll pull the datasheet for V4 later on and see what it says > >about input range etc. > > The Xilinx people are probably on comp.arch.fpga Hoping they will chime in, I have added caf.Article: 113530
All, I have previously posted on the differential input circuit that we (Xilinx) use. I will repeat what I have said before: the differential input circuit is a full CMOS differential comparator. It will operate (function) from rail to rail on its inputs. Its performance has only been characterized for LVDS, and low voltage LVPECL common mode voltages and swings. Now for the new part: there are no configuration bits to select anything. The comparator is the comparator, and it is the same circuit regardless of standard selected. If it is differential, it is the same circuit. Hope this helps, AustinArticle: 113531
Hi A couple of months ago I had to move up to ISE 8.2 once 7.1 stopped meeting my timings. Since I moved I have had nothing but problems with project files and their corruption. I have finally settled on 8.2.3 as it appeared more stable than older patched versions. 8.2.0 was dire. The project file corruptions seem to occur randomly and will do various things, such as remove all files from the project (and not let you add them back), or not let you edit coregen parts, or a host of other things. Re-creating a project each time seems very laborious. Does anyone have any shortcuts to do this? Is there a TCL script that can be run? Archiving and Project Cleanup don't help. The project is a mix of VHDL, verilog and coregen parts (xaw and xco). Why can't they just implement project files as text files and let you control them by hand? Regards MarcArticle: 113532
Hi A couple of months ago I had to move up to ISE 8.2 once 7.1 stopped meeting my timings. Since I moved I have had nothing but problems with project files and their corruption. I have finally settled on 8.2.3 as it appeared more stable than older patched versions. 8.2.0 was dire. The project file corruptions seem to occur randomly and will do various things, such as remove all files from the project (and not let you add them back), or not let you edit coregen parts, or a host of other things. Re-creating a project each time seems very laborious. Does anyone have any shortcuts to do this? Is there a TCL script that can be run? Archiving and Project Cleanup don't help. The project is a mix of VHDL, verilog and coregen parts (xaw and xco). Why can't they just implement project files as text files and let you control them by hand? Regards MarcArticle: 113533
Are you using any type of operating system to do the reading and writing?Article: 113534
"Austin Lesea" <austin@xilinx.com> wrote in message news:eluk9r$fjj2@cnn.xsj.xilinx.com... > All, > > I have previously posted on the differential input circuit that we > (Xilinx) use. > > I will repeat what I have said before: the differential input circuit > is a full CMOS differential comparator. It will operate (function) from > rail to rail on its inputs. Its performance has only been characterized > for LVDS, and low voltage LVPECL common mode voltages and swings. > > Now for the new part: there are no configuration bits to select > anything. The comparator is the comparator, and it is the same circuit > regardless of standard selected. If it is differential, it is the same > circuit. > > Hope this helps, > > Austin FWIW, I think the OP is talking about the MGT clock inputs. But the same applies, I guess. Cheers, Syms.Article: 113535
Tommy Thorn wrote: > Peter Alfke wrote: > >>In an asynchronous FIFO, reading and writing is controlled by two >>counters with independent clocks. >>If you need to detect FULL or EMPTY, you compare the two counters for >>identity. >>If you do that with binary counters, you are vulnerable to strange >>decoding glitches, while multiple binary bits change (almost, but not >>quite, simultaneously). You never have that problem with Gray counters, >>where only one bit changes, from one state to the next. > > > How about a different way? Couldn't one simply maintain two views (one > for each clock) of the state of the FIFO, always a conservative > approximation to the "true" state, and use standard handshake > techniques to communicate to the writer "since our last handshake, I've > dequeued X words", and visa versa. > > The advantage of this (besides simplicity) is that one can pipeline the > handshake arbitrarily much, only at the expense of added latency > between full->non-full and empty->non-empty transitions. > > Isn't this a standard technique? > > Tommy > I've used similar techniques. Basically, an alternative to using gray code is to maintain population counts that are separate from the read and write pointers, and then resynchronizing the write event for a read side population count and/or resynchronizing the read event for a write side population count. The things to watch are 1: you need to make sure that read or write events can't overrun the flag in your system. This can happen if, for example, you write twice between successive read clock edges. So, yes, this is a viable alternative, it will sometimes save some logic, can result in higher speeds, but it also carries with it a responsibility for the user to make sure the event flags don't overrun.Article: 113536
Symon, Thanks for pointing this out -- I was answering the wrong question! Unfortunately, no, my previous post does not apply to the dedicated clock inputs for the MGTs. Those differential comparators are designed to their own specific requirements. However, I do believe they operate for LVDS or low voltage PECL (2.5V). I would have to go read the data sheet, and also the MGT user's guide. AustinArticle: 113537
Antti, I think he wanted to ask for the prices for the Spartan-3A. I also could not find any prices for it. Luiz CarlosArticle: 113538
First to Peter, my comment was definitely not intended as a critism of the Async FIFO in Virtex, but as an alternative to consider for the OP. Ray Andraka wrote: > I've used similar techniques. Basically, an alternative to using gray > code is to maintain population counts that are separate from the read > and write pointers, and then resynchronizing the write event for a read > side population count and/or resynchronizing the read event for a write > side population count. That was the idea, although I'm suggesting communicating deltas rather than absolute values (ie, how many elements read / written respectively). It may be the same, but it seems more intuitive. I admit I have never done it so I was looking for the potential pitfalls. > The things to watch are 1: you need to make sure > that read or write events can't overrun the flag in your system. This > can happen if, for example, you write twice between successive read > clock edges. I'm not sure I follow. As writing (like reading) follow a local, synchronous, conservative approximation that would be updated for each write, what would stop me from adding logic to drop the write if I deem the FIFO full? BTW, what were the other things to look out for? :-) > So, yes, this is a viable alternative, it will sometimes > save some logic, can result in higher speeds, but it also carries with > it a responsibility for the user to make sure the event flags don't overrun. Thanks, TommyArticle: 113539
Hi all, I was abble to compile working uClinux core for the Spartan-3e Starter Kit. I was abble to program on board Flash Memory so the system.bit starts by itself. Can anyone help me with the bootloader, so the whole project may start after power-on? I need to place the system.bit and linux core somewhere on the board so it may boot by itself... Thanks Jerzy jerz.zielinski@gmail.comArticle: 113540
I want to drive a LVPECL_25 input on a bank with VCCO=2.5V with a 3.3V LVPECL signal. Xilinx has a nice app note on doing this with a Virtex ii and a Spartan 3, but I can't find anything concrete about doing it on a Virtex-4. Would you agree that it's safe to implement the same solution on a Virtex-4? Here's the app note: http://www.xilinx.com/bvdocs/appnotes/xapp696.pdf See page 4. It's just a voltage divider. Are there any adverse effects to this? Thanks, DaleArticle: 113541
I can: -make (and use succesfully) .bit files under Xilinx WebPack 8.2.03i *unless* the design contains RAM- whether I specify it in Verilog, or use CoreGen to specify it. I can: -use Verilog-defined memories if I compile under Synplify Pro, bring the resulting file into WebPack and place,route, and generate .bit file there. I can't: -use memories under WebPack- place and route is OK, but "Generate Programming File" fails with no error messages. This happens under XP Pro and WIn2000. What am I doing wrong? -- Per ardua ad nauseamArticle: 113542
Tommy Thorn wrote: > First to Peter, my comment was definitely not intended as a critism of > the Async FIFO in Virtex, but as an alternative to consider for the OP. > > Ray Andraka wrote: > >>I've used similar techniques. Basically, an alternative to using gray >>code is to maintain population counts that are separate from the read >>and write pointers, and then resynchronizing the write event for a read >>side population count and/or resynchronizing the read event for a write >>side population count. > > > That was the idea. I admit I have never done it so I was looking for > the potential pitfalls. > > >>The things to watch are 1: you need to make sure >>that read or write events can't overrun the flag in your system. This >>can happen if, for example, you write twice between successive read >>clock edges. > > > I'm afraid I don't follow. As writing (resp. reading) follow a local, > synchronous, conservative approximation how could it overrun? The > "flag" as I understand it is direct function of the local counter so it > would be updated for each write. > > BTW, what were the other things to look out for? :-) > > >>So, yes, this is a viable alternative, it will sometimes >>save some logic, can result in higher speeds, but it also carries with >>it a responsibility for the user to make sure the event flags don't overrun. > > > Thanks, > Tommy > OK, for example, if the write clock is at 10 MHz and the read clock is at 5 MHz, if you wrote on 2 consecutive write clocks, then synchronizing them to the read clock domain, you'd lose one or both of the write events. In order for this set-up to work, you need to guarantee that whatever signal you send across the clock domain boundary to indicate a write event or events is infrequent enough to be reliably sensed in the other domain for every single event. If there is a possibility of writing too frequently, then you need some sort of signaling scheme that can indicate a certain number of writes occurred and update the population count accordingly. If the clocks for both sides are similar frequencies, you need at least one clock between events to get a clean crossing. This extra care to make sure you don't have events happen too quickly for reliable operation is the reason the shrink wrapped FIFO components use the gray code schemes.Article: 113543
On Fri, 15 Dec 2006 08:59:38 -0800, Austin Lesea <austin@xilinx.com> wrote: >All, > >I have previously posted on the differential input circuit that we >(Xilinx) use. > >I will repeat what I have said before: the differential input circuit >is a full CMOS differential comparator. It will operate (function) from >rail to rail on its inputs. Its performance has only been characterized >for LVDS, and low voltage LVPECL common mode voltages and swings. > >Now for the new part: there are no configuration bits to select >anything. The comparator is the comparator, and it is the same circuit >regardless of standard selected. If it is differential, it is the same >circuit. > >Hope this helps, > >Austin It is, incidentally, a *very good* comparator! JohnArticle: 113544
Dale, This will work. Some care is required to keep everything short (try not to create stubs that cause reflections). Figure 4 is the DC divider, or Figure 6 is the AC coupling solution (both will work). AC coupling may be an issue if the signals are not balanced (more 0's than 1's or more 1's than 0's). Works for S3, S3E, S3A, V4 and V5. Austin (Xilinx ICDES) > I want to drive a LVPECL_25 input on a bank with VCCO=2.5V with a 3.3V > LVPECL signal. Xilinx has a nice app note on doing this with a Virtex > ii and a Spartan 3, but I can't find anything concrete about doing it > on a Virtex-4. Would you agree that it's safe to implement the same > solution on a Virtex-4? > > Here's the app note: > http://www.xilinx.com/bvdocs/appnotes/xapp696.pdf > See page 4. > > It's just a voltage divider. Are there any adverse effects to this? > > Thanks, > Dale >Article: 113545
In looking at the Virtex-4 documentation for the PMCD, Xilinx shows a simple connection from the DCM to the PMCD. They don't show the clocking for the reset signal going into the PMCD even though the Xilinx doc says that the reset should be released synchronously to with the clock. If the DCM and the PMCD both get the same reset signal, I assume that since the DCM output clocks should be stopped while reset is asserted, inherently the release of reset will be synchronous to the clock since the clock won't be running at the time. Does this match other people's understanding? Thanks! John ProvidenzaArticle: 113546
Ray Andraka wrote: > OK, for example, if the write clock is at 10 MHz and the read clock is > at 5 MHz, if you wrote on 2 consecutive write clocks, then synchronizing > them to the read clock domain, you'd lose one or both of the write > events. Thanks Ray. I'm sorry to persist, but I still can't agree. When the writer writes the first item we can have one of several situations, including: - The reader has yet to acknowledge some messages prior to this write. No update will be sent until it does. The writes writes another item and updates its local count. Once the reader finally acknowledges the original message, the writer sends a "2 written" message. - The writer wasn't waiting and goes ahead with a "1 written" message. The reader updates it's local count and acknowledges that it saw "1 written" message. The writer writes again etc. - The writer wasn't waiting and goes ahead with a "1 written" message. The reader doesn't pick up the message in time before the writer writes to the FIFO again. No worries. Once the reader finally acknowledges the "1 written", the writer can issue a new message to the reader with the delta between the writers current count and the writers count at the time of the last message, thus including the write that just happend. > In order for this set-up to work, you need to guarantee that > whatever signal you send across the clock domain boundary to indicate a > write event or events is infrequent enough to be reliably sensed in the > other domain for every single event. IMHO, any scheme depending on such an assumption is broken (it's too easy to forget this assumption when the design is revised a year later). I make no assumption on the relative speed of writers and readers. I do assume that no messages will be dropped/missed, but that assumption can also be removed with more work. > If there is a possibility of > writing too frequently, then you need some sort of signaling scheme that > can indicate a certain number of writes occurred and update the > population count accordingly. I beleive that's what I suggested. Thanks Tommy > If the clocks for both sides are similar > frequencies, you need at least one clock between events to get a clean > crossing. This extra care to make sure you don't have events happen too > quickly for reliable operation is the reason the shrink wrapped FIFO > components use the gray code schemes.Article: 113547
John, Yes. The PMCD is simply some D type flip flops, with a delay matched path for the 1X output. If the phases of the divided clocks are important, then reset of the PMCD is useful. If the phases are not important, don't even bother with the reset of the PMCD. When the PCM input clock is driven by the DCM, one should not worry about the reset, as you say, the DCM will not do anything 'bad' to the PMCD while reset is asserted. Austin johnp wrote: > In looking at the Virtex-4 documentation for the PMCD, Xilinx shows a > simple > connection from the DCM to the PMCD. They don't show the clocking for > the > reset signal going into the PMCD even though the Xilinx doc says that > the > reset should be released synchronously to with the clock. > > If the DCM and the PMCD both get the same reset signal, I assume that > since the > DCM output clocks should be stopped while reset is asserted, inherently > the > release of reset will be synchronous to the clock since the clock won't > be running > at the time. > > Does this match other people's understanding? > > Thanks! > > John Providenza >Article: 113548
marc_ely wrote: > Hi > > A couple of months ago I had to move up to ISE 8.2 once 7.1 stopped > meeting my timings. Since I moved I have had nothing but problems with > project files and their corruption. > I have finally settled on 8.2.3 as it appeared more stable than older > patched versions. 8.2.0 was dire. > > The project file corruptions seem to occur randomly and will do various > things, such as remove all files from the project (and not let you add > them back), or not let you edit coregen parts, or a host of other > things. > > Re-creating a project each time seems very laborious. Does anyone have > any shortcuts to do this? Is there a TCL script that can be run? > Archiving and Project Cleanup don't help. > > The project is a mix of VHDL, verilog and coregen parts (xaw and xco). > > Why can't they just implement project files as text files and let you > control them by hand? > > Regards > Marc The 8.2 project navigator can still read the old text style .npl files. If you have a copy of 6.3 or older ISE you can see how these project files look. There is a caveat. When you open a .npl file from 8.2, ISE not only converts the project to the new format and creates an .ise file, but it also trashes the .npl file. So always keep another copy for re-building the project after a crash. HTH, GaborArticle: 113549
Austin - Thanks for the clarification. John Providenza Austin Lesea wrote: > John, > > Yes. > > The PMCD is simply some D type flip flops, with a delay matched path for > the 1X output. If the phases of the divided clocks are important, then > reset of the PMCD is useful. If the phases are not important, don't > even bother with the reset of the PMCD. When the PCM input clock is > driven by the DCM, one should not worry about the reset, as you say, the > DCM will not do anything 'bad' to the PMCD while reset is asserted. > > Austin > > johnp wrote: > > In looking at the Virtex-4 documentation for the PMCD, Xilinx shows a > > simple > > connection from the DCM to the PMCD. They don't show the clocking for > > the > > reset signal going into the PMCD even though the Xilinx doc says that > > the > > reset should be released synchronously to with the clock. > > > > If the DCM and the PMCD both get the same reset signal, I assume that > > since the > > DCM output clocks should be stopped while reset is asserted, inherently > > the > > release of reset will be synchronous to the clock since the clock won't > > be running > > at the time. > > > > Does this match other people's understanding? > > > > Thanks! > > > > John Providenza > >
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