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 152725

Article: 152725
Subject: Microblaze Resources such as BRAMS, LUTS
From: "hrishi24h" <hrishi24h@n_o_s_p_a_m.gmail.com>
Date: Tue, 11 Oct 2011 13:30:48 -0500
Links: << >>  << T >>  << A >>
Hello all,

I am a newbie in the FPGA stuff!.. 

I wanted to know some FPGA resource consumption by the microblaze but could
not find some specific details such as how much BRAMS does it take (with
minimal configuration) ?...I checked other documents but they had its
architecture but not these resource consumption details!...

Also, I installed ISE Design suite 13.2 Embedded Kit ( License type:
Evaluation). And followed base system builder guidelines for spartan 6
board with microblaze (My OS is Win 7). But I could not create netlist and
design summary.. Is this because of the evaluation license issue ?   

Also could anyone suggest a weblink or source where I can start learning
from basics about the FPGA development toolkit ?...


Thanks you,
Hrishi


	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 152726
Subject: Re: Microblaze Resources such as BRAMS, LUTS
From: Gabor <gabor@szakacs.invalid>
Date: Tue, 11 Oct 2011 18:13:00 -0400
Links: << >>  << T >>  << A >>
hrishi24h wrote:
> Hello all,
> 
> I am a newbie in the FPGA stuff!.. 
> 
> I wanted to know some FPGA resource consumption by the microblaze but could
> not find some specific details such as how much BRAMS does it take (with
> minimal configuration) ?...I checked other documents but they had its
> architecture but not these resource consumption details!...

BRAM for MicroBlaze depends to a large extent on how much instruction
memory you assign during the BSB process.

> 
> Also, I installed ISE Design suite 13.2 Embedded Kit ( License type:
> Evaluation). And followed base system builder guidelines for spartan 6
> board with microblaze (My OS is Win 7). But I could not create netlist and
> design summary.. Is this because of the evaluation license issue ?   
> 

In my experience evaluation licenses have done everything you can
do with a full license, with the possible exception of creating
a bitstream.  So I don't think the netlist generation problem is
from the license.  On the other hand Windows 7 Professional is the
only W7 officially supported for ISE.  There may be some issues
using WIndows 7 Home...

> Also could anyone suggest a weblink or source where I can start learning
> from basics about the FPGA development toolkit ?...
> 
> 
> Thanks you,
> Hrishi
> 
> 
> 	   
> 					
> ---------------------------------------		
> Posted through http://www.FPGARelated.com

Article: 152727
Subject: Re: Microblaze Resources such as BRAMS, LUTS
From: Martin Thompson <martin.j.thompson@trw.com>
Date: Wed, 12 Oct 2011 08:41:16 +0100
Links: << >>  << T >>  << A >>
"hrishi24h" <hrishi24h@n_o_s_p_a_m.gmail.com> writes:

> Hello all,
>
> I am a newbie in the FPGA stuff!.. 
>
> I wanted to know some FPGA resource consumption by the microblaze but could
> not find some specific details such as how much BRAMS does it take (with
> minimal configuration) ?...I checked other documents but they had its
> architecture but not these resource consumption details!...

It depends on the cache size you choose.  AFAIK the core CPU doesn't
need any BRAMs at all.

There's also the instruction/data memory that you may hang off the LMB,
which also takes up BRAMs, but isn't technically part of microblaze.

>
> Also, I installed ISE Design suite 13.2 Embedded Kit ( License type:
> Evaluation). And followed base system builder guidelines for spartan 6
> board with microblaze (My OS is Win 7). But I could not create netlist and
> design summary.. Is this because of the evaluation license issue ?   
>

I doubt it - evaluation license may stop you at the bsitstream phase,
but not the netlisting. Post the error messages...

Cheers,
Martin

-- 
martin.j.thompson@trw.com 
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.conekt.co.uk/capabilities/39-electronic-hardware

Article: 152728
Subject: Spartan changes in glitch sensitivity
From: Jon Elson <elson@pico-systems.com>
Date: Wed, 12 Oct 2011 23:26:30 -0500
Links: << >>  << T >>  << A >>
Hello, all, I know this refers to graveyard parts, but
we have reason to keep using them.

Anyway, I made a new batch of motherboards that use a 5 V Spartan
as the slot select control logic.  I have made over 20 of these
before.  i did a revision of the design, but this particular area
had no schematic change, and I really didn't move any traces,
either.  I do have a case for bus reflections, as the bus is
16 inches long.  The FPGA detects unoccupied card slots and jumps
serial config strings across the empty positions, and also has
some serial config registers on the FPGA.  Well, this newest
version worked erratically, and after a couple days working with
it, I figured out reflections on the serial clock that goes to all
board slots plus the FPGA were double-clocking the FPGA.  I patched
a series termination resistor on the output of the driver, and
the board now works perfectly.

So, what caused this change?  I'm fairly sure the board layout is
not to blame.  The older boards were made with 2003 Spartan
XCS20-3PQ208C chips, the newer ones were made with 2009 vintage
chips, otherwise the same designation, and just purchased a few
weeks ago from Avnet.  Could a more recent fab run at Xilinx
have been made with significantly different speeds in the I/O?
Of course, this COULD just be a circuit that was so close to the
edge that I've just been really lucky, but I did make 20+ of these
with no sign of this problem before.

(This is a 6-layer board, always made at the same board house.)

Jon

Article: 152729
Subject: Re: Spartan changes in glitch sensitivity
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Thu, 13 Oct 2011 04:50:59 +0000 (UTC)
Links: << >>  << T >>  << A >>
Jon Elson <elson@pico-systems.com> wrote:

> Anyway, I made a new batch of motherboards that use a 5 V Spartan
> as the slot select control logic.  I have made over 20 of these
> before.  i did a revision of the design, but this particular area
> had no schematic change, and I really didn't move any traces,
> either.  I do have a case for bus reflections, as the bus is
> 16 inches long.  
(snip)
> version worked erratically, and after a couple days working with
> it, I figured out reflections on the serial clock that goes to all
> board slots plus the FPGA were double-clocking the FPGA.  I patched
> a series termination resistor on the output of the driver, and
> the board now works perfectly.

I don't know any specifics about the chips, but certainly faster
switching outputs could cause reflection problems.  Series 
termination is often needed on lines much shorter than 16in.
With a dielectric constant of about 2.5, that is in the 4ns to 5ns
range, which is easily slow enough to double clock those.

> So, what caused this change?  I'm fairly sure the board layout is
> not to blame.  The older boards were made with 2003 Spartan
> XCS20-3PQ208C chips, the newer ones were made with 2009 vintage
> chips, otherwise the same designation, and just purchased a few
> weeks ago from Avnet.  

-- glen

Article: 152730
Subject: Re: Spartan changes in glitch sensitivity
From: Jim Granville <j.m.granville@gmail.com>
Date: Thu, 13 Oct 2011 00:36:37 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Oct 13, 5:26=A0pm, Jon Elson <el...@pico-systems.com> wrote:
>=A0Could a more recent fab run at Xilinx
> have been made with significantly different speeds in the I/O?

 It does not need to be 'significantly' in absolute terms, just enough
to trigger the problem :)

 You can build a ring oscillator test cell, to check the raw MHz of
the silicon, and see if that differs by much.

 I think Xilinx parts had a small hystereis, so maybe that varied ?
6 years is a reasonable time too, so the exact same fab line is
unlikely to have been used.
-jg

Article: 152731
Subject: Re: Spartan changes in glitch sensitivity
From: "RCIngham" <robert.ingham@n_o_s_p_a_m.n_o_s_p_a_m.gmail.com>
Date: Thu, 13 Oct 2011 07:11:33 -0500
Links: << >>  << T >>  << A >>
>Hello, all, I know this refers to graveyard parts, but
>we have reason to keep using them.
>
>Anyway, I made a new batch of motherboards that use a 5 V Spartan
>as the slot select control logic.  I have made over 20 of these
>before.  i did a revision of the design, but this particular area
>had no schematic change, and I really didn't move any traces,
>either.  I do have a case for bus reflections, as the bus is
>16 inches long.  The FPGA detects unoccupied card slots and jumps
>serial config strings across the empty positions, and also has
>some serial config registers on the FPGA.  Well, this newest
>version worked erratically, and after a couple days working with
>it, I figured out reflections on the serial clock that goes to all
>board slots plus the FPGA were double-clocking the FPGA.  I patched
>a series termination resistor on the output of the driver, and
>the board now works perfectly.
>
>So, what caused this change?  I'm fairly sure the board layout is
>not to blame.  The older boards were made with 2003 Spartan
>XCS20-3PQ208C chips, the newer ones were made with 2009 vintage
>chips, otherwise the same designation, and just purchased a few
>weeks ago from Avnet.  Could a more recent fab run at Xilinx
>have been made with significantly different speeds in the I/O?
>Of course, this COULD just be a circuit that was so close to the
>edge that I've just been really lucky, but I did make 20+ of these
>with no sign of this problem before.
>
>(This is a 6-layer board, always made at the same board house.)
>
>Jon
>

Does the 'old' design with the 'new' chips fail?
Does the 'new' design with the 'old' chips fail?
Does the 'new' design use a newer version of ISE than before?

Slight changes in logic can cause surprisingly large changes in placement
and routing. Changes in ISE version can cause large changes in placement
and routing.
	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 152732
Subject: Re: Spartan changes in glitch sensitivity
From: Gabor <gabor@szakacs.invalid>
Date: Thu, 13 Oct 2011 10:47:20 -0400
Links: << >>  << T >>  << A >>
Jon Elson wrote:
> Hello, all, I know this refers to graveyard parts, but
> we have reason to keep using them.
> 
> Anyway, I made a new batch of motherboards that use a 5 V Spartan
> as the slot select control logic.  I have made over 20 of these
> before.  i did a revision of the design, but this particular area
> had no schematic change, and I really didn't move any traces,
> either.  I do have a case for bus reflections, as the bus is
> 16 inches long.  The FPGA detects unoccupied card slots and jumps
> serial config strings across the empty positions, and also has
> some serial config registers on the FPGA.  Well, this newest
> version worked erratically, and after a couple days working with
> it, I figured out reflections on the serial clock that goes to all
> board slots plus the FPGA were double-clocking the FPGA.  I patched
> a series termination resistor on the output of the driver, and
> the board now works perfectly.
> 
> So, what caused this change?  I'm fairly sure the board layout is
> not to blame.  The older boards were made with 2003 Spartan
> XCS20-3PQ208C chips, the newer ones were made with 2009 vintage
> chips, otherwise the same designation, and just purchased a few
> weeks ago from Avnet.  Could a more recent fab run at Xilinx
> have been made with significantly different speeds in the I/O?
> Of course, this COULD just be a circuit that was so close to the
> edge that I've just been really lucky, but I did make 20+ of these
> with no sign of this problem before.
> 
> (This is a 6-layer board, always made at the same board house.)
> 
> Jon

Over the years, without "changing" the process, the fab houses do
a better job of producing parts that fall into the highest speed
grade bin.  In 2003 when you ordered a -3 part, it was therefore
more probable that this part did not meet the -4 speedgrade than
it is now with the 2009 parts.  In other words, your 2009 "-3" chips
were *tested* to the -3 speed grade requirements, but most probably
*meet* the -4 speedgrade.  Xilinx has commented on increased yields
over the life of newer products, and I don't see why Spartan parts
would be any different.

-- Gabor

Article: 152733
Subject: Re: Spartan changes in glitch sensitivity
From: Jon Elson <jmelson@wustl.edu>
Date: Thu, 13 Oct 2011 17:48:36 -0500
Links: << >>  << T >>  << A >>
On 10/13/2011 07:11 AM, RCIngham wrote:

>
> Does the 'old' design with the 'new' chips fail?
> Does the 'new' design with the 'old' chips fail?
> Does the 'new' design use a newer version of ISE than before?
>
> Slight changes in logic can cause surprisingly large changes in placement
> and routing. Changes in ISE version can cause large changes in placement
> and routing.
No, this is running the exact same EPROM image as all older revs.  The 
only change is the mfg date of the FPGA and other chips on the board, 
and whatever changes might have occurred on the PCB layout and 
fabrication details of the PCB itself.  The serial clock is generated by
a 74HC14, and it is also possible that the output driver of this 
commodity part might be different than the ones used before.

Thanks for all the interesting comments!  This is now mostly an academic
curiosity, as the board runs with this additional resistor.  Almost 
certainly I SHOULD have been using such a scheme from the beginning on
the several clock lines on the board.  But, it worked without them.......

Jon

Article: 152734
Subject: Re: Synthesizable heap-sorter for FPGA - BSD licensed sources
From: Wojtek =?UTF-8?Q?Zabo=C5=82otny?= <wzab@WZLap.nasz.dom>
Date: Fri, 14 Oct 2011 13:10:51 +0000 (UTC)
Links: << >>  << T >>  << A >>
Hi,

The article describing my "Synthesizable heap-sorter for FPGA"
(available at http://www.ise.pw.edu.pl/~wzab/fpga_heapsort)
is just published and available at http://dx.doi.org/10.1117/12.905281

-- 
Regards, Wojtek

Article: 152735
Subject: Re: Spartan changes in glitch sensitivity
From: Bob Perlman <cambriandesign@gmail.com>
Date: Sat, 15 Oct 2011 00:35:15 -0700 (PDT)
Links: << >>  << T >>  << A >>
Could you describe this serial clock that goes to all boards in a bit
more detail?  Is it a single clock that is daisy-chained to all card
slots?  If so, you may still have a problem.  The driver on a series-
terminated net will send a half-height wave down the trace when it
transitions, followed by a half-height reflection in the reverse
direction.  The upshot is that the signal at the very last load will
look fine, because the return wave launches at the same time the
incident wave arrives, producing a clean rising or falling edge.  But
all other loads along the line will see a half-height pedestal in the
edge, with the pedestal becoming more pronounced as you get closer to
the driver.  If that pedestal happens to be in the transition region,
the receiver could see a double (or triple, or whatever) clock.

On the other hand, if you send a separate, series-terminated clock to
each load, each clock should look fine at its destination (well, there
are other considerations, but I'm going to conveniently ignore them
for the moment).

If this is a series-terminated, daisy-chained clock, take a look at
the clock going into the FPGA with a high-bandwidth scope and probe,
and see if there's a pedestal.  If there is, there's more work to be
done.

Bob Perlman
Cambrian Design Works

On Oct 13, 3:48=A0pm, Jon Elson <jmel...@wustl.edu> wrote:
> On 10/13/2011 07:11 AM, RCIngham wrote:
>
>
>
> > Does the 'old' design with the 'new' chips fail?
> > Does the 'new' design with the 'old' chips fail?
> > Does the 'new' design use a newer version of ISE than before?
>
> > Slight changes in logic can cause surprisingly large changes in placeme=
nt
> > and routing. Changes in ISE version can cause large changes in placemen=
t
> > and routing.
>
> No, this is running the exact same EPROM image as all older revs. =A0The
> only change is the mfg date of the FPGA and other chips on the board,
> and whatever changes might have occurred on the PCB layout and
> fabrication details of the PCB itself. =A0The serial clock is generated b=
y
> a 74HC14, and it is also possible that the output driver of this
> commodity part might be different than the ones used before.
>
> Thanks for all the interesting comments! =A0This is now mostly an academi=
c
> curiosity, as the board runs with this additional resistor. =A0Almost
> certainly I SHOULD have been using such a scheme from the beginning on
> the several clock lines on the board. =A0But, it worked without them.....=
..
>
> Jon


Article: 152736
Subject: Re: Spartan changes in glitch sensitivity
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Sat, 15 Oct 2011 09:03:11 +0000 (UTC)
Links: << >>  << T >>  << A >>
Bob Perlman <cambriandesign@gmail.com> wrote:

(snip)
> The driver on a series-
> terminated net will send a half-height wave down the trace when it
> transitions, followed by a half-height reflection in the reverse
> direction.  The upshot is that the signal at the very last load will
> look fine, because the return wave launches at the same time the
> incident wave arrives, producing a clean rising or falling edge.  But
> all other loads along the line will see a half-height pedestal in the
> edge, with the pedestal becoming more pronounced as you get closer to
> the driver.  If that pedestal happens to be in the transition region,
> the receiver could see a double (or triple, or whatever) clock.

That is what is supposed to happen, but there are other possibilities.

First, consider no termination.  The reflection comes back at
double height, hits the protection diode, and pulls Vcc up.
That can't be good.  That might be enough to mess up IOB
flip-flops.

Next, try a smaller than optimal impedance match resistor.
The signal going out might be at 3/4 height, instead of 1/2,
the reflection will then come back at 3/2, but goes through
the resistor before hitting the protection diode.  

There will also be a negative reflaction back again, which
should be about half the reflection coming in, which shouldn't
bother things too much.

Also, the resistor, into the transmission line load impedance,
should round off the sharp edge a little bit, but not too much,
reducing the effects of a too-fast transition.

If the bus is TTL levels, then half of 5V, or even half of 4V
will meet the Vhigh level.  

A small series termination resisitor is a lot better than
none at all.

-- glen

Article: 152737
Subject: Doulos training courses at Xilinx
From: "Mr.CRC" <crobcBOGUS@REMOVETHISsbcglobal.net>
Date: Sat, 15 Oct 2011 10:51:29 -0700
Links: << >>  << T >>  << A >>
Hi:

While I'm very able to learn on my own, I feel that at my age and with
so many people pulling at me every minute, that to assemble the hours of
 focussed attention to actually work through a significant amount of
study material, these sorts of immersion courses are beneficial.

Of course, that also assumes that my employer is willing to pay for it,
which they are.  If I had to pay, then the economics would be in favor
of cracking a book and taking the fully DIY approach--which is basically
how I've learned nearly everything I know about electronics to date.

Of course, these sorts of courses require a lot of DIY follow-through to
drive things home.

In this case, since I have quite a bit of increasingly complicated
(though still fairly simple by the standards of most experts) FPGA
development to do over the next few years, there will be ample
opportunity to exercise what I have learned.

I think the point is, that there are a lot of practices that aren't
obviated by simply reading a Verilog textbook.  Even some of the "learn
by example" books have some shoddy practices.

Also, I suffer from "tool overwhelmitis" syndrome, where there are so
many sub-tools in the vendor's development environment that I don't know
what they are all for.


Anyway, I am considering to take the "Comprehensive Verilog" and
"Essentials and Design for Performance" classes by Doulos at Xilinx in Dec.

Just wondering if people think these are worthwhile?

Thanks for input.  And output too.  Just no high-z's!


Good day!


-- 
_____________________
Mr.CRC
crobcBOGUS@REMOVETHISsbcglobal.net
SuSE 10.3 Linux 2.6.22.17

Article: 152738
Subject: Synapticad BugHunter and VeriloggerExtreme
From: "Mr.CRC" <crobcBOGUS@REMOVETHISsbcglobal.net>
Date: Sat, 15 Oct 2011 15:41:55 -0700
Links: << >>  << T >>  << A >>
Greetings:

They gave me a 6-mo eval license for those, which I will begin tinkering
with in upcoming weeks.

I have so far used only Icarus Verilog for sims, ever since Modelsim
stopped being included with Xilinx tools.  I know they have Isim now, or
whatever the flavor of the month is, but I have yet to check it out or
even determine if it's free in some capacity or not.

But what attracted me to Synapticad's product was the prospect for much
easier "graphical" waveform editing to compose test benches, which I
suppose is among all of our least favorite things to do.


Any thoughts on Synapticad for Verilog sim and testbench generation?


Thanks for comments.


-- 
_____________________
Mr.CRC
crobcBOGUS@REMOVETHISsbcglobal.net
SuSE 10.3 Linux 2.6.22.17

Article: 152739
Subject: Re: Spartan changes in glitch sensitivity
From: Bob Perlman <cambriandesign@gmail.com>
Date: Sat, 15 Oct 2011 16:02:31 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Oct 15, 2:03=A0am, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
> A small series termination resisitor is a lot better than
> none at all.
>
> -- glen

Sometimes.  And clearly in this case it *is*better, because the new
motherboards seem to work.  But the question before us is whether this
is a legitimate fix, i.e., one that will work for the next batch of
boards, and the batches after that.  Without probing at the signals to
see what they look like, and perhaps simulating over the range of
likely driver output impedances and risetimes, you can't say.  But in
general, using a series-terminated, daisy-chained net to drive
multiple clock inputs is a bad idea, and is to be avoided.

For those who want to learn more about this, here's a paper I wrote a
while back:

http://cambriandesign.squarespace.com/downloadable-files/pads_series_term_p=
aper.pdf

Bob Perlman
Cambrian Design Works

Article: 152740
Subject: Re: Spartan changes in glitch sensitivity
From: Jon Elson <elson@pico-systems.com>
Date: Sat, 15 Oct 2011 18:30:54 -0500
Links: << >>  << T >>  << A >>
Bob Perlman wrote:

> Could you describe this serial clock that goes to all boards in a bit
> more detail?  Is it a single clock that is daisy-chained to all card
> slots?
Yes, a horrible situation, a 16" long trace that is fed roughly
from the middle, to all 16 board slots, with the FPGA in the middle.

> If so, you may still have a problem.  The driver on a series- 
> terminated net will send a half-height wave down the trace when it
> transitions, followed by a half-height reflection in the reverse
> direction.  The upshot is that the signal at the very last load will
> look fine, because the return wave launches at the same time the
> incident wave arrives, producing a clean rising or falling edge.  But
> all other loads along the line will see a half-height pedestal in the
> edge, with the pedestal becoming more pronounced as you get closer to
> the driver.  If that pedestal happens to be in the transition region,
> the receiver could see a double (or triple, or whatever) clock.
> 
Yup, I am not inexperienced in transmission line design.  I tried a
number of combinations of daughter boards, but obviously not a full
combinatorial test.  There was no sign of trouble in those test
cases.  Our control system runs test patterns on the serial config.
register, and found no trouble.
> On the other hand, if you send a separate, series-terminated clock to
> each load, each clock should look fine at its destination (well, there
> are other considerations, but I'm going to conveniently ignore them
> for the moment).
> 
This is already a 6-layer board filled with traces, so I don't think that
is practical.
> If this is a series-terminated, daisy-chained clock, take a look at
> the clock going into the FPGA with a high-bandwidth scope and probe,
> and see if there's a pedestal.  If there is, there's more work to be
> done.
Yes, I ought to do some more testing to make sure this HACK is as
robust as I hope it is.

Jon

Article: 152741
Subject: Re: Spartan changes in glitch sensitivity
From: Jon Elson <elson@pico-systems.com>
Date: Sat, 15 Oct 2011 18:33:49 -0500
Links: << >>  << T >>  << A >>
glen herrmannsfeldt wrote:


> Also, the resistor, into the transmission line load impedance,
> should round off the sharp edge a little bit, but not too much,
> reducing the effects of a too-fast transition.
> 
That is what I was hoping to do, round off the edge so that loads,
and the board itself pretty much absorbs the reflection.

> If the bus is TTL levels, then half of 5V, or even half of 4V
> will meet the Vhigh level.

Everything is CMOS, but may have "TTL" input thresholds. 
> A small series termination resisitor is a lot better than
> none at all.
Well, it SEEMS to have solved the problem.  I will probably
do some more testing to be sure it is solid.

Jon

Article: 152742
Subject: Re: Spartan changes in glitch sensitivity
From: Jon Elson <elson@pico-systems.com>
Date: Sat, 15 Oct 2011 18:41:48 -0500
Links: << >>  << T >>  << A >>
Bob Perlman wrote:

> On Oct 15, 2:03 am, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
>> A small series termination resisitor is a lot better than
>> none at all.
>>
>> -- glen
> 
> Sometimes.  And clearly in this case it *is*better, because the new
> motherboards seem to work.  But the question before us is whether this
> is a legitimate fix, i.e., one that will work for the next batch of
> boards, and the batches after that.  Without probing at the signals to
> see what they look like, and perhaps simulating over the range of
> likely driver output impedances and risetimes, you can't say.  But in
> general, using a series-terminated, daisy-chained net to drive
> multiple clock inputs is a bad idea, and is to be avoided.
> 
> For those who want to learn more about this, here's a paper I wrote a
> while back:
> 
>
http://cambriandesign.squarespace.com/downloadable-files/pads_series_term_paper.pdf
Thanks for the link.  Well, in this system, the daughter boards have two
chips made by MOSIS for us on the half um AMI process, now ON Semi.
Not a really fast process, but the important stuff there is all
analog, and the slower digital is fine.  There are some Maxim
serial-controlled MOS switches on the motherboard that have the slowest
digital logic I've ever seen, dating back to the discrete transistor
computer days.  I had to slow the serial clock down to 1.2 us to
get valid data to clock through these chips, almost twice as slow
as their datasheet!

So, the ONLY thing fast on this board seems to be the FPGA!  That's
why I got away with this design before.  Having the FPGA in the
center of the board may be the worst spot for reflections.

Jon

Article: 152743
Subject: Re: Doulos training courses at Xilinx
From: nico@puntnl.niks (Nico Coesel)
Date: Sun, 16 Oct 2011 13:12:29 GMT
Links: << >>  << T >>  << A >>
"Mr.CRC" <crobcBOGUS@REMOVETHISsbcglobal.net> wrote:

>Hi:
>
>While I'm very able to learn on my own, I feel that at my age and with
>so many people pulling at me every minute, that to assemble the hours of
> focussed attention to actually work through a significant amount of
>study material, these sorts of immersion courses are beneficial.
>
>Of course, that also assumes that my employer is willing to pay for it,
>which they are.  If I had to pay, then the economics would be in favor
>of cracking a book and taking the fully DIY approach--which is basically
>how I've learned nearly everything I know about electronics to date.
>
>Of course, these sorts of courses require a lot of DIY follow-through to
>drive things home.
>
>In this case, since I have quite a bit of increasingly complicated
>(though still fairly simple by the standards of most experts) FPGA
>development to do over the next few years, there will be ample
>opportunity to exercise what I have learned.
>
>I think the point is, that there are a lot of practices that aren't
>obviated by simply reading a Verilog textbook.  Even some of the "learn
>by example" books have some shoddy practices.

Why Verilog? If you have a background in programming you might find
VHDL easier to work with.

-- 
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
nico@nctdevpuntnl (punt=.)
--------------------------------------------------------------

Article: 152744
Subject: Re: Spartan changes in glitch sensitivity
From: "RCIngham" <robert.ingham@n_o_s_p_a_m.n_o_s_p_a_m.gmail.com>
Date: Mon, 17 Oct 2011 05:28:19 -0500
Links: << >>  << T >>  << A >>
>glen herrmannsfeldt wrote:
>> Also, the resistor, into the transmission line load impedance,
>> should round off the sharp edge a little bit, but not too much,
>> reducing the effects of a too-fast transition.
>> 
>That is what I was hoping to do, round off the edge so that loads,
>and the board itself pretty much absorbs the reflection.
>
>> If the bus is TTL levels, then half of 5V, or even half of 4V
>> will meet the Vhigh level.
>
>Everything is CMOS, but may have "TTL" input thresholds. 
>> A small series termination resisitor is a lot better than
>> none at all.
>Well, it SEEMS to have solved the problem.  I will probably
>do some more testing to be sure it is solid.
>
>Jon

If available, I advise doing tests in a cold chamber, which should increase
edge rates (reduce rise/fall time). It wasn't until we got to low
temperature qualification tests that I discovered signal integrity issues
relating to series termination on one of my designs...
	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 152745
Subject: Re: Doulos training courses at Xilinx
From: "Mr.CRC" <crobcBOGUS@REMOVETHISsbcglobal.net>
Date: Mon, 17 Oct 2011 12:50:18 -0700
Links: << >>  << T >>  << A >>
Nico Coesel wrote:
> "Mr.CRC" <crobcBOGUS@REMOVETHISsbcglobal.net> wrote:
> 
>> Hi:
>>
>> While I'm very able to learn on my own, I feel that at my age and with
>> so many people pulling at me every minute, that to assemble the hours of
>> focussed attention to actually work through a significant amount of
>> study material, these sorts of immersion courses are beneficial.
>>
>> Of course, that also assumes that my employer is willing to pay for it,
>> which they are.  If I had to pay, then the economics would be in favor
>> of cracking a book and taking the fully DIY approach--which is basically
>> how I've learned nearly everything I know about electronics to date.
>>
>> Of course, these sorts of courses require a lot of DIY follow-through to
>> drive things home.
>>
>> In this case, since I have quite a bit of increasingly complicated
>> (though still fairly simple by the standards of most experts) FPGA
>> development to do over the next few years, there will be ample
>> opportunity to exercise what I have learned.
>>
>> I think the point is, that there are a lot of practices that aren't
>> obviated by simply reading a Verilog textbook.  Even some of the "learn
>> by example" books have some shoddy practices.
> 
> Why Verilog? If you have a background in programming you might find
> VHDL easier to work with.


I thought very carefully about the decision to use Verilog years ago.
My background is electronics, with a bunch of programming, mostly
low-level to go along with it.

But I have to do many things, and sometimes I will do a burst of
logic/embedded work, then go align lasers for 6 months.  What I come
back to needs to be as simple as possible.

Verilog is less verbose than VHDL.  I consider VHDL to be the Java of
HDLs.  I don't need that.  So far I have been happy with working with
Verilog.  It's fairly easy to understand.  I'd just like an immersion
type of experience right now to cover in a few short days all the
details that I need to learn about, even if I don't necessarily commit
them to memory in that short time, or fully get all their implications.

Likewise with the toolset.

Thanks for the comment.

-- 
_____________________
Mr.CRC
crobcBOGUS@REMOVETHISsbcglobal.net
SuSE 10.3 Linux 2.6.22.17

Article: 152746
Subject: Re: Doulos training courses at Xilinx
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Mon, 17 Oct 2011 22:35:39 +0000 (UTC)
Links: << >>  << T >>  << A >>
Mr.CRC <crobcBOGUS@removethissbcglobal.net> wrote:

(snip)

> I thought very carefully about the decision to use Verilog years ago.
> My background is electronics, with a bunch of programming, mostly
> low-level to go along with it.

> But I have to do many things, and sometimes I will do a burst of
> logic/embedded work, then go align lasers for 6 months.  What I come
> back to needs to be as simple as possible.

> Verilog is less verbose than VHDL.  I consider VHDL to be the Java of
> HDLs.  I don't need that.  

I have worked with Java, and it isn't that wordy.  Some have 
compared VHDL to ADA, though I haven't worked with ADA enough
to know.  I can usually read VHDL enough to figure out what it
does, but won't claim to be able to write it.

Some years ago, I was told that VHDL was more common for FPGA
designs, and verilog for ASIC designs, but I believe even that
isn't true by now.

> So far I have been happy with working with Verilog.  It's fairly 
> easy to understand.  I'd just like an immersion type of experience 
> right now to cover in a few short days all the details that I need 
> to learn about, even if I don't necessarily commit them to memory 
> in that short time, or fully get all their implications.

-- glen

Article: 152747
Subject: Re: Doulos training courses at Xilinx
From: "RCIngham" <robert.ingham@n_o_s_p_a_m.n_o_s_p_a_m.gmail.com>
Date: Tue, 18 Oct 2011 04:25:54 -0500
Links: << >>  << T >>  << A >>
"Some have compared VHDL to ADA, though I haven't worked with ADA enough to
know."

Both were developed at the behest of the USA DoD, and a cursory examination
of example code from each will draw you to the inevitable conclusion that
VHDL's syntax was derived from that of Ada's. Which should not be a
surprise...

Note: 'Ada' is not an acronym, but 'VHDL' is.
	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 152748
Subject: Re: Doulos training courses at Xilinx
From: nico@puntnl.niks (Nico Coesel)
Date: Tue, 18 Oct 2011 16:24:56 GMT
Links: << >>  << T >>  << A >>
glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:

>Mr.CRC <crobcBOGUS@removethissbcglobal.net> wrote:
>
>(snip)
>
>> I thought very carefully about the decision to use Verilog years ago.
>> My background is electronics, with a bunch of programming, mostly
>> low-level to go along with it.
>
>> But I have to do many things, and sometimes I will do a burst of
>> logic/embedded work, then go align lasers for 6 months.  What I come
>> back to needs to be as simple as possible.
>
>> Verilog is less verbose than VHDL.  I consider VHDL to be the Java of
>> HDLs.  I don't need that.  
>
>I have worked with Java, and it isn't that wordy.  Some have 
>compared VHDL to ADA, though I haven't worked with ADA enough
>to know.  I can usually read VHDL enough to figure out what it
>does, but won't claim to be able to write it.
>
>Some years ago, I was told that VHDL was more common for FPGA
>designs, and verilog for ASIC designs, but I believe even that
>isn't true by now.

It depends on personal preference I guess. To me Verilog looks like a
lot of gibberish so I use VHDL. What I also like about VHDL is its
power. VHDL may be more verbose but once you treat it as a programming
language a simple function can reduce the number of typing required
considerably.

A nice example is a priority encoder. If you search with Google for an
example you'll see 9 out of 10 people write an equation for each
output. Only one writes a function consisting of 3 lines which has the
additional advantage of being generic.

And don't get me started on designs which can be adjusted by means of
few simple parameters...

-- 
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
nico@nctdevpuntnl (punt=.)
--------------------------------------------------------------

Article: 152749
Subject: Re: Doulos training courses at Xilinx
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Tue, 18 Oct 2011 19:15:13 +0000 (UTC)
Links: << >>  << T >>  << A >>
Nico Coesel <nico@puntnl.niks> wrote:

(snip, someone wrote)
>>> Verilog is less verbose than VHDL.  I consider VHDL to be 
>>> the Java of HDLs.  I don't need that.  

>>I have worked with Java, and it isn't that wordy.  Some have 
>>compared VHDL to ADA, though I haven't worked with ADA enough
>>to know.  I can usually read VHDL enough to figure out what it
>>does, but won't claim to be able to write it.

(snip)
> It depends on personal preference I guess. To me Verilog looks like a
> lot of gibberish so I use VHDL. What I also like about VHDL is its
> power. VHDL may be more verbose but once you treat it as a programming
> language a simple function can reduce the number of typing required
> considerably.

I mostly write structural verilog, with continuous assignment
and module references.  Behavioral (always blocks) mostly for
registers and state machines.

> A nice example is a priority encoder. If you search with Google for an
> example you'll see 9 out of 10 people write an equation for each
> output. Only one writes a function consisting of 3 lines which has the
> additional advantage of being generic.

You mean for each input?  It seems, good or bad, that most
synthesis tools do pretty well with the verbose form, though.

Last time I wrote one, for 40 inputs, I did it nested, first
writing the eight input encoder, then five of those, and the
logic to put the result together.  I believe it was pipelined,
with a register between the two.

> And don't get me started on designs which can be adjusted by means of
> few simple parameters...

-- glen



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