Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarApr2017

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

Custom Search

Messages from 41250

Article: 41250
Subject: Re: A petition for Synplify's new fature (FPGA synthesis tool)
From: brimdavis@aol.com (Brian Davis)
Date: 22 Mar 2002 22:01:27 -0800
Links: << >>  << T >>  << A >>
Workaround:

   I ran into this 'feature' a while back, but hadn't tracked
 down exactly what was happening; I avoided it by switching
 back to Synplify 6.x instead.

   I experimented with some test code for a while tonight; another 
 way to work around this synthesis bug is to add an intermediate
 signal with a "syn_keep" attribute on it between the tristate
 bus and the register, which prevents the tristate pushthrough.

  See the example code below.


Root of the problem:

  I think the fundamental problem here is that the standard
 synthesis template used to infer a register (DFF) is not 
 entirely accurate as a simulation model of a real DFF; this
 results in the simulation "mismatch" to which Ken referred.

  Real DFFs don't propagate 'Z's from input to output, but a 
 functional simulation of the standard synthesis template for
 a DFF will propagate 'Z's under certain conditions.

  So you have to ask yourself, do you want your synthesizer
 to target real flip-flops, or the mythical Z-transport
 variety of flip-flop found only in your local simulator? 

   Such devices do not exist in the real world, and to create
 them by adding extra, unspecified hardware to the design is
 extremely undesirable behavior.

  I firmly believe that this tristate pushthrough behavior
 is incorrect, as it will lead to serious inconsistencies
 in the synthesis of nearly identical circuit constructs:

   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;
 

   In functional simulation, sig1 will propagate a 'Z', whereas 
 sig2 will propagate an 'X', due to the AND operator resolving 
 the 'Z' to an 'X'.

   So, following Ken's "match the simulation quirks at any price"
 synthesis policy, this means that sig1 should have a tristate 
 after the FF, but sig2 should not!

  ( Also, I'll bet Ken a dozen donuts that when Synplify optimizes
 that AND out of existence, it pushes the tristate through sig2, 
 causing yet another pre & post synthesis sim mismatch problem.)

  I'll experiment further and post more results later on.

Brian



--
-- demonstrate syn_keep workaround for unwanted 
-- tristate pushthrough 'feature'
--
-- Notes:
--
-- tested with Synplicity 7.0.3, targeting Spartan-2
--
-- Without syn_keep before output register:
--
--   - if tristate mux is not fully populated (has fewer drivers
--     than possible control input states),  Synplify pushes the 
--     tristate through to the output
--
--   - if tristate mux has the same # of drivers as it does control 
--     input selects, will make a mux without a tristate output 
--     ( it decides the bus can never be tristated )
--
-- With syn_keep before output register:
--
--   - prevents tristate pushthrough to the output register
--
--   - however, it does not build an internal tristate mux; 
--      instead, it builds a mux out of logic
--
--      - the syn_tristatetomux attribute is completely ignored!!!
--
--      - this will cause very poor QOR for some designs
--
--
library ieee;
use ieee.std_logic_1164.all;

entity tri_test is 
  port
    (   
      clk   : in  std_logic;

      sel   : in  std_logic_vector( 2 downto 0 );

      a_in  : in  std_logic_vector( 7 downto 0 );
      b_in  : in  std_logic_vector( 7 downto 0 );
      c_in  : in  std_logic_vector( 7 downto 0 );
      d_in  : in  std_logic_vector( 7 downto 0 );
      e_in  : in  std_logic_vector( 7 downto 0 );
      f_in  : in  std_logic_vector( 7 downto 0 );
      g_in  : in  std_logic_vector( 7 downto 0 );
      h_in  : in  std_logic_vector( 7 downto 0 );

      dout  : out std_logic_vector( 7 downto 0 )
    );
end tri_test;

architecture arch1 of tri_test is

  attribute syn_tristatetomux : integer;
  attribute syn_tristatetomux of arch1 : architecture is 1; 

  signal ts_mux      : std_logic_vector(7 downto 0);
  signal ts_mux_keep : std_logic_vector(7 downto 0);

  attribute syn_keep : boolean;
  attribute syn_keep of ts_mux_keep : signal is true;


begin

 --
 -- build an internal tristate mux
 --
 ts_mux <= a_in  when sel = "000" else (others => 'Z');
 ts_mux <= b_in  when sel = "001" else (others => 'Z');
 ts_mux <= c_in  when sel = "010" else (others => 'Z');
 ts_mux <= d_in  when sel = "011" else (others => 'Z');
 ts_mux <= e_in  when sel = "100" else (others => 'Z');
 ts_mux <= f_in  when sel = "101" else (others => 'Z');
 ts_mux <= g_in  when sel = "110" else (others => 'Z');

 --
 -- Need to comment out the last driver so tristate pushthrough
 -- behavior appears. If the tristate mux is fully populated,
 -- the output tristates vanish, as Synplify's analysis of the
 -- enables concludes that the bus is always being driven
 --
 -- ts_mux <= h_in  when sel = "111" else (others => 'Z');

 --
 -- read the tristate bus through a keep buffer
 -- ( note, "keep buffer" is Synplicity terminology for
 --  a "don't mess with this signal" buffer; this is NOT
 --  a weak buffer wired as a bus holder, aka "bus keeper" )
 --
 ts_mux_keep <= ts_mux;

 --
 -- then register it
 --
 out_reg: process(clk)
  begin

    if rising_edge(clk)  then

      -- using the keep_buffer prevents the 
      -- tristate pushthrough
      dout  <= ts_mux_keep;

      --
      -- uncommenting this assignment will build
      -- tristates at the output register 
     --
      --dout <= ts_mux;

    end if;

  end process;


end arch1;

Article: 41251
Subject: FIFOs are just like magic
From: FIFO_Luvr <FIFO_Luvr@lsuser_aol.name>
Date: Fri, 22 Mar 2002 23:59:34 -0800
Links: << >>  << T >>  << A >>
FIFOs are just like magic. Best length is not 666 KiBi bytes.
Like golf balls in drain pipe, but not as noisy

Article: 41252
Subject: QuartusII 2.0!!!!!
From: lyqin@cti.com.cn (Leon Qin)
Date: 23 Mar 2002 00:05:31 -0800
Links: << >>  << T >>  << A >>
When  I Start QuartusII 2.0 on My P4+Win2000,It can't compiling my design but
altera that start quartus_cmp server fail!,
What's wrong?

Article: 41253
Subject: Re: Looking for EBook?
From: lyqin@cti.com.cn (Leon Qin)
Date: 23 Mar 2002 00:07:33 -0800
Links: << >>  << T >>  << A >>
oh,thanks any way.

srinivasan_v@india.com (Srinivasan Venkataramanan) wrote in message news:<84245291.0203170315.60ff05f2@posting.google.com>...
> Hi,
>   I can imagine that it is difficult to procure them at China,  but
> the fact is these books (listed by you) are not (yet) available to
> public as e-books. The closest that I know of is:
> 
> http://www-ee.eng.hawaii.edu/~msmith/ASICs/HTML/ASICs.htm
> 
> Good Luck.
> Srinivasan
> 
> lyqin@cti.com.cn (Leon Qin) wrote in message news:<23c59085.0203161851.3a5e0295@posting.google.com>...
> > HDL Chip Design,
> > Writting TestBench,
> > Real Chip Design
> > 
> > 
> > Who can help me ?
> > My email box is big enough for receieve this boos .

Article: 41254
Subject: Re: Pipelined sorting algorithms...
From: Philip Freidin <philip@fliptronics.com>
Date: Sat, 23 Mar 2002 09:11:07 GMT
Links: << >>  << T >>  << A >>
On Fri, 22 Mar 2002 09:45:34 -0800, 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.
>
>My desire is to build a circuit to do the following:
>
>Every cycle, 16 pieces of data are provided as input.
>Some number of cycles later, the data set is provided
>at the output, sorted...
>
>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,
>Eric

The following link will take you to some research on using
Genetic Programming, on FPGAs, to create sorting systems.

While this is not what you want to do, the paper (select
the "cached" PDF in the top right corner of the page) has
good background information.

Then, get out your Volume 3 of Knuth's "The Art of Computer
Programming (Sorting and Searching)", and turn to page 231,
and there you will see an n=16 sort network, with 61
comparators, and a worstcase chain depth of 9. Read the
adjacent 722 pages for a good introduction to the subject.

Philip Freidin


Philip Freidin
Fliptronics

Article: 41255
Subject: Re: High speed clock routing
From: nospam@needed.com (Paul)
Date: Sat, 23 Mar 2002 04:14:12 -0500
Links: << >>  << T >>  << A >>
In article <3C923297.57531263@yahoo.com>, rickman
<spamgoeshere4@yahoo.com> wrote:

> I need to plan a high speed bus that will connect 5 devices.  They will
> all be very closely spaced so that the lengths of the routes can be kept
> pretty short.  The clock line is the one I am most concerned about.  It
> is 100 MHz ECLKOUT from a TI C6711 DSP.  The five devices are an SBSRAM,
> two SDRAMs (16 bits each for 32 bit memory) and an XC2S200E.  
... snip... 
> I know Austin will tell me to simulate it, which I plan to do.  I am
> just trying to get a "gut" feeling as Bob Pease would want to do.  You
> know how easy it is to get the WRONG, right answer from a computer. 
> GIGO.

These days, simulation IS the gut feeling. Once you've done a few 
simulations, with some typical CMOS 4ma, 8ma, 12ma drivers etc, you'll
develop classifications for each problem type, their associated risks,
and will find your simulation work affecting the way that you architect
solutions. For example, before simulation, I would build designs with
10 loads on a long parallel bus - after simulation, I would never try
anything like that again. 

First, for background reading, get a copy of the "MECL System Designers
Handbook". Motorola went through several printings of this fine book
without substantially updating the content, but it is still handy to 
have on your desk (it is what I started with 20 years ago). Obviously,
Howard Johnston's book is excellent as well.

Some other pointers:

1) Choosing track impedance - a higher impedance like 70ohms, can be
   easier for an IC to drive incident wave, but makes the track more 
   sensitive to loading. A lower impedance track like 50ohms, reduces
   this sensitivity, but will need a CMOS driver with roughly an
   8ma DC drive capability (that is a rule-of-thumb - CMOS 8ma DC drive
   looks roughly like a 50ohm source). All the digital stuff I do now
   is 50 ohms. 
2) Series damped, point to point interconnect is your friend. In the
   case of a bidirectional interface, you could use two resistors 
   (a small one on each end), or only place a series damping resistor
   on the device with extremely fast output edge rates (like data 
   outputs from SDRAM). Use the rule of thumb in (1) to ensure the
   driver output impedance is less than or equal to the track
   impedance, so the series damping resistor can be used for "tuning".
3) Multipoint interfaces are a last resort. This is where you invest
   in a simulator. The first thing you need to do, is develop a 
   realistic model for a copper track in FR-4. In the case of an
   expensive simulator like Hspice ($35K), you can actually enter 
   geometric information, and the tool creates the parameters for you. 
   To prove in the model, take a pulse source, a series damping resistor
   at the source and a parallel termination at the end of the 
   transmission line as a proof of concept. If everything is matched,
   an "ideal" half-size signal should show up at the destination. After
   you are happy with the single ended or differential model you have 
   developed, you can investigate topology. (Note that 10 experts will
   have 11 opinions on the validity of various vendors lossless or 
   lossy transmission line models, so prepare to spend some time on 
   this aspect.)

   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.
   b) Star (one track from source to each load, with a series damping
      resistor). After you add several loads, you'll see the amplitude
      collapse.
   c) Symmetric T or H topology. The DIMM designers friend. I don't
      really understand why it works, because it should ring like crazy.
      The issue here, is slight differences in the length of the arms of
      the T or H can break this interconnect case. The issue is 
      time-of-flight, so anything that affects TOF can break the 
      interconnect (the delta allowed is about 1.5 inches or so for the
      last set of simulations I tried). This case typically uses no 
      terminations, as their use spreads the devices out too far on the
      board and breaks the timing.
4) When selecting a solution, give some weight to fallback positions.
   In case (2) above, the series damping resistor value can be changed
   in the lab, if your assumptions or models are wrong (or if the board
   vendor spoils the "controlled impedance" tracks you asked for). Use
   zero ohm resistors to provide places to make engineering changes.
5) In terms of models, when I was working for a big company, I tried to
   insist on Spice models (Hspice supports a form of encryption, which,
   until some bozo proved they could break it, allowed the vendor some
   protection of their intellectual property.) These days, we are stuck
   with IBIS, which is good enough for the seat-of-the-pants 
   investigation in (3) above.
6) Zero delay buffers can and should be used, to derisk clock
   distribution. Series damp the outputs. Cypress and many other vendors
   make zero delay buffers. Things to watch for:

   a) When planning the clock topology, don't daisy chain too many of
      these, because of jitter accumulation via the PLLs in these
      devices. Both active (PLL) and passive (non-PLL) devices exist, so
      plan accordingly. I aim for no more than one PLL per path from 
      oscillator to load (but vendors say more than that are possible).
   b) Large fanout devices may have slow rise times, so investigate
      the timing before committing to using large fanout devices.
      (2-3 ns Tr for 16 outputs). Slow rise times give clock edge
      uncertainty.
   c) Try to allocate a buried layer for the clock signals (to reduce
      EMI) and use generous spacing rules to avoid clock crosstalk. 
      A clock signal emits 100 times the emissions of a (random) data
      signal, so a single clock can emit as much as a whole databus.
7) Multilayer boards are your friend (if you can afford them in your 
   application). Stripline (ground layer - signal layer - ground layer)
   is best, while offset stripline ( ground layer - north/south signal
   layer - east/west signal layer - ground layer) is really the most
   commonly used method. The offset stripline isn't, strictly speaking,
   controlled impedance, but it is good enough. 
8) For the economy minded, Berkeley Spice was available in source form
   in past years (and may still be). The existence of this resource is
   what has enabled so many large and small developers, to provide
   analog simulation tools. As a result, cheap tools can be found, but
   the tradeoff may be, that the vendor's software team may not know 
   anything about analog simulation! That is why I mention the topic of 
   "dialling-in" a simulator below - it takes several hardware design 
   cycles before you'll become somfortable with your simulator.

These pleasant generalities are good in the 100-200MHz range. At much
higher rates, signal attenuation can become an issue. At some point,
your differential tracks may need to change from edge coupled (side by
side on the same layer) to broadside coupled (over top of one another
on adjacent layers). Broadside reduces loss by allowing the use of 
wider tracks.

For cases involving higher rates, you may have to select devices based
on the availability of Spice models. Some vendors will actually offer
to run a Spice simulation case for you, at their factory, if it will 
make the sale and protect their intellectual property.

In addition, plan to spin a prototype of the higher rate interconnect
case in parallel with your actual hardware design, to "dial-in" your
simulation model. Stuff like this is good training for an Eng 
student.

*******

Years ago, a 10MHz bus or clock used to scare me. I never knew whether
it would work, until I got into the lab. With the availability of 
signal integrity simulation, my pain threshold is now about 622Mb/s. 

In a big company, interconnect simulation can eat up 10-20% of your
board design manpower.

HTH,
      Paul (a believer in simulation)

Article: 41256
Subject: Too many clocks
From: "Niv" <niv@ntlworld.com>
Date: Sat, 23 Mar 2002 09:16:12 -0000
Links: << >>  << T >>  << A >>
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: 41257
Subject: Re: Clock termination affecting JTAG interface
From: nospam@needed.com (Paul)
Date: Sat, 23 Mar 2002 05:41:47 -0500
Links: << >>  << T >>  << A >>
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: 41258
Subject: Re: Ligthning strikes & EMI - SPARTAN II design in flight
From: nospam@needed.com (Paul)
Date: Sat, 23 Mar 2002 06:02:30 -0500
Links: << >>  << T >>  << A >>
In article <xfIm8.27407$Ff3.2635136@news20.bellglobal.com>, "Dan"
<daniel.deconinck@sympatico.ca> wrote:

> Hello,
> 
> I am designing a Spartan II board. It will be installed in an aircraft. The
> customer wants special care taken in the design for lightning & EMI.
> 
> Where can I get info on proper design guidelines ?
> 
> Sincerely
> Dan

At the risk of offending you, if you have to ask this question, the
customer didn't hire the right company. If you want to get into designing
mission critical systems, such as biomedical, aeronautical, or military,
it is best to apprentice with "old farts" who have collected all the
necessary specs. If this product is going to be used globally, you must
design to the country that has the toughest specs - this is something
that can only be identified with years of experience. Many areas of 
design involve competing standards, which only experience handed down
from others can help you resolve (or ignore) the issues raised.

That being said, generally speaking, filter all the wires entering or
leaving the module, put a faraday cage around the board as a start.
Use copper ground planes on top and bottom of the board to reduce
emissions. Make sure clock tracks are buried on inner layers. As a
non-specialist, that is all the help I can give. 

I hope the Spartan isn't driving the rudder or flaps :-)

       Paul

P.S. The skill your company needs to hire is a "Product Integrity
     Specialist". This person would be tasked with testing the 
     product to meet global standards and would be able to advise
     you on what to do. Otherwise, just reverse engineer someone
     elses module :-)

Article: 41259
Subject: Re: All Digital PLL for locking DDS to input clock
From: Matt Boytim <maboytim@yahoo.com>
Date: Sat, 23 Mar 2002 13:25:27 GMT
Links: << >>  << T >>  << A >>
Kevin Neilson wrote:
> 
> > Kevin,
> >
> > First, thanks for an explicit and clear description of what you're
> > doing and what your questions are.  An excellent first step in getting
> > something useful out of this group.
> >
> > If you're actually phase locking the output symbol_clk to data_clk,
> > then the frequency relationship will be fixed, so I'm not sure what
> > you're really after when asking about the frequency error.   There
> > isn't one in a PLL, since the "lock" is between the output and the
> > reference.   If there _is_ an error, then you're experiencing cycle
> > slips somewhere, which is a solvable problem.
> >
> > Dithering the LSBs of the NCO phase increment register can help reduce
> > the spurious signals in the output, but if you're output is clean
> > enough for your application then there's no need to bother.   These
> > are the usual tradeoffs with this sort of architecture, though, so
> > that is a pertinent question.
> >
> > Qualcomm and ADI have both published some very good app notes on
> > NCO/DDS implementations over the years, so you may look around for
> > those if you haven't already.   I think there are some other links
> > around that could probably be found with suitable keywords in google
> > (I don't have any directly handy).   Perhaps some others will chime in
> > with useful references.
> >
> >
> > Eric Jacobsen
> > Minister of Algorithms, Intel Corp.
> 
> Eric,
> By "frequency error" I just mean the feedback signal.  Basically, I count
> how many times
> the vector theta revolves in N periods of data_clk, and then I subtract this
> from M to yield
> the "error".  This feedback signal is multiplied by a gain value and then
> added to the phase
> incrment that controls the NCO frequency.
> 
> One thing I'm trying to figure out is the effect of using a ratio of
> (S*M)/(S*N), which is the same
> ratio, but with top and bottom multiplied by S.  This decreases the loop
> gain, but does it add
> precision?
> -Kevin

There's a lot of -related- literature but I too have not found much to
be useful for similar loops.

If you are interested in spectral purity then you will want to use the
fractional part of the theta - in fact, if the free running range of the
nco is limited then you may not need the integer part.

Increase the reference rate - don't decrease it.  There are several
conceptually similar ways to compute an error on each input clock - this
will spread the error energy in frequency so it is better filtererd off
by the loop filter - by the way, use a loop filter.

If clocks are stable then quantization effects can limit steady state
performance (error is driven to zero or constant is bad) - dither can
really help.

If your incoming clock is asynchronous to your sample clock then there
will be sampling jitter which can be very low frequency depending on
actual relationship which can be addressed similar to fractional-N
techniques.

To the loop, a changing sample clock looks like a changing input clock. 
In terms of purity it depends on how you interpret the output - if you
feed the nco output sequence to a DAC which uses the changing sample
clock it will reconstruct using that clock and give one answer - if you
feed the data to an FFT (for example) which assumes uniform sampling
you'll get another - which is right depends on how the sequence is used.

These can be interesting circuits.

Matt

Article: 41260
Subject: Re: Any DDR SDRAM controller stories?
From: spam_hater_7@email.com (Spam Hater)
Date: Sat, 23 Mar 2002 14:51:02 GMT
Links: << >>  << T >>  << A >>

I looked at it.

IIRC, it requires re-compiling if memory sizes change, and does not
overlap transactions.

The only parts I wouund up keeping were the clocking scheme and the
data buffers.

Contact me if you need some help with your design.



On Fri, 22 Mar 2002 17:09:33 GMT, John_H <johnhandwork@mail.com>
wrote:

>I'm evaluating the Xilinx reference design for a DDR SDRAM
>controller.  The code comes free of charge and reports
>133MHz (PC2100) compliance in the VirtexE -7 speed grades
>(I'll be using a Spartan-IIE -7).  There are some minor gaps
>in the code (adding a refresh counter is simple but the
>forced auto-precharge is annoying) which I should be able to
>"firm up" to my needs.
>
>Has anyone used this code with success/failure?  Has anyone
>worked with other or better DDR controller cores that
>they've had good experiences with?
>
>I'm designing a memory bridge where most of our performance
>will be targeted at this "local" DDR memory buffer so
>keeping latencies down from the processor's perspective is
>of great importance.
>
>Thanks for the help!
>
>- John_H
>


Article: 41261
Subject: Re: Altera Stratix compared to Xilinx Virtex
From: rickman <spamgoeshere4@yahoo.com>
Date: Sat, 23 Mar 2002 10:25:44 -0500
Links: << >>  << T >>  << A >>
Ray Andraka wrote:
> 
> Timing numbers in the software don't mean squat until the silicon is characterized 

Would that be a standard "squat" or a "diddley squat"?


-- 

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 FAX

Article: 41262
Subject: Re: Altera Stratix compared to Xilinx Virtex
From: rickman <spamgoeshere4@yahoo.com>
Date: Sat, 23 Mar 2002 10:31:24 -0500
Links: << >>  << T >>  << A >>
rickman wrote:
> 
> Ray Andraka wrote:
> >
> > Timing numbers in the software don't mean squat until the silicon is characterized
> 
> Would that be a standard "squat" or a "diddley squat"?

Sorry, I should have checked the references before I posted.  That
should have been "doodly squat".  

doodly-squat

  Pronunciation: (dOOd'lE-skwot"), [key] 
  n. Slang. 
  a minimum amount or degree; the least bit (usually used in the
negative): This coin
  collection isn't worth doodly-squat in today's market.
Also,diddly-squat.

But there is a diddly-squat...

iddly-squat

  Pronunciation: (did'lE-skwot"), [key] 
  n. Slang. 
  see doodly-squat.

:)


-- 

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 FAX

Article: 41263
Subject: Re: Electronic Parts Locator
From: c_oflynn@yahoo.com (Colin O'Flynn)
Date: 23 Mar 2002 07:55:43 -0800
Links: << >>  << T >>  << A >>
Hi,
I use www.freetradezone.com , which is the same thing as
www.partminer.com. They also let you search for parts and all sorts of
stuff. However to get some of the more advanced feature you have to
pay.

If your with a company you could probably convince them to pay for it
;)

    -Colin


rickman <spamgoeshere4@yahoo.com> wrote in message news:<3C9C0B0B.4444F0D9@yahoo.com>...
> You can try partminer.com.  You will need to register which is not
> painful.  It searches some 20 or so sites fairly well.  I find that
> sometimes it will not return a hit that I can get if I go to distis
> direct.  It is also a bit slow and it will time out and require you to
> log in again after 20 mins or so of inactivity.  
> 
> Arrow is not one of the sites searched, likely because Arrows wants you
> to log in so they can track your interests.  But Insight also requires
> you to log in and they are searched by partminer. 
>  
> 
> Yury wrote:
> > 
> > Greetings all,
> >  I wonder if there would be other good sites like Questlink or
> >  the former findparts.com out there?
> > 
> > (Whatever happened to findparts.com electronic components search
> > engine?)
> > 
> > Can anyone recommend one? I need to check the availability and/or
> > datasheets accross multiple parts vendors.
> > 
> > Thanks,
> >  Yury
>  
> -- 
> 
> 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 FAX

Article: 41264
Subject: Re: High speed clock routing
From: rickman <spamgoeshere4@yahoo.com>
Date: Sat, 23 Mar 2002 11:34:58 -0500
Links: << >>  << T >>  << A >>
Paul,

Thanks for your comments.  It was so good, I didn't want to snip any of
it.  I have made my comments in your text.


Paul wrote:
> 
> In article <3C923297.57531263@yahoo.com>, rickman
> <spamgoeshere4@yahoo.com> wrote:
> 
> > I need to plan a high speed bus that will connect 5 devices.  They will
> > all be very closely spaced so that the lengths of the routes can be kept
> > pretty short.  The clock line is the one I am most concerned about.  It
> > is 100 MHz ECLKOUT from a TI C6711 DSP.  The five devices are an SBSRAM,
> > two SDRAMs (16 bits each for 32 bit memory) and an XC2S200E.
> ... snip...
> > I know Austin will tell me to simulate it, which I plan to do.  I am
> > just trying to get a "gut" feeling as Bob Pease would want to do.  You
> > know how easy it is to get the WRONG, right answer from a computer.
> > GIGO.
> 
> These days, simulation IS the gut feeling. Once you've done a few
> simulations, with some typical CMOS 4ma, 8ma, 12ma drivers etc, you'll
> develop classifications for each problem type, their associated risks,
> and will find your simulation work affecting the way that you architect
> solutions. For example, before simulation, I would build designs with
> 10 loads on a long parallel bus - after simulation, I would never try
> anything like that again.

I was working under the assumption that my paths would be short relative
to the edge rate of the driver.  But I now realize that you can't make
any assumptions about your edge rate since this can change at any time
as the chips are run with new processes.  So the working minimum edge
rate is 0 ps.  

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.  

Either that or I am rationalizing not being able to pay for every
multi-thousand dollar toy that I would like to be able to use.  


> First, for background reading, get a copy of the "MECL System Designers
> Handbook". Motorola went through several printings of this fine book
> without substantially updating the content, but it is still handy to
> have on your desk (it is what I started with 20 years ago). Obviously,
> Howard Johnston's book is excellent as well.

I had a copy at some point, but it seems to be MIA at the moment.  


> Some other pointers:
> 
> 1) Choosing track impedance - a higher impedance like 70ohms, can be
>    easier for an IC to drive incident wave, but makes the track more
>    sensitive to loading. A lower impedance track like 50ohms, reduces
>    this sensitivity, but will need a CMOS driver with roughly an
>    8ma DC drive capability (that is a rule-of-thumb - CMOS 8ma DC drive
>    looks roughly like a 50ohm source). All the digital stuff I do now
>    is 50 ohms.
> 2) Series damped, point to point interconnect is your friend. In the
>    case of a bidirectional interface, you could use two resistors
>    (a small one on each end), or only place a series damping resistor
>    on the device with extremely fast output edge rates (like data
>    outputs from SDRAM). Use the rule of thumb in (1) to ensure the
>    driver output impedance is less than or equal to the track
>    impedance, so the series damping resistor can be used for "tuning".

This is a nice solution if you can do it.  It would be very, very hard
to provide point to point traces for every bit of a 32 bit data bus
along with the 20 bit address bus and control signals.  

> 3) Multipoint interfaces are a last resort. This is where you invest
>    in a simulator. The first thing you need to do, is develop a
>    realistic model for a copper track in FR-4. In the case of an
>    expensive simulator like Hspice ($35K), you can actually enter
>    geometric information, and the tool creates the parameters for you.
>    To prove in the model, take a pulse source, a series damping resistor
>    at the source and a parallel termination at the end of the
>    transmission line as a proof of concept. If everything is matched,
>    an "ideal" half-size signal should show up at the destination. After
>    you are happy with the single ended or differential model you have
>    developed, you can investigate topology. (Note that 10 experts will
>    have 11 opinions on the validity of various vendors lossless or
>    lossy transmission line models, so prepare to spend some time on
>    this aspect.)

I am missing something here.  Why would I want a "half-size signal" to
appear at my inputs?  This would violate the input voltage levels and
likely would create double clocking and not work.  Or is this just a way
to verify the impedance model, but will not be used? 


>    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. 


>    b) Star (one track from source to each load, with a series damping
>       resistor). After you add several loads, you'll see the amplitude
>       collapse.

I was thinking about doing this.  Why would the amplitude colapse?  If
parallel termination is not used, why would this be a problem?  Howard
Johnson (HJ) did an analysis of the T (a simple case of the star) and
showed that it could work.  He used 50 ohm trace up to the point of
split and used 100 ohm trace after that.  Of course with a four way
star, you would need 200 ohm trace or start with a lower impedance. 
Some have indicated that 200 ohm traces are a problem. 


>    c) Symmetric T or H topology. The DIMM designers friend. I don't
>       really understand why it works, because it should ring like crazy.
>       The issue here, is slight differences in the length of the arms of
>       the T or H can break this interconnect case. The issue is
>       time-of-flight, so anything that affects TOF can break the
>       interconnect (the delta allowed is about 1.5 inches or so for the
>       last set of simulations I tried). This case typically uses no
>       terminations, as their use spreads the devices out too far on the
>       board and breaks the timing.

HJ did a couple of articles on this at
http://www.sigcon.com/articles/edn/tee.htm and
http://www.sigcon.com/articles/edn/DrivingTwoLoads.htm


> 4) When selecting a solution, give some weight to fallback positions.
>    In case (2) above, the series damping resistor value can be changed
>    in the lab, if your assumptions or models are wrong (or if the board
>    vendor spoils the "controlled impedance" tracks you asked for). Use
>    zero ohm resistors to provide places to make engineering changes.
> 5) In terms of models, when I was working for a big company, I tried to
>    insist on Spice models (Hspice supports a form of encryption, which,
>    until some bozo proved they could break it, allowed the vendor some
>    protection of their intellectual property.) These days, we are stuck
>    with IBIS, which is good enough for the seat-of-the-pants
>    investigation in (3) above.
> 6) Zero delay buffers can and should be used, to derisk clock
>    distribution. Series damp the outputs. Cypress and many other vendors
>    make zero delay buffers. Things to watch for:
> 
>    a) When planning the clock topology, don't daisy chain too many of
>       these, because of jitter accumulation via the PLLs in these
>       devices. Both active (PLL) and passive (non-PLL) devices exist, so
>       plan accordingly. I aim for no more than one PLL per path from
>       oscillator to load (but vendors say more than that are possible).
>    b) Large fanout devices may have slow rise times, so investigate
>       the timing before committing to using large fanout devices.
>       (2-3 ns Tr for 16 outputs). Slow rise times give clock edge
>       uncertainty.
>    c) Try to allocate a buried layer for the clock signals (to reduce
>       EMI) and use generous spacing rules to avoid clock crosstalk.
>       A clock signal emits 100 times the emissions of a (random) data
>       signal, so a single clock can emit as much as a whole databus.
> 7) Multilayer boards are your friend (if you can afford them in your
>    application). Stripline (ground layer - signal layer - ground layer)
>    is best, while offset stripline ( ground layer - north/south signal
>    layer - east/west signal layer - ground layer) is really the most
>    commonly used method. The offset stripline isn't, strictly speaking,
>    controlled impedance, but it is good enough.
> 8) For the economy minded, Berkeley Spice was available in source form
>    in past years (and may still be). The existence of this resource is
>    what has enabled so many large and small developers, to provide
>    analog simulation tools. As a result, cheap tools can be found, but
>    the tradeoff may be, that the vendor's software team may not know
>    anything about analog simulation! That is why I mention the topic of
>    "dialling-in" a simulator below - it takes several hardware design
>    cycles before you'll become somfortable with your simulator.
> 
> These pleasant generalities are good in the 100-200MHz range. At much
> higher rates, signal attenuation can become an issue. At some point,
> your differential tracks may need to change from edge coupled (side by
> side on the same layer) to broadside coupled (over top of one another
> on adjacent layers). Broadside reduces loss by allowing the use of
> wider tracks.
> 
> For cases involving higher rates, you may have to select devices based
> on the availability of Spice models. Some vendors will actually offer
> to run a Spice simulation case for you, at their factory, if it will
> make the sale and protect their intellectual property.
> 
> In addition, plan to spin a prototype of the higher rate interconnect
> case in parallel with your actual hardware design, to "dial-in" your
> simulation model. Stuff like this is good training for an Eng
> student.
> 
> *******
> 
> Years ago, a 10MHz bus or clock used to scare me. I never knew whether
> it would work, until I got into the lab. With the availability of
> signal integrity simulation, my pain threshold is now about 622Mb/s.
> 
> In a big company, interconnect simulation can eat up 10-20% of your
> board design manpower.
> 
> HTH,
>       Paul (a believer in simulation)

Thanks for the comments...


-- 

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 FAX

Article: 41265
Subject: Re: QuartusII 2.0!!!!!
From: "Peter Ormsby" <faepete.deletethis@attbi.com>
Date: Sat, 23 Mar 2002 18:39:27 GMT
Links: << >>  << T >>  << A >>
Sorry, but your translation to English didn't come out very well.  Can you
post the error message and the conditions under which you are getting it?

-Pete-

Leon Qin <lyqin@cti.com.cn> wrote in message
news:23c59085.0203230005.66a0000e@posting.google.com...
> When  I Start QuartusII 2.0 on My P4+Win2000,It can't compiling my design
but
> altera that start quartus_cmp server fail!,
> What's wrong?



Article: 41266
Subject: Re: QuartusII 2.0!!!!!
From: Kevin Brace <ihatespam99kevinbraceusenet@ihatespam99hotmail.com>
Date: Sat, 23 Mar 2002 14:55:32 -0600
Links: << >>  << T >>  << A >>
Back in the days of QII 1.1 Web Edition, when I tried to use
LeonardoSpectrum-Altera 2001_1a_028 through NativeLink (QII
automatically invoking LS-Altera from QII), QII 1.1 WE "always" crashed
at quartus_cmp.exe.
In QII 2.0 WE, NativeLink for LS-Altera has been fixed somewhat, and in
my case, QII no longer crashes at quartus_cmp.exe.
However, if you are targeting FLEX10KE/ACEX1K with LS-Altera through
NativeLink (I have no idea because you didn't explain what device you
are targeting or what synthesis tool you are using.), QII might fail to
synthesize your design because some idiot at Altera specified wrong file
names in LS-Altera NativeLink script.
The problem seems to occur only with FLEX10KE/ACEX1K, and not with
APEX20KE or FLEX6000.
You probably will like to tell more about which device you are targeting
or what synthesis tool you are using, but if you happened to use
NativeLink, I recommend not using it because Altera cannot seem to get
it right.
If you happened to use LS-Altera, import the netlist (EDIF file) to QII,
or use QII's in-house synthesis tool (QII native synthesis) which tends
to generate circuit that's fairly larger than LS-Altera.



Kevin Brace (In general, don't respond to me directly, and respond
within the newsgroup.)




Leon Qin wrote:
> 
> When  I Start QuartusII 2.0 on My P4+Win2000,It can't compiling my design but
> altera that start quartus_cmp server fail!,
> What's wrong?

Article: 41267
Subject: Re: A petition for Synplify's new fature (FPGA synthesis tool)
From: Ken McElvain <ken@synplicity.com>
Date: Sat, 23 Mar 2002 21:38:39 GMT
Links: << >>  << T >>  << A >>

See comments below

Brian Davis wrote:

> Workaround:
> 
>    I ran into this 'feature' a while back, but hadn't tracked
>  down exactly what was happening; I avoided it by switching
>  back to Synplify 6.x instead.
> 
>    I experimented with some test code for a while tonight; another 
>  way to work around this synthesis bug is to add an intermediate
>  signal with a "syn_keep" attribute on it between the tristate
>  bus and the register, which prevents the tristate pushthrough.
> 
>   See the example code below.
> 
> 
> Root of the problem:
> 
>   I think the fundamental problem here is that the standard
>  synthesis template used to infer a register (DFF) is not 
>  entirely accurate as a simulation model of a real DFF; this
>  results in the simulation "mismatch" to which Ken referred.
> 
>   Real DFFs don't propagate 'Z's from input to output, but a 
>  functional simulation of the standard synthesis template for
>  a DFF will propagate 'Z's under certain conditions.
> 
>   So you have to ask yourself, do you want your synthesizer
>  to target real flip-flops, or the mythical Z-transport
>  variety of flip-flop found only in your local simulator? 
> 
>    Such devices do not exist in the real world, and to create
>  them by adding extra, unspecified hardware to the design is
>  extremely undesirable behavior.
> 
>   I firmly believe that this tristate pushthrough behavior
>  is incorrect, as it will lead to serious inconsistencies


Any difference between RTL and gate level simulation results
in users sending us very complicated designs and asking us
to debug them.  Our ratio of suspected problems to real problems
is very high and they consume a lot of engineering time to
track back to things like differences in X propagation and
also 'Z' propagation differences.

Your argument is not really that it is "incorrect" to produce
a functional match between the RTL and gate level simultion, but
rather that it is impractical.  In Aki's test case it looks
like we did the transform inefficiently.  We will fix this.
It should in practice turn out to cost very little to maintain
a behavior match in 'Z' propagation.

In any case we did add a switch in 7.1 to select the old behavior.


>  in the synthesis of nearly identical circuit constructs:
> 
>    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;
>  
> 
>    In functional simulation, sig1 will propagate a 'Z', whereas 
>  sig2 will propagate an 'X', due to the AND operator resolving 
>  the 'Z' to an 'X'.
> 
>    So, following Ken's "match the simulation quirks at any price"
>  synthesis policy, this means that sig1 should have a tristate 
>  after the FF, but sig2 should not!

Correct!

It will not be at any price because matching 'Z' propagation
should be very cheap.  Note that we only propagate the 'Z's when
there is a destination node that can potentially distinguish the
'Z' from an 'X'.  At module/entity  boundaries this is possible, but
later in the optimization process these tristate drivers will be removed
when we analyze across module/entity boundaries.


> 
>   ( Also, I'll bet Ken a dozen donuts that when Synplify optimizes
>  that AND out of existence, it pushes the tristate through sig2, 
>  causing yet another pre & post synthesis sim mismatch problem.)
> 
>   I'll experiment further and post more results later on.
> 
> Brian
> 
> 


Thanks for the very clear feedback.
- Ken


> 
> --
> -- demonstrate syn_keep workaround for unwanted 
> -- tristate pushthrough 'feature'
> --
> -- Notes:
> --
> -- tested with Synplicity 7.0.3, targeting Spartan-2
> --
> -- Without syn_keep before output register:
> --
> --   - if tristate mux is not fully populated (has fewer drivers
> --     than possible control input states),  Synplify pushes the 
> --     tristate through to the output
> --
> --   - if tristate mux has the same # of drivers as it does control 
> --     input selects, will make a mux without a tristate output 
> --     ( it decides the bus can never be tristated )
> --
> -- With syn_keep before output register:
> --
> --   - prevents tristate pushthrough to the output register
> --
> --   - however, it does not build an internal tristate mux; 
> --      instead, it builds a mux out of logic
> --
> --      - the syn_tristatetomux attribute is completely ignored!!!
> --
> --      - this will cause very poor QOR for some designs
> --
> --
> library ieee;
> use ieee.std_logic_1164.all;
> 
> entity tri_test is 
>   port
>     (   
>       clk   : in  std_logic;
> 
>       sel   : in  std_logic_vector( 2 downto 0 );
> 
>       a_in  : in  std_logic_vector( 7 downto 0 );
>       b_in  : in  std_logic_vector( 7 downto 0 );
>       c_in  : in  std_logic_vector( 7 downto 0 );
>       d_in  : in  std_logic_vector( 7 downto 0 );
>       e_in  : in  std_logic_vector( 7 downto 0 );
>       f_in  : in  std_logic_vector( 7 downto 0 );
>       g_in  : in  std_logic_vector( 7 downto 0 );
>       h_in  : in  std_logic_vector( 7 downto 0 );
> 
>       dout  : out std_logic_vector( 7 downto 0 )
>     );
> end tri_test;
> 
> architecture arch1 of tri_test is
> 
>   attribute syn_tristatetomux : integer;
>   attribute syn_tristatetomux of arch1 : architecture is 1; 
> 
>   signal ts_mux      : std_logic_vector(7 downto 0);
>   signal ts_mux_keep : std_logic_vector(7 downto 0);
> 
>   attribute syn_keep : boolean;
>   attribute syn_keep of ts_mux_keep : signal is true;
> 
> 
> begin
> 
>  --
>  -- build an internal tristate mux
>  --
>  ts_mux <= a_in  when sel = "000" else (others => 'Z');
>  ts_mux <= b_in  when sel = "001" else (others => 'Z');
>  ts_mux <= c_in  when sel = "010" else (others => 'Z');
>  ts_mux <= d_in  when sel = "011" else (others => 'Z');
>  ts_mux <= e_in  when sel = "100" else (others => 'Z');
>  ts_mux <= f_in  when sel = "101" else (others => 'Z');
>  ts_mux <= g_in  when sel = "110" else (others => 'Z');
> 
>  --
>  -- Need to comment out the last driver so tristate pushthrough
>  -- behavior appears. If the tristate mux is fully populated,
>  -- the output tristates vanish, as Synplify's analysis of the
>  -- enables concludes that the bus is always being driven
>  --
>  -- ts_mux <= h_in  when sel = "111" else (others => 'Z');
> 
>  --
>  -- read the tristate bus through a keep buffer
>  -- ( note, "keep buffer" is Synplicity terminology for
>  --  a "don't mess with this signal" buffer; this is NOT
>  --  a weak buffer wired as a bus holder, aka "bus keeper" )
>  --
>  ts_mux_keep <= ts_mux;
> 
>  --
>  -- then register it
>  --
>  out_reg: process(clk)
>   begin
> 
>     if rising_edge(clk)  then
> 
>       -- using the keep_buffer prevents the 
>       -- tristate pushthrough
>       dout  <= ts_mux_keep;
> 
>       --
>       -- uncommenting this assignment will build
>       -- tristates at the output register 
>      --
>       --dout <= ts_mux;
> 
>     end if;
> 
>   end process;
> 
> 
> end arch1;
> 


Article: 41268
Subject: Re: Electronic Parts Locator
From: yuryws@optonline.com (Yury)
Date: 23 Mar 2002 17:45:58 -0800
Links: << >>  << T >>  << A >>
Thanks you all for the good advice.

Yury

Article: 41269
Subject: Re: A petition for Synplify's new fature (FPGA synthesis tool)
From: "Tim" <tim@rockylogic.com.nooospam.com>
Date: Sun, 24 Mar 2002 02:36:40 -0000
Links: << >>  << T >>  << A >>
Ken McElvain wrote
> Brian Davis wrote:
> >  in the synthesis of nearly identical circuit constructs:
> >
> >    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;
> >
> >
> >    In functional simulation, sig1 will propagate a 'Z', whereas
> >  sig2 will propagate an 'X', due to the AND operator resolving
> >  the 'Z' to an 'X'.
> >
> >    So, following Ken's "match the simulation quirks at any price"
> >  synthesis policy, this means that sig1 should have a tristate
> >  after the FF, but sig2 should not!
>
> Correct!
>
> It will not be at any price because matching 'Z' propagation
> should be very cheap.  Note that we only propagate the 'Z's when
> there is a destination node that can potentially distinguish the
> 'Z' from an 'X'.  At module/entity  boundaries this is possible, but
> later in the optimization process these tristate drivers will be removed
> when we analyze across module/entity boundaries.

Isn't Brian's example something which, though OK for sim,
should be flagged for synthesis?  If this is what is meant,
would it not be a good idea for the code to say so:

   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';
   ts_mux <= 'H'; -- synth looks at its technology data base
                  -- to see if this results in a well-controlled
                  -- signal into the flop.  otherwise, warns/errors.
  process
    wait until rising_edge(clk);
     sig1 <= to_x01(ts_mux);
     sig1_enable <= sel="00" or sel="01" sel="10";
  end process;

  final_output <= sig1 when sig1_enable else 'Z';

And "sig2 <= ts_mux AND '1';" just gets a warning from the synth
- "not a supported metaphor".









Article: 41270
Subject: Re: High speed clock routing
From: nospam@needed.com (Paul)
Date: Sat, 23 Mar 2002 23:11:36 -0500
Links: << >>  << T >>  << A >>
In article <3C9CAEB2.359557F2@yahoo.com>, rickman
<spamgoeshere4@yahoo.com> wrote:

> Paul,
> 
> Thanks for your comments.  It was so good, I didn't want to snip any of
> it.  I have made my comments in your text.
> 
> > These days, simulation IS the gut feeling. Once you've done a few
> > simulations, with some typical CMOS 4ma, 8ma, 12ma drivers etc, you'll
> > develop classifications for each problem type, their associated risks,
> > and will find your simulation work affecting the way that you architect
> > solutions. For example, before simulation, I would build designs with
> > 10 loads on a long parallel bus - after simulation, I would never try
> > anything like that again.
> 
> I was working under the assumption that my paths would be short relative
> to the edge rate of the driver.  But I now realize that you can't make
> any assumptions about your edge rate since this can change at any time
> as the chips are run with new processes.  So the working minimum edge
> rate is 0 ps.

If you get the IBIS model for the driver and it has params dV/dt_r
and dV/dt_f, that will give risetime of the driver with a simple load
on it. If a manufacturer does a simple shrink, they shrink the core
geometry but leave the pads at the old geometry (i.e. 0.18u pads, 0.13u
core gates). The dV/dt listed in the IBIS file should apply for the life
of that part number.

> 
> 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.  
> 
> Either that or I am rationalizing not being able to pay for every
> multi-thousand dollar toy that I would like to be able to use.  

The last time I wanted to try some simulations at home, I was able to 
find a product for Macintosh, that had a 30 day evaluation. If you are
trying to do this work as economically as possible, you could go from
one evaluation to another, but it will cost you personal time. I guess
it really depends on the size of the company. One floating license can
support a lot of engineers, when the runtime for a simulation is 30
seconds. (And, for Hspice, I was able to find a viewer package from a
university, that avoids having to buy a license for many waveform
viewers.) If you are doing detailed simulations, these times can run up
to 24 hours - and that type of simulation is not what I am proposing.
I like to do quick simulations, sometimes using models from analagous
parts, just to see how practical an interconnect topology is. Sort of
a manual sensitivity analysis.

Doing a search on Altavista (search term "berkeley spice"), I can see,
for example, a new project on SourceForge called NGspice. My point is,
the Berkeley Spice project has fathered many solutions - either buy an
expensive one (and ask on the net, if the tech support is good), or
try out some cheaper or free solutions on your own time. 

...snip...

> > 2) Series damped, point to point interconnect is your friend. In the
> >    case of a bidirectional interface, you could use two resistors
> >    (a small one on each end), or only place a series damping resistor
> >    on the device with extremely fast output edge rates (like data
> >    outputs from SDRAM). Use the rule of thumb in (1) to ensure the
> >    driver output impedance is less than or equal to the track
> >    impedance, so the series damping resistor can be used for "tuning".
> 
> This is a nice solution if you can do it.  It would be very, very hard
> to provide point to point traces for every bit of a 32 bit data bus
> along with the 20 bit address bus and control signals.

Agreed. Sometimes you have a choice, as in choosing whether an FPGA
sits off the side of a bus, or buffers data onto a sub-bus. On my last
project, I cut my bus in two pieces with some 2:1 QuickSwitches, in
order to shorten the segments and make a reasonable transfer rate
possible. I wouldn't have tried that, if the original sim hadn't looked
so bad.

> 
> > 3) Multipoint interfaces are a last resort. This is where you invest
> >    in a simulator. The first thing you need to do, is develop a
> >    realistic model for a copper track in FR-4. In the case of an
> >    expensive simulator like Hspice ($35K), you can actually enter
> >    geometric information, and the tool creates the parameters for you.
> >    To prove in the model, take a pulse source, a series damping resistor
> >    at the source and a parallel termination at the end of the
> >    transmission line as a proof of concept. If everything is matched,
> >    an "ideal" half-size signal should show up at the destination. After
> >    you are happy with the single ended or differential model you have
> >    developed, you can investigate topology. (Note that 10 experts will
> >    have 11 opinions on the validity of various vendors lossless or
> >    lossy transmission line models, so prepare to spend some time on
> >    this aspect.)
> 
> I am missing something here.  Why would I want a "half-size signal" to
> appear at my inputs?  This would violate the input voltage levels and
> likely would create double clocking and not work.  Or is this just a way
> to verify the impedance model, but will not be used? 
> 

Sorry if I was unclear. The "ideal transmission line" case is something
I run, to make sure my geometric specification has roughly the right
impedance. After I have proved a single segment of transmission line is
correct, like Lego, I can start plugging segments together and do my
real test cases.

> 
> >    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.

That was a little tongue in check. The input capacitance is never small
enough :-) 

> 
> 
> >    b) Star (one track from source to each load, with a series damping
> >       resistor). After you add several loads, you'll see the amplitude
> >       collapse.
> 
> I was thinking about doing this.  Why would the amplitude colapse?  If
> parallel termination is not used, why would this be a problem?  Howard
> Johnson (HJ) did an analysis of the T (a simple case of the star) and
> showed that it could work.  He used 50 ohm trace up to the point of
> split and used 100 ohm trace after that.  Of course with a four way
> star, you would need 200 ohm trace or start with a lower impedance. 
> Some have indicated that 200 ohm traces are a problem. 

The "impedance fork", using two 100 ohm traces running from a 50 ohm
trace, is shown in the MECL System Designers Handbook. Making a 100ohm
track would require cutting a slot in virtually all your ground layers,
so isn't practical. I was referring to driving (n) 50 ohm stubs from 
one driver - if you try this in simulation, you'll see the amplitude
drop pretty quickly. More than three loads or so wouldn't work.

      Paul

Article: 41271
Subject: Help with Xilinx CoolRunner Problem
From: halstoninaustin@yahoo.com (Mik e Payne)
Date: 23 Mar 2002 21:18:32 -0800
Links: << >>  << T >>  << A >>
I'm using a Xilinx XCR256XL CPLD to connect an 8051 (AT89S8252)
microcontroller to an SRAM (Dallas DS1746) chip.  For now all I have
the CPLD doing is the glue logic for the SRAM interface (De-multiplex
the low address lines and control read/write enable).  I'm using an
AVNET evaluation board for the prototyping.  I cannot get this design
to work.  I can read/write to some SRAM locations but not all.  The
problem looks like ground bounce and I've tried everything I can think
of to fix the problem.  I've put 100 Ohm resistors in series with
AD0-7, I've put a 15pf Cap on the ALE line and still it does not work.
 When I scope the address lines comming from the CPLD they look
terrible, alot of ringing on the edges.

I'm thinking that I'm not understanding something about this CPLD.  It
has a 32.768KHz clock going into CLK0 and CLK1-3 are tied to ground. 
Do I need to have clocks on all of these lines?  Does the clock need
to be equal to or greater than my fastest switching line?  Below is my
VHDL code in case it helps.  I'm really stuck here and would
appreciate any help/advice.

Thanks for your time,
Mike

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;

entity uC_to_SRAM is
   port(
	ucAddrData  : inout std_logic_vector (7 downto 0);
	ucHiAddr    : in    std_logic_vector (7 downto 0);
	ucRead		: in    std_logic;
	ucWrite		: in	  std_logic;
	ucALE			: in    std_logic;
	ucPSEN		: in    std_logic;
	ramLoAddr	: out   std_logic_vector (7 downto 0);
	ramHiAddr	: out   std_logic_vector (7 downto 0);
	ramData		: inout std_logic_vector (7 downto 0);
	ramA16		: out   std_logic;
	ramOutput   : out   std_logic;
	ramWrite    : out   std_logic;
	ramChipSel  : out   std_logic
  );
end uC_to_SRAM;

architecture BEHAVIOUR of uC_to_SRAM is

constant LOGIC_LOW : STD_LOGIC := '0';
constant LOGIC_HIGH : STD_LOGIC := '1'; 

signal DataOut  : std_logic_vector(7 downto 0); -- data to be output
to 8051
signal DataIn   : std_logic_vector(7 downto 0); -- data input from the
8051
signal LowAddress : std_logic_vector(7 downto 0);
signal ReadEnable : std_logic;
signal WriteEnable : std_logic;

begin

ReadEnable <= ucRead and ucPSEN;
WriteEnable <= ucWrite;

ramHiAddr <= ucHiAddr;
ramLoAddr <= LowAddress;
ramChipSel <= LOGIC_LOW;

ramA16 <= '1';
ramOutput <= ReadEnable;
ramWrite <= WriteEnable;

--************************** Bi-directional 8051 Data Bus
**********************************
ucAddrData <= DataOut when ReadEnable = '0' else (others => 'Z');
DataIn <= ucAddrData when WriteEnable = '0' else "00000000";

--************************** 
LOW_ADDRESS: process(ucALE)
begin
	if ucALE = '1' then
		LowAddress <= ucAddrData;
	end if;
end process;

DATA_WRITE: process(WriteEnable, DataIn)
begin
	if WriteEnable = '0' then
		ramData <= DataIn;
   else
		ramData <= "ZZZZZZZZ";
	end if;
end process;

DATA_READ: process(ReadEnable, ramData)
begin
	if ReadEnable = '0' then
		DataOut <= ramData;
	else
		DataOut <= "00000000";
	end if;
end process;

end BEHAVIOUR;

Article: 41272
Subject: Re: Help with Xilinx CoolRunner Problem
From: "Falk Brunner" <Falk.Brunner@gmx.de>
Date: Sun, 24 Mar 2002 14:21:26 +0100
Links: << >>  << T >>  << A >>
"Mik e Payne" <halstoninaustin@yahoo.com> schrieb im Newsbeitrag
news:b1946105.0203232118.7d4ecbeb@posting.google.com...

> the low address lines and control read/write enable).  I'm using an
> AVNET evaluation board for the prototyping.  I cannot get this design

How do you connect the 8051 and SRAM to the demo board? Via 10 feet of
ribbon cable with just 1 ground wire ? ;-)
Just kidding.
Serious, I think a 8051 isnt such a killer (IOs are not too fast) to produce
heavy ground bounce and/or ringing if the setup is reasonably OK. Use short
(<10 cm) connection cables, good ground connections (close to the signals,
not fly-around ground wire) and everything should be OK.

> I'm thinking that I'm not understanding something about this CPLD.  It
> has a 32.768KHz clock going into CLK0 and CLK1-3 are tied to ground.
> Do I need to have clocks on all of these lines?  Does the clock need

No. As far as I acn see you are just running the asynchronous interface
between the 8051 and SRAM through the CPLD, so there is no need for a clock.

--
MfG
Falk





Article: 41273
Subject: Re: A petition for Synplify's new fature (FPGA synthesis tool)
From: allan_herriman.hates.spam@agilent.com (Allan Herriman)
Date: Sun, 24 Mar 2002 13:53:30 GMT
Links: << >>  << T >>  << A >>
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: 41274
Subject: RTP & Aggregation design
From: anurag@mail.ru (Anurag)
Date: 24 Mar 2002 10:56:50 -0800
Links: << >>  << T >>  << A >>
Hi,

are there any references to the design of a RTP & aggregation engine
in Verilog or VHDL ? Or availability of such a core ?

Would appreciate any info./leads on this !

Thanks,

Anurag



Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarApr2017

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

Custom Search