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
If I use two DLL's to generate a x4 clock such that the rising edges of the x1 and x4 clocks align, and have the x1 and x4 clks on global clocks buffers, can I go from one clock domain to the other with just a flip flop? In other words, are the rising edges aligned close enough so I don't have to worry about metastability and other nasty things? DanArticle: 36301
Hi , is there a market-place where a can buy and sell FPGAs (erroneus purchase or unused parts) ? T.Article: 36302
Hello, I would like offer to you two useful links: http://archives.e-insite.net/archives/ednmag/reg/1997/081597/17di_01.htm http://www.google.com/search?hl=en&q=vhdl+%22divide+by%22+%2250%25+duty%22 --IgorArticle: 36306
We've used a heat-sink in the past that was a bit larger than the
package, with holes drilled in the four corners so that it got bolted to
the PWB over the FPGA. I don't know who made the heatsink. It may have
been a custom part. That was for a flight qualified box. Most of the
lab environment stuff, we just make sure there is enough forced air over
the part, and occasionally we use a glue on in the few cases where it is
needed.
Pete Fraser wrote:
> I am involved in a design using a 2V1000 in the FF896 package.
>
> We are allowing for a passive heatsink. Any recommendations?
>
> This is for a shipboard application, so there will be vibration
> and a hostile environment, so I'd like to use something
> with positive retention (rather than two-sided sticky).
>
> Thanks.
--
--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: 36307
The floorplanner won't help with I/O timing if you have the I/Os
registered in the IOB. You should, however check to verify that the
registers did go into all the IOBs on your critical path. There are a
number of conditions that have to be met for the register to go into the
IOB; miss one of them, and the register goes into the core getting you a
longer input setup and output clk to Q. Set the output ffs to a faster
slew rate, and set the input ones to no delay. Use the DLL to keep the
internal clock phase aligned with your external clock (that'll reduce the
times). 7 and 11 should be OK with registered I/O in a spartanII-5. You
probably won't reach those numbers if you don't use the register in the
I/O
Kevin Brace wrote:
> I will like to know effective is the Floorplanner software that comes
> with Xilinx ISE series of software.
> The design I am working on is a PCI IP core which Tsu (setup time) has
> to be less than 7ns, and Tval (clock to output valid) has to be less
> than 11ns.
> Currently, the worst Tsu I have is 12.974ns, and the worst Tval I have
> is 16.594ns.
> I synthesized my design with XST Verilog, and I used only automatic
> P&R with user constraints (Pad to Setup = 7ns, Clock to Pad = 11ns).
> The software I am currently using is ISE WebPack 4.1.
> Is it realistic to expect that I will get Tsu and Tval within 7ns and
> 11ns respectively if I use the Floorplanner?
> Will reducing fan-out during synthesis help?
> If so, what number (default is 100) is appropriate?
> Are there any other helpful synthesis/P&R options that will improve
> the timings?
> The part I am using is Spartan-II 150K system gate part speed grade -5
> which comes with Insight Electronics Spartan-II PCI Development Kit,
> so the use of speed grade -6 is not an option.
> I already synthesized my design with the speed grade -6, and that
> improved the worst timings by 20%, but that still wasn't enough by
> about 15%.
> I already tried "Pack I/O Registers/Latches into IOBs" in MAP.
> If I packed IOBs for input by selecting "For Inputs Only" or "For
> Inputs or Outputs", it created a positive hold time, a no-no in PCI
> (hold time has to be 0ns in PCI).
> Selecting "For Outputs Only" didn't seem to improve Tval that much.
> If the Floorplanner is going to help, what kinds of strategies should
> I use to hand place the design?
>
> Regards,
>
> Kevin Brace (don't respond to me directly, respond within the
> newsgroup)
--
--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: 36308Peter Alfke <peter.alfke@xilinx.com> wrote in message news:3BE1A3ED.36D2DA0A@xilinx.com... >Xilinx is officially quite guarded about mentioning and explaining the next generation Virtex-II devices ( although we are >obviously quite far along ). >But here is a brand-new magazine article that puts the Xilinx and Altera efforts in perspective. >Read at you own peril, and please don't accuse me of "Marketing"... >http://www.eet.com/story/OEG20011031S0025 > >Peter Alfke Peter, I appologize if my comments seemed to be accusing you of Marketing. If you re-read my mesage, I think you'll see that I was only claiming that Philip's comments that Xilinx is the right way to go because they bought someone's IP for their SerDes design was sort of weak. I mean, Xilinx may be the right way to go for David's design, but making the decision because an unannounced device is going to use technology based on someone else's IP (that hasn't previously been used with Xilinx's processes or previously integrated into Xilinx's FPGA designs) isn't a very strong arguement. One other comment: the EETime story is a good reference for discussing embedded processors, but the only mention of SerDes in the whole article was: "The Virtex 2 Pro is designed to handle 3.125-Gbit/second serial I/O and can be scaled for 10 Gbits/s, said Sevcik." We can discuss processors embedded in programmable logic devices in another thread if you wish. -Pete- Philip Freidin <philip@fliptronics.com> wrote in message news:o2juttcq2pc8nbfkf6722a4qcjahb6bgv2@4ax.com... > The Xilinx Virtex-2 is the underlying FPGA for their upcomming > Virtex-2 Pro parts that they say will have the 3.125GBaud SerDes > blocks on it. Xilinx press releases and presentations say that the > underlying SerDes technology is the Conexant SerDes that > they have licensed. I believe that Conexant SerDes technology > has been spun out into a separate company named MindSpeed. > > Given this, I would recommend doing your design with Xilinx Virtex-2 > and the MindSpeed/Conexant SerDes, and use the integrated > product when it becomes available. > > You can probably get more info on this by contacting your local > Xilinx sales office. > > Philip Freidin > > On 30 Oct 2001 14:25:55 -0800, dvdprsns36@hotmail.com (David) wrote: > >I'm looking for a FPGA that will b e used with a SERDES > >device. Originally I was looking at an XCV2000 or APEX1000 > >along with a SERDES device (most likely TI or Conexant > >3.125Gbps) but I've heard that Xilinx is coming out with a > >FPGA that will have high-speed SERDES functionality built in. > >Does anyone know what the story is with that? Would you > >recommend that as a better/cheaper (how much?) alternative? > > > > > >Dave > > Philip Freidin > FliptronicsArticle: 36309
who knows how to detect both edges (rising and falling edge) of clock in verilog? always @(posedge clk or negedge clk) counter <= counter + 1; //only count 1, not 2 Thanks.Article: 36311
The count 0,1,2,0,1,2... is simple, it is achieved with a 2 bit shift register. The
50% duty cycle divide by 3 can't be done entirely synchronously. You'll have to take
either the of the count bits, feed it to a flip-flop clocked on the opposite clock
edge and logically OR it with the the delayed rendition. TO get the 50% duty cycle,
the output clock has to toggle alternately on rising and falling edges. The way to
do that and still have a synchronous design is to OR overlapping clock pulses
synchronized to opposite clock phases.
signal cnt:std_logic_vector(1 downto 0);
signal cnt0_fe:std_logic;
begin
process(clk)
begin
if clk'event and clk='1' then
cnt<= cnt(0) & not(cnt(0) or cnt(1));
end if;
end process;
process(clk)
begin
if clk'event and clk='0' then
cnt0_fe<=cnt(0);
end if;
end process;
count_output<=cnt;
clk33<=cnt(0) or cnt0_fe;
end;
Banana wrote:
> Good Morning,
> I'm trying to produce a counter that count 0 , 1 , 2 at a rate of
> 99MHz and at the same time to use it to produce a clock of 33MHz, the
> clock I need must be symmetrical so I can't use a simple loop counter.
> Have you any idea on how I could arrange it in vhdl, following there
> is my code but it seems to be not synthesizable, thanks for your help
> ...
>
> Banana
>
> library IEEE;
> use IEEE.std_logic_1164.all;
> use IEEE.std_logic_unsigned.all;
>
> entity counter_divider_3 is
> port (
> clk : in STD_LOGIC;
> reset : in STD_LOGIC;
> count_3 : out STD_LOGIC_VECTOR (2 downto 0);
> clk_div_3 : out STD_LOGIC
> );
> end counter_divider_3;
>
> architecture counter_divider_3_arch of counter_divider_3 is
> begin
> process (clk, reset)
> variable count_3_internal : STD_LOGIC_VECTOR (2 downto 0);
> variable clk_div_3_internal : std_logic;
> begin
> if reset = '1'
> then
> count_3_internal := "000";
> elsif falling_edge(clk)
> then
> if (count_3_internal = "010")
> then -- si deve riazzerare il contatore
> count_3_internal := "000";
> clk_div_3_internal := '0' ;
> else
> count_3_internal := count_3_internal + 1;
> end if;
> elsif count_3_internal = "001"
> then
> clk_div_3_internal := '1' ;
> end if ;
> count_3 <= count_3_internal ;
> clk_div_3 <= clk_div_3_internal ;
> end process;
>
> end counter_divider_3_arch;
--
--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: 36312
You need to be careful with The FMAP component with synthesis. If it is used as is in the library the synthesis
either takes it out (no outputs) or complains about multiple drivers on a net (I don't remember which it was now).
The FMAP really needs an INOUT for the O pin, which it does not have in the library. If you change it, then it
doesn't match the primitive so it fails in the mapper. Hopefully this has changed, but as of about 2 years ago we
gave up on the FMAP primitive with synplicity because it would not synthesize. That said, you can encapsulate a
component with the synplicity xc_map attribute to get the same effect.
Brian Philofsky wrote:
> You do have low-level access to the Spartan/XL resources via instantiation as you do with all Xilinx devices
> however it is a bit different than with the Spartan-II and newer families. In order to specify the logic in a
> LUT, you must first describe the logic contents in the LUT, typically by specifying logic gate(s) with up to four
> inputs and one output. You then "entomb" this logic by instantiating an FMAP component around the logic. This
> tells the mapper that you want this logic in a LUT. Look at FMAP in the Libraries guide for more details about
> this.
>
> In order to specify the carry chain, you must instantiate the proper CY4_xx component that tells the tools what
> function you want to program into the carry structure. There is an entire chapter devoted to this in the
> Libraries Guide. Check out chapter 12 for more details on how this works.
>
> You can access the fore mentioned manuals on-line if you wish at http://support.xilinx.com/support/library.htm
>
> Good luck,
>
> -- Brian
>
> Peter Alfke wrote:
>
> > Spartan is based on XC4000, and SpartanXL is based on XC4000XL, and all of them have the same carry structure.
> > Take a look at the XC4000 and XC4000XL documentation, it may be clearer. But it describes the identical
> > architecture.
> >
> > Peter Alfke
> > ====================================
> > newman wrote:
> >
> > > It looked to me that the Spartan CLB does not include any
> > > dedicated carry logic. Each LUT has one output, so
> > > at least two LUT's would be required per bit... one to
> > > generate the cout bit, and one to generate the pc bit.
> > >
> > > Have you tried looking at the design after P&R with the
> > > FPGA editor? This may shed more light on the situation.
> > >
> > > Newman
> > >
> > > "Tim Boescke" <t.boescke@tu-harburg.de> wrote in message news:<9rvn5u$10hndj$1@ID-107613.news.dfncis.de>...
> > > > I am currently trying to synthesize a loadable
> > > > accumulator with synopsis. The target architecture
> > > > is a spartan. (not 2)
> > > >
> > > > In my opinion the code below should fit into one 4 LUT
> > > > per bit. (inputs to each 4 LUT: pc, cin, load, inp)
> > > > However, after synthesis the design requires no less
> > > > than 16 4-luts.
> > > >
> > > > Did I miss something ? Is there any way to infer a
> > > > combined add/load structure ? I already tried
> > > > lots of combinations without success and unfortunately
> > > > it seems that the xilinx libs dont allow direct
> > > > access to the LUTs and the carry logic for spartan..
> > > > (They do for spartan 2)
> > > >
> > > > ------------------------------------------------------
> > > >
> > > > architecture synth of counter is
> > > > signal pc: std_logic_vector(7 downto 0);
> > > > begin
> > > > process(clk)
> > > > begin
> > > > if (res ='1') then
> > > > pc <= "00000000";
> > > > elsif rising_edge(clk) then
> > > > if (load = '1') then
> > > > pc <= inp;
> > > > else
> > > > pc <= pc + inp;
> > > > end if;
> > > > end if;
> > > > end process;
> > > >
> > > > outp <= pc;
> > > > end synth;
--
--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: 36313
You are apparently traversing two chains in this particular path. The
data sheet performance is based on a single carry chain, which you'll see
as the Topcyf or g to get on, + N-2 * Tbyp for each bit pair in the
chain, plus a Tciny or Tcisu for the time to get off the chain. To
achieve the data sheet performance, you'll need to use the clb registers
on the output in the same slice as the carry chain, AND you'll have to
register all the inputs in an adjacent slice with no other loads on the
registered inputs.
khtsoi@pc90026.cse.cuhk.edu.hk wrote:
> Hi,
>
> I have checked the datasheet of Xilinx that the speed of an adder
> in xv1000e-6 (1.8v) is very fast:
> 16 bit 4.x ns
> 64 bit 6.x ns
> But the timing analysizer report something different:
>
> CLB_R27C37.S1.G3 net (fanout=1) 2.084R jk<1>
> CLB_R27C37.S1.COUT Topcyg 1.000R j<0>
> ijk_add/C2/C3/C0
> ijk_add/C2/C3/C2
> CLB_R26C37.S1.CIN net (fanout=1) 0.000R ijk_add/C2/C3/C2/O
> CLB_R26C37.S1.COUT Tbyp 0.149R j<2>
> ijk_add/C2/C4/C2
> ijk_add/C2/C5/C2
> CLB_R25C37.S1.CIN net (fanout=1) 0.000R ijk_add/C2/C5/C2/O
> CLB_R25C37.S1.Y Tciny 0.677R j<4>
> ijk_add/C2/C6/C2
> ijk_add/C2/C7/C1
> CLB_R30C32.S0.F4 net (fanout=2) 1.758R j<5>
> CLB_R30C32.S0.X Tilo 0.468R C8/N49
> C741
>
> where Tbyp is the Cin to Cout speed, this is quite fast
> but the Topcyg is the time for Ginput to Cout. This should be
> the carryout generated in the upper LUT. If this is the delay,
> 64 bit adder will never be 6ns but 64 ns at least. But why the
> report just count one of it but not all in the path?
>
> what I do is:
>
> jk <= j + k;
> ijk <= jk + i;
>
> help me pls
>
> ---- Brittle
--
--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: 36314
There was, as I recall, information on the serdes in the VIrtexII rollout
roadshow last February. So it would appear that it has been announced. The
details, IIRC weren't real complete, but as I recall, they were supposed to be
coming out pretty soon by the presented data.
Peter Ormsby wrote:
> Peter Alfke <peter.alfke@xilinx.com> wrote in message
> news:3BE1A3ED.36D2DA0A@xilinx.com...
> >Xilinx is officially quite guarded about mentioning and explaining the next
> generation Virtex-II devices ( although we are >obviously quite far along ).
> >But here is a brand-new magazine article that puts the Xilinx and Altera
> efforts in perspective.
> >Read at you own peril, and please don't accuse me of "Marketing"...
> >http://www.eet.com/story/OEG20011031S0025
> >
> >Peter Alfke
>
> Peter,
>
> I appologize if my comments seemed to be accusing you of Marketing. If you
> re-read my mesage, I think you'll see that I was only claiming that Philip's
> comments that Xilinx is the right way to go because they bought someone's IP
> for their SerDes design was sort of weak. I mean, Xilinx may be the right
> way to go for David's design, but making the decision because an unannounced
> device is going to use technology based on someone else's IP (that hasn't
> previously been used with Xilinx's processes or previously integrated into
> Xilinx's FPGA designs) isn't a very strong arguement.
>
> One other comment: the EETime story is a good reference for discussing
> embedded processors, but the only mention of SerDes in the whole article
> was:
>
> "The Virtex 2 Pro is designed to handle 3.125-Gbit/second serial I/O and can
> be scaled for 10 Gbits/s, said Sevcik."
>
> We can discuss processors embedded in programmable logic devices in another
> thread if you wish.
>
> -Pete-
>
> Philip Freidin <philip@fliptronics.com> wrote in message
> news:o2juttcq2pc8nbfkf6722a4qcjahb6bgv2@4ax.com...
> > The Xilinx Virtex-2 is the underlying FPGA for their upcomming
> > Virtex-2 Pro parts that they say will have the 3.125GBaud SerDes
> > blocks on it. Xilinx press releases and presentations say that the
> > underlying SerDes technology is the Conexant SerDes that
> > they have licensed. I believe that Conexant SerDes technology
> > has been spun out into a separate company named MindSpeed.
> >
> > Given this, I would recommend doing your design with Xilinx Virtex-2
> > and the MindSpeed/Conexant SerDes, and use the integrated
> > product when it becomes available.
> >
> > You can probably get more info on this by contacting your local
> > Xilinx sales office.
> >
> > Philip Freidin
> >
> > On 30 Oct 2001 14:25:55 -0800, dvdprsns36@hotmail.com (David) wrote:
> > >I'm looking for a FPGA that will b e used with a SERDES
> > >device. Originally I was looking at an XCV2000 or APEX1000
> > >along with a SERDES device (most likely TI or Conexant
> > >3.125Gbps) but I've heard that Xilinx is coming out with a
> > >FPGA that will have high-speed SERDES functionality built in.
> > >Does anyone know what the story is with that? Would you
> > >recommend that as a better/cheaper (how much?) alternative?
> > >
> > >
> > >Dave
> >
> > Philip Freidin
> > Fliptronics
--
--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: 36315Ray Andraka <ray@andraka.com> wrote: > You are apparently traversing two chains in this particular path. The > data sheet performance is based on a single carry chain, which you'll see That's the real problem. I just don't know how to tell the tools not to break the chain (Synopsys Design Compiler & Xilinx Alliance 3.1i). Must I use core gen? > as the Topcyf or g to get on, + N-2 * Tbyp for each bit pair in the > chain, plus a Tciny or Tcisu for the time to get off the chain. To > achieve the data sheet performance, you'll need to use the clb registers > on the output in the same slice as the carry chain, AND you'll have to > register all the inputs in an adjacent slice with no other loads on the > registered inputs. Is that mean I cannot drive other devices by the adder outputs directly? Then how can I implement i+j+k in one clock cycle? Anyway, thanks a lot! ---- BrittleArticle: 36316
Ray Andraka wrote: > The floorplanner won't help with I/O timing if you have the I/Os > registered in the IOB. You should, however check to verify that the > registers did go into all the IOBs on your critical path. There are a > number of conditions that have to be met for the register to go into the > IOB; miss one of them, and the register goes into the core getting you a > longer input setup and output clk to Q. Set the output ffs to a faster > slew rate, and set the input ones to no delay. Use the DLL to keep the > internal clock phase aligned with your external clock (that'll reduce the > times). 7 and 11 should be OK with registered I/O in a spartanII-5. You > probably won't reach those numbers if you don't use the register in the > I/O > > Kevin Brace wrote: > > All Ray's suggestions are correct 'cept the DLL one. Whether or not you can use this on the PCI clock depends on whether you are going to follow the PCI spec strictly and allow the clock min frequency to be 0. Even if your architecture doesn't do PCI clock stopping the DLL imposes a min freq. limit (25MHz for V-E ?). PCI timing posed a real problem for the PCI i/f I did ~3 years ago in an XCV300-4. Tco was not a problem once I'd persuaded Synplify not to mess up the IOB packing rules. Tsu was a whole other story since the PCI protocols make it very difficult to use registered inputs. With a lot of sweat I managed to get Tsu down to ~7.5-8 nsec with the automatic tools. Ray will remember that this was in the early Virtex days when Xilinx's attitude was ``FloorPlanner? Virtex doesn't need it''. On top of this the device had to live in a system where the clock was stepped up from 8, 24, 32MHz and used spread spectrum EMI reduction. I was fortunate in that we were working in a ``closed'' PCI universe with a limited range of other PCI masters and a short bus so the 1nsec error didn't matter. I've since figured out a way to use registered inputs (I think) but with Virtex-E -6 I don't yet need it for 33MHz PCI.Article: 36317
Hi, I have just learnt to use RLOC to place the components closer inside a larger component. But how can I forece these larger components to be closer by RLOC. I mean, the component created by myself will not have RLOC attribute and/or other attributes like the LUT4, FDC, etc. Neigther of them will be a regular block (e.g. not a rectangular box). How to instruct the par tools to place them in certain, fixed place? (Using VHDL only!) Thanks in advance! ---- BrittleArticle: 36318
Let me re-focus what my inquiry is about, not CPU speeds
but specific methodology for guided design ......
The guide option relies on 'ncd' files from a previous P&R run. After I do
my 1st, initial P&R, I notice that there are 4 such files in the
xproj/ver1/rev1 directory:
guide.ncd
map.ncd
guidemap.ncd
my_design_top.ncd
Question 1: One app note talks of using the template manager to enable "-gf"
and "-gm" switches in the map program. The "-gf" switch specifies the guide
ncd file. Which file should I point to w/ the -gf switch: guide.ncd,
map.ncd, guidemap.ncd & my_design_top.ncd ?
Question 2: Yet, under the Design Manager's "Design -> Set Guide File(s)
...."
menu, there is a dialog box where I can specify 2 (ncd) files:
"Guide File"
"Mapping Guide File"
What's the difference between the two?
Do we use one or the other or both?
Which file (guide.ncd, map.ncd, guidemap.ncd or my_design_top.ncd)
goes with which dialog box entry?
Does this dialog box supplement, override, or ??? the template manager
"-gf" and "-gm" switch settings mentioned in Question 1?
I've read XAPP 164, but it does not have answers to these questions.
Is there another Xilinx document that does?
Ray Andraka wrote:
> That may be a comparison of ducks to oranges (apples would be closer, at
> least there they are both fruits). How close your constraints are set to
> the delay with no routing has a big bearing on the PAR time. If your
> design is big enough that the computer has to start paging, your compile
> times go to hell in a handbasket as well. Also, if parts of the design
> are floorplanned, you can reduce the run times considerably.
>
> chris wrote:
>
> > the 6 hour PAR time sounds a little long. i am using the XC2V1000
> > right now in a design of mostly control logic and is 98% full (really
> > bad, i know). the PAR time is about 45 minutes with my P4, 1.7GHz
> > computer. it also has 1 gigabyte of RAMBUS which i believe greatly
> > improves the speed. by the way, the XC2V1000 is probably equivalent to
> > something around a XCV300 in terms of usable logic gates, which means
> > that it might take more time to PAR a large XCV600 design.
> > if you are using a pentium4 chip, you might want to consider adding
> > RAMBUS to the max amount of supported memory, if you haven't already.
> > the savings in time i get versus my regular work computer is
> > tremendous.
> > chris
>
> --
> --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
--
==============================
William Lenihan
lenihan3weNOSPAM@earthlink.net
.... remove "NOSPAM" when replying
==============================
Article: 36320khtsoi@cse.cuhk.edu.hk wrote: > Hi, > I have just learnt to use RLOC to place the components closer inside a larger > component. But how can I forece these larger components to be closer by RLOC. > I mean, the component created by myself will not have RLOC attribute and/or > other attributes like the LUT4, FDC, etc. Neigther of them will be a regular > block (e.g. not a rectangular box). How to instruct the par tools to place > them in certain, fixed place? (Using VHDL only!) Thanks in advance! > ---- Brittle Actually I want to use the ADD8 macro in VirtexE. But the gndbuild tool always report error not finding the ADD8 component. It can find something like LUT4 but no macro can be used. I search the alliance3.1i directory and cannot find any NMC file. How to use the macro like ADD8 or must I write it by myself? ---- BrittleArticle: 36321
William Lenihan wrote: > Let me re-focus what my inquiry is about, not CPU speeds > but specific methodology for guided design ...... > > The guide option relies on 'ncd' files from a previous P&R run. After I do > my 1st, initial P&R, I notice that there are 4 such files in the > xproj/ver1/rev1 directory: > > guide.ncd > map.ncd > guidemap.ncd > my_design_top.ncd > > Question 1: One app note talks of using the template manager to enable "-gf" > and "-gm" switches in the map program. The "-gf" switch specifies the guide > ncd file. Which file should I point to w/ the -gf switch: guide.ncd, > map.ncd, guidemap.ncd & my_design_top.ncd ? > > Question 2: Yet, under the Design Manager's "Design -> Set Guide File(s) > ...." > menu, there is a dialog box where I can specify 2 (ncd) files: > > "Guide File" > "Mapping Guide File" > > What's the difference between the two? > Do we use one or the other or both? > Which file (guide.ncd, map.ncd, guidemap.ncd or my_design_top.ncd) > goes with which dialog box entry? > Does this dialog box supplement, override, or ??? the template manager > "-gf" and "-gm" switch settings mentioned in Question 1? > > I've read XAPP 164, but it does not have answers to these questions. > Is there another Xilinx document that does? > I would suggest that the first thing you do, if you haven't already, is to read the sections on guided mapping and guided PAR in the ``Development System Reference Guide''. Studying the full set of command line switches would also most likely be useful. Second I would guess that guidemap.ncd is the one for MAP and guide.ncd is the one for PAR - you could probably confirm this by looking at the timestamps. Note also that guided MAP uses the previous .ngm file as well; this isn't specified explicitly but it uses the guide file name with the .ngm extension. So there should be a guidemap.ngm file as well. MAP *can* go guided without the .ngm but will issue a warning. Finally (hobby-horse time) I have to say that once you're using the tools at this - more advanced - level its a lot easier to get the results you want from the command line than the GUI. Personally my general rule is that I'll use the GUI for fast-cut one-off experimentation [or when I'm just too lazy to setup a special makefile]. As soon as I need repeatability or the ability to re-build something I've archived then its time to go command-line+makefile. Even under NT this is pretty easy to setup once you've installed all the Cygwin stuff..Article: 36322
dfx2001 wrote:
> who knows how to detect both edges (rising and falling edge) of clock in
> verilog?
>
> always @(posedge clk or negedge clk)
> counter <= counter + 1; //only count 1, not 2
>
> Thanks.
An ``always'' block is triggered when any thing in the sensitivity list
changes - the bit between the `(' and `)'. So you need:
always @(clk)
....
If you try to synthesise this you will get a latch & not the FFs you
probably want.
Article: 36323Hi, We are using a Altera University Program UP1 Board. We would like to program the MAX7128S in such a way that we can use an external (low frequency) clocksignal. The MAXPLUS II software seems to allow only the allocation of the pins 2 or 83 to a clocksignal. Pin 83 is connected to the on-board 25.175MHz clockgenerator. What are we supposed to do when we want to use an external clock? Rene DoesburgArticle: 36324
hi....
can someone help with understanding the mercury architecture
problem from my previos message....
thanks in advance...
Ciao,
nitin.
ndeshmukh@yahoo.com (nitin) wrote in message news:<7685aa5c.0111032240.552091fe@posting.google.com>...
> Hi...
>
> Well actually i was also pondering over the Mercury Architecture
> and questions do come to mind. Well i still can't understand why not 5
> top LEs drive to the right and 5 bottom LEs to the left or something
> like that. And this odd and evn LEs in a LAB driving different
> resources carries on even to the RAPID LAB INTERCONNCT, and also the
> LEAP LINES... why...? does this give some bigger region os a crudely
> defined cluster with faster routing within it? If yes then what
> motivates that kind of descision and what sort of shape & size does
> that crudely defined cluster have...?
>
> Well i aslo spotted an intresting thing in Mercury architecture...
> Uptil now horizontal rsouces used to drive vertical ones ad vertical
> ones used to drive horizontal ones. But in Mercury we see Leap lines
> driving columns, columns driving columns, and priority comlumns
> driving columns as well as priority columns.
> Well first of all the question that comes to mind is the when a
> column drives a column is it driving a segment within itself...? I
> certainly hope not. Cuse that does not make too much sense to me. But
> then is it drives adjacent columns then which ones? to the right or to
> the left or both?
>
> And what motivates such a decision? Well i hope some one has the
> answers...
>
> Ciao,
> Nitin.
>
> Ray Andraka <ray@andraka.com> wrote in message news:<3BE30B9B.FD358F22@andraka.com>...
> > Right, but the real reason is to provide fast connections for logic using the
> > carry/cascade chains. Those chains run across the LE's in a LAB, which prevents
> > the LE's from connecting to another LE in the same LAB. The inter-lab connects
> > give you a way to connect arithmetic logic with a reasonable delay.
> >
> > Steve Fair wrote:
> >
> > > Digari -
> > >
> > > It's all about speed . . .
> > >
> > > The interleaving of the labs gives the router more flexibility. Each lab
> > > has it's own local routes, which is the fastest non-dedicated route (as
> > > opposed to carry or cascade chains). If all the logic between two flops can
> > > fit into a lab, you will achieve the best performance possible. If the
> > > logic can't fit into the lab, you go to a megalab route in the apex II
> > > architecture, which adds delay AND uses another routing resource. By
> > > interleaving the labs, an LE can be connected to many more LE's for making
> > > those fast, local connections. The area expense isn't that great (a single
> > > line and mux to the next lab's local interconnect), so it's a very efficient
> > > way to increase routing and performance. Put another way, a lab goes from
> > > having 9 possible local connections to 19 with very little overhead. With
> > > the further interleaving available (remember the left & right drives), you
> > > can do some pretty deep equations with very small routing delays.
> > >
> > > Hope that helps.
> > >
> > > Steve
> > >
> > > "digari" <digari@dacafe.com> wrote in message
> > > news:e0855517.0111010034.375d9328@posting.google.com...
> > > > Why there is interleaved routing from an LE to adjecent LLIs in
> > > > Mercury and ApexII architectures.
> > > >
> > > > "APEX II devices use an interleaved LAB structure, so that each LAB
> > > > can
> > > > drive two local interconnect areas. Every other LE drives to either
> > > > the left
> > > > or right local interconnect area, alternating by LE."
> > > >
> > > > Can anyone shed some light on the alternate routing structure of LEs
> > > > within a LAB.
> >
> > --
> > --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
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