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
In article <39818074.325A095B@xess.com>, Dave Vanden Bout <devb@xess.com> wrote: > Try this: > > proj_fsm_coding_style = "onehot" > > or > > proj_fsm_coding_style = "binary" > > We have a document on using makefiles with Foundation at > http://www.xess.com/manuals/fndmake.pdf. > > Klaus Falser wrote: > > > Does anybody know how to force FPGA-Express to use binary encoding from > > command line mode? > > > > I'm using FPGA Express 3.3 and Xilinx Foundation F2.1. > > From the GUI I can specify the encoding type (one hot, binary .. ) for > > FSM's, but I have not found how to do this from the command line tool > > fe_shell. > > This would be useful for me since I like to do the whole synthesis > > process with makefiles. > > > > Every help is appreciated > > Klaus > > > > -- > > Klaus Falser > > Durst Phototechnik AG > > I-39042 Brixen > > > > Sent via Deja.com http://www.deja.com/ > > Before you buy. > > -- > || Dr. Dave Van den Bout XESS Corp. (919) 387-0076 || > || devb@xess.com 2608 Sweetgum Dr. (800) 549-9377 || > || http://www.xess.com Apex, NC 27502 USA FAX:(919) 387-1302 || > > Thank you very much. Could you please tell me where such information can be found? Klaus -- Klaus Falser Durst Phototechnik AG I-39042 Brixen Sent via Deja.com http://www.deja.com/ Before you buy.Article: 24176
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.Article: 24177
eml@riverside-machines.com.NOSPAM wrote: > > On Thu, 27 Jul 2000 14:30:05 -0400, rickman <spamgoeshere4@yahoo.com> > wrote: > Even if the mapper could restructure existing logic, how far would it > have to go? It might be reasonable to detect LUTs which only contain > an inverter, and remove them. It might be reasonable to invert F/F > data inputs and reset polarities. It might be reasonable to De > Morgan-ise an entire logic function, if it turns out that a free > inverter somewhere will save a few LUTs. However, this will cause > other inversions, which will propagate backwards, and the synthesiser > should have done all this work already. You have to draw the line > somewhere. Inverter elimination is exactly the type of stuff that it is supposed to do. I was told way back when the 4K series was new that the software would push an inverter in either direction into LUTs. I don't remember it being able to cross a FF boundry while invertering the GSR action. But at that time people seemed to be very aware of the waste of using a CLB to implement an inverter. Remember that this was done at a time when synthesis was not available. If you drew a block of gates on your schematic, the mapper had to figure out the best method of getting this to fit CLBs rather than the gates you had drawn. And engineers used every logic object in the book. -- 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: 24178
Klaus Falser wrote: > > Thank you very much. > Could you please tell me where such information can be found? > I find most of my information about FPGA Express by opening it directly (not through Foundation). It's under Start=>Programs=>Xilinx Foundation Series 2.1i=>Accesories=>FPGA Express. Then use its help system to open Help Topics=>Contents Tab=>FPGA Scripting Tool (FST). There is an FST Command Overview in there. -- || Dr. Dave Van den Bout XESS Corp. (919) 387-0076 || || devb@xess.com 2608 Sweetgum Dr. (800) 549-9377 || || http://www.xess.com Apex, NC 27502 USA FAX:(919) 387-1302 ||Article: 24179
Cool. I was not aware that a BUFG could be driven by anything by
a clock pin or a DLL output. That could be quite useful.
Sorry for the mis-information!
Ben
===========================================================
Ben Sanchez Engineer, Lab Manager
e-mail: ben@phoenix.seti.org Project Phoenix
SETI Institute
Web: http://www.seti.org 2035 Landings Drive
Mountain View, CA 94043
===========================================================
"K.Orthner" wrote:
>
> "Ben Sanchez" <ben@seti.org> wrote:
>
> > No. It can only be driven by a global clock input buffer
> > (IBUFG), which can only be driven by a Global clock input pin
> > (there are 4 on a virtex, 8 on VirtexE). If you want an internal
> > signal to drive a CLKDLL, you have to bring it out a pin and back
> > in a clock pin, but all that delay out and in probably defeats
> > the purpose of the DLL.
>
> Referring to XAPP132,
>
> If you use the CLKDLL primitive, you can source the input clockfrom a BUFG,
> but if you use the BUFGDLL primitive, than you must use an external pin.
>
> This is copied from the XAPP132 application note, from the CLKDLL section:
>
> CLKDLL Primitive Pin Descriptions
> The library CLKDLL primitives provide access to the complete set of DLL
> features needed
> when implementing more complex applications with the DLL.
> Source Clock Input - CLKIN
> The CLKIN pin provides the user source clock (the clock signal on which the
> DLL operates) to
> the DLL. The CLKIN frequency must fall in the ranges specified in the
> datasheet. The clock
> input signal can be provided by one of the following:
> . BUFG - Internal global clock buffer
> . IBUFG - Global clock input buffer on the same edge of the device (top or
> bottom)
> . IO_LVDS_DLL - the pin adjacent to a global clock pin.
>
> ------------
> Kent Orthner
> korthner at hotmail dot com
Article: 24180
I was using a 14 bit counter. I think the problem is somehow
related to the fact that I recently switched to the
LeonardoSpectrum synth tool, and I don't know how to use it. It
is supposed to be much better than FPGA express that comes with
the ViewLogic tools, but in this case the results are dismal.
The 14bit counter run's at only 50-65MHz, while the rest of the
design can run a little above 160MHz.
In the mean time I implemented an LFSR in FFs with a pipelined
comparator to decode the all zero state. (three 4-input ANDs ->
register (pipeline the lsb of the 13 bit LFSR) -> 1 4 input AND
-> register -> output)
That run's fast.
In the future when the time pressure of this particular job is
off I want to figure out why these counters don't run fast when
synthesized with LS.
Ben
===========================================================
Ben Sanchez Engineer, Lab Manager
e-mail: ben@phoenix.seti.org Project Phoenix
SETI Institute
Web: http://www.seti.org 2035 Landings Drive
Mountain View, CA 94043
===========================================================
rickman wrote:
>
> "K.Orthner" 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).
>
> You were doing pretty well untill you suggested ANDing all the bits of
> the counter. If the standard fast carry counter is speed limited, then a
> 14 input AND gate will be the speed limiting logic. This would need to
> be pipelined and likely floorplanned.
>
> Actually, I can't see how a 14 bit fast carry counter could be too slow
> for this application. The fast carries are very fast and with only 14
> bits are likely to be nearly as fast as the LFSR. How many bits were
> being used in the counter?
>
>
> > 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
>
> --
>
> 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
Article: 24181Your problem is definitely the fact that the counter is too slow. If you dig into the EDIF produced (use a schematic viewer) you will likely find that the counter is being made with LUT logic. It should be made using the carry spine. To do this a macro is normally used with the carry logic embedded in it. I am not familiar with the Leonardo tool, so I can't tell you what you are doing wrong, but it may be related to your source, or possibly a switch on the tool. I expect that you could fix the counter problem faster than you can generate the LFSR you are talking about. But since you have already done that, it is a moot point now. Ben Sanchez wrote: > > I was using a 14 bit counter. I think the problem is somehow > related to the fact that I recently switched to the > LeonardoSpectrum synth tool, and I don't know how to use it. It > is supposed to be much better than FPGA express that comes with > the ViewLogic tools, but in this case the results are dismal. > > The 14bit counter run's at only 50-65MHz, while the rest of the > design can run a little above 160MHz. > > In the mean time I implemented an LFSR in FFs with a pipelined > comparator to decode the all zero state. (three 4-input ANDs -> > register (pipeline the lsb of the 13 bit LFSR) -> 1 4 input AND > -> register -> output) > > That run's fast. > > In the future when the time pressure of this particular job is > off I want to figure out why these counters don't run fast when > synthesized with LS. > > Ben > > =========================================================== > Ben Sanchez Engineer, Lab Manager > e-mail: ben@phoenix.seti.org Project Phoenix > SETI Institute > Web: http://www.seti.org 2035 Landings Drive > Mountain View, CA 94043 > =========================================================== > > rickman wrote: > > > > "K.Orthner" 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). > > > > You were doing pretty well untill you suggested ANDing all the bits of > > the counter. If the standard fast carry counter is speed limited, then a > > 14 input AND gate will be the speed limiting logic. This would need to > > be pipelined and likely floorplanned. > > > > Actually, I can't see how a 14 bit fast carry counter could be too slow > > for this application. The fast carries are very fast and with only 14 > > bits are likely to be nearly as fast as the LFSR. How many bits were > > being used in the counter? > > > > > > > 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 > > > > -- > > > > 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: 24182
In article <8louol$bj6@inf-gw.inf.furukawa.co.jp>, nospam@ihatespam.com (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! The mirror /doesn't/ invert left and right (or up and down or anything else). The /user/ of the mirror does. Think about it. -- Steve Rencontre http://www.rsn-tech.co.uk //#include <disclaimer.h>Article: 24183
Can anyone recommend low-cost alternatives to what seems to be pretty costly serial config eproms/proms for FPGAs ?? We are looking at Spartan-II and the 1MBit config eprom is about the same price as the FPGA. For my current application I can't load the FPGA from the microprocessor. I was thinking about maybe using a regular byte-wide Flash device and CPLD or PIC instead (maybe a $5 solution instead of $15) -- StuartArticle: 24184
For some reason my posts (going through nntp.news.netcom.com) are VERY slow in posting, so some of you have not received my responses yet. The clock rate is 100MHz. I am using this counter to replace a 1PPS pulse, but I don't need the time between pulses to be 1 second for this application, so I just made it 10K so the counter wouldn't be that big. I do wonder why the counter wouldn't run faster, I've never had these types of problems with other counter's, but that was using FPGA Express as a synth, now I'm using LeonardoSpectrum. Anybody why counters would be slow when run through LS? Ben rickman wrote: > > "K.Orthner" wrote: > > > > > You were doing pretty well untill you suggested ANDing all the bits of > > > the counter. If the standard fast carry counter is speed limited, then a > > > 14 input AND gate will be the speed limiting logic. This would need to > > > be pipelined and likely floorplanned. > > > > I was going to suggest pipelining the AND . . but i figured if you can use > > 6-input LUTs, then a 14-bit AND is only 2 logic levels . . . . how slow can > > it be? > > > > <checking the book quick to make sure you can use 6-input LUTs . . . > > > > > Okay. Looks like no 6-input LUTs. > > But still, two levels of 2-input LUTs? > > > > o <= (i0 * i1 * i2 * i3) * (i4 * i5 * i6 * i7) * (i8 * i9 * i10 * i11) * > > (i12 * i13) > > > > That's not *that* bad, is it? How fast are you trying to run your counter? > > > > ------------ > > Kent Orthner > > I agree that this is not all that slow. But it will be slower than a > LFSR. The LFSR is designed to only use a single level of logic for the > feedback and the FFs can be arranged to minmize the routing delays. The > 14 input AND gate will make it harder to get short routes. Often the > route delays are longer than the logic delays. > > In this design I can't see where a 14 bit fast counter will be too slow > for nearly any application. I would like to know what clock rate is > being used. Especially if a count of 10,000 is roughly equal to 1 > second!!! I may have misread that part... > > -- > > 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: 24185
K.Orthner wrote in message <8lqmv8$c1@inf-gw.inf.furukawa.co.jp>...
>> These processes won't generate the same logic. Example 1 has both a
>> synchronous reset and an async reset. Example 2 has two async resets.
>> Different behaviour. Of course, if ByteReq is generated by synchronous
>> logic, then it will "appear" to be a sync reset, but it's not.
>>
>> In fact, an FPGA synthesis tool will probably choke on Example 2, because
>> the template for flip-flops has only the clock and the async reset in the
>> sensitivity list.
>
>I have't tried it, but wouldn't any decent synthesis tool generate a
>two-input logic function for the two resets, and then feed that into the FF
>reset? You only run into a problem if you're trying to reset tt to '1' in
>one case, and to '0' in another.
OK, I just did a simple test with FPGA Express and F2.1i. Target was an XLA
part.
given:
flop : process (clk, rst1, rst2) is
begin
if rst = '1' or rst2 = '1' then
q <= '0';
elsif rising_edge (clk) then
q <= d;
end if;
end process flop;
and raise my rent! rst1 and rst2 get ORed in a CLB, whose output (a net
called N0) feeds the STARTUP block's GSR. N0 is therefore the chip's global
reset!
Now, where it gets ugly is if you add another flop to your design, but you
choose to asynchronously reset it with only one of the two signals:
flop2 : proess (clk, rst1) is
if rst1 = '1' then
q1 <= '0';
elsif rising_edge(clk) then
q1 <= d1;
end if;
end process flop2;
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.)
so, the synthesis tool is quite happy to have a flop with two async resets.
and the P+R tools are quite happy to spit out some logic to attempt to do
what you want.
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.
-- a
-----------------------------------------
Andy Peters
Sr Electrical Engineer
National Optical Astronomy Observatories
950 N Cherry Ave
Tucson, AZ 85719
apeters (at) noao \dot\ edu
"A sufficiently advanced technology is indistinguishable from magic"
--Arthur C. Clarke
Article: 24186We use a CPLD and a 16 Mbit Flash on our XSV Boards. The CPLD controls the programming of the Flash and then the configuration of the Virtex FPGA from the Flash. Xilinx provides an app-note that shows how the CPLD controls the configuration process. You can get an 8051 in a 44-pin package for about $1 and a 1 Mbit Flash device for about $1.50. The 8051 will have enough I/O to drive the address and control lines of the Flash and the configuration clock of the FPGA. I'm not sure how much pinout you can get from a PIC for $1. Stuart J Adams wrote: > Can anyone recommend low-cost alternatives to > what seems to be pretty costly serial config > eproms/proms for FPGAs ?? We are looking at > Spartan-II and the 1MBit config eprom is about > the same price as the FPGA. > > For my current application I can't load the FPGA > from the microprocessor. > > I was thinking about maybe using a regular byte-wide > Flash device and CPLD or PIC instead (maybe a $5 > solution instead of $15) > > -- Stuart -- || Dr. Dave Van den Bout XESS Corp. (919) 387-0076 || || devb@xess.com 2608 Sweetgum Dr. (800) 549-9377 || || http://www.xess.com Apex, NC 27502 USA FAX:(919) 387-1302 ||Article: 24187
Andy Peters wrote: > > K.Orthner wrote in message <8lqmv8$c1@inf-gw.inf.furukawa.co.jp>... > >> These processes won't generate the same logic. Example 1 has both a > >> synchronous reset and an async reset. Example 2 has two async resets. > >> Different behaviour. Of course, if ByteReq is generated by synchronous > >> logic, then it will "appear" to be a sync reset, but it's not. > >> > >> In fact, an FPGA synthesis tool will probably choke on Example 2, because > >> the template for flip-flops has only the clock and the async reset in the > >> sensitivity list. > > > >I have't tried it, but wouldn't any decent synthesis tool generate a > >two-input logic function for the two resets, and then feed that into the FF > >reset? You only run into a problem if you're trying to reset tt to '1' in > >one case, and to '0' in another. > > OK, I just did a simple test with FPGA Express and F2.1i. Target was an XLA > part. > > given: > > flop : process (clk, rst1, rst2) is > begin > if rst = '1' or rst2 = '1' then > q <= '0'; > elsif rising_edge (clk) then > q <= d; > end if; > end process flop; > > and raise my rent! rst1 and rst2 get ORed in a CLB, whose output (a net > called N0) feeds the STARTUP block's GSR. N0 is therefore the chip's global > reset! > > Now, where it gets ugly is if you add another flop to your design, but you > choose to asynchronously reset it with only one of the two signals: > > flop2 : proess (clk, rst1) is > if rst1 = '1' then > q1 <= '0'; > elsif rising_edge(clk) then > q1 <= d1; > end if; > end process flop2; > > 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.) > > so, the synthesis tool is quite happy to have a flop with two async resets. > and the P+R tools are quite happy to spit out some logic to attempt to do > what you want. > > 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. This was a good test, but are you sure that the second reset "rst2" in the second case is really a synchronous reset? The FFs as described in the data sheet have a clock, three explicit inputs and one hidden input. The hidden input is the GSR which is an async reset/set. The explicit inputs are the data and CE inputs which are both synchronous and the set/reset input which is asynchronous. If the logic produced used the set/reset input rather than a LUT, then this is also an async input and is just what the VHDL specified. Was your statement above about the rst2 signal being a *synchronous* reset a typo? -- 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: 24188
I have 1078 blank XC17128DPC20C configuration proms 20 pin PLCC package one time programmable 5Volt technology 131072 bits top mark: 17128DJC 929467 I can program the devices if needed. If you are interested in any quantity, please reply to pablo@maine.rr.com Thanks, PaulArticle: 24189
You're not saving much of anything on the routing. The signals still have to go onto the routing channel, as each signal has 2 destinations. One of those is the F5 Mux. The other has to go on the routing. You'll find that in most cases the route goes past the second destination anyway (best layout seems to be natural order on every layer so you can get half the routes direct. In the case of the F5 mux, that makes the direct route the one through the F5. Also, you get a slightly irregular layout (signals going back and forth to allow you to put two of the extra 2 input muxes in the same slice) or holes in the layout that aren't too useful. In 4K this going back and forth actually makes the shifter with the HLUTs slower without even considering the effect of pipelining. In virtex, I don't know if there'd be much a difference. rickman wrote: > Ray Andraka wrote: > > > > Well, the F5 mux is still a 2 input mux, sure you get it for "free", but that is beside my > > point. Consider the simple case of a 4 input rotator (a barrel shift with the inputs > > 'wrapped around'). If you implement it in 4 input muxes, you need 4 of them right. That > > is 4 slices or 4 CLBs depending on the xilinx architecture, fine. If you use 2 input > > muxes in a merged tree, the first layer uses 4, and the second layer uses 4, for a total > > area that is the same as that of the case using 4 input muxes, but without using the F5 > > muxes. The difficulty with using the F5 muxes is that you don't get to share the terms. > > I understand what you are saying, but the "free" muxes are *exactly* my > point. But in any case but the most trivial, the merged tree is better > than the non-merged tree. As you get larger, the merged tree is *much* > better. But you can do a merged tree with 4 input muxes as well. > > 2mux 4mux > bits CLBs CLBs > 4 2 2 > 8 6 6 (one layer of 2mux) > 16 16 16 > 32 40 40 (one layer of 2mux) > 64 96 96 > > So it looks like a merged tree of 4mux and 2mux uses the same number of > CLBs, but certainly the 4mux approach uses fewer routes since some of > them are internal to the CLBs. > > Routing congestion is a little hard to measure. If you count pins that > must be connected, it is 10 * CLBs for the 4mux and 12 * CLBs for the 2 > mux. The net counts are N*(log4(N)+1) for the 4 mux and N*(log2(N)+1) > for the 2 mux. > > 2mux 4mux > bits Nets Pins Nets Pins > 4 12 24 8 20 > 16 80 192 48 160 > 64 448 1,152 256 960 > > I can't tell if this is a significant difference or not. I suspect that > the pin count is more important than the net count, but is is probably a > mixture of both. So the difference is there, and can approach a factor > of two in favor of the 4 mux as the size gets large. For the smaller > shifters it is likely not a big issue. > > The 8 input mux performs worse than either in terms of CLB count. It > will use 4/3 the CLB count of the 2mux and 4mux, the same pin count as > the 2mux and only slightly fewer nets than the 4mux. So it does not look > like it has any advantage over the 4mux approach. > > -- > > 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: 24190
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
Article: 24191I've never used anything but the foundation express tools with the gooey, but . . . You may want to simply call the place-and-route tools from the command line. That way you can explicitly set allt he options, and aren't limited to what they decided to let you use in the GUI. If you go to the Xilinx web site, I think that you'll find what you're looking for under the section for "2.1 Alliance" documentation. Try this URL: http://toolbox.xilinx.com/docsan/2_1i/ -Kent ------------ Kent Orthner korthner at hotmail dot comArticle: 24192
> Does the CLKDLL in Virtex/Spartan II could be drived by a internal
> signal ? If so, how to implement this ?
It must be driven by a clock buffer, so probably the easiest way is to
instantiate a clock buffer for the signal that you want to use to drive the
DLL, and then use the buffered signal as the DLL input.
Example: If you want to drive the DLL input with the signal clk_in:
dll_buffer_inst: bufg( i =>clk_in, o=>clk_in_buf);
dll_inst: dll( clkin => clk_in_buf, . . . . .
-Kent
------------
Kent Orthner
korthner at hotmail dot com
Article: 24193I've run into plenty of instances in Synplicity where the counter gets implemented as two levels of logic instead of one. Seems to be a function of trying to do loads and resets on the same counter. There are times it is easier to just do it structurally than to get the tools to make exactly what you want. Also, and I think this is more likely the problem in your case, I've noticed in several instances the Xilinx 3.1 tools don't always place the carry chain in one contiguous piece. You'd think something as basic as keeping the carry chain as one 'stick' would be something they'd check, but no. rickman wrote: > Your problem is definitely the fact that the counter is too slow. If you > dig into the EDIF produced (use a schematic viewer) you will likely find > that the counter is being made with LUT logic. It should be made using > the carry spine. To do this a macro is normally used with the carry > logic embedded in it. > > I am not familiar with the Leonardo tool, so I can't tell you what you > are doing wrong, but it may be related to your source, or possibly a > switch on the tool. I expect that you could fix the counter problem > faster than you can generate the LFSR you are talking about. But since > you have already done that, it is a moot point now. > > Ben Sanchez wrote: > > > > I was using a 14 bit counter. I think the problem is somehow > > related to the fact that I recently switched to the > > LeonardoSpectrum synth tool, and I don't know how to use it. It > > is supposed to be much better than FPGA express that comes with > > the ViewLogic tools, but in this case the results are dismal. > > > > The 14bit counter run's at only 50-65MHz, while the rest of the > > design can run a little above 160MHz. > > > > In the mean time I implemented an LFSR in FFs with a pipelined > > comparator to decode the all zero state. (three 4-input ANDs -> > > register (pipeline the lsb of the 13 bit LFSR) -> 1 4 input AND > > -> register -> output) > > > > That run's fast. > > > > In the future when the time pressure of this particular job is > > off I want to figure out why these counters don't run fast when > > synthesized with LS. > > > > Ben > > > > =========================================================== > > Ben Sanchez Engineer, Lab Manager > > e-mail: ben@phoenix.seti.org Project Phoenix > > SETI Institute > > Web: http://www.seti.org 2035 Landings Drive > > Mountain View, CA 94043 > > =========================================================== > > > > rickman wrote: > > > > > > "K.Orthner" 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). > > > > > > You were doing pretty well untill you suggested ANDing all the bits of > > > the counter. If the standard fast carry counter is speed limited, then a > > > 14 input AND gate will be the speed limiting logic. This would need to > > > be pipelined and likely floorplanned. > > > > > > Actually, I can't see how a 14 bit fast carry counter could be too slow > > > for this application. The fast carries are very fast and with only 14 > > > bits are likely to be nearly as fast as the LFSR. How many bits were > > > being used in the counter? > > > > > > > > > > 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 > > > > > > -- > > > > > > 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: 24194
> > > > The datasheet says the Virtex is .22 um. The Spartan II is .18 um > > according to an XCell article, xl35_5.pdf. > > > > Yup, based on your reference I stand corrected. I wonder how they get > away with it? I was under the impression that 2.5V was too much for > 0.18um geometries, hence the requirement for 1.8V power for devices > like Vertex-E, XPLA4, and XC9500XE. Other Xilinx 2.5V devices > including XC4000XV, XC9500XV, and K2 use 0.25um geometries. The data book that I have (Programmable Logic Data Book 2000) indicates : Spartan-II: "Advanced 0.22/0.18 um 6-layer process" Virtex: "0.22um 5-layer metal process" (Not advanced?) This, of course, implies that Virtex *will* burn more power, and the spreadsheet that I pointed you to is not applicable to use. My apologies. -Kent ------------ Kent OrthnerArticle: 24195
> These processes won't generate the same logic. Example 1 has both a > synchronous reset and an async reset. Example 2 has two async resets. > Different behaviour. Of course, if ByteReq is generated by synchronous > logic, then it will "appear" to be a sync reset, but it's not. > > In fact, an FPGA synthesis tool will probably choke on Example 2, because > the template for flip-flops has only the clock and the async reset in the > sensitivity list. I have't tried it, but wouldn't any decent synthesis tool generate a two-input logic function for the two resets, and then feed that into the FF reset? You only run into a problem if you're trying to reset tt to '1' in one case, and to '0' in another. ------------ Kent OrthnerArticle: 24196
"Jamil Khatib" <Khatib@opencores.org> wrote in message
news:397EAC8F.75874219@opencores.org...
> I use the ieee.std_logic_signed
> in order to perform synthesizable arithmetic functions using the
> operators +,-,*,/
OK. Be aware that std_logic_signed is really a Synopsys creation, and not a
true IEEE library.
> but I do not know which representation do they use (sign magnitude, 1's
> complement or so). I want to use sign magnitude representation
They use 2's complement representations. You'll have to write your own
libraries if you want to use sign magnitude representations. (But do you
really want to do that? Sign magnitude is really painful...)
> What can I do if some of the operations in the same module are signed
> and the others are not? I am trying to append '0' on the left of the
> std_logic_vector signals and perform the operation.
mySignedSignal<= signed("0" & someUnsignedSignal) ???
---Joel Kolstad
Article: 24197I 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. 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. 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? Ray Andraka wrote: > > You're not saving much of anything on the routing. The signals still have to go onto the > routing channel, as each signal has 2 destinations. One of those is the F5 Mux. The other has > to go on the routing. You'll find that in most cases the route goes past the second destination > anyway (best layout seems to be natural order on every layer so you can get half the routes > direct. In the case of the F5 mux, that makes the direct route the one through the F5. Also, > you get a slightly irregular layout (signals going back and forth to allow you to put two of the > extra 2 input muxes in the same slice) or holes in the layout that aren't too useful. In 4K > this going back and forth actually makes the shifter with the HLUTs slower without even > considering the effect of pipelining. In virtex, I don't know if there'd be much a difference. > > rickman wrote: > > > Ray Andraka wrote: > > > > > > Well, the F5 mux is still a 2 input mux, sure you get it for "free", but that is beside my > > > point. Consider the simple case of a 4 input rotator (a barrel shift with the inputs > > > 'wrapped around'). If you implement it in 4 input muxes, you need 4 of them right. That > > > is 4 slices or 4 CLBs depending on the xilinx architecture, fine. If you use 2 input > > > muxes in a merged tree, the first layer uses 4, and the second layer uses 4, for a total > > > area that is the same as that of the case using 4 input muxes, but without using the F5 > > > muxes. The difficulty with using the F5 muxes is that you don't get to share the terms. > > > > I understand what you are saying, but the "free" muxes are *exactly* my > > point. But in any case but the most trivial, the merged tree is better > > than the non-merged tree. As you get larger, the merged tree is *much* > > better. But you can do a merged tree with 4 input muxes as well. > > > > 2mux 4mux > > bits CLBs CLBs > > 4 2 2 > > 8 6 6 (one layer of 2mux) > > 16 16 16 > > 32 40 40 (one layer of 2mux) > > 64 96 96 > > > > So it looks like a merged tree of 4mux and 2mux uses the same number of > > CLBs, but certainly the 4mux approach uses fewer routes since some of > > them are internal to the CLBs. > > > > Routing congestion is a little hard to measure. If you count pins that > > must be connected, it is 10 * CLBs for the 4mux and 12 * CLBs for the 2 > > mux. The net counts are N*(log4(N)+1) for the 4 mux and N*(log2(N)+1) > > for the 2 mux. > > > > 2mux 4mux > > bits Nets Pins Nets Pins > > 4 12 24 8 20 > > 16 80 192 48 160 > > 64 448 1,152 256 960 > > > > I can't tell if this is a significant difference or not. I suspect that > > the pin count is more important than the net count, but is is probably a > > mixture of both. So the difference is there, and can approach a factor > > of two in favor of the 4 mux as the size gets large. For the smaller > > shifters it is likely not a big issue. > > > > The 8 input mux performs worse than either in terms of CLB count. It > > will use 4/3 the CLB count of the 2mux and 4mux, the same pin count as > > the 2mux and only slightly fewer nets than the 4mux. So it does not look > > like it has any advantage over the 4mux approach. > > > > -- > > > > 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: 24198
"Steve Casselman" <sc@vcc.com> wrote in message news:snu82dnr3j169@corp.supernews.com... > I predict 2-3 years > after they produce the device in volume everyone will recognize that > reconfigurable computing is the future. I realize you're in the business of reconfigurable computing, Steve, but I think your time estimates are way too liberal. Getting software technology (compilers, primarily) to actually make use of the reconfigurable portion of a CPU and getting programmers to write in some style or language to facilitate that use is going to take a lot longer, I believe. More like the better part of a decade, I think. Heck, FPGAs are only just barely reconfigurable today due to a lack of tool support. You can do it, but it's still way too hard for all but the most aggressive designers out there today. I'd be interested in hearing your opinions on applications for PowerPC+FPGA ICs vs. the ill-fated XC6200 series of ICs. ---Joel KolstadArticle: 24199
"Ben Sanchez" <ben@seti.org> wrote: > No. It can only be driven by a global clock input buffer > (IBUFG), which can only be driven by a Global clock input pin > (there are 4 on a virtex, 8 on VirtexE). If you want an internal > signal to drive a CLKDLL, you have to bring it out a pin and back > in a clock pin, but all that delay out and in probably defeats > the purpose of the DLL. Referring to XAPP132, If you use the CLKDLL primitive, you can source the input clockfrom a BUFG, but if you use the BUFGDLL primitive, than you must use an external pin. This is copied from the XAPP132 application note, from the CLKDLL section: CLKDLL Primitive Pin Descriptions The library CLKDLL primitives provide access to the complete set of DLL features needed when implementing more complex applications with the DLL. Source Clock Input - CLKIN The CLKIN pin provides the user source clock (the clock signal on which the DLL operates) to the DLL. The CLKIN frequency must fall in the ranges specified in the datasheet. The clock input signal can be provided by one of the following: . BUFG - Internal global clock buffer . IBUFG - Global clock input buffer on the same edge of the device (top or bottom) . IO_LVDS_DLL - the pin adjacent to a global clock pin. ------------ Kent Orthner korthner at hotmail dot com
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