Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
Hello, > How will the core behave if the host will issue a type 1 > config cycle while selecting the xilinx device with IDSEL? It will ignore the cycle, because it was designed to do so. > Can my internal logic sniff configuration transaction > on the PCI bus? Not really. The v3.0 core has some provision to do things like this, but the v5.0 core does not. Plus, even if you could, the configuration mechanism will not work properly. What if you need to do a config read? Snooping won't help, because you need to actively participate in the transaction. If you contact your Xilinx FAE, and indicate you need to do a PCI bridging application, they can help you. EricArticle: 61951
If your homework is too tough, and the time just flies away, thinking hard is not enough, click: comp.arch.fpga. There you find those friendly souls, Austin, Philip, Peter, Ray filling in your mental holes, making problems go away. But learning is for you to do, even if it hurts the brain. The one that has to learn is you. There's no substitute for pain. If you want to learn design don't treat homework just as play. Real life is not benign, and you'll have to earn your pay! sooner or later... These lines were triggered by the endless dice discussion. Peter Alfke, Xilinx ApplicationsArticle: 61952
Hi, I am very interested in exploring the use of ICAP for self-reconfiguration of the Virtex2 fpga. XAPP 662 describes the in-system reconfiguration of RocketIO attributes, and I have been trying to understand the process of self-reconfiguration through this application note as well as the reference design that comes with it. It seems that we need to configure the FPGA with a bitstream generated from hdl that includes an PLB bus arbitrator and controller, as well as ICAP IPIF to the PLB. Does this mean the ICAP, possessing access the configuration memory, would actually have access to parts of the configuration memory that defines the arbitrator and ICAP IPIF as well? Or are is the information used to configure the arbitrator and IPIF somewhere else? Say for instance the fpga is to be configured with a jpeg encoder. Would the configuration memory accessed by the ICAP be solely occupied by the jpeg encoder configuration, or by the ipif etc as well? If in the latter case, then ICAP should never modify areas defining the IPIF, is this correct? I would appreciate too if someone who has done this before can provide some guidelines on how I can set the system up to use the ICAP. Thanks in advance!:) Ju HwaArticle: 61953
Well, I FINALLY finished my PhD. For those who are exceedingly bored, my dissrtation is online (The SFRA: A Fixed-Frequency FPGA Architecture) at http://www.cs.berkeley.edu/~nweaver/nweaver_thesis.pdf -- Nicholas C. Weaver nweaver@cs.berkeley.eduArticle: 61954
You could either use 3 copies of a long LFSR with unique
seeds that are placed sufficiently far apart to produce
uncorrelated sequences *within the observation period*, or
you could use LFSRs with 3 different relatively prime
lengths. There is a very limited set of polynomials that
will produce an LFSR of a given length, and the resulting
sequence is usually a permutation of the same sequence, so
it does not provide much randomness.
PO Laprise wrote:
> How about using one LFSR per die pip? Using the SRL16s in
> Xilinx chips (don't know A, sorry), that would mean
> somewhere around 9 slices (for 3x6 pips), plus overhead,
> decoding logic, etc..., if I'm not mistaken? Incidentally,
> would using different polynomials effectively (as far as
> the human is concerned) decorrelate the LFSRs? Or would
> varying lengths (16, 32, etc...) do the trick? Or even,
> would different seeds be enough? I've never gotten around
> to studying the math, and never been great with statistics
> anyway...
>
> Pierre-Olivier
>
> -- to contact me directly, remove the obvious from my
> email --
--
--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: 61955
Well, not really an adder. It is an XOR or XNOR combination of the terms in the
polynomial. In either case, grabbing adjacent bits will give a random as long
as you let N clocks go by between successive samples (N is the number of bits
taken from the LFSR). Note that this is the same as taking one bit at a time
and filling a shift register. The restriction is that you get one new bit for
each time you clock the LFSR, the remaining bits are shifted copies of the first
bit. If you take more bits out per sample than you have clocks per sample, you
will get a correlation between successive samples.
Vinh Pham wrote:
> > An LFSR output is only "random" for a single bit out per clock. The
> > remaining bits are delayed copies of the first bit. In order to use an
>
> There are two forms of an LFSR. One where the bits are just delayed
> versions and you have a huge adder that feeds the chain (good ol' Google
> says this is called the Fibonacci form). And there's another one where
> there are adders inbetween the registers so that the bits are not delayed
> versions of each other (called the Galois form).
>
> Even in the case of the Fibonacci form, I have a feeling that grabbing a few
> adjacent bits will still produce a "random" number. Of course it depends on
> what you consider random, and I don't know much about the measurements they
> use for that.
>
> > it 3x per die. If you go further to reject 'illegal' combinations, then
> > you are skewing the probabilities of the legal combinations so that they
> > are no longer uniform.
>
> Rejecting illegal combinations should be okay. The legal combinations will
> remain uniform. Unfortunately I don't know a good way to explain this. But
> you can take a six sided dice, reject values of 5 and 6, and have it act
> like a uniform four sided dice.
>
> The only problem with the rejection method is you're not guaranteed a valid
> value every clock cycle, which is no big deal in this human operated push
> button application, but for some deterministic applications, you can't
> afford to wait for a "reroll" of the number.
>
> --Vinh
--
--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: 61956On Tue, 14 Oct 2003 17:56:31 +0100, "Jonathan Bromley" <jonathan.bromley@doulos.com> wrote: >"Amstel" <lange360@hotmail.com> wrote in message >news:56f7756d.0310140824.7d8fe744@posting.google.com... >> I'm trying to make an electronic dice (3 die). Basically the dice has >> 3 seven-segment displays and the 3 dice values will run randomly so >> that we would always get different values combinations. However I >> tried and was unable to write the program in VHDL . > >Do you have any idea how incredibly hard this is? > ><Mind-boggling detailed discussion snipped> Superb answer, Jonathan. I suspect that, even as you read this, someone is talking to their dean about transferring from electrical engineering to political science or animal husbandry. And should you need it, I can give you the name of an excellent removing-tongue-from-cheek surgeon. Take care, Bob Perlman Cambrian Design WorksArticle: 61957
> An LFSR output is only "random" for a single bit out per clock. The > remaining bits are delayed copies of the first bit. In order to use an > LFSR and really have a random stream of 3 bit numbers you'd need to clock > it 3x per die. If you go further to reject 'illegal' combinations, then > you are skewing the probabilities of the legal combinations so that they > are no longer uniform. I agree that you have to implement the full PRNG and not just use some bits of the LFSR, to get the full quality of the PRNG. However, rejecting illegal values is IMHO a "good" thing to do, meaning that it doesn't bias. After all, each and every output value of the PRNG is "unpredictable" (within the quality limits of the PRNG). Thus, rejecting all 0x6 and 0x7 doesn't reveal more information than that the final output won't ever be 0x6 or 0x7. Still, an attacker can't predict any output value, given that he couldn't predict them already before we added the reject circuit. It's a consequence of the lack of feedback into the PRNG. The PRNGs internal state is only changed through the intended means - by going from state n to n+1 (next value) etc. All cryptographic study that the PRNG design has received, inherently also applies to the combination of PRNG and rejection circuit. The only disadvantage of this method is that the execution time is not predictable. Although highly unprobable, the PRNG could output 0x6 / 0x7 for a lot of cycles in sequence. Thus you don't know how long it takes to get an acceptable (legal) output. In this particular application (dice) however, I don't think that it will be a problem of significance. MarcArticle: 61958
Tim wrote: > > rickman wrote: > > No, the requirement only dropped from 2.0 Amps to 1.5 Amps at the > > industrial temp range. This would require the power converter to be > > larger than the chip! This section of the board is our "low power" > > section and the power converter will supply a *total* of 250 mA at 2.5 > > volts. > > Did you see Austin Lesea's cunning trick of cycling the > chip until it warms up and starts on lower power? I am selling boards to OEM customers. Do you really think it will look good to recommend that they continue to cycle the FPGA until it warms up? That could easily take seconds when the board should be ready to come up in milliseconds. If the user is running on battery and needs to process for a few ms, this will drain the battery very quickly. Xilinx has a pattern of building problems into their chips which they claim is the inevitable price of progress and expecting the users to deal with them. In this case it turned out that it was not inevitable since they fixed the problem with later, more advanced families. Another issue that is being touted as "inevitable" is the increase in static Icc to becoming greater than the dynamic current. But I can assure you that this will be licked. Advances in transistor design are being made that will allow 65 nm chips to maintain an acceptable level of static Icc. If you don't believe me ask Intel about double and triple gates. Thanks for the warm up idea, but it is not workable in this situation. -- Rick "rickman" 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 URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 61959
I am not sure what your current requirements are since they greatly depend on the design you put in the FPGA. You also don't say if you want a linear or a switching regulator. But I can recommend the TI Swift line of switchers if that suits your needs. They have 3 Amp parts and 6 Amp parts. We are designing a module that uses the 3 Amp part and will provide up to 3 Amps in a 0.3 sq in foot print. The module may not be able to supply 3 Amps continuously due to heat issues. With such a small module we don't have the copper the data sheet recommends for cooling. We will be testing this next month to see what the limits are over 0C to 70C and -40C to 85C. If you are interested in a module this small I can keep you informed on our results. Bram van de Kerkhof wrote: > > Hi, > > Im looking for a regulator for the 1.5 and 1.2 Volt. > > I have a insight board as reference which has 2 times a 1.5 amps regulators > for the 1.5 V. > > I would like to have one regulator on my own design. > > I'm going to use the following components: xc2v1000 and xc3s400 later. > > Yours Bram -- Rick "rickman" 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 URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 61960
Steve Lass wrote: > > ram wrote: > > >Hi all, > > I am interested in doing partial reconfiguration using Xilinx Virtex > >2 pro, i am having a HW AFX xilinx prototype baord. > >I tried the small bit manipulation method defined in Xilinx > >application note > >xapp290, with the simple example , Example 1 simple system desing from > >xilinx EDK examples web page. > >Ok , my desing is this, > > I am using PPC405, and uartlite and gpio with uart continiously > >writing some data in Hyper terminal and gpio is connected to four leds > >and writing '1' to it > >I tried to change the routing for the LEDs , I do have to mention > >here, my board has 8 user LEDS, i changed the routing from upper half > >to lower half and generated the partial bit stream. > > > The configuration frames are columns, so if the routing you are changing > is in the same column > as the PPC, UART, or any of their routing, they will probably stop. I am looking at using this feature, although not while the chip is running. One problem I foresee is that with a column alignment, a module might be very hard to route if it is restricted to just a small number of columns. In my application there are 5 modules with one being constant and four being changed according to the hardware that is connected. Some of the planned modules are much larger than others, so I don't see them mapping to a fixed footprint. Some may be as narrow as two or even one column in an XC3S400. So I have been thinking about partitioning the designs differently. Instead of mapping modules to columns, I would divide the columns in half and map the designs to half columns. This won't be an issue as long as none of the logic (or interconnect) in the column is being used by running circuitry. But it will require that the bit files be assembled from partial bit files. Each column will need to be made of two halves glued together. As long as there is no routing between them, this should be a simple matter of concatenating two separate streams for each column. Anyone know if this might be practical? -- Rick "rickman" 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 URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 61961
"Nicholas C. Weaver" wrote: > > Well, I FINALLY finished my PhD. > > For those who are exceedingly bored, my dissrtation is online (The > SFRA: A Fixed-Frequency FPGA Architecture) at > http://www.cs.berkeley.edu/~nweaver/nweaver_thesis.pdf Congrats... I am sure it was a lot of work. :) Since you are in that lofty group and must have a much better view than the rest of us, are you aware of much research in FPGAs about partial/modular configuration? Just curious. -- Rick "rickman" 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 URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 61962
Rick, Hey, we admit the high POS current in Virtex, Virtex E, Spartan II, and Sparatan IIE, and we are proud that we got rid of it in subsequent families. It is not "inevitable." If you want to have a 200 MHz Fmax part instead of a 500 MHz Fmax part, we can make the leakage much, much lower. No one seems to want a slower part, even though it may costs a whole lot less. As for transistor design techniques that reduce leakage, no one has found one that works yet. Hi_K gate oxide does not reduce d-s leakage, SOI does not reduce d-s leakage, so about the only thing to do is to raise the Vt (relative to the Vcc), which makes things slower. Anyone can do that. Austin rickman wrote: > Tim wrote: > > > > rickman wrote: > > > No, the requirement only dropped from 2.0 Amps to 1.5 Amps at the > > > industrial temp range. This would require the power converter to be > > > larger than the chip! This section of the board is our "low power" > > > section and the power converter will supply a *total* of 250 mA at 2.5 > > > volts. > > > > Did you see Austin Lesea's cunning trick of cycling the > > chip until it warms up and starts on lower power? > > I am selling boards to OEM customers. Do you really think it will look > good to recommend that they continue to cycle the FPGA until it warms > up? That could easily take seconds when the board should be ready to > come up in milliseconds. If the user is running on battery and needs to > process for a few ms, this will drain the battery very quickly. > > Xilinx has a pattern of building problems into their chips which they > claim is the inevitable price of progress and expecting the users to > deal with them. In this case it turned out that it was not inevitable > since they fixed the problem with later, more advanced families. > > Another issue that is being touted as "inevitable" is the increase in > static Icc to becoming greater than the dynamic current. But I can > assure you that this will be licked. Advances in transistor design are > being made that will allow 65 nm chips to maintain an acceptable level > of static Icc. If you don't believe me ask Intel about double and > triple gates. > > Thanks for the warm up idea, but it is not workable in this situation. > > -- > > Rick "rickman" 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 URL http://www.arius.com > 4 King Ave 301-682-7772 Voice > Frederick, MD 21701-3110 301-682-7666 FAXArticle: 61963
"Antti Lukats" <antti@case2000.com> wrote in message news:80a3aea5.0310150300.79f98bbd@posting.google.com... > "SneakerNet" <nospam@nospam.org> wrote in message news:<Qf%ib.178724$JA5.4476502@news.xtra.co.nz>... > > Hi All > > > > Has anyone got this going fully (using the VB code from the site)? I'm still > > stuck *wawawa* > > Pls reply to this post.. > > how far did you get? > is the USB device enumerated? > > I only did verify that the synthesis is ok 'out of box' so I assume the > the VB project should also be OK, but I had no reasons to check the > project in more detail. > > antti Hi Antti 1. Japanese Version USB * VHDL code => I agree with you on this. I adapted the code from his site for Altera Cyclone chip and did the pin assignments, assigned some of the outputs to leds (where would we be without LEDs) and uploaded the program. The code was doing something. This was futher verified when I plugged the usb cable in the pc and the light pattern changed for about a sec. it was like pc was trying to communicate and tell pc what driver to use, but because no drivers are loaded, the original led sequence resumed (meaning still waiting for a valid connection). * VB Code => First I thought that this would be a straight process, however when running the vb program it doesn't seem to be doing anything as the vb program keeps reporting that no device found. So what i did was i went back to the site and asked one of our team members to translate the whole japanese stuff (http://member.nifty.ne.jp/fpga/freeip/usb/) into english. When this was done, i read the stuff atleast 10 times. one of the paras after traslation is as follows (PS: If you want a copy of full translation, just reply back to this post. I'll post it - it's a professional translation as we have a translations manager in our company): "In order to test its operation, I simply changed to a Morphy Planning USB-I0 on the hardware. I have not completed the application software yet. It is a VB extra, but the functionality is inadequate. When I have more time, I will work more on this." This got me thinking.. So I did a search on Morphy Planning USB-IO and i came across this site (http://csx.jp/~fex/usbio/index-en.html and http://www.morphyplanning.co.jp/). I went back to the original page of the usb (http://member.nifty.ne.jp/fpga/freeip/usb/) and if you look carefully at the pic on that site you will notice that the person is using a micro (right hand side half way thr the board). So it looks like the person has used some extra hardware to connect the pc to fpga. This is verified by the fact that if you go to this site (http://csx.jp/~fex/usbio/spec-en.html) and if you open the vb program, you will see ditto commands being used, so dat's verfied. So the bottom line is that extra hardware is still required to write to usb and the fact i can't seem to find out what chip is being used on micr planning usb-io site as i can't find any schematic, etc.. So i'm stuck. 2. Opencores v1.1 usb_phy and PDIUSBP11A transcever chip. As i'm stuck with the japanese version, I started building the circuit for this version. So lets see how this goes. I'm sure this will work though once again how do I acess the usb through windows. I'll need help again. I hope I have been able to explain what I have investigated. So what do you say Antti? Pls Advice Regards ;o)Article: 61964
In article <3F8DA93C.C2C16FF3@yahoo.com>, rickman <spamgoeshere4@yahoo.com> wrote: >Since you are in that lofty group and must have a much better view than >the rest of us, are you aware of much research in FPGAs about >partial/modular configuration? Quick coredump from memory. There was a lot of stuff on the old 6200 a few years back, because it was relatively friendly for it. Satnam had some stuff, among others. Also there was the many-years-back time-multiplexed 4K Xilinx research project, which virtualized circuits with fine-grained multiplexing (project never went anywhere because of the power consumption of context switching every cycle). There's some on programming model to allow virtualization (eg, SCORE here at berkeley), these target abstract FPGAs, not current silicon. There's a lot of interest today internally in Xilinx and elsewhere on the possibility, but not sure HOW much research is going on, and in many ways limited by both the silicon (can only reconfigure column-at-a-time, a feature largely for testing not user design) and the tools (how do you swap out bits? Represent the swapping? Etc?). I think if there is some conceptual breakthrough on how to treat the silicon, the other stuff will probably fall into place, as the detailed routing (eg, insuring modules don't interfear etc) could be faked up with Jbits (do a ripup and reroute, and run things 10% slower to give a margin for simplicity), and "make this change and now these things run a lot faster" on the silicon could happen in later egnerations. But I think its largely awaiting the conceptual breakthrough. How do you treat this blob which is different things at different points in time? -- Nicholas C. Weaver nweaver@cs.berkeley.eduArticle: 61965
hello,someone in this group did use it?i have the machine but no probes,is it possible to diy?thanksArticle: 61966
jsabater@dimat.es (Joe Sabater) wrote in message news:<b80681f7.0310130832.78646141@posting.google.com>... > Hi, > > I have been debugging a software application running in an Altera APEX > device with Nios 32 (including OCI-Core) via JTAG with no problem at > all. Now, I am trying to do the same with an ACEX (EP1K100FC256-2) > with no success. The problem seems to be when the debugger tries to > connect to the remote target via JTAG. After issuing a "nios-debug" > command under SOPC Builder shell I get the following error: "mdi > error: found 0 devices instead of 1". > > It seems as the "nios-debug" script supplied by Altera doesn't > recognize ACEX devices, but not quite sure about. > > Any idea? What is more, any of you have ever debugged software via > JTAG with an ACEX? > > Thank you very much in advance. > > Joe Hi Joe, Using an ACEX device is the cause of this issue. The OCI debug core (via JTAG) relies on some enhanced connectivity to JTAG implemented with APEX (and subsequent) FPGA families. The same limitation applies for use of the SignalTap on-chip logic analyzer (in fact, the SignalTap app note lists which device families can be used). Going back to the Nios kit, this means that the older device families that Nios supports (ACEX 1K & FLEX 10KE) will not support the OCI core via JTAG. Because of your report I put in a request that we provide a more explicit warning (or error) message in SOPC Builder if you try to activate OCI and are targeting FLEX or ACEX (in addition to updating relevant documentation). As it is now, I noticed that there are a number of warning messages in Quartus that say that the OCI logic is being synthesized away because of this device limitation -- so this is really the only warning of this limitation. In Nios versions prior to 3.0, we had a different debug solution that operated over serial port rather than JTAG. While I don't recommend going backwards in terms of Nios CPU version, if its absolutely essential that you use the GDB debugger with your ACEX device, you might consider (temporarily) going back to Nios v2.2 to use the non-JTAG debugging... this method operates over UART, and therefore does not require the special JTAG enhancements which came out after ACEX. If its possible to debug with your APEX device and then move to a final test of your ACEX-based product with OCI turned off, this would be the easiest solution. Jesse Kempa Altera Corp. jkempa at altera dot comArticle: 61967
Austin Lesea wrote: > > Rick, > > Hey, we admit the high POS current in Virtex, Virtex E, Spartan II, and > Sparatan IIE, and we are proud that we got rid of it in subsequent families. > It is not "inevitable." > > If you want to have a 200 MHz Fmax part instead of a 500 MHz Fmax part, we can > make the leakage much, much lower. No one seems to want a slower part, even > though it may costs a whole lot less. Wow - Who have you asked ? In the CPLD sector, the 'bragging rights slugfests' are over uA standby, not MHz. ( see lattice web site - I did note they pitch uA only, and avoid uA/MHz, so perhaps they come (close) second on that one :) > > As for transistor design techniques that reduce leakage, no one has found one > that works yet. A sweeping, and thus rather brave, statement ? I assume Xilinx is already using mixed threshold design, at least ? > > Hi_K gate oxide does not reduce d-s leakage, SOI does not reduce d-s leakage, > so about the only thing to do is to raise the Vt (relative to the Vcc), which > makes things slower. Anyone can do that. Look at the latest Transmeta processor. Extremely MHz focused company, but they can get to 2mW I think ? Press release mentions something about licensing the IP... -jgArticle: 61968
Ray Andraka wrote: > > > Why seven segment LEDs though? It would be more appropriate to use 7 LEDs arranged > like the 'six' and 'one' sides of the die superimposed. Correct - and the design also does not have to have Mod 6 counting -> Decoder; it is possible to count directly in either 7 segment Font patterns, or in Ray's Dice-Font pattern. I have actually done a design that counts directly in 7 segment Font patterns (0..9) - the student can explain why that might be a good idea. -jgArticle: 61969
etrac wrote: > > Hi, > We have found the problem and this might interest somebody here so I > explain the reasons of the voltage falling : It was simply because we > put too many bypassing capacitors around the FPGA ! The virtex II > datasheet is asking for many capacitors to have good linearity in the > fpga voltages, but our power supply was not enough strong to support > the current when we power on the board. > > Etrac. > > > etrac wrote: > > > > > > > We want to power on a Virtex II xc2v3000 FPGA (Xilinx). The core power > > > > seems to work correctly (VccInt = 1.5V ; I<100mA), but VccAux and VccO > > > > are asking too much current (> 1.5A) for a long time. This occurs > > > > approximatively 1 second after the power is on. > > > > We have a current limitation power supply, so the VccAux/VccO voltage > > > > fall at nearly 1.5V, that is to say that the FPGA needs very much than > > > > 1.5A .. This does not quite 'gel' - you are saying lowering the Total C alone solved the issue ? That suggests a dV/dT limit, but times in the order of 1 second ? It may be a power-sequencing effect, which total C would affect. -jgArticle: 61970
My final answer (until someone asks an interesting
variation on the question...)
OP asked about VHDL implementation, John_H and I gave
graphs, so the code below is illustration of how to
build the graphs in VHDL, for both the other John's
tree (simple tree), and mine (modified tree), for 30 bits.
Some observations on synthesis results using XST:
LUT utilization (from map report)...
Simple - 44 LUTs
Modified - 43 LUTs
This is a trivial difference. Because the code for the simple
tree is, well, simpler, it is preferred. Smart folk should be
able to genericize it so that the tree structure is built
automatically for arbitrary input size, by a synthesis tool
that accepts unconstrained bus inputs and outputs. (Does XST
do this yet?)
Timing (from par report smallest Spartan3)...
Pad to Pad delay...
Simple - 17+ ns
Modified - 17+ ns
Clock period (with the FFs at the end commented back in,
so as to take the pad delay out of the equation)...
Simple - 10+ ns ( 6 levels )
Modified - 10+ ns ( 6 levels )
No pin assignment or other attempts to map logic used.
Timing can be pushed around a little by playing with
map/par options, but not necessarily the way you'd expect
(who called it 'pushing the rope'? Great metaphor!)
The keep attribute, trying to force the tool, may
backfire.
So there it is. I like this one, because it is such a
neat example of how even the simplest of operations
( Counting ones!!?!?! ) may not be so simple. You need
to be aware of what the compiler actually does with a
behavioural model, and how to push it, and how not to
push it.
Regards,
John
p.s. thanks to Dan C., local X-FAE, for helping me
get this thing through XST. Like the OP, I'm not a big
VHDL guy either (just don't like the wordiness/aesthetics
of it), I am liking Handel-C more and more.
p.p.s the code (un-simulated, you get what you pay for):
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;
entity TestAddBits_Top is
generic (UseFA3 : boolean := FALSE );
Port ( Clock: in std_logic;
InBits : in std_logic_vector(29 downto 0);
SumOut : out std_logic_vector(4 downto 0));
end TestAddBits_Top;
architecture VirtexII of TestAddBits_Top is
subtype TwoBit is std_logic_vector(1 downto 0);
subtype ThreeBit is std_logic_vector(2 downto 0);
subtype FourBit is std_logic_vector(3 downto 0);
type Leaf is array (0 to 8) of TwoBit;
type Level1 is array (0 to 3) of ThreeBit;
type Level2 is array (0 to 1) of FourBit;
type Level1A is array (0 to 5) of TwoBit;
signal LeafSum: Leaf ;
signal L1Sum: Level1;
signal L2Sum: Level2;
signal L1SumA: Level1A;
signal FA3: std_logic_vector(1 downto 0);
signal SumBits: std_logic_vector(4 downto 0);
signal Bits: std_logic_vector(29 downto 0);
--attribute keep : string;
--attribute keep of LeafSum: signal is "true";
--attribute keep of L1Sum: signal is "true";
--attribute keep of L2Sum: signal is "true";
begin
-- Simple adder tree to count 30 bits. Uses 44 LUTs
T1: if ( UseFA3 = FALSE ) generate
addleaf: for I in 0 to 7 generate -- Add 8 leafs
LeafSum(I) <= ('0' & Bits(3*I) )
+ ('0' & Bits(3*I+1))
+ ('0' & Bits(3*I+2));
end generate;
addlevel1: for J in 0 to 3 generate -- Add Level1
L1Sum(J) <= ( '0' & LeafSum(2*J) )
+ ( '0' & LeafSum(2*J+1))
+ ("00" & Bits(24+J) );
end generate;
addlevel2:for K in 0 to 1 generate -- Add Level2
L2Sum(K) <= ( '0' & L1Sum(2*K) )
+ ( '0' & L1Sum(2*K+1) )
+ ("000" & Bits(28+K) );
end generate;
SumBits <= ('0' & L2Sum(0)) -- Final Answer
+ ('0' & L2Sum(1));
end generate;
-- Modified adder tree to count 30 bits. Uses 43 LUTs,
-- 1 less LUT than simple adder tree
T2: if ( UseFA3 = TRUE ) generate -- Use FA3 = True
addleafsA: for I in 0 to 8 generate -- Add 9 leafs
LeafSum(I) <= ('0' & Bits(3*I) )
+ ('0' & Bits(3*I+1))
+ ('0' & Bits(3*I+2));
end generate;
addlevel1A: for J in 0 to 2 generate -- Add Level1A
inner: for K in 0 to 1 generate
L1SumA(2*J+K) <= ( '0' & LeafSum(3*J)(K) )
+ ( '0' & LeafSum(3*J+1)(K) )
+ ( '0' & LeafSum(3*J+2)(K) );
end generate;
end generate;
FA3 <= ( '0' & L1SumA(0)(1) ) -- Add weight 1 bits
+ ( '0' & L1SumA(2)(1) )
+ ( '0' & L1SumA(4)(1) );
L2Sum(0) <= ( "00" & Bits(27) ) -- Add Level2
+ ( '0' & L1SumA(1) & L1SumA(0)(0) )
+ ( '0' & L1SumA(3) & L1SumA(2)(0) );
L2Sum(1) <= ( '0' & L1SumA(5) & L1SumA(4)(0) )
+ ( '0' & FA3 & Bits(28) );
SumBits <= ( '0' & L2Sum(0)) -- Final Answer
+ ( '0' & L2Sum(1))
+ ( "0000" & Bits(29));
end generate;
process ( Clock ) begin
if RISING_EDGE( Clock ) then
Bits <= InBits;
SumOut <= SumBits;
end if;
end process;
end VirtexII;
"John_H" <johnhandwork@mail.com> wrote in message news:<whGhb.24$jU3.10392@news-west.eli.net>...
> Peter's: solution for 48 bits:
> 2 BlockRAMs, 16 LUTs
> BlockRAM tcko + 2 levels carry chain
> John's solution for 30 bits:
> Resources: 46 LUTs (giving him 1 LUT per CYAdd bit)
> Delay: 2 levels LUTs + 3 levels carry chain
> John_H's solution for 31 bits (mine, at end):
> Resources: 41 LUTs
> Delay: 3 levels LUTs + 2 levels carry chain
>
Article: 61971rickman wrote: > > Jim Granville wrote: > > > > rickman wrote: > > > There are two devices you might be interested in. One is an MCU with > > > programmable digital and analog blocks made by Cypress Semi. This is > > > not really an FPGA since they don't make it easy for you to design your > > > own digital functions. They used to, but they seem to have gone to a > > > canned module approach where you have lots of standard functions to > > > choose from. > > > > Did you see info that documented this ? - all I ever saw was 'marketing > > arm waving' > > and I was looking for better detail, on just what was SFR based, and > > what was programmable logic in the true sense. > > I don't understand. What are you looking for documentation on; the > chips being ready or being programmable? Originally, when they first > came out, you could program the digital and analog blocks yourself. But > I think the rules were very complex and people objected to the limited > amount of logic and capability for a single block. I looked a few times for any under-the-bonnet stuff, as to just how programmable these blocks _really_ are. A few muxes does not quite rank as programmable, merely configurable, and all uC have configurable peripherals.... Did you ever see the complex rules - or the tools themselves ? Comments from someone who has seen this, and is FPGA tool/flow literate (like yourself) would be interesting. > So they went to a > marketing approach where they predesign function blocks and you pick the > ones you need. Makes sense, of course. In doing do they morph more to an IP company, and their PSoC morphs to a CSoC... > BTW, I don't know what SFR means. Special Function Register == Standard Peripheral access/configure scheme in microcontrollers. -jgArticle: 61972
Jim, The easy ways are all taken. To use more than one oxide or more than one threshold vt is just using last years technology where you can squeeze it in. There are no new physical transistors that have been made that look like anything other than PhD projects.... I don't speak CPLDs, so uA is something I have no understanding of..... as for the "Ef-fishy-on" they are using a back well bias technique (already patented by us and also separately by IBM, among others) that makes things slower where one can get away with it (under programmable cell controls). If you use a standard CMOS process, you are only able to bias up the nmos, or the pmos wells, (not both), so unless you have a triple well process you can't really push this technique as far as one would like. Making the FPGA slower where you can get away with it is a far more difficult task than a uP. I can just see the software tool error message now: "unknown constraint - can not apply 'slow' attribute to this block" Not brave, but not stupid either, Austin Jim Granville wrote: > Austin Lesea wrote: > > > > Rick, > > > > Hey, we admit the high POS current in Virtex, Virtex E, Spartan II, and > > Sparatan IIE, and we are proud that we got rid of it in subsequent families. > > It is not "inevitable." > > > > If you want to have a 200 MHz Fmax part instead of a 500 MHz Fmax part, we can > > make the leakage much, much lower. No one seems to want a slower part, even > > though it may costs a whole lot less. > > Wow - Who have you asked ? > > In the CPLD sector, the 'bragging rights slugfests' are over uA > standby, > not MHz. ( see lattice web site - I did note they pitch uA only, > and avoid uA/MHz, so perhaps they come (close) second on that one :) > > > > > As for transistor design techniques that reduce leakage, no one has found one > > that works yet. > > A sweeping, and thus rather brave, statement ? > > I assume Xilinx is already using mixed threshold design, at least ? > > > > > Hi_K gate oxide does not reduce d-s leakage, SOI does not reduce d-s leakage, > > so about the only thing to do is to raise the Vt (relative to the Vcc), which > > makes things slower. Anyone can do that. > > Look at the latest Transmeta processor. Extremely MHz focused company, > but > they can get to 2mW I think ? > Press release mentions something about licensing the IP... > > -jgArticle: 61973
I expected to see this entitled: "XAPP 998" or something similar... Peter Alfke <peter@xilinx.com> wrote in message news:<3F8D76F9.416635DF@xilinx.com>... > If your homework is too tough, > and the time just flies away, > thinking hard is not enough, > click: comp.arch.fpga. ...Article: 61974
Jim Granville wrote: > > rickman wrote: > > > > Jim Granville wrote: > > > > > > rickman wrote: > > > > There are two devices you might be interested in. One is an MCU with > > > > programmable digital and analog blocks made by Cypress Semi. This is > > > > not really an FPGA since they don't make it easy for you to design your > > > > own digital functions. They used to, but they seem to have gone to a > > > > canned module approach where you have lots of standard functions to > > > > choose from. > > > > > > Did you see info that documented this ? - all I ever saw was 'marketing > > > arm waving' > > > and I was looking for better detail, on just what was SFR based, and > > > what was programmable logic in the true sense. > > > > I don't understand. What are you looking for documentation on; the > > chips being ready or being programmable? Originally, when they first > > came out, you could program the digital and analog blocks yourself. But > > I think the rules were very complex and people objected to the limited > > amount of logic and capability for a single block. > > I looked a few times for any under-the-bonnet stuff, as to just > how programmable these blocks _really_ are. A few muxes does > not quite rank as programmable, merely configurable, and all uC > have configurable peripherals.... > > Did you ever see the complex rules - or the tools themselves ? > > Comments from someone who has seen this, and is > FPGA tool/flow literate (like yourself) would be interesting. I have seen some info on this. But it seems they have removed this from the web site and have changed to a prepackaged module design approach. They provide a menu of what is available and you pick what you will download to the programmable blocks. They are not just using a "few muxes". The digital blocks contain various elements that they configure. For example, digital blocks can be a serial shift register that can be used as a (rather crude) UART. Combine analog blocks and you can get a SAR ADC. The list of functions that can be programmed are listed on their web site. Here is a definition of one field in a register that configures a digital block. Bit [2:0]: Function [2:0] The Function [2:0] bits select the block function which determines the basic hardware configuration 0 0 0 = Timer (chainable) 0 0 1 = Counter (chainable) 0 1 0 = CRC/ PRS (Cyclical Redundancy Checker or Psuedo Random Sequencer) (chainable) 0 1 1 = Reserved 1 0 0 = Deadband for Pulse Width Modulator 1 0 1 = UART (function only available on DCA type blocs) 1 1 0 = SPI (function only available on DCA type blocs) 1 1 0 = Reserved 1 1 1 = Reserved Clearly this is not a LUT type FPGA. But it is a programmable block, even if it is only programmable by them. This was taken from a 2000 data sheet I have. > > So they went to a > > marketing approach where they predesign function blocks and you pick the > > ones you need. > > Makes sense, of course. In doing do they morph more to an IP company, > and > their PSoC morphs to a CSoC... Yes, but I don't think they did it because they wanted to be an "IP" company. I think they realized that programming the blocks was not very simple and would never be supported by the type of tools that FPGAs and CPLDs are. The laundry list is just a more practical way of getting this to work. If you are a company wanting to buy millions, I am sure they will design any block you would like to see that can be supported. After all, they have already come up the learning curve. > > BTW, I don't know what SFR means. > > Special Function Register == Standard Peripheral access/configure > scheme in microcontrollers. -- Rick "rickman" 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 URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAX
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