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
Hi: I am now looking for a floorplanner with open source code. I need to make some adjustions on the codes to meet the specific requirement of our project. Any suggestions? Thank a lot. YoursArticle: 49801
I think some of you might find reading the following instructive: http://www.fpga-faq.com/FAQ_Pages/0017_Tell_me_about_metastables.htm Philip FreidinArticle: 49802
"Ray Andraka" <ray@andraka.com> wrote in message news:3DDC7740.15E8C72@andraka.com... > I heartily disagree. I don't think you do disagree, much less heartily ;-) > Structural code, which is required for placement and > mapping in the code is probably the most portable way to write code in VHDL. Agreed, I never said any differently. > The same would be true with schematics if the tools shared a common file format, > but they don't. WIth HDL's the file format is common, so that is not an issue > here. Exactly, and I never said any differently. > ... I can also put the > attributes for all of these tools in, because they are non-interfering. Yes, but my point is they are tool specific. That was it, it's the only point I was making, and you apparently agree with that. Regards, AustinArticle: 49803
Hi All. [...] > use addresses of resources listed for the PCI card, but it does not work, > too. > > Is your solution implemented in Impact 4.2? [...] Maybe try plug printer in port on PCI and Xcable to lpt1 ? furiaArticle: 49804
If you are using Xilinx, your best bet is to learn the UCF syntax, and write Perl scripts to do custom placement. -Kevin "Hua WANG" <wanghua@imec.be> wrote in message news:a9ac3fc0.0211210703.2cb49653@posting.google.com... > Hi: > > I am now looking for a floorplanner with open source code. I need to > make some adjustions on the codes to meet the specific requirement of > our project. > > Any suggestions? > > Thank a lot. > > YoursArticle: 49805
Others will probably be able to explain it better than I am, but I disagree. Slack time is basically the time that you need to reserve in case your FF goes metastable, so that (you hope) the metastability has the time to resolve itself. Assuming that your FF has already gone metastable and is settling to its final value, the noise will have as much chance of kicking it right back into a metastable state as it does of kicking it out of that state. To take from the ball on a hill analogy, if the ball is perfectly balanced on the top of the hill and you are waiting for it to come down, then noise might knock it off, but if the ball is just starting to roll down, noise can just as well knock it back up to the peak. Pierre-Olivier Michael S <already5chosen@yahoo.com> wrote: > hmurray@suespammers.org (Hal Murray) wrote in message news:<utiom46n1pu6a7@corp.supernews.com>... >> >I have tried to analyze the behaviour of such an analogy in the presence >> >of noise, but I don't have the tools to do it rigorously. It may well >> >be possible to shorten the metastable time with noise, but I really >> >can't prove it one way or the other. >> >> Somebody mentioned noise recently, but I'll repeat. It doesn't work. >> It kicks the system toward the stable point just as often as it helps >> you by kicking the system in the right direction. >> > As I said above, there is very short time (metastability-catching > set-up time window) when noise has a chance to kicks the system in the > wrong direction. > On the other hand, in the properly designed system there is much > longer time (slack time) when noise might move a node out of > metastability. > According to Xilix estimations metastability-catching set-up time > window is 7 orders of magnitude shorter than typical slack time, so > the negative effect of the noise is negligible relatively to its > positive effect. > Before you start to argue, try to realize that I am not talking about > metastability as a theoretical phenomenon but about metastability as > something which can compromize the correctness of the design. > You are right, noise doesn't reduce the probability of entering > metastable state. However, it does increase a probability of resolving > metastability within a slack time window. If metastability resolved > within a slack time window - nobody care about it. I don't even know > how to detect the case. From the practical point of view the case is > the same as when metastability didn't happen. > Once again, I expect metastability-affected system to performe better > (produce longer MTBF) at higher temperature. I don't know how much > better. I would be glad to see the measurements results. Because Xilix > Lab alredy has a proper setup for the mesurements it must be easy for > them to repeat the tests at -40Deg and at +70Deg. It's all I am asking > for.Article: 49806
rickman wrote: > nospam wrote: > > > > hmurray@suespammers.org (Hal Murray) wrote: > > > > >>I have tried to analyze the behaviour of such an analogy in the presence > > >>of noise, but I don't have the tools to do it rigorously. It may well > > >>be possible to shorten the metastable time with noise, but I really > > >>can't prove it one way or the other. > > > > > >Somebody mentioned noise recently, but I'll repeat. It doesn't work. > > >It kicks the system toward the stable point just as often as it helps > > >you by kicking the system in the right direction. > > > > It depends where the noise is. Yes noise on the input signal makes no > > difference. Noise (or preferably a well defined high frequency 'agitation') > > in the flipflop feedback path would limit the duration of the metastable > > state. > > I feel bad now. I started this thread because I had hoped to get some > definitive information to take back to a discussion that was hot in > comp.lang.forth a few days ago. I had some people over there telling me > that they could "cure" metastability or that it was dealt with in the > chips. There was even one chip designer who told me that you could > safely "ignore" metastability in modern logic (modern being anything > smaller than 0.25 um) because of the high settling speeds. > You might consider referring anyone on comp.lang.forth who thinks metastibility can be "cured" to this NG sci.motion.perpetual since Hal Murray's history of metastability closely parallels this argument, with a delay of a couple of centuries. Its amazing how hard people will struggle when the truth crunches into their deepest held beliefs.Article: 49807
And how do you tell IMPACT whether the parallel port is mapped to I/O-space or memory-space? The PCI-Spec recommends that all new designs should be mapped to memory space, so his PCI parallel port might reside in memory space. Doing an IO access to the bases address stated by the hardware manager would then not be very helpful. Isn't there a driver abstraction layer for LPTs, that impact yould use? I guess it does not use low level IO accesses to talk to the USB cable? Kolja Sulimma > Neil Glenn Jacobson <neil.jacobson@xilinx.com> wrote in message > news:<3DDC0AF3.566AC256@xilinx.com>... > As a workaround for this situation use the XIL_IMPACT_ENV_LPT1_BASE_ADDRESS > environment variable in iMPACT. If this variable is set, the specified value will be used as the > port address for the lpt port. > The port base address is listed as a resource in Windows Device Manager->Ports->LPTx devices. Right > click on an LPT > device, then select Properties->Resources->Input/Output Range. > > From a command window set the aforementioned env variable prior to invoking iMPACT. > Specify the port base address value in hex. > > ex. set XIL_IMPACT_ENV_LPT1_BASE_ADDRESS=378 > > This will set the LPT1 base address. LPT2, LPT3 and LPT4 are also supported > > > > Dziadek wrote: > > > Hi, > > The motherboard printer port in my PC is used by some hardware, so I have to > > connect the Parallel Cable to another printer port on an PCI I/O card. The > > port is EPP etc, but - as I suppose for most PCI printer ports - does not > > use the original printer port addresses (378,etc.) but some other in PCI > > space.Article: 49808
In article <utiom46n1pu6a7@corp.supernews.com>, Hal Murray <hmurray@suespammers.org> wrote: >>I have tried to analyze the behaviour of such an analogy in the presence >>of noise, but I don't have the tools to do it rigorously. It may well >>be possible to shorten the metastable time with noise, but I really >>can't prove it one way or the other. > >Somebody mentioned noise recently, but I'll repeat. It doesn't work. >It kicks the system toward the stable point just as often as it helps >you by kicking the system in the right direction. I don't see why. Unstable equilibrium state: Noise in either direction kicks it away. Next to the unstable equilibrium state: Noise away kicks it away. Noise TOWARDS kicks it towards. So in the unstable equilibrium point, all noise kicks away. Just outside of it, half the noise kicks it away. Of course, "MEET THE SETUP AND HOLD TIMES" is a lot easier to say in general. :) -- Nicholas C. Weaver nweaver@cs.berkeley.eduArticle: 49809
Ray Andraka wrote: > This is not good synchronous design practice. Instead, consider clocking > all your logic from a common clock, and then use a synchronous edge detect > (signal and'd with inverted signal delayed by 1 clock) as a clock enable to > the register you were previously clocking with a logic signal. > There are a couple of places where some async clocking is essential and the double sampled digital edge detector approach breaks down. Basically these are so-called `source synchronous' protocols where the data strobes do not run continuously. o IDE UDMA where the worst case data validity window around the strobe edges is very narrow. o Hitting the DDR DRAM read data eye at high - 133Mhz+ - speeds.Article: 49810
Can anybody give me (a NOVICE in FPGA programming) some advice on how to implement a look up table on an FPGA? Prefferably using Xilinx software. Thank you TomArticle: 49811
Noddy wrote: > Haven't encountered this error before... > > I am building a truncating module in schematics by simply using a bus tap to > take off a sub-bus. Main bus is 15bits wide, and I am taking bits 12-8. ISE > complains that the bus and sub-bus cannot be connected to different I/O > markers... how do I get around this?? > > thanks > > adrian > > > Use non-inverting buffers and a different name for the output bus. This all gets optimized out later. If you do this a lot it's worthwhile to build a small library of bus buffers of various widths. regards, TomArticle: 49812
Hello all, I've recently been examining possibilities for implementing the exponential function in a virtex 2. I am attempting to implement a simple neuron model (MacGregor) in a virtex 2 device using only one multiplier per neuron initially (eventually many neurons per multipier). The numerical integration scheme for the model is fairly straightforward except it includes an exponential function. After looking at a few possibilities (shift-add and look up table) it seems like simply using a built in multiplier to implement the taylor series expansion e^x = 1 + x + (x^2)/2! + (x^3)/3! + .... is a reasonable and easy way of solving this problem especially if I am using a multiplier anyway. I just thought I would see if anyone here has done this sort of thing before or if any of the fpga gurus here see any problems with this approach. Thanks for your help, ChipArticle: 49813
"Leon Heller" <leon@heller123.freeserve.co.uk> schrieb im Newsbeitrag news:aripp2$ifk$1@newsg2.svr.pol.co.uk... > One big advantage with the old devices is that they come in PLCC, making > prototyping very easy. You sissy!! ;-)) Serious, one can also hand solder a 0.5mm pin pitch QFP, its easier than it sounds. Also, the old part is worthless when the free tools dont support it (any more) as it is the case with Spartan. Also, the old parts are quite expensive. -- MfG FalkArticle: 49814
Agreed,
And the way to deal with those is a very localized local clock, just enough to get
the data into a register and toggle a semaphore. When this is the case,
floorplanning is essential to avoid killer clock skew, and in some cases
(especially with the post 3.3i routers) some hand routing using FPGA editor (yuck).
In the case in question however, the problem statement indicated that it was a slow
signal coming in, in whch case the circuit I suggested is a lot less painful to
incorporate.
Rick Filipkiewicz wrote:
> Ray Andraka wrote:
>
> > This is not good synchronous design practice. Instead, consider clocking
> > all your logic from a common clock, and then use a synchronous edge detect
> > (signal and'd with inverted signal delayed by 1 clock) as a clock enable to
> > the register you were previously clocking with a logic signal.
> >
>
> There are a couple of places where some async clocking is essential and the
> double sampled digital edge detector approach breaks down. Basically these are
> so-called `source synchronous' protocols where the data strobes do not run
> continuously.
>
> o IDE UDMA where the worst case data validity window around the strobe edges is
> very narrow.
>
> o Hitting the DDR DRAM read data eye at high - 133Mhz+ - speeds.
--
--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: 49815"Tom" <tom_robinson6@yahoo.com> schrieb im Newsbeitrag news:74172c34.0211210959.52b18f74@posting.google.com... > Can anybody give me (a NOVICE in FPGA programming) some advice on how > to implement a look up table on an FPGA? Prefferably using Xilinx > software. Just take a HDL and tell them what you want. In VHDL it would look like this. case (input) is when "000" => output <= "0101"; when "001" => output <= "0001"; when "010" => output <= "1101"; etc. -- MfG FalkArticle: 49816
But is not the placement attributes that are tool specific. If you do those
with user attributes, like my example, those do not change from tool to tool,
and you get EXACTLY the same result regardless of the tool provided your tool
supports user attributes. It is the attributes for RTL level stuff, things
like keep buffers, preserving inferred registers and what not that can
differ....basically the synthesis directive type attributes. Since those,
almost by definition, don't apply to structural construction using primitives,
the structural code can generally be run without a hitch on other tools. Even
'rope-pushed' RTL with vendor attributes will generally compile and give you a
working circuit on another tool, but it might require some tweaks to get back
to the exact implementation you wanted.
This part of the discussion started with your asking about, and positing that
mapping and placement in a structural design makes the code tool-specific. My
arguement is that it does not, and in fact makes the code more portable than
'rope-pushed' RTL. The vendor specific attributes have nothing to do with
place and map for the most part (although some do have vendor equivalents,
xc_map and xc_rloc in synplify, for example, which I don't use because a) they
are not portable, b) they had been broken for a while, c) they are not as
flexible as the user attributes).
For reference, you started this part of the discussion with:
"I also believe this ability is somewhat tool specific? Are the mapping and
placement abilities of HDLs cross tool abilities? Will the highly mapped
and placed HDL code used for Synplify work with FPGA Express? That, of
course, is a major issue in touting portability if it is not, as you ARE
relying on a single vendor for the tool, just like you are with schematic,
though not as entirely...as the code can be massaged to "work", but not
necessarily as well as it would with the tool it was intended for."
Austin Franklin wrote:
>
>
> > ... I can also put the
> > attributes for all of these tools in, because they are non-interfering.
>
> Yes, but my point is they are tool specific. That was it, it's the only
> point I was making, and you apparently agree with that.
>
> 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: 49817
Speedy Zero Two wrote:
>
> Hi Kevin,
>
> Thanks for the reply.
>
> I think a FAQ would be a great idea, why not start one?
>
I think what I already posted was sort of an FAQ.
> > 1) Obtain the specification before you start!
> >
>
> It's on my wish lish
>
Yes, you definitely need the original specification if you are
serious about developing one.
> > 2) Obtain a user's manual for PCI IP core already developed by someone
> > else
> >
>
> I used a PCI>ISA like document for my info
>
You mean PLX Technology's PCI ASSP bridge?
> > 3) Don't bother with Opencores.org PCI IP core's Verilog RTL code
>
> I agree, I tried this route.
>
Yeah, I am not the only one who thinks the Opencores.org PCI IP
core is hard to use or understand.
> > 4) Don't pay for expensive EDA tools
>
> I too use Webpack and Modelsim.
Having the paid version tools may improve your productivity
somewhat, especially the simulator, but I don't think it can be
justified if you are on a tight budget or the size of the project isn't
too large.
> > 5) HDL is fine
> >
> > Since my PCI IP core meets the 33MHz PCI's timings with
> > Verilog, there is no need to resort to schematics.
> > Choose Verilog or VHDL whichever you like.
>
> Verilog rules IMHO obviously.
>
I prefer Verilog because the language is less verbose than VHDL.
> > 6) Don't bother with Altera
> >
> > The lack of three FFs per IOB (IOE in Altera) of Altera FPGA
> > makes it hard to meet 33MHz PCI's Tval < 11 ns requirement.
> > Xilinx Spartan-II has three FFs per IOB, and
> > Also, Quartus II's fitter (P&R) and floorplanner quality is far worse
> > than Xilinx's software.
>
> Quartus who ?
>
Quartus II is Altera's design software.
You can use the Web Edition of Quartus II for free if you are curious,
but it will probably be waste of time.
> > 7) Learn the pitfalls of Xilinx IOB
> >
> > The one fanout rule almost always requires the synthesis tool
> > to take care of this problem.
> > This posting should help you take care of the problem.
> >
> >
> http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&selm=cc7b0b5f.0210081256.
> 22ba2b1f%40posting.google.com
> >
> >
> > As long as you get the synthesis tool to duplicate the IOB output and
> > tri-state FFs, you should not have problems meeting the Tval < 11 ns
> > requirement (And now you will have to worry about Tsu.).
>
> Webpack does this under GUI control.
>
You might think the software will solve all of the IOB issues,
but you still have to know the IOB packing rules like the single fanout
rule and how to instruct the software to get FFs into an IOB even if you
are using the GUI design flow.
It's trickier than you think, but it shouldn't be too bad as long as you
follow the instructions I wrote.
> > 8) Meeting the setup time (Tsu) is the hardest part
>
> I have done post P&R and Tsu is OK, however I recently designed a SDRAM
> controller and all was fine in simulation but synthesis did not come up to
> expectations!!
The SDRAM controller problem sounds like something went wrong
during synthesis.
Regarding Tsu, you should be aware that when you use IOB output and
tri-state FFs (I am not sure if you are using them.), they will worsen
the Tsu.
The reason for that is because there will be some extra routing delay
from a CLB to an IOB.
> > 9) Eliminate hold time completely by using IOB input FFs
>
> I think Webpack does this under GUI control automatically.
Yes, the GUI flow can solve this problem easily, but it took me
a while until I understood why hold time was occurring in the first
place.
> > 10) A well developed PCI IP core for Spartan-II does not require doing
> > hand placement for 33MHz PCI
> >
>
> I require 33MHz and use auto P&R which seems OK....
>
Beating the 33MHz frequency isn't hard if the target device is
Spartan-II, but meeting the Tsu might still be difficult.
> > 11) It will be nice if the PCI IP core is in padless netlist form
> >
> > In my opinion, it will take more than an hour to do the text
> > editing, so do it when you really have to fire up your design.
> > Although EDIF's syntax isn't nice, it shouldn't take more than 15
> > minutes to figure out the syntax.
>
> I have no idea about this, my simulations can take a while but normally
> multiplex it with something else.
>
The idea here is to break up the design into two sections, the
PCI IP core and the PCI IP core's backend logic.
The backend logic will instantiate the PCI IP core which will be kept as
a padless netlist, so that you don't have to resynthesize the PCI IP
core each time you make modifications to your backend logic.
Doing so, you will save a lot of time in synthesis in the long run.
Also, supplying an IP core as a padless netlist is the the standard way
IP cores are supplied in my opinion.
> > 12) Keep your PCI IP core generic as much as possible for maximum
> > portability.
> >
>
> I have had to ignore the PCILOGIC as I have no idea how to use it. Could you
> enlighten me?
Again, it is not necessary to use PCILOGIC if the PCI IP core
only needs to meet 33MHz PCI's timings, but knowing how it works
probably won't hurt.
Here is how PCILOGIC looks like.
_____________________________________________________
module PCILOGIC (
IRDY,
TRDY,
I1,
I2,
I3,
PCI_CE
);
input IRDY;
input TRDY;
input I1;
input I2;
input I3;
output PCI_CE;
endmodule
_____________________________________________________
Here is how you instantiate PCILOGIC in Verilog.
_____________________________________________________
PCILOGIC MAGICBOX (
.IRDY(IRDY_n_Pin),
.TRDY(TRDY_n_Pin),
.I1(Block_IRDY),
.I2(Unconditional_Transfer),
.I3(Block_TRDY),
.PCI_CE(AD_CE)
);
_____________________________________________________
The equivalent equation inside looks like this (Actually, the PCILOGIC's
logic consists of three NAND gates, but I converted it using DeMorgan's
theorem for clarity.).
_____________________________________________________
assign PCI_CE = I2 | (!(I3 | TRDY)) | (!(I1 | IRDY));
_____________________________________________________
I1 and I3 masks IRDY and TRDY, respectively, so that PCI_CE is negated
when you don't want AD[31:0] to be changed.
I2 can override rest of the signals when it is high.
>
> > 13) DEVSEL# decode should be medium or slow, but not fast
> >
> > Don't even try to do address decoding without registering
> > AD[31:0], C/BE#[3:0], and IDSEL (IDSEL for configuration cycle only).
> > That means, the DEVSEL# decode will be medium or slow.
> > I think medium DEVSEL# decode in general is preferred.
>
> I think I have that covered...
>
> > 14) Registering the signal should be done only for address decoding
> > and parity calculation
> >
>
> I presume you mean that as PCI is syncronous unregistered inputs should be
> OK?
>
Nope, the synchronous unregistered inputs are the ones that
cause most of the timing problems when developing a PCI IP core.
So, to reduce the number of critical timing paths, register input
signals as much as possible.
If you don't care about performance (i.e., Willing to insert one wait
state for each burst transfer data phase, or the PCI IP core doesn't
accept a burst transfer.), you can register even the PCI control signals
(i.e., FRAME#, IRDY#, DEVSEL#, TRDY#, STOP#.), and you will have very
little timing problems, but if you do care about performance (i.e., Want
to handle a no wait state burst transfer.), you cannot register the PCI
control signals.
Either case, you can still use input registering for address decode and
parity calculation.
> > 15) Read Appendix B of the specification before developing the state
> > diagram
> >
>
> Bus Busy, That would have caught me out, thanks
>
That's really easy to miss if you haven't seen the Appendix B
target state machine diagram.
> > 16) Use Address/Data stepping
> >
>
> I presume you add an extra state between the address and data phase. If not,
> could you explain?
>
Using Address/Data stepping means that, the PCI IP core will
turn on AD and C/BE# one or more cycles later.
The benefit of doing this is that a signal path starting from
a control signal pin to AD or C/BE#'s tri-state control FF will become
less of a critical timing path.
The downside of doing this will be some performance, but as long as your
PCI IP core is a target only, the performance penalty should be minimal.
> > 17) The PCI IP core must be able to keep up with a device does fast
> > DEVSEL# decode and performs Fast Back-to-Back transaction.
> >
>
> Can you explain fast Back-to-Back transfers?
>
The specification explains it well, but anyhow, a fast
back-to-back transaction means that you won't see wait states (FRAME# =
"H" and IRDY# = "H") between two transactions.
Normally, when a transaction is ending, FRAME# will be 1 (High) and
IRDY# will be 0 (Low), and after that, FRAME# will be 1 (High) and IRDY#
will be 1 (High).
However, when a fast back-to-back transaction is occurring, after FRAME#
is 1 (High) and IRDY# is 0 (Low), FRAME# and IRDY# will skip going back
to an idle state (FRAME# = "H" and IRDY# = "H") , and instead starts a
new transaction (FRAME# = "L" and IRDY# = "H").
In your target state machine, you are "required" to be able to detect a
fast back-to-back cycle during a turnaround state.
> > 18) All PCI devices must be able to handle Fast Back-to-Back
> > Transaction to the same device
> >
> > Regardless of the state of Fast Back-to-Back Enable bit
> > (Bit 9 of Command Register), all target devices must be able to handle
> > Fast Back-to-Back Transaction to itself.
> > The way to implement is to see if FRAME# is asserted during a bus
> > turnaround state (See Appendix B), and if it is asserted, move to
> > address decode state I mentioned without going through an idle state.
> > Otherwise, return to an idle state.
>
> Fast Back-to-Back Transaction to itself!! Could you clarify?
>
However, there are two types of fast back-to-back transaction, a
fast back-to-back transaction to the same target and a fast back-to-back
transaction to different targets.
Ignore fast back-to-back transaction to different targets because almost
no one does that, but "all" PCI devices must be able to handle a fast
back-to-back transaction to the same target, regardless of the state
(Whether or not it is 1 or 0.) of Fast Back-to-Back Enable bit (Bit 9 of
Command Register).
I think you will need the specification to understand what I am talking
about.
> > 21) For a fully compliant PCI interface, you need to do error checking
> >
>
> The interface is for an in-house ATE which currently runs off ISA.
> There is only a target and I guess error checking is not really required.
>
The specification says you have to implement parity checking,
but a lot PCI devices don't do.
I implemented it because I didn't want to bend the rules.
> > 23) Creating a fast parity generator
>
> I have pretty much ignored parity assuming that my system will be error
> free.
>
Whether or not your PCI IP core does parity checking, it is a
requirement to generate parity.
The problem with the assumption you are making is that, you will never
know whether or not the PCI bus you have your PCI card in will do parity
checking.
While most desktop PCI chipsets don't bother to do data parity checking,
several server class PCI chipsets do data parity checking.
Kevin Brace (In general, don't respond to me directly, and respond
within the newsgroup.)
--
Posted via Mailgate.ORG Server - http://www.Mailgate.ORG
Article: 49818
Falk Brunner wrote:
> Connect clk0 and clkx2 from the DLL to output pins to see if there are
> signals present.
> Also connect the reset and LOCKED signal to output pins.
>
> --
> MfG
> Falk
Hello,
thanks for the answer.
I have connected clk0, clk2x, Reset and Locked Signal to output pin.
The Output CLK0 => Bufg => buf => inv => led has got the value '1' .
CLK0 has got the value '0'.
The RESET has got the value '0' (GND=> BUF => INV => '1').
But i will use Clk2x and Locked in this schematic then i get only errors:
For Clk2x -> bufg -> out (led):
Locked -> bufg -> out
"Could not pack the GCLK xlxi_24. The symbol has a constraint
(LOC=DLL0) that specifies an illegal physical site for the component.
Please correct the constraint value."
For:
clk2x -> obuf -> out (led)
lock -> obuf -> out (led)
"ERROR:NgdBuild:466 - output pad net 'led<4>' has illegal connection"
I will be glad, if i can get more informations or answers (for using dll).
with kind regards
Stefan
Article: 49819Hello Anyone know why the statment x := (others => '0') ork on unsigned but don't work on a subtype of unsigned. ThanksArticle: 49820
Worked fine for me, with or without SP2 What's the error? D "Thomas Buerner" <buerner@lrs.e-technik.uni-erlangen.de> wrote in message news:3DC9353C.32321019@lrs.e-technik.uni-erlangen.de... > > Hi all > > impact works fine when I use it as administrator > but brings up an error message when I try to use > it as an simple user. > does anybody know how I can use impact as user not as administrator? > > thanx > > ThomasArticle: 49821
yes President, Quadrature Peripherals Altera, Xilinx and Digital Design Consulting email: kayrock66@yahoo.com http://fpga.tripod.com -----------------------------------------------------------------------------"hiro" <hiro-ta@pd6.so-net.ne.jp> wrote in message news:<aris55$2tu$1@news01be.so-net.ne.jp>... > Dear all, > > I have a question about Xilinx's ISE tool regarding > clock enable input of FFs. > I use FFs with clock enable input(that is FDCE) and > constrain clock frequency with PERIOD attribute. > The timing analyzer will check all data paths between > two FFs whether the sets of path delay are within specified > value with respect to the constrain. > Likewise, are paths to clock enable input of FFs also > setup/hold timing-checked at this time ? > > Thanks, > > HiroArticle: 49822
3 ideas for you: 1) The input structure for the Vertex has a facility to insert a fixed delay which has the effect of increasing your hold time for the case that you used the DLL and violated hold time. 2)The DLL has a facility to "trim" the delay that its inserting, maybe the resolution is fine enough to get the timing relationship you desire. 3) Is there a speed grade available that matches you input data timing, you are SO close. Best Regards President, Quadrature Peripherals Altera, Xilinx and Digital Design Consulting email: kayrock66@yahoo.com http://fpga.tripod.com ----------------------------------------------------------------------------- Andreas Schweizer <aschweiz@iiic.ethz.ch> wrote in message news:<3ddceff3@core.inf.ethz.ch>... > Hi all, > > can somebody help me with the following problem? The > target device is a Xilinx Virtex FPGA (speed gr. -6) > > Data is available to the FPGA from outside in a small > window 1.5ns before CLK and stays at the inputs until > 800ps after CLK. I read that data into IOB registers > on each rising edge of CLK. > > I have set constraints on the inputs as follows: > NET "dimmcsxsib" OFFSET = IN 1.5 ns BEFORE "dimmclkxci" > > Now, without using a DLL for dimmclkxci, I get > Tsetup = 2.3 ns, Thold = 0.0 from the static timing > analyzer, with Tsetup violating my constraint. > Without the IOB delay element, I get > Tsetup = 0.509ns, Thold = 0.943ns > Now, the window is considerably smaller, but Thold > violates my constraints. > > With dimmclkxci going through a DLL, I get > Tsetup = 1.7 ns, Thold = -0.4 ns > which looks promising but still violates the constraint. > Forcing the DLL to bring the rising edge of CLK0 earlier > by inserting more buffers into the feedback line > doesn't seem to work (I have two BUFG in series, so > it's clear that the 2nd BUFG isn't driven by a CLKDLL...): > > ERROR:LIT:179 - BUFG symbol "dlldlybufg" (output signal=s2) > is driving a CLKDLL. When the CLKIN pin or the CLKFB pin of > a CLKDLL is being driven by a BUFG,the BUFG must also be > driven by a CLKDLL. To by-pass this error, set environment > variable XIL_MAP_ALLOW_ANY_DLL_INPUT. > > The mapper seems to ignore the XIL_MAP_ALLOW... env > variable, because I still get the error after setting it > to 1. > > Can anybody help me here? > > Thank you, > AndyArticle: 49823
I'm with Hal on this one, do the computer part of your design first, then, if you're still interested, you'll know exactly the resources you'll need. President, Quadrature Peripherals Altera, Xilinx and Digital Design Consulting email: kayrock66@yahoo.com http://fpga.tripod.com ----------------------------------------------------------------------------- hmurray@suespammers.org (Hal Murray) wrote in message news:<utp01v3umse3ff@corp.supernews.com>... > >I would like to know what kind of project complexity I'm able > >to realize (when having the knowledge) with 100 CLBs / 360 FF / > >5000 gates in the xcs-05 fpga and 196 CLBs / 616 FF / 10k gates > >in the xcs10 fpga. > > I suggest doing enough of a design so that you can answer that > question yourself. Or finding a design you can push through > the tools far enough to get some numbers. > > You might get some ideas by browsing in opencores.org. > Here is a URL to a PCI bridge that uses 1300 slices and > some RAM, but that's a test chip that includes a bridge > and CRT core too. > http://www.opencores.org/projects/pci/ > Maybe if you look harder than I did you can find a breakdown. > > [I also second Ray's suggestion to use a newer part.]Article: 49824
A level converter. Am I missing something here? Theres got to be some 3.3V PLLs out there too. President, Quadrature Peripherals Altera, Xilinx and Digital Design Consulting email: kayrock66@yahoo.com http://fpga.tripod.com ----------------------------------------------------------------------------- anand287@lycos.com (Anand) wrote in message news:<a6908954.0211201917.67cb5048@posting.google.com>... > Hi everybody, > > I am looking for a programmable oscillator for a board consisting > mainly of a Xilinx Virtex 2000E . (XCV2000E) > > For this purpose I looked at DS1075 econ-oscillator ,but this > oscillator is 5 V. > On the other hand the Virtex-E I/O's ( I assume that I/O's include > clock inputs)are 3.3 . > > Is there a solution for this problem ? > > I need to be able to program the clock in-circuit ? > > > please do reply, > > thanks very much , > Anand Kulkarni
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