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
Hello! I have an app where I have byte-wide data coming in at 125 MHz,
and a system clock running at 125 Mhz, but they're not driven by the
same source (alas). Thus, the source clock could be slightly faster
or slightly slower than the internal system clock. Is there a standard
way of dealing with these sorts of clock-async issues that doesn't
involve an asynchronous FIFO?
I would just use one of the standard FIFOs discussed in the xilinx app
notes and save myself some time and headache, but I read something at
free-ip (http://www.free-ip.com/ramlib/fifo.html) suggesting that the
implementation in the app-notes was patented, and thus even a
reimplementation of their approach wouldn't be allowed in an
open-source hardware project.
So, I was hoping there might be some non-FIFO implementation that
might work :) Are there any classical approaches to this?
...Eric
Article: 59651Hi, I have noticed that in my Spartan IIe 200 designs there are a lot of logic one and zero nets, on the order of 150 nets. I looked at where these nets go and discovered that a lot, not all, of these nets could be replace by properly configuring the slices and tri-state devices. For example a GLOBAL_LOGIC1 signal will go to a slice configured as a fast carry chain the signal goes to a 4 to 1 configuration mux that can have as it's inputs: a direct in , an AND gate output, a logic one or a logic zero. Instead of using the logic one or zero position on the mux, it uses this GLOBAL_LOGIC1 net. Can anyone explain why this is done. BTW my design is in verilog and I use XST for the synthesis and all my adders and counters are behavioral models. It appears XST does the right thing with them. I have noticed that the internal tri-state devices have some configuration capability Both the enable input and data input have 4 to 1 selection mux. These muxes allow you to select the signal in, the compliment of the signal, a one or a zero. I did not see anything in the data sheet about these configuration options, and again a GLOBAL_LOGIC1 signal will be routed to a tri-state device when configuring the mux would do the same thing. I would like to get rid of the extra nets because it takes up resources both slices and routing that I really need. Thank you Dave ColsonArticle: 59652
Hi Martin, TIG should work, if not, you could always try a MCP (multicycle path constraint) if you know how many times your data is sampled. Anil "Allan Herriman" <allan.herriman.hates.spam@ctam.com.au.invalid> wrote in message news:3f49e539@dnews.tpgi.com.au... > Martin Euredjian wrote: > > The constraint guide indicates that the TIG constraint can be used in HDL > > (Verilog in my current design). However, an attempt to use it produces the > > following error: > > > > ERROR:Xst:1582 - The constraint 'tig=' is not supported neither in BEGIN > > MODEL/END section in the XCF file, nor in HDL code. > > > > I have not been able to find further information on this error message or > > issue in the Xilinx site. Does anyone know if TIG is truly supported in > > HDL? I'd hate to place it in the UCF file, to me it feels much more > > approprite to have this constraint move with the HDL source. > > > > The form I'm using is: > > > > // synthesis attribute TIG of <net_name> is ""; > > > > As a point of interest, the nets in question are the output of the registers > > of a microprocessor interface. The values are only sampled a few times per > > second by the receiving module. There is not need to have any of these nets > > meet nanosecond level timing constraints as other parts of the design must. > > Is there a better approach than "TIG"? > > Hi Martin, > > I think this old thread answers your question: > http://groups.google.com/groups?threadm=3dbd0daa%241_1%40lon-news.intensive. net > > Regards, > Allan. >Article: 59653
> The constraint guide indicates that the TIG constraint can be used in HDL > (Verilog in my current design). However, an attempt to use it produces the > following error: > > ERROR:Xst:1582 - The constraint 'tig=' is not supported neither in BEGIN > MODEL/END section in the XCF file, nor in HDL code. > > I have not been able to find further information on this error message or > issue in the Xilinx site. Does anyone know if TIG is truly supported in > HDL? I'd hate to place it in the UCF file, to me it feels much more > approprite to have this constraint move with the HDL source. > > The form I'm using is: > > // synthesis attribute TIG of <net_name> is ""; > Using: // synthesis attribute TIG of <net_name> is "TRUE"; makes the error go away. Is there a way to verify that the net is being ignored for timing purposes? The log says: Set user-defined property "TIG = TRUE" for signal <signal_name>. Being that the constraints guide does not list "TRUE" as a valid value I'd like verification that the constraint is truly doing something useful. Thanks, -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Martin Euredjian To send private email: 0_0_0_0_@pacbell.net where "0_0_0_0_" = "martineu"Article: 59654
IMHO these tools are very expensive and for my needs I am better with placement constraints by hand then using these tools. This gives me even better control and saves me time and money. But your needs may be different. To be honest I don't see the benefit of e.g. Amplify which would be worth the money. BR Chris Alfredo wrote: > Thanks Neeraj, I have some notion of the benefits of these tools but I do not > fully understand how to differentiate them and how to choose one for a specific > task: which one is better for IP immersion, which one help manage better for > stitching blocs at the top level (modular design), which one interfaces better > with STA tools for timing closure, ... > I think I'll need to run some testbenches to get a good grasp on these tools and > how to better use them. > > Does anyone have a book or documetation that I can read to learn more about this > subject? > > The only documentation I have now is what the vendors are providing. > > Thanks, > > *** > Alfredo. > > "Neeraj Varma" <neeraj@cg-coreel.com> wrote in message > news:bidh5u$8762p$1@ID-159439.news.uni-berlin.de... > >>The Physical synthesis and SVP tools from 3rd parties are not just mere >>Floorplanners. In a nutshell, Amplify and Precision Physical do something >>called "Placement Aware Synthesis", which is the most important thing to do >>to bring down the routing delays...whereas SVP tools like the one from Hier >>help provide final representation of the PLD design early in the design >>stage. >> >>Floorplanning is just one of the many features built into these tools, >>though an important one, to help achieve performance goals and reducing the >>compile time of the design by working closely with the P&R tools... >> >>Feel free to correct me if I am wrong... >> >>--Neeraj >> >> >> >> >> >> >> >> >> >>"Alfredo" <alherrer@nortelnetworks.com> wrote in message >>news:bid6ib$mfa$1@zcars0v6.ca.nortel.com... >> >>>Hi, >>>physical synthesis tools for FPGAs are being introduced by a few vendors. >> >>Have >> >>>you read, evaluated or seen a presentation about these tools: >>>Synplicity's Amplify: >> >>http://www.synplicity.com/products/amplify/index.html >> >>>Mentor's Precision: http://www.mentor.com/precisionphysical/ >>>Hier Design's Plan Ahead: http://www.hierdesign.com >>> >>>Do you have any thoughts about what you would be looking for in an FPGA >>>floorplanner from a 3rd party (not the FPGA manufacturer)? >>> >>>Do you use Altera's or Xilinx floorplanner now? >>> >>>Thanks for you input, >>> >>>*** >>>Alfredo. >>> >>> >> >> > >Article: 59655
As far as cost goes, it again comes down to what you are trying to achieve. Many times, the cost of the tools could be justified easily by showing the savings - for example, saving a speedgrade (use a slower speedgrade part) by the use of physical synthesis has a great impact on the total cost of your board. Using placement constraints is okay if you are trying to meet timing on certain small sections of the designs AND you know if these are going to be the bottleneck. It is not feasible to do this if you have a big design that is using 90+% of the slices/LEs etc. As FPGAs are getting bigger and can accomodate complex designs, there are newer physical synthesis tools in the market that have different approaches to solving the timing closure issue. It is definitely worthwhile to check them out. "Christian Schneider" <cgs-news@cgschneider.com> wrote in message news:bidt5i$83ehs$1@ID-68826.news.uni-berlin.de... > IMHO these tools are very expensive and for my needs I am better with > placement constraints by hand then using these tools. This gives me even > better control and saves me time and money. But your needs may be > different. To be honest I don't see the benefit of e.g. Amplify which > would be worth the money. > > BR Chris > > > Alfredo wrote: > > > Thanks Neeraj, I have some notion of the benefits of these tools but I do not > > fully understand how to differentiate them and how to choose one for a specific > > task: which one is better for IP immersion, which one help manage better for > > stitching blocs at the top level (modular design), which one interfaces better > > with STA tools for timing closure, ... > > I think I'll need to run some testbenches to get a good grasp on these tools and > > how to better use them. > > > > Does anyone have a book or documetation that I can read to learn more about this > > subject? > > > > The only documentation I have now is what the vendors are providing. > > > > Thanks, > > > > *** > > Alfredo. > > > > "Neeraj Varma" <neeraj@cg-coreel.com> wrote in message > > news:bidh5u$8762p$1@ID-159439.news.uni-berlin.de... > > > >>The Physical synthesis and SVP tools from 3rd parties are not just mere > >>Floorplanners. In a nutshell, Amplify and Precision Physical do something > >>called "Placement Aware Synthesis", which is the most important thing to do > >>to bring down the routing delays...whereas SVP tools like the one from Hier > >>help provide final representation of the PLD design early in the design > >>stage. > >> > >>Floorplanning is just one of the many features built into these tools, > >>though an important one, to help achieve performance goals and reducing the > >>compile time of the design by working closely with the P&R tools... > >> > >>Feel free to correct me if I am wrong... > >> > >>--Neeraj > >> > >> > >> > >> > >> > >> > >> > >> > >> > >>"Alfredo" <alherrer@nortelnetworks.com> wrote in message > >>news:bid6ib$mfa$1@zcars0v6.ca.nortel.com... > >> > >>>Hi, > >>>physical synthesis tools for FPGAs are being introduced by a few vendors. > >> > >>Have > >> > >>>you read, evaluated or seen a presentation about these tools: > >>>Synplicity's Amplify: > >> > >>http://www.synplicity.com/products/amplify/index.html > >> > >>>Mentor's Precision: http://www.mentor.com/precisionphysical/ > >>>Hier Design's Plan Ahead: http://www.hierdesign.com > >>> > >>>Do you have any thoughts about what you would be looking for in an FPGA > >>>floorplanner from a 3rd party (not the FPGA manufacturer)? > >>> > >>>Do you use Altera's or Xilinx floorplanner now? > >>> > >>>Thanks for you input, > >>> > >>>*** > >>>Alfredo. > >>> > >>> > >> > >> > > > > >Article: 59656
On a sunny day (Sun, 24 Aug 2003 18:33:25 GMT) it happened "michele bergo" <michelebergo@libero.it> wrote in <Vx72b.262458$Ny5.8069636@twister2.libero.it>: >I want to interface altera cyclone(3.3V) to the pc parallel port(5V). Is it >possible without using further external devices? > >Thanks > > > > I have noticed (measure a logic 1) that my PC parallel port (and it is no laptop) gives about 3.3 V.Article: 59657
In article <uepkkvo2rn871sjbdij3ltjsjes72nmfjj@4ax.com>, Bob Perlman <bobsrefusebin@hotmail.com> wrote: >On Mon, 25 Aug 2003 18:25:30 +0000 (UTC), >nweaver@ribbit.CS.Berkeley.EDU (Nicholas C. Weaver) wrote: > >>In article <3F4A4A96.18037049@xilinx.com>, >>Peter Alfke <peter@xilinx.com> wrote: >>>Sounds reasonable to me... >>>Peter Alfke >> >>Just realized. How does a LUT input react to a metastable input (to >>do the voting circuit)? > >Voting circuits don't work as a metastability cure. Imagine a >2-out-of-3 circuit that's looking at three flip-flops. If one FF is >HIGH, another is LOW, and the third is metastable, what's the output >of the voting circuit? As long as the voting circuit output is consistant LOW or HIGH, it doesn't really matter, at least in the context given. If the voting circuit output is metastable, then thats problematic. >Back in the early 80's, UCSD professor Leonard Marino wrote a paper in >which he very thoroughly analyzed a number of alleged metastability >cures, one of which was the voting circuit. I can't find my copy of >the paper, but it must have appeared in IEEE Transactions on >Computers. > >Bob Perlman >Cambrian Design Works -- Nicholas C. Weaver nweaver@cs.berkeley.eduArticle: 59658
On Mon, 25 Aug 2003 21:31:53 +0000 (UTC), nweaver@ribbit.CS.Berkeley.EDU (Nicholas C. Weaver) wrote: >In article <uepkkvo2rn871sjbdij3ltjsjes72nmfjj@4ax.com>, >Bob Perlman <bobsrefusebin@hotmail.com> wrote: >>On Mon, 25 Aug 2003 18:25:30 +0000 (UTC), >>nweaver@ribbit.CS.Berkeley.EDU (Nicholas C. Weaver) wrote: >> >>>In article <3F4A4A96.18037049@xilinx.com>, >>>Peter Alfke <peter@xilinx.com> wrote: >>>>Sounds reasonable to me... >>>>Peter Alfke >>> >>>Just realized. How does a LUT input react to a metastable input (to >>>do the voting circuit)? >> >>Voting circuits don't work as a metastability cure. Imagine a >>2-out-of-3 circuit that's looking at three flip-flops. If one FF is >>HIGH, another is LOW, and the third is metastable, what's the output >>of the voting circuit? > >As long as the voting circuit output is consistant LOW or HIGH, it >doesn't really matter, at least in the context given. If the voting >circuit output is metastable, then thats problematic. True on both counts. But how do you do make the output stable? This is the point at which folks have tried adding hysteresis, etc. And we've all been down that road before, I think. Bob Perlman Cambrian Design WorksArticle: 59659
I have never seen strange levels or oscillations ( well, 25 years ago we had TTL oscillations). Metastability just affects the delay on the Q output. Your suggestion seems to be to do exactly what one "should not do," namely use multiple synchronization flip-flops with tiny input routing delay differences, and then do majority voting on the three outputs. Seems like a smart idea, because it does not waste extra latency. Peter Alfke, Xilinx ====================== "Nicholas C. Weaver" wrote: > > Just realized. How does a LUT input react to a metastable input (to > do the voting circuit)? > -- > Nicholas C. Weaver nweaver@cs.berkeley.eduArticle: 59660
Hi Antti, Antti Lukats wrote: > John Williams <jwilliams@itee.uq.edu.au> wrote in message news:<biblqa$206$1@bunyip.cc.uq.edu.au>... > >>Microblaze uClinux Demo Package Released >>---------------------------------------- >> >>We are pleased to announce the first public release of the Microblaze >>uClinux demo package, available for download from the project web site: >> >>http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux > > > question: if I take the mbvanilla EDK project from your website and > recompile it for example for ML300 would it work with the supplied > linux bootimage? I mean if I keep all the peripherals the same > as in the vanilla design, or is the hardware in the supplied .bit > images from some other design? It will indeed work - the demo bit file is just mbvanilla targetting the V2MB1000. Just make sure you keep the address map the same, eg the location of your main RAM bank, which the kernel expects to find at 0x80000000, for 16 Mb. Also the bootloader expects there to be AMD-style flash at 0xFF000000. The source of the bootloader comes with the mbvanilla project so you should have no trouble changing that if necessary. I'm going to freeze the mbvanilla design today, time to move on to the next target, so if you check on the website soon you'll find a "golden" copy of it that should be very eay to port. I haven't played with an ML300 but if it has similar resources to the V2MB1000 then it should just be a matter of changing the ucf file and resynthesising. I'd be keen to host the ML300 version of mbvanilla once you're done. Regards, JohnArticle: 59661
"Jim Kearney" <replace.this.with.my.forename@jkearney.com> wrote in message news:<Exq2b.255714$YN5.175023@sccrnsc01>... > > > pablobleyer@hotmail.com (Pablo Bleyer Kocik) wrote in message > news:<bb2f07d6.0308242212.6707fd90@posting.google.com>... > > > > Hello. > > > > > > > > I have a Spartan-II device connected to a small 5V micro which does > > > > the configuration process. I want to multiplex the same micro's pin > > > > for CCLK generation during Spartan-II configuration and as a timer > > > > output to another device after that. The CCLK signal is 5V -- I know > > I think what's he's asking is whether the FPGA will care if the CCLK line is > toggling after configuration - note the phrase "same micro's pin ... output > to another device after". > > AFAIK, This would be no problem - the FPGA ignores CCLK after its DONE goes > active so that a chained serial configuration mode works. Exactly, this is what I was referring to. Sorry if it was not clear. I want to share the same CCLK line for another purpose after the FPGA has been configured. This will be a toggling 5V signal. Will the (sleeping) CCLK will have any concerns with that? Thanks again. Regards.Article: 59662
Rickman et al,
This is indeed fairly common. The manufacturer specifies the interface timing
only relative to signals on that interface, not relative to the DSP clock. This
often shows up on memory interfaces intended for static async RAM memory, for
example. In that case, the timing is all relative to the address, write pulse
and data and nearly never in relation to a clock. As Rickman points out, there
is no valid assumption you can make about the relationship to the DSP clock
other than the fact that these signals are synchronous to the clock unless it is
specified in the data sheet. Where it is not, even the manufacturer can't tell
you what the timing is because they don't characterize it. OK, so how do you
deal with it?
The trick is to make your interface look like the intended device, which can be
tricky with an FPGA. For writes, you can use write strobe as a clock signal
into the FPGA, and use that then to clock the address/data coming in from the
CPU. I use an additional toggle flip-flop to indicate when data has written by
changing state. Sync the toggle signal to your local clock, then use a state
machine to produce a 1 clock pulse in response to the toggle changing state, and
that 1 clock pulse then enables registers that copy the input registers to
locally clocked registers. Works fine like that if the input rate is lower than
the local clock by a factor of 3 or more. If less, then you need to be a bit
more clever about catching multiple writes then transferring more than one word
on one local clock.
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 59663If you have to cope with frequency differences ( not just unknown phase ), then a FIFO is your only choice. And you have to have a strategy for FIFO overflow/underflow, which will inevitably happen. A Xilinx patent should never be a hindrance to implement such a FIFO in a Xilinx device. Obviously. Using a dual-ported RAM for a FIFO is straightforward. The trickery is in the implementation of FULL and EMPTY signals ( or also ALMOST FULL and ALMOST EMPTY ). Peter Alfke (invented the first integrated circuit FIFO, the Fairchild 3341, in 1971) ================== Eric wrote: > > Hello! I have an app where I have byte-wide data coming in at 125 MHz, > and a system clock running at 125 Mhz, but they're not driven by the > same source (alas). Thus, the source clock could be slightly faster > or slightly slower than the internal system clock. Is there a standard > way of dealing with these sorts of clock-async issues that doesn't > involve an asynchronous FIFO? > > I would just use one of the standard FIFOs discussed in the xilinx app > notes and save myself some time and headache, but I read something at > free-ip (http://www.free-ip.com/ramlib/fifo.html) suggesting that the > implementation in the app-notes was patented, and thus even a > reimplementation of their approach wouldn't be allowed in an > open-source hardware project. > > So, I was hoping there might be some non-FIFO implementation that > might work :) Are there any classical approaches to this? > ...EricArticle: 59664
Hi Peter,
Compared to what this guy's research is about, maybe Xilinx's
present CMOS is slow! Try googling for SiGe FPGA. Very interesting.
Syms.
Peter Alfke <peter@xilinx.com> wrote in message news:<3F4A3115.97553C14@xilinx.com>...
> What do you mean by "context switch"?
> And, CMOS is not slow. We build 10 gigabit/second serial interfaces; and
> the LUT and flip-flop response is well below 1 ns. Do you call that "slow"?
>
> Peter Alfke, Xilinx
> ===========================
> Kuan Zhou wrote:
> >
> > Hi,
> > I am wondering how fast can the Virtex does the context switch.
> > I heard it's slow because the CMOS response very slowly. Is it true?
> >
> > Thank you very much!
> >
> > sincerely
> > -------------
> > Kuan Zhou
> > ECSE department
Article: 59665
It infers a ripple carry adder using the fast carry chains. The FPGAs
have special logic for implementing fast ripple carry (they actually do a
2 bit carry look-ahead in hardware, but that is invisible to the user).
Other carry schemes are forced to use the much slower general purpose
routing and logic. In most cases, the adder built using the fast carry
chains is not only the minimum area, it is also the maximum performance.
Nagaraj wrote:
> Hi all,
> I am using XST (ISE 5.1i sp3) for my logic synthesis. If I write a
> piece of VHDL code as in " c <= a + b ", an N-bit adder will be
> inferred (assuming a,b,c are N bits).
> As there are many types of adder algorithms/implementations
> available (like Carry Look Ahead, Carry Save etc.), I want to know
> which one does XST infer? Can I have a control over the type of adder
> ?
>
> Regards,
> Nagaraj
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 59666Sure, I could use multi-cycle in the UCF (or TIF, for that matter). For maintainability (and reusability) purposes I wanted to include these and other constraints with the HDL file. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Martin Euredjian To send private email: 0_0_0_0_@pacbell.net where "0_0_0_0_" = "martineu" "Anil Khanna" <anil_khanna@mentor.com> wrote in message news:3f4a72c4$1@solnews.wv.mentorg.com... > Hi Martin, > > TIG should work, if not, you could always try a MCP (multicycle path > constraint) if you know how many times your data is sampled. > > Anil > > "Allan Herriman" <allan.herriman.hates.spam@ctam.com.au.invalid> wrote in > message news:3f49e539@dnews.tpgi.com.au... > > Martin Euredjian wrote: > > > The constraint guide indicates that the TIG constraint can be used in > HDL > > > (Verilog in my current design). However, an attempt to use it produces > the > > > following error: > > > > > > ERROR:Xst:1582 - The constraint 'tig=' is not supported neither in BEGIN > > > MODEL/END section in the XCF file, nor in HDL code. > > > > > > I have not been able to find further information on this error message > or > > > issue in the Xilinx site. Does anyone know if TIG is truly supported in > > > HDL? I'd hate to place it in the UCF file, to me it feels much more > > > approprite to have this constraint move with the HDL source. > > > > > > The form I'm using is: > > > > > > // synthesis attribute TIG of <net_name> is ""; > > > > > > As a point of interest, the nets in question are the output of the > registers > > > of a microprocessor interface. The values are only sampled a few times > per > > > second by the receiving module. There is not need to have any of these > nets > > > meet nanosecond level timing constraints as other parts of the design > must. > > > Is there a better approach than "TIG"? > > > > Hi Martin, > > > > I think this old thread answers your question: > > > http://groups.google.com/groups?threadm=3dbd0daa%241_1%40lon-news.intensive. > net > > > > Regards, > > Allan. > > > >Article: 59667
Ray Andraka wrote: >Rickman et al, > >This is indeed fairly common. The manufacturer specifies the interface timing >only relative to signals on that interface, not relative to the DSP clock. This >often shows up on memory interfaces intended for static async RAM memory, for >example. In that case, the timing is all relative to the address, write pulse >and data and nearly never in relation to a clock. As Rickman points out, there >is no valid assumption you can make about the relationship to the DSP clock >other than the fact that these signals are synchronous to the clock unless it is >specified in the data sheet. Where it is not, even the manufacturer can't tell >you what the timing is because they don't characterize it. > Well, just because the manufacturer isn't putting the info in the data sheets, and don't test for it, I suspect that you could get a rough description that could be quite helpful. Knowing, for instance, that the strobes will always follow a CPU clock by at least 1 ns, and never change than 5 nS after the clock, would make designing a synchronous memory/peripheral controller running from the same clock a lot simpler. If you can just get the roughest of descriptions of the clock vs. strobes circuitry, you can improve the system performance greatly, because you don't have to have ranked FFs on every strobe. Now, on the high speed stuff, with clock multipliers, etc. it can get quite complex, and a CPU swap to the next higher speed can throw everything off due to a change in clock multiplier. But, I gathered from the initial post that this wasn't a clock multiplied CPU. JonArticle: 59668
Bob Perlman wrote: > Voting circuits don't work as a metastability cure. I agree. The odds that one synchronizer will work without error is always better than the odds that two synchronizers will work without error. The voting circuit only works without error only if two of the three synchronizers work without error. -- Mike TreselerArticle: 59669
Peter Alfke wrote: > > Sounds reasonable to me... > Peter Alfke > > "Nicholas C. Weaver" wrote: > > Does this mean that, thanks to routing delay, you could just do a 3 > > flip-flops in parallel for capturing, voting circuit on the other > > side, and not have to worry about it? > > > > >For the 1.5 ns delay, the capture window is thus 3.3 ns / 50 million = > > >0.07 femtosecond > > >For the 2.0 ns delay, the capture window is a million times smaller, > > >and for 2.5 ns it's another million times smaller ... > > > > > >Light travels 0.3 m in a ns, 0.3 mm in one ps, and 0.3 micron in one > > >femtosecond. > > > > > >Peter Alfke, Xilinx Applications So, can you try this ? 3 FF could be too small, as you would have a HXL option, so a voting scheme needs to ensure a single delayed Q, does not change the result. 5 FF and a S-R latch, would seem to avoid this ? But then you can _still_ have a Late-Q effect - eg consider a HI @ 4, LOW @ 1 S-R vote. Take the OP as set high, and there is 1 HI, with a slow-Q doing ==\__, that passes the vote, in a delayed timeframe. Peter - could you measure the aperture on a 3 / 5 voting scheme, to see if it is larger, same, smaller, or zero ? -jgArticle: 59670
"Pablo Bleyer Kocik" <pablobleyer@hotmail.com> wrote in message > Exactly, this is what I was referring to. Sorry if it was not clear. > I want to share the same CCLK line for another purpose after the FPGA > has been configured. This will be a toggling 5V signal. Will the > (sleeping) CCLK will have any concerns with that? Here is some official documentation - look at Answer # 10046 in Xilinx's Answer Database. If this applies to Virtex, I believe it should to the Spartan II as well, since it is a derivative device.Article: 59671
Austin Lesea wrote: > Allan, > > Yes, it is as simple as two series 1N914 or 1N4148 diodes (to make sure > the voltage is dropped as the current is so low). > > Austin Thanks Austin. We'll try that. > Allan Herriman wrote: > > >>Hi, >> >>I notice that the maximum recommended Virtex2pro Vbatt is 2.63V. >>Lithium cells put out more than that. >> >>What are other designers doing about this? >> >>Is the solution as simple as a series Si diode on the Vbatt line? >> >>Thanks, >>Allan. > >Article: 59672
Does anyone know how to concatenate two Xilinx Spartan-II FPGA bit files? Need to put multiple bit files together because I have daisy chained multiple fpga's. Thank you.Article: 59673
"Nicholas C. Weaver" wrote: > Does this mean that, thanks to routing delay, you could just do a 3 > flip-flops in parallel for capturing, voting circuit on the other > side, and not have to worry about it? What if one FF says '1', one FF says '0' and the last is someplace inbetween? -- Phil HaysArticle: 59674
Hello, I am selling a DN3000K10S board. see for more information http://www.dinigroup.com/products/3000k10.html This is a great prototyping platform, use the PCI interface either to develop a PCI device, or to perfor testing from the PC (super convinient). The dini group has done a tremendous job at providing first class material, includung PCI code for the FPGA, drivers for the PC, code for all the build in components fo the board. Truly a work of art! Please contact me by email if you want more information Regards, MArk
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