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
On Fri, 11 Jan 2008 09:20:48 -0800 (PST), ghelbig@lycos.com wrote: >> But the real case is that : 0 1 2 3 4 ... 64 64 64 64 64 64 64 > >You can easily do it... > > if int < LIMIT then > int := int + 1; > else > int := 0; > end if; > > >Shouldn't this be: > > if int < LIMIT then > int := int + 1; > else > int := LIMIT ; > end if; Quite possibly. I understood the OP to mean that he wanted wrap-to-zero behaviour, and was getting something different. Either way makes sense, depending on the application. Note that you can also get wrap-to-zero behaviour using "mod": int := (int + 1) mod (LIMIT+1); but that is unlikely to be synthesisable unless LIMIT+1 is an exact power of 2. Apologies if I misled anyone. -- Jonathan Bromley, Consultant DOULOS - Developing Design Know-how VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK jonathan.bromley@MYCOMPANY.com http://www.MYCOMPANY.com The contents of this message may contain personal views which are not the views of Doulos Ltd., unless specifically stated.Article: 127976
michel.talon@gmail.com wrote:
> ISE tells me it can't apply my constraints.. I will understand if it
> tells me timing were not met, but why can't it apply them ? is there a
> problem between synplify pro and ISE ? why synplify can't pass my
> constraints to ISE ?
Open a case with Synplicty.
Communication of constraints from
synthesis to place and route and
vice-versa is one of the downsides
to separate synthesis.
I prefer to apply detailed constraints at the backend.
-- Mike Treseler
Article: 127977On Jan 10, 2:22 pm, Gabor <ga...@alacron.com> wrote: > On Jan 10, 12:11 pm, rickman <gnu...@gmail.com> wrote: > > > > > On Jan 10, 5:20 am, "Maki" <veselic...@eunet.yu> wrote: > > > > <snip> > > > > >. With the XP device, once > > > > the flash is reprogrammed by the system via JTAG, I believe it has to > > > > be told to reboot the SRAM from the flash which I don't have a simple > > > > way of doing. I may have to share a incoming board pin between a > > > > board disable control and the PROGRAM_N control.. if this is what is > > > > required to reboot the device. > > > > > Anyone here know for sure that toggling the PROGRAM_N pin is needed > > > > and sufficient to reload the SRAM from the Flash? > > > > Yes, it is neded and sufficient. I'm working with an XP device based board > > > as we speak. > > > > Best regards, > > > Maki > > > Thanks. I guess I am just a bit unsure, not having worked with these > > parts before. The board disable signal is high for disable. In that > > state my board should be non-functional in all ways. When the board > > is to be used or programmed, that line will be low. If I invert the > > disable signal and use it to drive PROGRAM_N, it will hold the XP in > > program mode when the board is disabled. Will this cause any > > problems? I know these parts are similar to the Xilinx parts and they > > would sit in the initialize state clearing memory continuously until > > PROGRAM_N is released. I can't find any info on what happens with the > > Lattice parts. They do list the power consumption in initialization > > which is around 100 mA combined and over twice as high as in > > "Standby". But they don't define exactly either of these > > measurements. I assume the initialization current is about the same > > while holding the PROGRAM_N pin low as it is after you release it > > until the DONE pin goes high. I also assume the Standby power is a > > configured part with no activity. > > > I'll see what their support says. They seem to be pretty good at > > getting back in a day or so. > > I'd be very surprised if the parts drew as much power while > PROGRAM_N is held low as they do while initializing until DONE > goes high. The main reason for the extra current is the internal > flash memory reading. That may well be true. But I am pretty sure the chip is very active while PROGRAM_N is low. I will see what support says, if they have any additional info at all. > Also be aware that the pullups may be active on some pins until > the part is programmed. I know this is the case for ECP parts, > and that the "weak" pullup current is higher in these parts than > in the Xilinx parts I've used in the past. Then you haven't used the Spartan parts. They have a bug in the pullup resistor values that let them be as low as 1.15 Kohms. Instead of fixing this they decided that users could live with it and documented it as a feature. The newer versions of the Spartan 3 chips have fixed it. The Lattice XP parts are spec'd at 22 kohms min. This should not be a real problem. My concern is floating I/Os. It is always hard to find documentation on all the combinations of modes that an FPGA may be in to see how all the various pins are defined. I can't be sure there aren't modes where an I/O is floating. I currently have about 40 pullups and I am looking to get rid of them. So I will be reading every detail of the data sheet that I can find.Article: 127978
>"Dave" <dhschetz@gmail.com> wrote in message >I had thought that the requirement for inferring BRAM was: >1) Either register the read address, or the read data output >2) register the write into the ram signal/variable Dave, you are right. Looking back at the link I quoted, most of the dout assignments are outside the clk block. I am not sure when or why I started putting dout inside the block. I am pretty sure that I never registered the read address lines. So I guess I have no answer for Xin. There is a switch, however, in one of the synthesis process properties. Maybe he inadvertently turned off his BRAM. Brad Smallridge AiVisionArticle: 127979
Hi all , Is there any place where I can download opb emc 1.10.b as my lates EDK istallation doesnt have it? BR RateArticle: 127980
On Jan 11, 8:00=A0am, michel.ta...@gmail.com wrote: > Hi, > > I'm a new synplify pro user. This tool seems to be much powerfull than > XST for apply timing constraints. But there is something I don't > understand : in the synplify pro report, I can see all my timing > constraints, and design meets timing requirements. > After that, using Synplify pro interface, I launch ISE Place & Route.. > When P&R finishs, I look at the report, and I can see all my timing > constraints, but for the most importants, I can read : N/A. > ISE tells me it can't apply my constraints.. I will understand if it > tells me timing were not met, but why can't it apply them ? is there a > problem between synplify pro and ISE ? why synplify can't pass my > constraints to ISE ? > > Thank you by advance, > > Best regards, Michel. I, too, apply my constraints primarily in the back end. What I've seen in both the constraints passed from the Synplify tool and from applying constraints exclusively in the back end, many constraints end up on a generated net (such as the output of a DCM) rather than the net specified in the original constraint. The result is an "N/A" listing for the constraint specified but a different nearly identical constraint that applies to all the registers (typically) that you intended. It may be ISE rather than SynplifyPro that's supplying the confusing information. - John_HArticle: 127981
On Jan 11, 12:20 pm, ghel...@lycos.com wrote: > > But the real case is that : 0 1 2 3 4 ... 64 64 64 64 64 64 64 > > You can easily do it... > > if int < LIMIT then > int := int + 1; > else > int := 0; > end if; > > Shouldn't this be: > > if int < LIMIT then > int := int + 1; > else > int := LIMIT ; > end if; > > BTW, I used something very similar to age items in a queue. > > Regards, > G. G's code: if int < LIMIT then int := int + 1; else int := LIMIT ; end if; ------- let's see.. initialize int to 0 LIMIT is 3 int < LIMIT ? int Y 1 Y 2 Y 3 N 3 : : N 3 -Dave PollumArticle: 127982
glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote: > It did occur to me while writing that, that temperature variations > would shift the metastable point. The goal of the MLL is to maximize > the rate of observations of metastability... maybe an interessting link to this topic: <http://www.sigcon.com/Pubs/news/4_4.htm> WD --Article: 127983
Philipp Have a look at our Broaddown4 http://www.enterpoint.co.uk/moelbryn/broaddown4.html and Swinyard1 http://www.enterpoint.co.uk/moelbryn/swinyard1.html products. Both can do the size you want and discounts are available under our University Access Program http://www.enterpoint.co.uk/uap/uap.html. John Adair Enterpoint Ltd. On 11 Jan, 14:29, Philipp <Phil...@gmx.at> wrote: > Hi > > We are looking for an FPGA evaluation board > to get a simple RISC processor running. It > should have at least 32K slices and I was thinking > of buying a Xilinx Virtex board. As synthesis tool > we would like to use XST 9.2. Anyone has got a hint > where I could get here a good and cheap board ;). We > are using it at university so also some deals for students > would come into question! > > many thanks, > pArticle: 127984
On Jan 11, 2:28 pm, ratemonotonic <niladri1...@gmail.com> wrote: > Hi all , > > Is there any place where I can download opb emc 1.10.b as my lates > EDK istallation doesnt have it? > > BR > Rate What version of EDK are you using? opb emc 1.10.b is still in 9.1, but it has been deprecated for a while and EDK does not show deprecated cores by default. You can have EDK show deprecated cores by going to Edit->Preferences- >IP Catalog and IP Config Dialog and checking the Display Deprecated IP Cores in IP Catalog check box. If it really is not there, you can download older versions of Xilinx software from the electronic fulfillment center if you have registered for it. Regards, John McCaskill www.FasterTechnology.comArticle: 127985
Well, we all know and respect Howard Johnson. His circuit will demonstrate metastable events, but it does not give quantitative data. How often does the output go metastable for how long, when it tries to synchronize two frequencies of that distribution? Those are the questions I have answered in XAPP094, with reasonable numeric precision. Peter Alfke On Jan 11, 1:16=A0pm, Walter Dvorak <use-reply...@invalid.invalid> wrote: > glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote: > > It did occur to me while writing that, that temperature variations > > would shift the metastable point. =A0The goal of the MLL is to maximize > > the rate of observations of metastability... > > =A0 =A0 =A0 =A0 maybe an interessting link to this topic: > > =A0 =A0 =A0 =A0 <http://www.sigcon.com/Pubs/news/4_4.htm> > > WD > --Article: 127986
Peter Alfke wrote: > Let me give some quantitative information: > At a 300 MHz clock rate and roughly 50 MHz data rate, the Virtex-2Pro > flip-flop exhibits an extra delay of 1.5 ns once every second. > > What is the metastable capture window? > The data changes once every 10 ns ( 50 MHz has a 20 ns period, with 2 > changes per period) > Within a second, the 300 MHz oscillator puts 300 million transitions > into this half period, and only one of them causes a metastable delay > of 1.5 ns > 10 ns divided by 300 million = 0.03 femtosecond = 33 times 10 exp -18 > seconds. > In other words, the capture window is extremely small... Yes it is small, but the analysis above seems a little suspect ?. Of the 300MHz edges, only one in every three has _any_ chance of hitting a metastable window, the others are effectively blanks. Say one 300MHz edge is within 500ps, and so has some probability, the next two will be well clear of any window, and so have zero chance of triggering an event. So that would indicate 0.1fs, or 100 atto seconds. (still small) You could verify that, by a change in the rate, and seeing if a drop to 200MHz did move the 'fire rate'. -jgArticle: 127987
Gary Pace wrote: > > I wonder how the AMD Phenom quad core doo-dah would perform ? I am assuming > it accesses main memory via a dedicated 128-bit port like the dual core one. > I think the Intel goes via the northbridge, and uses "interleaved dual > channel" (meaning what I don't know). Sounds like a better channel to main > memory. > Anyone who uses a 128-bit path (dual channel) uses interleaving (running both in parallel) as long as you have the same amount of memory on each port. -hpaArticle: 127988
"H. Peter Anvin" <hpa@zytor.com> writes: > Anyone who uses a 128-bit path (dual channel) uses interleaving > (running both in parallel) as long as you have the same amount of > memory on each port. With the possible exception of the Socket 1207 parts, for which documentation is not available, the AMD processors don't have dual memory channels, despite widespread claims. They have a single channel that can operate in either 64-bit or 128-bit width (plus optional ECC). Using 128-bit width has obvious benefits, but interleave is not one of them.Article: 127989
On Jan 11, 2:15=A0pm, -jg <Jim.Granvi...@gmail.com> wrote: > Peter Alfke wrote: > > Let me give some quantitative information: > > At a 300 MHz clock rate and roughly 50 MHz data rate, the Virtex-2Pro > > flip-flop exhibits an extra delay of 1.5 ns once every second. > > > What is the metastable capture window? > > The data changes once every 10 ns ( 50 MHz has a 20 ns period, with 2 > > changes per period) > > Within a second, the 300 MHz oscillator puts 300 million transitions > > into this half period, and only one of them causes a metastable delay > > of 1.5 ns > > 10 ns divided by 300 million =3D 0.03 femtosecond =3D 33 times 10 exp -1= 8 > > seconds. > > In other words, the capture window is extremely small... > > Yes it is small, but the analysis above seems a little suspect ?. > > Of the 300MHz =A0edges, only one in every three has _any_ chance of > hitting > a metastable window, the others are effectively blanks. > Say one 300MHz edge is within 500ps, and so has some probability, the > next two > will be well clear of any window, and so have zero chance of > triggering an event. > So that would indicate 0.1fs, or 100 atto seconds. (still small) > > You could verify that, by a change in the rate, and seeing if a drop > to 200MHz > did move the 'fire rate'. > > -jg Interesting argument, but it is wrong. The easiest proof would be to imagine twice the clock rate, 600 MHz. I know intuitively that the metastability rate would be much (very much) higher, but by your reasoning, it would stay the same. So here is a more rigorous attempt: If data changes once per 10 ns, and we have one clock edge per second, the largest possible distance between data change and clock edge is of course 10 ns. At a 1 MHz clock rate, the maximally possible distance between data change and clock edge is a million times shorter, and this relationship continues: at 300 MHz the max distance during any second is 10 ns divided by 300 million. (That's the 0.03 femtoseconds I mentioned.) Increasing the clock frequency even more will further reduce the max distance between clock edge and data change. That's why MTBF is known to be inversely proportional to the product of the two frequencies (clock and data), irrespective of which one is the larger value. The statistics of random events can be a tricky subject... Peter AlfkeArticle: 127990
yes brad, but now I solved the problem. I was using a small fpga, and it hadn't enough block rams. I've chose another model and now all works well. "Brad Smallridge" <bradsmallridge@dslextreme.com> wrote in message news:13ofh6156t0fo4e@corp.supernews.com... > >>"Dave" <dhschetz@gmail.com> wrote in message >>I had thought that the requirement for inferring BRAM was: >>1) Either register the read address, or the read data output >>2) register the write into the ram signal/variable > > Dave, you are right. > > Looking back at the link I quoted, most of the dout assignments > are outside the clk block. I am not sure when or why I started > putting dout inside the block. I am pretty sure that I never > registered the read address lines. > > So I guess I have no answer for Xin. There is a switch, however, > in one of the synthesis process properties. Maybe he inadvertently > turned off his BRAM. > > Brad Smallridge > AiVision >Article: 127991
I have a working Spartan 3E design that I am porting to XC3S200AN. It
has a handful of instantiated ODDR2s connected to instantiated
OBUFDSes, such as the following:
serchan_gen : for chan in 0 to 3 generate
-- here's the output DDR flop.
u_oddr : ODDR2
generic map (
DDR_ALIGNMENT => "NONE",
INIT => '0',
SRTYPE => "ASYNC")
port map (
Q => iDOut(chan),
C0 => SerClk,
C1 => SerClk_l,
CE => iVcc,
D0 => iD0(chan),
D1 => iD1(chan),
R => gReset,
S => iGnd);
u_DOBUF : OBUFDS
port map (
O => DOut_p(chan),
OB => DOut_n(chan),
I => iDOut(chan));
end generate serchan_gen;
If I assign the pins in my UCF as follows:
NET "DOut_n<0>" LOC = D3 | IOSTANDARD = "LVDS_25";
NET "DOut_p<0>" LOC = D4 | IOSTANDARD = "LVDS_25";
the mapper fails with the following inscrutable* messages:
ERROR:Pack:1107 - Unable to combine the following symbols into a
single DIFFSTB
component:
PAD symbol "DOut_n<0>" (Pad Signal = DOut_n<0>)
SlaveBuffer symbol "u_ddcltx/serchan_gen[0].u_DOBUF/
SLAVEBUF.DIFFOUT"
(Output Signal = DOut_n<0>)
Each of the following constraints specifies an illegal physical
site for a
component of type DIFFSTB:
Symbol "DOut_n<0>" (LOC=D3 [Physical Site Type = DIFFSLR])
The component type is determined by the types of logic and the
properties and
configuration of the logic it contains. Please double check that
the types of
logic elements and all of their relevant properties and
configuration options
are compatible with the physical site type of the constraint.
Please correct the constraints accordingly.
ERROR:Pack:1107 - Unable to combine the following symbols into a
single DIFFMTB
component:
PAD symbol "DOut_p<0>" (Pad Signal = DOut_p<0>)
BUFINV symbol "u_ddcltx/serchan_gen[0].u_DOBUF/OBUFDS" (Output
Signal =
DOut_p<0>)
Each of the following constraints specifies an illegal physical
site for a
component of type DIFFMTB:
Symbol "DOut_p<0>" (LOC=D4 [Physical Site Type = DIFFMLR])
The component type is determined by the types of logic and the
properties and
configuration of the logic it contains. Please double check that
the types of
logic elements and all of their relevant properties and
configuration options
are compatible with the physical site type of the constraint.
Please correct the constraints accordingly.
That's all very interesting, but WTF are DIFFMLR and DIFFMTB and
DIFFSLR and DIFFSTB, anyways? Asking the great god Google for "Xilinx
DIFFMLR" returns exactly zero results (well, maybe one, after this
post is indexed). Nowhere in Xilinx' docs are these components
mentioned.
Then I figure, OK, let's see what the tools do when one deletes the
placement and I/O type constraints in the UCF.
Map completes, and the mapper assigns the IOB type DIFFMTB for all of
the non-inverted LVDS output signals and it assigns the type DIFFSTB
for all of the inverted LVDS output signals. Again, NOWHERE in the
docs or on the Xilinx website are these components defined.
However, place and route bombs out with the following complaint:
ERROR:Place:866 - Not enough valid sites to place the following IOBs:
IO Standard: Name = LVDS_25, VREF = NR, VCCO = 2.50, TERM = NONE
(list of differential signals snipped)
This may be due to either an insufficient number of sites available
on the device, too many prohibited sites, or incompatible I/O
Standards locked or range constrained to I/O Banks with valid sites.
This situation could possibly be resolved by one (or all) of
the following actions:
a) Grouping IOBs of similar standards into a minimum amount of I/O
Banks by using LOC or range constraints.
b) Maximizing available I/O Banks resources for special IOBs by
choosing lower capacity I/O Banks if possible.
c) If applicable, decreasing the number of user prohibited sites or
using a larger device.
This is all ridiculous because the device has an entire unused bank
that it can use for these outputs.
So how does one use LVDS outputs on a Spartan 3AN device?
-a
* I say "inscrutable" because Xilinx apparently agrees with me:
"This valid error message is not very useful because of its generic
nature; it is meant to describe a wide variety of conflicts between
site types and the logical instances constrained to them. The key
elements are as follows ..."
Article: 127992On Jan 11, 5:21 pm, Andy Peters <goo...@latke.net> wrote: > I have a working Spartan 3E design that I am porting to XC3S200AN. Oh, yeah, because some people will ask. Yes, I did change the build target to XC3S200A (there's no specific callout for AN parts). -aArticle: 127993
Hi, It could be that you are trying to put LVDS outputs on banks that don't support LVDS output. In Spartan-3A and Spartan-3AN, I believe you can only implement LVDS outputs on the top and bottom banks of the die. For reference, a DIFFSTB is an IOB that is a DIFFerential Slave on the Top or Bottom of the die. A DIFFSLR, as you might imagine, is DIFFerential Slave on the Left or Right of the die. You also referenced some site types with an M in them instead of an S, those are Master site types. What the message is unsuccessfully trying to communicate is that you've got something that needs to be on a DIFF*TB site, but your location constraint is for a DIFF*LR site. I cannot say for certain about the completely unconstrained I/O test you ran, but I suspect that the placer either wasn't able to figure out a solution to your design I/O requirements without some hints, or that you may have more LVDS outputs in your design than will fit on the top and bottom banks. I hope that throws some light on it, Eric > ERROR:Pack:1107 - Unable to combine the following symbols into a > single DIFFSTB > component: > PAD symbol "DOut_n<0>" (Pad Signal = DOut_n<0>) > SlaveBuffer symbol "u_ddcltx/serchan_gen[0].u_DOBUF/ > SLAVEBUF.DIFFOUT" > (Output Signal = DOut_n<0>) > Each of the following constraints specifies an illegal physical > site for a > component of type DIFFSTB: > Symbol "DOut_n<0>" (LOC=D3 [Physical Site Type = DIFFSLR]) > The component type is determined by the types of logic and the > properties and > configuration of the logic it contains. Please double check that > the types of > logic elements and all of their relevant properties and > configuration options > are compatible with the physical site type of the constraint. > Please correct the constraints accordingly. > ERROR:Pack:1107 - Unable to combine the following symbols into a > single DIFFMTB > component: > PAD symbol "DOut_p<0>" (Pad Signal = DOut_p<0>) > BUFINV symbol "u_ddcltx/serchan_gen[0].u_DOBUF/OBUFDS" (Output > Signal = > DOut_p<0>) > Each of the following constraints specifies an illegal physical > site for a > component of type DIFFMTB: > Symbol "DOut_p<0>" (LOC=D4 [Physical Site Type = DIFFMLR]) > The component type is determined by the types of logic and the > properties and > configuration of the logic it contains. Please double check that > the types of > logic elements and all of their relevant properties and > configuration options > are compatible with the physical site type of the constraint. > Please correct the constraints accordingly. > > That's all very interesting, but WTF are DIFFMLR and DIFFMTB and > DIFFSLR and DIFFSTB, anyways? Asking the great god Google for "Xilinx > DIFFMLR" returns exactly zero results (well, maybe one, after this > post is indexed). Nowhere in Xilinx' docs are these components > mentioned. > > Then I figure, OK, let's see what the tools do when one deletes the > placement and I/O type constraints in the UCF. > > Map completes, and the mapper assigns the IOB type DIFFMTB for all of > the non-inverted LVDS output signals and it assigns the type DIFFSTB > for all of the inverted LVDS output signals. Again, NOWHERE in the > docs or on the Xilinx website are these components defined. > > However, place and route bombs out with the following complaint: > > > ERROR:Place:866 - Not enough valid sites to place the following IOBs: > IO Standard: Name = LVDS_25, VREF = NR, VCCO = 2.50, TERM = NONE > (list of differential signals snipped) > > This may be due to either an insufficient number of sites available > on the device, too many prohibited sites, or incompatible I/O > Standards locked or range constrained to I/O Banks with valid sites. > This situation could possibly be resolved by one (or all) of > the following actions: > a) Grouping IOBs of similar standards into a minimum amount of I/O > Banks by using LOC or range constraints. > b) Maximizing available I/O Banks resources for special IOBs by > choosing lower capacity I/O Banks if possible. > c) If applicable, decreasing the number of user prohibited sites or > using a larger device. > > This is all ridiculous because the device has an entire unused bank > that it can use for these outputs. > > So how does one use LVDS outputs on a Spartan 3AN device? > > -a > > * I say "inscrutable" because Xilinx apparently agrees with me: > > "This valid error message is not very useful because of its generic > nature; it is meant to describe a wide variety of conflicts between > site types and the logical instances constrained to them. The key > elements are as follows ..."Article: 127994
Regarding the LVDS output capability of the Spartan-3 Generation, check here: http://www.xilinx.com/support/documentation/user_guides/ug331.pdf Look on page 334, Table 10-9. Eric "Eric Crabill" <eric.crabill@xilinx.com> wrote in message news:fm93a8$rls1@cnn.xsj.xilinx.com... > In Spartan-3A and Spartan-3AN, I believe you can only implement LVDS > outputs on the top and bottom banks of the die.Article: 127995
Peter Alfke wrote: > On Jan 11, 2:15=EF=BF=BDpm, -jg <Jim.Granvi...@gmail.com> wrote: > > Yes it is small, but the analysis above seems a little suspect ?. > > > > Of the 300MHz =EF=BF=BDedges, only one in every three has _any_ chance o= f > > hitting > > a metastable window, the others are effectively blanks. > > Say one 300MHz edge is within 500ps, and so has some probability, the > > next two > > will be well clear of any window, and so have zero chance of > > triggering an event. > > So that would indicate 0.1fs, or 100 atto seconds. (still small) > > > > You could verify that, by a change in the rate, and seeing if a drop > > to 200MHz > > did move the 'fire rate'. > > > > -jg > Interesting argument, but it is wrong. > The easiest proof would be to imagine twice the clock rate, 600 MHz. > I know intuitively that the metastability rate would be much (very > much) higher, but by your reasoning, it would stay the same. Very much ? - by your numbers it would only double ? I think you are viewing this in terms of your test circuit, where the clock does more than one thing - it also checks for the failure, and in that case yes, a faster clock would shrink the window, and so give (very much) higher failure rates. My argument is a system only has a finitie number of data edges, and so one cannot sensibly claim to 'roll the metastable dice more often' than that. Well, one can, but the calculated result is unrealistically short :) It should be possible to verify this on a test bench, but it would need a test circuit that did NOT change the metastable window snapshot, with clock changes. So, perhaps a Clock enable on the first register, that allowed 300MHz, 150MHz, 100MHz etc samples of the 51MHz data (but other registers keep their window sampling) ? It is somewhat academic, I'll admit, as designers don't care if an 'apparent window' is 33 or 100 attoseconds wide - both values are well under any system jitter. Another interesting bench test, would be to see how many adjacent samples could be made to exceed a metastable window. With a slow phase velocity, and good system jitters, a very small trigger window would say this would be very rare. A wider trigger window would increase the probability of two consecutive edges both failing. If the jitter is 1000x as large as the trigger window, then the chance of two consecutive failures is 1 in a million (assumes nominal phase lock, just jitter errors ) -jgArticle: 127996
On Jan 10, 3:22 pm, "H. Peter Anvin" <h...@zytor.com> wrote: > - multicore doesn't matter (unless you try to do other things while > running.) Most current FPGA tools are still single-threaded. > - cache size matters more than anything. Going from a 512K to a 1024K > cache cut the synthesis time by two-thirds. Intel probably has > an advantage here, because they have shared caches; remember to only > count the cache available to a single core. > - memory size and memory latency matters too. Get lots of fast RAM. > - the OS will manage memory better if it's a 64 bit OS. Running on a > 64-bit Linux seemed to run about 20-25% faster than 32-bit WinXP. I mostly agree. I ran my own scaling experiments before settling on my current setup (using Windows Quartus II 7.X and my mix of designs). I don't have the numbers handy, but for me: - number of cores made very little difference, - memory bandwidth, latency, and capacity made *no* measurable difference as long as I had enough (2 GiB+), - L2 cache size was significant, and finally - core frequency mattered most. Basically, given a large enough L2 (4+ MiB), performance scaled linearly with clock frequency (Core 2 Duo). The only AMD part I had to compare with was pretty old (XP 3200+ / 2.0 GHz) and it didn't perform well (d'oh). I went for a conservative over-clocked (~ 3.1 GHz) 4 MiB L2 Core2 Duo. P&R is one of the few problems left where we still don't have enough single-thread performance and where it is fully justifiable to spend more than half your budget on the CPU alone. (Music to Intel's ears. They just need to get the world hooked on FPGAs :-). TommyArticle: 127997
-jg wrote: > > Peter Alfke wrote: >> On Jan 11, 2:15�pm, -jg <Jim.Granvi...@gmail.com> wrote: >>> Yes it is small, but the analysis above seems a little suspect ?. >>> >>> Of the 300MHz �edges, only one in every three has _any_ chance of >>> hitting >>> a metastable window, the others are effectively blanks. >>> Say one 300MHz edge is within 500ps, and so has some probability, the >>> next two >>> will be well clear of any window, and so have zero chance of >>> triggering an event. >>> So that would indicate 0.1fs, or 100 atto seconds. (still small) >>> >>> You could verify that, by a change in the rate, and seeing if a drop >>> to 200MHz >>> did move the 'fire rate'. >>> >>> -jg >> Interesting argument, but it is wrong. >> The easiest proof would be to imagine twice the clock rate, 600 MHz. >> I know intuitively that the metastability rate would be much (very >> much) higher, but by your reasoning, it would stay the same. > > Very much ? - by your numbers it would only double ? > I think you are viewing this in terms of your test circuit, where the > clock does > more than one thing - it also checks for the failure, and in that case > yes, a faster clock would shrink the window, and so give (very much) > higher failure > rates. > > My argument is a system only has a finitie number of data edges, and > so > one cannot sensibly claim to 'roll the metastable dice more often' > than that. > Well, one can, but the calculated result is unrealistically short :) > > It should be possible to verify this on a test bench, but it would > need a test circuit > that did NOT change the metastable window snapshot, with clock > changes. > > So, perhaps a Clock enable on the first register, that allowed 300MHz, > 150MHz, 100MHz etc > samples of the 51MHz data (but other registers keep their window > sampling) ? > > It is somewhat academic, I'll admit, as designers don't care if an > 'apparent window' is > 33 or 100 attoseconds wide - both values are well under any system > jitter. > > Another interesting bench test, would be to see how many adjacent > samples could > be made to exceed a metastable window. With a slow phase velocity, and > good system jitters, a very small trigger window would say this would > be very rare. A wider trigger window would increase the probability of > two consecutive edges both failing. > If the jitter is 1000x as large as the trigger window, then the chance > of two consecutive failures is 1 in a million (assumes nominal phase > lock, just jitter errors ) > > -jg Your argument was that two out of every three 300 MHz clock edges don't even have a CHANCE of creating the metastable event. Consider the "controlled" asynchronous version of this test where the 300 MHz clock is phase locked to the 50 MHz clock being sampled and the 300 MHz clock is phase shifted across the full 10ns of a single bit period. This 10 ns phase shift produces three capture window crossings. If you use a 200 MHz clock and shift those 10 ns, you will have two window crossings. If your sample clock frequency could approach infinity, you would *always* have a metastable event captured. Peter's looked at this problem (measuring metastability) for a very, very long time with full experimental setups to verify his numbers. I don't believe the equations were created by him but have existed for ages. My first introduction to the theory and supporting equations was about 2 decades ago. Perhaps Peter Alfke authored that text. - John_HArticle: 127998
John_H wrote: > -jg wrote: > > Your argument was that two out of every three 300 MHz clock edges don't > even have a CHANCE of creating the metastable event. Correct. You can roll the dice once, but not three times. > Consider the > "controlled" asynchronous version of this test where the 300 MHz clock > is phase locked to the 50 MHz clock being sampled and the 300 MHz clock > is phase shifted across the full 10ns of a single bit period. This 10 > ns phase shift produces three capture window crossings. If you use a > 200 MHz clock and shift those 10 ns, you will have two window crossings. I'm not sure I follow?. Peter's test circuit uses the clock for two different things. Once to sample the data stream and again to set the settling window, to decide if metastable events occured. Yes, this is nice and simple, but can give the illusion that the faster clock gives more transistion-settling-event samplings. > If your sample clock frequency could approach infinity, you would > *always* have a metastable event captured. Yes, a good limit case (assuming zero jitter) : This case would have these events every 10ns (not every clock) - you cannot have more transistion-settling-events than transistions :) With a difference of 3:1 between CLK and Edge rates, the distinction I am trying to make is not large on the scale of metastable values, but I would derive a different window-size than Peter, from the same data. Should be easy enough to verify, and also get better test vehicles for more accurate window sizes. If I was making chips, I'd like to know that number as precisely as possible (even tho it is way below any jitter, and some would say 'who cares?') because it could indicate if a new process was actually better than an older one. -jgArticle: 127999
Hi all, Is there a simple way to read back data from Virtex5 BRAMs preferable over JTAG by XSFV/SVF commands? Best regards Ed
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