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 Thu, 20 Dec 2001 18:19:54 GMT, Andy Peters <andy@exponentmedia.nospam.com> wrote: >Bob Perlman wrote: > >> On Wed, 19 Dec 2001 17:19:58 GMT, Andy Peters >> <andy@exponentmedia.nospam.com> wrote: >> >> >>>Stephen Byrne wrote: >>> >>> >>>>I originally posted this yesterday on google groups, but I'm not seeing it >>>>on my home news server. In case it is not visible to all, I'm reposting. >>>> >>>>Hello All, >>>> >>>>My company is currently comparing 66MHz PCI core solutions from Xilinx >>>>and Altera, as well as debating using a home-spun core. One issue >>>>I've come upon is the PCI requirement for a MAX clock-to-out time of 6 >>>>ns and MIN clock-to-out time of 2 ns. Both the Xilinx ISE and Altera >>>>Quartus II tools seem very helpful in supplying MAX (worst-case) Tco >>>>times, but I don't see any info on best-case times. Apparently the >>>>SDF files for back-annotated timing sim have the same worst-case >>>>numbers repeated 3 times, resulting in the same simulation regardless >>>>of case selection. My question is: how is anyone (FPGA vendors >>>>included) guaranteeing a MIN Tco of 2 ns across all conditions and >>>>parts if the design tools don't even yield that information? >>>> >>> >>>You like to live dangerously if you depend on best-case timing information. >>> >> >> What's the alternative? > > > >Um, worst-case timing information? Worst-case timing information isn't a substitute for best-case timing information; you need both. If you're trying to calculate setup margin, you need the worst-case clock-to-Q time of the driving device. But if you're trying to calculate the hold margin, you need the best-case (i.e., shortest) clock-to-Q time. That's why Stephen Byrne was looking for best-case timing. Bob PerlmanArticle: 37801
Hi Peter, I am using 3 clocks with the same frequency because my FPGA interfaces with other modules whose outputs are my input clocks. I put all the input data from these modules in registers synchronized with the corresponding input clock and later I synchronized the data with my FPGA's clock. Its something I could not avoid. I have some problems with the timing constraints but I believe I have just found a possible cause. My main problem still remains the one I have described above with the FPGA EXPRESS. Harris "Peter Alfke" <peter.alfke@xilinx.com> wrote in message news:3C222D3C.A63B8107@xilinx.com... > > > "H.L" wrote: > > > Hello all and Merry Christmas, > > I have a small question. I work in a Virtex-E FPGA, my model has 4 clocks (3 > > in 155MHz and the other one slower~100MHz) as inputs. > > Why do you have 3 clocks with the same frequency? Use only one! > But if the phases or frequencies are not identical, then be very careful when > you cross from one frequency domain to the other > > > In the ucf file I > > located all clocks in the GCK pins, is that right? > > Yes > > > > > If yes, is this the only constraint that ensures proper distribution of the > > signals? > > Yes, you always get very good, low-skew distribution on the global clocks. > > > > > Ah , and another one :) .. one of the processes (VHDL coding) in my model > > that i want to implement uses the falling edge of the slow clock while the > > others use the rising edge of all clocks, is this going to be a problem? > > No problem > > Peter Alfke > >Article: 37802
Carl Brannen wrote: > .... I haven't figured out how to apply an attribute to a generated component > (i.e. like your > RLOC usage on generated components). I'm assuming here that "generated" means > the use of the "generate" command in VHDL. The basic problem is that I haven't > figured out how to properly address the components. So I went ahead and > instantiated them individually. > > If you have a way around that, I'd appreciate the secret. > Check this link (How to Attach Attributes Inside of Generate?): http://tech-www.informatik.uni-hamburg.de/vhdl/doc/faq/FAQ1.html#attributes FrédéricArticle: 37803
Hello all and Merry Christmas, I have a small question. I work in a Virtex-E FPGA, my model has 4 clocks (3 in 155MHz and the other one slower~100MHz) as inputs. In the ucf file I located all clocks in the GCK pins, is that right? If yes, is this the only constraint that ensures proper distribution of the signals? Ah , and another one :) .. one of the processes (VHDL coding) in my model that i want to implement uses the falling edge of the slow clock while the others use the rising edge of all clocks, is this going to be a problem? Thanks HarrisArticle: 37804
Well, I guess I am wrong then. Along with 99% of the others. We'll just have to cope the best we can. Austin Pete Dudley wrote: > Austin F. is right on the value of schematics vs. hdl and Austin L. is > wrong. It's best to use schematics to design the architectural hierarchy and > only use HDL within blocks where it makes sense. > > When an HDL is used structurally you have to maintain a graphical block > diagram (schematic) on the side to keep track of how it all fits together. > In any case most schematic tools will write out a structural VHDL netlist > automatically if you're required to provide a pure HDL design. > > HDL's have many valuable characteristics like portability but they have been > oversold as productivity enhancers. > > "Ray Andraka" <ray@andraka.com> wrote in message > news:3C20F7F0.CCE642F6@andraka.com... > > Both schematics and HDL can be horrendous or stellar. I've seen examples > both > > ways of both. In either case, proper use of hierarchy is the key to a > > maintainable design. > > > > Austin Franklin wrote: > > > > > Hi Austin, > > > > > > > If I see hdl code, at least I can see where it is going, even if it is > > > written > > > > badly. > > > > > > For me, that is not true. I have to wade around pages and pages of > > > text....where with a schematic, I can pick up what's going on almost > > > instantly. Schematics offer, if done right that is, a built-in block > > > diagram...which can not be done with text files very easily. The data > flow > > > is FAR easier to pick out in a schematic than in HDL, and control logic > may > > > or may not be easier to "understand" in HDL...it depends on how it's > done. > > > > > > > Nice thing about software is that people have figured out how to > manage > > > it, and > > > > document it. > > > > > > Why is that any different than schematics? > > > > > > > If I examine a design, from top to bottom, I can make a determination > of > > > the > > > > quality of the design by examining the hdl code. It is possible, but > more > > > > difficult to see what is going on in schematic. > > > > > > I believe the exact opposite. > > > > > > > As a > > > > technical manager, code review is one tool that should be used to make > > > sure the > > > > project is on track, following the rules, and has a higher likelihood > of > > > > success. > > > > > > And you've never seen/done a schematic review? I believe schematics are > FAR > > > easier to review than text files are. Anyway, design reviews are > typically > > > NOT the source files, but the architecture...it's rare that one brings > > > source files to a design review and gives a copy to everyone in the > room, > > > and people just sit around flipping through hundreds of pages of text > > > discussing constructs... > > > > > > I think you should attend my lecture in the spring on mixed design entry > for > > > FPGA design ;-) > > > > > > Regards, > > > > > > Austin > > > > -- > > --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: 37805
Personally, I prefer to instantiate my own. It gives me the capability
to a) place them in my code and b) more flexibility in the use, and
initialization.
The BRAMs have a default initialization of all zeros. To change that in
both the bitstream and the simulation you need to initialize them twice:
(I'll stick with the VHDL explanation). For simulation, you need to
set the INIT= generics in the model to the desired initialization
values. These are in the form of a bit_vector for VHDL. For synthesis,
the generics need to be made invisible to the synthesizer (it doesn't
know how to apply generics to a black box). To initialize the RAMs for
synthesis, you need to add INIT= attributes matching the generics. The
INIT= attribute strings are hex strings, so you'll need a conversion
between the two formats.
kh05168 wrote:
> Use Coregen. It is quite straightforward.
--
--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: 37806"S. Ramirez" wrote: > > "Bret Wade" <bret.wade@xilinx.com> wrote in message > news:3C212A10.D5E82114@xilinx.com... > > Simon, > > > > Okay, but you could use the IOB attribute and then there would be no > worries > > about whether you've set the Map options correctly. > > > > Regards, > > Bret > > Bret, > This is just a suggestion from a user point of view -- change the > default. Then we wouldn't be having this discussion. > Simon You could change the default but then you'll break things for those people who need the FFs to not be packed. There are cases when you might not want your FFs in the IOBs, e.g. extra hold time needed for inputs and/or outputs. This is why, IMHO, tools should always have command line flags for all states of an option. The tool should also echo a complete command line with all options enumerated so that the command can be recreated later, ideally in a script. -- Tim Hubberstey, P.Eng. . . . . . Hardware/Software Consulting Engineer Marmot Engineering . . . . . . . VHDL, ASICs, FPGAs, embedded systemsArticle: 37807
Bob Perlman wrote: > > On Thu, 20 Dec 2001 18:19:54 GMT, Andy Peters > <andy@exponentmedia.nospam.com> wrote: > > >Bob Perlman wrote: > > > >> On Wed, 19 Dec 2001 17:19:58 GMT, Andy Peters > >> <andy@exponentmedia.nospam.com> wrote: > >> > >> > >>>Stephen Byrne wrote: > >>> > >>> > >>>>I originally posted this yesterday on google groups, but I'm not seeing it > >>>>on my home news server. In case it is not visible to all, I'm reposting. > >>>> > >>>>Hello All, > >>>> > >>>>My company is currently comparing 66MHz PCI core solutions from Xilinx > >>>>and Altera, as well as debating using a home-spun core. One issue > >>>>I've come upon is the PCI requirement for a MAX clock-to-out time of 6 > >>>>ns and MIN clock-to-out time of 2 ns. Both the Xilinx ISE and Altera > >>>>Quartus II tools seem very helpful in supplying MAX (worst-case) Tco > >>>>times, but I don't see any info on best-case times. Apparently the > >>>>SDF files for back-annotated timing sim have the same worst-case > >>>>numbers repeated 3 times, resulting in the same simulation regardless > >>>>of case selection. My question is: how is anyone (FPGA vendors > >>>>included) guaranteeing a MIN Tco of 2 ns across all conditions and > >>>>parts if the design tools don't even yield that information? > >>>> > >>> > >>>You like to live dangerously if you depend on best-case timing information. > >>> > >> > >> What's the alternative? > > > > > > > >Um, worst-case timing information? > > Worst-case timing information isn't a substitute for best-case timing > information; you need both. If you're trying to calculate setup > margin, you need the worst-case clock-to-Q time of the driving device. > But if you're trying to calculate the hold margin, you need the > best-case (i.e., shortest) clock-to-Q time. That's why Stephen Byrne > was looking for best-case timing. > > Bob Perlman Seems a terminology problem. BOTH the shortest and longest time delays can be considered 'worst case', from a statistical and tolerance sense. 'Best-case' is to have all devices right in the middle of the error band :-) It's no different from lowest and highest Vcc, for example. Many systems actually rely on the silicon tracking. On many data sheets, if you applied shortest and longest limits, often the chip cannot ( technically ) drive itself! Fortunately in the real world, you do not get 'opposite corner' effects on one die. -jgArticle: 37808
I also found that the Synplify syn_useioff attribute didn't always work. I think it was because Synplify was violating the rules about putting FF's in the IOB so par couldn't put them there. I have not tried it recently; I now instantiate an FD on every IO. I tried many different ways to make an inferred register work. I used syn_keep for a while. Then I upgraded Synplify and it all stopped working. With the FD, it has continued to work through several upgrades of Synplify and par. And just to answer the original question, I always set the pr -b flag. I don't see how you can use an FPGA without it (and get repeatable high speed timing). Alan Nishioka alann@accom.com Austin Franklin wrote: >Hi Ken, > >If you read what I wrote in my reply, you would note that I mentioned the >syn_useioff "attribute" and also said that you still need the "pr -b" >option, as just the attribute alone does not put the FFs in the IOBs...at >least in the tool set I have been using... > >Regards, > >Austin > >"Ken McElvain" <ken@synplicity.com> wrote in message >news:3C221CDB.2060207@synplicity.com... > >>Synplify does have a syn_useioff attribute that you can >>set to 1 as a global attribute. This will default all >>packable boundary flip-flops into the IOB by putting the >>IOB attribute on them. You can then override the default >>on a pin by pin basis with the same attribute. >>Article: 37809
Hi Harris, I use FPGA Express too but as an integrated part of the Foundation Toolset. I do have constraints editor on Express but don't really feel the need to use it, I think you can get perfectly workable results without tweaking there, writing your code to force the synthesis you want and controlling the timing from the Xilinx implementation tool. The .ucf file is actually used by the Xilinx implementation tool, not the synth tool. I don't know if Alliance is the same as Foundation in this respect but when you create a project in Foundation, the tool creates a dummy template for your project. This contains just about everything you need to timespec your design. The ucf file can just be edited in a text editor and the tools should pick up the default <project_name>.ucf.from the projects directory. There's also a copy of the template in the Xillinx directory structure somewhere. You can find out more about ucf files by using the _advanced_ search at support.xilinx.com FredArticle: 37810
"Austin Franklin" <austin@dark98room.com> writes: > Typically, the schematic symbol isn't a "canned" symbol, it is a custom > symbol tailored to the function/pinout of the FPGA. They don't take THAT > long to make if you know the tool... > > Does anyone here **really** use a "canned" symbol for their FPGAs? For a > PAL, yes, but an FPGA? I don't even like canned symbols for PALs. I almost always draw a custom symbol.Article: 37811
Jim Granville wrote: > Many systems actually rely on the silicon tracking. > On many data sheets, if you applied shortest and longest limits, > often the chip cannot ( technically ) drive itself! > Fortunately in the real world, you do not get 'opposite corner' > effects on one die. > Inside the chip delay tracking is an acceptable assumption, but not in the I/O. The driver and receiver are different chips, and can be at the extremes of processing tolerances, and may not have exactly the same Vcc and temperature. That's why we now spec not only max input set-up, but also min set-up aka "negative hold time". And, sooner or later, you will also see min clock-to-out specs. One problem is to measure these, the other problem is that engineering and processing work very hard to defeat these "best case" parameter limits by making the chip even better = faster. And nobody wants to stop that laudable effort ;-) Peter AlfkeArticle: 37812
Austin Lesea wrote: > Well, > > I guess I am wrong then. > > Along with 99% of the others. > > We'll just have to cope the best we can. > > Austin > > There is a curious phenomenon on this NG whereby any thread that lasts long enough always converges on one of 2 discussion ``attractors'' - Schem vs. HDL. - Verilog vs. VHDL. strange.Article: 37813
Alan Nishioka wrote: > I also found that the Synplify syn_useioff attribute didn't always work. > I think it was because Synplify was violating the rules about putting > FF's in the IOB so par couldn't put them there. I have not tried it > recently; I now instantiate an FD on every IO. I tried many different > ways to make an inferred register work. I used syn_keep for a while. > Then I upgraded Synplify and it all stopped working. With the FD, it > has continued to work through several upgrades of Synplify and par. > You are correct. It can be a total PITA to presuade Synplify to not violate the packing rules. It can be done but the kludges can be ugly . I've got a little perl script that parses the MAP report file & checks that all input & output FFs, except for a small list, have been packed. And, as far as I can see, it gets worse when the FF concerned is not inferred at the top level of a ``synthesise everything all at once'' design approach but may be 1/2 levels down in a more modular design. Then, AFAIK, syn_useioff is just ignored.Article: 37814
Rick, That's It! Chaos Theory, again! I knew it all along. We can predict how many emails in any thread it takes to get to the three strange attactor points: dropped (everyone ignores it), VHDL vs verilog, schematic vs hdl, altera vs xilinx, fpga vs asic, .... Austin Rick Filipkiewicz wrote: > Austin Lesea wrote: > > > Well, > > > > I guess I am wrong then. > > > > Along with 99% of the others. > > > > We'll just have to cope the best we can. > > > > Austin > > > > > > There is a curious phenomenon on this NG whereby any thread that lasts long enough > always converges on one of 2 discussion ``attractors'' > > - Schem vs. HDL. > > - Verilog vs. VHDL. > > strange.Article: 37815
Yeah, the funny thing is that I started most of this bickering in the thread. But I didn't want to argue, I just wanted an answer to my hand routing question. It worked, mud slinging got enough interest that my particular question was answered. Now that is funny :> Bryan > There is a curious phenomenon on this NG whereby any thread that lasts long enough > always converges on one of 2 discussion ``attractors'' > > - Schem vs. HDL. > > - Verilog vs. VHDL. > > strange. > > >Article: 37816
Frédéric, that link is much appreciated, and though I haven't tried it yet, I believ it will do the trick. Carl > > > Check this link (How to Attach Attributes Inside of Generate?): > http://tech-www.informatik.uni-hamburg.de/vhdl/doc/faq/FAQ1.html#attributes > > Frédéric -- Posted from firewall.terabeam.com [216.137.15.2] via Mailgate.ORG Server - http://www.Mailgate.ORGArticle: 37817
Since this seems to come up fairly frequently, here is a simple example of RLOCs
applied as an attribute inside the generate. The itoa function is a homebrew
function that converts an integer into an ascii string. If your synthesizer
recognizes 'image, you could use that instead. The attributes have to be assigned in
the same level of code as the labels they are being assigned to are due to
visibility. In otherwords, components inside a generate are not visible outside the
generate, so the attributes have to be in the generate's declaration section.
LEN:for i in 0 to bits-1 generate
constant row :natural:=((width-1)/2)-(i/2);
constant column:natural:=0;
constant slice:natural:=0;
constant rloc_str : string := "R" & itoa(row) & "C" & itoa(column) & ".S" &
itoa(slice);
attribute RLOC of U1: label is rloc_str;
begin
U1: FDE port map (
Q => dd(j),
D => ff_d,
C => clk,
CE =>lcl_en(en_idx));
end generate LEN;
Frederic Rivoallon wrote:
> Carl Brannen wrote:
>
> > .... I haven't figured out how to apply an attribute to a generated component
> > (i.e. like your
> > RLOC usage on generated components). I'm assuming here that "generated" means
> > the use of the "generate" command in VHDL. The basic problem is that I haven't
> > figured out how to properly address the components. So I went ahead and
> > instantiated them individually.
> >
> > If you have a way around that, I'd appreciate the secret.
> >
>
> Check this link (How to Attach Attributes Inside of Generate?):
> http://tech-www.informatik.uni-hamburg.de/vhdl/doc/faq/FAQ1.html#attributes
>
> Frédéric
--
--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: 37818
I think using both in the same design, at least for a consultant doing designs for
a client, is a sin among sins. It requires the client to obtain and maintain two
tool flows if he wishes to do anything with the design without having to come back
to you. Pick one and stick with it for the whole design.
We've moved to VHDL and abandoned schematics because a) that is what the customer
wants, b) the VHDL generate allows us to make a parameterized library that is much
more complete, easier to maintain, and easier to use than what we had with
schematics. We've gained archives that can be read on a text editor, and much
better simulation capabilities in exchange for ready made block diagrams, and a
bit more time to grok the design, especially if it was not documented with more
text than code. I find myself doing block diagrams on scraps of paper. With the
addition of an RTL diagram generator, the scales tip in favor of VHDL for us.
Austin Lesea wrote:
> Well,
>
> I guess I am wrong then.
>
> Along with 99% of the others.
>
> We'll just have to cope the best we can.
>
> Austin
>
> Pete Dudley wrote:
>
> > Austin F. is right on the value of schematics vs. hdl and Austin L. is
> > wrong. It's best to use schematics to design the architectural hierarchy and
> > only use HDL within blocks where it makes sense.
> >
> > When an HDL is used structurally you have to maintain a graphical block
> > diagram (schematic) on the side to keep track of how it all fits together.
> > In any case most schematic tools will write out a structural VHDL netlist
> > automatically if you're required to provide a pure HDL design.
> >
> > HDL's have many valuable characteristics like portability but they have been
> > oversold as productivity enhancers.
> >
> > "Ray Andraka" <ray@andraka.com> wrote in message
> > news:3C20F7F0.CCE642F6@andraka.com...
> > > Both schematics and HDL can be horrendous or stellar. I've seen examples
> > both
> > > ways of both. In either case, proper use of hierarchy is the key to a
> > > maintainable design.
> > >
> > > Austin Franklin wrote:
> > >
> > > > Hi Austin,
> > > >
> > > > > If I see hdl code, at least I can see where it is going, even if it is
> > > > written
> > > > > badly.
> > > >
> > > > For me, that is not true. I have to wade around pages and pages of
> > > > text....where with a schematic, I can pick up what's going on almost
> > > > instantly. Schematics offer, if done right that is, a built-in block
> > > > diagram...which can not be done with text files very easily. The data
> > flow
> > > > is FAR easier to pick out in a schematic than in HDL, and control logic
> > may
> > > > or may not be easier to "understand" in HDL...it depends on how it's
> > done.
> > > >
> > > > > Nice thing about software is that people have figured out how to
> > manage
> > > > it, and
> > > > > document it.
> > > >
> > > > Why is that any different than schematics?
> > > >
> > > > > If I examine a design, from top to bottom, I can make a determination
> > of
> > > > the
> > > > > quality of the design by examining the hdl code. It is possible, but
> > more
> > > > > difficult to see what is going on in schematic.
> > > >
> > > > I believe the exact opposite.
> > > >
> > > > > As a
> > > > > technical manager, code review is one tool that should be used to make
> > > > sure the
> > > > > project is on track, following the rules, and has a higher likelihood
> > of
> > > > > success.
> > > >
> > > > And you've never seen/done a schematic review? I believe schematics are
> > FAR
> > > > easier to review than text files are. Anyway, design reviews are
> > typically
> > > > NOT the source files, but the architecture...it's rare that one brings
> > > > source files to a design review and gives a copy to everyone in the
> > room,
> > > > and people just sit around flipping through hundreds of pages of text
> > > > discussing constructs...
> > > >
> > > > I think you should attend my lecture in the spring on mixed design entry
> > for
> > > > FPGA design ;-)
> > > >
> > > > Regards,
> > > >
> > > > Austin
> > >
> > > --
> > > --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
> > >
> > >
--
--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: 37819
Heck, I was using that trick with 3000 series parts driving wired ORs
back in the early '90s. The problem was to eliminate the rise time on a
shared bus (I think it was a DACK on a motorola processor)
Peter Alfke wrote:
>
> Peter Alfke wrote:
>
>> What if you have to drive 5-V that has a CMOS input threshold of up
>> to 3.5 V.
>> Then you need a pull-up resistor to the 5 V, and you should
>> configure the
>> XC4005 output as "open collector" ( really: open drian ). That costs
>> you speed,
>> since you now have a 1 kilohm pull-up and a, say, 100 pF lad, which
>> creates a
>> 100 ns delay time constant.
>> There is a simple and clever way around that, and I can send you the
>> circuit
>> description on Monday when I am back at work.
>
> Here is the "simple and clever circuit" description and the whole,
> somewhat long-winded explanation, first published 3 years ago.
> Today the 3 ns rise-time is more like 1 ns...
>
>
> XC4000XL Driving 5-V CMOS Inputs
>
> The XC4000XL devices use 3.3 V supply, but tolerate 5 V on their I/O
> pins. They can drive 5-V TTL-level inputs directly. For driving 5-V
>
> CMOS-level inputs, a pull-up resistor to 5 V is required, and the
> XC4000XL output must be 3-stated when High.
>
> (If the output were to remain active High, the pull-up resistor would
>
> fight the <50 Ohm output transistor, and the output voltage would be
> only 100 mV above the Vcc of 3.3 V.)
>
> The required output structure is commonly called “open collector” or,
>
> more correctly, “open drain,” and this function is easily generated
> inside the chip by driving the Data and the active-Low Output Enable
> signal of the output block together. The external Low-to-High
> transition is then driven only by the pull-up resistor. A 470 Ohm
> pull-up
> resistor to 5 V and a 50 pF load capacitance create a 0.4-to-4.5 V
> rise
> time of >40 ns.
>
> For a faster rise time, drive the internal active-Low Output Enable
> signal not directly from the internal data signal, but from a 2-input
>
> AND gate driven by the internal data signal AND the input signal that
>
> comes back from the same device output pin. On the rising edge, this
>
> assures that the output pull-up transistor is active for most of the
> rise
> time, resulting in a shorter output delay. The important part of the
> rise
> time, from 0.4 to 3.0V, is reduced dramatically, from 20 ns to 3 ns.
> Watch out for ringing, it might pull the signal down again.
>
> In most cases, the fast active edge gets you through the CMOS
> threshold and the propagation delay is then <3 ns. At worst, the
> additional pull-up from the resistor is still needed to reach the
> threshold voltage reliably, but you still saved at least 15 ns.
>
> This idea originated with our European FAEs (Ken Chapman and Nick
> Sawyer). We recently performed experiments to verify the claim. It
>
> works splendidly.
> Peter Alfke, Xilinx Applications
>
>
>
--
--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: 37820Note: We did not file a patent, did not even write an app note ( mistake! ) nor a magazine article ( even bigger mistake ). It's nice to know that smart guys think alike... Meryy Christmas Peter Alfke ======================================= Ray Andraka wrote: > Heck, I was using that trick with 3000 series parts driving wired ORs > back in the early '90s. The problem was to eliminate the rise time on a > shared bus (I think it was a DACK on a motorola processor) >Article: 37821
If I add my two cents to this question, as a Xilinx Spartan-II user (a low cost version of Virtex. From what I see, it is sold at 1/3 of the price of the equivalent density Virtex) struggling to get my PCI IP core to meet mere 33MHz PCI timings (Tsu < 7ns . . . is hard to meet at least in my case), Virtex/Spartan-II (manufactured in UMC's 0.22u process) are the last and fastest device that supports 5V PCI I/O. Virtex-E/Spartan-IIE (manufactured in UMC's 0.18u process) dropped 5V PCI I/O support, and it only supports 3V PCI, which is hardly used on regular desktop motherboards. I must say that if Virtex-E/Spartan-IIE supported 5V PCI I/O, I rather have used them instead of Virtex/Spartan-II because newer devices tends to be cheaper than the older devices of the same density, or for the same amount of money, you get more gates (and features). Although not the question you asked, Altera basically did the same thing when they moved from APEX 20K (supported 5V PCI according to their datasheet, manufactured in TSMC's 0.22u process) to APEX 20KE (dropped 5V PCI support, manufactured in TSMC's 0.18u process). Regards, Kevin Brace (don't respond to me directly, respond within the newsgroup) Antonio wrote: > > Some hardware question on FPGA : > > 1) What's the difference between a part with speed -3 and another with > speed -4 , the number is the number of metal layers ?? > > 2) I read data sheet of Virtex and Virtex E, I didn't found really > much difference, can you explain me which is better and why ?? > > ThanksArticle: 37822
"Theory of Complex Conjugates" Austin Lesea wrote: > > Rick, > > That's It! Chaos Theory, again! I knew it all along. We can predict how many emails > in any thread it takes to get to the three strange attactor points: dropped (everyone > ignores it), VHDL vs verilog, schematic vs hdl, altera vs xilinx, fpga vs asic, ....Article: 37823
Peter Alfke wrote: > > Note: > We did not file a patent, > did not even write an app note ( mistake! ) > nor a magazine article ( even bigger mistake ). > > It's nice to know that smart guys think alike... > > Meryy Christmas > Peter Alfke > ======================================= > Ray Andraka wrote: > > > Heck, I was using that trick with 3000 series parts driving wired ORs > > back in the early '90s. The problem was to eliminate the rise time on a > > shared bus (I think it was a DACK on a motorola processor) And the 8051 ports have used this dynamic pullup/Quasi Open Drain, since 1980, and the 8048 before that. Note that the NAND gate OE, will work best with slower devices, and lightly loaded BUS loads, and become more marginal on faster devices / more heavy loads. This is because the OE is removed as soon as the IO hits the logic threshold ( which may not be the same as other connected devices ) It's probably 'good practice' to copy the 80c51 scheme, which uses a D-FF on the feedback, so the OE width is clock width, not propogation/threshold defined. In a FPGA, D-ff are almost free :-) - Jim GArticle: 37824
Hi everyone
I am using APEX20k400E, and my critical path incluse many long route,
so I want to use clique to group the path into a small area so that it
can run more fast.
but when I open Quartus II 1.1's assignment orgnizer, it can only
group the path into a LAB, no other type, but the description tell me
it can group path into a "LAB, row, half row, or the smallest possible
('Best') area",
why?
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