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
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: 41251FIFOs are just like magic. Best length is not 666 KiBi bytes. Like golf balls in drain pipe, but not as noisyArticle: 41252
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
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
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 FliptronicsArticle: 41255
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: 41256I 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
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
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: 41259Kevin 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. MattArticle: 41260
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
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 FAXArticle: 41262
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 FAXArticle: 41263
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: 41264Paul, 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 FAXArticle: 41265
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
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
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
Thanks you all for the good advice. YuryArticle: 41269
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
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: 41271I'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
"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 FalkArticle: 41273
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: 41274Hi, 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:
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