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
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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 100025

Article: 100025
Subject: Re: deglitching a clock
From: John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com>
Date: Sat, 01 Apr 2006 09:57:33 -0800
Links: << >>  << T >>  << A >>
On Fri, 31 Mar 2006 22:10:24 -0800, Phil Hays
<Spampostmaster@comcast.net> wrote:

>John Larkin wrote:
>
>>And we sure will be more careful about oscillators and clock
>>distribution in the future... everything's getting too fast. It was
>>probably the move of the ground plane to layer 5 of 6 (the clock is
>>mostly routed on 6), and the fast/weak xo, that caused the problem.
>>Clock-on-the-bottom isn't ideal for noise immunity, either.
>
>The change in stackup might have made the problem worse, but
>daisy-chained clocks are a bad idea with high speed logic.  It is
>better to star route them, with equal length lines from the clock
>driver to each destination with source termination resisters.  For a
>fanout greater than 1, don't use the oscillator output directly, use
>it to drive a higher drive gate.

Yup, that's about ideal.


>Daisy chaining clocks is bad for signal integrity and for clock skew.

Skew doesn't matter here, and daisy chaining is fine *if* everything
is done right, which it wasn't in this case. ECL clocks are usually
daisy-chained... many small chips and picosecond skew requirements
between nearby chips. Star fanout to 50 or so loads gets messy.

We're leaning towards slowing down the edge at the xo, maybe with an
R-C or an HC-class buffer, and adding a tiny-logic schmitt buffer at
each fpga, giving most of a volt of noise immunity. There's no room
for star traces, or at least not without a lot of ripups. If we put
the tinies on the bottom, under the fpga's, they fit nicely and we
don't have to waste a bunch of hundreds of bucks on a new solder-paste
stencil and reprogramming the pick-and-place.

Hey, the CPU has a clock-out pin, same freq as the clock-in in this
case. We could use *that* to drive the two following FPGAs in the
string. It's a 68332, ancient process cmos, swings hard and makes nice
sedate edges! May as well leave the deglitcher in there, so we don't
have to re-release the designs.


John



Article: 100026
Subject: Re: Atmel microcontroller
From: "swimmerphil1@gmail.com" <philip.hon@gmail.com>
Date: 1 Apr 2006 10:13:32 -0800
Links: << >>  << T >>  << A >>
Hi Jim and Rich,
Thanks for the replies. Rich is right, I do use fpgas for my designs.
But nonetheless, i apologize for not reading the datasheet a little
more carefully. Thanks you two; much appreciated. 

Regards, 
Phil


Article: 100027
Subject: Re: deglitching a clock
From: John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com>
Date: Sat, 01 Apr 2006 10:37:45 -0800
Links: << >>  << T >>  << A >>
On Sat, 1 Apr 2006 03:17:55 +0000 (UTC), kensmith@green.rahul.net (Ken
Smith) wrote:

>In article <p6nq22l4nf53kqanjhu7d4ojn70nb933nm@4ax.com>,
>John Larkin  <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote:
>[....]
>>I wonder if anyone has ever kluged a bga layout, sort of like one of
>>those jellyfish with a thousand tentacles.
>
>More likely it would be a costly blind-via PCB that sits between the BGA
>and the base PCB.  (Vomit)
>

One of my customers screwed up the pinout on a largish microprocessor
chip, *every pin*, and kluged it to work. It looked like a chip
sitting on a ball of red yarn.

John



Article: 100028
Subject: Re: PCB Bypass Caps
From: John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com>
Date: Sat, 01 Apr 2006 11:02:42 -0800
Links: << >>  << T >>  << A >>
On Sat, 01 Apr 2006 17:53:36 GMT, John_H <johnhandwork@mail.com>
wrote:

>rickman wrote:
>> In general, the power and ground plane coupling provides capacitance at
>> the highest frequencies where caps are too high impedance to do much
>> good.  So don't skimp on the planes, keep them as large as possible.
>> In the end you may need to add a second power layer or mix power and
>> signals just because most parts require two voltages and running split
>> power planes to the same part can be difficult.
>
>Another right answer  :-)
>
>But consider:  while the capacitance is larger to have 100 sqare inches 
>rather than 16, the point where the open edges of the PCB make the plane 
>capacitance worthless due to replections (think quarter wave antenna 
>here) is 2.5x worse.  The bulk capacitance is better but the board 
>capacitance will "open circuit" at a lower frequency.

I sometimes add SMA connector footprints to my boards so I can TDR the
bare boards and measure plane/pour noise on working boards. I've never
been able to resolve an edge reflection, using a 20 GHz TDR. I think a
typical pcb dielectric+copper structure is just too lossy. As far as I
can measure, a small-gap ground/powerplane structure behaves like an
ideal capacitor, and as you add bypasses *anywhere* on the board, it
looks like a bigger ideal capacitor. I've seen no advantage to mixing
ceramics, so I just use 0.33 uF.

>
>As Howard Johnson pointed out in last week's Xilinx webcast, that point 
>is rather moot for modern BGAs with the chips separated from the board 
>by the "masking inductance" to where those higher frequencies are a 
>problem for the BGA package or the chip itself.

Howard knows a lot of stuff, and makes up the rest.

John



Article: 100029
Subject: Re: Xilinx Schematic Entry
From: John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com>
Date: Sat, 01 Apr 2006 11:10:00 -0800
Links: << >>  << T >>  << A >>
On Fri, 31 Mar 2006 21:57:49 +0100, "Slurp" <slip@slop.slap> wrote:

>
>"John Larkin" <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote in message 
>news:ot0r22p8pdcr2g956ef1ln8h852ll9s7g2@4ax.com...
>> On 30 Mar 2006 22:22:07 -0800, "Jeff Brower" <jbrower@signalogic.com>
>> wrote:
>>
>>>John-
>>>
>>>> Except that I can flip through a 20-page schematic and not only
>>>> understand what it does, I can usually spot hazards and bugs quickly,
>>>> sometimes in seconds. Nobody can do that with a few thousand lines of
>>>> uncommented HDL.
>>>>
>>>> Parallel beats sequential, which is what FPGAs are all about.
>>>>
>>>> And if they call you Gramps, it's easy enough to fire them and hire a
>>>> fresh batch.
>>>
>>>Sure if it's OrCAD, which we use it for complex board designs.  Yes you
>>>can spot errors fast and things jump out that can save your board
>>>desgin.
>>
>> PADS has a beautiful schematic editor.
>>
>>>
>>>But ISE?  A 20 page schematic in ISE is like trying to cut concrete
>>>with knife.  You can do it, but only if you have a LOT of time on your
>>>hands, maybe for example a need to escape from prison :-)
>>>
>>
>> Well, the library symbols sure are hideous. What *were* they thinking?
>>
>> Too bad there's no universal schematic file format. Schematics would
>> be more pleasant if, for example, old Foundation schematics could be
>> imported into ISE; it's criminal that they can't.
>>
>> LT Spice seems to have a nice external ASCII file format for
>> expressing schematics.
>>
>> John
>>
>
>Now if you use the Altera Quartus schematic capture I personally believe you 
>get a superb set of tools and symbols.
>
>Here is an example I dropped together inside 3 mins, ready to synthesise. 
>Only needs the pins and device defining before I can drop it straight into a 
>part.
>
>http://www.wheelnut.plus.com/Block1_bdf.pdf
>
>I bet not many engineers cannot see what the intent is in this extreme 
>trivial example....

Very nice.

>
>..... as opposed to shedloads of VHDL which would take a week and numerous 
>sketches to work out what is going on, looking for typos and missed 
>declarations etc.

Or you can buy an expensive software thingie that turns your VHDL into
a (very, very ugly) schematic to help you understand what it does.

John



Article: 100030
Subject: Re: PCB Bypass Caps
From: "RobJ" <rsefton@abc.net>
Date: Sat, 01 Apr 2006 19:25:56 GMT
Links: << >>  << T >>  << A >>
"John Larkin" <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote in message 
news:mbit229a62jkgeffc3r9h8jgmr9ekh2s96@4ax.com...
>
> Howard knows a lot of stuff, and makes up the rest.
>
> John
>

That's hilareous, but partly true. I've been a Howie fan since Black Magic 
came out and it's been interesting to see what is gospel one year become 
anathema the next. The whole topic of high-speed design (SI, PDS design, 
modeling, etc.) reminds me of the FDA guidelines on what's good and bad to 
eat. It's all a constantly moving target, which is understandable because 
this is very complicated stuff.

After seeing some awful board stackups and PDS designs work flawlessly, I've 
concluded that a lot of the advanced art of PDS design is only needed for 
boards with super high-speed and high-current devices, like Pentium 
processors and the like. The research is driven mainly by companies like 
Sun, who deal in that area, and by the consultants and EDA tool vendors who 
have a vested interest in companies trying to follow the "state of the art" 
PDS design methodologies. Way overkill for most designs, even very large 
FPGA designs.

Signal integrity is a different story. There are tons of ways to get in 
trouble there, as I've proven to myself many times. :)

Rob 



Article: 100031
Subject: Re: deglitching a clock
From: Joerg <notthisjoergsch@removethispacbell.net>
Date: Sat, 01 Apr 2006 21:07:24 GMT
Links: << >>  << T >>  << A >>
Hello John,


> We're leaning towards slowing down the edge at the xo, maybe with an
> R-C or an HC-class buffer, and adding a tiny-logic schmitt buffer at
> each fpga, giving most of a volt of noise immunity. There's no room
> for star traces, or at least not without a lot of ripups. If we put
> the tinies on the bottom, under the fpga's, they fit nicely and we
> don't have to waste a bunch of hundreds of bucks on a new solder-paste
> stencil and reprogramming the pick-and-place.
> 

That increases phase noise. It may not matter in the digital world but I 
wouldn't do that for ADC clocks.

One technique I use if a home-run star system isn't practical is a 
nicely impedance controlled clock line (or a few) and then tapping off 
with low-C RF transistors wherever the clock is needed. It raises the 
hackles of the digital folks during design reviews but after a thorough 
explanation they like it.

That's how TV distribution used to be done in Europe, one line down from 
the roof and tapped off with -20dB couplers. At the very end there is a 
terminator. I use AC termination, mostly.

Regards, Joerg

http://www.analogconsultants.com

Article: 100032
Subject: Re: Doubt about SERDES
From: "KJ" <kkjennings@sbcglobal.net>
Date: Sat, 01 Apr 2006 21:45:01 GMT
Links: << >>  << T >>  << A >>
> Altera provides these SERDES transmit and receive functions within their 
> Mega Wizard tool box.  These packaged functions take care of all of the 
> timing needed to either receive or transmit the high speed serial data.
>
The one thing that bit me though was that the SERDES transmit/receivers is 
that the Stratix II family had no knowledge of bit alignment.relative to the 
SERDES clock.  My previous SERDES experience used discrete parts where the 
timing of each bit relative to the rising edge of the clock was defined. 
The Stratix II documentation I worked with sure implied that this was true 
also (bit as I realized later when the bite chomped down it did not directly 
say so.  Having worked with the discrete chips seeing the same drawings in 
the Stratix documentation led me astray).

With Stratix II (and maybe this is common with all SERDES other than 
discrete chips) the receive side needs to manually align the bits relative 
to the clock.  The MegaWizard brings has an optional input that you 
absolutely must use since you most likely will not power up with bits 
aligned where you want them.  Also, each SERDES channel needs to be 
individually aligned (i.e. bit 7 may show up at one spot relative to the 
clock on channel 1 but there is no guarantee that bit 7 on channel 2 will be 
there as well).

The problem then becomes how do you get the transmitter and receiver to 
'know' when they should be trying to align bits relative to the clock and 
when are you all aligned and ready to go?  That solution comes on a case by 
case basis depending on what your system is.

In hindsight this was all ignorance on my part in part caused by prior 
SERDES knowledge with the discrete chips...but thought I'd pass the 2 cents 
along.

KJ

"Rob" <robnstef@frontiernet.net> wrote in message 
news:V9lXf.4539$kg.2858@news02.roc.ny...
> Stratix has fast fabric on two sides of the chip for handling the SERDES 
> interface.  The internal logic fabric can NOT handle these high serialized 
> data rates.  One must de-serialize the data, do whatever logic is 
> necessary, and send it through a SERDES transmitter on the other side of 
> the FPGA.
>
> Altera provides these SERDES transmit and receive functions within their 
> Mega Wizard tool box.  These packaged functions take care of all of the 
> timing needed to either receive or transmit the high speed serial data.
>
> It sounds like you have 2 SERDES channels coming in and one going out; and 
> you need to select which input gets routed to the output--the FPGA is the 
> right solution for his situation.  If the input and output SERDES channels 
> have the same make up (lanes and bits / lane) and there is nothing you 
> have to do with the data, then the design is fairly staright forward. 
> Deserialize both of the input SERDES channels (using the MegaWizard 
> function) into a mux; and then connect the output of the mux  to the input 
> of the SERDES transmitter (MegaWizard function).
>
> Take care,
> Rob
>
>
> "pinku" <praveenkumar.bm@gmail.com> wrote in message 
> news:1143824706.197533.207620@u72g2000cwu.googlegroups.com...
>> Hello Groups,
>>
>> I have a 1Gbps SERDES output from the Network processor. But as i have
>> 2 SERDES signal coming from the back plane, depending of SEL line i
>> have to connect one of the SERDES to network processor. So i am using
>> FPGA to interface this, which takes a SERDES input and I have FIFO for
>> transmit FIFO, recieve FIFO and FIFO controller and this FIFO is again
>> connected to another SERDES which in turn connect to the Backplane. So
>> i need 4 SERDES for implementing it. Will this intermediate Logic
>> create for end to end SERDES data transfer ? Is there any other way of
>> implementing this logic? I am planning to use Stratix GX FPGA.
>>
>> Please let me know your suggestion,
>> waiting for your reply,
>> Kumar
>>
>
> 



Article: 100033
Subject: Re: USB Interface to Virtex-4
From: "Anonymous" <someone@microsoft.com>
Date: Sat, 01 Apr 2006 22:26:22 GMT
Links: << >>  << T >>  << A >>

"johnp" <johnp3+nospam@probo.com> wrote in message
news:1143913431.274974.10660@j33g2000cwa.googlegroups.com...
> The OP wanted a "time efficient" approach for adding USB support.
>
> I suspect trying to embed USB IP inside a FPGA does not meet
> this requirement.  Yes, you could add a USB core and a PHY and
> an embedded processor and write and debug a bunch of code....
>
> Or you could leverage parts like the Cypress FX2 that provides several
> easy approaches to doing this.
>
> Which is more "time efficient"?
>
> John Providenza
>

What's more time efficient then going to your EDK and just adding an OPB_USB
peripheral? I was just asking why such a thing doesn't appear to exist. But,
yes, I agree I strayed off topic.

-Clark



Article: 100034
Subject: Re: Configuration pins on Spartan-3
From: "Steve Knapp (Xilinx Spartan-3 Generation FPGAs)" <steve.knapp@xilinx.com>
Date: 1 Apr 2006 14:44:33 -0800
Links: << >>  << T >>  << A >>

rickman wrote:
> I just had a design review on my board and I was zinged for using
> resistors to pull the M[2:0] pins to power or ground.  I have always
> done it that way and do not see a reason to change.  But the Xilinx
> documents were shown to me, specifically XAPP453, where they clearly
> show the pins being pulled hard to power or ground.

For Spartan-3 FPGAs, it is perfectly acceptable to tie the M[2:0] pins
directly to either VCCAUX (2.5V) or to GND.  External pull-up or
pull-down resistors are also acceptable, but not required.  I tend to
use external pull-ups or pull-downs as it allows me to override the
default FPGA configuration mode on the board.  In some systems, this
may be desirable for field diagnostics, etc.

On Spartan-3E FPGAs, the M[2:0] pins _can_ be user-I/O after
configuration.  If using these pins as user-I/O, then you definitely
want to use pull-up or pull-down resistors.

BTW, the mode pins have internal pull-up resistors that are active
during configuration.  If left floating externally, the M[2:0] mode
pins will see "111" and the FPGA will be in Slave Serial configuration
mode.
---------------------------------
Steven K. Knapp
Applications Manager, Xilinx Inc.
General Products Division
Spartan-3/-3E FPGAs
http://www.xilinx.com/spartan3e
---------------------------------
The Spartan(tm)-3 Generation:  The World's Lowest-Cost FPGAs.


Article: 100035
Subject: Re: Configuration pins on Spartan-3
From: "Steve Knapp (Xilinx Spartan-3 Generation FPGAs)" <steve.knapp@xilinx.com>
Date: 1 Apr 2006 14:57:45 -0800
Links: << >>  << T >>  << A >>
The JTAG interface on Spartan-3 FPGAs are powered by the VCCAUX (2.5V)
supply.

The key limitation is to avoid back-driving the JTAG inputs.  For
example, if you apply a 3.3V input to a JTAG input, then there will be
a path back through the ESD protection diode.

There are a variety of solutions here, depending on your specific
application.

1.  If driving the JTAG interface with 2.5V, no problem.

2.  If actively driving the JTAG interface with 3.3V, be sure to use
current-limiting series resistors and it is best to park the lines low
or let them float when not in use.  You can also three-state the JTAG
pins after configuration or drive them using open-drain outputs.  The
JTAG pins have dedicated pull-up resistors to VCCAUX during
configuration.  After configuration, these pull-up resistors are left
enabled by default.  Via bitstream options, you can also change these
to pull-down resistors or turn them off.
---------------------------------
Steven K. Knapp
Applications Manager, Xilinx Inc.
General Products Division
Spartan-3/-3E FPGAs
http://www.xilinx.com/spartan3e
---------------------------------
The Spartan(tm)-3 Generation:  The World's Lowest-Cost FPGAs.


Article: 100036
Subject: Re: Concatenate String in Verilog?
From: sharp@cadence.com
Date: 1 Apr 2006 15:18:32 -0800
Links: << >>  << T >>  << A >>
To concatenate strings in Verilog, you can generally just use vector
concatenation of the regs containing the string values.  However, you
should remain aware that it is not really a string concatenation,
because that matters in some situations.  For example, if you tried to
do

reg [8*80:1] dir_name, file_name, full_name;

initial
begin
  dir_name = "./mydir/";
  file_name = "file.dat";
  full_name = {dir_name, file_name};
  $display("%s", full_name);
end

This won't work, because file_name is not just "file.dat".  It is
"file.dat" with an extra 70 null or zero bytes in front of it.  Those
extra nulls will appear in the concatenation too.  That 160 byte wide
concatenation will get truncated back to 80 bytes when assigned to
full_name, losing the part from dir_name entirely.  But if you declared
file_name to be 10 bytes, dir_name to be 70 bytes, and full_name to be
80 bytes, then everything would fit without any truncation.

Note that this also relies on the tools to ignore the embedded null
characters in the full name when it is passed to a system task like
$readmem, which some might not do.

Another way to build filenames with Verilog-2001 would be to use
$swrite to print the filename, including numbers from loop counters,
into a reg variable.


Article: 100037
Subject: Re: Spartan3E Phase-Shifter
From: "Steve Knapp (Xilinx Spartan-3 Generation FPGAs)" <steve.knapp@xilinx.com>
Date: 1 Apr 2006 15:36:26 -0800
Links: << >>  << T >>  << A >>
oen_no_spam@yahoo.com.br wrote:
> I have some doubts about the SPT3E Phase Shifter.
>
> First:
> Data sheet V3.0, pg. 54, fig. 44: CLK180 is wrong. I must start as
> high! (easy to see)

To quote the immortal Homer Simpson, "Doh!"  I'll see that this is
fixed!
>
> Data sheet V3.0, pg. 57, eq. 6: MAX_STEPS =
> +/-[integer(20*(TCLKIN-3ns))]
> For example a 20MHz clock, TCLKIN=50ns
> MAX_STEPS = +/-[integer(20*47n)] = +/-[integer(940*10E-9)] = +/- 0
>
> Only seeing the "Answer Record: 22414" I understood.
> How about changing it to: MAX_STEPS =
> +/-[integer(20*10E9*(TCLKIN-3ns))] ?

Is the confusion with the "ns" term in the equation?   It was added
only to emphasize that the equation is operating in time, not
frequency.

> Now my doubts.
> What happens when we overflow the Phase Shifter?
> For the same 20MHz clock, MAX_STEPS = +/-940.
> And if I shift 941 times (same direction form zero) ?

The output will be phase shifted by 940 steps.  The DCM outputs no
longer shift when incremented, but will decrement.

>
> >From the data sheet, PSCLK_FREQ (phase shift frequency input) ranges
> from 1MHz to 167MHz.
> For 1MHz: MAX_STEPS = +/-19940
> There must be at least 19940 internal delay taps (for each side)!
> So I can go past 940 (the shifter doesn't know the frequency of the
> clock, I think).

The phase shift limit is frequency dependent.  The equation uses the
clock period, which is inversely proportional to the clock frquency.

The phase shifting range depends on the CLKIN input, not the PSCLK.
The minimum CLKIN frequency is 5 Mz, which equates to +/-3,940 steps.
Each step, called DCM_DELAY_STEP, is between 20 to 40 ps.  The VARIABLE
phase shfit mode provide a phase shift range of between +/- (3,940 * 20
ps) to +/- (3,940 * 40 ps) or between +/- 78.8 ns to 157.6 ns.

The confusing difference between the Virtex-II/Spartan-3 variable phase
shifter and the Spartan-3E variable phase shifter is that
Virtex-II/Spartan-3 shifts by fraction of a period, the Spartan-3E
variable phase shift always shifts by time.

The FIXED phase shift mode for Virtex-II, Spartan-3, and Spartan-3E are
always measured in fraction of a clock period.

> Again the 20MHz clock.
> As MAX_STEPS = +/-940, the phase shift ranges from 940*20ps=18.8ns to
> 940*40ps=37.6ns, both below 50ns (TCLKIN).
> If 940 is the limit, how can the phase shifter, in the fixed mode,
> cover all the range from 0 to 2*pi (or 360 degrees, if you prefer)?

In FIXED phase shift mode, the Spartan-3E phase shifter works over the
range -180 degress to +180 degrees.  For software compatibility, this
range is mapped to the Virtex-II/Spartan-3 range of -360 to +360
degrees.

> I want to know if there is a way of changing the phase continuously,
> crossing the borders of +/-2*N*pi smoothly (from 2*pi back to zero).

I have a clarifying question on your question.  Are you using VARIABLE
phase shift mode to shift beyond -360 or +360 degrees and asking what
happens when you exceed a full period?

---------------------------------
Steven K. Knapp
Applications Manager, Xilinx Inc.
General Products Division
Spartan-3/-3E FPGAs
http://www.xilinx.com/spartan3e
Tel:  (408) 626-7447
E-mail: steve.knapp@xilinx.com
---------------------------------
The Spartan(tm)-3 Generation:  The World's Lowest-Cost FPGAs.


Article: 100038
Subject: Re: KEEP_HIERARCHY
From: "motty" <mottoblatto@yahoo.com>
Date: 1 Apr 2006 16:04:45 -0800
Links: << >>  << T >>  << A >>
I actually synched both the data and the trigger.  I can see how that
would produce the same erros though.  I guess I chalk it up to working
b/c of P and R differences.

I should probably go back and put a holding register in the 26 MHz
module and just resynch the trigger into the 38.4 domain using a couple
of flip flops.  The shift register still shifts in data when it
triggers the state machine (I can't lose a bit and the data stream is
continuous - until the enable goes low).  I guess it is VERY possible
that the data is sometimes unstable when it crosses into the 38.4
domain.  There is only one 26 MHz cycle available for this, and
depending on the phase relationship of the two clocks, I could see
timing issues arrising.  Putting a holding register in plus the trigger
synch flops in the 38.4 module should allow plenty of time for the data
to be stable.

Thanks all for the replys!! .


Article: 100039
Subject: Re: deglitching a clock
From: "Rob" <robnstef@frontiernet.net>
Date: Sun, 02 Apr 2006 01:44:15 GMT
Links: << >>  << T >>  << A >>
> Eventually the penny dropped - the significant parameter was not the
> probe's capacitance, but its _weight_. Somehow, of about 6000 joints on
> that board, this one had missed out on its dose of solder paste.
> A tiny spot of solder, and all was well.

I've had that happen, too!  I laughed out loud reading your post.  It is 
good to know that others in the world have gone through the same pain :) !

Take care,
Rob

"Brian Drummond" <brian_drummond@btconnect.com> wrote in message 
news:8prs22p57q2c8g5c1bcpfea9obbt7annhe@4ax.com...
> On Sat, 01 Apr 2006 03:51:26 GMT, "Rob" <robnstef@frontiernet.net>
> wrote:
>
>>> Interestingly, the fpga glitch stopped when the TDS probe was touched
>>> on the clock pin of the 2nd FPGA, which added about 0.5 pF.
>>
>>I hate when that happens :)
>
> Yup.
>
> I spent most of the night once on such a problem, on a SOIC on my first
> big SMT board. Probing anywhere else on the net - even a via half an
> inch away - didn't fix the problem, nor did series termination, parallel
> termination, or capacitive loading on the via.
>
> Eventually the penny dropped - the significant parameter was not the
> probe's capacitance, but its _weight_. Somehow, of about 6000 joints on
> that board, this one had missed out on its dose of solder paste.
> A tiny spot of solder, and all was well.
>
> - Brian 



Article: 100040
Subject: Re: deglitching a clock
From: "Michael A. Terrell" <mike.terrell@earthlink.net>
Date: Sun, 02 Apr 2006 02:27:33 GMT
Links: << >>  << T >>  << A >>
Joerg wrote:
> 
> Hello John,
> 
> > We're leaning towards slowing down the edge at the xo, maybe with an
> > R-C or an HC-class buffer, and adding a tiny-logic schmitt buffer at
> > each fpga, giving most of a volt of noise immunity. There's no room
> > for star traces, or at least not without a lot of ripups. If we put
> > the tinies on the bottom, under the fpga's, they fit nicely and we
> > don't have to waste a bunch of hundreds of bucks on a new solder-paste
> > stencil and reprogramming the pick-and-place.
> >
> 
> That increases phase noise. It may not matter in the digital world but I
> wouldn't do that for ADC clocks.
> 
> One technique I use if a home-run star system isn't practical is a
> nicely impedance controlled clock line (or a few) and then tapping off
> with low-C RF transistors wherever the clock is needed. It raises the
> hackles of the digital folks during design reviews but after a thorough
> explanation they like it.
> 
> That's how TV distribution used to be done in Europe, one line down from
> the roof and tapped off with -20dB couplers. At the very end there is a
> terminator. I use AC termination, mostly.
> 
> Regards, Joerg
> 
> http://www.analogconsultants.com


   CATV systems still use backmatched taps, but the tap value drops the
further you get from the amp.  the systems I worked with were designed
for a +10 dBm signal at the port on the tap to allow for four TVs per
drop, and up to 4 dB loss in the drop and house wiring.  It was an
average sized system with 10,000 active drops, and 4,000 homes passed
that didn't have service.


-- 
Service to my country? Been there, Done that, and I've got my DD214 to
prove it.
Member of DAV #85.

Michael A. Terrell
Central Florida

Article: 100041
Subject: Re: Doubt about SERDES
From: "Rob" <robnstef@frontiernet.net>
Date: Sun, 02 Apr 2006 02:30:14 GMT
Links: << >>  << T >>  << A >>
KJ,

> The one thing that bit me though was that the SERDES transmit/receivers is 
> that the Stratix II family had no knowledge of bit alignment.relative to 
> the SERDES clock.

Of course the FPGA doesn't have any knowledge of the bit stream; which is 
why you have to tell it where the data is in relation to the rising edge of 
the clock.  In the case of a receiver, the MegaWizard function gives you the 
option of choosing 0, 45, 90, 135, 180, 225, 270, & 315 degrees.  This is 
possible because the Wizard funcion uses a PLL to strip the data from the 
serialized stream.  Most discrete SERDES type chips, like National's 90CR 
types, align the data with the rising edge of the PLL clock.  In this case 
you would setup the FPGA's receiver to have 0 degree phase between the data 
and the clock, which will tell Quartus to latch the data on the falling edge 
of the receiver's PLL clock.

I've used this functionality about 1/2 dozen times over the last year and 
have NEVER had a problem.  I've interefaced with National parts and other 
FPGA (which simulated National parts).

>Also, each SERDES channel needs to be individually aligned (i.e. bit 7 may 
>show up at one spot relative to the clock on channel 1 but there is no 
>guarantee that bit 7 on channel 2 will be there as well).

If this is the case then the data coming into the FPGA probably has too much 
skew between the lanes.  This is not the FPGA's problem.  The receiver 
assumes that all the lanes are aligned.  If they're not then one has to play 
games with the timing on each lane--not fun (I've been there). Also remember 
that all systems like this get affected by clock jitter, cable skew, and 
flop setup/hold times: all of which contribute to the RSKM (receiver skew 
margin).

Take care,
Rob

"KJ" <kkjennings@sbcglobal.net> wrote in message 
news:xvCXf.50568$2O6.3316@newssvr12.news.prodigy.com...
>> Altera provides these SERDES transmit and receive functions within their 
>> Mega Wizard tool box.  These packaged functions take care of all of the 
>> timing needed to either receive or transmit the high speed serial data.
>>
> The one thing that bit me though was that the SERDES transmit/receivers is 
> that the Stratix II family had no knowledge of bit alignment.relative to 
> the SERDES clock.  My previous SERDES experience used discrete parts where 
> the timing of each bit relative to the rising edge of the clock was 
> defined. The Stratix II documentation I worked with sure implied that this 
> was true also (bit as I realized later when the bite chomped down it did 
> not directly say so.  Having worked with the discrete chips seeing the 
> same drawings in the Stratix documentation led me astray).
>
> With Stratix II (and maybe this is common with all SERDES other than 
> discrete chips) the receive side needs to manually align the bits relative 
> to the clock.  The MegaWizard brings has an optional input that you 
> absolutely must use since you most likely will not power up with bits 
> aligned where you want them.  Also, each SERDES channel needs to be 
> individually aligned (i.e. bit 7 may show up at one spot relative to the 
> clock on channel 1 but there is no guarantee that bit 7 on channel 2 will 
> be there as well).
>
> The problem then becomes how do you get the transmitter and receiver to 
> 'know' when they should be trying to align bits relative to the clock and 
> when are you all aligned and ready to go?  That solution comes on a case 
> by case basis depending on what your system is.
>
> In hindsight this was all ignorance on my part in part caused by prior 
> SERDES knowledge with the discrete chips...but thought I'd pass the 2 
> cents along.
>
> KJ
>
> "Rob" <robnstef@frontiernet.net> wrote in message 
> news:V9lXf.4539$kg.2858@news02.roc.ny...
>> Stratix has fast fabric on two sides of the chip for handling the SERDES 
>> interface.  The internal logic fabric can NOT handle these high 
>> serialized data rates.  One must de-serialize the data, do whatever logic 
>> is necessary, and send it through a SERDES transmitter on the other side 
>> of the FPGA.
>>
>> Altera provides these SERDES transmit and receive functions within their 
>> Mega Wizard tool box.  These packaged functions take care of all of the 
>> timing needed to either receive or transmit the high speed serial data.
>>
>> It sounds like you have 2 SERDES channels coming in and one going out; 
>> and you need to select which input gets routed to the output--the FPGA is 
>> the right solution for his situation.  If the input and output SERDES 
>> channels have the same make up (lanes and bits / lane) and there is 
>> nothing you have to do with the data, then the design is fairly staright 
>> forward. Deserialize both of the input SERDES channels (using the 
>> MegaWizard function) into a mux; and then connect the output of the mux 
>> to the input of the SERDES transmitter (MegaWizard function).
>>
>> Take care,
>> Rob
>>
>>
>> "pinku" <praveenkumar.bm@gmail.com> wrote in message 
>> news:1143824706.197533.207620@u72g2000cwu.googlegroups.com...
>>> Hello Groups,
>>>
>>> I have a 1Gbps SERDES output from the Network processor. But as i have
>>> 2 SERDES signal coming from the back plane, depending of SEL line i
>>> have to connect one of the SERDES to network processor. So i am using
>>> FPGA to interface this, which takes a SERDES input and I have FIFO for
>>> transmit FIFO, recieve FIFO and FIFO controller and this FIFO is again
>>> connected to another SERDES which in turn connect to the Backplane. So
>>> i need 4 SERDES for implementing it. Will this intermediate Logic
>>> create for end to end SERDES data transfer ? Is there any other way of
>>> implementing this logic? I am planning to use Stratix GX FPGA.
>>>
>>> Please let me know your suggestion,
>>> waiting for your reply,
>>> Kumar
>>>
>>
>>
>
> 



Article: 100042
Subject: Re: deglitching a clock
From: "Michael A. Terrell" <mike.terrell@earthlink.net>
Date: Sun, 02 Apr 2006 02:32:13 GMT
Links: << >>  << T >>  << A >>
John Larkin wrote:
> 
> Hey, the CPU has a clock-out pin, same freq as the clock-in in this
> case. We could use *that* to drive the two following FPGAs in the
> string. It's a 68332, ancient process cmos, swings hard and makes nice
> sedate edges! May as well leave the deglitcher in there, so we don't
> have to re-release the designs.


   The MC68340 is the same family as the MC68332.  I saw a lot of
MC68340 on the embedded controllers we built for the Microdyne 700 &
1620 series of telemetry equipment, as well as a satellite tracking
controller that used a modified version of the same custom controller. 
They made a layout error for the 32,768 Hz oscillator that no one had
noticed.  It caused starting problems, and there was no way to fix it
without changing the board layout.


-- 
Service to my country? Been there, Done that, and I've got my DD214 to
prove it.
Member of DAV #85.

Michael A. Terrell
Central Florida

Article: 100043
Subject: Re: KEEP_HIERARCHY
From: "johnp" <johnp3+nospam@probo.com>
Date: 1 Apr 2006 19:36:02 -0800
Links: << >>  << T >>  << A >>
Let us know if the holding register scheme helps!

John Providenza


Article: 100044
Subject: Re: Hierarchical FSM?
From: "Mike Treseler" <mike_treseler@comcast.net>
Date: Sat, 01 Apr 2006 23:11:52 -0800
Links: << >>  << T >>  << A >>
Davy wrote:

> I am new to hierarchical FSM design.
> Is there any paper or guideline for design hierarchical FSM?
> Any suggestions will be appreciated!

I would suggest that if your state machine
needs a hierarchy, there is likely a simpler
logic description possible, using multiple
process variables, not all of them enumerated.

        -- Mike Treseler

Article: 100045
Subject: Re: ModelSim Designer
From: "Mike Treseler" <mike_treseler@comcast.net>
Date: Sun, 02 Apr 2006 00:01:53 -0800
Links: << >>  << T >>  << A >>
RobJ wrote:

> I found out that HDL Designer is really what I'm looking for, 

I suggest a full evaluation with a real design
to validate that idea.

> Have you used HDL Designer? Any comments on it?

I did an evaluation, but settled on emacs vhdl-mode
which is non-graphical, but covers much of the
same ground for free.

With HDL designer I did not enjoy fussing
with wires and attaching text to graphical
views to get the code to come out right.

In vhdl-mode, I especially like the templates,
the port copy/paste functions, and the Makefile
generation for simulation.

         -- Mike Treseler

Article: 100046
Subject: Re: JTAG programing specs for XC18V01 PROM
From: Petter Gustad <newsmailcomp6@gustad.com>
Date: 02 Apr 2006 12:42:58 +0200
Links: << >>  << T >>  << A >>
"David Colson" <dscolson@rcn.com> writes:

> This is the ieee1532 bsdl file that describes the programming
> algorithm. for the xc18v00. Using this file and an understanding of
> the JTAG interface, you maybe able to decipher how to program your
> device.

The BSDL file does not describe the programming algorithm. It just
describes the boundry scan registers (some which are used for
programming).

I would not call this decipher, but using the SVF file and the JTAG
state machine you can extract how to program the device. The SVF file
describes how to select the programming registers and the contents of
these registers, the JTAG state machine describes how to shift data
into boundry-scan registers.

e.g. if you toggle TMS and TDI according to this model:

http://www.gustad.com/petter/18v01.v

you should end up with what is described by the SVF given by the O.P.

Petter
-- 
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

Article: 100047
Subject: Re: KEEP_HIERARCHY
From: "Nial Stewart" <nial@XXXXnialstewartdevelopments.co.uk>
Date: Sun, 2 Apr 2006 11:47:03 +0100
Links: << >>  << T >>  << A >>
> I should probably go back and put a holding register in the 26 MHz
> module and just resynch the trigger into the 38.4 domain using a couple
> of flip flops.

I had assumed you were transferring the data to an output_register(95..0)
in the 26 MHz domain at the same time as you generate the 'data ready'
signal.

> The shift register still shifts in data when it
> triggers the state machine (I can't lose a bit and the data stream is
> continuous - until the enable goes low).  I guess it is VERY possible
> that the data is sometimes unstable when it crosses into the 38.4
> domain.  There is only one 26 MHz cycle available for this, and
> depending on the phase relationship of the two clocks, I could see
> timing issues arrising.  Putting a holding register in plus the trigger
> synch flops in the 38.4 module should allow plenty of time for the data
> to be stable.

Exaclty, you can re-time the enable signal into the 38MHz domain
a number of clock cycles so the data should be settled at the 38MHz
register inputs.

Nial.


>
> Thanks all for the replys!! .
>



Article: 100048
Subject: Re: Xilinx SelectMAP problem
From: "jenze" <jenze@et.upb.de>
Date: 2 Apr 2006 06:26:17 -0700
Links: << >>  << T >>  << A >>
Hi smu,

usually this behavior is caused by incorrect data loaded into the
device. The BUSY Signal will be driven high some CCLK cycles after the
incorrect data has been loaded into the device. Have you checked the
data alignment (D0=MSB), correct assertion/deassertion of CS#, and the
setup/hold times on the select map interface?

Regards

Jens

smu schrieb:

> Hi,
>
> I have developed board with a Spartan 2E. The Spartan is configured by
> an antifuse fpga with the SelectMAP mode. The configuration of M[2:0] is
> ok. The configuration stream is transferred at 2.5MBytes/s.
> It said in the datasheet that the busy flag is provide for frequency
> above 50MHz. But in my design, I see a high level on the busy flag.
>
> Somebody saw this kind of phenomena on Spartan 2E device?
> What was the origin of this phenomenon?
> 
> Thank you in advance
> 
> smu


Article: 100049
Subject: Re: ModelSim Designer
From: Brian Drummond <brian_drummond@btconnect.com>
Date: Sun, 02 Apr 2006 14:48:01 +0100
Links: << >>  << T >>  << A >>
On Sat, 01 Apr 2006 15:58:04 GMT, "RobJ" <rsefton@abc.net> wrote:

>"Brian Drummond" <brian_drummond@btconnect.com> wrote in message 
>news:fnss22hl486nr858dj1b4bkj3d7bg550qc@4ax.com...
>> On Fri, 31 Mar 2006 16:05:11 GMT, "RobJ" <rsefton@abc.net> wrote:
>>
>>>Anyone using this tool from Mentor? If so, any comments about it would be
>>>much appreciated. And any comments on how ModelSim + ModelSim Designer
>>>compares to Aldec's Active-HDL environment would be even better. I 
>>>currently
>>>own ModelSim but am looking for a more complete environment (testbench
>>>automation, graphical tools, code coverage, etc.).
>>>
>>>Thanks,
>>>Rob
>>
>> It's OK, but it won't work with designs from older versions of HDL
>> Designer or Renoir. This wasn't made clear when I bought it, so I am
>> using it as a Modelsim seat alongside my (legacy) HDL Designer.
>>
>> - Brian
>
>Hi Brian -
>
>Ends up I misunderstood what ModelSim Designer is. I thought it was a 
>product that runs with ModelSim, but adds new features (automated testbench 
>generation, HDL to graphics, etc.). I talked at length with a Mentor sales 
>person yesterday and Designer is a stand-alone simulator and development 
>environment meant to attract the "low-end" FPGA crowd (like me) away from 
>Active-HDL. They just lowered the price from $5500 to $2500, so it caught my 
>interest. But I already own ModelSim so I'm not looking to replace it. I 
>found out that HDL Designer is really what I'm looking for, but HDL Designer 
>is a $17.5K tool.
>
>Have you used HDL Designer? Any comments on it?

Can't comment on the new versions, I'm still using the transition
version from Renoir (which dates from 2001).

I agree with Mike that some of it is clunky, like adding text to
graphical blocks for the this you can't deal with in wiring.

Strong plus points : 

(1) Viewing/drawing block diagrams and state machines gives me a very
clear view of the design, which helps me handle the complexity.

(2) Code generation from these blocks means I have very little contact
with the alleged verbosity of VHDL. (And when I do, it's helping me by
providing clarity, instead of making me type long words)

Neutral points:

(1) Creating and using components works well and greatly encourages
re-use.
I make this neutral because when I started (1998), I created components
at a low level of abstraction - even down to a parameterisable pipeline
register. And re-used them in higher level blocks, etc - to give quite a
deep hierarchy.

Not necessarily a bad thing, but somewhat opposed to e.g. Mike
Treseler's "one process" style. These are two approaches to the same
goal - minimising complexity, so to some extent, using one renders the
other less important.

On the other hand, this hierarchy can be allowed to persist through the
tools, and greatly aids floorplanning, and creating RPMs.

So to me it's positive overall, but I recognise that's open to debate.


Negative points. (May have been addressed in new versions)

(1) Allows creation of either "blocks" (compile to entity/arch pairs)
for direct instantiation, or "components" for component instantiation,
which is deprecated in some styles. 
Aside: I don't know why component instantiation is deprecated ... is it
just verbose? If so, that's less important here... (see plus point 2
above)

The trouble is

(a) Navigating "up" from a block moves to the parent (instantiating)
block; "up" from a component, just to the component's symbol itself.
Annoying, especially if you just moved "down" into the component from a
parent. I can see why ... a component may have many parents. But this is
really just an excuse for the developers not to maintain a navigation
trail, so it's really not an acceptable excuse.

(b) Blocks cannot be copied or moved to different libraries or re-used
in other than the original instantiating block. Unless you convert them
to components. (And then, if you move the component into a different
library, you also need to convert every block instantiated within it!)

Thus in the longer term, blocks tend to be self-deprecating.


(2) There are some vaguely useful concepts like "bundles" of signals
that are implemented in a half-assed way, and tend to atrophy with newer
versions. These should map neatly onto VHDL records, but don't. They
should also allow mixe signal directions and port types, like Data,
Address, Req, Ack (InOut, Out, Out, In), but don't. And so on...



My gripes aren't actually fundamental to the concept, but specific to
the implementation. And haven't changed much in years.

But overall I'm with Hans that I'd definitely not want to work without
it.

I don't know how much use this is to you, given the version differences.
But I'd question the value of the full product, and ask if Modelsim
Designer doesn't give you most of what you need (basic non-graphical
VHDL import, block diagrams, and state machines) as well as another
Modelsim seat (full function PE as far as I can tell). 

As I said, I've ended up simply using it as ModelSim, but I believe I'd
have been satisfied with it - IF - I didn't have a legacy database.

- Brian



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
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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