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 147800

Article: 147800
Subject: Re: MIG v3.0 inputs signal
From: "Eagle_mk4" <eagle_mk4@n_o_s_p_a_m.n_o_s_p_a_m.hotmail.com>
Date: Tue, 25 May 2010 02:49:39 -0500
Links: << >>  << T >>  << A >>
>On 18 Maj, 13:51, "Eagle_mk4" <eagle_mk4@n_o_s_p_a_m.hotmail.com>
>wrote:
>> Hi, I=B4m using MIG v3.0 to generate the VHDL code for a DDR SDRAM
>> controller. I implement the design but I don=B4t know which is the
>> format(values) the inputs signal, as for example app_af_addr,
app_mask_da=
>ta
>> and app_wdf_data. And where do I declare the signals?
>>
>> Thanks a lot in advance.
>>
>> --------------------------------------- =A0 =A0 =A0 =A0
>> Posted throughhttp://www.FPGARelated.com
>
>I'd like to help you but you need to be more precies.
>
>lutex
>

I am using MIG v.3.0 for V4 XC4VLX160-FF1513 Development Kit of Avnet. I
need to generate the vhdl code for a DDR SDRAM. With the MIG I generate the
all vhdl code for the control signals, but the input signals aren´t
generate and I don´t know how and where I declare it...

Thanks and sorry for my bad English.	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 147801
Subject: Re: MIG v3.0 inputs signal
From: "Eagle_mk4" <eagle_mk4@n_o_s_p_a_m.n_o_s_p_a_m.hotmail.com>
Date: Tue, 25 May 2010 02:52:59 -0500
Links: << >>  << T >>  << A >>
>On May 18, 7:51=A0am, "Eagle_mk4" <eagle_mk4@n_o_s_p_a_m.hotmail.com>
>wrote:
>> Hi, I=B4m using MIG v3.0 to generate the VHDL code for a DDR SDRAM
>> controller. I implement the design but I don=B4t know which is the
>> format(values) the inputs signal, as for example app_af_addr,
app_mask_da=
>ta
>> and app_wdf_data. And where do I declare the signals?
>>
>> Thanks a lot in advance.
>>
>> --------------------------------------- =A0 =A0 =A0 =A0
>> Posted throughhttp://www.FPGARelated.com
>
>In your MIG-generated directory structure should be a copy
>of the user guide that explains the use of these signals.  For
>earlier versions of MIG this was ug086.pdf.  As I recall it is
>not very clear about certain things like which address bits
>convert to row column and bank, but it has a few timing
>diagrams that help you understand the basics of the interface.
>
>for add_af_addr the lowest address bits map to the
>column address, the next bits up are the row address
>and the most significant bits are bank.  If it hasn't changed
>since MIG 2.3, the address has a fixed width of 31 bits,
>so you need to add up your column/row/bank sizes to
>see how many of these 31 bits are really used.
>
>app_wdf_data is the write data input and is twice the
>width of the external DDR interface so it runs at the
>main clock rate rather than twice the rate.  To determine
>how many words of data you need to provide with each
>write command, divide the burst length by two.  Also
>remember to start a burst on a burst boundary.  For
>example for a burst length of 4 you would provide two
>words of data and the low two bits of add_af_addr
>would be 00.
>
>app_mask_data is ignored if you don't generate the core
>with byte masking enabled.  If you need to use it, each
>bit of the mask corresponds to one byte of app_wdf_data.
>A one bit in the mask "masks out" the associated byte.
>If you want to write all bytes it should be zero.
>
>Take a look at the interface description in the user guide to
>see the sequence for pushing commands and data into
>the core.
>
>HTH,
>Gabor
>

Thanks for your info, but I have to generate this signals in a new vhdl
module   or in the top level module??

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

Article: 147802
Subject: Re: mux behavior
From: hssig <hssig@gmx.net>
Date: Tue, 25 May 2010 05:39:25 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi,

thank you for your opinions.

>I believe that the LUT/mux design on most FPGAs is such
>that they won't glitch in the case of a single input changing
>with LUT entries that don't change the output.

>My guess is that either they don't oscillate
>that fast, or that they won't couple even if they do.


Is there any FPGA vendor paper available that could clarify these
questions ?

cheers,
hssig



Article: 147803
Subject: Re: mux behavior
From: Gabor <gabor@alacron.com>
Date: Tue, 25 May 2010 05:49:33 -0700 (PDT)
Links: << >>  << T >>  << A >>
On May 24, 10:19=A0pm, glen herrmannsfeldt <g...@ugcs.caltech.edu>
wrote:
> Gabor <ga...@alacron.com> wrote:
> > On May 24, 3:58=A0pm, hssig <hs...@gmx.net> wrote:
> >> how does an (unclocked) 2:1 multiplexer behave if input B is selected
> >> and input A becomes metastable ? Does the metastability of A have an
> >> influence on the stability of the mux output at any point of time ?
> > For an ideal multiplexer, I'd have to say that input A should
> > have no effect if B is selected. =A0However in an FPGA, muxes are
> > often built from look-up tables, which could exhibit odd
> > behavior if one input stayed in the logic threshold region
> > long enough. =A0
>
> I believe that the LUT/mux design on most FPGAs is such
> that they won't glitch in the case of a single input changing
> with LUT entries that don't change the output. =A0One way to
> do that would be to implement the 16:1 mux as 15 2:1 mux
> chained together. =A0That might be a little too much, but you
> are supposed to be able to rely on them not glitching.
>
> > Think of a LUT as a bunch of ones and zeroes
> > feeding a larger (usually 16:1) mux. =A0Then A, B and SEL would
> > all be select inputs to the LUT. =A0Theoretically if SEL is
> > low, then the output value should not depend on B, but if
> > the mux uses decoders and FETs to connect one input at
> > a time to the output, and the B input is neither 1 nor 0,
> > the output could float. =A0Normally this period of floating
> > would be too short for the output to glitch while B is
> > transitioning. =A0But a particularly long metastable event
> > could float the output long enough for it to change state.
> > Such an event would indeed be rare.
>
> The one that I would wonder about is, if the metastable input
> was oscillating at a high frequency, that it might capacitively
> couple through. =A0My guess is that either they don't oscillate
> that fast, or that they won't couple even if they do.
> (With the current high-speed devices, it might not be possible
> to oscillate that fast.)
>
> -- glen

I don't think that metastability generally causes oscillation.
I would think that as soon as the signals swing one way or the
other they should stabilize.  Think of a coin landing on its
edge.  In the metastable case it stands upright for some time
before leaning toward heads or tails, but once it leans one
way or the other it accelerates to its resting position.

Regards,
Gabor

Article: 147804
Subject: Re: MIG v3.0 inputs signal
From: "RCIngham" <robert.ingham@n_o_s_p_a_m.n_o_s_p_a_m.gmail.com>
Date: Tue, 25 May 2010 08:07:25 -0500
Links: << >>  << T >>  << A >>
[snip]
>
>Thanks for your info, but I have to generate this signals in a new vhdl
>module   

Yes.

>or in the top level module??
>
>Jose	   
>	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 147805
Subject: Re: mux behavior
From: Symon <symon_brewer@hotmail.com>
Date: Tue, 25 May 2010 14:12:15 +0100
Links: << >>  << T >>  << A >>
On 5/25/2010 1:49 PM, Gabor wrote:
>
> I don't think that metastability generally causes oscillation.
> I would think that as soon as the signals swing one way or the
> other they should stabilize.  Think of a coin landing on its
> edge.  In the metastable case it stands upright for some time
> before leaning toward heads or tails, but once it leans one
> way or the other it accelerates to its resting position.
>
> Regards,
> Gabor

http://www.google.com/images?q=metastability

There are some piccies on Philip's site, as well as a whole bunch of 
stuff about metastability. I post this link in the hope it will head off 
yet another useless metastability thread. Fat chance.

Cheers, Syms.

Article: 147806
Subject: Re: mux behavior
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Tue, 25 May 2010 13:30:25 +0000 (UTC)
Links: << >>  << T >>  << A >>
Gabor <gabor@alacron.com> wrote:
(snip, I wrote)

>> The one that I would wonder about is, if the metastable input
>> was oscillating at a high frequency, that it might capacitively
>> couple through. 
(snip)
 
> I don't think that metastability generally causes oscillation.

I believe that it isn't usual, but I am not sure that it
isn't possible.

> I would think that as soon as the signals swing one way or the
> other they should stabilize.  Think of a coin landing on its
> edge.  In the metastable case it stands upright for some time
> before leaning toward heads or tails, but once it leans one
> way or the other it accelerates to its resting position.

Consider the case where the coin is spinning?  Or bouncing
around on the table before settling down?  But maybe the
analogy isn't perfect.

-- glen

Article: 147807
Subject: Re: Software bloat (Larkin was right)
From: MooseFET <kensmith@rahul.net>
Date: Tue, 25 May 2010 06:38:05 -0700 (PDT)
Links: << >>  << T >>  << A >>
On May 24, 7:53=A0pm, John Larkin
<jjlar...@highNOTlandTHIStechnologyPART.com> wrote:
> On Mon, 24 May 2010 18:32:32 -0500, "k...@att.bizzzzzzzzzzzz"
>
>
>
> <k...@att.bizzzzzzzzzzzz> wrote:
> >>>>I don't drive the Xilinx software myself, but R, my guy who does,
> >>>>uses MAKE files and avoids the top-level GUI, which is apparently
> >>>>crap.
>
> >>>Interesting. =A0I haven't used the latest Xilinx stuff.
>
> >>>>Xilinx puts pin assignments into a UCF "universal constraints file",
> >>>>which we create from the PADS pcb netlist. We tell The Brat what
> >>>>signals we prefer on which banks and such, she routes it the way that
> >>>>works best, and we make the pin file for Xilinx. Seems to work.
>
> >>>The point is that the UCF isn't so "universal". =A0VHDL attributes are=
 (sorta).
>
> >>The "universal" part has occasioned some humor. It is handy to have
> >>the pin numbers in a file off to the side, but we could just as well
> >>have taken the PADS netlist and mashed that into VHDL, if VHDL were
> >>the way to name pins. For Xilinx, it isn't.
>
> >It used to be *A* way. =A0Seems they've removed the possibility. =A0Mayb=
e it makes
> >it too easy to retarget for the competition. =A0;-)
>
> Speaking of which, we're looking very seriously at cutting over to
> Altera for new designs. The Xilinx software is so broken they will
> probably never fix it. And the support is ghastly... when you get any
> at all.

Switching to Altera looks to be safe to do.  I haven't designed in any
of their parts lately so I won't have to warn you away from any of
them.

[*]For those who don't know:  Every single CPLD I have ever designed
in has
gone out of production.

I like the Altera software (sort of).  There VHDL compiler had a major
bug in it back when I tried to use one of their parts in a design.
Chances are, they have fixed it by now.  I didn't use their part.

At least with Altera, they understand that without tools to make the
bits for them, their parts are useless so they actively try to make
the part easy for the tools to work with and make the tools work well.

Xilinx's tools are absolutely huge and so hard to figure out that I
gave up on their parts fairly early in looking at them.

Lattice made some parts that looked interesting but IIRC you could not
get the actual datasheet without making a user name and password.  I
ran away from that in terror.  There is no way that a company that
makes a good part is going to do stuff like that.

Atmel makes some CPLDs.  Unfortunately, their fitter doesn't work
and they, as far as I know, never fixed it. They promised the fix
and just never did it.  On that project we ended up switching to
Altera and then pulling the plug on the whole effort.

Way back when, a company called ICT made some parts that just made
it into the CPLD class.  They had the best tool for development of
CPLD stuff that I have ever seen.  This was back in the DOS days.
The tool was dead simple to use and just flat worked.  Unfortunately
for them, I designed in their flagship product.  You know the rest
of the story.




>
> John


Article: 147808
Subject: Re: Xilinx Xact software for XC2018 Logic Cell Array
From: d_s_klein <d_s_klein@yahoo.com>
Date: Tue, 25 May 2010 09:09:15 -0700 (PDT)
Links: << >>  << T >>  << A >>
On May 24, 3:07=A0pm, John Adair <g...@enterpoint.co.uk> wrote:
> The other problem you get with old software is the OS. I keep some
> machines with NT for times I need to run my old version software.
>
> John Adair
> Enterpoint Ltd.
>

Take a look at 'vmware' or 'virtualbox'.  I have been able to run
antique OS's (and applications) on modern hardware using both.

RK

Article: 147809
Subject: Re: Software bloat (Larkin was right)
From: d_s_klein <d_s_klein@yahoo.com>
Date: Tue, 25 May 2010 09:12:05 -0700 (PDT)
Links: << >>  << T >>  << A >>
On May 24, 7:53=A0pm, John Larkin
<jjlar...@highNOTlandTHIStechnologyPART.com> wrote:
> On Mon, 24 May 2010 18:32:32 -0500, "k...@att.bizzzzzzzzzzzz"
>
>
>
> <k...@att.bizzzzzzzzzzzz> wrote:
> >>>>I don't drive the Xilinx software myself, but R, my guy who does,
> >>>>uses MAKE files and avoids the top-level GUI, which is apparently
> >>>>crap.
>
> >>>Interesting. =A0I haven't used the latest Xilinx stuff.
>
> >>>>Xilinx puts pin assignments into a UCF "universal constraints file",
> >>>>which we create from the PADS pcb netlist. We tell The Brat what
> >>>>signals we prefer on which banks and such, she routes it the way that
> >>>>works best, and we make the pin file for Xilinx. Seems to work.
>
> >>>The point is that the UCF isn't so "universal". =A0VHDL attributes are=
 (sorta).
>
> >>The "universal" part has occasioned some humor. It is handy to have
> >>the pin numbers in a file off to the side, but we could just as well
> >>have taken the PADS netlist and mashed that into VHDL, if VHDL were
> >>the way to name pins. For Xilinx, it isn't.
>
> >It used to be *A* way. =A0Seems they've removed the possibility. =A0Mayb=
e it makes
> >it too easy to retarget for the competition. =A0;-)
>
> Speaking of which, we're looking very seriously at cutting over to
> Altera for new designs. The Xilinx software is so broken they will
> probably never fix it. And the support is ghastly... when you get any
> at all.
>
> John

I've had *very* good responses when I've called Altera and said that I
was wanting to migrate.

That said, no matter which side of the fence (A<->X) I'm on, it always
looks greener on the other side :)

RK

Article: 147810
Subject: Re: Software bloat (Larkin was right)
From: John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com>
Date: Tue, 25 May 2010 09:36:14 -0700
Links: << >>  << T >>  << A >>
On Tue, 25 May 2010 09:12:05 -0700 (PDT), d_s_klein
<d_s_klein@yahoo.com> wrote:

>On May 24, 7:53pm, John Larkin
><jjlar...@highNOTlandTHIStechnologyPART.com> wrote:
>> On Mon, 24 May 2010 18:32:32 -0500, "k...@att.bizzzzzzzzzzzz"
>>
>>
>>
>> <k...@att.bizzzzzzzzzzzz> wrote:
>> >>>>I don't drive the Xilinx software myself, but R, my guy who does,
>> >>>>uses MAKE files and avoids the top-level GUI, which is apparently
>> >>>>crap.
>>
>> >>>Interesting. I haven't used the latest Xilinx stuff.
>>
>> >>>>Xilinx puts pin assignments into a UCF "universal constraints file",
>> >>>>which we create from the PADS pcb netlist. We tell The Brat what
>> >>>>signals we prefer on which banks and such, she routes it the way that
>> >>>>works best, and we make the pin file for Xilinx. Seems to work.
>>
>> >>>The point is that the UCF isn't so "universal". VHDL attributes are (sorta).
>>
>> >>The "universal" part has occasioned some humor. It is handy to have
>> >>the pin numbers in a file off to the side, but we could just as well
>> >>have taken the PADS netlist and mashed that into VHDL, if VHDL were
>> >>the way to name pins. For Xilinx, it isn't.
>>
>> >It used to be *A* way. Seems they've removed the possibility. Maybe it makes
>> >it too easy to retarget for the competition. ;-)
>>
>> Speaking of which, we're looking very seriously at cutting over to
>> Altera for new designs. The Xilinx software is so broken they will
>> probably never fix it. And the support is ghastly... when you get any
>> at all.
>>
>> John
>
>I've had *very* good responses when I've called Altera and said that I
>was wanting to migrate.
>
>That said, no matter which side of the fence (A<->X) I'm on, it always
>looks greener on the other side :)
>
>RK

Xilinx probably has better silicon, and it works great. The software
is a train wreck.

John


Article: 147811
Subject: Re: mux behavior
From: Patrick Maupin <pmaupin@gmail.com>
Date: Tue, 25 May 2010 10:16:54 -0700 (PDT)
Links: << >>  << T >>  << A >>
On May 25, 8:12=A0am, Symon <symon_bre...@hotmail.com> wrote:

>  I post this link in the hope it will head off
> yet another useless metastability thread. Fat chance.

You need to post again right away.  The metastability should only
really be a problem between your first post and your second post.  Two
posts should be enough to clear it, but there might be some people who
disagree, so maybe you should make two more posts to be on the safe
side.

Pat

Article: 147812
Subject: Re: mux behavior
From: Gabor <gabor@alacron.com>
Date: Tue, 25 May 2010 10:42:46 -0700 (PDT)
Links: << >>  << T >>  << A >>
On May 25, 9:30=A0am, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
> Gabor <ga...@alacron.com> wrote:
>
> (snip, I wrote)
>
> >> The one that I would wonder about is, if the metastable input
> >> was oscillating at a high frequency, that it might capacitively
> >> couple through.
>
> (snip)
>
> > I don't think that metastability generally causes oscillation.
>
> I believe that it isn't usual, but I am not sure that it
> isn't possible.
>
> > I would think that as soon as the signals swing one way or the
> > other they should stabilize. =A0Think of a coin landing on its
> > edge. =A0In the metastable case it stands upright for some time
> > before leaning toward heads or tails, but once it leans one
> > way or the other it accelerates to its resting position.
>
> Consider the case where the coin is spinning? =A0Or bouncing
> around on the table before settling down? =A0But maybe the
> analogy isn't perfect.
>
> -- glen

I was going by the posts about FPGA fabric flip-flops.  In the
many discussions on metastability, the gurus seemed to say that
oscillation is not a typical manifestation in these structures.
Of course the chip vendors don't generally want to disclose the
actual flip-flop structure, but it makes sense that
metastability caused by failure to meet setup and hold time
would not generally result in oscillation.  Perhaps metastability
caused by a runt clock pulse might?  In any case, getting back to
the point of the original post, my thought was that a metastable
state could cause the LUT output multiplexer to go essentially
tristate if it is implemented as a decoder driving pass gates.
That of course is another internal structure that the chip
vendors don't want to give the details of.  In any case it is
pretty clear that the LUT's in an FPGA are carefully designed
not to glitch when an input changes state unless that input
changes the output state.  It is possible to test that theory
by designing some asynchronous sequential logic using LUT's
and seeing if it behaves as anticipated.

Regards,
Gabor

Article: 147813
Subject: Re: mux behavior
From: Brian Drummond <brian_drummond@btconnect.com>
Date: Tue, 25 May 2010 21:17:05 +0100
Links: << >>  << T >>  << A >>
On Tue, 25 May 2010 10:16:54 -0700 (PDT), Patrick Maupin
<pmaupin@gmail.com> wrote:

>On May 25, 8:12am, Symon <symon_bre...@hotmail.com> wrote:
>
>>  I post this link in the hope it will head off
>> yet another useless metastability thread. Fat chance.
>
>You need to post again right away.  The metastability should only
>really be a problem between your first post and your second post.  Two
>posts should be enough to clear it, but there might be some people who
>disagree, so maybe you should make two more posts to be on the safe
>side.

I'm not sure you're right about that, I think it would be better to
remain undecided for a bit, and see what happens.

- Brian

Article: 147814
Subject: Re: Xilinx Xact software for XC2018 Logic Cell Array
From: nico@puntnl.niks (Nico Coesel)
Date: Tue, 25 May 2010 20:23:36 GMT
Links: << >>  << T >>  << A >>
John Adair <g1@enterpoint.co.uk> wrote:

>Depending on what you want to achieve there are ways to make boards
>simple by using modules like our previously mentioned Darnaw1. There
>are also the DIL format Craignell1 http://www.enterpoint.co.uk/component_replacements/craignell.html
>and Craignell2 http://www.enterpoint.co.uk/component_replacements/craignell2.html
>modules. These modules allow you to develop your own carrier board but
>handle the complex and costly BGA bit for you.
>
>There are other low cost products like our Polmaddie series
>http://www.enterpoint.co.uk/polmaddie/polmaddie_family.html offer ways
>into FPGA and CPLD technology at not a lot of cost. These particular
>boards sell 1 off at GBP 40 (approx USD 60, Euro 50) in one off and
>you get a free programming cable (parallel port) for that money. Club
>together with a couple of friends and you can get free worldwide
>shipping on our web shop if you can get the order over GBP 100.
>
>All of these products are bought by hobby engineers. Tools for all of
>the above are free to download. We also use 0.1 inch/ 2.54mm pitch
>headers/sockets a lot to facilitate hobby and student markets with
>many customers even building their add ons with simple stripboard.

This is definitely a sensible way to go. 

OTOH it is not very difficult to put a TQFP100 or PQ208 on a board
with a simple soldering iron.

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

Article: 147815
Subject: Re: mux behavior
From: Brian Drummond <brian_drummond@btconnect.com>
Date: Tue, 25 May 2010 21:25:39 +0100
Links: << >>  << T >>  << A >>
On Tue, 25 May 2010 10:42:46 -0700 (PDT), Gabor <gabor@alacron.com>
wrote:

>On May 25, 9:30am, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
>> Gabor <ga...@alacron.com> wrote:
>>
>> (snip, I wrote)
>>
>> >> The one that I would wonder about is, if the metastable input
>> >> was oscillating at a high frequency, that it might capacitively
>> >> couple through.
>>
>> (snip)
>>
>> > I don't think that metastability generally causes oscillation.
>>
>> I believe that it isn't usual, but I am not sure that it
>> isn't possible.
>>
>> > I would think that as soon as the signals swing one way or the
>> > other they should stabilize. Think of a coin landing on its
>> > edge. In the metastable case it stands upright for some time
>> > before leaning toward heads or tails, but once it leans one
>> > way or the other it accelerates to its resting position.
>>
>> Consider the case where the coin is spinning? Or bouncing
>> around on the table before settling down? But maybe the
>> analogy isn't perfect.
>>
>> -- glen
>
>I was going by the posts about FPGA fabric flip-flops.  In the
>many discussions on metastability, the gurus seemed to say that
>oscillation is not a typical manifestation in these structures.

There may be no oscillation on the metastable FF itself, but remember
that it is probably driving all its loads into their linear region. 
One or more of those loads (e.g. an inverter driven from it) may then
oscillate, but the metastable FF itself will not. 

(In any case, metastable events with any significant probability is
easily dealt with in FPGA as has been discussed many times before)

- Brian


Article: 147816
Subject: Re: Last Xilinx Webpack that was big-brother free?
From: radarman <jshamlet@gmail.com>
Date: Tue, 25 May 2010 13:50:23 -0700 (PDT)
Links: << >>  << T >>  << A >>
On May 22, 6:50=A0pm, John_H <newsgr...@johnhandwork.com> wrote:
> Call me a sadist, but I tend to cruise through the license agreements
> and EULAs before installing software to make sure I'm not being
> victimized by using someone's application. =A0I wanted to bring my S3E
> starter kit back up to prototype Xilinx-based algorithms while
> employed by a particularly Altera-friendly group. =A0Loading ISE 12.1, I
> not only find lawyer-speak that's longer than Facebook privacy policy
> but see that:
>
> =A0 "Webtalk" is a required component to run Webpack.
>
> A quote from the second page of legalese: "Please note that WebTalk
> will collect and transmit certain data that may contain (or be
> correlated to reveal, primarily via the Authorization Codes data)
> personally identifiable information. =A0By agreeing to this Agreement,
> you hereby give your consent (on behalf of Licensee and Users) for
> Xilinx to use and disclose this information anywhere in the world for
> the purposes and as described in this Agreement."
>
> Crud.
>
> Anyone know of the last Webpack I could get that doesn't transmit
> things like my constraints, devices, and authorization codes back to
> Xilinx? =A0I just want to prototype some stuff and do NOT like my
> computer to leak information out into the world beyond my control. =A0At
> the moment my form of control is to not install ISE. =A0To not use
> Xilinx.
>
> Hey - at least it's not like Cadence who says that anything I send
> them - designs, etc - effectively becomes public domain. =A0But it
> leaves a seriously bad taste in my mouth.
>
> - John_H

Altera does this as well, but offers the carrot approach instead. Turn
on web talk, and you get to run SignalTap. Xilinx apparently is going
the other route, which I find a bit troubling. However, it is easy
enough to deal with. Install a windows firewall, and block the
application from sending. Unfortunately, this is becoming more and
more common, and you would be surprised at how much traffic comes out
of the average PC without the owners knowledge these days.

If you want to be absolutely sure your firewall is working, run
Wireshark on another system (or, if you are the trusting sort, the
same machine), fire off a build, and see if anything crosses the wire
that looks like it came from a Xilinx tool. It's using https, so you
will probably have to filter on headers.

Article: 147817
Subject: Re: Xilinx Xact software for XC2018 Logic Cell Array
From: Philip Pemberton <usenet10@philpem.me.uk>
Date: 25 May 2010 21:17:59 GMT
Links: << >>  << T >>  << A >>
On Tue, 25 May 2010 20:23:36 +0000, Nico Coesel wrote:

> John Adair <g1@enterpoint.co.uk> wrote:
[...]
>>All of these products are bought by hobby engineers. Tools for all of
>>the above are free to download. We also use 0.1 inch/ 2.54mm pitch
>>headers/sockets a lot to facilitate hobby and student markets with many
>>customers even building their add ons with simple stripboard.
> 
> This is definitely a sensible way to go.

Seconded. The Drigmorn2 is a lovely little board -- 32MiB SDRAM, onboard 
SPI flash, switches, HD44780 LCD, and a ton of LEDs. Debugging it is a 
DREAM, especially when you can just plug a Harwin pin header into the LHS/
RHS headers, wire in a logic analyser pod and watch as closely as you 
like.

The only thing I don't like about it is the ISSI SDRAM -- the refresh 
rate figures in the datasheet are incorrect. Use 4096 cycles per 32ms 
(the refresh rate for the "Industrial" spec part) and it's fine, use 4096-
in-64ms (the "Commercial" spec rating) and you get random data corruption 
issues. I suspect the section on Auto Refresh has been copy-pasted from a 
datasheet for a different part and not checked against the tested 
specification... but that's just conjecture.

The other possibility is that the part on my DM2 is a mis-marked Ind Temp 
part, but the laser-markings say it *should* be a -7BL, or a 7ns part in 
Pb-free BGA... if it was ind-spec it *should* have been marked "-7BLI"...

> OTOH it is not very difficult to put a TQFP100 or PQ208 on a board with
> a simple soldering iron.

Yeah, tack down a few pins at a corner, then coat the pins in paste flux 
and drag-solder. Clean up with solder wick and you're done. If you're not 
a fan of manual labour you can use solder paste and a hot-air reflow 
station, but drag soldering is usually quicker... not to mention more 
reliable :)

-- 
Phil.
usenet10@philpem.me.uk
http://www.philpem.me.uk/
If mail bounces, replace "10" with the last two digits of the current year

Article: 147818
Subject: Advice on Xilinx Spelunking
From: Rob Gaddi <rgaddi@technologyhighland.com>
Date: Tue, 25 May 2010 14:32:59 -0700
Links: << >>  << T >>  << A >>
I've got a Spartan 6 design that I'm working with under ISE 11.5.  A 
code block that I would expect to take up about 200 LUTs is taking 800 
instead.  600 LUTs wouldn't be the end of the world, except I'm planning 
to replicate this block 32 times, which puts me well over the top.

So the question becomes where are all of the LUTs going?  There's 
nothing in the XST status report for the section that would imply 
anywhere near this much utilization.  I've tried looking over the RTL 
schematic; it's difficult to read and from what I could make out, there 
still wasn't anything to explain all those LUTs.  Then I tried looking 
through the technology schematic instead.  The viewer took forever to 
open the schematic, and when I finally got it open it took better than a 
minute any time I wanted to refresh the screen.  Needless to say, this 
got me nowhere.

So, I'm out for advice.  Any suggestions on figuring out just where all 
of those LUTs are going?

Thanks,
Rob

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

Article: 147819
Subject: Re: Software bloat (Larkin was right)
From: Philip Pemberton <usenet10@philpem.me.uk>
Date: 25 May 2010 21:47:47 GMT
Links: << >>  << T >>  << A >>
On Tue, 25 May 2010 06:38:05 -0700, MooseFET wrote:

> Switching to Altera looks to be safe to do.  I haven't designed in any
> of their parts lately so I won't have to warn you away from any of them.

I'm quite fond of them. My first "proper" FPGA devkit was a DE1 (bought 
mainly because it had a good price-performance ratio and the Minimig-DE1 
team were porting Minimig to it) so I've got a bit of a 'soft spot' for 
ALTR.

I will, however, admit that the first PLD I ever used was a Lattice GAL; 
their insistence that I needed a "Lattice Approved" programmer for it was 
a bit offputting until I found out about (and built a) GALBlast. Software 
was mediocre, I used to use Atmel-WinCupl, tried to learn registered 
logic but couldn't stand the syntax for that. All my GALs ended up being 
used as address decoders in my 6502 computer.

First CPLD I used was a Xilinx XC9572XL... back in the days when Windows 
98 was king, and you only had Win2000 if you were on the beta team. I'm a 
compulsive hoarder of LCD displays, and had a couple of direct-drive ones 
in my scrap bin. Spent the afternoon reverse engineering the display 
pinouts with a Fluke 25 DMM, then hooked up the CPLD and reversed the 
pixel shift order. Good fun.

> I like the Altera software (sort of).  There VHDL compiler had a major
> bug in it back when I tried to use one of their parts in a design.
> Chances are, they have fixed it by now.  I didn't use their part.

I usually use the Verilog side of things, though occasionally do mixed-
mode (Vlog+VHDL) when I have a VHDL IP core I need to use. That's pretty 
rare though.

> Xilinx's tools are absolutely huge and so hard to figure out that I gave
> up on their parts fairly early in looking at them.

I started learning ISE because I'd just bought a Drigmorn2. I figured 
Xilinx's free dev tools would be about as good as Altera's... how wrong I 
was!

Just getting the SDRAM timing right has been an exercise that would only 
appeal to a masochist. I finally figured it out at nearly 11:45 last 
night... kick the refresh timing down, then force everything SDRAM 
related into an IOB, set the slew rate to FAST, and figure out what to 
set the phase-shift of the DCM to.

When I did this on the DE1, Quartus picked up most of what I was doing, 
and all I had to set was the PLL phase-shift. Not bad. I think I had the 
LatticeMico32 core up and running in a few hours, and SDRAM a day or so 
after that.

> Lattice made some parts that looked interesting but IIRC you could not
> get the actual datasheet without making a user name and password.  I ran
> away from that in terror.  There is no way that a company that makes a
> good part is going to do stuff like that.

Can't say I've tried Lattice's FPGAs. I looked at them a few years ago 
and basically discounted them because I couldn't get hold of them 
(although I could get a programming cable... for £595, plus ~£2k for the 
ispLEVER software -- the cable alone was more expensive than XLNX's then-
current offering IIRC)

> Way back when, a company called ICT made some parts that just made it
> into the CPLD class.  They had the best tool for development of CPLD
> stuff that I have ever seen.  This was back in the DOS days. The tool
> was dead simple to use and just flat worked.  Unfortunately for them, I
> designed in their flagship product.  You know the rest of the story.

That would be the ICT PEEL series, right?

Allegedly still in production today -- ICT went bust, then Anachip bought 
the PLD product line, and Anachip were bought by Diodes Inc. The 
datasheets aren't on DI's website, but Mouser list the PEEL series as 
current products.

If you're hellbent on using SPLDs, the GAL series are still the best 
(IMO), but these days you're better off looking at a small CPLD like a 
Xilinx XC9500XL, CoolRunner or one of the Altera MAX-II parts... for a 
start they tend to be equal in price to (or cheaper than) the SPLDs.

-- 
Phil.
usenet10@philpem.me.uk
http://www.philpem.me.uk/
If mail bounces, replace "10" with the last two digits of the current year

Article: 147820
Subject: Re: Advice on Xilinx Spelunking
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Tue, 25 May 2010 21:54:41 +0000 (UTC)
Links: << >>  << T >>  << A >>
Rob Gaddi <rgaddi@technologyhighland.com> wrote:
> I've got a Spartan 6 design that I'm working with under ISE 11.5.  A 
> code block that I would expect to take up about 200 LUTs is taking 800 
> instead.  600 LUTs wouldn't be the end of the world, except I'm planning 
> to replicate this block 32 times, which puts me well over the top.

How full is the FPGA that you are targeting?  If not so full, I
believe that the tools don't try so hard.  Well, actually the LUT
count shouldn't be so far off, but the CLB count can change, as
it doesn't fill each CLB.

Otherwise, without knowing about the design it is hard to say.

Can you say a little about the logic?  How many counters, adders, RAMs.

Maybe it is using CLB for RAM, instead of BRAM?  

-- glen

Article: 147821
Subject: Re: Advice on Xilinx Spelunking
From: John_H <newsgroup@johnhandwork.com>
Date: Tue, 25 May 2010 15:42:40 -0700 (PDT)
Links: << >>  << T >>  << A >>
On May 25, 5:32=A0pm, Rob Gaddi <rga...@technologyhighland.com> wrote:
> I've got a Spartan 6 design that I'm working with under ISE 11.5. =A0A
> code block that I would expect to take up about 200 LUTs is taking 800
> instead. =A0600 LUTs wouldn't be the end of the world, except I'm plannin=
g
> to replicate this block 32 times, which puts me well over the top.
>
> So the question becomes where are all of the LUTs going? =A0There's
> nothing in the XST status report for the section that would imply
> anywhere near this much utilization. =A0I've tried looking over the RTL
> schematic; it's difficult to read and from what I could make out, there
> still wasn't anything to explain all those LUTs. =A0Then I tried looking
> through the technology schematic instead. =A0The viewer took forever to
> open the schematic, and when I finally got it open it took better than a
> minute any time I wanted to refresh the screen. =A0Needless to say, this
> got me nowhere.
>
> So, I'm out for advice. =A0Any suggestions on figuring out just where all
> of those LUTs are going?
>
> Thanks,
> Rob
>
> --
> Rob Gaddi, Highland Technology
> Email address is currently out of order

A good technology view will make the world of difference.  But it
seems Xilinx isn't giving you that.  I used the Synplify synthesizer's
HDL Analyst to get a superb technology view that allowed me to
understand the occasional oddity the synthesizer would produce from my
code.  I found that technology viewer to be a truly top-notch product
and sincerely helpful in keeping a design on track.

I've only glanced at the Xilinx technology viewer, seeing that it
looked like a last-gen VW beetle compared to a modern day Lexus in the
HDL Analyst.  It may do the job but it won't be a comfortable job if
it gets too involved.

Article: 147822
Subject: Re: Advice on Xilinx Spelunking
From: Symon <symon_brewer@hotmail.com>
Date: Tue, 25 May 2010 23:55:50 +0100
Links: << >>  << T >>  << A >>
On 5/25/2010 10:32 PM, Rob Gaddi wrote:
>
> So the question becomes where are all of the LUTs going?
>
> Thanks,
> Rob
>
Does ISE11.5 have FPGA editor?

Syms.


Article: 147823
Subject: Re: Software bloat (Larkin was right)
From: "krw@att.bizzzzzzzzzzzz" <krw@att.bizzzzzzzzzzzz>
Date: Tue, 25 May 2010 17:58:27 -0500
Links: << >>  << T >>  << A >>
On Tue, 25 May 2010 06:38:05 -0700 (PDT), MooseFET <kensmith@rahul.net> wrote:

>On May 24, 7:53pm, John Larkin
><jjlar...@highNOTlandTHIStechnologyPART.com> wrote:
>> On Mon, 24 May 2010 18:32:32 -0500, "k...@att.bizzzzzzzzzzzz"
>>
>>
>>
>> <k...@att.bizzzzzzzzzzzz> wrote:
>> >>>>I don't drive the Xilinx software myself, but R, my guy who does,
>> >>>>uses MAKE files and avoids the top-level GUI, which is apparently
>> >>>>crap.
>>
>> >>>Interesting. I haven't used the latest Xilinx stuff.
>>
>> >>>>Xilinx puts pin assignments into a UCF "universal constraints file",
>> >>>>which we create from the PADS pcb netlist. We tell The Brat what
>> >>>>signals we prefer on which banks and such, she routes it the way that
>> >>>>works best, and we make the pin file for Xilinx. Seems to work.
>>
>> >>>The point is that the UCF isn't so "universal". VHDL attributes are (sorta).
>>
>> >>The "universal" part has occasioned some humor. It is handy to have
>> >>the pin numbers in a file off to the side, but we could just as well
>> >>have taken the PADS netlist and mashed that into VHDL, if VHDL were
>> >>the way to name pins. For Xilinx, it isn't.
>>
>> >It used to be *A* way. Seems they've removed the possibility. Maybe it makes
>> >it too easy to retarget for the competition. ;-)
>>
>> Speaking of which, we're looking very seriously at cutting over to
>> Altera for new designs. The Xilinx software is so broken they will
>> probably never fix it. And the support is ghastly... when you get any
>> at all.
>
>Switching to Altera looks to be safe to do.  I haven't designed in any
>of their parts lately so I won't have to warn you away from any of
>them.
>
>[*]For those who don't know:  Every single CPLD I have ever designed
>in has
>gone out of production.
>
>I like the Altera software (sort of).  There VHDL compiler had a major
>bug in it back when I tried to use one of their parts in a design.
>Chances are, they have fixed it by now.  I didn't use their part.
>
>At least with Altera, they understand that without tools to make the
>bits for them, their parts are useless so they actively try to make
>the part easy for the tools to work with and make the tools work well.
>
>Xilinx's tools are absolutely huge and so hard to figure out that I
>gave up on their parts fairly early in looking at them.
>
>Lattice made some parts that looked interesting but IIRC you could not
>get the actual datasheet without making a user name and password.  I
>ran away from that in terror.  There is no way that a company that
>makes a good part is going to do stuff like that.
>
>Atmel makes some CPLDs.  Unfortunately, their fitter doesn't work
>and they, as far as I know, never fixed it. They promised the fix
>and just never did it.  On that project we ended up switching to
>Altera and then pulling the plug on the whole effort.

You forgot Actel.  Some of their parts are interesting, though LUT3s are quite
limiting and their choice of packages isn't that great.  They have some
*really* low power stuff and the new mixed-signal with embedded hard core
processor stuff is quite interesting.

I find it a huge advantage to not commit to one vendor.  Well, I should say,
it's an advantage for the small designs we do.  If I were using at the larger
Virtex or Stratix parts I'd likely have a different opinion (BTDT).

Article: 147824
Subject: Re: Advice on Xilinx Spelunking
From: Rob Gaddi <rgaddi@technologyhighland.com>
Date: Tue, 25 May 2010 16:39:35 -0700
Links: << >>  << T >>  << A >>
On 5/25/2010 2:54 PM, glen herrmannsfeldt wrote:
> Rob Gaddi<rgaddi@technologyhighland.com>  wrote:
>> I've got a Spartan 6 design that I'm working with under ISE 11.5.  A
>> code block that I would expect to take up about 200 LUTs is taking 800
>> instead.  600 LUTs wouldn't be the end of the world, except I'm planning
>> to replicate this block 32 times, which puts me well over the top.
>
> How full is the FPGA that you are targeting?  If not so full, I
> believe that the tools don't try so hard.  Well, actually the LUT
> count shouldn't be so far off, but the CLB count can change, as
> it doesn't fill each CLB.
>
> Otherwise, without knowing about the design it is hard to say.
>
> Can you say a little about the logic?  How many counters, adders, RAMs.
>
> Maybe it is using CLB for RAM, instead of BRAM?
>
> -- glen

Sure.  The widget in question does 8 pole IIR filtering of 16 bit data 
using 48-bit internal data paths.  The actual add/multiply/add math is 
taken care of by a subblock that uses a DSP48 slice and 222 LUTs that 
I'm not counting towards the 800.

The block I'm looking at is the wrapper that sequences the math 
operations and holds the internal states.  The logic infers two 48 bit 
LUT RAMs, one dual port, and one quad port.  There's a 24-bit LUT RAM 
and a 24 bit adder that I use to implement an FIR prefilter (the 8 zeros 
at z=-1 that you get from the bilinear transform of an 8 pole filter). 
There's an FSM with four states, and a couple of 3 bit counters.  There 
are two 18 bit comparators, but most of the LSBs of them should optimize 
out.

I'll append the code here.  I'm not bothering to include pkg_bus as 
well, but it just defines a simple WISHBONE bus and a few constants.

--

library IEEE;
use IEEE.STD_LOGIC_1164.all;
use IEEE.NUMERIC_STD.all;
use IEEE.STD_LOGIC_MISC.all;

use work.pkg_bus.all;

-- Xilinx specific macro library
-- library UNISIM;
-- use UNISIM.VComponents.all;

entity filter is
   port (
     -- Data path
     din   : in  signed(15 downto 0);
     nd    : in  boolean;

     dout  : out signed(15 downto 0);
     drdy  : out boolean;

     -- Coefficient path
     WB_IN : in  t_wb_mosi;
     WB_OUT  : out t_wb_miso;

     WB_SYS  : in  t_wb_sys
   );
end entity filter;

architecture Behavioral of filter is

   alias clk : std_logic is WB_SYS.CLK_I;
   alias rst : std_logic is WB_SYS.RST_I;

   -- Component declaration of the "filter_math" unit defined in
   -- file: "./src/vhdl/filter_math.vhd"
   component filter_math
   port(
     data : in SIGNED(47 downto 0);
     pre : in SIGNED(47 downto 0);
     post : in SIGNED(47 downto 0);
     k : in SIGNED(47 downto 0);
     lsd_nd : in BOOLEAN;
     ichg : out BOOLEAN;
     irdy : out BOOLEAN;
     y : out SIGNED(47 downto 0);
     lsd_rdy : out BOOLEAN;
     msd_rdy : out BOOLEAN;
     clk : in STD_LOGIC);
   end component;
   for all: filter_math use entity work.filter_math(Xilinx_DSP48A1);

   -- We're going to use a whole mess o' RAMs to store various
   -- and sundry.
   subtype t_data  is signed(47 downto 0);
   constant POLES    : integer := 8;
   constant MAX_IDX  : integer := POLES-1;

   -- Data memory is S3.45.
   subtype t_idx is integer range 0 to MAX_IDX;
   type t_ram    is array(t_idx) of t_data;
   signal ram_dat  : t_ram := (others => (others => '0'));

   subtype t_uns_idx is unsigned(2 downto 0);
   signal write_idx  : t_uns_idx;
   signal read_idx   : t_uns_idx;

   -- Coefficient memory is also S3.45, but since we're
   -- writing it from a 16 bit data bus, we need to be
   -- able to access it a word at a time.
   --
   type t_coefram  is array(t_idx) of t_wb_data;
   signal ram_k_hi : t_coefram := (others => (others => '0'));
   signal ram_k_md : t_coefram := (others => (others => '0'));
   signal ram_k_lo : t_coefram := (others => (others => '0'));

   -- As seen from the memory bus, the coefficients are
   -- 64 bits long.  The uppermost word of this is shared
   -- between all coefficients, and is the filter control
   -- word.

   signal fcw     : t_wb_data;

   -- Bits 2:0 are POLES_USED, which should be an odd number
   -- equal to the number of poles for this filter - 1.  Any
   -- even number here, including zero, will code for no filter.
   alias poles_used : std_logic_vector is fcw(2 downto 0);

   -- Hook the data up to the math core
   signal data : t_data;
   signal pre  : t_data;
   signal post : t_data;
   signal k  : t_data;
   signal y  : t_data;

   signal go   : boolean;

   signal lsd_nd : boolean;
   signal ichg   : boolean;
   signal irdy   : boolean;
   signal lsd_rdy  : boolean;
   signal msd_rdy  : boolean;

   -- Downstream of the math core we'll apply a cascade of 2 pole
   -- boxcar filters in order to put some zeros.  One bit growth per
   -- stage brings us to S1.23 when we're done.

   subtype t_fir_data is signed(din'length + POLES - 1 downto 0);
   type t_firram is array(t_idx) of t_fir_data;
   signal fir_cascade  : t_firram := (others => (others => '0'));
   signal fir_idx    : t_uns_idx;
   signal fir_din    : t_fir_data;

   -- Internal states of things
   signal fir_drdy   : boolean;
   signal use_fir_data : boolean;

   type t_state is (IDLE, FIR, IIR, RESET);
   signal state : t_state := RESET;

   -- LFSR noise generator.  When we first extend the 16 bit data to 24
   -- bits for the FIR filter, adding this noise in below the LSB helps
   -- make sure the IIR filters don't get into long, drawn out settlings.
   signal lfsr : std_logic_vector(22 downto 1) := (others => '0');

begin
   -------------------------------------------------------------------------
   --  Make sure our constants are compiled correctly.
   -------------------------------------------------------------------------

   assert (2**write_idx'length = POLES)
     report "Length of RAM index does not correspond to number of poles."
     severity failure;

   -------------------------------------------------------------------------
   --  Connect up the asynchronous data paths.
   -------------------------------------------------------------------------

   -- FIR data is in S1.23, the math core is expecting S3.45
   data  <=  SHIFT_LEFT(RESIZE(fir_din, data'length), 45-23) when 
use_fir_data
         else y;

   lsd_nd  <=  fir_drdy when use_fir_data else
         lsd_rdy;

   -- Everything else comes out of the RAMs.  ram_k has one r/w port and one
   -- read port, ram_dat has one write port and two read ports.
   --

   pre   <= ram_dat(TO_INTEGER(read_idx or "001"));
   post  <= ram_dat(TO_INTEGER(read_idx));
   k   <=  SIGNED(ram_k_hi(TO_INTEGER(read_idx))) &
         SIGNED(ram_k_md(TO_INTEGER(read_idx))) &
         SIGNED(ram_k_lo(TO_INTEGER(read_idx)));

   -- Instantiate our math core.
   MATH : filter_math
     port map(
       data => data,
       pre => pre,
       post => post,
       k => k,
       lsd_nd => lsd_nd,
       ichg => ichg,
       irdy => irdy,
       y => y,
       lsd_rdy => lsd_rdy,
       msd_rdy => msd_rdy,
       clk => clk
     );

   -------------------------------------------------------------------------
   --  WISHBONE coefficient readback.
   -------------------------------------------------------------------------

   WB_READBACK: process(WB_IN, fcw, ram_k_hi, ram_k_md, ram_k_lo)
     variable read_addr  : integer range 0 to MAX_IDX;
     variable word_addr  : integer range 0 to 3;

   begin
     read_addr := TO_INTEGER(WB_IN.ADDR(1 + read_idx'length downto 2));
     word_addr := TO_INTEGER(WB_IN.ADDR(1 downto 0));

     WB_OUT  <= WB_BADA_SLAVE;

     if read_addr <= MAX_IDX then
       case word_addr is
         when 0 => WB_OUT.DAT <= fcw;
         when 1 => WB_OUT.DAT <= ram_k_hi(read_addr);
         when 2 => WB_OUT.DAT <= ram_k_md(read_addr);
         when 3 => WB_OUT.DAT <= ram_k_lo(read_addr);
       end case;
     end if;

   end process WB_READBACK;

   -------------------------------------------------------------------------
   --  Wrangle the big state machine.
   -------------------------------------------------------------------------

   MACHINE: process
     variable write_addr : integer range 0 to 31;
     variable word_addr  : integer range 0 to 3;
     variable current  : t_data;

     variable unclamped  : signed(17 downto 0);  -- S3.15 number

   begin
     wait until rising_edge(clk);
     drdy    <= false;
     fir_drdy  <= false;

     if nd then
       assert (state = IDLE)
         report "New data request before IDLE state."
         severity error;
     end if;

     case state is
       when IDLE =>
         -- Hold things in the start state.
         use_fir_data  <= true;
         read_idx    <= (others => '0');
         write_idx   <= (others => '0');

         if nd then
           if (poles_used(0) = '0') then
             -- Allow for no filter at all
             dout  <= din;
             drdy  <= true;
             state <= IDLE;
           else
             -- Start our FIR filter with din at the MSBs.
             state   <= FIR;
             fir_idx   <= UNSIGNED(poles_used);
             fir_din   <= SHIFT_LEFT(
                     RESIZE(din & lfsr(lfsr'high), fir_din'length),
                     fir_din'length - din'length - 1
                   );
           end if;

         else
           state <= IDLE;
         end if;

       when FIR =>
         -- Store the value, push the average forward.
         fir_cascade(TO_INTEGER(fir_idx)) <= fir_din;

         fir_din <= SHIFT_RIGHT(fir_din, 1) +
               SHIFT_RIGHT(fir_cascade(TO_INTEGER(fir_idx)), 1);

         if (fir_idx = 0) then
           -- Start the IIR filter.  Repurpose the FIR index to count
           -- down the number of poles to do.
           state   <= IIR;
           fir_drdy  <= true;
           fir_idx   <= UNSIGNED(poles_used);
         else
           fir_idx   <= fir_idx - 1;
         end if;

       when IIR =>
         -- The main responsibilities are updating
         -- the pointers and updating the stored data.

         if msd_rdy then

           -- Update the stored data and advance the
           -- write pointer.  Also decrement the FIR index, which
           -- we're just using to count IIR stages at this point.

           ram_dat(TO_INTEGER(write_idx))  <= y;
           write_idx <= write_idx + 1;
           fir_idx   <= fir_idx - 1;

           if (fir_idx = 0) then
             state   <= IDLE;
             write_idx <= (others => '0');

             -- We've treated the data as S3.45 all the
             -- way through.  First, remap it to S3.15
             unclamped := RESIZE(SHIFT_RIGHT(y, 45-15), 18);

             -- Now clamp any excess.
             if TO_INTEGER(unclamped) >= 2**15 then
               dout  <= x"7FFF";

             elsif TO_INTEGER(unclamped) <= -(2**15) then
               dout  <= x"8001";

             else
               dout  <= RESIZE(unclamped, 16);

             end if;
             drdy    <= true;

           end if;

         elsif ichg and not lsd_nd then
           -- We can advance the read index ahead of
           -- time.
           read_idx <= write_idx + 1;

           if (fir_idx = 0) then
             use_fir_data  <= true;

           else
             use_fir_data  <= false;

           end if;

         end if;

       when RESET =>
         -- Initialize the states for both filters
         ram_dat(TO_INTEGER(write_idx))  <= (others => '0');
         fir_cascade(TO_INTEGER(fir_idx))<= (others => '0');

         if (fir_idx = 0) then
           write_idx <= (others => '0');
           state   <= IDLE;

         else
           write_idx <= write_idx + 1;
           fir_idx   <= fir_idx - 1;

         end if;

     end case;

     -- Allow bus writes to the coefficient RAM
     if is_write(WB_IN) then
       write_addr  := TO_INTEGER(WB_IN.ADDR(6 downto 2));
       word_addr := TO_INTEGER(WB_IN.ADDR(1 downto 0));

       if write_addr <= MAX_IDX then
         case word_addr is
           when 0 => fcw <= WB_IN.DAT;
           when 1 => ram_k_hi(write_addr) <= WB_IN.DAT;
           when 2 => ram_k_md(write_addr) <= WB_IN.DAT;
           when 3 => ram_k_lo(write_addr) <= WB_IN.DAT;
         end case;
       end if;
     end if;

     -- Advance the LFSR
     lfsr  <= lfsr(21 downto 1) & (lfsr(22) xnor lfsr(21));

     -- Handle the reset.
     if (rst = '1') then
       write_idx   <= (others => '0');
       read_idx    <= (others => '0');
       fir_idx     <= (others => '1');
       fcw       <= (others => '0');
       use_fir_data  <= true;
       state     <= RESET;
     end if;

   end process;

end architecture Behavioral;

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



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