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
A product originating from the UK called Handel-C would likely be of great interest to you. It allows C type syntax to be compiled and produces a bitstream, xnf, or edif files. It has some subtle nuances that should be observed though. I suspect you could port your code very quickly with this tool. The web link is: http://www.embedded-solutions.ltd.uk/ Click on overview, under the technology heading. Alex :) Eliot Friedman <efriedma@eos.hitc.com> wrote in message news:395917FD.3E5F8916@eos.hitc.com... > I'm new to FPGA/HDL, and assigned to a "proof of concept" project > porting legacy C code to FPGA, hoping for significant execution speed > improvements. What books/hardware/software tools can anyone recommend > to help us get reportable results soonest/cheapest? > > Thanks for all your help, > > Eliot >Article: 23501
->Rob, you have it all wrong.
Sorry, I did not want to mislead anyone. I got it _plain_ wrong. You are
100% correct. I should have spent more time thinking about it and less time
thinking about pizza. I guess that's why I never got an engineering job...
:(
I am well aware of deMorgan's theorem, and bubbles on input and output - that's why I mentioned them, but I should have been more careful about the number of possibilities.
I knew I should have paid more attention in that calculus of variable functions class.
Rob
"Peter Alfke" <palfke@earthlink.net> wrote in message news:3958380C.FB2507C3@earthlink.net...
> Rob, you have it all wrong.
> The question was: How many different "black-box" circuit can be implemented
> with a look-up table.
> And the answer is 2 exp(2exp.n) which means 16 different functions for a
> 2-input LUT. ( Nobody ever claimed 256 for this. You got that wrong, too)
> There are the basic functions like: and, or, xor, but then there are possible
> "bubbles" on the input(s) and/or the outputs, and then there is deMorgan... And
> there is the "ignore" function...
> It's much simpler to look at it as black box: You can test the behavior of a
> combinatorial black box with two inputs exhaustively by applying four test
> vectors (neither more nor less), and observing the four results.
> Obviously, there are 16 different response patterns. ( and there are 256 for 3
> inputs, 64K for 4 inputs, 16million for 5 inputs etc)
> I have used these questions to interview many hundreds of applicants for
> applications engineer jobs, over the past 20 years. Anybody who could not
> (finally) answer these questions satisfactorily never got an applications job
> at Fairchild, Zilog, AMD and now Xilinx. The smart candidates usually "got it"
> in a few minutes.
>
> Greetings
> Peter Alfke
>
> "R. T. Finch" wrote:
>
> > The confusing aspect is the difference between the number of bits of storage
> > available and the number of possible states this storage may represe
nt. 40
> > bits of storage (16+16+8) may have one of 2^40 _possible_ values.
However,
> > it is important to note that it may have only _one_ of these values. IE
40
> > bits of stoarage can't represent every different possible state at the
same
> > time, only one at a time!
> >
> > I think you have the right idea. To calculate the potential number of
> > "states" shouldn't it be 2 * (n+1) not 2 ^ (n+1), because not all the
> > combinations can be active at the same time (there is only one output).
IE.
> > you're not combining state 0000 and 0001, but just counting them. For
> > example with a two input function (under the same constraints), there
are
> > eight basic functions (and, or, xor, andc) * 2 for possibly inverting
the
> > output, _not_ 2^(2+1) = 256 functions. Note that as a black box, with
two
> > inputs and a single output, we could model all possible states using a
truth
> > table with just four entries. It all depends what you want to consider
to be
> > a function. I could call this a single function (sigma) or I could claim
it
> > represents eight different functions. However I think we could define a
> > function, at a minimum, as something that produces a different output
than
> > any other 'function'.
> > Thus the 9-input Xilinx 4+4+3 FGH tree would result in 2 * (3 + 1) = 8
> > states for the 3-LUT times(I think this is a product operation here) 2 *
2 *
> > (4 + 1) = 20 for the two four LUTs which results in a total of 160
possible
> > states.
> > This is certainly far less than the 2^40 number (but I'm not comparing
> > apples to apples here).
> > We know for certain we cannot have more than 2^(9+1) (1024) states
because
> > there is only nine inputs and all possible outcomes can be represented
in
> > 2^10 values. (IE think of a black box with 9 inputs and a single output)
160
> > possibilities is pretty darn good considering the small amount of ram
used.
> > Note: I think we have to distinguish between the number of possible
> > functions implemented and the number of possible functions implemented
with
> > unique results. I think the number of possible states may represent the
> > number of possible functions with unique results (but don't quote me).
The
> > possible number of functions implemented may be quite large (although I
> > seriously doubt it's anywhere near 2^25), however the number of unique
> > results they produce (160) is quite limited.
> > What can be said is that for any possible combination of inputs, there
is
> > only one of 160 states selected. Compare that to the 1024 that would be
> > available with a 512 bit ram.
> >
> > The best approach may be to simply state that given x inputs, one of y
> > different output (states) can be produced. If you wnat to take functions
to
> > the extreme you could claim that an infinite number of functions can be
> > handled, because you can define the function to be as complex as you
like,
> > however all of these functions would reduce to "given x inputs, one of y
> > different output (states) can be produced".
> >
> > If I got the right answer, do I get a prize - pizza would be good :) ?
> > Rob
> >
> > "Tom Burgess" <tom.burgess@home.com> wrote in message
> > news:39555A39.5345F956@home.com...
> > > I withdraw the conjecture as stated. If true, one could implement a
512x1
> > ROM in
> > > a single CLB which is obviously not the case, darn it.
> > >
> > > post in haste, regret at leisure,
> > > tom
> > >
> > > Tom Burgess wrote:
> > > >
> > > > Assertion: for an n-input LUT, with input swapping permitted,
> > > > there are 2^(n+1) possible unique functions possible.
> > > >
> > > > Nor-rigorous proof: For n inputs, there are n+1 possible unique
states
> > available,
> > > > e.g. for 4 inputs, the 5 unique states are {0000, 0001, 0011, 0111,
> > 1111}.
> > > > (with swapping allowed, 0001 is is equivalent to 1000, 0100, and
0010)
> > > > Since the n inputs to the LUT can only assume n+1 states, and the
> > contents of
> > > > each LUT entry are either 0 or 1, there are therefore 2^(n+1)
possible
> > > > unique LUT patterns (functions) available. So the result for n=4 is
32.
> > > >
> > > > Conjecture: the internal structure of the LUT is not important. With
> > input
> > > > swapping permitted, any function of n inputs is possible. So a
single
> > > > 512x1 LUT is equivalent to the 9-input Xilinx 4+4+3 FGH tree. Both
can
> > > > therefore implement 2^(9+1) = 1024 unique functions. The proof is
left
> > as
> > > > exercise for the student :)
> > > >
> > > > regards, tom
> > > >
> > > > Philip Freidin wrote:
> > > > >
> > > > > In article <8j2b2o$ar3$1@news.ust.hk>,
> > > > > WU Chi Hang FOX <eefox@uxmail.ust.hk> wrote:
> > > > > > First, thanks Rickman. However, I am really stucked at
that, I
> > am
> > > > > >not asking about HW questions, I really want to count how many
> > fuctions
> > > > > >that a cascaded LUTs can implement.
> > > > > > For 1-bit LUT, I know there are 4 functions
> > > > > >
> > > > > > Output
> > > > > > Input Function 1 2 3 4
> > > > > > 0 0 0 1 1
> > > > > > 1 0 1 0 1
> > > > >
> > > > > Fine. You have enumerated all the functions of a 1 input LUT
> > > > >
> > > > > Inputs Number of memory bits Functions
> > > > > 1 2 4
> > > > > 2 4 16
> > > > > 3 8 256
> > > > > 4 16 65536
> > > > > N 2^N 2^(2^N)
> > > > >
> > > > > >Function 1 is a zero function, Function 2 is follower, Function 3
is
> > NOT
> > > > > >Function 4 is a one function.
> > > > >
> > > > > So depending on your view of life, not all of these are
'interesting'.
> > > > >
> > > > > Function 1 and 4 ignore the input, function 2 is a wire, and
function
> > 3
> > > > > is an inverter. Maybe only the inverter case is interesting,
depends
> > what
> > > > > you had for breakfast.
> > > > >
> > > > > > However, what I am concerning is that, even there are 4
> > functions,
> > > > > >utimatelly, it is only 0 and 1 pass into the LUT, so, it does not
> > matter.
> > > > > >So, what I think is, no-matter it is cascaded or not, the maximum
> > > > > >function is determined by the last LUT, so for this case, the no.
of
> > functions
> > > > > >is 2^4.
> > > > >
> > > > > For this case maybe, but remember that in the following LUT, it
too
> > has
> > > > > cases where the inputs are ignored, or the output is the inversion
or
> > > > > pass thru of one input, and other inputs are ignored. Which do you
> > > > > consider interesting?
> > > > >
> > > > > > Then bringing back to the XC4000, if that is the case,
then
> > why
> > > > > >the total number of funtions is 2^40 instead of 2^8 ?
> > > > >
> > > > > Since the XC4000 CLB has 40 bits total in the two 4-LUTs, and the
one
> > > > > 3-LUT, there are exactly 2^40 possible configurations.
> > > > >
> > > > > I believe they are not all interesting, because MANY of these
ignore
> > some
> > > > > of the inputs, or are synonyms of each other, with just the input
> > signals
> > > > > swapped. The reason that the pin swaped equivalent functions are
not
> > > > > interesting, is because the place and route software does this pin
> > > > > swapping all the time, and permutes the LUT contents to account
for
> > the
> > > > > pin swapping. I wouldn't be surpised if the number of unique
patterns
> > is
> > > > > less than 2^25. The only way to find out the real number may be
> > through
> > > > > an exhaustive search.
> > > > >
> > > > > Philip Freidin
>
>
Article: 23502Hello, Recently (end of May) there was a thread in the group regarding digital phase lock loops. Below is a part of the thread. It mentions a xilinx app note. Does anyone have the app#? -Thanks -Sue On Mon, 29 May 2000 15:19:39 +0100, dmac <dmac@cutme.matter200.demon.co.uk> wrote: > >Hi Nestor, > >I don't have your original request for info and so have lost track of >your intended application but offer some info from what you have given. > >I have not used type 2 but have used type 1 extensively with success. It >is a superbly simple circuit and so wins hands down in my book - you >could have the basics working in no time. > >I notice that you are intending a comparison frequency of 25MHz in the >phase comparator section. I would avoid this - notice that Peter's Xil >Apps note uses a comparison freq of around 5kHz. The benefits of this >are jitter reduction, filter simplicity (audio range) and simpler >stability calcs. A lower comparison frequency is easily achieved by >dividing the reference and feedback paths by the same amount. Thanks, Dave, for your response. I read the xilinx AppNote too and noticed this low reference, but Peter doesn't mention what frequency he intends to generate with that reference. I do agree that the design will be simpler since certain sections could operate slower. Do you know perhaps how the jitter depends on the reference tone? I would like to perforom some calculations to determine the maximum reference frequency that can also provide a small enough jitter. So far I know that the jitter is related to the loop variance which can be derived from the loop bandwidth. Any comments are welcome. Nestor nestor@ece.concordia.ca > >Peter also mentions ... >... >Watch out also for the type of VCXO used. At the frequency you are >talking, the mfr may use a lower rate item with a freq tripler stage. >Ours did - I think 'cos we wanted a big spread (+/-250ppm) - this will >have greater jitter. 3rd overtone VCXO (the alternative) has, I think, >lower pull range. As you are looking for +/-300ppm, watch out. If you >can reduce the spread, do, as lower spread oscs will be better behaved >and easier (cheaper) to procure. I will see if I can use a narrower range VCXO (+/-150ppm tuning range). Sent via Deja.com http://www.deja.com/ Before you buy.Article: 23503
I have done a board similar to what you want to do. The are 4 devices in my chain in the following order 1) MPC823 (microcontroller), 2) XCV200, 3) XCS30XL, and 4) TMS320C5402. Both the microcontroller and DSP use the JTAG port for emulation. I put 0 ohm resistors on the board to allow me to break the chain between devices if necessary for emulation / debugging. When the 0 ohm jumpers are installed (standard configuration) production will use the JTAG port to test the board. So far we have had no problems emulating either the microcontroller or the DSP (XDS-510) with the jumpers in place. I believe (it's be some months since we made the config / ini files so I don't remember the details) there was a setup step with the XDS-510 (or Code Composer SW) that told it what position the DSP was at in the chain. This caused the XDS-510 (and/or SW) to put any earilier devices in the chain in pass-thru mode so the emulator would work properly. Hope this helps, mark Rickman <spamgoeshere4@yahoo.com> wrote in message news:39583F61.D9F938DA@yahoo.com... > I am looking at what it will take to use JTAG boundry scan on my next > DSP board. I expect the board to have several FPGAs, one TI DSP and > possibly a 16 bit microController, all with JTAG. I would like to string > all of these devices in line to allow software to use the boundry scan > features to test the interconnections on the board. > > But I have read from several people who have had problems with this > approach. The biggest one seem to be that adding other devices to the > JTAG path interferes with the operation of the XDS-510 emulator. Does > anyone have any experience with this? Have you done this and did it > work? Were there any special design features I need to know about, like > does the DSP need to be first in the chain (or the last)? > > I don't expect to be using the FPGA JTAG ports in any other way. But I > may want to use the JTAG to program Flash on the microController. I have > not selected the micro just yet, but is this expected to be a problem? > > > -- > > Rick Collins > > rick.collins@XYarius.com > > Ignore the reply address. To email me use the above address with the XY > removed. > > > > Arius - A Signal Processing Solutions Company > Specializing in DSP and FPGA design > > Arius > 4 King Ave > Frederick, MD 21701-3110 > 301-682-7772 Voice > 301-682-7666 FAX > > Internet URL http://www.arius.comArticle: 23504
Elftmann wrote: > Eirik-- > > Try running a free running clock into TCK and insure that TMS is tied high, > this will insure that the TAP controller state machine returns to > the IDLE state. Assuming it is in an unknown state. If this corrects the > problem then most likely the Xilinx JTAG tap controller is not > getting sufficient power on reset at low temperature and is getting left in > an unknown state, which will most likely leave all I/Os tri-stated. I assume that the optional TRST* is not on this chip. I am a big fan of the optional TRST* pin. Especially for critical systems (I note the original poster was from Lockheed-Martin). Also, when running the free running clock into the TCLK pin, make sure that it is isolated from a regular pin. If a regular pin drives out and low from the instruction register being loaded with something unfortunate, it can clamp the clock and then you get no TCLK and you have a bad day. While according to the JTAG specification one is guaranteed to get back into the TEST-LOGIC-RESET state in no more than 5 ticks of the TCLK, in practice, with some chip designs, it may not do the job as the effects of a bad instruction can take down a system (i.e., high currents). Also a good idea to make sure that at -40C the power supply rise is relatively quick and monotonic so that the power-on-reset circuit doesn't get confused. ---------------------------------------------------------------------- rk It is unlikely that all these stellar engineering, ltd. conditions come together, but we are stellare@erols.com.NOSPAM designers, not gamblers. Hi-Rel Digital Systems Design -- Peter Alfke > "Eirik Esp" <eirik.n.esp@lmco.com> wrote in message > news:394F8CF0.590E9D@lmco.com... > > Technically a CPLD problem, but I thought to post it here anyway. I am > > having a problem with a XC9572XL @ -40 degrees. It seems that when I > > cycle power, the JTAG controller becomes confused and takes over the > > chip. The only way I can reset the JTAG controller is to power down and > > up at room temp. Once the JTAG controller is confused, if I warm the > > part to room, it still misbehaves (TAP controller is in control). I do > > have a switching power supply on the board, so the +5v starts coming up > > about 6 ms before the 3.3v, but if I apply a cap between the 3.3 and +5 > > so the 3.3 starts coming up with the +5v, it still doesn't fix it. I > > tried shorting the TCK directly to gnd and through a 1.1K pulldown, and > > I tied the TMS to +5 through 4.7K and to 3.3 through a wire. I am > > really starting the suspect a ground bounce problem, or the TAP > > controller in the chip itself. Anyone else have similar experiences the > > the 9500XL family at cold? If so, how did you address it? Also, anyone > > know how Xilinx tests the industrial rated parts at cold? Any chance > > the JTAG controller is not tested? If I access the JTAG port in the > > right way at cold, the parts seems to come back to life, so maybe if the > > testing uses the JTAG port, then it wouldn't demonstrate the fault we > > are experiencing?Article: 23505
The Conference Proceedings from the Military and Aerospace Applications of Programmable Devices and Technologies Conference (MAPLD 1999), September 28-30, 1999, are now available. http://rk.gsfc.nasa.gov/richcontent/MAPLDCon99/Technical_Program.html The Conference Proceedings was designed for CD-ROM distribution and some users may experience long download times for some of the material. All abstracts, presentations, and papers are available from the link above. Richard B. Katz National Aeronautics and Space AdministrationArticle: 23506
For a 4 input LUT, there are 4 inputs, 16 bits in the LUT, and 65536 possible patterns that the 16 bits can represent. Because the input signals can be swapped by the routing software, we should consider how many permutations there are for 4 inputs. The answer is 4 factorial. 24 Start with a pattern in the 16 bits of the LUT. Calculate the new pattern for each of the remaining 23 input permutations. If the new pattern is not the current pattern, then it is a pattern that is not unique, just a pattern that can result from permuting the inputs and getting the same output from the LUT. Repeat this for all 65536 patterns, except for those already eliminated as permutations of previous patterns. The answer is 3984 unique paterns ( or interesting functions ). Note that this includes functions where an input has no effect. For example, an inverter only uses 1 of the 4 inputs. If we call the 4 inputs D,C,B,A, and the inverter input is on input A, and th rest are "don't care" the LUTs are actually loaded with a pattern that makes the unused inputs don't care, rather than requiring them to be tied to ground (which would add significantly to the routing congestion). Lut Input arrangement Lut Contents (MSB to LSB) D C B A 0101 0101 0101 0101 Of the 23 input permutations, only the following are interesting: (x can be any of D, C, or B) x x A x 0011 0011 0011 0011 x A x x 0000 1111 0000 1111 A x x x 0000 0000 1111 1111 so only 3 other patterns would be eliminated from the pool by the 23 permutations. Would you like me to post an article that lists them? Philip Freidin In article <3958FD0F.AEEEF144@hia.nrc.ca>, Tom Burgess <tom.burgess@hia.nrc.ca> wrote: >I should point out that I was not discussing the number of functions available >from an n-input LUT (2^(2^n)), but the number of "unique" functions, i.e. >those which cannot be generated from another function by arbitrarily permuting >(swapping) the input pins - which I believe to be 2^(n+1). The difference is that >while n inputs can assume 2^n binary states, only n+1 of those states are unique >in this sense. > >Apologies for any confusion this may have caused, >Tom Burgess >Article: 23507
> > > If you don't have any inputs that will cause a > > > state change following reset (including any logic that will change state > > > without inputs such as a free running counter) then you don't have a > > > problem with the reset timing. I think I covered that in my other > > > description for case 3. > > > > well, why not just hold off the counter for N (N as described/defined > > above)? > > That would require that you have a secondary reset input to your counter > which I discussed in case 2 of my post to Derek Wallace, IIRC. It does not require a secondary reset (for counters). Use the clock enable to waiting during reset. For refresh, where in the count the counter starts, is not relevant anyway. Instead of contesting you point by point, let it suffice to say I believe 'people' over complicating the reset issue. Perhaps, for some applications, it can be complicated, but I believe they are due more to poor engineering, or bad circumstances.Article: 23508
Philip Freidin wrote: > > For a 4 input LUT, there are 4 inputs, 16 bits in the LUT, and 65536 > possible patterns that the 16 bits can represent. > > Because the input signals can be swapped by the routing software, we <snip> But can they ? If you have to design a routing scheme that is a true crosspoint, ( so simplifies the LUT ) you have a LOT of bus loading, and a large die overhead, plus more bits to control the cross points... It might make more sense to allow the LUT to do '4 line allocate', to simplify, and speed, the routing resource. - jgArticle: 23509
Thanks, the XDS510 was my main concern. Did you pick this order deliberately? Are there any issues that made this order preferred? BTW, I looked to see what a MPC823 was and the Motorola web site indicated it is a PowerPC chip. When I looked at the microcontroller section the only parts they listed are the MPC509 and MPC555 both of which seem a bit overgrown to be microcontrollers. Is the MPC823 also an external memory part? Mark wrote: > > I have done a board similar to what you want to do. The are 4 devices in my > chain in the following order 1) MPC823 (microcontroller), 2) XCV200, 3) > XCS30XL, and 4) TMS320C5402. Both the microcontroller and DSP use the JTAG > port for emulation. I put 0 ohm resistors on the board to allow me to > break the chain between devices if necessary for emulation / debugging. > When the 0 ohm jumpers are installed (standard configuration) production > will use the JTAG port to test the board. > So far we have had no problems emulating either the microcontroller or > the DSP (XDS-510) with the jumpers in place. I believe (it's be some months > since we made the config / ini files so I don't remember the details) there > was a setup step with the XDS-510 (or Code Composer SW) that told it what > position the DSP was at in the chain. This caused the XDS-510 (and/or SW) > to put any earilier devices in the chain in pass-thru mode so the emulator > would work properly. > > Hope this helps, > mark > > Rickman <spamgoeshere4@yahoo.com> wrote in message > news:39583F61.D9F938DA@yahoo.com... > > I am looking at what it will take to use JTAG boundry scan on my next > > DSP board. I expect the board to have several FPGAs, one TI DSP and > > possibly a 16 bit microController, all with JTAG. I would like to string > > all of these devices in line to allow software to use the boundry scan > > features to test the interconnections on the board. > > > > But I have read from several people who have had problems with this > > approach. The biggest one seem to be that adding other devices to the > > JTAG path interferes with the operation of the XDS-510 emulator. Does > > anyone have any experience with this? Have you done this and did it > > work? Were there any special design features I need to know about, like > > does the DSP need to be first in the chain (or the last)? > > > > I don't expect to be using the FPGA JTAG ports in any other way. But I > > may want to use the JTAG to program Flash on the microController. I have > > not selected the micro just yet, but is this expected to be a problem? > > > > > > -- > > > > Rick Collins > > > > rick.collins@XYarius.com > > > > Ignore the reply address. To email me use the above address with the XY > > removed. > > > > > > > > Arius - A Signal Processing Solutions Company > > Specializing in DSP and FPGA design > > > > Arius > > 4 King Ave > > Frederick, MD 21701-3110 > > 301-682-7772 Voice > > 301-682-7666 FAX > > > > Internet URL http://www.arius.com -- Rick Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design Arius 4 King Ave Frederick, MD 21701-3110 301-682-7772 Voice 301-682-7666 FAX Internet URL http://www.arius.comArticle: 23510
Thanks for the note. I have both of these documents fortunately. I tried to find them on the TI site and it is almost impossible to find using the search even if you know the document file name. I am sure there is a place to look these up, but it can be hard to find that place. Anyway they are good documents and I will reread them carefully. Etienne Racine wrote: > > Hi Rick, > > Rickman wrote: > > > I am looking at what it will take to use JTAG boundry scan on my next > > DSP board. I expect the board to have several FPGAs, one TI DSP and > > possibly a 16 bit microController, all with JTAG. I would like to string > > all of these devices in line to allow software to use the boundry scan > > features to test the interconnections on the board. > > Assuming all components are IEEE 1149.1 compatible, it *should* be OK. > > > But I have read from several people who have had problems with this > > approach. The biggest one seem to be that adding other devices to the > > JTAG path interferes with the operation of the XDS-510 emulator. Does > > anyone have any experience with this? Have you done this and did it > > work? Were there any special design features I need to know about, like > > does the DSP need to be first in the chain (or the last)? > > The idea is that you cannot directly use the emulator on your JTAG chain > because the resulting bitstream is not understood well by the emulation > software. What must first be done is a small text file to indicate the > emulation software the length of the JTAG instruction register of every > device placed before and after the DSP(s). > > Thus, each non-DSP component will be placed in BYPASS (by shifting an all-1 > pattern for the appropriate number of bits) and will only add a data bit (0) > to the chain. Based on this info, the emulation software will discard > irrelevant data and should work OK. > > As for the position in the chain, I remember some people in c.a.fpga stating > that some positions (i.e. DSP being first) worked better. Was it pure > coincidence, a design issue or just a flaky JTAG compatibility, I couldn't > say. > > Two TI documents are quite useful when discussing issues about emulation & > JTAG: "spdu079a.pdf" and "spra439.pdf"; they're worth a look (if you haven't > done it already). > > Regards, > > tienne. > -- > ______ ______ > *****/ ____// _ \_\************************************************* > * / /_/_ / /_/ / / Etienne Racine, Hardware Designer * > * / ____// __ /_/ Visual Systems Engineering * > * / /_/_ / / /\ \ \ CAE Electronics Ltd. * > */_____//_/_/**\_\_\************************************************* -- Rick Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design Arius 4 King Ave Frederick, MD 21701-3110 301-682-7772 Voice 301-682-7666 FAX Internet URL http://www.arius.comArticle: 23511
Hello, I am trying to interface a PCI9050 card to software. I am in win98 and I do it with a VxD driver. A problem shows when I try to use interrupts. My handler in VxD is called, but if I unmask the irq at the end with VPICD_Phys_EOI() the system freezes. I of course deassert the intA line in my card as soon as I can. Another something suspicious occur, I cannot find my interrupt in CMCONFIG at configuration time but later it appears and I can register it successfully. What's unclear to me is what happens in the chipset between the four PCI irq lines and the PIC. Maybe its the realm of the plug and play bios. I would like to know if there are more registers to look at, to investigate futher the problem. Any hints, threads on the problem welcome. d.Article: 23512
Charles Brain wrote: > > Hi, > > Can someone tell me what I am doing wrong? > Well the problem is now fixed. Adding a boundary scan object to the schematic did the job. - CharlesArticle: 23513
Hello. I need a rough estimation of the power consumption of my design (the target device is a Xilinx XCV400). I've found a web page (http://www.xilinx.com/cgi-bin/powerweb.pl) with the Virtex Power Estimator developed by Xilinx. Is there somebody who used it? Is it a good choice? Or do you suggest another way to perform this estimation? Thanks, SteVeArticle: 23514
Hello, Once PLXTech offered to download the sources of their PCI debuggers, PLXMon and PLXMon95, and phyacc.vxd driver. I would like to see if I can adapt the VxD to win98, it only works for win95. I would be happy if anybody could pass me these sources. PLXTech doesn't support them any longer. d.Article: 23515
Dear motoring experts, I think there is something wrong with my car. When I drive round the corner to my sister's house I find that I can complete the journey in as little as five minutes, yet my journey to work in the next town can take half an hour! So what is the reason? Shoran wrote: > There is a problem in my design under Maxplus2 9.6 . I find that > each individual module(symbol) can run at high speed above > 100MHz, but it will be slow as 20MHz when I connect the symbols > as a whole design. So what is the reason?Article: 23516
You can find a listing of Virtex Demo boards from Xilinx and third parties at: http://www.xilinx.com/products/protoboards/protoboards.htm John Fielden wrote: > I'm looking for a Virtex demonstration board. Something that has at least > one of the larger parts (1000 or 1000E, and above). I would prefer an E > part. > > Does anyone know who makes such a thing? > > Thanks, > > John FieldenArticle: 23517
How to generate a signal with a cpld, an crystal and a resistor and other ? Angel Gutirrez ADVANCED PROSER SL e-mail: agutierrez@matrix.es Tel: +34 93 588 2137 Fax: + 34 93 588 6172Article: 23518
Jim Granville wrote: > Philip Freidin wrote: > > > > For a 4 input LUT, there are 4 inputs, 16 bits in the LUT, and 65536 > > possible patterns that the 16 bits can represent. > > > > Because the input signals can be swapped by the routing software, we > <snip> > > But can they ? > > If you have to design a routing scheme that is a true crosspoint, > ( so simplifies the LUT ) you have a LOT of bus loading, and a large > die overhead, plus more bits to control the cross points... > > It might make more sense to allow the LUT to do '4 line allocate', > to simplify, and speed, the routing resource. > > - jg Not swapping the inputs by some sort of Xbar but allowing the layout tools to choose the input to LUT ``pin'' allocation for most efficient routing then adjusting the LUT configuration accordingly. BTW Its not only input permutations that can reduce the number of distinct LUT functions but also pushing & pulling inversions. If we say that 2 LUT patterns are equivalent if you can get from one to the other by permutations & inversions on the inputs then an N input LUT has (2**(2**N))/(N! * (2**N)) distinct [= equivalence classes of] patterns (?).Article: 23519
<extract> The digital Phase/Frequency Comparator is the same one shown in Xilinx Application Note XAPP028 (Dec 2 1996) http://www.xilinx.com/xapp/xapp028.pdf <end> I think this is the one from Nestor's original post - author is Peter Alfke - now where have I heard that name before :o) Dave sriley <sueriley@my-deja.com> writes >Hello, > >Recently (end of May) there was a thread in the group regarding >digital phase lock loops. Below is a part of the thread. It mentions >a xilinx app note. Does anyone have the app#? -Thanks > >-Sue > dmac remove the obvious for email replyArticle: 23520
--------------8E330EF489511977CB4CD0BE Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit The phase-frequency compartor app note is XAPP028. Juts lick on http://www.xilinx.com/apps/xapp.htm and go to XAPP028. The comparator is a CLB adaptation of the venerable Motorola design of many decades ago . Peter Alfke sriley wrote: > Hello, > > Recently (end of May) there was a thread in the group regarding > digital phase lock loops. Below is a part of the thread. It mentions > a xilinx app note. Does anyone have the app#? -Thanks > > -Sue > > On Mon, 29 May 2000 15:19:39 +0100, dmac > <dmac@cutme.matter200.demon.co.uk> wrote: > > > > >Hi Nestor, > > > >I don't have your original request for info and so have lost track of > >your intended application but offer some info from what you have > given. > > > >I have not used type 2 but have used type 1 extensively with success. > It > >is a superbly simple circuit and so wins hands down in my book - you > >could have the basics working in no time. > > > >I notice that you are intending a comparison frequency of 25MHz in > the > >phase comparator section. I would avoid this - notice that Peter's > Xil > >Apps note uses a comparison freq of around 5kHz. The benefits of this > >are jitter reduction, filter simplicity (audio range) and simpler > >stability calcs. A lower comparison frequency is easily achieved by > >dividing the reference and feedback paths by the same amount. > > Thanks, Dave, for your response. > > I read the xilinx AppNote too and noticed this low reference, but > Peter doesn't mention what frequency he intends to generate with that > reference. I do agree that the design will be simpler since certain > sections could operate slower. > > Do you know perhaps how the jitter depends on the reference tone? I > would like to perforom some calculations to determine the > maximum reference frequency that can also provide a small enough > jitter. So far I know that the jitter is related to the loop variance > which can be derived from the loop bandwidth. > > Any comments are welcome. > > Nestor > nestor@ece.concordia.ca > > > > >Peter also mentions ... > >... > >Watch out also for the type of VCXO used. At the frequency you are > >talking, the mfr may use a lower rate item with a freq tripler stage. > >Ours did - I think 'cos we wanted a big spread (+/-250ppm) - this > will > >have greater jitter. 3rd overtone VCXO (the alternative) has, I > think, > >lower pull range. As you are looking for +/-300ppm, watch out. If you > >can reduce the spread, do, as lower spread oscs will be better > behaved > >and easier (cheaper) to procure. > > I will see if I can use a narrower range VCXO (+/-150ppm tuning > range). > > Sent via Deja.com http://www.deja.com/ > Before you buy. --------------8E330EF489511977CB4CD0BE Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit <!doctype html public "-//w3c//dtd html 4.0 transitional//en"> <html> The phase-frequency compartor app note is XAPP028. Juts lick on <p><u><A HREF="http://www.xilinx.com/apps/xapp.htm">http://www.xilinx.com/apps/xapp.htm</A></u> <p>and go to XAPP028. <br>The comparator is a CLB adaptation of the venerable Motorola design of many decades ago . <p>Peter Alfke <br> <p>sriley wrote: <blockquote TYPE=CITE>Hello, <p>Recently (end of May) there was a thread in the group regarding <br>digital phase lock loops. Below is a part of the thread. It mentions <br>a xilinx app note. Does anyone have the app#? -Thanks <p>-Sue <p>On Mon, 29 May 2000 15:19:39 +0100, dmac <br> <dmac@cutme.matter200.demon.co.uk> wrote: <p> > <br> >Hi Nestor, <br> > <br> >I don't have your original request for info and so have lost track of <br> >your intended application but offer some info from what you have <br>given. <br> > <br> >I have not used type 2 but have used type 1 extensively with success. <br>It <br> >is a superbly simple circuit and so wins hands down in my book - you <br> >could have the basics working in no time. <br> > <br> >I notice that you are intending a comparison frequency of 25MHz in <br>the <br> >phase comparator section. I would avoid this - notice that Peter's <br>Xil <br> >Apps note uses a comparison freq of around 5kHz. The benefits of this <br> >are jitter reduction, filter simplicity (audio range) and simpler <br> >stability calcs. A lower comparison frequency is easily achieved by <br> >dividing the reference and feedback paths by the same amount. <p> Thanks, Dave, for your response. <p> I read the xilinx AppNote too and noticed this low reference, but <br>Peter doesn't mention what frequency he intends to generate with that <br> reference. I do agree that the design will be simpler since certain <br>sections could operate slower. <p> Do you know perhaps how the jitter depends on the reference tone? I <br>would like to perforom some calculations to determine the <br> maximum reference frequency that can also provide a small enough <br>jitter. So far I know that the jitter is related to the loop variance <br> which can be derived from the loop bandwidth. <p> Any comments are welcome. <p> Nestor <br> nestor@ece.concordia.ca <p> > <br> >Peter also mentions ... <br> >... <br> >Watch out also for the type of VCXO used. At the frequency you are <br> >talking, the mfr may use a lower rate item with a freq tripler stage. <br> >Ours did - I think 'cos we wanted a big spread (+/-250ppm) - this <br>will <br> >have greater jitter. 3rd overtone VCXO (the alternative) has, I <br>think, <br> >lower pull range. As you are looking for +/-300ppm, watch out. If you <br> >can reduce the spread, do, as lower spread oscs will be better <br>behaved <br> >and easier (cheaper) to procure. <p> I will see if I can use a narrower range VCXO (+/-150ppm tuning <br> range). <p>Sent via Deja.com <a href="http://www.deja.com/">http://www.deja.com/</a> <br>Before you buy.</blockquote> </html> --------------8E330EF489511977CB4CD0BE--Article: 23521
Rick Filipkiewicz wrote: > BTW Its not only input permutations that can reduce the number of distinct > LUT functions but also > pushing & pulling inversions. If we say that 2 LUT patterns are equivalent > if you can get from one to the other by permutations & inversions on the > inputs then an N input LUT has > > (2**(2**N))/(N! * (2**N)) > > distinct [= equivalence classes of] patterns (?). Isn't math fun! Exponentials and factorials! This was all very enlightening, but it has no practical significance. The 4-input LUT is a very compact and efficient way to implement logic, and it has no restrictions in implementing ANY function of its four input variables. Whether the 64K number is inflated by the 24 input permutations is of no practical significance. Nobody should even try to burden the routing with attempts to save something in the LUT that is there, for free. Let's go back to engineering... Peter AlfkeArticle: 23522
If you have not found the needed software I have the DOS version for a ALLPRO 88. * Sent from RemarQ http://www.remarq.com The Internet's Discussion Network * The fastest and easiest way to search and participate in Usenet - Free!Article: 23523
Why would input swapping reduce the number of functions possible ? To figure out how many functions there was I drawed them all and I don't see why swapping the input names would make a difference. Put all the inputs (storage bits numbered 0 to 39) along the x-axis of a graph, and the output along the y-axis of a graph. Transposing (permuting) two storage bits and there input select doesn't reduce the number of functions (it just changes the order they appear in) doesn't it ? Rob "Rick Filipkiewicz" <rick@algor.co.uk> wrote in message news:395A1985.3E5930D1@algor.co.uk... > > > Jim Granville wrote: > > > Philip Freidin wrote: > > > > > > For a 4 input LUT, there are 4 inputs, 16 bits in the LUT, and 65536 > > > possible patterns that the 16 bits can represent. > > > > > > Because the input signals can be swapped by the routing software, we > > <snip> > > > > But can they ? > > > > If you have to design a routing scheme that is a true crosspoint, > > ( so simplifies the LUT ) you have a LOT of bus loading, and a large > > die overhead, plus more bits to control the cross points... > > > > It might make more sense to allow the LUT to do '4 line allocate', > > to simplify, and speed, the routing resource. > > > > - jg > > Not swapping the inputs by some sort of Xbar but allowing the layout tools > to choose the input to LUT ``pin'' allocation for most efficient routing > then adjusting the LUT configuration accordingly. > > BTW Its not only input permutations that can reduce the number of distinct > LUT functions but also > pushing & pulling inversions. If we say that 2 LUT patterns are equivalent > if you can get from one to the other by permutations & inversions on the > inputs then an N input LUT has > > (2**(2**N))/(N! * (2**N)) > > distinct [= equivalence classes of] patterns (?). >Article: 23524
You approach is of course correct - I had been sidetracked into considering the number of n-bit binary patterns which are not permutations of each other while thinking I was doing something else. Anyway, I think I have demonstrated enough combinatorial ignorance for now and will consider the thread closed :) regards, Tom Burgess Philip Freidin wrote: > <snipped> > > For a 4 input LUT, there are 4 inputs, 16 bits in the LUT, and 65536 > possible patterns that the 16 bits can represent. > > Because the input signals can be swapped by the routing software, we > should consider how many permutations there are for 4 inputs. > The answer is 4 factorial. 24 >
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