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 75725

Article: 75725
Subject: Re: Spartan3 Block RAM from WebPACK
From: Elder Costa <elder.costa@terra.com.br>
Date: Sat, 13 Nov 2004 08:55:51 -0200
Links: << >>  << T >>  << A >>
Hal Murray wrote:
> Is it possible to use the Block RAMs in the Spartan3
> with the (free) WebPACK software?  If so, how?
> 
> I'm playing with the Spartan3 starter kit and trying to make
> a ROM.  I'd expect to find something in the library package.
> I can't find anything there other than tiny ones using CLBs.
> 
> Looks like the normal path is to use Coregen, but that's not
> part of WebPACK.  I could use a machine with Coregen installed
> on it to do the "gen" part, but that makes something that's
> tangled up with the Coregen libraries.  (Maybe that tangle is
> only the simulation libraries. But everybody would snicker if
> I didn't simulate.)
> 
> Am I just overlooking something simple?  (If so, what's the
> magic word.)
> 

Doesn't Webpack include a language template help? (It is marked with a 
lit lamp on the tool bar). If it does you may find some templates. 
However I would suggest you to look for application note XAPP463 at 
Xillinx' page. There are zip files with vhdl/verilog code you may simply 
copy and paste and adapt to your needs.

HTH

Article: 75726
Subject: Re: Spartan3 Block RAM from WebPACK
From: Marc Randolph <mrand@my-deja.com>
Date: Sat, 13 Nov 2004 05:46:26 -0600
Links: << >>  << T >>  << A >>
Elder Costa wrote:
> Hal Murray wrote:
> 
>> Is it possible to use the Block RAMs in the Spartan3
>> with the (free) WebPACK software?  If so, how?
>>
>> I'm playing with the Spartan3 starter kit and trying to make
>> a ROM.  I'd expect to find something in the library package.
>> I can't find anything there other than tiny ones using CLBs.
>>
>> Looks like the normal path is to use Coregen, but that's not
>> part of WebPACK.  I could use a machine with Coregen installed
>> on it to do the "gen" part, but that makes something that's
>> tangled up with the Coregen libraries.  (Maybe that tangle is
>> only the simulation libraries. But everybody would snicker if
>> I didn't simulate.)
>>
>> Am I just overlooking something simple?  (If so, what's the
>> magic word.)
>>
> 
> Doesn't Webpack include a language template help? (It is marked with a 
> lit lamp on the tool bar). If it does you may find some templates. 
> However I would suggest you to look for application note XAPP463 at 
> Xillinx' page. There are zip files with vhdl/verilog code you may simply 
> copy and paste and adapt to your needs.

The online documentation at

http://toolbox.xilinx.com/docsan/xilinx6/books/manuals.htm

has it as well.  I drilled down through XST User guide -> HDL Coding 
techniques -> RAMs/ROMs.  This lead me here:

http://toolbox.xilinx.com/docsan/xilinx6/books/data/docs/xst/xst0026_5.html#wp325264

which shows how to infer the ROM.  I'm sure you could also instantiate 
it, but to me, that actually seems harder than inferring.

    Marc

Article: 75727
Subject: PWM using FPGA
From: static123ph@yahoo.com (iceman)
Date: 13 Nov 2004 06:25:59 -0800
Links: << >>  << T >>  << A >>
does anyone have a code for this? i will be using pwm for controlling a servo motor

Article: 75728
Subject: Re: asynchronous bus transfers
From: "Jason Berringer" <jberringer.at@sympatico.dot.ca>
Date: Sat, 13 Nov 2004 09:50:20 -0500
Links: << >>  << T >>  << A >>
Rick,

That sounds like the approach that I was considering, as the reads seem to
be okay, it's the writes that become unstable, however if I am delaying the
write strobe, then I must also delay the data lines, and the address lines,
otherwise the micro has moved on to the next cycle without the data being
written correctly. It would seem to me that I must pipeline the write
transfer to eliminate the instability.

Thanks for the help.

Jason

"rickman" <spamgoeshere4@yahoo.com> wrote in message
news:41945E21.F7E5544F@yahoo.com...
> Jason Berringer wrote:
> >
> > Hello all,
> >
> > I have a microcontroller running at 40 MHz that performs asynchronous
bus
> > transfers, and I have an FPGA running at 100 MHz. With talk of
metastability
> > and all I would conclude that sending some of the control signals
through
> > flip flops (say 2 levels) would eliminate any metastability. The
question
> > then becomes how do I keep the bus transfers short enough without
incurring
> > significant delays between registering a read command (for example) and
then
> > responding to it and placing the data on the bus to be read. This would
have
> > 2 clock cycles to eliminate the metastability on the read signal (and
> > address lines if I want to worry about metastability with those lines)
and
> > then at least one more for the data to be placed on the bus, a total of
> > three clock cycles. That is too much time to get the data on bus (if I'm
> > trying to keep the bus cycles short). I would appreciate some advice on
how
> > others have handled transferring data between an asynchronous device and
an
> > FPGA.
> >
> > Would it not be acceptable to make an asynchronous interface block for
the
> > FPGA, and then pull it into the synchronous world inside the chip? This
> > seems to go against the metastability thoughts that I've come across.
>
> I designed something similar and found it was not a big problem.  You
> don't have to worry about metastability on the read as long as you are
> not doing anything else with the strobe internally.  Even though the
> read enable or address may be changing on a clock edge, that first cycle
> will be ignored by the CPU and 10 ns later the second clock cycle will
> read valid data from the RAM in the FPGA.
>
> On the write you should use a register to hold the data when the write
> strobe is asserted.  The stabilized (and delayed) write strobe can write
> the data into your RAM.  If your data is not stable on the leading edge
> of the write strobe, you can use one of the delayed strobes to as your
> data register enable.  That will help you meet both setup and hold.
>
> -- 
>
> Rick "rickman" Collins
>
> rick.collins@XYarius.com
> Ignore the reply address. To email me use the above address with the XY
> removed.
>
> Arius - A Signal Processing Solutions Company
> Specializing in DSP and FPGA design      URL http://www.arius.com
> 4 King Ave                               301-682-7772 Voice
> Frederick, MD 21701-3110                 301-682-7666 FAX



Article: 75729
Subject: Re: asynchronous bus transfers
From: "Jason Berringer" <jberringer.at@sympatico.dot.ca>
Date: Sat, 13 Nov 2004 09:55:02 -0500
Links: << >>  << T >>  << A >>
Ultimately in the design I start with one 10 MHz TCXO and use PLL chips to
generate a 40 MHz clock (micro) and another 100 MHz clock (FPGA). Since
there are no handshaking lines between the chips for data transfers I cannot
use. I have not checked the relationship between the two clocks, as I wanted
just assume they were completely asynchronous for the design, thus allowing
this design to work in any situation.

32 bit micro is what I'm using.

Thanks for the help.

Jason

"AnonymousFC3" <no_email@please.net> wrote in message
news:ur2dnUd9XqlOlQncRVn-vQ@comcast.com...
> Jason:
>   It would be nice to have more specifics on your problem.
>
> Inherently ther is no difference between an FPGA (which one) and anything
> else.
>
> Which kid of metastability?
> Which kid of microcontroller?
> Do you use the same clock, and derive one from another ? (I guess no).
>   Here having somewhat synchronous clocks simplify the problem, but async
> transfers are ok... as long as you do not violate any timing requirement
> (mostly cpu/memory).
>   I would suggest to derive one clock from another if you could.
> The somewhat brute force way to resolve this issue would be to use of
FIFO's
> between busses but you probably can do better.
> There is no way you can avoid a proper assessment of timing closure!
> --
> All the luck.
>
> Jason Berringer wrote:
>
> > Hello all,
> >
> > I have a microcontroller running at 40 MHz that performs asynchronous
bus
> > transfers, and I have an FPGA running at 100 MHz. With talk of
> > metastability and all I would conclude that sending some of the control
> > signals through flip flops (say 2 levels) would eliminate any
> > metastability. The question then becomes how do I keep the bus transfers
> > short enough without incurring significant delays between registering a
> > read command (for example) and then responding to it and placing the
data
> > on the bus to be read. This would have 2 clock cycles to eliminate the
> > metastability on the read signal (and address lines if I want to worry
> > about metastability with those lines) and then at least one more for the
> > data to be placed on the bus, a total of three clock cycles. That is too
> > much time to get the data on bus (if I'm trying to keep the bus cycles
> > short). I would appreciate some advice on how others have handled
> > transferring data between an asynchronous device and an FPGA.
> >
> > Would it not be acceptable to make an asynchronous interface block for
the
> > FPGA, and then pull it into the synchronous world inside the chip? This
> > seems to go against the metastability thoughts that I've come across.
> >
> > Any and all comments would be appreciated..
> >
> > Thanks,
> >
> > Jason
>



Article: 75730
Subject: Re: asynchronous bus transfers
From: "Jason Berringer" <jberringer.at@sympatico.dot.ca>
Date: Sat, 13 Nov 2004 09:57:55 -0500
Links: << >>  << T >>  << A >>
Jim,

Yes it does (XC2S200), but I have no access to the 40 MHz clock from the
micro, otherwise I would have implemented a synchronous transfer or used the
dual port RAM. I figured that without access to the 40 MHz clock the dual
port RAM would be out of the question since I would need a clock one the
second port which I do not have.

Thanks

Jason

"Jim Granville" <no.spam@designtools.co.nz> wrote in message
news:rXTkd.952$3U4.83723@news02.tsnz.net...
> Jason Berringer wrote:
> > Hello all,
> >
> > I have a microcontroller running at 40 MHz that performs asynchronous
bus
> > transfers, and I have an FPGA running at 100 MHz. With talk of
metastability
> > and all I would conclude that sending some of the control signals
through
> > flip flops (say 2 levels) would eliminate any metastability. The
question
> > then becomes how do I keep the bus transfers short enough without
incurring
> > significant delays between registering a read command (for example) and
then
> > responding to it and placing the data on the bus to be read. This would
have
> > 2 clock cycles to eliminate the metastability on the read signal (and
> > address lines if I want to worry about metastability with those lines)
and
> > then at least one more for the data to be placed on the bus, a total of
> > three clock cycles. That is too much time to get the data on bus (if I'm
> > trying to keep the bus cycles short). I would appreciate some advice on
how
> > others have handled transferring data between an asynchronous device and
an
> > FPGA.
> >
> > Would it not be acceptable to make an asynchronous interface block for
the
> > FPGA, and then pull it into the synchronous world inside the chip? This
> > seems to go against the metastability thoughts that I've come across.
> >
> > Any and all comments would be appreciated..
>
> Does the FPGA not have DualPort RAM blocks ?
> -jg
>



Article: 75731
Subject: Re: PWM using FPGA
From: "Vanheesbeke Stefaan" <svhb@pandora.be>
Date: Sat, 13 Nov 2004 15:05:50 GMT
Links: << >>  << T >>  << A >>
counter, comparator, ...

When this is done, go the the newsgroup about servo's and ask how to do the
control loop.


"iceman" <static123ph@yahoo.com> wrote in message
news:62011d8f.0411130625.ef256ae@posting.google.com...
> does anyone have a code for this? i will be using pwm for controlling a
servo motor



Article: 75732
Subject: Re: PWM using FPGA
From: "Antti Lukats" <antti@case2000.com>
Date: Sat, 13 Nov 2004 17:30:15 +0100
Links: << >>  << T >>  << A >>
"iceman" <static123ph@yahoo.com> wrote in message
news:62011d8f.0411130625.ef256ae@posting.google.com...
> does anyone have a code for this? i will be using pwm for controlling a
servo motor

http://www.fpga4fun.com/RCServos.html

Antti



Article: 75733
Subject: FPGA's at Electronica 2004
From: "Antti Lukats" <antti@case2000.com>
Date: Sat, 13 Nov 2004 18:37:31 +0100
Links: << >>  << T >>  << A >>
Hi

just some short info what was at Electronica 2004 (they way I did feel and
see things there)

Xilinx -
I did see the ML401 board running an OS from the CF card using standard PC
peripherals (keyboard monitor) - well it's my opinion of course but anyone
considering buying some other V4LX25 based starterkit/eval board should
think twice and see if he can get ML401 instead, its real nice board packet
with all you wanna have peripherals (all that make sense for V4-LX)

As per Xilinx ML401 boards "ARE SHIPPING" - as of other information Avent
and Memec are not yet shipping their V4 starterkits, at least I have not
information about anyone receiving Avnet/Memec V4 board, I know there are
pending order for both, and both Memec/Avent are promising to start
deliveries (really) soon.

ML461 was also there, its real HUGE board! Well I guess anyone testing the
memories and memory controllers have already placed their orders.

There is expected a low cost S3-1500 board (Digilent) with "feature packed
peripherals" - no further info but my guess price tag $199-$299

Altera -
"Wasnt there" as of general feeling at Xilinx booth - this was almost true,
a small Altera booth was at the fair, but very hidden at the Automotive
hall. Altera seems to cover it all by "one size fits them all" approuch -
they only had "Large" T-shirts (no options), and a special calculator to
help engineers to get Altera equivalent to all other FPGA's, a few examples:

XC2VP100 -> EP1S80
XC2V80 ->EPM1270G (* secondary choice)
APA75 -> EP1C3
AX2000 -> EP1C20
[...] -> [...]

Great tool! Now we can buy Altera parts for all our needs!

Ah, sorry some useful info too: First MAX2 chips in TQFP package are
expected JAN 2005

Actel -
Great expresso at the booth! And.. my mouth is shut :(
(I did see there someone and something unexpected)

Synplify -
ver 8 due Jan 2005,
Actel Proasic is not and will not be supported by Amplify

Mentor -
Got Modelsim Designer 6.0 mini CD (not sure whats on it)

Altium -
All busy explaining visitors how to route a wire, the new V2Pro nanoboard
module was not at the show (but they have it!)

Lattice -
Sorry I forgot about you guys, my fault, see you next time around! (I still
have EC board on my wishlist of wanna have eval boards)

Atmel -
was there, hard to find, when found nothing to see nobody to talk, no
espresso either.


Antti
PS All above are my personal and possible biased comments only, please read
them light with :) on the face

http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&rd=1&item=3852842807





Article: 75734
Subject: Re: Obsolete processors resurected in FPGAs
From: "Monte Dalrymple" <monted@systemyde.com>
Date: Sat, 13 Nov 2004 18:48:57 GMT
Links: << >>  << T >>  << A >>

"Ryan" <ryanclark410@hotmail.com> wrote in message
news:sp6ld.116$ri7.3@newsfe5-win.ntli.net...
> As part of an academic project I'm going to be looking at the pros and
cons
> of re-producing microprocessors in current FPGA technologies that are no
> longer available on the open market. This is to address the problem that
> occurs in some specialised areas where the lifetime of a product is very
> long and the cost of rewriting the software is prohibitively high (e.g. it
> was written in a language and/or tools that aren't supported anymore). The
> idea is to be able to use an FPGA implementation an either a drop-in
> replacement component onto a legacy board or to produce a new board but of
> identical functionality. Either way, no changes to the application object
> code stored in ROM is required.
>
> There are many different factors that I'll have to look into before I can
> make any conclusions and I'm concerned that some important ones could be
> missed. Obviously there are:
> 1) Availability of the original processor HDL or equivalent.

Even if the design was originally done in an HDL, getting the original owner
to
release it will be next to impossible. However, recreating an older design
in an
HDL form doesn't take an unreasonable amount of time if the specifications
are fairly complete (and accurate, see below).


> 2) How can the exact EBI timings of the original be recreated (or how
close
> to the original is practical)?

If you are talking nanoseconds, it's going to be time-consuming and probably
not worth the effort as long as the timings are cycle-accurate.


> 3) Cache memory cannot be recreated on-chip.

And unless you have the time and inclination to figure out the internal
timing for
this kind of subsystem (a non-trivial task) you wil never be able to achieve
cycle accuracy. A similar problem arises whenever you have more than one
clock domain in the device, as the original synchronization strategy will be
very
difficult to discern.


> 4) How close can the internal timings be recreated?

It's actually an interesting exercise to try to figure out how the original
design was
implemented to come up with the original timings. I have done this twice,
for the
Z180 and the Z8000. I was able to match the Z180 clock cycle timing in all
cases. The Z8000 was a different story, for two reasons. First, the exact
timing
for the case of the interrupt acknowledge was not specified except "1 to 7
clock
cycles" for an aborted instruction fetch. Second, the published timing for
both
the multiply and divide instruction was clearly incorrect, as it did not
account
for the different addressing modes correctly, besides not making sense (from
a
clock cycle standpoint) relative to whether a bit in the divisor was set or
not.



> 5) Verification ?!

If you write your testbench properly, and cover all the boundary cases, it's
possible to exercise the original chip with the same stimulus and compare
the
results. This was very useful in my Z8000 case, where a number of
instructions
are described as having "undefined" flag values. I was able to figure out
what
the chip was doing in these "undefined cases" and match the behavior in my
implementation. It's usually a case of figuring out where the original
designer
used "don't cares" in his logic design.

This step is critical if you are working from a published spec. For example,
the Z8000 divide instruction is completely specified, including boundary
cases. This was obviously the work of the Z8000 architect, and is what I
implemented. My testbench tested each of the specified boundary cases,
only to find that the actual chip did not properly handle one boundary case!
This was actually the hardest case to implement, and it seems that the
designer decided to signal overflow rather than properly handle the case of
the most-negative quotient (recall that the range of a 2's complement number
is assymetric). Well, this change never made it into the published
documentation
for the chip.

This "specification/implementation disconnect" is one of the more difficult
aspects of this process. Without detailed and accurate specifications, the
task can be impossible. I would add this to your list of important factors
to
consider.


>
> If anyone would like to contribute to this initial brainstorming, I'd be
> grateful.

There are a number of cases where this avenue is the most logical or even
the least expensive. (Think about the cost requalifying flight-critical
software,
for example.) Emulating an older design on a fast new whiz-bang chip does
nothing except postpone the problem, because what happens when that
chip is obsolete in 18 months (or worse, in the middle of your redesign).
Having the design in a retargetable HDL format makes the obsolesense
problem manageable. Emulation is also grossly inefficient in terms of power,
and can't hope to be hardware compatible except at the edges of the system,
if then.


>
> Rupert.
>
>



Article: 75735
Subject: Virtex-II Pro Dev Board for RTOS Integrity
From: scottie7980@yahoo.de (scottie)
Date: 13 Nov 2004 11:05:17 -0800
Links: << >>  << T >>  << A >>
I've just forgot to mention that I will use a PowerPC core.

Article: 75736
Subject: Re: Obsolete processors resurected in FPGAs
From: hmurray@suespammers.org (Hal Murray)
Date: Sat, 13 Nov 2004 13:22:33 -0600
Links: << >>  << T >>  << A >>
>And unless you have the time and inclination to figure out the internal
>timing for
>this kind of subsystem (a non-trivial task) you wil never be able to achieve
>cycle accuracy. A similar problem arises whenever you have more than one
>clock domain in the device, as the original synchronization strategy will be
>very
>difficult to discern.

Why not?  Old cycle times were slow by modern standards.  Just add
enough delay to match the specs.

-- 
The suespammers.org mail server is located in California.  So are all my
other mailboxes.  Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's.  I hate spam.


Article: 75737
Subject: Re: Spartan3 Block RAM from WebPACK
From: cs_posting@hotmail.com (Chris Stratton)
Date: 13 Nov 2004 11:54:32 -0800
Links: << >>  << T >>  << A >>
hmurray@suespammers.org (Hal Murray) wrote in message news:<RuednZqh6-LY5QjcRVn-hQ@megapath.net>...
> Is it possible to use the Block RAMs in the Spartan3
> with the (free) WebPACK software?  If so, how?
> 

Sure - you might be able to infer it, but you can also just
instantiate it
with the appropriate verilog of vhdl library component.  The block
ram's function as a fixed number of bits, which you can access with
varying widths and lengths, and are optionally dual port.  Do a
directory of everything starting with RAMB in your
xilinx/src/verilog/unisims directory to get an idea of the options. 
For example RAMB16_S9 is an 8bit+parity memory, and RAMB16_S9_S9 is
the same thing in dual port configuration.

One thing to remember is that this is SYNCHRONOUS memory - there's a
clock delay in getting anything out of it.

Initializing them as rom's is a bit of a pain, as you need to do it
seperately for the simulation and for synthesis.  For example, in
verilog you would have:

//synthesis translate_off
defparam my_mem.INIT_00 =
256'h7B98606064C364C364C364C364C364C300006FC360646080F060607C64C30077;
//synthesis translate_on

To get the simulation values in there.  For synthesis, you specify the
value like this:

//synthesis attribute init_00 of my_mem is
"7B98606064C364C364C364C364C364C300006FC360646080F060607C64C30077"

(synthesis directives are all formally verilog comments, hence the //)

If you have processor code in the ROM, you can also use a .bmm file
and the data2mem tool to let you change the code without recompiling
the whole design.

For example:

my_mem.bmm:
ADDRESS_BLOCK rom RAMB16 [0x00000000:0x00007FF]
BUS_BLOCK
my__mem3 [7:0] OUTPUT = my_dump.mem;
END_BUS_BLOCK;
END_ADDRESS_BLOCK;

If you put my_mem.bmm in your project, XST will further process it and
give you a my_mem_bd.bmm which you can then use along with a .mem file
of data:

data2bram -bm my_mem_bd.bmm -bt project.bit -bd my_mem.mem -o bv
updated

This will create an 'updated.bit' as well as an 'updated.v' with
defparam's that you can `include (from within a //synthesis
translate_off block!) in your design to subsequently have the same
values in simulation.

It's a pain to set up, but once it works it's really nice.

Chris

Article: 75738
Subject: Digital LP filter in multiplier free FPGA
From: "markp" <map.nospam@f2s.com>
Date: Sat, 13 Nov 2004 19:55:43 -0000
Links: << >>  << T >>  << A >>
Hi All,

I need to implement a low pass digital filter on 12 bit ADC data in a Spatan
IIE device, but I'd like it to be multiplier free - in other words just use
adders and bit shifting for the coefficients. The sample rate is 12Mhz and I
need a sharp cut-off at around 3MHz. Does anyone know of a simple design
(IIR?) to do this, or a website/tutorial to give me some pointers? I've seen
several websites with coefficient calculators, there are always a few
coefficients that can't be easily calculated with bit shifting and adding.

Thanks!

Mark.



Article: 75739
Subject: Re: Digital LP filter in multiplier free FPGA
From: "Antti Lukats" <antti@case2000.com>
Date: Sat, 13 Nov 2004 21:59:29 +0100
Links: << >>  << T >>  << A >>
"markp" <map.nospam@f2s.com> wrote in message
news:2vn75sF2o7m4kU1@uni-berlin.de...
> Hi All,
>
> I need to implement a low pass digital filter on 12 bit ADC data in a
Spatan
> IIE device, but I'd like it to be multiplier free - in other words just
use
> adders and bit shifting for the coefficients. The sample rate is 12Mhz and
I
> need a sharp cut-off at around 3MHz. Does anyone know of a simple design
> (IIR?) to do this, or a website/tutorial to give me some pointers? I've
seen
> several websites with coefficient calculators, there are always a few
> coefficients that can't be easily calculated with bit shifting and adding.
>
> Thanks!

depending what you need, one solution is very simple "digital integrator"
its doable with only shift and add, there is some appnote or something at
xilinx web, I used that in digital carrier frequency amplifier, and it did
give actually very good filtering (for my application at least).

an example digital integrator source is appended
---------
--
-- 18 Bit Digital Integrator Feedback "multiplier"
-- constant 1 / 256 (fixed, no choices implemented)
-- Tested and working.
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;

library work;

entity integrator_18bit is Port (
           rst : in std_logic;
           clk : in std_logic;
           din : in std_logic_vector(17 downto 0); -- Input: 18 Bit Unsigned
INTEGER
           k : in std_logic_vector(3 downto 0); -- multiplier select (not
implemented)
           dout : out std_logic_vector(17 downto 0) -- Output: 18 Bit
Unsigned INTEGER
           );
end integrator_18bit;

architecture Behavioral of integrator_18bit is

signal acc : std_logic_vector(25 downto 0);
signal vi_minus_vo : std_logic_vector(25 downto 0);
signal vi_minus_vo_sign_extended : std_logic_vector(7 downto 0);

begin
  -- Microblaze "endian" conversion
  dout(0) <= acc(25);  dout(1) <= acc(24);  dout(2) <= acc(23);  dout(3) <=
acc(22);
  dout(4) <= acc(21);  dout(5) <= acc(20);  dout(6) <= acc(19);  dout(7) <=
acc(18);
  dout(8) <= acc(17);  dout(9) <= acc(16);  dout(10) <= acc(15);  dout(11)
<= acc(14);
  dout(12) <= acc(13);  dout(13) <= acc(12);  dout(14) <= acc(11);  dout(15)
<= acc(10);
  dout(16) <= acc(9);  dout(17) <= acc(8);

  -- Error Value
  vi_minus_vo <= (din & "00000000") - acc;
  -- Sign Extension for Error Value
  with vi_minus_vo(25) select vi_minus_vo_sign_extended(7 downto 0) <=
"00000000" when '0', "11111111" when others;

  process (clk) begin
    if (rst='1') then
      acc <= "00000000000000000000000000";
    else
      if (clk'event and clk='1') then
        -- Accumulate
        acc <= acc + (vi_minus_vo_sign_extended(7 downto 0) & vi_minus_vo(25
downto 8));
      end if;
    end if;
  end process;

end Behavioral;



Article: 75740
Subject: Re: Digital LP filter in multiplier free FPGA
From: John Larkin <jjlarkin@highlandSNIPtechTHISnologyPLEASE.com>
Date: Sat, 13 Nov 2004 13:10:15 -0800
Links: << >>  << T >>  << A >>
On Sat, 13 Nov 2004 19:55:43 -0000, "markp" <map.nospam@f2s.com>
wrote:

>Hi All,
>
>I need to implement a low pass digital filter on 12 bit ADC data in a Spatan
>IIE device, but I'd like it to be multiplier free - in other words just use
>adders and bit shifting for the coefficients. The sample rate is 12Mhz and I
>need a sharp cut-off at around 3MHz. Does anyone know of a simple design
>(IIR?) to do this, or a website/tutorial to give me some pointers? I've seen
>several websites with coefficient calculators, there are always a few
>coefficients that can't be easily calculated with bit shifting and adding.
>
>Thanks!
>
>Mark.
>

See zipfile in abse. If I post it here, the formatting gets lunched.

John


Article: 75741
Subject: Re: Digital LP filter in multiplier free FPGA
From: "markp" <map.nospam@f2s.com>
Date: Sat, 13 Nov 2004 21:19:25 -0000
Links: << >>  << T >>  << A >>

"John Larkin" <jjlarkin@highlandSNIPtechTHISnologyPLEASE.com> wrote in
message news:g0ucp0l3v5pmv3a8afvlil3g7b1k7u2jc1@4ax.com...
> On Sat, 13 Nov 2004 19:55:43 -0000, "markp" <map.nospam@f2s.com>
> wrote:
>
> >Hi All,
> >
> >I need to implement a low pass digital filter on 12 bit ADC data in a
Spatan
> >IIE device, but I'd like it to be multiplier free - in other words just
use
> >adders and bit shifting for the coefficients. The sample rate is 12Mhz
and I
> >need a sharp cut-off at around 3MHz. Does anyone know of a simple design
> >(IIR?) to do this, or a website/tutorial to give me some pointers? I've
seen
> >several websites with coefficient calculators, there are always a few
> >coefficients that can't be easily calculated with bit shifting and
adding.
> >
> >Thanks!
> >
> >Mark.
> >
>
> See zipfile in abse. If I post it here, the formatting gets lunched.

Thanks John. Unfortunately I've got text only news server access, any chance
in emailing? (remove .nospam).

Cheers,

Mark.
> John
>



Article: 75742
Subject: Re: Digital LP filter in multiplier free FPGA
From: John Larkin <jjlarkin@highlandSNIPtechTHISnologyPLEASE.com>
Date: Sat, 13 Nov 2004 13:40:49 -0800
Links: << >>  << T >>  << A >>
On Sat, 13 Nov 2004 21:19:25 -0000, "markp" <map.nospam@f2s.com>
wrote:

>
>"John Larkin" <jjlarkin@highlandSNIPtechTHISnologyPLEASE.com> wrote in
>message news:g0ucp0l3v5pmv3a8afvlil3g7b1k7u2jc1@4ax.com...
>> On Sat, 13 Nov 2004 19:55:43 -0000, "markp" <map.nospam@f2s.com>
>> wrote:
>>
>> >Hi All,
>> >
>> >I need to implement a low pass digital filter on 12 bit ADC data in a
>Spatan
>> >IIE device, but I'd like it to be multiplier free - in other words just
>use
>> >adders and bit shifting for the coefficients. The sample rate is 12Mhz
>and I
>> >need a sharp cut-off at around 3MHz. Does anyone know of a simple design
>> >(IIR?) to do this, or a website/tutorial to give me some pointers? I've
>seen
>> >several websites with coefficient calculators, there are always a few
>> >coefficients that can't be easily calculated with bit shifting and
>adding.
>> >
>> >Thanks!
>> >
>> >Mark.
>> >
>>
>> See zipfile in abse. If I post it here, the formatting gets lunched.
>
>Thanks John. Unfortunately I've got text only news server access, any chance
>in emailing? (remove .nospam).
>
>Cheers,
>
>Mark.
>> John
>>
>


OK, done, I think.

John


Article: 75743
Subject: Re: Digital LP filter in multiplier free FPGA
From: John Larkin <jjlarkin@highlandSNIPtechTHISnologyPLEASE.com>
Date: Sat, 13 Nov 2004 13:53:44 -0800
Links: << >>  << T >>  << A >>
On Sat, 13 Nov 2004 13:10:15 -0800, John Larkin
<jjlarkin@highlandSNIPtechTHISnologyPLEASE.com> wrote:

>On Sat, 13 Nov 2004 19:55:43 -0000, "markp" <map.nospam@f2s.com>
>wrote:
>
>>Hi All,
>>
>>I need to implement a low pass digital filter on 12 bit ADC data in a Spatan
>>IIE device, but I'd like it to be multiplier free - in other words just use
>>adders and bit shifting for the coefficients. The sample rate is 12Mhz and I
>>need a sharp cut-off at around 3MHz. Does anyone know of a simple design
>>(IIR?) to do this, or a website/tutorial to give me some pointers? I've seen
>>several websites with coefficient calculators, there are always a few
>>coefficients that can't be easily calculated with bit shifting and adding.
>>
>>Thanks!
>>
>>Mark.
>>
>
>See zipfile in abse. If I post it here, the formatting gets lunched.
>
>John


Oops, K1 should be 4, 1/16. File got scrambled somehow.

John


Article: 75744
Subject: Re: Obsolete processors resurected in FPGAs
From: "vax, 9000" <vax9000@gmail.com>
Date: Sat, 13 Nov 2004 17:30:13 -0500
Links: << >>  << T >>  << A >>
Monte Dalrymple wrote:

> It's actually an interesting exercise to try to figure out how the
> original design was
> implemented to come up with the original timings. I have done this twice,
> for the
> Z180 and the Z8000. I was able to match the Z180 clock cycle timing in all
> cases. The Z8000 was a different story, for two reasons. First, the exact
> timing...
 
  Since you are an expert of Z8000, I'd like to ask you a question about
Z8000, out of curiosity. I heard that Z8000 had bugs. Do you know what
these bugs were, and whether they are corrected? Thank you.

vax, 9000

Article: 75745
Subject: Re: Obsolete processors resurected in FPGAs
From: Jim Granville <no.spam@designtools.co.nz>
Date: Sun, 14 Nov 2004 13:16:51 +1300
Links: << >>  << T >>  << A >>
Monte Dalrymple wrote:

<snip>
>>4) How close can the internal timings be recreated?
> 
> 
> It's actually an interesting exercise to try to figure out how the original
> design was implemented to come up with the original timings. I have done this twice,
> for the  Z180 and the Z8000. I was able to match the Z180 clock cycle timing in all
> cases. The Z8000 was a different story, for two reasons. First, the exact
> timing for the case of the interrupt acknowledge was not specified except "1 to 7
> clock cycles" for an aborted instruction fetch. Second, the published timing for
> both the multiply and divide instruction was clearly incorrect, as it did not
> account for the different addressing modes correctly, besides not making sense (from
> a  clock cycle standpoint) relative to whether a bit in the divisor was set or
> not.
<snip>

Interesting, Sounds a lot of work on the Z8000, can you elaborate on the 
reasons/needs for this core, in particular.
Could also be a good example, for the OP.

-jg



Article: 75746
Subject: Re: Digital LP filter in multiplier free FPGA
From: "Ken" <aeu96186@NOSPAM.yahoo.co.uk>
Date: Sun, 14 Nov 2004 01:42:44 +0100
Links: << >>  << T >>  << A >>
> I need to implement a low pass digital filter on 12 bit ADC data in a 
> Spatan
> IIE device, but I'd like it to be multiplier free - in other words just 
> use
> adders and bit shifting for the coefficients. The sample rate is 12Mhz and 
> I
> need a sharp cut-off at around 3MHz. Does anyone know of a simple design
> (IIR?) to do this, or a website/tutorial to give me some pointers? I've 
> seen
> several websites with coefficient calculators, there are always a few
> coefficients that can't be easily calculated with bit shifting and adding.

Hi Mark,

I can help you out with this by automatically generating VHDL for an FIR 
implementation for your filter that uses shifts and adds.

Please post the following details:


Do you want the filter to run at 12MHz (i.e. full-parallel) or do you have a 
faster clock available that could be used to share hardware over multiple 
clock cycles?

Is the filter single-rate or are you decimating?

Input bit-width?

Signed/unsigned input?

Quantised filter coefficients (integers ideally but fixed-point will do) or 
more detailed spectral requirements (what -dB gain at 3MHz, pass-band ripple 
etc., start rolling off at what freq, stop rolling of at what freq. etc.)


Cheers,

Ken



Article: 75747
Subject: Re: Obsolete processors resurected in FPGAs
From: "Monte Dalrymple" <monted@systemyde.com>
Date: Sun, 14 Nov 2004 00:48:37 GMT
Links: << >>  << T >>  << A >>

"Jim Granville" <no.spam@designtools.co.nz> wrote in message
news:ytxld.1198$3U4.104987@news02.tsnz.net...
> Monte Dalrymple wrote:
>
> <snip>
> >>4) How close can the internal timings be recreated?
> >
> >
> > It's actually an interesting exercise to try to figure out how the
original
> > design was implemented to come up with the original timings. I have done
this twice,
> > for the  Z180 and the Z8000. I was able to match the Z180 clock cycle
timing in all
> > cases. The Z8000 was a different story, for two reasons. First, the
exact
> > timing for the case of the interrupt acknowledge was not specified
except "1 to 7
> > clock cycles" for an aborted instruction fetch. Second, the published
timing for
> > both the multiply and divide instruction was clearly incorrect, as it
did not
> > account for the different addressing modes correctly, besides not making
sense (from
> > a  clock cycle standpoint) relative to whether a bit in the divisor was
set or
> > not.
> <snip>
>
> Interesting, Sounds a lot of work on the Z8000, can you elaborate on the
> reasons/needs for this core, in particular.
> Could also be a good example, for the OP.
>
> -jg
>
>

The original customer for this design makes air data computers, and projects
demand to continue well beyond when the "obsolete part stock" quantities of
the Z8000 will be around. Since the software for this system has to be FAA
certified, changing even one line of code is horrendously expensive. I'm
sure
that the OP was talking about exactly these kinds of applications. There are
a number of similar applications out there, because the Z8000 was the first
MIL-qualified 16-bit CPU and was designed into quite a few military and
mil-spec systems. These are the kinds of systems with very long lifetimes. I
know that the Z8000 was used in the F-15, the F-16, the 747 and the 757,
for example. All of these aircraft are still flying and are still in
production as
far as I know. These kinds of applications are the exact opposite of the
more
common "throw-it-away-in-18 months" that most people deal with today.

Monte



Article: 75748
Subject: Re: Obsolete processors resurected in FPGAs
From: "Monte Dalrymple" <monted@systemyde.com>
Date: Sun, 14 Nov 2004 01:01:22 GMT
Links: << >>  << T >>  << A >>

"vax, 9000" <vax9000@gmail.com> wrote in message
news:cn61r8$37l$1@charm.magnus.acs.ohio-state.edu...
> Monte Dalrymple wrote:
>
> > It's actually an interesting exercise to try to figure out how the
> > original design was
> > implemented to come up with the original timings. I have done this
twice,
> > for the
> > Z180 and the Z8000. I was able to match the Z180 clock cycle timing in
all
> > cases. The Z8000 was a different story, for two reasons. First, the
exact
> > timing...
>
>   Since you are an expert of Z8000, I'd like to ask you a question about
> Z8000, out of curiosity. I heard that Z8000 had bugs. Do you know what
> these bugs were, and whether they are corrected? Thank you.
>
> vax, 9000

You can download the spec for my clone design at

http://www.systemyde.com/pdf/y8002.pdf

All of the differences between the published spec and what we found with
the actual silicon are detailed there. I think that most of the bugs were
back-annotated into the spec. For example, register R0 can't be used
with some instructions, for no obvious reason. I think that some of the
"undefined" flag settings were actually bugs that were deemed not
important. The biggest one, in my opinion, had to do with divide not
handling the one boundary case, as I mentioned in the previous post.
And there is also the issue of cycle counts for both multiply and divide
that can't be correct in the published spec.

Monte




Article: 75749
Subject: Re: Obsolete processors resurected in FPGAs
From: "Kryten" <kryten_droid_obfusticator@ntlworld.com>
Date: Sun, 14 Nov 2004 01:04:03 GMT
Links: << >>  << T >>  << A >>

"Alex Gibson" <al xx at tpg dot com dot au - remove spaces replace dot> 
wrote in message 
news:4195db13$0$31718$61c65585@un-2park-reader-01.sydney.pipenetworks.com.au...
>
> quite a few 6502 cores available

Always read the small print though.

Several 6502 cores have been published but most of them come with notes 
about not being completely finished. For example, BCD instructions missing.

Daniel Wallner seems to be the only one who gets round to finishing stuff 
and testing it.

> http://www.howell1964.freeserve.co.uk/logic/index_logic.htm  lots of stuff

Recently announced plans to clone Atari 800XL, which will be a bigger task 
than the Atom. 





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