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 148075

Article: 148075
Subject: Re: Xilinx Timing Constraings
From: Christian Widtmann <christian.widtmann@student.tuwien.ac.at>
Date: Fri, 18 Jun 2010 20:54:56 +0200
Links: << >>  << T >>  << A >>
On 18.06.2010 20:25, Gabor wrote:
> On Jun 18, 1:27 pm, Rob Gaddi<rga...@technologyhighland.com>  wrote:
>> I'm no luck figuring out how to implement the timing constraints for
>> something that, to my mind, ought to be pretty simple.  I'm connected to
>> an external synchronous logic chip.  For now let's call it a regular
>> 74HC74 flip flop, but the details are unimportant.  My FPGA outputs D
>> and CLK to the 74HC74, and reads back Q.
>>
>> The FPGA has a single global clock net, call it SysClk.  I've got a
>> state machine running on SysClk generating both data and clock for this
>> widget; the clock is running at a sufficiently low rate that it's being
>> generated by a simple, rising-edge only, divide-by-N from my master
>> clock.  My logic defines both D and CLK in a way that they're registered
>> outputs and Q as a registered input with no logic; such that all of them
>> should be able to be pushed into the IOBs.
>>
>> The 74HC74 datasheet tells me that I've got setup time (Ts), hold time
>> (Th), and clock-to-output delay (Tcko).  How do I go about communicating
>> these requirements to the Xilinx toolchain?  Clearly it's some
>> combination of OFFSET constraints, but what are the magic words?
>>
>> UG612 discusses the use of the REFERENCE_PIN qualifier to indicate that
>> the output data is referred to the output clock, but the example doesn't
>> give any advice that would connect those OFFSET constraints to only
>> define the relationship between D and CLK, not the entire world and CLK.
>>    And I can't seem to find any information whatsoever that would let me
>> define the relationship between CLK and Q.
>>
>> I've gone through the Constraints Guide.  I've gone through UG612.  I've
>> gone through Austin's 5 part series over on the Xilinx forums.  And I'm
>> still lost.  Anyone have any revelations for me?
>>
>> --
>> Rob Gaddi, Highland Technology
>> Email address is currently out of order
>
> Basically, you are using a source synchronous output clock to your
> flip-flop.  There is no constraint to my knowledge that would do
> the job you're looking for which is to define the relative timing
> on two outputs.  This should be correct by design.  i.e. if you
> push both CLK and Q outputs into IOB flops, using DDR flops if
> necessary for the clock, you should have essentially zero timing
> difference between CLK and Q if they are switching on the same
> edge of the same global clock.  Make your Tsu and Th based on
> the relative timing to the IOB flops, for example making CLK
> go high on the falling edge of the internal clock and changing
> Q on the next rising edge to get 1/2 cycle of hold time.
>
> HTH,
> Gabor

Hi!

Gabor is right with that there is no constraint that will ensure and 
check the setup/hold time that your external FF requires. As he already 
said, use an ODDR block to pass your clock on to the external FF, it is 
described in the user manual of the FPGA.

You can create a timing report though that gives you the relative output 
delay between clock and data, which will enable you to confirm the setup 
time for your external FF manually. For this, create a timing group 
containing only the CLK and D pin and apply an OFFSET OUT constraint 
with reference pin CLK relative to the internal SysClk. This will give 
you the report in the .twr file. If the timing is not sufficient, you 
can delay either CLK or D by an IODELAY or ODELAY block, which is 
described in the FPGA user manual or the HDL library guide.

To constrain and ensure the capture of Q, create a timing group 
containing only Q and apply an OFFSET IN BEFORE constraint to it, 
relative to your capturing clock, and specify the setup and hold time 
that your external FF output signal will exhibit when it is clocked with 
the timing as reported by the OFFSET OUT contraint and the external FF 
datasheet. You will have to perform this analysis manually (and 
theoretically also consider board delays and skews), but if the OFFSET 
IN constraint holds and represents the real behavior, your design will 
work. Again, you may manually fix a timing violation by an IODELAY or 
IDELAY instance on the input pin.

There is also a Timing Constraint guide that you can look for at the 
Xilinx homepage, it should provide you with the exact syntax.

Hope I gave you the right keywords ...

Christian

Article: 148076
Subject: Difficulty with Xilinx FPGA configuration using Platform Flash PROM
From: Vic Orloff <vcorloff@gmail.com>
Date: Fri, 18 Jun 2010 12:14:39 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hello,

I am a beginner and have tried to learn how to configure my FPGA
(XC3S1600E) in Master Serial Mode using configuration of a design
stored in Platform Flash PROM (XCF04S) .
I use Xilinx ISE 9.1i and followed the steps described in 'Spartan-3
Generation Configuration User Guide (ug332.pdf, pages 42-46 and
91-100) and everything seemed working alright - FPGA bitstream was
generated, PROM file (.mcs) for Platform Flash PROM memory was created
and PROM was successfuly programmed using JTAG ('Program Succeeded'
message appeared). So everything seems working according to the guide
but when I power board off and then on, my FPGA is not configured
according to what I have programmed into PROM.

So my problem is that although PROM is seemed correctly programmed but
FPGA has not being configured after power is on.

What could be reasons for this, what I have missed?

Thank you.

Article: 148077
Subject: Re: Difficulty with Xilinx FPGA configuration using Platform Flash
From: Gabor <gabor@alacron.com>
Date: Fri, 18 Jun 2010 12:59:38 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Jun 18, 3:14=A0pm, Vic Orloff <vcorl...@gmail.com> wrote:
> Hello,
>
> I am a beginner and have tried to learn how to configure my FPGA
> (XC3S1600E) in Master Serial Mode using configuration of a design
> stored in Platform Flash PROM (XCF04S) .
> I use Xilinx ISE 9.1i and followed the steps described in 'Spartan-3
> Generation Configuration User Guide (ug332.pdf, pages 42-46 and
> 91-100) and everything seemed working alright - FPGA bitstream was
> generated, PROM file (.mcs) for Platform Flash PROM memory was created
> and PROM was successfuly programmed using JTAG ('Program Succeeded'
> message appeared). So everything seems working according to the guide
> but when I power board off and then on, my FPGA is not configured
> according to what I have programmed into PROM.
>
> So my problem is that although PROM is seemed correctly programmed but
> FPGA has not being configured after power is on.
>
> What could be reasons for this, what I have missed?
>
> Thank you.

You can get some debug information from Impact that will
tell you the state of the FPGA config pins.  Make sure the
mode pins are correct for your device.  Putting the whole
S3 series in one config guide is a bit confusing.  The
mode pin definitions vary between S3 families.

Also make sure you generated the .bit file with CCLK as
the startup clock, and that you didn't increase the
CCLK frequency beyond the capability of the XCF04S.
Remember that CCLK frequencies can be +/- 50% of the
nominal value!

Check if the INIT line goes high then low again during startup.
This indicates a CRC error and could be caused by signal integrity
problems or if the .bit file is not generated properly, for example
with bits reversed.

If you have access to the PROG pin, try to ground it momentarily to
see if the FPGA will load.  If it does, but not on power-up you may
have a power sequencing problem.  If the supply that powers the
XCF04S is the last one up, the FPGA might try to start configuration
before the flash is ready.

It also helps to put a scope on the CCLK line.  After power on is
it running constantly?  This happens if the FPGA doesn't see a
proper bitstream startup sync pattern and keeps trying to shift in
data, as for example if the Flash is erased.

And of course double check the connections in the schematics for
master serial from the user guide.  Make sure you have all the
necessary connections and pullup resistors.

HTH,
Gabor

Article: 148078
Subject: Re: Anyone else need bigger parts in small (low pin count) packages
From: "Jaime Andres Aranguren C." <jaime.aranguren@ieee.org>
Date: Sat, 19 Jun 2010 00:26:49 +0200
Links: << >>  << T >>  << A >>

"rickman" <gnuarm@gmail.com> wrote in message 
news:54356eb8-3f64-4df7-9997-e916daa71b7c@m21g2000vbr.googlegroups.com...
On Jun 2, 7:35 pm, -jg <jim.granvi...@gmail.com> wrote:
> On Jun 3, 10:05 am, rickman <gnu...@gmail.com> wrote:
>
> > > Rather than the uC+CPLD the marketing types are chasing, I would find
> > > a CPLD+RAM more useful, as there are LOTS of uC out there already, and
> > > if they can make 32KB SRAM for sub $1, they should be able to include
> > > it almost for free, in a medium CPLD.
>
> > > -jg
>
> > I won't argue with that for a moment. But deciding what to put in a
> > part and which flavors to offer in what packages is decided in the
> > land of marketing. As much as I whine and complain, I guess I have to
> > assume they know *something* about their jobs.
>
> The product managers are understandably blinkered by what has gone
> before, and what they sell now, so in the CPLD market it is very rare
> to see a bold step.
>
> The CoolRunner was the last bold step I recall, and that was not made
> by a traditional vendor product manager, but by some new blood.
>
> Altera, Atmel, Lattice and Xilinx have slowed right down on CPLD
> releases, to almost be in 'run out' mode.

I've been busy with work the last few months so I tend to forget what
I read about trends.  I seem to recall that Xilinx has announced
something with an MCU in it and not the PPC they used in the past.  Do
I remember right?  Is X coming out with an FPGA with an ARM?

Personally, I prefer something other than an ARM inside an FPGA.  I
want a CPU that executes each instruction in a single clock cycle and
has very seriously low interrupt latency.  That is why I designed my
own CPU at one point.  ARM CPUs with FPGAs seem to be oriented to
people who want to use lots of memory and run a real time OS.  Not
that that an ARM or a real time OS is a bad thing, I just want
something closer to the metal.

If I could get a good MCU in an FPGA (which would certainly have some
adequate memory) in a "convenient" package, that would really make my
day.  I don't have to have the analog stuff, but 5 volt tolerance
would certainly be useful.  That alone would take two chips off my
board and maybe more.

Rick
--

ARM Cortex-M3 is in Actel SmartFusion FPGAs. Not in small package, though.

--
Jaime Andres Aranguren Cardona
SanJaaC Electronics
Soluciones en DSP
www.sanjaac.com 



Article: 148079
Subject: Re: Expand TEMAC fifo?
From: Griffin <captain.griffin@gmail.com>
Date: Fri, 18 Jun 2010 17:30:25 -0700 (PDT)
Links: << >>  << T >>  << A >>
Is anyone else not able to view the link anymore? I can ping the site,
but not access the webpage.

-Sean.

Article: 148080
Subject: Re: Difficulty with Xilinx FPGA configuration using Platform Flash
From: Vic Orloff <vcorloff@gmail.com>
Date: Fri, 18 Jun 2010 22:10:16 -0700 (PDT)
Links: << >>  << T >>  << A >>
Thank you very much!

It looks a very good list of key points to check indeed.

Article: 148081
Subject: Re: Difficulty with Xilinx FPGA configuration using Platform Flash
From: Anssi Saari <as@sci.fi>
Date: Sat, 19 Jun 2010 11:43:11 +0300
Links: << >>  << T >>  << A >>
Vic Orloff <vcorloff@gmail.com> writes:

> Hello,
>
> I am a beginner and have tried to learn how to configure my FPGA
> (XC3S1600E) in Master Serial Mode using configuration of a design
> stored in Platform Flash PROM (XCF04S) .

At the very least there's the slight problem of fitting almost 6 Mb of
config data into a 4 Mb PROM. Presumably you used compression? But if
so, did you limit CCLK to 20 MHz or below for configuration as
described in the documentation?

Article: 148082
Subject: Re: Difficulty with Xilinx FPGA configuration using Platform Flash
From: Vic Orloff <vcorloff@gmail.com>
Date: Sat, 19 Jun 2010 13:57:06 -0700 (PDT)
Links: << >>  << T >>  << A >>
On 19 =D0=B8=D1=8E=D0=BD, 11:43, Anssi Saari <a...@sci.fi> wrote:
> Vic Orloff <vcorl...@gmail.com> writes:
> > Hello,
>
> > I am a beginner and have tried to learn how to configure my FPGA
> > (XC3S1600E) in Master Serial Mode using configuration of a design
> > stored in Platform Flash PROM (XCF04S) .
>
> At the very least there's the slight problem of fitting almost 6 Mb of
> config data into a 4 Mb PROM. Presumably you used compression? But if
> so, did you limit CCLK to 20 MHz or below for configuration as
> described in the documentation?

Hello,

Yes, ConfigRate was set to 12 (which is approximately 12 MHz).

Article: 148083
Subject: Xilinx DCM Block Stability Issues
From: Randy Yates <yates@ieee.org>
Date: Sat, 19 Jun 2010 18:00:14 -0400
Links: << >>  << T >>  << A >>
Hi,

We're using one of the global DCM blocks in a Xilinx Spartan 3E
to regenerate/deskew an important clock in our application. The
clock has an input frequency of 31.5 MHz and we're using the 270
phase of the X1 output of the block. 

However, we've observed that the block seems to be marginally
stable. At random, the clock output completely dies, usually
lasting somewhere between approximately 2 to 6 seconds. 

We brought out the status signal that indicates "input clock
is out of jitter tolerance" and observed that it is pulsing
frequently. Indeed, it is during a group of those pulses that
the output clock finally dies. 

Looking at the input clock with a scope doesn't reveal any 
particular problems. The signal comes from about 2 inches
across a 4-layer FR4 board, so it isn't perfect (we've
used a 33-ohm series resistor to "match" impedances), but
it certainly looks good enough, although I realize that
statement is somewhat imprecise and subjective.

Anyway, if anyone has experienced or heard of such problems
with the DCM module and knows of a fix, I'd appreciate a
pointer. Thanks!

--Randy

-- 
Randy Yates                      % "So now it's getting late,
Digital Signal Labs              %    and those who hesitate
mailto://yates@ieee.org          %    got no one..."
http://www.digitalsignallabs.com % 'Waterfall', *Face The Music*, ELO

Article: 148084
Subject: Re: Xilinx DCM Block Stability Issues
From: Gabor <gabor@alacron.com>
Date: Sat, 19 Jun 2010 15:14:58 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Jun 19, 6:00=A0pm, Randy Yates <ya...@ieee.org> wrote:
> Hi,
>
> We're using one of the global DCM blocks in a Xilinx Spartan 3E
> to regenerate/deskew an important clock in our application. The
> clock has an input frequency of 31.5 MHz and we're using the 270
> phase of the X1 output of the block.
>
> However, we've observed that the block seems to be marginally
> stable. At random, the clock output completely dies, usually
> lasting somewhere between approximately 2 to 6 seconds.
>
> We brought out the status signal that indicates "input clock
> is out of jitter tolerance" and observed that it is pulsing
> frequently. Indeed, it is during a group of those pulses that
> the output clock finally dies.
>
> Looking at the input clock with a scope doesn't reveal any
> particular problems. The signal comes from about 2 inches
> across a 4-layer FR4 board, so it isn't perfect (we've
> used a 33-ohm series resistor to "match" impedances), but
> it certainly looks good enough, although I realize that
> statement is somewhat imprecise and subjective.
>
> Anyway, if anyone has experienced or heard of such problems
> with the DCM module and knows of a fix, I'd appreciate a
> pointer. Thanks!
>
> --Randy
>
> --
> Randy Yates =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0% "So now it's get=
ting late,
> Digital Signal Labs =A0 =A0 =A0 =A0 =A0 =A0 =A0% =A0 =A0and those who hes=
itate
> mailto://ya...@ieee.org =A0 =A0 =A0 =A0 =A0% =A0 =A0got no one..."http://=
www.digitalsignallabs.com% 'Waterfall', *Face The Music*, ELO

While good signal integrity helps, it really has little to
do with clock jitter, since the FR4 delay is relatively
constant.  Spartan 3 DCM's are not particularly jitter
tolerant.  Also the jitter in the spec is measured inside
the FPGA after possible insertion of additional jitter
due to ground bounce and power-supply noise.  At least
make sure that there are no cross-talk issues on the
board and that the PLL supplies (Vccaux?) are clean.
It helps to avoid outputs with strong drive on IOB's
near the clock input.  These will inject noise into the
receiver on the clock pin, and that noise increases
the jitter more when the clock rise and fall rates
are slower.

What is your clock source? Is it just an oscillator or
does it come from off-board?  If you're using an
oscillator you should also make sure it's Vcc is
clean to avoid power-supply induced jitter.

HTH,
Gabor

Article: 148085
Subject: Re: Xilinx DCM Block Stability Issues
From: Randy Yates <yates@ieee.org>
Date: Sat, 19 Jun 2010 19:58:56 -0400
Links: << >>  << T >>  << A >>
Gabor <gabor@alacron.com> writes:

> On Jun 19, 6:00 pm, Randy Yates <ya...@ieee.org> wrote:
>> Hi,
>>
>> We're using one of the global DCM blocks in a Xilinx Spartan 3E
>> to regenerate/deskew an important clock in our application. The
>> clock has an input frequency of 31.5 MHz and we're using the 270
>> phase of the X1 output of the block.
>>
>> However, we've observed that the block seems to be marginally
>> stable. At random, the clock output completely dies, usually
>> lasting somewhere between approximately 2 to 6 seconds.
>>
>> We brought out the status signal that indicates "input clock
>> is out of jitter tolerance" and observed that it is pulsing
>> frequently. Indeed, it is during a group of those pulses that
>> the output clock finally dies.
>>
>> Looking at the input clock with a scope doesn't reveal any
>> particular problems. The signal comes from about 2 inches
>> across a 4-layer FR4 board, so it isn't perfect (we've
>> used a 33-ohm series resistor to "match" impedances), but
>> it certainly looks good enough, although I realize that
>> statement is somewhat imprecise and subjective.
>>
>> Anyway, if anyone has experienced or heard of such problems
>> with the DCM module and knows of a fix, I'd appreciate a
>> pointer. Thanks!
>>
>> --Randy
>>
>> --
>> Randy Yates                      % "So now it's getting late,
>> Digital Signal Labs              %    and those who hesitate
>> mailto://ya...@ieee.org          %    got no one..."http://www.digitalsignallabs.com% 'Waterfall', *Face The Music*, ELO
>
> While good signal integrity helps, it really has little to
> do with clock jitter, since the FR4 delay is relatively
> constant.  Spartan 3 DCM's are not particularly jitter
> tolerant.  Also the jitter in the spec is measured inside
> the FPGA after possible insertion of additional jitter
> due to ground bounce and power-supply noise.  At least
> make sure that there are no cross-talk issues on the
> board and that the PLL supplies (Vccaux?) are clean.
> It helps to avoid outputs with strong drive on IOB's
> near the clock input.  These will inject noise into the
> receiver on the clock pin, and that noise increases
> the jitter more when the clock rise and fall rates
> are slower.

Hi Gabor,

Thanks - good points to check.

> What is your clock source? 

I'm not sure (don't have the schematic here) but I think it's
a TI CDC924.

> Is it just an oscillator or
> does it come from off-board?  

On-board.

> If you're using an
> oscillator you should also make sure it's Vcc is
> clean to avoid power-supply induced jitter.

That occurred to me but I haven't yet looked. 

> HTH,
> Gabor

Thanks for the tips, Gabor.
-- 
Randy Yates                      % "Rollin' and riding and slippin' and
Digital Signal Labs              %  sliding, it's magic."
mailto://yates@ieee.org          %  
http://www.digitalsignallabs.com % 'Living' Thing', *A New World Record*, ELO

Article: 148086
Subject: Re: Anyone interested in customizable EDA software for FPGA?
From: "shoonya" <manish.paradkar@n_o_s_p_a_m.n_o_s_p_a_m.gmail.com>
Date: Sun, 20 Jun 2010 00:04:47 -0500
Links: << >>  << T >>  << A >>
>Hello.
>
>I am working at an SoC startup developing EDA software for FPGA-like
>structures. Currently we have a half-finished software covering from
>technology mapping to placement and routing for FPGA. I am looking for
>opportunities to put the software into practice.
>
>Originally the software was expected to evaluate FPGA structures
>(known or unknown) for various application domains. So it is not
>designated to any specific logic cell or interconnect. Instead, given
>structure descriptions, this software can perform technology mapping,
>packing, placement and routing on a wide variety of
>structures. Actually, there does exist limitations like entities in
>logic cell must be organized in tree structure, interconnection must
>build on switches and the overall structure must be repetitive. Even
>though, the software is flexible enough to be customized to different
>FPGA structures.
>
>The frustration I am facing to is that there is few chance to practice
>since the top priority task for a startup is to make money and
>survive. So after talking with my boss, now I am seeking opportunities
>outside.
>
>Main features of the software:
>
>  1. Flexible logic cell structure. We have developed algorithm
>  performing technology mapping and packing in the same time. The
>  logic cell don't need to be look-up table only. You can add in other
>  special purpose entities like mux. The software can automatically
>  map and pack netlist into expected logic cells given a proper
>  specification.
>
>  2. Flexible interconnection. Similiar to VPR, the placement and
>  routing algorithms work on abstract interconnection model.
>
>  3. Heterogeneous placement. What VPR cannot do is placement for
>  blocks of different size, which is an unavoidable case for
>  real-world FPGA designs. For example, adders are usually synthesized
>  to a bank of logic cells which requires to be placed along dedicated
>  carry chains. Our algorithm deals with such cases by a
>  partition-and-place approach.
>
>  4. Unified design representation. All algorithms read design from
>  and store to the same database. So there is no need for data
>  transformation as using discrete tools like ABCmap and VPR.
>
>  5. Complete Pythonization (ongoing). The database and core
>  algorithms are written in C++. But we are porting the database to
>  Python so that one can operate on designs directly from Python. The
>  core algorithms will also be exposed to Python. By enjoying the
>  elegancy and extensibility of Python, design flows are built up
>  quite easily.
>
>Then I have to mention some shortages of the software.
>
>  1. No GUI/IDE. We are used to scripting and is unfamiliar with
>  GUI development. But I think with Python it is easy to design
>  cross-platform GUI and IDE.
>
>  2. No RTL design entry. Currently we are using icarus to parse RTL
>  Verilog to gate level. We are thinking of build an RTL HDL parser
>  but haven't have time to kick it off.
>
>  3. No synthesis optimization. Since we haven't reach RTL level,
>  there is no synthesis and logic optimization algorithms yet.
>
>  4. Not timing-driven. Existing algorithms are bound to resource
>  constraints. We haven't put timing constraints into consideration
>  yet.
>
>I am wondering whether there is any FPGA startup or other design house
>that works on embedded reconfigurable fabric will need such kind of
>software. If not any, it will be locked up in the basement until 2012
>or someday due to the company strategy. As a main developer, I will be
>very sad if so. That is why I post here. I am looking for an
>opportunity to practice and to push forward the software.
>
>Personally I think open-source is one of the possible way out and it
>is the most interesting way. It will be cool if we can build up an
>open source design automation flow to lower the software barrel for
>FPGA/reconfigurable market. But there is a long way to go. Besides,
>since the software is still my company's proprietary, though the
>company is open to open source, I have to find a profitable reason for
>open-source.
>
>Should you have any suggestions, advices, critism or willings, please
>fill free to let me know. I will appreciate very much for your feed
>back. And thank you for reading this far.
>
>Yujie Wen
>
>Celestial Semiconductor.
>Shanghai Office.
>yujie.wen REPLACE_WITH_AT celestialsemi.cn
>
>
>
>
>	   
>					
>---------------------------------------		
>Posted through http://www.FPGARelated.com
>

For your HDL entry and parsing - why don't you use MyHDL ? It is a python
module so would gel with your pythonization idea. It also has a built in
verilod/vhdl code generator.

Personally I would love to contribute to an open source fpga development
tool. So if it is going to be locked up, its better to release it as open
source; the making money part can come later when the software picks up.	  

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

Article: 148087
Subject: GTKWave 3.3.7 for Windows is available
From: Muzaffer Kal <kal@dspia.com>
Date: Sat, 19 Jun 2010 23:40:44 -0700
Links: << >>  << T >>  << A >>
Hi everyone,
The latest version of GTKWave (3.3.7)
windows binary is available here: http://www.dspia.com/gtkwave.html
You need to grab TCL-TK libraries in addition to the GTK libraries in
two separate archives if you don't have them.
If you have previously installed 3.3.0, only the exe file is
necessary.
-- 
Muzaffer Kal

DSPIA INC.
ASIC/FPGA Design Services

http://www.dspia.com

Article: 148088
Subject: Re: Anyone interested in customizable EDA software for FPGA?
From: "Yujie Wen" <yjwen.ty@n_o_s_p_a_m.n_o_s_p_a_m.gmail.com>
Date: Sun, 20 Jun 2010 02:46:28 -0500
Links: << >>  << T >>  << A >>
>>Hello.
>>
>>I am working at an SoC startup developing EDA software for FPGA-like
>>structures. Currently we have a half-finished software covering from
>>technology mapping to placement and routing for FPGA. I am looking for
>>opportunities to put the software into practice.
>>
>>Originally the software was expected to evaluate FPGA structures
>>(known or unknown) for various application domains. So it is not
>>designated to any specific logic cell or interconnect. Instead, given
>>structure descriptions, this software can perform technology mapping,
>>packing, placement and routing on a wide variety of
>>structures. Actually, there does exist limitations like entities in
>>logic cell must be organized in tree structure, interconnection must
>>build on switches and the overall structure must be repetitive. Even
>>though, the software is flexible enough to be customized to different
>>FPGA structures.
>>
>>The frustration I am facing to is that there is few chance to practice
>>since the top priority task for a startup is to make money and
>>survive. So after talking with my boss, now I am seeking opportunities
>>outside.
>>
>>Main features of the software:
>>
>>  1. Flexible logic cell structure. We have developed algorithm
>>  performing technology mapping and packing in the same time. The
>>  logic cell don't need to be look-up table only. You can add in other
>>  special purpose entities like mux. The software can automatically
>>  map and pack netlist into expected logic cells given a proper
>>  specification.
>>
>>  2. Flexible interconnection. Similiar to VPR, the placement and
>>  routing algorithms work on abstract interconnection model.
>>
>>  3. Heterogeneous placement. What VPR cannot do is placement for
>>  blocks of different size, which is an unavoidable case for
>>  real-world FPGA designs. For example, adders are usually synthesized
>>  to a bank of logic cells which requires to be placed along dedicated
>>  carry chains. Our algorithm deals with such cases by a
>>  partition-and-place approach.
>>
>>  4. Unified design representation. All algorithms read design from
>>  and store to the same database. So there is no need for data
>>  transformation as using discrete tools like ABCmap and VPR.
>>
>>  5. Complete Pythonization (ongoing). The database and core
>>  algorithms are written in C++. But we are porting the database to
>>  Python so that one can operate on designs directly from Python. The
>>  core algorithms will also be exposed to Python. By enjoying the
>>  elegancy and extensibility of Python, design flows are built up
>>  quite easily.
>>
>>Then I have to mention some shortages of the software.
>>
>>  1. No GUI/IDE. We are used to scripting and is unfamiliar with
>>  GUI development. But I think with Python it is easy to design
>>  cross-platform GUI and IDE.
>>
>>  2. No RTL design entry. Currently we are using icarus to parse RTL
>>  Verilog to gate level. We are thinking of build an RTL HDL parser
>>  but haven't have time to kick it off.
>>
>>  3. No synthesis optimization. Since we haven't reach RTL level,
>>  there is no synthesis and logic optimization algorithms yet.
>>
>>  4. Not timing-driven. Existing algorithms are bound to resource
>>  constraints. We haven't put timing constraints into consideration
>>  yet.
>>
>>I am wondering whether there is any FPGA startup or other design house
>>that works on embedded reconfigurable fabric will need such kind of
>>software. If not any, it will be locked up in the basement until 2012
>>or someday due to the company strategy. As a main developer, I will be
>>very sad if so. That is why I post here. I am looking for an
>>opportunity to practice and to push forward the software.
>>
>>Personally I think open-source is one of the possible way out and it
>>is the most interesting way. It will be cool if we can build up an
>>open source design automation flow to lower the software barrel for
>>FPGA/reconfigurable market. But there is a long way to go. Besides,
>>since the software is still my company's proprietary, though the
>>company is open to open source, I have to find a profitable reason for
>>open-source.
>>
>>Should you have any suggestions, advices, critism or willings, please
>>fill free to let me know. I will appreciate very much for your feed
>>back. And thank you for reading this far.
>>
>>Yujie Wen
>>
>>Celestial Semiconductor.
>>Shanghai Office.
>>yujie.wen REPLACE_WITH_AT celestialsemi.cn
>>
>>
>>
>>
>>	   
>>					
>>---------------------------------------		
>>Posted through http://www.FPGARelated.com
>>
>
>For your HDL entry and parsing - why don't you use MyHDL ? It is a python
>module so would gel with your pythonization idea. It also has a built in
>verilod/vhdl code generator.

We can't force designers give up Verilog or VHDL and rewrite their design
in MyHDL. I am afraid the software will never be popular without support 
to popular HDL entries. But MyHDL is a great plus. And I will work out a
MyHDL entry later because, as you said, Python is the easy-to-go bridge 
between the two.

>
>Personally I would love to contribute to an open source fpga development
>tool. So if it is going to be locked up, its better to release it as open
>source; the making money part can come later when the software picks up.	 


That's great! Let me first find a win-win solution towards open-source. :)

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

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

Article: 148089
Subject: Re: Xilinx DCM Block Stability Issues
From: Brian Drummond <brian_drummond@btconnect.com>
Date: Sun, 20 Jun 2010 11:30:16 +0100
Links: << >>  << T >>  << A >>
On Sat, 19 Jun 2010 19:58:56 -0400, Randy Yates <yates@ieee.org> wrote:

>Gabor <gabor@alacron.com> writes:
>
>> On Jun 19, 6:00pm, Randy Yates <ya...@ieee.org> wrote:

>>>
>>> Anyway, if anyone has experienced or heard of such problems
>>> with the DCM module and knows of a fix, I'd appreciate a
>>> pointer. Thanks!
>
>> What is your clock source? 
>
>I'm not sure (don't have the schematic here) but I think it's
>a TI CDC924.

Deriving its own clock from a 14.318MHz crystal, or a reference oscillator?

A quick look at the CDC924 datasheet suggests one thing...
check you have spread-spectrum turned off!

- Brian

Article: 148090
Subject: Re: Xilinx DCM Block Stability Issues
From: Gabor <gabor@alacron.com>
Date: Sun, 20 Jun 2010 07:38:49 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Jun 20, 6:30=A0am, Brian Drummond <brian_drumm...@btconnect.com>
wrote:
> On Sat, 19 Jun 2010 19:58:56 -0400, Randy Yates <ya...@ieee.org> wrote:
> >Gabor <ga...@alacron.com> writes:
>
> >> On Jun 19, 6:00 pm, Randy Yates <ya...@ieee.org> wrote:
>
> >>> Anyway, if anyone has experienced or heard of such problems
> >>> with the DCM module and knows of a fix, I'd appreciate a
> >>> pointer. Thanks!
>
> >> What is your clock source?
>
> >I'm not sure (don't have the schematic here) but I think it's
> >a TI CDC924.
>
> Deriving its own clock from a 14.318MHz crystal, or a reference oscillato=
r?
>
> A quick look at the CDC924 datasheet suggests one thing...
> check you have spread-spectrum turned off!
>
> - Brian

One more thing, the max jitter specs are all at least 300 ps,
and if I'm not mistaken this exceeds the jitter tolerance of
the Spartan 3E.  There is no mention of whether the cycle-to-cycle
jitter depends on the spread-spectrum feature, but I would have
thought that if it did they would spec the presumably lower
number for non spread-spectrum jitter.

I have used similar chips from Cypress (CY22392) and found that
even without spread-spectrum induced jitter they are only
marginal for use with the Xilinx DCM's.  Newer Xilinx parts
have PLL's that can handle 1 ns peak-to-peak jitter, but with
Spartan 3E you might need to clean up your clock externally
or use another part to do the required frequency geenration.

Regards,
Gabor

Article: 148091
Subject: Re: Newer Model Instrumentation Amp
From: John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com>
Date: Sun, 20 Jun 2010 10:14:54 -0700
Links: << >>  << T >>  << A >>
On 20 Jun 2010 08:29:57 -0700, Winfield Hill
<Winfield_member@newsguy.com> wrote:

>John Larkin wrote...
>>
>> On a current design, I had to make my own. I wanted lots of
>> overvoltage protection, logic-switchable gains from 0.05 to 256, high
>> precision, and at least +-12 volts of common-mode range, 120 dB CMRR
>> at high gain. I wound up with a classic 3-opamp diffamp, using an
>> LT1124 dual opamp, four Supertex depletion mode fets for protection, a
>> discrete string of thinfilm resistors, one DPDT gain switch relay, two
>> analog muxes, and an INA154 as the second stage. Two tiny trimpots
>> tweak cmrr. Times 16 on one board. I'd love to get all that in a SO-8!
>
> Indeed. 
>
> What was its CMRR at 1 and 10kHz, that's a tough region.

I'm after common-mode rejection for reasonable ground loops (DC, 60
Hz, mild harmonics) and volts of DC from load cell bridges. We tune
the CMRR with a 10 volt p-p, 100 Hz square wave applied to both
inputs, and the residual, as you turn the tweak pots, looks pretty
square. We are currently applying the square wave and looking at the
IA output with the gain set to max, using signal averaging on a scope
at 2 mv/div, which is 8 uv/div relative to the input. Seems to work. I
want to do it all in software, with a lockin-type thing, based on
reading our ADC and synchronously detecting it against the cm square
wave; if we sell enough of these, it might be worth writing that code.

Here it is:

http://www.highlandtechnology.com/DSS/V490DS.html

The analog stuff pretty much just worked. The big problems were

1. The AD7699 ADC data sheet is, to be polite, terse. The differential
inputs are unusual. It is just barely possible, or maybe according to
the specs impossible, to actually run it at 500 KHz. A timing diagram
might be helpful.

2. I rashly promised 8-pole digital filtering down to 1 Hz, Bessel and
Butterworth. That turns out to be non-trivial when you get to
500,000:1 sample/cutoff ratio. Three architectures later, one
consultant hired/paid/dumped, great amounts of experiment and
simulation and debate, it seems to work. That adventure deserves a
thread of its own. One hint: the classic DSP butterfly filter explodes
at ratios like this.

3. The lead customer liked the filtering concept so much he asked for
two independent filters per channel, one for the realtime data and
another for the FIFOs. That's 32 filters and 16 4Kx16 FIFOs and lots
of other junk in a Spartan6/45.

4. The Xilinx software is a train wreck, which greatly complicated 2)
and 3). Rev 12, supposedly the one that supports Spartan6 properly, is
worse than 11. You say "place that flipflop in an i/o block" and it
says, after considering the request for five or six hours, "drop
dead." We may start using Altera for new designs.

I'm tweaking the rev C board layout and finishing up the firmware this
weekend. I get interrupted too much at work to let me concentrate on
stuff like this. I can't multitask and get serious work done.

This is Fathers Day and it's been Meat Weekend. Rubbed Tri-tip last
night, BBQ ribs tonight. Nothing green in sight.

John


Article: 148092
Subject: Re: Xilinx DCM Block Stability Issues
From: Randy Yates <yates@ieee.org>
Date: Mon, 21 Jun 2010 02:22:01 -0400
Links: << >>  << T >>  << A >>
Gabor <gabor@alacron.com> writes:

> On Jun 20, 6:30 am, Brian Drummond <brian_drumm...@btconnect.com>
> wrote:
>> On Sat, 19 Jun 2010 19:58:56 -0400, Randy Yates <ya...@ieee.org> wrote:
>> >Gabor <ga...@alacron.com> writes:
>>
>> >> On Jun 19, 6:00 pm, Randy Yates <ya...@ieee.org> wrote:
>>
>> >>> Anyway, if anyone has experienced or heard of such problems
>> >>> with the DCM module and knows of a fix, I'd appreciate a
>> >>> pointer. Thanks!
>>
>> >> What is your clock source?
>>
>> >I'm not sure (don't have the schematic here) but I think it's
>> >a TI CDC924.

Correction: It's a CDCE706.

>> Deriving its own clock from a 14.318MHz crystal, or a reference oscillator?
>>
>> A quick look at the CDC924 datasheet suggests one thing...
>> check you have spread-spectrum turned off!
>>
>> - Brian
>
> One more thing, the max jitter specs are all at least 300 ps,
> and if I'm not mistaken this exceeds the jitter tolerance of
> the Spartan 3E.  There is no mention of whether the cycle-to-cycle
> jitter depends on the spread-spectrum feature, but I would have
> thought that if it did they would spec the presumably lower
> number for non spread-spectrum jitter.
>
> I have used similar chips from Cypress (CY22392) and found that
> even without spread-spectrum induced jitter they are only
> marginal for use with the Xilinx DCM's.  Newer Xilinx parts
> have PLL's that can handle 1 ns peak-to-peak jitter, but with
> Spartan 3E you might need to clean up your clock externally
> or use another part to do the required frequency geenration.

Thanks for the tips - but does any of this still go for the CDCE706?
-- 
Randy Yates                      % "Bird, on the wing,
Digital Signal Labs              %   goes floating by
mailto://yates@ieee.org          %   but there's a teardrop in his eye..."
http://www.digitalsignallabs.com % 'One Summer Dream', *Face The Music*, ELO

Article: 148093
Subject: Re: Xilinx DCM Block Stability Issues
From: Randy Yates <yates@ieee.org>
Date: Mon, 21 Jun 2010 02:29:34 -0400
Links: << >>  << T >>  << A >>
Randy Yates <yates@ieee.org> writes:

> Correction: It's a CDCE706.

Also we have initialized it like this:

  1. All clock slew rate controls are set to max (11b).

  2. Byte 25, SSC modulation selection, is not transmitted, thus
  the spread spectrum control should be at its default, which is
  off.

--RY

>
>>> Deriving its own clock from a 14.318MHz crystal, or a reference oscillator?
>>>
>>> A quick look at the CDC924 datasheet suggests one thing...
>>> check you have spread-spectrum turned off!
>>>
>>> - Brian
>>
>> One more thing, the max jitter specs are all at least 300 ps,
>> and if I'm not mistaken this exceeds the jitter tolerance of
>> the Spartan 3E.  There is no mention of whether the cycle-to-cycle
>> jitter depends on the spread-spectrum feature, but I would have
>> thought that if it did they would spec the presumably lower
>> number for non spread-spectrum jitter.
>>
>> I have used similar chips from Cypress (CY22392) and found that
>> even without spread-spectrum induced jitter they are only
>> marginal for use with the Xilinx DCM's.  Newer Xilinx parts
>> have PLL's that can handle 1 ns peak-to-peak jitter, but with
>> Spartan 3E you might need to clean up your clock externally
>> or use another part to do the required frequency geenration.
>
> Thanks for the tips - but does any of this still go for the CDCE706?

-- 
Randy Yates                      % "My Shangri-la has gone away, fading like 
Digital Signal Labs              %  the Beatles on 'Hey Jude'" 
mailto://yates@ieee.org          %  
http://www.digitalsignallabs.com % 'Shangri-La', *A New World Record*, ELO

Article: 148094
Subject: Re: Xilinx DCM Block Stability Issues
From: Gabor <gabor@alacron.com>
Date: Mon, 21 Jun 2010 06:29:54 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Jun 21, 2:22=A0am, Randy Yates <ya...@ieee.org> wrote:
> Gabor <ga...@alacron.com> writes:
> > On Jun 20, 6:30=A0am, Brian Drummond <brian_drumm...@btconnect.com>
> > wrote:
> >> On Sat, 19 Jun 2010 19:58:56 -0400, Randy Yates <ya...@ieee.org> wrote=
:
> >> >Gabor <ga...@alacron.com> writes:
>
> >> >> On Jun 19, 6:00 pm, Randy Yates <ya...@ieee.org> wrote:
>
> >> >>> Anyway, if anyone has experienced or heard of such problems
> >> >>> with the DCM module and knows of a fix, I'd appreciate a
> >> >>> pointer. Thanks!
>
> >> >> What is your clock source?
>
> >> >I'm not sure (don't have the schematic here) but I think it's
> >> >a TI CDC924.
>
> Correction: It's a CDCE706.
>
>
>
> >> Deriving its own clock from a 14.318MHz crystal, or a reference oscill=
ator?
>
> >> A quick look at the CDC924 datasheet suggests one thing...
> >> check you have spread-spectrum turned off!
>
> >> - Brian
>
> > One more thing, the max jitter specs are all at least 300 ps,
> > and if I'm not mistaken this exceeds the jitter tolerance of
> > the Spartan 3E. =A0There is no mention of whether the cycle-to-cycle
> > jitter depends on the spread-spectrum feature, but I would have
> > thought that if it did they would spec the presumably lower
> > number for non spread-spectrum jitter.
>
> > I have used similar chips from Cypress (CY22392) and found that
> > even without spread-spectrum induced jitter they are only
> > marginal for use with the Xilinx DCM's. =A0Newer Xilinx parts
> > have PLL's that can handle 1 ns peak-to-peak jitter, but with
> > Spartan 3E you might need to clean up your clock externally
> > or use another part to do the required frequency geenration.
>
> Thanks for the tips - but does any of this still go for the CDCE706?
> --
> Randy Yates =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0% "Bird, on the wi=
ng,
> Digital Signal Labs =A0 =A0 =A0 =A0 =A0 =A0 =A0% =A0 goes floating by
> mailto://ya...@ieee.org =A0 =A0 =A0 =A0 =A0% =A0 but there's a teardrop i=
n his eye..."http://www.digitalsignallabs.com% 'One Summer Dream', *Face Th=
e Music*, ELO

The jitter looks a lot better on the CDCE706.  Still at the low
end of the VCO frequency range it's perhaps marginal for the
Spartan 3E.  Look at your VCO and divider settings.  The data
sheet seems to imply that setting the VCO to a higher frequency
will reduce the cycle-to-cycle jitter.  So if you are
generating 63 MHz and dividing by 2, you might want to
instead generate 126 MHz and divide by 4.

Regards,
Gabor

Article: 148095
Subject: Re: Xilinx DCM Block Stability Issues
From: Randy Yates <yates@ieee.org>
Date: Mon, 21 Jun 2010 10:32:48 -0400
Links: << >>  << T >>  << A >>
Gabor <gabor@alacron.com> writes:
> [...]
> The jitter looks a lot better on the CDCE706.  Still at the low
> end of the VCO frequency range it's perhaps marginal for the
> Spartan 3E.  Look at your VCO and divider settings.  The data
> sheet seems to imply that setting the VCO to a higher frequency
> will reduce the cycle-to-cycle jitter.  So if you are
> generating 63 MHz and dividing by 2, you might want to
> instead generate 126 MHz and divide by 4.

Thanks Gabor!
-- 
Randy Yates                      % "Watching all the days go by...    
Digital Signal Labs              %  Who are you and who am I?"
mailto://yates@ieee.org          % 'Mission (A World Record)', 
http://www.digitalsignallabs.com % *A New World Record*, ELO

Article: 148096
Subject: Xilinx BULLSHITIX-8, when?
From: Antti <antti.lukats@googlemail.com>
Date: Mon, 21 Jun 2010 11:27:30 -0700 (PDT)
Links: << >>  << T >>  << A >>
the X-7 roadmap and all device table are no online,
and the ARM11 is coming is also all public knowledge, but.. where? in
what family?

spartan is dead, now is Artix, und Kintex? but where is ARM11?

in BULLSHITIX-8 release?

I wonder. of course its very interesting to see how much mess Xilinx
is able
to organize with the 7 series, right now Xilinx online shop list
exactly 2 devices of Spartan-6ES both going to avnet no stock
there was initial stock of 45 pieces of Spartan-6 at digikey
after that was depleted digikey has not received any new s-6 silicon.

so, when comes spartan-6 general availability?
does it makes to wait?
or maybe it makes more sense to wait the Artix-7?
or maybe..look for alternatives?


Antti

Article: 148097
Subject: Re: Xilinx BULLSHITIX-8, when?
From: Rob Gaddi <rgaddi@technologyhighland.com>
Date: Mon, 21 Jun 2010 11:45:47 -0700
Links: << >>  << T >>  << A >>
On 6/21/2010 11:27 AM, Antti wrote:
> the X-7 roadmap and all device table are no online,
> and the ARM11 is coming is also all public knowledge, but.. where? in
> what family?
>
> spartan is dead, now is Artix, und Kintex? but where is ARM11?
>
> in BULLSHITIX-8 release?
>
> I wonder. of course its very interesting to see how much mess Xilinx
> is able
> to organize with the 7 series, right now Xilinx online shop list
> exactly 2 devices of Spartan-6ES both going to avnet no stock
> there was initial stock of 45 pieces of Spartan-6 at digikey
> after that was depleted digikey has not received any new s-6 silicon.
>
> so, when comes spartan-6 general availability?
> does it makes to wait?
> or maybe it makes more sense to wait the Artix-7?
> or maybe..look for alternatives?
>
>
> Antti

Right now I'm working on two S6 projects, both of which are absolute 
disasters due to problems with the toolchain.  My DRAM problem from a 
month ago, Xilinx ultimately told me was my problem and they washed 
their hands of it.  Now on my other project, version 12 of the tools 
uses 10% more of the chip than version 11 and neither is willing to 
respect a simple IOB=FORCE.  I've got a WebCase crawling along on it, 
but so far have been trained to not expect much from that process.

I'm finding my choice of Xilinx FPGAs to be the single largest 
impediment to my actually getting product out the door.  Spartan 6 has 
been a trainwreck, and the decision to pull back from NuHo to only AvNet 
has meant that I don't even have any support through my distribution 
chain anymore.  And now they're touting 7 series silicon and expecting 
us to be excited?

Antti, of your choices I know which one I'm taking.  My Arrow sales rep, 
who has always been responsive and supported me to the hilt, has been 
asking me for the longest time to have a serious sit down with her 
Altera FAEs to talk about moving all of Highland's future designs over, 
company wide.  We're having it Friday.

-- 
Rob Gaddi, Highland Technology
Email address is currently out of order

Article: 148098
Subject: Re: Newer Model Instrumentation Amp
From: "langwadt@fonz.dk" <langwadt@fonz.dk>
Date: Mon, 21 Jun 2010 11:53:34 -0700 (PDT)
Links: << >>  << T >>  << A >>
On 20 Jun., 19:14, John Larkin
<jjlar...@highNOTlandTHIStechnologyPART.com> wrote:
snip
>
> 2. I rashly promised 8-pole digital filtering down to 1 Hz, Bessel and
> Butterworth. That turns out to be non-trivial when you get to
> 500,000:1 sample/cutoff ratio. Three architectures later, one
> consultant hired/paid/dumped, great amounts of experiment and
> simulation and debate, it seems to work. That adventure deserves a
> thread of its own. One hint: the classic DSP butterfly filter explodes
> at ratios like this.

That is DSP 101 and kinda obvious when you think about it, for a
filter
to have any effect at 1Hz it needs to have "memory" it that range.
with a 500kHz samplerate that either means a very high order or a very
high
precision

standard approach would be decimate the signal to a more resonable
sample rate


-Lasse

Article: 148099
Subject: Re: Newer Model Instrumentation Amp
From: John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com>
Date: Mon, 21 Jun 2010 12:58:43 -0700
Links: << >>  << T >>  << A >>
On Mon, 21 Jun 2010 11:53:34 -0700 (PDT), "langwadt@fonz.dk"
<langwadt@fonz.dk> wrote:

>On 20 Jun., 19:14, John Larkin
><jjlar...@highNOTlandTHIStechnologyPART.com> wrote:
>snip
>>
>> 2. I rashly promised 8-pole digital filtering down to 1 Hz, Bessel and
>> Butterworth. That turns out to be non-trivial when you get to
>> 500,000:1 sample/cutoff ratio. Three architectures later, one
>> consultant hired/paid/dumped, great amounts of experiment and
>> simulation and debate, it seems to work. That adventure deserves a
>> thread of its own. One hint: the classic DSP butterfly filter explodes
>> at ratios like this.
>
>That is DSP 101 and kinda obvious when you think about it, for a
>filter
>to have any effect at 1Hz it needs to have "memory" it that range.
>with a 500kHz samplerate that either means a very high order or a very
>high
>precision

You'd think that 16 bit data and 1e6:1 sample/cutoff ratio could be
accomplished with roughly 36 bit math.

>
>standard approach would be decimate the signal to a more resonable
>sample rate

That's one approach: build a chain of filters, clocked at declining
rates, and use the early ones to take the stress off the later ones.
Switch filters in or out as needed. We could do that, but it's harder
to explain to the customers. It's easier to model the product as a
lowpass filter followed by a 500 KHz ADC. 

The classic butterfly explodes violently as the clock:cutoff ratio
goes up. Numbers have to subtract to make tiny residuals, and stage
gains get absurd. Instead we used a double-integrator filter,
essentially a digital simulation of an analog state-variable filter.
That gets into trouble much more linearly than the butterfly, and each
2nd order section has a gain of exactly 1. It works using MAC blocks
using 18x18 multiplies and a sort of coarse barrel shifter into a 48
bit accumulator.

John




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