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
rickman wrote: > I am not clear as to what you are saying. Do you mean that the signal > from an F/G LUT will go to the F5 mux as well as to some other > destination? I don't think this is correct. The architecture I assumed > did not use the same structure when using the 4 input mux. The output of > the 4 input mux is from the F5 mux and the F/G LUTs do not leave the CLB > rather they go directly to the F5 mux and only to the F5 mux. If you do the 2x2 merged tree, then the F/G outputs each go to two places. One would the F5, the other is to a 2 input mux somewhere else. If you are not taking those outputs, then you are building with a basic block of a 4 input mux, in which case you need one 4 input mux (one slice) for each bit in the output. As you observed yesterday, this quickly becomes inefficient as the width increases. > > > Actually, that might be a third way to do this. Can you use the F5 mux > in a Virtex or Spartan II and still access the outputs from the F LUT > and G LUT? If so, then using the F5 mux as a 2 input mux in the original > 2 input mux tree arrangement will reduce the number of CLBs by 1/3 in > addition to helping somewhat with the routing. You can get one of them out easily, but not both. Techically, you cna get the second out the XB or YB output by using the carry chain, but that requires the CLB below to drive a '1' into the carry in, which means you're not getting the density anyway > > > I did not consider the 4K series since there is not much point in using > them in a new design. I expect they will be very pricey compared to what > Xilinx is selling this time next year; Spartan III perhaps? True enough, although consider the original spartan is also a 4K architecture. Still, Xilinx calls the 4K structure obsolete. (In many ways it is more flexible, and is certainly denser than Virtex but it is also less forgiving of sloppy design)Article: 24201
> I am no expert when it comes to Virtex but you seem to have interpreted the > data sheet differently to me. You can learn a lot about how things work and/or what it possible by playing with the FPGA Editor. I usually keep a toy design around for this purpose. If you can see a way to wire up what you want, there is probably a way to get the tools to make it happen. If you can't figure out how to wire up what you want it probably isn't possible. -- These are my opinions, not necessarily my employers. I hate spam.Article: 24202
rickman wrote: > At the time I had the problem, they were insistent that they had to do > it this way to "protect" their interests. They just couldn't "get it" > that this is such a major PITA that it actually prevented us from buying > more of the full up board stations. I never did "get it" why they couldn't > figure out a way to allow FPGA designs developed on *any* station to be used > and reworked on *any* station licened for FPGA development. They seemed to > think that the one way nature of transfering designs was an acceptable > limitation. I had long conversations with them about this. It doesn't seem technically hard to solve but they were just totally insistent on the way they were doing things. At day job, this cost me a lot of money, since it essentially made existing one-product licenses useless; I had to upgrade them to full licenses even though the engineers using them only used the capabilities of the one-product license. It seemed to me to be totally ridiculous that two designers working on the same chip sitting right next to each other couldn't share files. Of course, every time I upgrade the software it's a game of Russian roullette - I know something that did work before will now be broken. As a policy, I never upgrade any of the software unless I absolutely have to. Recently, something crashed and the viewlogic system became unusable (7.3x). So I loaded a slightly more modern version (7.5x I believe) and it all works great except that it won't simulate anything. GROAN!!!!!!!!!! ---------------------------------------------------------------------- rk stellar engineering, ltd. Once again, we were lucky - but luck stellare@erols.com.NOSPAM has no business in spaceflight. Hi-Rel Digital Systems Design -- Gene KranzArticle: 24203
look at http://www.rdrop.com/~cary/html/vlsi.html On Thu, 1 Jun 2000 00:08:41 +0200, "Domagoj" <domagoj@engineer.com> wrote: >Hi, > Does anybody have any data about cost/performance as a function >of performance (MIPS) for microprocessors in FPGA ? > >Any information about processors in fpga would be highly appreciated. > >thanks, >------------------------------------------- >- Domagoj - >- Domagoj@engineer.com - >------------------------------------------- >Article: 24204
Hi all, On my new embedded design, I have a Spartan-II XC2S200 and a Virtex-E XCV1600E. As this is an embedded product, I need some linear regulators, one for 3.3V, one for 2.5V and one for 1.8V. Now my question is about my 2.5V and 1.8V DC linear regulators and about current I need. On the 2.5V I have VCCINT of Spartan-II XC2S200 and VCCO of Virtex-E XCV1600E (1.5A or 3A). On the 1.8V I have VCCINT of of Virtex-E XCV1600E (1.5A or 3A). Now for both regulators, can I use a 1.5A DC linear regulator, or I need to use a 3A DC linear regulator ( This question, because if I can use a 1.5A DC linear regulator I will save many places on my board). Or maybe I need a 3A for the 2.5V (VCCINT of Spartan-II XC2S200 and VCCO of Virtex-E XCV1600E), and a1.5A for the 1.8V (VCCINT of of Virtex-E XCV1600E). In limit case, what is the current max for the VCCINT of Spartan-II XC2S200? In limit case, what is the current max for the VCCO of Spartan-II XC2S200? In limit case, what is the current max for the VCCINT of Virtex-E XCV1600E. In limit case, what is the current max for the VCCO of Virtex-E XCV1600E. Thank you to let me know you experience! Have a nice week-end. LaurentArticle: 24205
Ray Andraka wrote: > > rickman wrote: > > > I am not clear as to what you are saying. Do you mean that the signal > > from an F/G LUT will go to the F5 mux as well as to some other > > destination? I don't think this is correct. The architecture I assumed > > did not use the same structure when using the 4 input mux. The output of > > the 4 input mux is from the F5 mux and the F/G LUTs do not leave the CLB > > rather they go directly to the F5 mux and only to the F5 mux. > > If you do the 2x2 merged tree, then the F/G outputs each go to two places. One would the F5, the > other is to a 2 input mux somewhere else. If you are not taking those outputs, then you are building > with a basic block of a 4 input mux, in which case you need one 4 input mux (one slice) for each bit > in the output. As you observed yesterday, this quickly becomes inefficient as the width increases. Yes, the numbers I posted were for using 4 input muxes in a merged tree without tapping into any intermediate signals within the mux. This uses the same number of CLBs and uses *less* routing. So it does *not* get inefficient as the width increases. Of course it is not useful for a barrel shifter of width 2. But at all other widths, the 4 input mux is a better solution. > > I did not consider the 4K series since there is not much point in using > > them in a new design. I expect they will be very pricey compared to what > > Xilinx is selling this time next year; Spartan III perhaps? > > True enough, although consider the original spartan is also a 4K architecture. Still, Xilinx calls > the 4K structure obsolete. (In many ways it is more flexible, and is certainly denser than Virtex but > it is also less forgiving of sloppy design) What is more flexible about the 4K series. You once posted that the carry chain is more flexible in the 4K than in the Virtex. Are there any other features that are better in the 4K series? -- 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: 24206
Maybe I am just a contrarian, but I saw the licensing working the other way. I would *only* buy the FPGA workstations since I needed to be able to support the FPGA stations. Using a board station would make the design incompatible with the rest of the world of FPGA stations. Does anyone know if Viewlogic has fixed this problem? I guess I could ask Viewlogic. rk wrote: > > rickman wrote: > > > At the time I had the problem, they were insistent that they had to do > > it this way to "protect" their interests. They just couldn't "get it" > > that this is such a major PITA that it actually prevented us from buying > > more of the full up board stations. I never did "get it" why they couldn't > > figure out a way to allow FPGA designs developed on *any* station to be used > > and reworked on *any* station licened for FPGA development. They seemed to > > think that the one way nature of transfering designs was an acceptable > > limitation. > > I had long conversations with them about this. It doesn't seem technically > hard to solve but they were just totally insistent on the way they were doing > things. At day job, this cost me a lot of money, since it essentially made > existing one-product licenses useless; I had to upgrade them to full licenses > even though the engineers using them only used the capabilities of the > one-product license. It seemed to me to be totally ridiculous that two > designers working on the same chip sitting right next to each other couldn't > share files. > > Of course, every time I upgrade the software it's a game of Russian roullette > - I know something that did work before will now be broken. As a policy, I > never upgrade any of the software unless I absolutely have to. Recently, > something crashed and the viewlogic system became unusable (7.3x). So I > loaded a slightly more modern version (7.5x I believe) and it all works great > except that it won't simulate anything. GROAN!!!!!!!!!! > > ---------------------------------------------------------------------- > rk > stellar engineering, ltd. Once again, we were lucky - but luck > stellare@erols.com.NOSPAM has no business in spaceflight. > Hi-Rel Digital Systems Design -- Gene Kranz -- 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: 24207
Greetings - We have a few (new) parts left for QuickLogic programming. Please see http://www.jumboprawn.net/forsale/ql_100144.html and http://www.jumboprawn.net/forsale/ql_base.html and make offer if you like. thanks - - jesse@jumboprawn.net Sent via Deja.com http://www.deja.com/ Before you buy.Article: 24208
rickman wrote: > Ray Andraka wrote: > > > > rickman wrote: > > > > > I am not clear as to what you are saying. Do you mean that the signal > > > from an F/G LUT will go to the F5 mux as well as to some other > > > destination? I don't think this is correct. The architecture I assumed > > > did not use the same structure when using the 4 input mux. The output of > > > the 4 input mux is from the F5 mux and the F/G LUTs do not leave the CLB > > > rather they go directly to the F5 mux and only to the F5 mux. > > > > If you do the 2x2 merged tree, then the F/G outputs each go to two places. One would the F5, the > > other is to a 2 input mux somewhere else. If you are not taking those outputs, then you are building > > with a basic block of a 4 input mux, in which case you need one 4 input mux (one slice) for each bit > > in the output. As you observed yesterday, this quickly becomes inefficient as the width increases. > OK, if you are using 4 input MUXs as your primitive, then your tree is a 4x4 tree (fan-in of 4, fan-out of 4) for it to work right. That means your area is the same as the 2x2 tree, but the fan out on each layer is doubled (you have one 4 in mux for each bit, and each of those is connected to 4 muxes in the next layer). Discounting routing and loading this would be a bit faster for an unpipelined rotator. The routing can be a little more congested, although as I pointed out before, those signals are probably already occupying the channels anyway. Pipelined, the 2x2 tree will still be faster, but will have twice the clock latency. I can see now that this does use a smaller number of routes. > > Yes, the numbers I posted were for using 4 input muxes in a merged tree > without tapping into any intermediate signals within the mux. This uses > the same number of CLBs and uses *less* routing. So it does *not* get > inefficient as the width increases. Of course it is not useful for a > barrel shifter of width 2. But at all other widths, the 4 input mux is a > better solution. > > > > I did not consider the 4K series since there is not much point in using > > > them in a new design. I expect they will be very pricey compared to what > > > Xilinx is selling this time next year; Spartan III perhaps? > > > > True enough, although consider the original spartan is also a 4K architecture. Still, Xilinx calls > > the 4K structure obsolete. (In many ways it is more flexible, and is certainly denser than Virtex but > > it is also less forgiving of sloppy design) > > What is more flexible about the 4K series. You once posted that the > carry chain is more flexible in the 4K than in the Virtex. Are there any > other features that are better in the 4K series? The carry chain in 4K is indeed more flexible, and in fact can be used without using the LUTs, leaving the LUTs for other functionality( usually related). Additionally, the 4K gives you a LUT on the second layer of logic instead of a mux. That in turn increases the flexibility of a CLB, plus you can use that LUT somewhat independently of the 4LUTs. In virtex, you tie up both 4 LUTs if you use the F5, even if the LUT is programmed as a pass-thru. > > > -- > > 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: 24209
Laurent Gauch wrote: > <snip> > In limit case, what is the current max for the VCCINT of Spartan-II > XC2S200? > In limit case, what is the current max for the VCCO of Spartan-II > XC2S200? > > In limit case, what is the current max for the VCCINT of Virtex-E > XCV1600E. > In limit case, what is the current max for the VCCO of Virtex-E > XCV1600E. > There is no meaningful answer to this question. The supply currents are all the result of dynamically charging ( and discharging ) internal or external capacitances. So the current is proportional to frequency, and depends totally on your design type and size. The "limit case" would be an unrealistic amount of current if you implement a max size toggling shift register and clock it at 200+MHz. BTW, don't forget that the forward drop of an appropriately large silicon diode can generate 2.5 V from 3.3 V, or 1.8 V from 2.5 V, but it is of course up to you to figure out the worst-case scenario... Peter Alfke, Xilinx ApplicationsArticle: 24210
> Since we use both OrCAD and Viewlogic tools, I have to say that OrCAD's > entry tools are easier to use, and we are more productive when using > them. I am sorry to sound so cynical if you are really serious, but I just can't believe anyone would...COULD make that statement with a straight face, or at least without a lot of inebriation... OrCAD is undoubtedly the WORST schematic 'scribbling' program I have ever used. And the worst part is, they charge a LOT for it! If it was $99, I'd take it seriously. I'd rather use stone and chisel... It has the worst text handling capabilities I have ever seen. You can't like up the text unless you do it all ONE way, and bus handling is just so so bad. And...what's with "off page connectors"? What's the point? Try putting a net just on top of a bus that goes up...you can't! You have to do all sorts of little jaggies to go up, around and over... And the list goes on... I personally find ViewDraw to be one of the best, if not the best schematic drawing program out there...and I've used quite a few... What were your complaints with ViewDraw? Sorry, I know this isn't the OrCAD bashing group...Article: 24211
I am unclear on how you feel about Orcad, Austin. Do you like it or not? Stop beating around the bush and tell us! ;) Austin Franklin wrote: > > > Since we use both OrCAD and Viewlogic tools, I have to say that OrCAD's > > entry tools are easier to use, and we are more productive when using > > them. > > I am sorry to sound so cynical if you are really serious, but I just can't > believe anyone would...COULD make that statement with a straight face, or > at least without a lot of inebriation... OrCAD is undoubtedly the WORST > schematic 'scribbling' program I have ever used. And the worst part is, > they charge a LOT for it! If it was $99, I'd take it seriously. I'd > rather use stone and chisel... > > It has the worst text handling capabilities I have ever seen. You can't > like up the text unless you do it all ONE way, and bus handling is just so > so bad. And...what's with "off page connectors"? What's the point? Try > putting a net just on top of a bus that goes up...you can't! You have to > do all sorts of little jaggies to go up, around and over... And the list > goes on... > > I personally find ViewDraw to be one of the best, if not the best schematic > drawing program out there...and I've used quite a few... What were your > complaints with ViewDraw? > > Sorry, I know this isn't the OrCAD bashing group... I was the one complaining about how the Viewlogic licensing works, or at least used to work. I am asking if it *still* works that way and if they ever plan to fix it. The problem is that if I want to use a board design station to edit FPGA schematics I can no longer share them with people using FPGA workstations. This is a *major* problem for me since I will need to distribute my FPGA designs to various customers. I can edit board schematics using any package I want. But I have to support my Lucent ORCA FPGA designs with the Viewdraw package. If I get a Viewdraw board package I am worried that I will either have a lot of trouble with the FPGA support or will have to maintain *two* Viewlogic workstations; one for boards and one for FPGAs. This is just such a PITA!!! Maybe I will pay them with a check that is only compatible with my bank if they don't run it through their bank first? -- 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: 24212
I forgot to make a point that shows how silly this Viewlogic restriction is. I long ago figured out that you can bring any VL schematic into any VL workstation by creating a file with the same name and extracting the key line. Copy this line into the file you are trying to move and it will work on the new workstation! It is just the fact that I will have to do this every time I want to send out a design to a customer that ticks me off. Then the first time I forget, I will have lots of calls from people saying that they can't read the files!!! -- 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: 24213
>> You're eyes are on the left and right sides of your face. If they >> were, say, in the top and bottom of your face, then a mirror would >> invert top & bottom! > >The mirror /doesn't/ invert left and right (or up and down or anything >else). The /user/ of the mirror does. Think about it. That was pretty much my point. >-- >Steve Rencontre http://www.rsn-tech.co.uk >//#include <disclaimer.h>Article: 24214
>Andy Peters wrote: <snip> >> and raise my rent! ... implying that you're not in the Bay area. >> What happens here is that the synth notices that rst1 is the global >> reset. The P+R tools then use rst1 as GSR, and rst2 in flop is >> actually used as a *synchronous* reset. (Note that neither rst1 nor >> rst2 were synced in an IFF.) Are you sure it's a synchronous reset? (You did put'*'s around it, so your probably sure.) That means that the synth tools are rather changing the function of the design, giving me a rather worrying feeling. This means, then, that if you do want to have the output of an asynchronous logic function reset a FF, and the output of a different asynch logic function reset a different logic function, you have to instatniate it "by hand"? >> In any event, I think the best thing to do is to have one global async >> reset, and use sync resets for your state machines and such to ensure >> they get reset as you expect. Hmm. Won't work for my application. I'm implementing a bunch of 1-shot timers in some unused space in a Xilinx FPGA. When the input bit goes to '1', I asynchronously reset my counter to all '1's. Then, I count down with a rather slow clock. My output is all the bits of the counter 'or'ed together. Since the input pulse can be really quick compared to my clock, and since I'm implementing about a dozen of these in one FPGA, does that mean that all of my asynch RST's are implemented synchronously? -kentArticle: 24215
In the Spartan FPGAs, you can use the free-running oscillator used for configuration inside your design with the 'OSC4' primitive. It's a very inaccurate oscillator, but good enough for what I'm doing. I'd like to know if it's possible to do the same thing in a spartan-II device. I've tried simply retargeting the Spartan-II device, without changing the VHDl code at all, but I get a "the OSC4 symbol is not supported in the spartan2 architecture. ..." error during translation. Thanks! -KentArticle: 24216
hey, i can't understand why many of you recommend the use of LFSR rather than a simple counter. building a counter using the dedicated carry logic will be much faster. although it's bit "rigid" because of the carry logic, but if it's modulo 16, it will take nomore than 2 clb... any comments please ... In article <8lqlva$sns@inf-gw.inf.furukawa.co.jp>, "K.Orthner" <nospam@ihatespam.com> wrote: > Assuming that you're not extremely short on space, you could buile a LFSRout > of regular FF's and logic blocks. Because the logic for a LFSR is much > simpler that for a counter, it would still be able to run significantly > faster. > > The VHDL code would look something like this: > > process lfsr (rst, clk ) > begin > if rst = '1' then > lfsr_reg <= '1' & (others => '0'); > -- Note: You have to reset the lfsr to non-zero. > > elsif rising_edge( clk ) then > lfsr_reg <= (lfsr_reg(0) xor lfsr_reg(2) ) & lfsr_reg (lfsr_size-1 > downto 1); > -- Another note: This is going left-to-right. > > end if; > end process; > > You can then just AND together all of the bits of lfsr_reg, which will give > you a pulse when the entire LFSR is '1'. (The all-zero state will never > happen). > > A length of 14 bits should give you a pulse once every 16383 clk cycles. > > -Kent > > P.S. I haven't read the app note, so my implementation may look nothing at > all like Xilinx's. > > > I have looked into using the LFSR setup described in Xilinx's > > XAPP210 (By Maria George and Peter Alfke), and implementing it > > looks simple enough. The problem is that I don't see how one > > gains access to all the bits in the LFSR. I want to do something > > like let the thing free run and output a pulse every time it > > comes round to a particular state, say 0. > > > > Does anybody know how to do this? > > ------------ > Kent Orthner > > Sent via Deja.com http://www.deja.com/ Before you buy.Article: 24217
erika_uk@my-deja.com wrote: > hey, > > i can't understand why many of you recommend the use of LFSR rather > than a simple counter. building a counter using the dedicated carry > logic will be much faster. although it's bit "rigid" because of the > carry logic, but if it's modulo 16, it will take nomore than 2 clb... > And if it's really a 4-bit modulo 16 counter, it would not even use the carry logic, but rather the 4-input LUTs, and would run "full bore" at >200 MHz. Peter Alfke, Xilinx ApplicationsArticle: 24218
"K. Orthner" wrote: > <snip> I'm implementing a bunch of 1-shot > timers in some unused space in a Xilinx FPGA. When the input bit goes to > '1', I asynchronously reset my counter to all '1's. Then, I count down > with a rather slow clock. My output is all the bits of the counter 'or'ed > together. Pretty clever! If the trailing edge of asynchr. preset collides with the first count clock, this problem gets resolved in the LSB only. It does not matter if other bits are still being preset for a few nanoseconds, or have been released earlier. At first look I was worried about the notoriously dangerous parallel resolution of an asynchronous interface, but your design is safe. Peter Alfke, Xilinx ApplicationsArticle: 24219
I'm downloading an xcv1000 from a CPU but get no change on the DONE or INIT_L pins ie they stay at 0 and 1 respectively. INIT_L responds OK to a pulse on PROGRAM_L. I've checked the data on a logic analyser and the start and end look correct (I haven't checked all words). The data is bit swapped compared to a .bit file as per Xilinx app note. I am strobing CS_L and WRITE_L so that the config is done in two byte bursts. Both CS_L and WRITE_L strobe to 0 to write a byte, and both are 1 when not writng. CCLK is 30.72MHz. BUSY is n/c since CCLK is <50-MHz. Should BUSY be tied high? I don't see why, it's output only according to the data sheet. The startup clock is CCLK. The programming mode is SelectMAP. I can configure OK with JTAG. I'm going mad and need ideas. This is the worst thing to debug since I programmed a Zilog SCC back in 1987 - nothing happens until everything is perfect. thanks AlunArticle: 24220
The LFSR does run considerably faster than a counter using the carry chain, especially as the width of the counter increases. The drawbacks are that 1) the count sequence is not intuitive, and 2) generally speaking you can't directly decode a particular state as fast as the counter runs. However, you can pipeline the decode to get the performance back. The LFSR can save you some resources but even that is not as important as it once was (you can use SRL16's if you don't need simultaneous access to all the states, and generally only one LUT is needed. BTW, you can still decode a state, for instance to get a terminal count when using SRL16s by looking at the N bit history. Easiest is the decode of the all zeros state, in which case you have a state machine that produces a '1' if the input was '0' for the last N clocks. erika_uk@my-deja.com wrote: > hey, > > i can't understand why many of you recommend the use of LFSR rather > than a simple counter. building a counter using the dedicated carry > logic will be much faster. although it's bit "rigid" because of the > carry logic, but if it's modulo 16, it will take nomore than 2 clb... > > any comments please ... > > In article <8lqlva$sns@inf-gw.inf.furukawa.co.jp>, > "K.Orthner" <nospam@ihatespam.com> wrote: > > Assuming that you're not extremely short on space, you could buile a > LFSRout > > of regular FF's and logic blocks. Because the logic for a LFSR is > much > > simpler that for a counter, it would still be able to run > significantly > > faster. > > > > The VHDL code would look something like this: > > > > process lfsr (rst, clk ) > > begin > > if rst = '1' then > > lfsr_reg <= '1' & (others => '0'); > > -- Note: You have to reset the lfsr to non-zero. > > > > elsif rising_edge( clk ) then > > lfsr_reg <= (lfsr_reg(0) xor lfsr_reg(2) ) & lfsr_reg > (lfsr_size-1 > > downto 1); > > -- Another note: This is going left-to-right. > > > > end if; > > end process; > > > > You can then just AND together all of the bits of lfsr_reg, which > will give > > you a pulse when the entire LFSR is '1'. (The all-zero state will > never > > happen). > > > > A length of 14 bits should give you a pulse once every 16383 clk > cycles. > > > > -Kent > > > > P.S. I haven't read the app note, so my implementation may look > nothing at > > all like Xilinx's. > > > > > I have looked into using the LFSR setup described in Xilinx's > > > XAPP210 (By Maria George and Peter Alfke), and implementing it > > > looks simple enough. The problem is that I don't see how one > > > gains access to all the bits in the LFSR. I want to do something > > > like let the thing free run and output a pulse every time it > > > comes round to a particular state, say 0. > > > > > > Does anybody know how to do this? > > > > ------------ > > Kent Orthner > > > > > > Sent via Deja.com http://www.deja.com/ > Before you buy.Article: 24221
rickman wrote: > I forgot to make a point that shows how silly this Viewlogic restriction > is. I long ago figured out that you can bring any VL schematic into any > VL workstation by creating a file with the same name and extracting the > key line. Copy this line into the file you are trying to move and it > will work on the new workstation! > > It is just the fact that I will have to do this every time I want to > send out a design to a customer that ticks me off. Then the first time I > forget, I will have lots of calls from people saying that they can't > read the files!!! Which, if your customers are like mine might be two revisions of the tools later :-) Is the FPGA only thing even an issue anymore, now that VL isn't being packaged with the FPGA tool suites from the vendors? I do remember what a PITA it was. > > > -- > > 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: 24222
K.Orthner wrote: > > You're welcome. I learnt something today too: nobody seems able to > > explain me why left and right are inverted in a mirror but not top > > and bottom ;-) > > You're eyes are on the left and right sides of your face. If they were, > say, in the top and bottom of your face, then a mirror would invert top & > bottom! > > (Aren't I full of answers today!) So what does a person with one eye see in a mirror? ...AArticle: 24223
One of the four inputs of the LUTs in the FLEX family is faster than the three others. Suppose we have a function like Y = A AND B AND C AND D, that fits in a LUT... And suppossing that there isn't any timing constrain in any of the inputs Is there any way to know - BEFORE compiling - which one of the four inputs will be assigned the fastest of the four inputs? Thanks Bernardino Leon bleon@lander.esArticle: 24224
Hans wrote: > I wonder if anybody can help me with the following problem, I have a > component synthesised by Synplicity 6.0 which I would like to use as a > black box component in a Foundation 2.1i project. I instantiate this black > box component (EDIF) in a VHDL top level entity which I then synthesis (or > try too) with FPGA express. The black box is synthesised without I/O ( I/O > insertion disabled). I assumed that the back box EDIF and FPGA generated > EDIF file would simply be merged into 1 big EDIF file, this doesn't seem > to be happening. > > When I synthesis the top entity I get (FPGA-PADMAP-3) errors on the inout > ports of the back box (all Out and In ports are OK). Unfortunately > Xilinx techdocs (http://support.xilinx.com/techdocs/3296.htm) did not > provide me with a solution. There also seem to be some issue with the EDIF > file bus notation as described in > http://support.xilinx.com/techdocs/2649.htm, this also (adding the > attribute to the Synplicity file) did not solve the problem. > > So my question is what steps are required to add a foreign generated EDIF > file to a Foundation project? > > Thanks, > Hans. The best way to do this is probably to merge in the foreign EDIF file at the NGDBUILD stage, keeping it as a black box during synthesis. This is easy if you are running with the command line tools + make. Using the GUI you will have to o use the ``add file to project'' command or whatever its called to put the EDIF in the right place in the hierarchy o use a GUI feature that can add flags to the Xilinx commands as they are run. The flag you need is the -sd one that points to a ``source directory'' where you keep the foreign EDIF. I'm sorry its so long since I used the GUI that I can't remeber the exact mechanics of this.
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