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 139925

Article: 139925
Subject: Re: Atari VCS 2600 FPGA Cartridge
From: Darcio Prestes <darcioprestes@gmail.com>
Date: Sun, 19 Apr 2009 13:10:57 -0700 (PDT)
Links: << >>  << T >>  << A >>
On 19 abr, 15:39, whygee <why...@yg.yg> wrote:
> Antti.Luk...@googlemail.com wrote:
> > The ONLY part that satisfies ALL requirements is: ice65L16 from SiliconBlue
>
> A SBt employee told me that it is not available very soon (end of year ?).
> On top of that, is it 5V-tolerant on enough pins ?
>
> > Antti
>
> yg
> --http://ygdes.com/http://yasep.org

YG brought an important question. The data bus is 8 bit wide and
address bus is 12 bit wide. I want to add 4 switches so the count is
24 pins or higher.

Article: 139926
Subject: Re: Atari VCS 2600 FPGA Cartridge
From: Frank Buss <fb@frank-buss.de>
Date: Sun, 19 Apr 2009 22:33:00 +0200
Links: << >>  << T >>  << A >>
Darcio Prestes wrote:

> Hey programmable logic seniors! I'm planning to build an Atari VCS
> 2600 game cartridge in order to play with my "brand new" console
> acquired from ebay. I would like to replace the old fashioned 27C
> series EPROM by a programmable device thus cutting board space and
> (main reason) merging the bankswitching logic and rom file in a single
> device. My requirements are 32k x 8 (64k is a plus) of non volatile
> memory and some space to house a couple of FFs and logic gates (simple
> equations). My question is: which manufacturer, family and/or device
> should I look for? Thanks for sharing your valuable experience with my
> hobby project.

Wikipedia says that the VCS 2600 has a 6507 with 1.19 MHz. So if the bus is
not faster, the easiest solution would be just a microcontroller with
sufficient flash storage, like the STM32 series or the LPC21xx series.
Should be fast enough in a small assembler loop to decode an address
requests, read the flash location and change the data pins to output.

-- 
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de

Article: 139927
Subject: Re: Atari VCS 2600 FPGA Cartridge
From: nico@puntnl.niks (Nico Coesel)
Date: Sun, 19 Apr 2009 22:02:06 GMT
Links: << >>  << T >>  << A >>
Frank Buss <fb@frank-buss.de> wrote:

>Darcio Prestes wrote:
>
>> Hey programmable logic seniors! I'm planning to build an Atari VCS
>> 2600 game cartridge in order to play with my "brand new" console
>> acquired from ebay. I would like to replace the old fashioned 27C
>> series EPROM by a programmable device thus cutting board space and
>> (main reason) merging the bankswitching logic and rom file in a single
>> device. My requirements are 32k x 8 (64k is a plus) of non volatile
>> memory and some space to house a couple of FFs and logic gates (simple
>> equations). My question is: which manufacturer, family and/or device
>> should I look for? Thanks for sharing your valuable experience with my
>> hobby project.
>
>Wikipedia says that the VCS 2600 has a 6507 with 1.19 MHz. So if the bus is
>not faster, the easiest solution would be just a microcontroller with
>sufficient flash storage, like the STM32 series or the LPC21xx series.
>Should be fast enough in a small assembler loop to decode an address
>requests, read the flash location and change the data pins to output.

I think that will actually work. IIRC the old Motorola controllers use
an extra E signal to distingiush between the address selection and
data cycle. But you'll need the LPC2000 series with fast I/O and they
are fully 5V tolerant. The ST peripherals are crap.

-- 
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
                     "If it doesn't fit, use a bigger hammer!"
--------------------------------------------------------------

Article: 139928
Subject: Re: PLL ratios (was Re: Dual-frequency quartz oscillator with a FPGA ?)
From: Brian Drummond <brian_drummond@btconnect.com>
Date: Mon, 20 Apr 2009 00:11:13 +0100
Links: << >>  << T >>  << A >>
On Sun, 19 Apr 2009 21:35:12 +0200, whygee <whygee@yg.yg> wrote:

>Hi !
>
>Brian Drummond wrote:
>> On Sun, 19 Apr 2009 03:08:39 +0200, whygee <whygee@yg.yg> wrote:
>>> Brian Drummond wrote:
>>>> The other crystal is 12.288MHz then.
>>> good guess :-)

>Yes I have changed my mind again, with the help of yet another trick :
>44100 and 48000 have 300 as common divisor
>(and I need 256 times this frequency). (44100/300)*(48000/300)=23520
>I'll have to divide this by 149 or 160 to obtain the right frequency.

Sorry, I'd forgotten that one. 
It's 147 not 149, or 7*7*3 if you are restricted in ratios...
versus 8*5*4 for 48kHz.

>The Actel PLL has only 7-bit ratios, that is too short
>(128<147). 

(Unless you can use their factors as above. Which means 2 PLLs.

>Now I have to find a frequency in the 5-15 MHz range that satisfies
>all these division needs and PLL osc. ranges.

7.056 MHz sound about right? :-)

>Maybe I'll be able to solve this with 2 PLLs or another trick ?

The alternative - if you can tolerate a tiny (1-10ppm) frequency error - is to
find a high frequency (but less than 1.8G) that you can divide down to close
approximations to both 12.288 and 11.2896. (I had a program to search for these
once...)

Or if you can live with say 3-5ns jitter on the 11/12MHz clock (but
substantially no jitter at the sample rate) use a 200-300MHz osc (standard freq,
standard module) and a phase accumulator to generate 11/12Mhz. This will be
arbitrarily accurate and reloading the phase increment will switch frequency
without glitches. Jitter will be 1 (optionally 1/2) cycle of the fast osc.

>that's interesting, though my concern is more about long-term stability.
>150ppm of drift can add up to a significant delay after a while,
>which will desynchronise the system...

Long term drift would be at least an order of magnitude less; the pull was
because one mode of operation required a PLL round the crystal to synchronise to
other equipment.

- Brian


Article: 139929
Subject: Help me I am a new techie on FPGA
From: 'use_real_email'
Date: Sun, 19 Apr 2009 21:32:37 -0700
Links: << >>  << T >>  << A >>

Hello Friends
I am a new techie on FPGA
I am dumping simple programs <4 bit on Xilinx Spartan-3E kit with
xilinx ISE
can any one say me how to dumb a program >4bit on this kit
and  please say me why micro biz is used


Thanking you
Ramesh


-- 
ramesh441
------------------------------------------------------------------------
ramesh441's Profile: http://www.fpgacentral.com/group/member.php?userid=69
View this thread: http://www.fpgacentral.com/group/showthread.php?t=89534


Article: 139930
Subject: Re: Why is XST optimizing away my registers and how do I stop it?
From: Ben Jackson <ben@ben.com>
Date: Mon, 20 Apr 2009 04:52:13 GMT
Links: << >>  << T >>  << A >>
On 2009-04-18, mooo <randomname650@gmail.com> wrote:
> I don't know, this is my third verilog program and I'm just tooling
> around on my lonesome in my spare time.  I was googling around trying
> to figure out how to convert a binary number to an ASCII string and
> that's what I came up with.  How does one tell whether or not
> something is synthesizeable?

This is what's wrong with almost every Verilog tutorial I've seen.  They
all start out teaching you about the scripting features of Verilog (which
are not synthesizable) and totally fail to make the distinction.  What's
worse is that most people using those tutorials are software programmers
who are easily misled.

I would scale back your first attempt to sending an ASCII binary string
out your serial port.

-- 
Ben Jackson AD7GD
<ben@ben.com>
http://www.ben.com/

Article: 139931
Subject: Re: PLL ratios (was Re: Dual-frequency quartz oscillator with a FPGA
From: whygee <whygee@yg.yg>
Date: Mon, 20 Apr 2009 07:30:16 +0200
Links: << >>  << T >>  << A >>
Brian Drummond wrote:
> On Sun, 19 Apr 2009 21:35:12 +0200, whygee <whygee@yg.yg> wrote:
>> Yes I have changed my mind again, with the help of yet another trick :
>> 44100 and 48000 have 300 as common divisor
>> (and I need 256 times this frequency). (44100/300)*(48000/300)=23520
>> I'll have to divide this by 149 or 160 to obtain the right frequency.
> Sorry, I'd forgotten that one. 
> It's 147 not 149, or 7*7*3 if you are restricted in ratios...
sorry for the type :-)

> versus 8*5*4 for 48kHz.
yes, I wrote them all down...

IIRC the 44100Hz sampling rate comes from a storage medium that used
video tapes, they simply reused the same sampling rate when they designed
the CD standard, because there was no other digital recording equipment
that could match the CD quality... So one should find television
frequencies, divisors or factors, no ?

>> The Actel PLL has only 7-bit ratios, that is too short (128<147). 
> (Unless you can use their factors as above. Which means 2 PLLs.
I'll look at the recent "Igloo plus" or "Igloo E" that have 2 to 6 PLLs.
Currently (for my first custom board) I keep the usual ProASIC3,
cheaper, available and more-or-less compatible with the successors.


>> Now I have to find a frequency in the 5-15 MHz range that satisfies
>> all these division needs and PLL osc. ranges.
> 7.056 MHz sound about right? :-)
sure :-)
I've seen this frequency when playing with the ratios,
but i did not settle there because I needed another *256 factor.
I'll look more closely to this one...

>> Maybe I'll be able to solve this with 2 PLLs or another trick ?
> The alternative - if you can tolerate a tiny (1-10ppm) frequency error - is to
> find a high frequency (but less than 1.8G) that you can divide down to close
> approximations to both 12.288 and 11.2896. (I had a program to search for these
> once...)
hmmm...
If I was OK then I would not bother and use Wolfson or Texas Instruments
chips, they generate "something close enough to the required frequency"
from a 12MHz quartz (that is required by the USB protocol).
I'm not an "audiophile" but I know digital sound enough to know how
to avoid stupid problems later (even when it means that I have to solve
not-so-easy problems now).

> Or if you can live with say 3-5ns jitter on the 11/12MHz clock (but
> substantially no jitter at the sample rate)
yes because it is integrated by the *256 oversampling D/A
(and hopefully a PLL ?)

> use a 200-300MHz osc (standard freq,
> standard module) and a phase accumulator to generate 11/12Mhz.
It's going to buuuuurn power :-/

> This will be
> arbitrarily accurate and reloading the phase increment will switch frequency
> without glitches. Jitter will be 1 (optionally 1/2) cycle of the fast osc.
hmmm... I prefer the PLL idea because it uses special gates, not
those from the fabric. And a phase accumulator needs to work at high speed,
but a standard 32-bit adder in ProASIC3 works generally at 60-70MHz max.
And it eats quite a lot of gates.

thank you for the insight,
> - Brian
yg

-- 
http://ygdes.com / http://yasep.org

Article: 139932
Subject: Re: PLL ratios (was Re: Dual-frequency quartz oscillator with a FPGA
From: whygee <whygee@yg.yg>
Date: Mon, 20 Apr 2009 07:33:59 +0200
Links: << >>  << T >>  << A >>
Antti.Lukats@googlemail.com wrote:
> 1) Actel PLL tolerates customer xx.yy divider clock remover in the
> feedback loop, so it can generate almost any frequency - see "pll
> clock dither app note"
I've not heard about it yet... I'll have to find it.

> 2) there is dynamic config mode
yes, I count on this one too :-)
I'll modify my SPI master VHDL code to include the 81-bit
shift register thing.

> so you can connect ext freq to 1 pin, and get all the desired
> frequencies from single PLL
> 
> PS for the clock dither you NEED specific extfb path connecting 2
> actual IOs of the FPGA, on PA it was possible in fabric but PA3
> requires external loopback, this loopback wire is one of the things we
> added on FPGA stamp PCB rev B, just to support the clock dither trick

thanks for the tips !

> Antti
yg

-- 
http://ygdes.com / http://yasep.org

Article: 139933
Subject: Re: PLL ratios (was Re: Dual-frequency quartz oscillator with a FPGA
From: "Antti.Lukats@googlemail.com" <Antti.Lukats@googlemail.com>
Date: Sun, 19 Apr 2009 22:37:18 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 20, 2:11=A0am, Brian Drummond <brian_drumm...@btconnect.com>
wrote:
> On Sun, 19 Apr 2009 21:35:12 +0200, whygee <why...@yg.yg> wrote:
> >Hi !
>
> >Brian Drummond wrote:
> >> On Sun, 19 Apr 2009 03:08:39 +0200, whygee <why...@yg.yg> wrote:
> >>> Brian Drummond wrote:
> >>>> The other crystal is 12.288MHz then.
> >>> good guess :-)
> >Yes I have changed my mind again, with the help of yet another trick :
> >44100 and 48000 have 300 as common divisor
> >(and I need 256 times this frequency). (44100/300)*(48000/300)=3D23520
> >I'll have to divide this by 149 or 160 to obtain the right frequency.
>
> Sorry, I'd forgotten that one.
> It's 147 not 149, or 7*7*3 if you are restricted in ratios...
> versus 8*5*4 for 48kHz.
>
> >The Actel PLL has only 7-bit ratios, that is too short
> >(128<147).
>
> (Unless you can use their factors as above. Which means 2 PLLs.
>
> >Now I have to find a frequency in the 5-15 MHz range that satisfies
> >all these division needs and PLL osc. ranges.
>
> 7.056 MHz sound about right? :-)
>
> >Maybe I'll be able to solve this with 2 PLLs or another trick ?
>
> The alternative - if you can tolerate a tiny (1-10ppm) frequency error - =
is to
> find a high frequency (but less than 1.8G) that you can divide down to cl=
ose
> approximations to both 12.288 and 11.2896. (I had a program to search for=
 these
> once...)
>
> Or if you can live with say 3-5ns jitter on the 11/12MHz clock (but
> substantially no jitter at the sample rate) use a 200-300MHz osc (standar=
d freq,
> standard module) and a phase accumulator to generate 11/12Mhz. This will =
be
> arbitrarily accurate and reloading the phase increment will switch freque=
ncy
> without glitches. Jitter will be 1 (optionally 1/2) cycle of the fast osc=
.
>
> >that's interesting, though my concern is more about long-term stability.
> >150ppm of drift can add up to a significant delay after a while,
> >which will desynchronise the system...
>
> Long term drift would be at least an order of magnitude less; the pull wa=
s
> because one mode of operation required a PLL round the crystal to synchro=
nise to
> other equipment.
>
> - Brian

1) Actel PLL tolerates customer xx.yy divider clock remover in the
feedback loop, so it can generate almost any frequency - see "pll
clock dither app note"
2) there is dynamic config mode


so you can connect ext freq to 1 pin, and get all the desired
frequencies from single PLL

PS for the clock dither you NEED specific extfb path connecting 2
actual IOs of the FPGA, on PA it was possible in fabric but PA3
requires external loopback, this loopback wire is one of the things we
added on FPGA stamp PCB rev B, just to support the clock dither trick

Antti






Article: 139934
Subject: Re: PLL ratios (was Re: Dual-frequency quartz oscillator with a FPGA ?)
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Mon, 20 Apr 2009 05:53:39 +0000 (UTC)
Links: << >>  << T >>  << A >>
whygee <whygee@yg.yg> wrote:
 
> IIRC the 44100Hz sampling rate comes from a storage medium that used
> video tapes, they simply reused the same sampling rate when they designed
> the CD standard, because there was no other digital recording equipment
> that could match the CD quality... So one should find television
> frequencies, divisors or factors, no ?

If I remember the story, it was also so that the video tape
based system could be used to store master tapes for CDs.

My first hard disk, a few years after CDs came out,
was 40MB.  Tape was the only medium with enough storage
capacity for a CD master.

-- glen

Article: 139935
Subject: Re: Atari VCS 2600 FPGA Cartridge
From: Gregory Estrade <gregory.estrade@gmail.com>
Date: Mon, 20 Apr 2009 00:02:53 -0700 (PDT)
Links: << >>  << T >>  << A >>
On 19 avr, 22:33, Frank Buss <f...@frank-buss.de> wrote:
> Darcio Prestes wrote:
> > Hey programmable logic seniors! I'm planning to build an Atari VCS
> > 2600 game cartridge in order to play with my "brand new" console
> > acquired from ebay. I would like to replace the old fashioned 27C
> > series EPROM by a programmable device thus cutting board space and
> > (main reason) merging the bankswitching logic and rom file in a single
> > device. My requirements are 32k x 8 (64k is a plus) of non volatile
> > memory and some space to house a couple of FFs and logic gates (simple
> > equations). My question is: which manufacturer, family and/or device
> > should I look for? Thanks for sharing your valuable experience with my
> > hobby project.
>
> Wikipedia says that the VCS 2600 has a 6507 with 1.19 MHz. So if the bus is
> not faster, the easiest solution would be just a microcontroller with
> sufficient flash storage, like the STM32 series or the LPC21xx series.
> Should be fast enough in a small assembler loop to decode an address
> requests, read the flash location and change the data pins to output.
>
> --
> Frank Buss, f...@frank-buss.dehttp://www.frank-buss.de,http://www.it4-systems.de

IMO, there are some issues that prevent from doing that :
- Some cartridges have werid bankswitching schemes, some others
contain additional RAM, so even at 50Mhz or so, your assembler loop
may not fit in a VCS clock cycle. And for the LPC2xxx series, even the
ones with "fast I/O" can't switch over 15-16Mhz, IIRC.
- VCS2600 has not reset switch (the reset switch on the front panel
doesn't perform a reset of the machine), and the power-on reset delay
is very small. Your MCU might not have the time to perform its own
initialization code. Well, in this case you could still use a separate
power supply.

Article: 139936
Subject: Igloo nano Starter Kit
From: Bert_Paris <do_not_spam@me.com>
Date: Mon, 20 Apr 2009 09:33:13 +0200
Links: << >>  << T >>  << A >>
Hello,

For those who just got their hands on an Igloo nano Starter Kit,
and especially for beginners, I have assembled a complete Tutorial at :
http://www.alse-fr.com/Actel/igloo.html

Enjoy...

Bert



Article: 139937
Subject: Re: PLL ratios (was Re: Dual-frequency quartz oscillator with a FPGA ?)
From: Brian Drummond <brian_drummond@btconnect.com>
Date: Mon, 20 Apr 2009 08:57:11 +0100
Links: << >>  << T >>  << A >>
On Mon, 20 Apr 2009 07:30:16 +0200, whygee <whygee@yg.yg> wrote:

>Brian Drummond wrote:
>> On Sun, 19 Apr 2009 21:35:12 +0200, whygee <whygee@yg.yg> wrote:
>>> Yes I have changed my mind again, with the help of yet another trick :
>>> 44100 and 48000 have 300 as common divisor
>>> (and I need 256 times this frequency). (44100/300)*(48000/300)=23520
>>> I'll have to divide this by 149 or 160 to obtain the right frequency.
>> Sorry, I'd forgotten that one. 
>> It's 147 not 149, or 7*7*3 if you are restricted in ratios...
>sorry for the type :-)
>
>> versus 8*5*4 for 48kHz.
>yes, I wrote them all down...
>
>IIRC the 44100Hz sampling rate comes from a storage medium that used
>video tapes, they simply reused the same sampling rate when they designed
>the CD standard, because there was no other digital recording equipment
>that could match the CD quality... So one should find television
>frequencies, divisors or factors, no ?
>
>>> The Actel PLL has only 7-bit ratios, that is too short (128<147). 
>> (Unless you can use their factors as above. Which means 2 PLLs.
>I'll look at the recent "Igloo plus" or "Igloo E" that have 2 to 6 PLLs.
>Currently (for my first custom board) I keep the usual ProASIC3,
>cheaper, available and more-or-less compatible with the successors.
>
>
>>> Now I have to find a frequency in the 5-15 MHz range that satisfies
>>> all these division needs and PLL osc. ranges.
>> 7.056 MHz sound about right? :-)
>sure :-)
>I've seen this frequency when playing with the ratios,
>but i did not settle there because I needed another *256 factor.
>I'll look more closely to this one...
>
>>> Maybe I'll be able to solve this with 2 PLLs or another trick ?
>> The alternative - if you can tolerate a tiny (1-10ppm) frequency error - is to
>> find a high frequency (but less than 1.8G) that you can divide down to close
>> approximations to both 12.288 and 11.2896. (I had a program to search for these
>> once...)
>hmmm...
>If I was OK then I would not bother and use Wolfson or Texas Instruments
>chips, they generate "something close enough to the required frequency"
>from a 12MHz quartz (that is required by the USB protocol).
>I'm not an "audiophile" but I know digital sound enough to know how
>to avoid stupid problems later (even when it means that I have to solve
>not-so-easy problems now).
>
>> Or if you can live with say 3-5ns jitter on the 11/12MHz clock (but
>> substantially no jitter at the sample rate)
>yes because it is integrated by the *256 oversampling D/A
>(and hopefully a PLL ?)

With an oversampling D/A you want the lowest possible jitter on the *256 clock;
the phase accumulator (unless followed by a PLL) is not a good option. You need
identical area under all 256 possible charge packets.

Given that constraint the PLL looks better.

However it might be worth asking where you get the D/A. If you can roll your own
- or even the DSP portion and use the analog portion of a commercial solution -
it would be possible to oversample by either *3,*7,*7 or *4,*5,*8  and generate
both datastreams at the same clock frequency.

But that would require a medium sized Spartan-3 or equivalent; possibly bigger
than you want.

- Brian

Article: 139938
Subject: Re: PLL ratios (was Re: Dual-frequency quartz oscillator with a FPGA ?)
From: Brian Drummond <brian_drummond@btconnect.com>
Date: Mon, 20 Apr 2009 09:03:34 +0100
Links: << >>  << T >>  << A >>
On Mon, 20 Apr 2009 05:53:39 +0000 (UTC), glen herrmannsfeldt
<gah@ugcs.caltech.edu> wrote:

>whygee <whygee@yg.yg> wrote:
> 
>> IIRC the 44100Hz sampling rate comes from a storage medium that used
>> video tapes, they simply reused the same sampling rate when they designed
>> the CD standard, because there was no other digital recording equipment
>> that could match the CD quality... So one should find television
>> frequencies, divisors or factors, no ?
>
>If I remember the story, it was also so that the video tape
>based system could be used to store master tapes for CDs.
>
>My first hard disk, a few years after CDs came out,
>was 40MB.  Tape was the only medium with enough storage
>capacity for a CD master.

Specifically the Sony U-Matic semi-pro (3/4 inch?) videotape used by the PCM1600
(1610?). Three samples (per channel) per active line on either 60Hz NTSC or 50Hz
PAL. Since drop-frame NTSC actually ran at 59.94Hz (I believe to hide supply
interference) the American version actually sampled at 44.056 kHz. 
But I don't believe any CD players actually followed that particular deviation.

- Brian

Article: 139939
Subject: Re: Atari VCS 2600 FPGA Cartridge
From: Frank Buss <fb@frank-buss.de>
Date: Mon, 20 Apr 2009 10:48:28 +0200
Links: << >>  << T >>  << A >>
Gregory Estrade wrote:

> IMO, there are some issues that prevent from doing that :
> - Some cartridges have werid bankswitching schemes, some others
> contain additional RAM, so even at 50Mhz or so, your assembler loop
> may not fit in a VCS clock cycle. And for the LPC2xxx series, even the
> ones with "fast I/O" can't switch over 15-16Mhz, IIRC.

You are right, this could be interesting. The bankswitching I've found
doesn't look complicated:

http://www.scribd.com/doc/5439358

It is just a read from a magic address to switch banks. Simulating 256
bytes RAM works by providing write access from 0x1000 to 0x10ff and read
access for the same memory by accessing 0x1100 to 0x11ff. But the E7 method
might be a bit more complicated.

So I think the standard catridge with a 4k eprom simulation should be no
problem. If there are problems with the 3.3V output of the microcontroller
(might be not enough voltage for the data out), you'll need additional
level translation chips. A PIC might be better, e.g. the PIC18F2420, which
works with 5V power supply and up to 40MHz.

But you have to carefully read the timing diagrams of the Atari system and
the PIC and check if it is possible to implement the more complex bank
switching concepts. Each port write and read of the PIC needs already 8
clocks, so might be too slow.

> - VCS2600 has not reset switch (the reset switch on the front panel
> doesn't perform a reset of the machine), and the power-on reset delay
> is very small. Your MCU might not have the time to perform its own
> initialization code. Well, in this case you could still use a separate
> power supply.

At least the schematic for the Junior version shows a reset circuit with a
12k resistor loading a 4u7 elco:

http://www.atariage.com/2600/archives/schematics_pal/Schematic_2600_Junior_PAL.html

The original schematic looks a bit strange, because I don't see any plus
supply to the reset pin:

http://www.atariage.com/2600/archives/schematics_pal/Schematic_2600_Console_PAL.html

But I guess this was just missing from the schematic, and it was something
like 1k for loading the 4u7, which should give a lot of time to start a
microcontroller from the same power supply.

So a FPGA with serial configuration might be too slow, but you could buffer
it with an elco and just power cycle the Atari twice, or changing the reset
circuit inside the Atari system.

-- 
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de

Article: 139940
Subject: Re: Atari VCS 2600 FPGA Cartridge
From: Mike Harrison <mike@whitewing.co.uk>
Date: Mon, 20 Apr 2009 10:20:34 +0100
Links: << >>  << T >>  << A >>
On Sun, 19 Apr 2009 22:33:00 +0200, Frank Buss <fb@frank-buss.de> wrote:

>Darcio Prestes wrote:
>
>> Hey programmable logic seniors! I'm planning to build an Atari VCS
>> 2600 game cartridge in order to play with my "brand new" console
>> acquired from ebay. I would like to replace the old fashioned 27C
>> series EPROM by a programmable device thus cutting board space and
>> (main reason) merging the bankswitching logic and rom file in a single
>> device. My requirements are 32k x 8 (64k is a plus) of non volatile
>> memory and some space to house a couple of FFs and logic gates (simple
>> equations). My question is: which manufacturer, family and/or device
>> should I look for? Thanks for sharing your valuable experience with my
>> hobby project.
>
>Wikipedia says that the VCS 2600 has a 6507 with 1.19 MHz. So if the bus is
>not faster, the easiest solution would be just a microcontroller with
>sufficient flash storage, like the STM32 series or the LPC21xx series.
>Should be fast enough in a small assembler loop to decode an address
>requests, read the flash location and change the data pins to output.

With ARM MCUs with fast IO like the NXP LPC series, you can use FIQs on the chip select to give very
fast response to external signals - I've read data from an image sensor at 4MHz like this in the
past. 
The only problem is that to get enough on-chip RAM you end up paying for a lot of flash you don't
need - and external SRAM usually works out cheaper.

However a CPLD plus SRAM may end up being the cheapest overall solution. 


Article: 139941
Subject: Re: PLL ratios (was Re: Dual-frequency quartz oscillator with a FPGA ?)
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Mon, 20 Apr 2009 10:31:21 +0000 (UTC)
Links: << >>  << T >>  << A >>
Brian Drummond <brian_drummond@btconnect.com> wrote:
(snip, I wrote)
 

>>If I remember the story, it was also so that the video tape
>>based system could be used to store master tapes for CDs.

>>My first hard disk, a few years after CDs came out,
>>was 40MB.  Tape was the only medium with enough storage
>>capacity for a CD master.

> Specifically the Sony U-Matic semi-pro (3/4 inch?) videotape 
> used by the PCM1600 (1610?). Three samples (per channel) 
> per active line on either 60Hz NTSC or 50Hz PAL. 
> Since drop-frame NTSC actually ran at 59.94Hz (I believe 
> to hide supply interference) the American version actually 
> sampled at 44.056 kHz. 

It comes from three constraints, the last one being
the offset between the video and the audio subcarrier.
The first two are an odd number of cycles per line
and per field.

> But I don't believe any CD players actually followed that 
> particular deviation.

Well, for NTSC timing, the 59.94 only applies to color
signals (with an active color burst).  Black and white
signals would still run at 60Hz.  In either case, the recorder
has to synch to the incoming signal.  Normally (for TV sets)
in playback, one would synch to the playback signal.  I believe
that some players would allow one to supply a source signal
for the player to synch to.  That would allow, for example,
combining two video signals.

-- glen

Article: 139942
Subject: re: FPGA Inernal reset
From: gabor <gabor@alacron.com>
Date: Mon, 20 Apr 2009 05:33:49 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 19, 2:13=A0pm, whygee <why...@yg.yg> wrote:
> -jg wrote:
>
[snip]
> Off-topic : what FPGA family provides an internally-generated /RESET sign=
al
> to the logic array ? Those that I know require an externel signal...
> Now that I think about this, it sounds curious.
> This is probably because most chips work with different I/O-cores-whateve=
r voltages,
> but then in a Flash-based FPGA at least, one could eventually program
> the tripping voltage of a power supply supervisor.
> I guess that the Fusion devices are a bit close to this, but the chip
> can examine its own power supply with the ADC which means that the core
> must be initialised before...
>
> > -jg
>
> yg
>
> --http://ygdes.com/http://yasep.org

Pretty much all SRAM-based FPGA's have internal power-on
reset circuitry to trigger the configuration of the part.
While this reset happens well before the logic is up and
running, the nature of the bitstream load lends itself to
an internal reset in that all of the flip-flops and
(usually) RAM cells are initialized during configuration.
An internal reset can be generated simply by releasing
the logic to a running state.  The normal procedure is
to instantiate a short shift register with an initial
value of all 1's (or all 0's for active low logic) and
then shifting in 0's when the chip starts up.  The output
of the shift register will therefore start up the
rest of the chip a few clocks after configuration
is complete without the need for an external reset
signal.

Regards,
Gabor

Article: 139943
Subject: Re: Why is XST optimizing away my registers and how do I stop it?
From: gabor <gabor@alacron.com>
Date: Mon, 20 Apr 2009 05:37:45 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 20, 12:52=A0am, Ben Jackson <b...@ben.com> wrote:
> On 2009-04-18, mooo <randomname...@gmail.com> wrote:
>
> > I don't know, this is my third verilog program and I'm just tooling
> > around on my lonesome in my spare time. =A0I was googling around trying
> > to figure out how to convert a binary number to an ASCII string and
> > that's what I came up with. =A0How does one tell whether or not
> > something is synthesizeable?
>
> This is what's wrong with almost every Verilog tutorial I've seen. =A0The=
y
> all start out teaching you about the scripting features of Verilog (which
> are not synthesizable) and totally fail to make the distinction. =A0What'=
s
> worse is that most people using those tutorials are software programmers
> who are easily misled.
>
> I would scale back your first attempt to sending an ASCII binary string
> out your serial port.
>
> --
> Ben Jackson AD7GD
> <b...@ben.com>http://www.ben.com/

Not a bad suggestion, since it skips the binary to decimal
step.  Printing a hexadecimal string would not be much harder.

Cheers,
Gabor

Article: 139944
Subject: ISE 10.1 installation troubles on windows Vista 32bit
From: Benjamin Couillard <benjamin.couillard@gmail.com>
Date: Mon, 20 Apr 2009 07:32:52 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi, I've downloaded ISE 10.1  and I'm now trying to install it on my
PC. Every time I click on setup.exe, the program crashes and I get an
error message from Windows.

I tried running it as an administrator, I tried running it with
"windows xp compatability mode" and it still doesn't work. What's
weird is that I've installed ISE 9.2 without any problems. It seems
that Vista home is not officially supported by Xilinx since they only
mention Vista Business on ISE 10.1 webpage. However, it should stil
work with Vista Home.

My windows vista configuration is the following :

Windows Vista Home edition premium 32-bit French
3 gig of ram

Best regards

Article: 139945
Subject: FPGA lockup with pinout report view. was: fpga locks up with slow
From: jleslie48 <jon@jonathanleslie.com>
Date: Mon, 20 Apr 2009 08:46:14 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 19, 10:10 am, jleslie48 <j...@jonathanleslie.com> wrote:
> On Apr 19, 9:06 am, Brian Drummond <brian_drumm...@btconnect.com>
> wrote:
>
>
>
> > On Sat, 18 Apr 2009 16:03:33 -0700 (PDT), jleslie48 <j...@jonathanleslie.com>
> > wrote:
>
> > >> One approach would be to generate an enable ( a pulse 1 clk40MHz cycle wide)
> > >> from it (easy: e.g. delay it 1 cycle and XOR them for an 8Hz enable) and clock
> > >> the actual logic off 40MHz. This will ensure the tool's timing analysis works
> > >> correctly and eliminates a major potential set of problems; it may waste a few
> > >> mw if that matters.
>
> > >> Another approach would be to instantiate a BUFG on the 4Hz clock. Then the BUFG
> > >> output should be automatically routed on low skew networks and analyzed for
> > >> timing hazards.
> > >Thanks for the tips.  they will be tried/looked at on monday morning.
> > >I am confused though.  what's the big deal about it being a "clock"?
>
> > For all other signals, the tools basically only need to guarantee the routing is
> > faster than the clock period (+/- small allowance for jitter, clock skew etc);
> > which at 4Hz or even 40MHz is easy.
>
> > For a clock, the tools must perform a much more rigorous analysis; it is equally
> > bad for a clock signal to arrive too early as too late!
>
> > I presume your 4Hz clock is driving a simple state machine to blink blink blink;
> > pause; repeat.
>
> > If the clock delay to each FF in that SM isn't tightly controlled, it will reach
> > some FFs before their inputs change, and others after their inputs (output from
> > FFs clocked earlier) change. Hence there is no predicting what the SM will do.
> > And each routing pass will behave differently; by chance, some may even work!
>
> > >I don't get why tying a std_logic value to a second output pin can be
> > >a catalyst to a catastrophic failure of an FPGA.
>
> > That can cause the routing to change significantly.
>
> > Don't let it scare you - once you find the groove; avoiding dodgy design areas -
> > the tools will deliver reliable results. It's not any worse than C's pointer
> > arithmetic!
>
> > Re: persistence of obsolete pins: how are you generating constraints (UCF
> > files)?
>
> > If you are using the ISE tools, it's worth checking the UCF file in a text
> > editor; I just use the editor and forget the tools (which maddeningly force
> > another synthesis pass first because I updated a comment somewhere)
>
> > I also check the translate (.bld) report, the map (.mrp) report and the PAR
> > (.par) report; if any of these stages fail, you CAN end up using obsolete files
> > (at least from the command line)
>
> > - Brian
>
> Yeah, I only use the UCF file in the text editor.  I'll take a look at
> all those files very
> carefully.  I tried doing a diff at one point between a working
> version using pin 15 and an non
> working version using pin13 but nothing jumped up at me.  On several
> occasions I just went into
> the ucf file with notepad, added a trailing space and saved just to
> make sure it was touched, Didn't help though.

Ok, I'm looking at the PACE and pinout report, nothing jumps out at
me, maybe you can see something.

Here's the program that drives the LED, and pins 17, 18. This one
works fine:

http://jleslie48.com/fpga_uartjl_01/11jlmod/ccuart01/screencap/screencap24_led3_working_pins_1718.png


and heres the one where all I did was add PIN15_LED, but it locks up
the FPGA:

http://jleslie48.com/fpga_uartjl_01/11jlmod/ccuart01/screencap/screencap25_led3_notworking_pins_1718_15.png


I hi-lighted/ red-boxed what appears to me to be the significant
lines.

It just doesn't make any sense.

the UCF file differs  by one line, I added:

NET "PIN15_led" LOC = "A13";    #"FPGA_IO14"

and the top.vhd differs by two,

I've added the pin15_led line here:

-----------------------------------------------------------------------
ENTITY lprj_TOP IS

    Port

    (

    -- CLOCKS.UCF SIGNALS
    SYSTEM_CLOCK            : IN  STD_LOGIC;


    -- RS232.UCF SIGNALS
    RS232_DSR_OUT           : OUT STD_LOGIC;
    HUART_TX_LINE           : OUT STD_LOGIC;
    RS232_CTS_OUT           : OUT STD_LOGIC;
    HUART_RX_LINE           : IN  STD_LOGIC;
  --RS232_RTS_IN            : IN  STD_LOGIC;

    -- SIGNALS
    a2mhz_HUART_TX_LINE     : OUT STD_logic;
    a2mhz_HUART_CK_LINE     : OUT STD_LOGIC;

    -- LEDS.UCF SIGNALS
    led_2                   : OUT STD_LOGIC;
    led_3                   : OUT STD_LOGIC;
    led_4                   : OUT STD_LOGIC;
    led_5                   : OUT STD_LOGIC;
    pin15_led               : OUT STD_LOGIC;

-- FPGA pin JTAG signals   -- dummy placeholders.
--    TCK  : IN STD_LOGIC;
--    TDI  : IN STD_LOGIC;
--    TDO  : in STD_LOGIC;
--    TMS  : IN STD_LOGIC;
--    jtag_or_dummy           : OUT STD_LOGIC;



    -- PUSHBUTTON.UCF SIGNALS
  button_1                : IN  STD_LOGIC;
  --PB_UP                   : IN  STD_LOGIC;
  PB_DOWN                 : IN  STD_LOGIC;
  button_2                 : IN  STD_LOGIC;
  PB_RIGHT                : IN  STD_LOGIC

    );
-----------------------------------------------------------------------


and in the main body of the behavioral I added this pin15_led line:


-----------------------------------------------------------------------
  led_3     <= clk_4hz;
  pin15_led     <= not clk_4hz;   -- default state for pin 15 is on.

-----------------------------------------------------------------------

Sincerely,

Jonathan
Leslie

Article: 139946
Subject: Re: FPGA lockup with pinout report view. was: fpga locks up with slow
From: jleslie48 <jon@jonathanleslie.com>
Date: Mon, 20 Apr 2009 09:40:12 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 20, 11:46 am, jleslie48 <j...@jonathanleslie.com> wrote:
> On Apr 19, 10:10 am, jleslie48 <j...@jonathanleslie.com> wrote:
>
>
>
> > On Apr 19, 9:06 am, Brian Drummond <brian_drumm...@btconnect.com>
> > wrote:
>
> > > On Sat, 18 Apr 2009 16:03:33 -0700 (PDT), jleslie48 <j...@jonathanleslie.com>
> > > wrote:
>
> > > >> One approach would be to generate an enable ( a pulse 1 clk40MHz cycle wide)
> > > >> from it (easy: e.g. delay it 1 cycle and XOR them for an 8Hz enable) and clock
> > > >> the actual logic off 40MHz. This will ensure the tool's timing analysis works
> > > >> correctly and eliminates a major potential set of problems; it may waste a few
> > > >> mw if that matters.
>
> > > >> Another approach would be to instantiate a BUFG on the 4Hz clock. Then the BUFG
> > > >> output should be automatically routed on low skew networks and analyzed for
> > > >> timing hazards.
> > > >Thanks for the tips.  they will be tried/looked at on monday morning.
> > > >I am confused though.  what's the big deal about it being a "clock"?
>
> > > For all other signals, the tools basically only need to guarantee the routing is
> > > faster than the clock period (+/- small allowance for jitter, clock skew etc);
> > > which at 4Hz or even 40MHz is easy.
>
> > > For a clock, the tools must perform a much more rigorous analysis; it is equally
> > > bad for a clock signal to arrive too early as too late!
>
> > > I presume your 4Hz clock is driving a simple state machine to blink blink blink;
> > > pause; repeat.
>
> > > If the clock delay to each FF in that SM isn't tightly controlled, it will reach
> > > some FFs before their inputs change, and others after their inputs (output from
> > > FFs clocked earlier) change. Hence there is no predicting what the SM will do.
> > > And each routing pass will behave differently; by chance, some may even work!
>
> > > >I don't get why tying a std_logic value to a second output pin can be
> > > >a catalyst to a catastrophic failure of an FPGA.
>
> > > That can cause the routing to change significantly.
>
> > > Don't let it scare you - once you find the groove; avoiding dodgy design areas -
> > > the tools will deliver reliable results. It's not any worse than C's pointer
> > > arithmetic!
>
> > > Re: persistence of obsolete pins: how are you generating constraints (UCF
> > > files)?
>
> > > If you are using the ISE tools, it's worth checking the UCF file in a text
> > > editor; I just use the editor and forget the tools (which maddeningly force
> > > another synthesis pass first because I updated a comment somewhere)
>
> > > I also check the translate (.bld) report, the map (.mrp) report and the PAR
> > > (.par) report; if any of these stages fail, you CAN end up using obsolete files
> > > (at least from the command line)
>
> > > - Brian
>
> > Yeah, I only use the UCF file in the text editor.  I'll take a look at
> > all those files very
> > carefully.  I tried doing a diff at one point between a working
> > version using pin 15 and an non
> > working version using pin13 but nothing jumped up at me.  On several
> > occasions I just went into
> > the ucf file with notepad, added a trailing space and saved just to
> > make sure it was touched, Didn't help though.
>
> Ok, I'm looking at the PACE and pinout report, nothing jumps out at
> me, maybe you can see something.
>
> Here's the program that drives the LED, and pins 17, 18. This one
> works fine:
>
> http://jleslie48.com/fpga_uartjl_01/11jlmod/ccuart01/screencap/screen...
>
> and heres the one where all I did was add PIN15_LED, but it locks up
> the FPGA:
>
> http://jleslie48.com/fpga_uartjl_01/11jlmod/ccuart01/screencap/screen...
>
> I hi-lighted/ red-boxed what appears to me to be the significant
> lines.
>
> It just doesn't make any sense.
>
> the UCF file differs  by one line, I added:
>
> NET "PIN15_led" LOC = "A13";    #"FPGA_IO14"
>
> and the top.vhd differs by two,
>
> I've added the pin15_led line here:
>
> -----------------------------------------------------------------------
> ENTITY lprj_TOP IS
>
>     Port
>
>     (
>
>     -- CLOCKS.UCF SIGNALS
>     SYSTEM_CLOCK            : IN  STD_LOGIC;
>
>     -- RS232.UCF SIGNALS
>     RS232_DSR_OUT           : OUT STD_LOGIC;
>     HUART_TX_LINE           : OUT STD_LOGIC;
>     RS232_CTS_OUT           : OUT STD_LOGIC;
>     HUART_RX_LINE           : IN  STD_LOGIC;
>   --RS232_RTS_IN            : IN  STD_LOGIC;
>
>     -- SIGNALS
>     a2mhz_HUART_TX_LINE     : OUT STD_logic;
>     a2mhz_HUART_CK_LINE     : OUT STD_LOGIC;
>
>     -- LEDS.UCF SIGNALS
>     led_2                   : OUT STD_LOGIC;
>     led_3                   : OUT STD_LOGIC;
>     led_4                   : OUT STD_LOGIC;
>     led_5                   : OUT STD_LOGIC;
>     pin15_led               : OUT STD_LOGIC;
>
> -- FPGA pin JTAG signals   -- dummy placeholders.
> --    TCK  : IN STD_LOGIC;
> --    TDI  : IN STD_LOGIC;
> --    TDO  : in STD_LOGIC;
> --    TMS  : IN STD_LOGIC;
> --    jtag_or_dummy           : OUT STD_LOGIC;
>
>     -- PUSHBUTTON.UCF SIGNALS
>   button_1                : IN  STD_LOGIC;
>   --PB_UP                   : IN  STD_LOGIC;
>   PB_DOWN                 : IN  STD_LOGIC;
>   button_2                 : IN  STD_LOGIC;
>   PB_RIGHT                : IN  STD_LOGIC
>
>     );
> -----------------------------------------------------------------------
>
> and in the main body of the behavioral I added this pin15_led line:
>
> -----------------------------------------------------------------------
>   led_3     <= clk_4hz;
>   pin15_led     <= not clk_4hz;   -- default state for pin 15 is on.
>
> -----------------------------------------------------------------------
>
> Sincerely,
>
> Jonathan
> Leslie

here's another view of some stuff, looks neat, does it show anything
of the problem?

http://jleslie48.com/fpga_uartjl_01/11jlmod/ccuart01/screencap/screencap26_led3_notworking_pin_15_view.png


Here's the report that is only partially visible:


--------------------------------------------------------------------------------
Release 10.1.03 Trace  (nt)
Copyright (c) 1995-2008 Xilinx, Inc.  All rights reserved.

C:\Xilinx\10.1\ISE\bin\nt\unwrapped\trce.exe -ise
C:/jon/fpga_uartjl_01/r-drigmorn1/Pchu_cc02/ms_d03/ms_d03.ise -
intstyle ise -v
3 -s 4 -xml lprj_TOP lprj_TOP.ncd -o lprj_TOP.twr lprj_TOP.pcf -ucf
C:/jon/fpga_uartjl_01/r-drigmorn1/Pchu_cc02/ms_d03/source/ucf/
DRIGMORN1.ucf


Design file:              lprj_TOP.ncd
Physical constraint file: lprj_TOP.pcf
Device,speed:             xc3s500e,-4 (PRODUCTION 1.27 2008-01-09)
Report level:             verbose report

Environment Variable      Effect
--------------------      ------
NONE                      No environment variables were set
--------------------------------------------------------------------------------

INFO:Timing:2698 - No timing constraints found, doing default
enumeration.
INFO:Timing:2752 - To get complete path coverage, use the
unconstrained paths
   option. All paths that are not constrained will be reported in the
   unconstrained paths section(s) of the report.
INFO:Timing:3339 - The clock-to-out numbers in this timing report are
based on
   a 50 Ohm transmission line loading model.  For the details of this
model,
   and for more information on accounting for different loading
conditions,
   please see the device datasheet.


Data Sheet report:
-----------------
All values displayed in nanoseconds (ns)

Setup/Hold to clock SYSTEM_CLOCK
-------------+------------+------------+------------------+--------+
             |  Setup to  |  Hold to   |                  |  Clock |
Source       | clk (edge) | clk (edge) |Internal Clock(s) |  Phase |
-------------+------------+------------+------------------+--------+
HUART_RX_LINE|    3.122(R)|    0.430(R)|SYSTEM_CLOCK_BUFGP|   0.000|
PB_RIGHT     |    7.180(R)|    0.479(R)|SYSTEM_CLOCK_BUFGP|   0.000|
button_1     |    1.756(R)|   -0.118(R)|SYSTEM_CLOCK_BUFGP|   0.000|
button_2     |    8.952(R)|    0.424(R)|SYSTEM_CLOCK_BUFGP|   0.000|
-------------+------------+------------+------------------+--------+

Clock SYSTEM_CLOCK to Pad
-------------------+------------+------------------+--------+
                   | clk (edge) |                  |  Clock |
Destination        | to PAD     |Internal Clock(s) |  Phase |
-------------------+------------+------------------+--------+
HUART_TX_LINE      |    9.086(R)|SYSTEM_CLOCK_BUFGP|   0.000|
a2mhz_HUART_CK_LINE|    7.697(R)|SYSTEM_CLOCK_BUFGP|   0.000|
a2mhz_HUART_TX_LINE|    6.159(R)|SYSTEM_CLOCK_BUFGP|   0.000|
led_2              |    8.511(R)|SYSTEM_CLOCK_BUFGP|   0.000|
led_3              |    9.097(R)|SYSTEM_CLOCK_BUFGP|   0.000|
led_4              |    9.246(R)|SYSTEM_CLOCK_BUFGP|   0.000|
led_5              |    6.159(R)|SYSTEM_CLOCK_BUFGP|   0.000|
pin15_led          |   11.171(R)|SYSTEM_CLOCK_BUFGP|   0.000|
-------------------+------------+------------------+--------+

Clock to Setup on destination clock SYSTEM_CLOCK
---------------+---------+---------+---------+---------+
               | Src:Rise| Src:Fall| Src:Rise| Src:Fall|
Source Clock   |Dest:Rise|Dest:Rise|Dest:Fall|Dest:Fall|
---------------+---------+---------+---------+---------+
SYSTEM_CLOCK   |   10.491|         |         |         |
---------------+---------+---------+---------+---------+

Analysis completed Mon Apr 20 10:50:56 2009
--------------------------------------------------------------------------------



Peak Memory Usage: 119 MB

Article: 139947
Subject: Re: fpga locks up with slow signal, spartan chip, pin type issues.
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Mon, 20 Apr 2009 17:16:56 +0000 (UTC)
Links: << >>  << T >>  << A >>
jleslie48 <jon@jonathanleslie.com> wrote:
 
> Simply put, if I drive PIN13 or PIN18 (the lhclk types) at 2mhz, no
> problem, but if I drive them at 4hz, they lock up the fpga.

Can you define what you mean by 'lock up'?

That has a specific meaning for CMOS circuits, though it
isn't supposed to happen anymore.  Even so, there might
still be some conditions where you could get the chip
to do it.

-- glen

Article: 139948
Subject: Re: ISE 10.1 installation troubles on windows Vista 32bit
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Mon, 20 Apr 2009 17:17:56 +0000 (UTC)
Links: << >>  << T >>  << A >>
Benjamin Couillard <benjamin.couillard@gmail.com> wrote:
> Hi, I've downloaded ISE 10.1  and I'm now trying to install it on my
> PC. Every time I click on setup.exe, the program crashes and I get an
> error message from Windows.

It would help to tell what the message says.

-- glen

Article: 139949
Subject: Re: fpga locks up with slow signal, spartan chip, pin type issues.
From: jleslie48 <jon@jonathanleslie.com>
Date: Mon, 20 Apr 2009 10:43:43 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 20, 1:16 pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
> jleslie48 <j...@jonathanleslie.com> wrote:
> > Simply put, if I drive PIN13 or PIN18 (the lhclk types) at 2mhz, no
> > problem, but if I drive them at 4hz, they lock up the fpga.
>
> Can you define what you mean by 'lock up'?
>
> That has a specific meaning for CMOS circuits, though it
> isn't supposed to happen anymore.  Even so, there might
> still be some conditions where you could get the chip
> to do it.
>
> -- glen

yes, I am not using any formal definition of "lock up"

the symptoms are this:

without pin15_led driven, the program starts up and on LED_3 I see
a blink code that is driven by:


-----------------------------------------------------------------------------------
 clock_4hz:  PROCESS ( system_clock_used )
 BEGIN
      IF ( rising_edge(system_clock_used)) then
           IF ( clk_4hz_countdown = 0) THEN
                clk_4hz_countdown <= human_clock_count;
                clk_4hz <= NOT clk_4hz;
             else
                clk_4hz_countdown <= clk_4hz_countdown -1;
                End if; -- countdown ife

      END IF;
 END PROCESS clock_4hz;



  led_3     <= clk_4hz;

-------------------------------------------------------------

when I download the code using the jtag device to the blink code on
the led_3 starts, messages appear on my rs232 port, and all is well.

If I add the line:

----------------------------------------------------
  led_3     <= clk_4hz;
  pin15_led     <= not clk_4hz;   -- default state for pin 15 is on.
---------------------------------------------------------

after I download the code using the jtag device, I get a solid light
on the led_3, and none of my messages appear on the RS232 port.


I just went as far as to remove PIN15_led out of the UCF completely,
and let the tools assign it;  it still locks up.  Its not a hardware
to pin issue.

after the "lock up" I am unable to communicate with the FPGA with the
jtag.   Here is the download of the program that locks up the FPGA:

// *** BATCH CMD : Program -p 1
Maximum TCK operating frequency for this device chain: 10000000.
Validating chain...
Boundary-scan chain validated successfully.
'1': Programming device...
PROGRESS_START - Starting Operation.
done.
'1': Reading status register contents...
CRC error                                         :         1
Decryptor security set                            :         1
DCM locked                                        :         1
DCI matched                                       :         1
legacy input error                                :         1
status of GTS_CFG_B                               :         1
status of GWE                                     :         1
status of GHIGH                                   :         1
value of MODE pin M0                              :         1
value of MODE pin M1                              :         1
value of MODE pin M2                              :         1
value of CFG_RDY (INIT_B)                         :         1
DONEIN input from DONE pin                        :         1
IDCODE not validated while trying to write FDRI   :         1
write FDRI issued before or after decrypt operation:         1
Decryptor keys not used in proper sequence        :         1
WARNING:iMPACT:2217 - Error shows in the status register, CRC Error
bit is NOT 0.
INFO:iMPACT:2219 - Status register values:
INFO:iMPACT - 1111 1111 1111 1111 1111 1111 1111 1111
INFO:iMPACT:579 - '1': Completed downloading bit file to device.
INFO:iMPACT - '1': Checking done pin....done.
'1': Programmed successfully.
PROGRESS_END - End Operation.
Elapsed time =      1 sec.
------------------------------------------------------------------------------------------------

Please note the WARNING: iMPACT:2217 - Error shows in the status
register, CRC Error bit is NOT 0.

a subsequent call to 'get device id' yields:

// *** BATCH CMD : ReadIdcode -p 1
INFO:iMPACT:583 - '1': The idcode read from the device does not match
the idcode in the bsdl File.
INFO:iMPACT:1578 - '1':  Device IDCODE :
00001111111111111111111111111111
INFO:iMPACT:1579 - '1': Expected IDCODE:
00000001110000100010000010010011


and a big red 'ReadIDcode failed' block pops up in instead of the nice
blue block saying 'succeeded'




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