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
What's wrong with a robust asynchronous fifo??? Pat hamish@cloud.net.au wrote: >In a design I'm working on at the moment, I have new data on every >rising edge of a 175 MHz clock and I need to transfer it to >be synchronous to a 350 MHz clock. No uncertainty in the >350 MHz data is acceptable. > >To generate the clocks, I have an external 350 MHz source, >and I'm using the CLK0 and CLKDV (divided by 2) outputs on >a DCM. I'm using a Xilinx 2V6000-5. > >I have global buffers for each clock, but I expect there >will be some skew between the clocks, since the 350 MHz >clock is lightly loaded (200-300 FFs), compared to the >175 MHz clock (2500 FFs). So I might violate the hold >time on the 350 MHz FFs if I'm not careful. > >Some things I have considered: > >1. Sample the 175 MHz data with the 350 MHz clock directly. Could > violate the hold time if there is sufficient skew between the > clocks and the logic/net delays are particularly small. Also, > I have 68 bits of data, so this isn't too good. > >2. Sample the 175 MHz data with the next falling edge of the > 350 MHz clock. A half-period of the 350 MHz clock is only > 1.429 ns. Allowing for jitter, the FF to FF delay needs > to be about 1.3 ns, on all 68 data paths. Plus another > 68 paths to get it back to the rising edge, possibly. > >3. Generate an enable signal at 175 MHz and sample it using > the falling edge of the 350 MHz. Same problem as #2, > but with only 1-2 bits. I did try this, with hand placement > of the FFs, and got the delay down to 1.41 ns, which is > impressive (effectively over 700 MHz performance), but > probably not enough. Using the enable signal, the data > bits have a full 350 MHz period of setup and hold (less skew). > >4. Just do it (like #1), but add some deliberate delays in the > data path to try to guarantee that the delays are larger > than the clock skew. Deliberate delays could include hand > placement to create long net delays, or instantiating > LUTs to act as buffers. This could be limited to a single > enable bit, with the data bits transferred safely on > the next 350 MHz edge. > >#3 is preferred, but not quite fast enough. #4 seems the >next best option, but it makes me a bit uncomfortable. > >Can anyone add any other suggestions? Or try to convince >me that #4 is acceptable, or otherwise? > >I saw a new Xilinx app note, XAPP265, which described a design >for doing an 8:1 SERDES. That design would have a similar >requirement to mine. It uses an 1/4 frequency clock instead >though, which seems to simplify the problem a bit. > > >thanks, >Hamish >Article: 35976
Hi,
"Ray Andraka" <ray@andraka.com> wrote in message
news:3BD814AD.2E81FE2E@andraka.com...
> I think perusing the FPGA vendor's websites, especially the design
for
> synthesis and applications notes pages will get you farther than a
book,
> and is likely to be more current.
>
Agreed, but if someone wants to learn the very basics (like CLBs,
routability, number of CLBs utilized etc. - I am sure there are more),
I feel this book is good, again I recommend this mainly as a VHDL book
with some Programmable stuff "embedded".
Let me put it this way, if I were to switch to FPGAs I will go
through this book once before looking at Vendors' stuff.
Regards,
Srinivasan
>
--
Srinivasan Venkataramanan
ASIC Design Engineer
Software & Silicon Systems India Pvt. Ltd. (An Intel company)
Bangalore, India, Visit: http://www.simputer.org)
Article: 35977
A count to 10^7 needs only 24 bits, which should require only 12 slices or
24 LEs to implement if it uses the fast carry chain. If you want a modulo
10^7 count, use a downcounter that gets reloaded when it reaches its
terminal count (goes negative). That way, there are no resources used to
do the compare, and by changing the load value the modulus is easily
changed. Alternatively, if you need the counter bits out and the count
modulus never changes, you needn't decode all the bits:
1000000 = 989680/h numbers above this are never reached, so you only
need to decode the '1' bits. so the decode need only look at bits
23,20,19,15,12,10,9, and 7. That's only 8 of the 24 bits.
Jerre wrote:
> Hello,
>
> In my design I need to make a synchronous counter that counts, let's
> say, till 1000000. (Actual aim for counter is to built in a delay). I
> do this by the use of integer type signals and with each clock'event I
> add 1 till I reach the wanted 1000000. When I try to implement this
> in an FPGA it consumes a very high amount of CLBs and it seems very
> disastrous for the maximum reachable clock freq.
>
> If I would use an unsigned type would it differ a lot?
>
> Other tips?
>
> Greetz from a newbie,
>
> Jerre.
--
--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: 35978
YOu can buy a little more margin by synthesizing a 175 MHz clock enable
in the 350 MHz clock domain, then using that to effectively sample the
175 MHz data in the middle of the sample. The synthesized clock enable
has to be synchronized to your 175 MHz clock, obviously. To do that,
sample your 175 MHz clock with the falling edge of the 350 MHz clock,
then retime that to the rising edge. These 2 flip-flops should be
floorplanned so that the delay between them does not exceed your allowed
time. This is a variation on what you are doing in alternative #2,
except here you have only one signal with the really tight timing.
Another consideration is to either not use single ended I/O on the same
IO Bank as the clock. Single ended I/Os on the same bank seem to add a
considerable amount of jitter to the internal clock because of the I/O
rail fluctuations, especially for outputs.
hamish@cloud.net.au wrote:
> In a design I'm working on at the moment, I have new data on every
> rising edge of a 175 MHz clock and I need to transfer it to
> be synchronous to a 350 MHz clock. No uncertainty in the
> 350 MHz data is acceptable.
>
> To generate the clocks, I have an external 350 MHz source,
> and I'm using the CLK0 and CLKDV (divided by 2) outputs on
> a DCM. I'm using a Xilinx 2V6000-5.
>
> I have global buffers for each clock, but I expect there
> will be some skew between the clocks, since the 350 MHz
> clock is lightly loaded (200-300 FFs), compared to the
> 175 MHz clock (2500 FFs). So I might violate the hold
> time on the 350 MHz FFs if I'm not careful.
>
> Some things I have considered:
>
> 1. Sample the 175 MHz data with the 350 MHz clock directly. Could
> violate the hold time if there is sufficient skew between the
> clocks and the logic/net delays are particularly small. Also,
> I have 68 bits of data, so this isn't too good.
>
> 2. Sample the 175 MHz data with the next falling edge of the
> 350 MHz clock. A half-period of the 350 MHz clock is only
> 1.429 ns. Allowing for jitter, the FF to FF delay needs
> to be about 1.3 ns, on all 68 data paths. Plus another
> 68 paths to get it back to the rising edge, possibly.
>
> 3. Generate an enable signal at 175 MHz and sample it using
> the falling edge of the 350 MHz. Same problem as #2,
> but with only 1-2 bits. I did try this, with hand placement
> of the FFs, and got the delay down to 1.41 ns, which is
> impressive (effectively over 700 MHz performance), but
> probably not enough. Using the enable signal, the data
> bits have a full 350 MHz period of setup and hold (less skew).
>
> 4. Just do it (like #1), but add some deliberate delays in the
> data path to try to guarantee that the delays are larger
> than the clock skew. Deliberate delays could include hand
> placement to create long net delays, or instantiating
> LUTs to act as buffers. This could be limited to a single
> enable bit, with the data bits transferred safely on
> the next 350 MHz edge.
>
> #3 is preferred, but not quite fast enough. #4 seems the
> next best option, but it makes me a bit uncomfortable.
>
> Can anyone add any other suggestions? Or try to convince
> me that #4 is acceptable, or otherwise?
>
> I saw a new Xilinx app note, XAPP265, which described a design
> for doing an 8:1 SERDES. That design would have a similar
> requirement to mine. It uses an 1/4 frequency clock instead
> though, which seems to simplify the problem a bit.
>
> thanks,
> Hamish
> --
> Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>
--
--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: 35979Thanks for the reply. I guess the deceptively simple sentence "design with the CLB architecture in mind" is the crux. What exactly that entails probably requires years of experience and a lot of knowledge. Any advice you can give a rookie to get me started? Thanks, Dave "Patrick Hibbs" <phibbs@ti.com> wrote in message news:3BD81348.5060900@ti.com... > The reason the CLB usage is so high is due to the fact that CLBs are > partially > used. For example, the report states that you've used 68/200 flops -- > what you > don't know is how the flops are packed into the CLBs. Each CLB contains > two flops, 3 look-up-tables (LUTs), & two groups of muxes. You might have > 1 flop per CLB. If you design with the CLB architecture in mind then > you can > map to both of the flops in each CLB. The same goes for the LUTs in > your report. > > Pat > > > Dave Brown wrote: > > >Hi all, > > Thanks for all the great help so far, this is a great newsgroup! I'm > >looking at my Device Utilization Summary in Foundation ISE 4.1, for a > >Spartan 05XL, and I'm not sure why the overall CLB utilization is so high > >when my other numbers are low, is there some tool setting I'm missing, if > >not, what is eating up all my CLBs? Here's the exerpt from the summary: > > > >Device utilization summary: > > > > Number of External IOBs 52 out of 80 67% > > Flops: 0 > > Latches: 0 > > > > Number of CLBs 87 out of 100 87% > > Total Latches: 0 out of 200 0% > > Total CLB Flops: 68 out of 200 34% > > 4 input LUTs: 137 out of 200 68% > > 3 input LUTs: 27 out of 100 27% > > > > Number of BUFGLSs 5 out of 8 62% > > > >Thanks, > >Dave > > > > >Article: 35980
Dear All, I want to implement a 2/3 trellis coder. Could someone refer some vhdl codes. It must be an easy task. I also wonder how puncturing of a 1/2 convolutional code is implemented in vhdl, to obtain 3/4, 7/8 rate codes. Thanks SrinasArticle: 35981
"????? <rokn92@lycos.co.kr> wrote in message news:<9r7tu0$i42$1@green.kreonet.re.kr>... > Hello everyone! > I'm graduated student at university. > I want know about JBits. > from fundamental to applications > please, answer to me. > thank you. Have a look at http://www.geocities.com/SiliconValley/Pines/6639/fpga/jbits.html for JBits resources JBits is a tool set of Java APIs and classes so you can handle FPGA bit streams.Article: 35982
Got one for you that works nicely in an FPGA (virtex2). It is brute force
but it works OK. Note that the counter is strictly quasi-asynchrounous.
You could code the last few bits as a synchnous counter for a little
better behavior. I am using this with a 100MHz counter as an input. It
gives a reset for the DCM at roughly 0.6 seconds if I recall correctly.
main file is
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;
entity rst_generator is
Port ( clock : in std_logic;
done : in std_logic;
rst_out : out std_logic
-- stop : inout std_logic
);
end rst_generator;
architecture Behavioral of rst_generator is
component dibitcounter
port (
clock : in std_logic;
enable : in std_logic;
reset : in std_logic;
dibit_out: inout std_logic_vector(1 downto 0)
);
end component;
component dibitcounter2
port (
clock : in std_logic;
reset : in std_logic;
dibit_out: inout std_logic_vector(1 downto 0)
);
end component;
signal dibit_out: std_logic_vector(1 downto 0);
signal stop, not_stop: std_logic;
signal data_out: std_logic_vector(27 downto 0);
signal not_done: std_logic;
signal temp_clock: std_logic;
function int2vec(int1,NBits: integer)
return std_logic_vector is
variable N1: integer;
variable retval: std_logic_vector(NBits-1 downto 0);
begin
N1:=int1;
for i in retval'Reverse_Range loop
if (N1 mod 2)=1 then
retval(i):='1';
else
retval(i):='0';
end if;
N1:=N1/2;
end loop;
return retval;
end int2vec;
begin
not_done <= not(done);
u1:dibitcounter
port map
(
clock => clock,
enable => not_stop,
reset => not_done,
dibit_out => data_out(1 downto 0)
);
u2:dibitcounter2
port map
(
clock=>data_out(1),
reset=>not_done,
dibit_out=>data_out(3 downto 2)
);
u3:dibitcounter2
port map
(
clock=>data_out(3),
reset=>not_done,
dibit_out=>data_out(5 downto 4)
);
u4:dibitcounter2
port map
(
clock=>data_out(5),
reset=>not_done,
dibit_out=>data_out(7 downto 6)
);
u5:dibitcounter2
port map
(
clock=>data_out(7),
reset=>not_done,
dibit_out=>data_out(9 downto 8)
);
u6:dibitcounter2
port map
(
clock=>data_out(9),
reset=>not_done,
dibit_out=>data_out(11 downto 10)
);
u7:dibitcounter2
port map
(
clock=>data_out(11),
reset=>not_done,
dibit_out=>data_out(13 downto 12)
);
u8:dibitcounter2
port map
(
clock=>data_out(13),
reset=>not_done,
dibit_out=>data_out(15 downto 14)
);
u9:dibitcounter2
port map
(
clock=>data_out(15),
reset=>not_done,
dibit_out=>data_out(17 downto 16)
);
u10:dibitcounter2
port map
(
clock=>data_out(17),
reset=>not_done,
dibit_out=>data_out(19 downto 18)
);
u11:dibitcounter2
port map
(
clock=>data_out(19),
reset=>not_done,
dibit_out=>data_out(21 downto 20));
u12:dibitcounter2
port map
(
clock=>data_out(21),
reset=>not_done,
dibit_out=>data_out(23 downto 22));
u13:dibitcounter2
port map
(
clock=>data_out(23),
reset=>not_done,
dibit_out=>data_out(25 downto 24));
u14:dibitcounter2
port map
(
clock=>data_out(25),
reset=>not_done,
dibit_out=>data_out(27 downto 26));
process (data_out, done)
begin
if done = '0' then -- not done
rst_out<='0';
stop<='0';
not_stop<='1';
elsif done='1' and data_out(27 downto 23)="00000" then--done and running
rst_out<='0';
stop<='0';
not_stop<='1';
elsif done='1' and data_out(27 downto 23)="01000" then-- pulse high
rst_out<='1';
stop<='0';
not_stop<='1';
elsif done='1' and data_out(27 downto 23)="01001" then--pulse low
rst_out<='0';
stop<='1';
not_stop<='0';
end if;
end process;
end Behavioral;
secondary file 1 is
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;
entity dibitcounter is
Port ( clock : in std_logic;
enable : in std_logic;
reset : in std_logic;
dibit_out : inout std_logic_vector(1 downto 0));
end dibitcounter;
architecture Behavioral of dibitcounter is
begin
process(clock, enable, reset)
begin
if reset='1' then
dibit_out<="00";
elsif enable='1'then
if clock'event and clock='0' then
case dibit_out is
when "00"=>
dibit_out<="01";
when "01"=>
dibit_out<="10";
when "10"=>
dibit_out<="11";
when "11"=>
dibit_out<="00";
when others=>
null;
end case;
end if;
end if;
end process;
end Behavioral;
secondary file 2 is
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;
entity dibitcounter2 is
Port ( clock : in std_logic;
-- enable : in std_logic;
reset : in std_logic;
dibit_out : inout std_logic_vector(1 downto 0));
end dibitcounter2;
architecture Behavioral of dibitcounter2 is
begin
process(clock, reset)
begin
if reset='1' then
dibit_out<="00";
elsif clock'event and clock='0' then
case dibit_out is
when "00"=>
dibit_out<="01";
when "01"=>
dibit_out<="10";
when "10"=>
dibit_out<="11";
when "11"=>
dibit_out<="00";
when others=>
null;
end case;
end if;
end process;
end Behavioral;
Good Luck
Theron Hicks
Jerre wrote:
> Hello,
>
> In my design I need to make a synchronous counter that counts, let's
> say, till 1000000. (Actual aim for counter is to built in a delay). I
> do this by the use of integer type signals and with each clock'event I
> add 1 till I reach the wanted 1000000. When I try to implement this
> in an FPGA it consumes a very high amount of CLBs and it seems very
> disastrous for the maximum reachable clock freq.
>
> If I would use an unsigned type would it differ a lot?
>
> Other tips?
>
> Greetz from a newbie,
>
> Jerre.
Article: 35983Robert Staven schrieb: > > This brings me to another question, anybody done a up/oversampler with > sample rate convertion?(e.g. you don't need to 'lock' on the incoming No. > signal, just get rid of the jitter on it) > (I haven't done the maths for it yet, but I'm shure it ain't going to be > easy :) Why that pessimistic? Lets do a rough calculation. S/PDIF is max. 6Mbit/s (right?). So lets say we would like to work with an oversampling ratio of 16 (which should be fine, even 4 would probably work). So we need a 96 MHz clock, not too hard to get (just use 2 DLLs in Spartan-II/Virtex, to quadruple a 25 Mhz Xtal clock, we should not use 24 Mhz, because datasheet says minimum input freuquency for the DLL is 25 MHz) With a 100 MHz clock inside your FPGA it is possible to build a digital PLL to - recover the clock information from the datastream - create a second (dejitterd) clock to read the data from a FIFO. Since the oversampling factor is ~16, we will see a jitter of 1/16 on the outside clock, or with some more advanced design using both clock edges 1/32. Not too bad I think. And its a nice single chip solution. And a nice design challenge too. ;-) -- MFG FalkArticle: 35984
Andy Peters schrieb: > > tgingold@pc204.ipricot.fr wrote: > > > BTW, what's about: > > when '1' => a <= '1'; > > bad coding style... > > Well, that's more than bad coding style -- it's pathological! Right. Who the hell needs such weired synthax possible with C/C++ ?? A nice, clean style like Pascal or VHDL is all we need. And makes things easy to read. -- MFG FalkArticle: 35985
"Assaf Sarfati" <assaf_sarfati@yahoo.com> wrote in message news:44b0ca4e.0110242218.79ed6771@posting.google.com... > Hello, > > I want to design a very small board to control some LEDs, relays etc. It will > be controlled by a serial port (Rx-only). > > I don't want to use any processor (not even PIC); instead I'd like to implement > the control-logic with a CPLD. > > I would like to use a watch-crystal (32768 Hz) as the clock source; is there > any CPLD with built-in crystal oscillator? I don't want to add another chip > to the design just for clock-source. You could use an inverter in the CPLD (with the input and output brought out to pins) biased with a resistor in an oscillator circuit. There was a discussion about this a few weeks ago. Leon -- Leon Heller, G1HSM leon_heller@hotmail.con http://www.geocities.com/leon_heller Low-cost Altera Flex design kit: http://www.leonheller.comArticle: 35986
The easiest (and most widely used) trellis coder is rate 1/2 (the
"mother" rate).
You can easily tack a puncturer onto the output of the convolutional encoder
to get the desired coding rate. Try doing searches for convolutional
encoder
and viterbi encoder ... it'll be implemented as a simple shift register
(probably)
with feedback taps & output taps.
The puncturer can be implemented as such:
rate data_in data_out
---------------------------
1/2 X1
Y1 X1Y1
2/3 X1X2
Y1Y2 X1Y1Y2
etc.
In other words, the puncturer takes the convolutional encoder
parallel output (x & y) on the first clock and outputs x followed
by on the next two successive clocks (try a pipelined implementation).
Higher coding rates are trivial once you see the pattern (or just look in
a coding theory textbook).
Hope it helps,
Patrick Hibbs
srinas wrote:
>Dear All,
> I want to implement a 2/3 trellis coder. Could someone refer some
>vhdl codes. It must be an easy task. I also wonder how puncturing of a
>1/2 convolutional code is implemented in vhdl, to obtain 3/4, 7/8 rate
>codes.
>Thanks
>Srinas
>
Article: 35987Hello folks, I have a few Xilinx XC2018 chips (5V version) and wonder if there was a cheap way of programming those chips. I know that the XC2000 series is now obsolete an no newer software supports it. But perhaps there is some old software for free download in the net. Thanks in advance, Peter -- Dipl.-Inform. Peter Heitzer, phone +49 941 943 4850, fax +49 941 943 4857 mail Peter.Heitzer@rz.uni-regensburg.deArticle: 35988
Hello, could anybody say me where to find a simple free GAL (especially 16V8) compiler for MS-DOS? Thank you in forward, Gunther MayArticle: 35989
Eric Smith wrote: > > Andy Peters <andy@exponentmedia.deletethis.com> writes: > > Do yourself a favor, and don't directly use the Crystal > > MCLK/LRCLK/BCLK/data outputs to drive a converter. Use a FIFO in > > between, and generate your clocks locally. You'll cut the jitter down. > > And potentially introduce slips, since your sample rate may not match > the source. :-( No, you clock your incoming data into a FIFO, and you have a local-generated clock on the read side that runs at the same frequency as the recovered clock, but it's from an oscillator and not a PLL, so the hope is that the jitter on the clock feeding your DAC (the only place you really need to worry about jitter) should be lower. -aArticle: 35990
Gunther May <g.may@tu-bs.de> wrote: > Hello, > could anybody say me where to find a simple free GAL (especially 16V8) > compiler for MS-DOS? > Thank you in forward, > Gunther May try http://www.ee.bgu.ac.il/~elinst/palasm/ or do a google search for PALASM -- Dipl.-Inform. Peter Heitzer, phone +49 941 943 4850, fax +49 941 943 4857 mail Peter.Heitzer@rz.uni-regensburg.deArticle: 35991
glen herrmannsfeldt wrote: > > Bob Perlman <bob@cambriandesign.com> writes: > > >You can build glitch filters with tapped delay lines and majority > >detection logic, but with an important caveat. These filters will > >eliminate pulses shorter than X ns and pass pulses longer than Y ns, > >but X and Y aren't the same number. In between X and Y, the circuit > >can misbehave; there's a range of pulse durations that can produce > >glitches at the output of the filter. > > >If there were such a thing as a perfect glitch filter, we could build > >a metastable-proof flip-flop by filtering out runt pulses. Were it > >that it were. > > The original question asked about asynchronous logic, which doesn't > have a metastability problem. Asynchronous logic, also called self > timed logic, runs as fast as gates can change. Look up self-timed > logic somewhere. OK, so you've traded potential metastability in synchronous logic for potential race conditions in asynchronous logic. pick yr poison. -aArticle: 35992
If you want to use GCK6 as a clock input, you must tristate the external clock driver during configuration. Otherwise you will have contention from the time of power up, till configuration complete. Philip On Thu, 25 Oct 2001 15:25:54 +0300, Utku Ozcan <ozcan@netas.com.tr> wrote: > >Our application will be targetted to Xilinx SpartanXL XCS30XL-4-BG256C. >In Spartan/SpartanXL datasheet v1.6, it says that GCK6 and DOUT is on >B19 in a BG256 package. > >We have too many clocks and we want to use this B19 as clock input. > >But during the configuration, does it harm that we connect a clock to B19, >if the device is master/slave serial? Shall we disable the clock to B19 during >the configuration of this device? > >Utku > Philip Freidin FliptronicsArticle: 35993
--------------060006070307000301040200
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
You've got it now ... that simple sentence takes a while to get the hang of.
As far as advice:
o open up the xilinx datasheet for the 05xl & look at what makes up
a clb. if you have a simple single flop process in vhdl,
synthesis will
map that flop to one of the flops in a clb. if you have two simple
flops in vhdl, synthesis COULD map that to two clbs or just one clb.
o use constraints to guide your synthesis run. if you optimize for
speed,
it's likely that you'll have a larger implementation. just the
opposite for
area. check out the delay of a flop to flop inside of one CLB &
compare
that to the delay of a flop of one clb to a flop of another clb
+ routing.
o use constraints to guide your place & route run. open up chipviewer
& see how constraints affect the placement of logic.
o use the schematic viewer inside of your synthesis tool to see how
your
rtl was implemented. this will give you clues on how to
re-architect your
rtl.
Patrick.
Dave Brown wrote:
>Thanks for the reply. I guess the deceptively simple sentence "design with
>the CLB architecture in mind" is the crux. What exactly that entails
>probably requires years of experience and a lot of knowledge. Any advice you
>can give a rookie to get me started?
>Thanks,
>Dave
>
>"Patrick Hibbs" <phibbs@ti.com> wrote in message
>news:3BD81348.5060900@ti.com...
>
>>The reason the CLB usage is so high is due to the fact that CLBs are
>>partially
>>used. For example, the report states that you've used 68/200 flops --
>>what you
>>don't know is how the flops are packed into the CLBs. Each CLB contains
>>two flops, 3 look-up-tables (LUTs), & two groups of muxes. You might have
>>1 flop per CLB. If you design with the CLB architecture in mind then
>>you can
>>map to both of the flops in each CLB. The same goes for the LUTs in
>>your report.
>>
>>Pat
>>
>>
>>Dave Brown wrote:
>>
>>>Hi all,
>>> Thanks for all the great help so far, this is a great newsgroup! I'm
>>>looking at my Device Utilization Summary in Foundation ISE 4.1, for a
>>>Spartan 05XL, and I'm not sure why the overall CLB utilization is so high
>>>when my other numbers are low, is there some tool setting I'm missing, if
>>>not, what is eating up all my CLBs? Here's the exerpt from the summary:
>>>
>>>Device utilization summary:
>>>
>>> Number of External IOBs 52 out of 80 67%
>>> Flops: 0
>>> Latches: 0
>>>
>>> Number of CLBs 87 out of 100 87%
>>> Total Latches: 0 out of 200 0%
>>> Total CLB Flops: 68 out of 200 34%
>>> 4 input LUTs: 137 out of 200 68%
>>> 3 input LUTs: 27 out of 100 27%
>>>
>>> Number of BUFGLSs 5 out of 8 62%
>>>
>>>Thanks,
>>>Dave
>>>
>>>
>
>
--------------060006070307000301040200
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<html>
<head>
</head>
<body>
You've got it now ... that simple sentence takes a while to get the hang
of.<br>
<br>
As far as advice:<br>
o open up the xilinx datasheet for the 05xl & look at what makes
up<br>
a clb. if you have a simple single flop process in vhdl, synthesis
will<br>
map that flop to one of the flops in a clb. if you have two simple<br>
flops in vhdl, synthesis COULD map that to two clbs or just one clb.<br>
<br>
o use constraints to guide your synthesis run. if you optimize for
speed,<br>
it's likely that you'll have a larger implementation. just the opposite
for<br>
area. check out the delay of a flop to flop inside of one CLB &
compare<br>
that to the delay of a flop of one clb to a flop of another clb +
routing.<br>
<br>
o use constraints to guide your place & route run. open up chipviewer<br>
& see how constraints affect the placement of logic.<br>
<br>
o use the schematic viewer inside of your synthesis tool to see how
your<br>
rtl was implemented. this will give you clues on how to re-architect
your<br>
rtl.<br>
<br>
Patrick.<br>
<br>
Dave Brown wrote:<br>
<blockquote type="cite" cite="mid:9r9ah2$js3$1@pallas.novatel.ca">
<pre wrap="">Thanks for the reply. I guess the deceptively simple sentence "design with<br>the CLB architecture in mind" is the crux. What exactly that entails<br>probably requires years of experience and a lot of knowledge. Any advice you<br>can give a rookie to get me started?<br>Thanks,<br>Dave<br><br>"Patrick Hibbs" <a class="moz-txt-link-rfc2396E" href="mailto:phibbs@ti.com"><phibbs@ti.com></a> wrote in message<br><a class="moz-txt-link-freetext" href="news:3BD81348.5060900@ti.com">news:3BD81348.5060900@ti.com</a>...<br></pre>
<blockquote type="cite">
<pre wrap="">The reason the CLB usage is so high is due to the fact that CLBs are<br>partially<br>used. For example, the report states that you've used 68/200 flops --<br>what you<br>don't know is how the flops are packed into the CLBs. Each CLB contains<br>two flops, 3 look-up-tables (LUTs), & two groups of muxes. You might have<br>1 flop per CLB. If you design with the CLB architecture in mind then<br>you can<br>map to both of the flops in each CLB. The same goes for the LUTs in<br>your report.<br><br>Pat<br><br><br>Dave Brown wrote:<br><br></pre>
<blockquote type="cite">
<pre wrap="">Hi all,<br> Thanks for all the great help so far, this is a great newsgroup! I'm<br>looking at my Device Utilization Summary in Foundation ISE 4.1, for a<br>Spartan 05XL, and I'm not sure why the overall CLB utilization is so high<br>when my other numbers are low, is there some tool setting I'm missing, if<br>not, what is eating up all my CLBs? Here's the exerpt from the summary:<br><br>Device utilization summary:<br><br> Number of External IOBs 52 out of 80 67%<br> Flops: 0<br> Latches: 0<br><br> Number of CLBs 87 out of 100 87%<br> Total Latches: 0 out of 200 0%<br> Total CLB Flops: 68 out of 200 34%<br> 4 input LUTs: 137 out of 200 68%<br> 3 input LUTs: 27 out of 100 27%<br><br> Number of BUFGLSs 5 out of 8 62%<br><br>Thanks,<br>Dave<br
><br><br></pre>
</blockquote>
</blockquote>
<pre wrap=""><!----><br><br></pre>
</blockquote>
<br>
</body>
</html>
--------------060006070307000301040200--
Article: 35994Here are some thoughts: hamish@cloud.net.au wrote: > In a design I'm working on at the moment, I have new data on every > rising edge of a 175 MHz clock and I need to transfer it to > be synchronous to a 350 MHz clock. No uncertainty in the > 350 MHz data is acceptable. > > To generate the clocks, I have an external 350 MHz source, > and I'm using the CLK0 and CLKDV (divided by 2) outputs on > a DCM. I'm using a Xilinx 2V6000-5. > > I have global buffers for each clock, but I expect there > will be some skew between the clocks, since the 350 MHz > clock is lightly loaded (200-300 FFs), compared to the > 175 MHz clock (2500 FFs). So I might violate the hold > time on the 350 MHz FFs if I'm not careful. I think the loading ( if it has any effect at all ) would help you: It would move the 175 MHz data a little later. When the source clock is late and the receive clock is early, you avoid all hold time issues, but you lose performance. So, no hold-time issues here. I would run everything off the 350 MHz clock and generate a 175 MHz clock enable off that clock, and use it for the "175 MHz" portion. Global clock distribution skew has always been good, but is very good in Virtex2. Count on less than 200 ps, perhaps even less than 100 ps. One obvious drawback to this suggestion of using 350 MHz clock for the many slower places, is increased power consumption. Peter Alfke > >Article: 35995
Continuing, The max skew in a 2V6000 is 200 ps, but as Peter points out, smaller devices have smaller skew in relation to their size. A 2V1000 is ~ .4 times less skew (~85 ps) One can guess at the dimension ratio by examining the X by Y size of the CLB's (96x88 vs 40x32, or .41 times less skew). Actual measurements confirms these values, but we tend to use the largest value in the data sheet, rather than specify eveything per device. The per device information is reserved for the speeds files when appropriate. In Virtex II we actually turn off parts of the clock tree that are unused, so there is a major power savings if the 350 MHz clock tree is constrained to a local area (perhaps using RLOC's). If all CLB's and IOB's can be localized, the power savings is quite real. If everything must run at 350 MHz, you better invest in a serious heatsinking solution! Use of clock enable saves less power, as everything is switching right up, and including logic, into the heart of the CLB. Austin Peter Alfke wrote: > Here are some thoughts: > > hamish@cloud.net.au wrote: > > > In a design I'm working on at the moment, I have new data on every > > rising edge of a 175 MHz clock and I need to transfer it to > > be synchronous to a 350 MHz clock. No uncertainty in the > > 350 MHz data is acceptable. > > > > To generate the clocks, I have an external 350 MHz source, > > and I'm using the CLK0 and CLKDV (divided by 2) outputs on > > a DCM. I'm using a Xilinx 2V6000-5. > > > > I have global buffers for each clock, but I expect there > > will be some skew between the clocks, since the 350 MHz > > clock is lightly loaded (200-300 FFs), compared to the > > 175 MHz clock (2500 FFs). So I might violate the hold > > time on the 350 MHz FFs if I'm not careful. > > I think the loading ( if it has any effect at all ) would help you: It would > move the 175 MHz data a little later. When the source clock is late and the > receive clock is early, you avoid all hold time issues, but you lose > performance. So, no hold-time issues here. > > I would run everything off the 350 MHz clock and generate a 175 MHz clock enable > off that clock, and use it for the "175 MHz" portion. > Global clock distribution skew has always been good, but is very good in > Virtex2. Count on less than 200 ps, perhaps even less than 100 ps. > > One obvious drawback to this suggestion of using 350 MHz clock for the many > slower places, is increased power consumption. > > Peter Alfke > > > > >Article: 35996
> could anybody say me where to find a simple free GAL (especially 16V8) > compiler for MS-DOS? > search for "easyAbel", might be its still somewhere around on the web or ask on the university Its simple and works fine up to 22v10 Greetings, Bertram -- Bertram Geiger, bgeiger@aon.at HTL Bulme Graz-Goesting - AUSTRIAArticle: 35997
At 100 MHz, why not use a synchronous counter and let the synthesizer take
care of the construction? It should use the carry chain. A 32 bit straight
synchronous counter should work at well over 100 MHz in virtexII. For bigger
counts, you can pipeline the carries between counter segments, or connect the
carry outs from segments into a carry look ahead scheme. If you need several
hundred MHz input, then it may make sense to use a prescaler with a ripple
carry, but not for a 100 MHz count.
Theron Hicks wrote:
> Got one for you that works nicely in an FPGA (virtex2). It is brute force
> but it works OK. Note that the counter is strictly quasi-asynchrounous.
> You could code the last few bits as a synchnous counter for a little
> better behavior. I am using this with a 100MHz counter as an input. It
> gives a reset for the DCM at roughly 0.6 seconds if I recall correctly.
>
> ma--
--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: 35998
I know of no source for the old sw. You might find someone with a used copy,
but you'll have to make sure you get the dongle, and a valid license file.
I'm pretty sure the license files from back then did not expire, but you
might check to make sure. I'm not sure what use these parts would be now:
They are feature poor compared with new devices, consume considerably more
power, are orphaned from both tools ans support points of view, and will
likely not teach you much as far as using modern FPGAs go. It may cost you
less to pick up an eval board with a current device on it, when you consider
the time and effort of finding and then getting tools to run for these old
parts. It is also worth noting that the software for the 2000 series is DOS
based. IIRC, the 2000 series was dropped from the tools about the same time
the windows (3.1) version of XACT came out. XACT did not work very well
under win95. You will probably have to resurrect an old operating system,
and perhaps even an old machine (I suspect the new machines may be too fast
to work the dongle properly, that was a problem with some faster machines
back then) jsut to get the software up an running. Sounds like an awful lot
of effort for a very questionable return to me.
Peter Heitzer wrote:
> Hello folks,
> I have a few Xilinx XC2018 chips (5V version) and wonder if there was
> a cheap way of programming those chips.
> I know that the XC2000 series is now obsolete an no newer software
> supports it. But perhaps there is some old software for free download
> in the net.
>
> Thanks in advance,
> Peter
>
> --
> Dipl.-Inform. Peter Heitzer, phone +49 941 943 4850, fax +49 941 943 4857
> mail Peter.Heitzer@rz.uni-regensburg.de
--
--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: 35999Dean, Yes, if it's controlling the chain like this, then no contention will occur. All you have to do now is write a JTAG controller <g>. Mike
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