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
You are correct. I've forwarded it to our compiler group to see what they say about it. Allan Herriman wrote: > On 22 Mar 2002 22:01:27 -0800, brimdavis@aol.com (Brian Davis) wrote: > > >> ts_mux <= a_in when sel = "00" else 'Z'; >> ts_mux <= b_in when sel = "01" else 'Z'; >> ts_mux <= c_in when sel = "10" else 'Z'; >> >> process >> wait until rising_edge(clk); >> sig1 <= ts_mux; >> sig2 <= ts_mux AND '1'; >> end process; >> > > > I would add to this: > > sig3 <= to_X01(ts_mux); > > This should *never* allow a tristate to propagate through a flip flop, > regardless of any tool settings. > (Ken, can you confirm this please?) > > Regards, > Allan. >Article: 41276
Its a right pain isn't it ! Spectrum has been doing this since 2000 1d I think, and it caught me out. There is a paramter somewhere which is approx 'set attribute do not insert global clock buffers'. Search the documentation for exact incantation. However, I think you have to then manually instantiate BUFG's on your global clocks and IBUF's for the others. Cheers, MikeJ "Niv" <niv@ntlworld.com> wrote in message news:9HXm8.1321$QR.101429@news11-gui.server.ntli.net... > I have a design with more than 4 clocks, the Virtex max., (but some are very > slow, < 1MHz). > > LeoSpec insists on putting BUFG's on all the clocks, which causes Xilinx PAR > to throw a wobbler. > > The design now has a 40MHz master clk into a CLKDLL, which produces 2 > internal clocks with BUFG's, which is wanted, and 4 other clocks, only 2 of > which need BUFG's. The other 2 clocks are low freq. and low fanout. > > The old design worked fine with 6 external clks; LeoSpec just sorted it out > somehow; But now with 5 external clks, the master one to a DLL, it all goes > to pot! > > Anyone got any bright ideas please? > > i.e. How do I force some of my clocks NOT to use BUFG's & IBUFG's, just use > IBUF's instead? > > TIA, Niv. > >Article: 41277
Hi Paul, Yes, your diagram is correct. I have now tried terminating with Rt_high = Rt_low = 180R, as well as with Rt_high = 270R, Rt_low = 120R, but this does not solve the problem. What I cannot figure out is why this clock should affect the Spartan II JTAG interface in any way. At this stage the clock input to the Spartan II is simply connected to one of the GCLK inputs, and the chip is not configured, so I figure that it should not matter what the clock is doing! With regard to 5V tolerance, all of the devices are supposed to have 5V tolerant I/O's, including the Spartan II. Regards, Dean. Paul wrote: > In article <3C9ABB11.1030006@cs.waikato.ac.nz>, Dean Armstrong > <daa1@cs.waikato.ac.nz> wrote: > > >>Hi All, >> >>I have encountered a strange problem on a board we have designed. The >>board contains a Xilinx Spartan II XC2S200, two Xilinx XC95288XL CPLDs, >>and one Xilinx XC95144XL CPLD. >> >>There are three power supply voltages on the board: 2.5V for the Spartan >>II core, 3.3V for the CPLDs and the Spartan II I/O, and 5V for some RAM >>and ROM. >> >>There is a 19.6608MHz Crystal Oscillator Module running on the 5V rail, >>which provides a clock to the four Xilinx chips. This clock rings more >>than I would like, so I wish to terminate it using pads included in the >>design for this reason. >> >>Using information from the manufacturer I have established that the >>impedance of the clock trace is around 90 Ohms, so I terminated it to 5V >>and to ground, each with 180 Ohm resistors. >> >>When I do this, however, the JTAG test access port on the Spartan II >>appears to become unreliable - I am not able to configure the Spartan II >>via JTAG. >> >>I am using the Xilinx Parallel Cable III running using the 5V supply on >>the board. >> >>I use the IDCODE looping feature in the Xilinx iMPACT JTAG programmer >>software, and when the clock is terminated then this fails after a >>varying number of iterations (often between 200 and 8000). >> >>As soon as I remove the clock termination, this IDCODE looping is >>successful. >> >>One idea that was put to me was that the clock termination may be >>introducing noise into my 5V rail, which is affecting the Parallel Cable >>III. I tried decoupling this supply close to the Cable, and this had no >>effect. I also tried using an entirely seperate power supply for the >>Parallel Cable, and this also made no difference. >> >>I tried terminating just to Ground (ie. removing the resistor from the >>clock net to 5V). This seemed to make things better, but did not fix the >>problem completely. >> >>My 5V supply is actually ~4.72V. While this is within the +/-10% >>specified limits of all the chips that use it, it is outside the +/-5% >>specified limits of the crystal oscillator module. I cannot see how this >>could cause problems, because the JTAG interface has nothing to do with >>this clock. >> >>Does anyone have any ideas about what may be causing this, or what I can >>try to establish the cause? >> >>Kind regards, >>Dean Armstrong >>The University of Waikato >>New Zealand > > > I need a little clarification. This oscillator at 19.6608MHz is the > clock for the digital logic you have implemented - how is that related > electrically to the TCK clock that comes from the JTAG cable ? I assume > your mission mode clock is like [view in Courier Font...] > > +5V > | > Rt_high > | > osc-------------------------------| > 19M | | | | | > | | | | Rt_Low > Load Load Load Load | > Gnd > > > JTAG------------------------------- > TCK | | | | > | | | | > Load Load Load Load > > > In the figure above, the 19MHz osc probably doesn't have enough drive > strength, to drive a parallel termination (shown here as Thevenin > equivalent consisting of Rt_high and Rt_Low). I would try a partial > termination, which may reduce the ringing enough to make it work. > I.e. Aim for 180 ohms as the parallel equivalent and use a 360ohm > resistor to +5V anda 360ohm resistor to GND. > > This 19MHz interconnect also brings up another issue. Are the clock > inputs on the loads 5V tolerant ? I bet the device powered by 2.5V > isn't. > > Frequently, driver outputs, like this 19M oscillator, have different > high and low drive capability. You should adjust the strength of > Rt_high and Rt_low according to the low and high drive strength > of the oscillator. When I had to do this termination case once > (when another board in a system gave me a clock with no series > termination), I used markedly different values for Rt_high and > Rt_low, to help the driver at the source board make a better > logic one. You could use a lower value for Rt_Low, if the logic 1 > voltage looks too high. > > Now, consider if we were doing the design again... > > A device driving the JTAG line should have a slow edge rate. If it > does, then no termination resistor is necessary. Ideally, clocks > should be point to point, so for perfection you should use > > _____ > | | > | | > ___| |---Rseries------ Load > | | | > | | 244 | > |___| BUF |---Rseries------ Load > | | | > | | | > JTAG---------| |---Rseries------ Load > TCK | | | > | | | > ___| |---Rseries------ Load > | | > | | > ------ > > _____ > | | > | | > | |---Rseries------ Load > | | > | | > | * |---Rseries------ Load > | | > | | > Osc ---------| |---Rseries------ Load > 19M | | > | | > | |---Rseries------ Load > | | > ___| FB |---Rseries--- > | _____ | > | | > ----------------------- > > * = Cypress CY2305 or CY2308 zero delay buffer > > The reason a 74xx244 can be used for JTAG, is data is clocked in > on rising edge, and out on falling edge. This makes the timing > insensitive to delay, so a sloppy and cheap buffer can be used > and JTAG will work just fine. By using series damping resistors, > the edge rate can be as sharp as you want. > > For the 19M distribution, I am assuming you are being bold, and > are passing data using only rising edges. In this case, a zero > delay buffer can be used to deliver the clocks in phase, with > only a few hundred picoseconds of penalty on your hold time > budget. > > Paul > > P.S. Don't worry about the supply voltage :-)Article: 41278
Thanks for the ideas, I will try these. I do not however, understand why this would affect the ability to use the JTAG interface to the Spartan II. Regards, Dean. Peter Alfke wrote: > > Paul Burke wrote: > > >>Can your clock source and sink 28mA? Try isolating the termination with >>a capacitor of negligible impedance at 20MHz, say 10nF. Or try a 91 ohm >>resistor in series with the clock close to the oscillator. >> > > > Series termination at the source is great for single-destination signals. But > here there are 4 destinations, and the 50% voltage step can cause a lot of > trouble. > > But parallel termination at the far end with an RC combination ( 91 Ohm in > series with a few nF) to ground might be a good idea. > > Peter Alfke > >Article: 41279
Allan wrote:
>
>I would add to this:
>
> sig3 <= to_X01(ts_mux);
>
>This should *never* allow a tristate to propagate through
> a flip flop, regardless of any tool settings.
>
Thanks, I added that one to my test-case-in-progress.
sig1 <= ts_mux;
sig2 <= ts_mux AND '1';
sig3 <= to_X01(ts_mux);
Although both sig2 and sig3 resolve to 'X' in pre-synthesis
simulation, Synplify 7.0.3 builds a tristate on all three outputs
instead of just on sig1.
That is completely incorrect from any perspective, whether you
believe in Z-transport DFFs or not.
Test Case notes ( see code below):
Sig5 shows the tristate pushthough in action across a big shift
register, which requires pipelining the phantom enable to match.
Also see sig7, which shows the tristate pushthough affecting
some combinatorial logic described with a conditional assignment.
For a real chuckle:
- synthesize the test case below
- look at the synthesis results in the HDL Analyst RTL viewer
- uncomment the fourth driver on the tristate bus & resynthesize
- look at the synthesis results again
Improved workaround:
Although "to_X01" doesn't work in Synplify 7.0.3, you could write
the following and still be fairly portable if you always use this
resolved signal as the input to registers or other logic:
attribute syn_keep : boolean;
attribute syn_keep of ts_mux_resolved : signal is true;
.
.
ts_mux_resolved <= to_X01(ts_mux)
Other Notes:
I was going to try this test case with Synplify 7.1, but it doesn't
seem to be available on the website.
I spent a while last night searching for this switch in 7.0.3;
there seems to be no mention of this tristate pushthrough feature
in the 7.0.3 release notes or documentation.
thanks,
Brian
--
-- tt2.vhd
--
-- - demonstrates nasty side effects of tristate pushthrough,
-- which will unpredictably create tristates at output pins
--
-- - demonstrates improper implementation of the pushthrough feature
-- - signals that have 'X's in pre-synth RTL sim also incorrectly
-- suffer from tristate pushthrough
--
-- - tested with Synplicity 7.0.3, targeting Spartan-2
--
--
library ieee;
use ieee.std_logic_1164.all;
entity tt2 is
port
(
clk : in std_logic;
sel : in std_logic_vector( 1 downto 0 );
a_in : in std_logic;
b_in : in std_logic;
c_in : in std_logic;
d_in : in std_logic;
dummy : in std_logic;
sig1 : out std_logic;
sig2 : out std_logic;
sig3 : out std_logic;
sig4 : out std_logic;
sig5 : out std_logic;
sig6 : out std_logic;
sig7 : out std_logic;
sig8 : out std_logic
);
end tt2;
architecture arch1 of tt2 is
signal ts_mux : std_logic;
constant PIPE_MSB : natural := 17;
signal pipe : std_logic_vector(PIPE_MSB downto 0);
begin
--
-- build an not-fully-populated internal tristate mux
--
ts_mux <= a_in when sel = "00" else 'Z';
ts_mux <= b_in when sel = "01" else 'Z';
ts_mux <= c_in when sel = "10" else 'Z';
--
-- Need to comment out the last driver so tristate pushthrough
-- behavior appears. If the tristate mux is fully populated,
-- some of the output tristates vanish, as Synplify's analysis
-- of the enables concludes that the bus is always being driven
--
-- ts_mux <= d_in when sel = "11" else 'Z';
--
-- register the mux several ways
--
--
out_reg: process(clk)
begin
if rising_edge(clk) then
--
-- results w/7.0.3 : sig1 has a tristate output
-- MATCH
--
sig1 <= ts_mux;
--
-- results w/7.0.3 : sig2 has a tristate output
-- MISMATCH
-- AND is optimized away, although it should resolve signal
--
sig2 <= ts_mux AND '1';
--
-- results w/7.0.3 : sig3 has a tristate output
-- MISMATCH
-- resolution function is apparently ignored
--
sig3 <= to_X01(ts_mux);
--
-- results w/7.0.3 : sig4 has a normal output
-- MATCH
-- Synplify can't optimize this AND away, so it works
--
sig4 <= ts_mux AND dummy;
--
-- create a big shift register for the next two signals
--
pipe <= pipe(PIPE_MSB-1 downto 0) & ts_mux;
--
-- results w/7.0.3 : sig5 has a tristate output
-- MATCH
-- lots of enable pipelining
--
sig5 <= pipe(PIPE_MSB);
--
-- results w/7.0.3 : sig6 has a normal output
-- MATCH
--
sig6 <= pipe(PIPE_MSB) XOR pipe(7);
end if;
--
-- try a FF with reset
--
if dummy = '0' then
sig7 <= '0';
elsif rising_edge(clk) then
--
-- results w/7.0.3 : sig7 has a tristate output
-- MATCH
--
sig7 <= ts_mux;
end if;
end process;
--
-- this pushthrough feature also affects combinatorial logic
--
sig8 <= ts_mux when dummy = '0' else NOT ts_mux;
end arch1;
Article: 41280Hi, Kevin: I am not sure what kind of hobby project do you do? Do you have any facilities to fabricate them out? I tend to like making some mp3 player or motor control toys out of an FPGA chip but it seems impossible to make into hardware as it's a lot of money when converted to my currency. I am using ISE Webpack from Xilinx. Its really a great tool anyway. -- Best Regards, ----------------------------------------------------------------- Xu Qijun Engineer OKI Techno Centre (S) Pte Ltd Tel: 770-7049 Fax: 779-1621 Email: qijun@okigrp.com.sg "Kevin Brace" <ihatespam99kevinbraceusenet@ihatespam99hotmail.com> wrote in message news:a79cg2$orc$1@newsreader.mailgate.org... > As an active ISE WebPACK 4.1 user, I don't find Altera's free tools as > powerful as Xilinx's offerings because Altera doesn't offer a limited > version of ModelSim like Xilinx does. > Yes, ModelSim XE-Starter (The free version that comes with ISE WebPACK.) > slows down after 500 lines of code, but it still lets the user run the > simulator past 500 lines of code, and because it is an OEM version of > ModelSim, it lets me run HDL testbench code. > I personally find the slow down acceptable for my application. > However, Altera offerings (Quartus II 2.0) only has a simple waveform > simulator which lacks the ability to run HDL testbench code. > Plus, Quartus II 1.1/2.0 Web Edition tends to be less reliable compared > to ISE WebPACK 4.1 on Windows 98 PCs because QII tends to consume system > resources heavily. > Also, LeonardoSpectrum-Altera (LS-Altera) tends to be buggier compared > to ISE WebPACK's synthesis tool XST (The latest 2002 version is somewhat > better, but still has some problems, and I have to question Mentor > Graphics' quality control. Do Mentor Graphics/Exempler Logic/Altera test > LS-Altera before releasing it? It almost seems like they never test > their products.) > At least, I personally will like to see Altera letting users use a > limited version of ModelSim AE (Altera Edition) for free, but until that > happens, I recommend using ISE WebPACK + ModelSim XE-Starter for doing > serious hobby projects with free tools. > I am sure some die hard Altera fans won't appreciate my comments, but > that is too bad because Altera's free tools are clearly inferior > compared to Xilinx's offerings. > > > > Kevin Brace (In general, don't respond to me directly, and respond > within the newsgroup.) > > > > "arpit.desai" wrote: > > > > Jacky Renaux <renaux.jacky@wanadoo.fr> wrote in message news:<2002319-12443-423681@foorum.com>... > > > Try > > > http://www.xilinx.com/xlnx/xil_prodcat_landingpage.jsp?title=ISE+WebPack > > > the free package is very powerfull , be sure you have a large disk space > > > and fast internet download access. > > > > > > regards > > > > Altera also has a free software package which is pretty powerful at: > > > > https://www.altera.com/support/software/download/sof-download_center.htmlArticle: 41281
hi all, would be glad to know about effcient implmentation of LFSR of odd length i.e not powers of 2 ...like 257 ...is it possible if so how... thanks in advance anishArticle: 41282
Use GNU V2.95.2 on Solaris or Linux -EyckArticle: 41283
In article <abc3b185.0203242257.1cf8a4ca@posting.google.com>, anish <anish@myrealbox.com> wrote: >hi all, > would be glad to know about effcient implmentation of LFSR of odd >length i.e not powers of 2 ...like 257 ...is it possible if so how... >thanks in advance All max period shift registers of size N have a length of (2^N) - 1. -- Nicholas C. Weaver nweaver@cs.berkeley.eduArticle: 41284
rickman <spamgoeshere4@yahoo.com> writes: <snip> > > I was planning to do a simulation using the demo version of Hyperlynx. > But they no longer allow you to so ANY useful work. This is one of my > problems with demo software. They want me to spend thousands of dollars > of time to "evaluate" their product, but are not willing to let me get > anything in return. I feel it is very reasonable to let me accomplish > some amount of work during the evaluation so that my time is not totally > wasted if the product does not turn out to be something that I wish to > pay thousands of dollars for. > I got a 30-day eval of the full Hyperlynx tool from them, for 30 days I reckon, They were very nice about extending it when I hadn't been able to start the eval soon enough as well. Delivered with manuals (real paper!) and everything! <snip> > > > a) Multipoint daisy chain. Works fine if the chips have extremely > > small input capacitance. Otherwise, much careful work must be done. > > If using a parallel termination resistor, place it AFTER the > > last IC. > > Can you define what you mean by "extremely small input capacitance". Is > 10 pF small enough? Is 5 pF small enough? I don't think I remember > ever seeing an input spec of 5 pF or less. They are all about 6 to 12 > pF. > IIRC you are doing a C6711 design? I did a C6711, two flash, two SDRAM (ith two footprints each to accomodate 64MBit and 256MBit devices) a DPRAM and a Flex10KE FPGA (Sorry EPLD :-). It ended up as a daisy chain, with series ternminators on the FPGA datalines as its edges were horrible. The C6711 has (according to TI) been designed with slower edges than the previos C6x family so it doens;t need terminators as it is a low cost device - and that did seem to be the case. <snip> HTH, Martin -- martin.j.thompson@trw.com TRW Conekt, Solihull, UK http://www.trw.com/conektArticle: 41285
In article <a7fafm$mg8$1@harrier.doc.ic.ac.uk>, Jacke <magz@citiz.net>
writes
>Hi, there
>Are there anyone know where I can find a free systemC compiler?
>or just convert systemC to verilog , VHDL is also acceptable.
>
>Thanks.
>
>
If you mean a tool that compiles the code, then use gcc and the free
SystemC library.
If you mean a synthesis tool, I'm not aware of a free SystemC synthesis
tool.
Alan
--
Alan Fitch
DOULOS Ltd.
Church Hatch, 22 Market Place, Ringwood, Hampshire BH24 1AW, United Kingdom
Tel: +44 1425 471223 Email: alan.fitch@doulos.com
Fax: +44 1425 471573 Web: http://www.doulos.com
**********************************
** Developing design know-how **
**********************************
This e-mail and any attachments are confidential and Doulos Ltd. reserves
all rights of privilege in respect thereof. It is intended for the use of
the addressee only. If you are not the intended recipient please delete it
from your system, any use, disclosure, or copying of this document is
unauthorised. The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.
Article: 41286Are these LVDS interfaces compatible with the FPGA LVDS ? Is there a demux problem ? "Ray Andraka" <ray@andraka.com> wrote in message news:3C9B2AE5.B02F842D@andraka.com... > several that sample at well over 1GS/sec. These seem to be mostly LVDS > interfaces, mostly 8 bit. > > Hal Murray wrote: > > > > An option for high data > > >rate is to use a demux such as the Atmel TS81102G0 to break a high > > >data rate ADC output stream into several parallel interleaved > > >streams at rates the FPGA can easily handle. We did this recently > > >for a 960 MS/S FFT design. > > > > Wow! Thanks for the info. > > > > I haven't been looking at ADCs recently. How fast do they go > > now? What sort of signaling do the fast ones use? > > > > -- > > These are my opinions, not necessarily my employer's. I hate spam. >Article: 41287
Eric Crabill (eric.crabill@xilinx.com) wrote: : Hi, : I am looking to build a circuit for sorting small data sets, : and am hoping someone here might have some pointers for where : I should start looking for algorithms to do it. : Every cycle, 16 pieces of data are provided as input. : Some number of cycles later, the data set is provided : at the output, sorted... < stated elsewhere - 32 bit words, sorted off a nibble > Hi, I got thinking about sorting, and this is what I came up with. It should sort data at high speed, and accepts all words in a single cycle in parallel, and spits them out in parallel, sorted, a fixed number of cycles later. I think with a bit of effort in layout it would run very fast as well. However, it makes rather less efficient use of a Xilinx device than the FIFO solution, as it uses flip-flops for data storage, not LUTs. Please lay into any problems it has, I'm out to learn! --- The design consists of a number of pipeline stages, each of which partially sorts the data by sorting pairs of values. We have N words. Conceptually these are split into N/2 pairs of words, each of which are sorted based on the 4 bit key. This could be done with a 4 bit magnitude comparitor and two 2:1 mux's - see my noddy diagram at http://www.dur.ac.uk/christopher.saunter/sort1.bmp So the first stage of the sorting pipeline is as follows: w0 > larger (w0,w1) = v0 w1 > smaller(w0,w1) = v1 w2 > larger (w2,w3) = v2 w3 > smaller(w2,w3) = v3 w4 > larger (w4,w5) = v4 w5 > smaller(w4,w5) = v5 w6 > larger (w4,w5) = v6 w7 > smaller(w4,w5) = v7 The next stage is similar, although it sorts pairs consisting of (v1, v2), (v3,v4), (v5,v6) and optionally (v0,v7) (I say optinally - this sort of folds the flat rectangular shape of the pipeline into a cylinder - I think doing this will save you one pipeline stage but it might make getting a fast design out of P&R harder?) So if we watch the effect of this on some worst case data... e represents a sort of (w0, w1), (w2,w3) etc and o represents a sort of (w1,w2), (w3,w4) etc: e o e o e o e 1 > 2 > 7 > 7 > 7 > 7 > 7 > 8 2 > 1 > 4 > 4 > 6 > 6 > 8 > 7 3 > 4 > 1 > 6 > 4 > 8 > 6 > 6 4 > 3 > 6 > 1 > 8 > 4 > 5 > 5 5 > 6 > 3 > 8 > 1 > 5 > 4 > 4 6 > 5 > 8 > 3 > 5 > 1 > 3 > 3 7 > 8 > 5 > 5 > 3 > 3 > 1 > 2 8 > 7 > 2 > 2 > 2 > 2 > 2 > 1 So if I have this right, you should be able to sort N words in N-1 pipeline stages, requiring N(N-1) word registers. You want 32 bit words, 16 words, so thats 32.16.15 = 7680 registers. That's doable in larger devices. If you can run the sorter faster that the data rate, then you can time mux it, by reducing the number of stages and looping datra back through it repeatedly. Infact, using 3:1 mux's and a bit of logic, you could probably reduce it to just one stage. However, you said 100MHz clock... This approach should sort data at a scary rate, although getting that much data into and off the chip might be interesting.... Cheers, Chris Saunter : The latency isn't a big issue, as long as it is constant, : and I can provide a new data set to the circuit every cycle. : Thanks, : EricArticle: 41288
"BumsukLee" <bumsuklee@yahoo.com> wrote in message news:%2Um8.182$bI1.911@news.hananet.net... > Hello, > > I am working on an asynchronous fifo (Xiliinx coregen 3.1) which uses > separate clocks(both 100MHz) for read/write and getting read error or write > error flag asserted when I simulate with various different phases between > two clocks even though read enable ot write enable signal has enough setup > time.. > > Any advice? Hi, You'll need to toggle ainit, then its quite a complex issue. Pointers generated in different clock domains are a problem. See page 17 of this execellent paper by Clifford Cummings. http://www.sunburst-design.com/papers/CummingsSNUG2001SJ_AsyncClk_rev1_1.pdf However, I suspect Xilinx will have done the hard work for you. I've found there is quite a lot of latency on the flag information so allow plenty of time before you read them. Hope this helps. Phil -- Posted via Mailgate.ORG Server - http://www.Mailgate.ORGArticle: 41289
Post-Map Timing Analysis reports that all timing constraints have been
met, in fact there's only one constraint and that is the clock period.
Device usage indicates that no resource has been estimated over 100%:
Number of Slices: 6,489 out of 6,912 93%
Number of Slices containing
unrelated logic: 0 out of 6,489 0%
Number of Slice Flip Flops: 10,169 out of 13,824 73%
Total Number 4 input LUTs: 8,508 out of 13,824 61%
Number used as LUTs: 8,504
Number used as a route-thru: 4
Number of bonded IOBs: 21 out of 158 13%
IOB Flip Flops: 10
Number of Block RAMs: 32 out of 72 44%
Number of GCLKs: 1 out of 4 25%
Number of GCLKIOBs: 1 out of 4 25%
Number of DLLs: 1 out of 8 12%
Number of RPM macros: 32
Total equivalent gate count for design: 709,935
Additional JTAG gate count for IOBs: 1,056
And yes, it is the Placer which fails! Implementation never gets as far as
the routing process.. I get numerous warnings similar to:
WARNING:Place:78 - The SLICE component
"totboard_totem_chip_neuronsarray_neu122_mul_xil_xier_multxil/N1579"
could not be placed.
Followed by errors similar to:
ERROR:Place:1613 - Design object
(totboard_totem_chip_neuronsarray_neu122_mul_xil_xier_multxil/N1579)
could not be placed.
So it's neither a case of timing constraints not being met, nor one of
excessive usage of SLICEs or any other resources..
Still puzzling!
Stephanie McBader
Researcher/Design Engineer
NeuriCam S.p.A
Article: 41290
In article <3C9BB6A0.B9DBB6C1@mail.com>, John_H <johnhandwork@mail.com>
writes
[a radix sort]
>Sounds like the best approach for the parts he's dealing with.
[snip]
Radix sorts are good if the key is small (as is yours) but in the
general case of a larger key there are other hardware-friendly
methods.
The classic source for this kind of material is Donald Knuth's
masterly work "The Art of Computer Programming"; volume 3 covers
sorting and searching. He describes a method due to Batcher, which
Knuth calls "merge-exchange" sort. It maps really nicely on to
hardware because:
* it uses lots of instances of a single, simple logic element
(compare two values, swap them if they're out of order)
* it is very pipeline-friendly; the software algorithm
naturally suggests a pipelined hardware implementation
* although it's fairly extravagant of hardware, as any
fully-parallel sort is sure to be, it is not as expensive
as some of the better known methods
I have a little C program that "designs" Batcher sorting
networks for arbitrary numbers of input words: source code
by email on request! Here's its output for a network to sort
six numbers into order. The data comes in at the top and
falls out, sorted, at the bottom. The "|-|-|-|-|-|" lines
represent places where a pipeline register could go.
Strings like "O======O" represent a compare/swap module.
The numbers on the left represent steps in the algorithm
given by Knuth, and use the same notation - they only make
sense if you read his description.
View this in a monospaced font!!!!
=========================================
p,q,r,d = 4, 4, 0, 4 |-|-|-|-|-|
O=======O |
| O=======O
p,q,r,d = 2, 4, 0, 2 |-|-|-|-|-|
O===O | | |
| O===O | |
p,q,r,d = 2, 2, 2, 2 |-|-|-|-|-|
| | O===O |
| | | O===O
p,q,r,d = 1, 4, 0, 1 |-|-|-|-|-|
O=O O=O O=O
p,q,r,d = 1, 2, 1, 3 |-|-|-|-|-|
| O=====O |
p,q,r,d = 1, 1, 1, 1 |-|-|-|-|-|
| O=O O=O |
Sorted 6 elements using:
6 levels of logic;
12 compare/exchange modules.
=========================================
--
Jonathan Bromley
DOULOS Ltd.
Church Hatch, 22 Market Place, Ringwood, Hampshire BH24 1AW, United Kingdom
Tel: +44 1425 471223 Email: jonathan.bromley@doulos.com
Fax: +44 1425 471573 Web: http://www.doulos.com
**********************************
** Developing design know-how **
**********************************
This e-mail and any attachments are confidential and Doulos Ltd. reserves
all rights of privilege in respect thereof. It is intended for the use of
the addressee only. If you are not the intended recipient please delete it
from your system, any use, disclosure, or copying of this document is
unauthorised. The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.
Article: 41291Okay, so playing around with my sugestion in a -4 virtex, it'll take a lot of work to get it up to 100MHz. I suppose the 100MHz data rate could be split into 2x50MHz streams, processed in parallel.Article: 41292
Maciek, as far as I know, LeonardoSpectrum 2002a crashing after startup has to do with the windows versions you're using, international or US. Try to set the following Windows environment variable: Name of the variable: TZ Value of the variable: GST-1GDT Regards Wolfgang "kudla" <kudla@fuw.edu.pl> schrieb im Newsbeitrag news:a7d1lg$s3g$1@sunsite.icm.edu.pl... > My Synplify (Leonardo Spectrum OEM2002a_Altera_NIGHTLY_14) crashes soon > after start. > (License passes - that I can see before window disapears). I have w2k sp2 > and Quartus II 2.0. > Does somebody know what I can do? > Maciek > >Article: 41293
Sounds like the geometry of the 32 RPMs is such that the placer can't find a
suitable placement. This is not uncommon when you have reasonably large RPMs,
or a fairly full device. Try manually placing the RPMs with the floorplanner
and then letting the placer do the rest.
"S.H.McBader" wrote:
> Post-Map Timing Analysis reports that all timing constraints have been
> met, in fact there's only one constraint and that is the clock period.
> Device usage indicates that no resource has been estimated over 100%:
>
> Number of Slices: 6,489 out of 6,912 93%
> Number of Slices containing
> unrelated logic: 0 out of 6,489 0%
> Number of Slice Flip Flops: 10,169 out of 13,824 73%
> Total Number 4 input LUTs: 8,508 out of 13,824 61%
> Number used as LUTs: 8,504
> Number used as a route-thru: 4
> Number of bonded IOBs: 21 out of 158 13%
> IOB Flip Flops: 10
> Number of Block RAMs: 32 out of 72 44%
> Number of GCLKs: 1 out of 4 25%
> Number of GCLKIOBs: 1 out of 4 25%
> Number of DLLs: 1 out of 8 12%
> Number of RPM macros: 32
> Total equivalent gate count for design: 709,935
> Additional JTAG gate count for IOBs: 1,056
>
> And yes, it is the Placer which fails! Implementation never gets as far as
> the routing process.. I get numerous warnings similar to:
>
> WARNING:Place:78 - The SLICE component
> "totboard_totem_chip_neuronsarray_neu122_mul_xil_xier_multxil/N1579"
> could not be placed.
>
> Followed by errors similar to:
>
> ERROR:Place:1613 - Design object
> (totboard_totem_chip_neuronsarray_neu122_mul_xil_xier_multxil/N1579)
> could not be placed.
>
> So it's neither a case of timing constraints not being met, nor one of
> excessive usage of SLICEs or any other resources..
>
> Still puzzling!
>
> Stephanie McBader
> Researcher/Design Engineer
> NeuriCam S.p.A
--
--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: 41294
Depends, some may not be. Please refer to the data sheets for the FPGA and the
ADC or demux.
Le Mer Michel wrote:
> Are these LVDS interfaces compatible with the FPGA LVDS ? Is there a demux
> problem ?
>
> "Ray Andraka" <ray@andraka.com> wrote in message
> news:3C9B2AE5.B02F842D@andraka.com...
> > several that sample at well over 1GS/sec. These seem to be mostly LVDS
> > interfaces, mostly 8 bit.
> >
> > Hal Murray wrote:
> >
> > > > An option for high data
> > > >rate is to use a demux such as the Atmel TS81102G0 to break a high
> > > >data rate ADC output stream into several parallel interleaved
> > > >streams at rates the FPGA can easily handle. We did this recently
> > > >for a 960 MS/S FFT design.
> > >
> > > Wow! Thanks for the info.
> > >
> > > I haven't been looking at ADCs recently. How fast do they go
> > > now? What sort of signaling do the fast ones use?
> > >
> > > --
> > > These are my opinions, not necessarily my employer's. I hate spam.
> >
--
--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: 41295
A better way to handle those slow clocks is to bring them in on regular I/O
through a register clocked by your local master clock (typically many times
faster than the slow clock), then detect the edges of the slow clock
synchronously to create clock enables for the data 'clocked' by the slow clock.
Niv wrote:
> I have a design with more than 4 clocks, the Virtex max., (but some are very
> slow, < 1MHz).
>
> LeoSpec insists on putting BUFG's on all the clocks, which causes Xilinx PAR
> to throw a wobbler.
>
> The design now has a 40MHz master clk into a CLKDLL, which produces 2
> internal clocks with BUFG's, which is wanted, and 4 other clocks, only 2 of
> which need BUFG's. The other 2 clocks are low freq. and low fanout.
>
> The old design worked fine with 6 external clks; LeoSpec just sorted it out
> somehow; But now with 5 external clks, the master one to a DLL, it all goes
> to pot!
>
> Anyone got any bright ideas please?
>
> i.e. How do I force some of my clocks NOT to use BUFG's & IBUFG's, just use
> IBUF's instead?
>
> TIA, Niv.
--
--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: 41296Martin Thompson wrote: > > rickman <spamgoeshere4@yahoo.com> writes: > > <snip> > > > > > I was planning to do a simulation using the demo version of Hyperlynx. > > But they no longer allow you to so ANY useful work. This is one of my > > problems with demo software. They want me to spend thousands of dollars > > of time to "evaluate" their product, but are not willing to let me get > > anything in return. I feel it is very reasonable to let me accomplish > > some amount of work during the evaluation so that my time is not totally > > wasted if the product does not turn out to be something that I wish to > > pay thousands of dollars for. > > > > I got a 30-day eval of the full Hyperlynx tool from them, for 30 days > I reckon, They were very nice about extending it when I hadn't been > able to start the eval soon enough as well. Delivered with manuals > (real paper!) and everything! > > <snip> > > > > > > a) Multipoint daisy chain. Works fine if the chips have extremely > > > small input capacitance. Otherwise, much careful work must be done. > > > If using a parallel termination resistor, place it AFTER the > > > last IC. > > > > Can you define what you mean by "extremely small input capacitance". Is > > 10 pF small enough? Is 5 pF small enough? I don't think I remember > > ever seeing an input spec of 5 pF or less. They are all about 6 to 12 > > pF. > > > > IIRC you are doing a C6711 design? I did a C6711, two flash, two > SDRAM (ith two footprints each to accomodate 64MBit and 256MBit > devices) a DPRAM and a Flex10KE FPGA (Sorry EPLD :-). It ended up as > a daisy chain, with series ternminators on the FPGA datalines as its > edges were horrible. The C6711 has (according to TI) been designed > with slower edges than the previos C6x family so it doens;t need > terminators as it is a low cost device - and that did seem to be the > case. I am a little confused by what you said. You say that the edge rates on the C6711 seem to be slower than other C6x chips, and yet you say that you needed terminators since the edges were horrible. I don't understand. Did you mean that the C6711B was redesigned? -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 41297
--------------8FBC77CCF5844D6EAD5B8E9E Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Kevin, Glad I could help. I'm not sure why it wasn't fixed in 4.2, probably because it was not an easy fix. The period has to be non-integer and with a lot of decimal digits. I think that the problem is due to rounding errors with floating point calculations. I'm told that it will be fixed in our next major release. G=F6ran Kevin Neilson wrote: > Goran,You're right... I thought this didn't work because I changed > the period in the UCF to an integer and saw no difference but forgot > that I had a period constraint in the NCF too so I just deleted the > NCF. Thanks a lot... you save me a lot of time. But since you're from > Xilinx maybe I can complain a bit... how come I have version 4.2 and > this problem still persists? Am I the only person that uses > noninteger periods? -Kevin > > "Goran Bilski" <goran@xilinx.com> wrote in message > news:3C99089E.57DA27B5@xilinx.com...Hi, > > I actually run in to this problem a little while ago. > The reason for the huge timing delays is when you are using > DLL and has a clock period constraint that > has many decimals. I think that there are some rounding > errors in the timing tools. > So just change your clock period to 41 ns and the problem > should go away > > G=F6ran > > > Kevin Neilson wrote: > > > All,I keep running into this problem all the time in which > > I have a route that misses my constraint by tens of > > thousands of nanoseconds. I'm using the Xilinx 4.1 PAR > > tools. In this case the bad paths are ones that cross > > from a domain with a 20ns period to a domain with a 10ns > > period. The faster domain is generated from a DLL locked > > to the first, so while it is twice the freq, it is > > synchronous to the first. I'm taking care to read data in > > the second domain only on "even" cycles of the first > > domain, so the data has 20ns to get from the slow domain > > to the fast.The first evidence of a problem comes during > > routing: End of iteration 1 > > 22869 successful; 0 unrouted; (152088) REAL time: 5 mins > > 34 secsYou've all cringed at seeing this message before. > > Then, in the PAR summary, I see > > this:------------------------------------------------------------= -------------------- > > > > * PERIOD analysis for net "clk_management/f | 10.416ns | > > 38591.280ns | 4 > > irclk_dcm_clk2x" derived from NET "clk_m | > > | | > > anagement/CLK_ibufg" PERIOD =3D 41.667 nS | > > | | > > HIGH 50.000000 % | > > | | > > > > -----------------------------------------------------------------= --------------This > > is obviously a problem: my constraint for the fast clock > > domain is 10.4ns, and one path requires 38591ns, meaning I > > need to slow my clock to the kilohertz range. Here's the > > detail from > > Trace:=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3DTiming > > constraint: PERIOD analysis for net > > "clk_management/firclk_dcm_clk2x" derived from NET > > "clk_management/CLK_ibufg" PERIOD =3D 41.667 nS HIGH > > 50.000000 % ; divided by 2.00 and duty cycle corrected to > > 10.416 nS HIGH 5.208 nS 29336 items analyzed, 58 timing > > errors detected. Minimum period is > > 38591.280ns.-----------------------------------------------------= ---------------------------Slack: > > -3.704ns (requirement - (data path - negative clock > > skew)) Source: dpll/theta[12] > > Destination: fir/phase_reclock[5] > > Requirement: 0.001ns Data Path Delay: > > 3.705ns (Levels of Logic =3D 4) Negative Clock Skew: > > 0.000ns Source Clock: sclk rising at > > 216975.695ns Destination Clock: firclk rising at > > 216975.696ns Data Path: dpll/theta[12] to > > fir/phase_reclock[5] Location Delay > > type Delay(ns) Physical > > Resource > > Logical Resource(s) > > ------------------------------------------------- > > ------------------- SLICE_X57Y32.YQ > > Tcko 0.568 > > theta[13] > > dpll/theta[12] SLICE_X54Y33.F1 net > > (fanout=3D3) 0.551 theta[12] > > SLICE_X54Y33.COUT Topcyf 0.769 > > fir/phase_reclock[2] > > fir/phase_reclock_qxu[2] > > fir/phase_reclock_cry[2] > > fir/phase_reclock_cry[3] SLICE_X54Y34.CIN net > > (fanout=3D1) 0.000 fir/phase_reclock_cry[3]/O > > SLICE_X54Y34.Y Tciny 1.446 > > fir/phase_reclock[4] > > fir/phase_reclock_cry[4] > > fir/phase_reclock_s[5] SLICE_X54Y34.DY net > > (fanout=3D1) 0.001 fir/phase_reclock_s[5] > > SLICE_X54Y34.CLK Tdyck 0.370 > > fir/phase_reclock[4] > > fir/phase_reclock[5] > > ------------------------------------------------- > > --------------------------- > > Total 3.705ns > > (3.153ns logic, 0.552ns > > route) > > (85.1% logic, 14.9% > > route)-----------------------------------------------------------= ---------------------This > > is just whack. You can see that the path delay is 3.7ns, > > which easily meets the 20ns period of the slow clock > > (sclk). However, for some reason it thinks the source > > clock is sclk rising at 216975ns. Where did that come > > from? And how did it get a slack of -3.704ns? Also, > > where did the 38591ns period in the PAR summary come > > from? That's not even close to 216975. This path really > > shouldn't be analyzed at all. The Xilinx answer files > > state that 4.1i doesn't analyze paths that cross clock > > domains. Sometimes when I see this problem, I can "fool" > > PAR by putting a FROM-TO in the UCF that explicity states > > that paths from the "sclk" domain to the "firclk" domain > > have 20ns. However, this isn't working now, and Trace > > claims that 0 items are analyzed using that TIMESPEC, even > > though there are obviously many paths that fit that > > description.Has anybody else seen this?-Kevin >Article: 41298
Hello all I've just loaded on ISE 4.2i and the first design I ran through gives me an error at ngdbuild. This is with exactly the same input files as 4.1i which works fine. I've reproduced the error log below but, to me, this looks like something is broken in the software or it hasn't installed properly, not something wrong with the input files as I can switch back to 4.1i and route the design fine. I'm still waiting for euroapps support to get back to me so I thought I try the experts here. (The design comes from Leonardo and contains an edf and an ncf file as the main input files, several edn files from coregen as well as the ucf file.) ERROR:NgdBuild:669 - A parsing error has occurred at line 0 while reading lsb_opif.ucf. The value is . ERROR:NgdBuild:31 - Errors found while parsing .ucf file "lsb_opif.ucf". Please check for syntax errors in the UCF file. For more information on legal UCF constraints, please see the Constraints Guide for more information on this attribute. I've tried re-installing to no avail. I've also tried an empty ucf file (just comments) but this makes ngdbuild Dr Watson. It's interesting how the error above is on line 0! Running the design through 4.1i has no problems like this whatsoever. Does anyone know if any of the system dll's need updating with this new release? Thanks and regards David Frith Fujifilm Electronic Imaging Principal Engineer Hemel Hempstead, Herts david.frith@ffei.co.uk +44 1442 343083Article: 41299
> But since you're from Xilinx maybe I can complain a bit... how come I > have version 4.2 and this problem still persists? Am I the only person > that uses noninteger periods? No, you are not the only one. I have seen this problem many times since I upgraded to 4.1i. Xilinx support pointed me to answer #12174. It is for Virtex2 DCM's, but he said that the problem also exists for Vitex/spartan-2 DLL's. A agree that it is a little dissappointing that has not been fixed in any service pack or 4.2i, especially since it has apparently bitten several engineers and they have known about it for a while (I contacted them in December / January, and he told me that it is a "known issue.") Hopefully it will be fixed in the next service pack? But answer 12174 does not seem to indicate any plan to fix it. It is almost comical to see the report say that something with two logic levels can only run at 33kHz in a Spartan-2 FPGA. Seems like something Xilinx would like to avoid... Jason Daughenbaugh http://www.aedinc.net
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