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 75750

Article: 75750
Subject: Re: Digital LP filter in multiplier free FPGA
From: soar2morrow@yahoo.com (Tom Seim)
Date: 13 Nov 2004 17:50:35 -0800
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!
> 
> Mark.

You didn't say how sharp your cutoff needs to be, or how much gain
ripple you can tolerate. You might consider a pipelined multiplier
design. This will result in very high clock rates, permitting one
multiplier to handle 8-16 coefficients. Several multipliers can be
used in parallel to increase the number of coefficients even further.
Xilinx has numerous ap notes on digital filtering techniques. Here is
a good review of the topic:
http://www.andraka.com/multipli.htm
This is probably the best book on the subject:
http://www.amazon.com/exec/obidos/ASIN/3540413413/andraka/103-1626470-7551837

Tom

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

> "Jim Granville" <no.spam@designtools.co.nz> wrote in message
>>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.

..and industrial systems are somewhere in-between.

Did you need to get certification for the Z8000 SoftCPU ? - it seems
this would need to be fully qualified as well, or have the MIL/FAA
not quite caught up with the idea of SoftCPU ?
-jg


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

"Jim Granville" <no.spam@designtools.co.nz> wrote in message
news:jdzld.1215$3U4.105563@news02.tsnz.net...
> Monte Dalrymple wrote:
>
> > "Jim Granville" <no.spam@designtools.co.nz> wrote in message
> >>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.
>
> ..and industrial systems are somewhere in-between.
>
> Did you need to get certification for the Z8000 SoftCPU ? - it seems
> this would need to be fully qualified as well, or have the MIL/FAA
> not quite caught up with the idea of SoftCPU ?
> -jg
>

I am not sure of the specifics, because the customer took this
responsibility.
I suspect that the hardware certification process is easier than the
software
certification process. I saw a copy of the procedure used for software
certification and I don't know how anyone could actually get any code
written in a finite amount of time following the procedure. But then, I'm a
hardware guy. I do know that the customer found my testbench to be
very useful. As I mentioned in an earlier post, it checked every
instruction,
flag, register combination, addressing mode and boundary condition. The
customer ran it with a real chip and my design and compared the results.
Then I modified my design to match the chip where there was a difference.
The only things I didn't match was the interrupt acknowledge timing and
the execution time for multiply and divide. My design used fewer clocks,
and the customer was satisfied with this result.

Monte



Article: 75753
Subject: Re: Obsolete processors resurected in FPGAs
From: Jim Granville <no.spam@designtools.co.nz>
Date: Sun, 14 Nov 2004 16:49:25 +1300
Links: << >>  << T >>  << A >>
Monte Dalrymple wrote:
> "Jim Granville" <no.spam@designtools.co.nz> wrote in message
<snip
>>Did you need to get certification for the Z8000 SoftCPU ? - it seems
>>this would need to be fully qualified as well, or have the MIL/FAA
>>not quite caught up with the idea of SoftCPU ?
>>-jg
>>
> 
> 
> I am not sure of the specifics, because the customer took this
> responsibility.
> I suspect that the hardware certification process is easier than the
> software
> certification process. I saw a copy of the procedure used for software
> certification and I don't know how anyone could actually get any code
> written in a finite amount of time following the procedure. But then, I'm a
> hardware guy. I do know that the customer found my testbench to be
> very useful.

Testbenchs are always under appreciated.

> As I mentioned in an earlier post, it checked every
> instruction,
> flag, register combination, addressing mode and boundary condition. The
> customer ran it with a real chip and my design and compared the results.
> Then I modified my design to match the chip where there was a difference.
> The only things I didn't match was the interrupt acknowledge timing and
> the execution time for multiply and divide. My design used fewer clocks,
> and the customer was satisfied with this result.

  An impressive case-study. Did they use an ASIC, or an FPGA (which?), 
and has that needed process revision yet ?
-jg


Article: 75754
Subject: Re: Obsolete processors resurected in FPGAs
From: "Monte Dalrymple" <monted@systemyde.com>
Date: Sun, 14 Nov 2004 04:36:10 GMT
Links: << >>  << T >>  << A >>
> > I am not sure of the specifics, because the customer took this
> > responsibility.
> > I suspect that the hardware certification process is easier than the
> > software
> > certification process. I saw a copy of the procedure used for software
> > certification and I don't know how anyone could actually get any code
> > written in a finite amount of time following the procedure. But then,
I'm a
> > hardware guy. I do know that the customer found my testbench to be
> > very useful.
>
> Testbenchs are always under appreciated.

Indeed.


>
> > As I mentioned in an earlier post, it checked every
> > instruction,
> > flag, register combination, addressing mode and boundary condition. The
> > customer ran it with a real chip and my design and compared the results.
> > Then I modified my design to match the chip where there was a
difference.
> > The only things I didn't match was the interrupt acknowledge timing and
> > the execution time for multiply and divide. My design used fewer clocks,
> > and the customer was satisfied with this result.
>
>   An impressive case-study. Did they use an ASIC, or an FPGA (which?),
> and has that needed process revision yet ?
> -jg
>

The target was an Actel FPGA. It hasn't gone through a process revision
yet that I am aware of.



Article: 75755
Subject: Re: Obsolete processors resurected in FPGAs
From: "vax, 9000" <vax9000@gmail.com>
Date: Sun, 14 Nov 2004 00:35:05 -0500
Links: << >>  << T >>  << A >>
Monte Dalrymple wrote:

>> > I am not sure of the specifics, because the customer took this
>> > responsibility.
>> > I suspect that the hardware certification process is easier than the
>> > software
>> > certification process. I saw a copy of the procedure used for software
>> > certification and I don't know how anyone could actually get any code
>> > written in a finite amount of time following the procedure. But then,
> I'm a
>> > hardware guy. I do know that the customer found my testbench to be
>> > very useful.
>>
>> Testbenchs are always under appreciated.
> 
> Indeed.

Agree. I only test my hobby project with a few settings and pray that
everything else works. 

Did you try Zilog 16C01/16C00 (CMOS version Z8000)? Did you find any
difference between Z8000 and 16C00?

vax, 9000

Article: 75756
Subject: video camera interface to FPGA
From: htj@es.lth.se (Hongtu)
Date: 14 Nov 2004 03:15:31 -0800
Links: << >>  << T >>  << A >>
Hi,
  I am trying to implement a system for video segmentation on xilinx
FPGAs. The application need raw RGB stream data from a video camera
and process it on FPGAs in real-time. Since using 24 pins(8 bits for
each color) is not a wise way to hook up cemera with an FPGA, I was
wondering what is usually done in such cases. About the camera, I will
get it from a company, and they promise they could provide any type of
camera I will need.


Hongtu

Article: 75757
Subject: Re: Obsolete processors resurected in FPGAs
From: buchty@atbode100.informatik.tu-muenchen.de (Rainer Buchty)
Date: Sun, 14 Nov 2004 12:37:01 +0000 (UTC)
Links: << >>  << T >>  << A >>
In article <7ayld.565$a83.316@newsfe3-win.ntli.net>,
 "Kryten" <kryten_droid_obfusticator@ntlworld.com> writes:
|> 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.

Next thing is, that mostly all 6502 cores I've seen so far emulate the 65C02. 
For quite a number of legacy stuff which exploited the NMOS 6502 illegal 
opcodes for timing reasons a 65C02 is plain unusable.

Rainer

Article: 75758
Subject: Re: Obsolete processors resurected in FPGAs
From: "Kryten" <kryten_droid_obfusticator@ntlworld.com>
Date: Sun, 14 Nov 2004 15:49:00 GMT
Links: << >>  << T >>  << A >>
"Rainer Buchty" <buchty@atbode100.informatik.tu-muenchen.de> wrote in 
message news:cn7jhc$19bkr$1@sunsystem5.informatik.tu-muenchen.de...

> Next thing is, that mostly all 6502 cores I've seen so far emulate the 
> 65C02.
> For quite a number of legacy stuff which exploited the NMOS 6502 illegal
> opcodes for timing reasons a 65C02 is plain unusable.

Daniel's T65 can be configured as either. :-)

It can't do the Atari "sally" variant yet, but I imagine that most games 
writers would want their code to run on the ordinary 6502 in old 800 
machines as well. So code using 'sally' illegals would be even rarer than 
those using the usual illegals.

I wonder what fraction of all code used illegal opcodes, and were they ever 
much use?



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

"vax, 9000" <vax9000@gmail.com> wrote in message
news:cn6qnq$58c$1@charm.magnus.acs.ohio-state.edu...
> Monte Dalrymple wrote:
>
> >> > I am not sure of the specifics, because the customer took this
> >> > responsibility.
> >> > I suspect that the hardware certification process is easier than the
> >> > software
> >> > certification process. I saw a copy of the procedure used for
software
> >> > certification and I don't know how anyone could actually get any code
> >> > written in a finite amount of time following the procedure. But then,
> > I'm a
> >> > hardware guy. I do know that the customer found my testbench to be
> >> > very useful.
> >>
> >> Testbenchs are always under appreciated.
> >
> > Indeed.
>
> Agree. I only test my hobby project with a few settings and pray that
> everything else works.
>
> Did you try Zilog 16C01/16C00 (CMOS version Z8000)? Did you find any
> difference between Z8000 and 16C00?
>
> vax, 9000

As far as I know, the comparison was only done with the Z8000.
However, I am pretty sure that the CMOS conversion at Zilog was
done directly from the schematics, so the devices would be identical.

As an aside, it's amusing to look at the Zilog website for a description
of the 16C0X. It starts off with "RISC-like load/store architecture"...
The Z8000 is classic CISC and is not anywhere near being load/store.
The only thing RISC-like about it is the fact that the instruction set is
quite regular.Classic marketing.



Article: 75760
Subject: Re: Overshoot/undershoot towards 2V4000
From: "Gunter Knittel" <knittel@gris.uni-tuebingen.de>
Date: Sun, 14 Nov 2004 17:53:52 +0100
Links: << >>  << T >>  << A >>
Austin,

thanks. Absolutely most useful information. Thanks also for making
such a clear statement. However, concerning SI, I can assure you
that you are preaching to the converted.
I was just asking because I have a number of low-rate control
signals which have more than enough time to settle. Of course
this doesn't reduce ringing, so I'm going to use series resistors at
any output driving towards the FPGA.

Thanks again
Gunter



"Austin Lesea" <austin@xilinx.com> wrote in message 
news:cn0e31$ruh1@cliff.xsj.xilinx.com...
> Gunther,
>
> To connect two fpgas together, one should use the proper standard.
>
> LVDCI works, as does LVCMOS 6 mA (no external resistors required) with no 
> simulations (as they are both 50 ohms and will match almost any pcb trace 
> well enough).
>
> Any other standards require some SI engineering.
>
> The Virtex II family uses 0.35u IO, and they are intrinsically protected 
> by the ESD structures.  You can not break them with overshoot and 
> undershoot.  But you can create functional problems, and even change BRAM 
> and config bit contents if you slap the substrate silly with currents!
>
> The Virtex II Pro, S3, and V4 families uses faster 0.25u transistors, and 
> the reliabily is affected if the IO pin is forced to a voltage below 
> ground (> 4.05V stress on the pmos output transistor = Vcco - undershoot < 
> 4.05V).  This is detailed in the data sheet under the abs max stresses.
>
> Not paying attention to signal integrity is just playing 'Russian 
> Roulette' with more than one chamber loaded -- very risky business.
>
> Austin
>
>
> Gunter Knittel wrote:
>> Austin,
>>
>> thanks very much for your answer. It's in a sense good to know that
>> the simulation seems to be accurate - despite the fact that we then
>> have to worry more about signals and spend more real estate for
>> terminations.
>> What makes me wonder, though, is that the simulations also said that
>> one cannot even connect two FPGAs directly without violating
>> undershoot limits - this doesn't reflect reality.
>> What I really would like to know is whether or not I can damage
>> the 2V4000 chip with strong over/undershoot. You said that the
>> clamp diodes will withstand that stress, but what about the
>> MOS transistors? The voltage across the gate oxide might become
>> too large if excessive current causes a large voltage drop across the
>> clamp diodes. I couldn't find anything on this topic in the VII-docs.
>> Can you shed some light on this?
>>
>> Thanks very much
>> Gunter
>>
>>
>> "Austin Lesea" <austin@xilinx.com> wrote in message 
>> news:cmtdif$ru81@cliff.xsj.xilinx.com...
>>
>>>Gunter,
>>>
>>>The protection diodes are clamping the overshoot and undershoot.  They 
>>>will not be damaged, but your signal integrity is terrible, you will have 
>>>excessive jitter, and that may lead to bit errors, and other behavior 
>>>that you will not like at all.
>>>
>>>I doubt the simulation is pessimistic, as I get the same results, and 
>>>often worse when too strong a driver is used unterminated.
>>>
>>>I suggest a small series resistor at the driver to better match the 
>>>lines. Perhaps somewhere from 22 ohms to 43 ohms.  Simulate until you 
>>>have the best choice for the slow/weak and fast/strong IBIS model 
>>>corners.
>>>
>>>Oh, and thank you for using IBIS before you built the board.  We are 
>>>happy (and you are happy) when you fix problems before the board layout.
>>>
>>>Austin
>>>
>>>Gunter Knittel wrote:
>>>
>>>
>>>>Hi,
>>>>
>>>>I'm planning to use ALVCH-Transceivers located 4-8 inches away from a 
>>>>2V4000 FPGA.
>>>>The board impedance is said to be 50R. I used IBIS models for both
>>>>the transceiver and the FPGA (LVCM316S), and simulated one wire using
>>>>PSPICE. The line is not terminated in any way.
>>>>I get serious overshoot (>4V at 3.3V VCCO) and undershoot (-1V)
>>>>at the (tri-stated) input of the FPGA. Current reaches 100mA during a
>>>>short spike, otherwise some 50mA.
>>>>My question: is this tolerable?
>>>>Doc for VII-Pro states that the FPGA would suffer damage (gate oxide
>>>>breakdown).
>>>>Could it be that the simulation is too pessimistic in these cases?
>>>>
>>>>Thanks for any help
>>>>Gunter
>>>>
>>>>
>> 


Article: 75761
Subject: Re: asynchronous bus transfers
From: rickman <spamgoeshere4@yahoo.com>
Date: Sun, 14 Nov 2004 12:04:36 -0500
Links: << >>  << T >>  << A >>
Jason Berringer wrote:
> 
> 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.

You only need one level of registers or latches for the write data and
either address or decoded address.  You are guaranteed two rising edges
of the 100 MHz clock in each period of the 40 MHz clock.  So you just
need to delay the write strobe by one clock cycle and the write strobe
will be settled.  So use that second clock edge to register the
non-timing info (data address...).  

 just make or just miss clock edge or even was metastable
                    V
write     -----------_________________________----
clock     -----_____-----_____-----_____-----_____
data,etc  ==========xx=======================xx===
                              ^         ^
       register data,etc here | or here |

You can see, either way the data and address are grabbed correctly. 

On my design, I took advantage of the delay to predecode the addresses
into separate control strobes removing one level of delay in the
subsequent logic.  

-- 

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: 75762
Subject: Re: asynchronous bus transfers
From: rickman <spamgoeshere4@yahoo.com>
Date: Sun, 14 Nov 2004 12:10:15 -0500
Links: << >>  << T >>  << A >>


rickman wrote:
> 
> You only need one level of registers or latches for the write data and
> either address or decoded address.  You are guaranteed two rising edges
> of the 100 MHz clock in each period of the 40 MHz clock.  So you just
> need to delay the write strobe by one clock cycle and the write strobe
> will be settled.  So use that second clock edge to register the
> non-timing info (data address...).
> 
>  just make or just miss clock edge or even was metastable
>                     V
> write     -----------_________________________----
> clock     -----_____-----_____-----_____-----_____
> data,etc  ==========xx=======================xx===
>                               ^         ^
              USE data,etc here | or here |
> 
> You can see, either way the data and address are grabbed correctly.
> 
> On my design, I took advantage of the delay to predecode the addresses
> into separate control strobes removing one level of delay in the
> subsequent logic.

I'm not sure I was awake when I wrote this.  You don't actually need to
register the data,etc since they are stable long before and after your
enabled clock edge.  Just use them before they go away which is
guaranteed to be a half clock cycle after the enabled clock edge.  

-- 

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: 75763
Subject: Re: asynchronous bus transfers
From: rickman <spamgoeshere4@yahoo.com>
Date: Sun, 14 Nov 2004 12:11:11 -0500
Links: << >>  << T >>  << A >>
Jason Berringer wrote:
> 
> 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.

Having the clock would not do you a lot of good anyway unless the micro
specs the transfers relative to the clock, which is rare except for
SSRAM or SDRAM interfaces.  

But you can use the rising edge of the write pulse as the clock to the
BRAM.  As long as it is a one way interface, you can provide your own
clock to the read side on the other port.  The micro won't be able to
read what it has written though since you need a clock to read as well.  

But my other suggestion only requires that you delay the write/read
strobes.  

-- 

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: 75764
Subject: Re: Obsolete processors resurected in FPGAs
From: rickman <spamgoeshere4@yahoo.com>
Date: Sun, 14 Nov 2004 12:15:30 -0500
Links: << >>  << T >>  << A >>
Hal Murray wrote:
> 
> >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.

You wouldn't need to *match* the timings, only meet them.  You can
always provide more setup time or allow less setup time from the
peripheral.  

-- 

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: 75765
Subject: Driving towards 2V4000 during Power up
From: "Gunter Knittel" <knittel@gris.uni-tuebingen.de>
Date: Sun, 14 Nov 2004 18:19:40 +0100
Links: << >>  << T >>  << A >>

Hi,

I have a driver (244) with its OE-pins strapped to ground driving
towards I/O-pins of a 2V4000 FPGA. I will make sure these are
pure inputs once the configuration is loaded. I'm also aware of the
fact that the FPGA tristates its IOs prior to configuration.
All devices are connected to the same VCC, the 244 is never
powered when the FPGA is not, and vice versa.
My question is: what happens during Power-up (or Power-down)?
Is it possible that the FPGA-IOs are damaged during power
transition when the 244 is already (still) firing at full force?

Any thoughts on this are appreciated.
Gunter



Article: 75766
Subject: Re: Obsolete processors resurected in FPGAs
From: buchty@atbode100.informatik.tu-muenchen.de (Rainer Buchty)
Date: Sun, 14 Nov 2004 17:29:38 +0000 (UTC)
Links: << >>  << T >>  << A >>
In article <M7Lld.340$IM1.37@newsfe4-gui.ntli.net>,
 "Kryten" <kryten_droid_obfusticator@ntlworld.com> writes:
|> I wonder what fraction of all code used illegal opcodes, and were they ever 
|> much use?

On the C64 they were used quite often for fancy video manipulation; AFAIK
they were also used within a floppy speeder to speed up GCR decoding. 

IIRC the mainly used ones were of the "do something and wire-or the accu in"
kind and multi-cycle NOPs.

You'll find a list here
	http://www.funet.fi/pub/cbm/documents/chipdata/6502-NMOS.extra.opcodes

and how they map into the overall opcode table here
	http://www.funet.fi/pub/cbm/documents/chipdata/64doc

Rainer

Article: 75767
Subject: Re: Driving towards 2V4000 during Power up
From: "Vanheesbeke Stefaan" <svhb@pandora.be>
Date: Sun, 14 Nov 2004 18:54:35 GMT
Links: << >>  << T >>  << A >>
I don't think you will have a problem. As long the 244 have the correct
output voltage levels.


"Gunter Knittel" <knittel@gris.uni-tuebingen.de> wrote in message
news:cn83s3$l7a$1@newsserv.zdv.uni-tuebingen.de...
>
> Hi,
>
> I have a driver (244) with its OE-pins strapped to ground driving
> towards I/O-pins of a 2V4000 FPGA. I will make sure these are
> pure inputs once the configuration is loaded. I'm also aware of the
> fact that the FPGA tristates its IOs prior to configuration.
> All devices are connected to the same VCC, the 244 is never
> powered when the FPGA is not, and vice versa.
> My question is: what happens during Power-up (or Power-down)?
> Is it possible that the FPGA-IOs are damaged during power
> transition when the 244 is already (still) firing at full force?
>
> Any thoughts on this are appreciated.
> Gunter
>
>



Article: 75768
Subject: Re: Research Project Re: Graphics Processor
From: Derek_SImmons@msn.com (Derek Simmons)
Date: 14 Nov 2004 11:22:30 -0800
Links: << >>  << T >>  << A >>
> 
> I've coded for both and I really can't ever recall thinking that a
> G3xx was anything like a 6845, so I am a bit surprised to see a
> claim that they were "based" on them !
> 

I wasn't really trying to compare them in sense that this device could
be used in place of that device. I was trying to show a time line of
evolution from a pretty simple device to a more complex. I remember
coming across the 6845 in devices that didn't require a high-end
device like video terminals and arcade games.

Derek

Article: 75769
Subject: Re: Obsolete processors resurected in FPGAs
From: "bh" <spam_not@nosuch.com>
Date: Sun, 14 Nov 2004 19:44:21 GMT
Links: << >>  << T >>  << A >>
There are a number of applications where old 8080 code or Z8000
has gone through significant number of code reviews and the logic
is considered safe for some special applications. Nevertheless, having
confidence in the softCPU is pretty important in order to have the
qualify-by-similarity argument will hold. Something like an 8080
is a much simpler task to verify, but it cannot be ignored.

Likewise, you really need to do some over-all system testing to
insure subtle timing differences have not resulted in unexpected
consequences. Just meeting/exceeding the timing of the original
component is not good enough (IMHO) since there may be
unknown dependencies on timing that might have been caught
in the original qualification program.

With respect to FAA certification, I believe RTCA DO-254 addresses
some of these issues.

-BH

"Jim Granville" <no.spam@designtools.co.nz> wrote in message
news:jdzld.1215$3U4.105563@news02.tsnz.net...
> Monte Dalrymple wrote:
>
> > "Jim Granville" <no.spam@designtools.co.nz> wrote in message
> >>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.
>
> ..and industrial systems are somewhere in-between.
>
> Did you need to get certification for the Z8000 SoftCPU ? - it seems
> this would need to be fully qualified as well, or have the MIL/FAA
> not quite caught up with the idea of SoftCPU ?
> -jg
>



Article: 75770
Subject: DMA for PPC in Virtex-II Pro/EDK6.2
From: Jeffsen <xjf77{@}yahoo.com>
Date: Sun, 14 Nov 2004 12:13:47 -0800
Links: << >>  << T >>  << A >>
There are one OPB-CENTRAL-DMA available in the EDK IP core list, while when you add this core to the system,no corresponding library file/directory generated for the software development,as described in <Xilinx-Driver>. While in <Xilinx-Driver>,there is one multi-channel-DMA,but core is not listed in the IP core list. So in this case,how can I take advantage of DMA in my design? Thanks!

Article: 75771
Subject: Re: Digital LP filter in multiplier free FPGA
From: "markp" <map.nospam@f2s.com>
Date: Sun, 14 Nov 2004 22:40:16 -0000
Links: << >>  << T >>  << A >>
<snip>
>
> OK, done, I think.
>
> John

Thanks John. I'm not really sure how to tweek this for my system, but very
interesting stuff nonetheless. I decided in the end to go for a 'rolling
average' type filter (rectangular) with 16 taps, and this seems to be
working quite nicely so I think I'll stick with this.

Regards,

Mark.



Article: 75772
Subject: Re: Digital LP filter in multiplier free FPGA
From: "markp" <map.nospam@f2s.com>
Date: Sun, 14 Nov 2004 22:51:33 -0000
Links: << >>  << T >>  << A >>

"Ken" <aeu96186@NOSPAM.yahoo.co.uk> wrote in message
news:cn69m5$rme$05$1@news.t-online.com...
> > 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


Hi Ken,

Well I've gone for a rolling average filter at the moment, but the specs
are:

 > 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?

I've got a 65MHz clock and currently dividing by 6 to give 13MHz.

> Is the filter single-rate or are you decimating?

Single rate so far.

> Input bit-width?

12 bit ADC data.

> Signed/unsigned input?

Unsigned.

> 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.)

-3db @ 3MHz, 4th order Butterworth type roll-off ideally, unity gain
otherwise.

Thanks!

Mark.




Article: 75773
Subject: Re: Digital LP filter in multiplier free FPGA
From: "markp" <map.nospam@f2s.com>
Date: Sun, 14 Nov 2004 22:52:25 -0000
Links: << >>  << T >>  << A >>

"Tom Seim" <soar2morrow@yahoo.com> wrote in message
news:6c71b322.0411131750.5b2c5534@posting.google.com...
> "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!
> >
> > Mark.
>
> You didn't say how sharp your cutoff needs to be, or how much gain
> ripple you can tolerate. You might consider a pipelined multiplier
> design. This will result in very high clock rates, permitting one
> multiplier to handle 8-16 coefficients. Several multipliers can be
> used in parallel to increase the number of coefficients even further.
> Xilinx has numerous ap notes on digital filtering techniques. Here is
> a good review of the topic:
> http://www.andraka.com/multipli.htm
> This is probably the best book on the subject:
>
http://www.amazon.com/exec/obidos/ASIN/3540413413/andraka/103-1626470-7551837
>
> Tom

Thanks Tom! Interesting stuff.

Mark.



Article: 75774
Subject: Re: Digital LP filter in multiplier free FPGA
From: "markp" <map.nospam@f2s.com>
Date: Sun, 14 Nov 2004 22:54:39 -0000
Links: << >>  << T >>  << A >>
Thanks! I'll have a look at this.

Mark.

"Antti Lukats" <antti@case2000.com> wrote in message
news:cn5s6o$9di$05$1@news.t-online.com...
> "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;
>
>





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