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
2017JanFebMarApr2017

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 139900

Article: 139900
Subject: Re: fpga locks up with slow signal, spartan chip, pin type issues.
From: Brian Drummond <brian_drummond@btconnect.com>
Date: Sat, 18 Apr 2009 23:43:28 +0100
Links: << >>  << T >>  << A >>
On Sat, 18 Apr 2009 09:56:10 -0700 (PDT), jleslie48 <jon@jonathanleslie.com>
wrote:

>> One question: where are you getting a 4Hz clock?

>> You might be better using a 100MHz clock and a 4Hz enable signal...
>>
>> - Brian
>
>the system has a 40Mhz oscillator and I set a countdown counter to
>10,000,000,
>subtract 1 every oscillator clock and
>at 0 I reset the counter to10,000,000 and:
>
>clk_4hz <= not clk_4hz;

OK so it's internally generated; rise times aren't the problem.
But it may not be identified by the tools as a clock; and that can cause
problems.

Do the tools actually identify it as a clock signal? (Should appear in the
Translate clock report, and in PAR and timing reports)

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.

>
>This ISE 10.1 is very buggy.  I have a whole list of WTF???  and
>situations where I just crashed it.  

Absolutely and you are correct to be wary of upgrading without good cause. I
used ISE7.1 exclusively until changing to 10.1 last year. (10.1 is sufficiently
better to be worth it though)

But though the tools crash, and may not be able to handle a clock they can't
identify, they are pretty solid at delivering reliable results when used within
their limits; e.g. with either technique above.

- Brian



Article: 139901
Subject: Re: Dual-frequency quartz oscillator with a FPGA ?
From: Brian Drummond <brian_drummond@btconnect.com>
Date: Sat, 18 Apr 2009 23:45:25 +0100
Links: << >>  << T >>  << A >>
On Sat, 18 Apr 2009 15:16:04 +0200, whygee <whygee@yg.yg> wrote:

>Hello,
>
>John Adair wrote:
>> On cost the new MEMS oscillators very often compete well with crystals.
>MEMS oscillators are not as widely available as quartz :-/

>Nice board. My issue though is : is your oscillator available
>in 11.2896MHz frequency, and at what cost ? 

Heh, thought as much.
The other crystal is 12.288MHz then.

- Brian

Article: 139902
Subject: Re: Synchronous clocking between Cyclone III and SDRAM
From: nico@puntnl.niks (Nico Coesel)
Date: Sat, 18 Apr 2009 23:00:08 GMT
Links: << >>  << T >>  << A >>
nico@puntnl.niks (Nico Coesel) wrote:

>rickman <gnuarm@gmail.com> wrote:
>
>>On Apr 16, 12:46 pm, n...@puntnl.niks (Nico Coesel) wrote:
>>> rickman <gnu...@gmail.com> wrote:
>>> >On Apr 15, 4:19 pm, jean-francois hasson <jfhas...@club-internet.fr>
>>> >wrote:
>>> >> Hi,
>>>
>>> >> We are looking at interfacing the Cyclone III EP3C40 with an SDRAM at 90
>>> >> MHz. We are considering having the FPGA generate the clock to the
>>> >> interface and find a way to ensure both the sdram and the cyclone III
>>> >> are in phase regarding the clock. We could not find up to now a
>>> >> mechanism that would ensure that both the SDRAM and the cyclone III will
>>> >> have their clock  almost with the same phase relationship over
>>> >> temperature, voltage and process. Could someone provide us with
>>> >> indications regarding the implementation ?
>>> >> Today we thought of using a specific PLL to generate a delayed clock
>>>
>>> >Still, if you need to reduce that, you can have the FPGA generate the
>>> >clock, routing it to the SDRAM with a trace of a known length.  Also
>>> >route a second, identical clock output back to the FPGA with the same
>>> >length trace.  This may require some serpentine coils, but with a
>>> >short route it shouldn't use too much board space.  Then both devices
>>> >will be receiving an external clock that is totally in phase other
>>> >than any skew generated internally in the FPGA.
>>>
>>> Totally useless. You don't need to synchronise the internal FPGA clock
>>> with the SDRAM. Just clock the SDRAM from the FPGA and make sure you
>>> meet setup and hold times on both FPGA and SDRAM. Thats all that
>>> matters.
>>--------------------------------------------------------------
>>
>>Isn't that a little bit like saying to make money in the stock market,
>>you just buy low and sell high?  The point is *how* you meet setup and
>>hold.
>>
>>The OP has said that his timing margins are tight and he has to be
>>concerned with PVT variations.  Sourcing the clock from the FPGA is
>>not a magic bullet.  In fact, I think doing that without routing it
>>back to a clock pin makes it very difficult to even determine the
>>timing of the I/O signals to the output clock, much less assure that
>>it meets requirements of the SDRAM.  FPGAs have clear specs on timing
>>relative to a clock *input*.  I have never seen specs on timing of I/
>>Os relative to a clock *output*.
>
>Its simple: If you source the clock from the FPGA, then the I/O will
>have 0 delay with the clock edges (give or take the skew between
>output buffers). When capturing data you can determine a window in
>which the data from the SDRAM is stable (clock to SDRAM output delay +
>routing delay combined with the setup and hold time. You'll probably
>need 2 clocks with a phase shift (one for sending data to the SDRAM
>and one for capturing data from the SDRAM). A 90 degree shift will
>probably do. If you are unlucky you need a phase shifted clock for the
>SDRAM as well. All these clocks can be produced inside the FPGA.
>
>It goes without saying that the FPGA output and inputs *** must be inside
>the I/O buffer cell. The external SDRAM signals should not be routed
>inside the FPGA otherwise you'll be in a world of pain.

*** should say flipflops. The clock output for de SDRAM should also be
duplicated by a flipflip in the I/O cell. A DDR flipflip is the
easiest way. Otherwise you'll need to double the frequency and make
the clock output flipflop part of a divide by 2 counter.

-- 
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: 139903
Subject: Re: fpga locks up with slow signal, spartan chip, pin type issues.
From: jleslie48 <jon@jonathanleslie.com>
Date: Sat, 18 Apr 2009 16:03:33 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 18, 6:43 pm, Brian Drummond <brian_drumm...@btconnect.com>
wrote:
> On Sat, 18 Apr 2009 09:56:10 -0700 (PDT), jleslie48 <j...@jonathanleslie.com>
> wrote:
>
> >> One question: where are you getting a 4Hz clock?
> >> You might be better using a 100MHz clock and a 4Hz enable signal...
>
> >> - Brian
>
> >the system has a 40Mhz oscillator and I set a countdown counter to
> >10,000,000,
> >subtract 1 every oscillator clock and
> >at 0 I reset the counter to10,000,000 and:
>
> >clk_4hz <= not clk_4hz;
>
> OK so it's internally generated; rise times aren't the problem.
> But it may not be identified by the tools as a clock; and that can cause
> problems.
>
> Do the tools actually identify it as a clock signal? (Should appear in the
> Translate clock report, and in PAR and timing reports)
>
> 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.
>
>
>
> >This ISE 10.1 is very buggy.  I have a whole list of WTF???  and
> >situations where I just crashed it.
>
> Absolutely and you are correct to be wary of upgrading without good cause. I
> used ISE7.1 exclusively until changing to 10.1 last year. (10.1 is sufficiently
> better to be worth it though)
>
> But though the tools crash, and may not be able to handle a clock they can't
> identify, they are pretty solid at delivering reliable results when used within
> their limits; e.g. with either technique above.
>
> - Brian

Brian,

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

All I'm doing is sending it out an output pin to blink an led, whats
the deal with BUFG, etc?  I don't care about mw or even if its
delayed, its just a blinking led on the project box...

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.




Article: 139904
Subject: Re: Dual-frequency quartz oscillator with a FPGA ?
From: -jg <Jim.Granville@gmail.com>
Date: Sat, 18 Apr 2009 16:04:38 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 18, 9:42=A0pm, whygee <why...@yg.yg> wrote:
> I've also found a working example's schematic using a couple of 74HC14 ga=
tes,
> two 1M resistors and the usual couple of capacitors...
> and I wonder again why a couple of FPGA pins wouldn't work :-/

You can certainly make a FPGA oscillate.
The problem is getting reliable, desired frequency output!.
A common issue with such circuits is 'edge fur' which is high speed
transistion oscillations, near the logic thresholds. Sometimes not
directly visible on a scope, but will show up as double-clocking.


> > so you may prefer to run them all the
> > time, and switch inside the FPGA.
>
> This means continuous power draw...
> even a few mA can matter, not for the proto but in the end... :-/
> I'll probably switch to the Igloo family later, too.
>
> It looks like i'll have to choose one fixed frequency
> and give up the others, or i'll have to end up with 3 or 4
> Xtal operating =A0simultaneously...
> Fortunately, FPGAs have integrated PLLs today.

The cheapest is obviously to use the PLL if you can, but if power
matters, then you also want to avoid a FPGA type oscillator, as they
do
not specify the transistion currents. (Icc vs Vi)

xxU04 gates are a mainstream part, and if you use one inverter as the
oscillator, and then cascade a couple more to square-up the edges, so
you are not driving
the FPGA with a sine-wave.

You then choose a logic family, and Vcc, to give the Icc you need.
10-12MHz is lowish, so you should be able to get lower Icc in a custom
design than from a Module.
You can supply the Vcc from a FPGA port pin, to enable
the oscillator (add a RC to adjust Icc )

-jg

Article: 139905
Subject: Re: fpga locks up with slow signal, spartan chip, pin type issues.
From: jleslie48 <jon@jonathanleslie.com>
Date: Sat, 18 Apr 2009 16:27:06 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 18, 6:43 pm, Brian Drummond <brian_drumm...@btconnect.com>
wrote:
>
> But though the tools crash, and may not be able to handle a clock they can't
> identify, they are pretty solid at delivering reliable results when used within
> their limits; e.g. with either technique above.
>
> - Brian

this has me very scared.  I know for a fact at one point I put in a
pin13 and then removed it, but the build still had references to pin13
(the map failed and the pinout report showed pin13)   It wasn't until
a made a whole new project that I eliminated the reference to pin13.
After I made my new project, I found out about the clean up thing
under projects and my old project was able to then build, but at that
point PIN15 was broken.

The point is, I get different results based on previous compile
situations and previous results of the software. this is really bad.
It means I can't reliably make a burn image, or possibly have to make
a new project for each SIG/ reboot the computer between builds (I also
notice that even if I shutdown the software, task manager has plenty
of ISE images still in the background)


Article: 139906
Subject: Re: source for Spartan 3E chips
From: Chris Abele <ccabele@yahoo.com>
Date: Sat, 18 Apr 2009 19:43:13 -0400
Links: << >>  << T >>  << A >>
Alex Freed wrote:
> 
> All,
> 
> I need 30 to 50 XC3S250E chips. The obvious source is
> DigiKey but they only have quantity one price.
> Is there a better place to buy?
> 
> -Alex.

Have a look at Avnet (http://em.avnet.com).  Depending on the package 
and grade it looks like their single piece pricing is slightly lower 
than Digikey, and I expect you can easily get a better price quoted for 
that quantity.

The web site may not be quite as easy as Digikey, but when I've talked 
to a person I've gotten good service and better prices.

Chris

Article: 139907
Subject: Re: Dual-frequency quartz oscillator with a FPGA ?
From: whygee <whygee@yg.yg>
Date: Sun, 19 Apr 2009 03:08:39 +0200
Links: << >>  << T >>  << A >>
Brian Drummond wrote:
> On Sat, 18 Apr 2009 15:16:04 +0200, whygee <whygee@yg.yg> wrote:
>> Nice board. My issue though is : is your oscillator available
>> in 11.2896MHz frequency, and at what cost ? 
> Heh, thought as much.
> The other crystal is 12.288MHz then.
good guess :-)
Now if you have a smart idea about how to switch between them
without a glitch... Oh well, when i'll add a video output,
i'll need yet another oscillator with another frequency :-/

I'm waiting for ecliptek's answer about a sample request.
However, I wonder how i'll be able to solder it in
the first prototypes (i'm not at ease with the hot air gun yet).
I'll have to measure how much it consumes, too. So many questions...

> - Brian
yg

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

Article: 139908
Subject: Re: Dual-frequency quartz oscillator with a FPGA ?
From: whygee <whygee@yg.yg>
Date: Sun, 19 Apr 2009 03:48:18 +0200
Links: << >>  << T >>  << A >>
-jg wrote:
> On Apr 18, 9:42 pm, whygee <why...@yg.yg> wrote:
>> I've also found a working example's schematic using a couple of 74HC14 gates,
>> two 1M resistors and the usual couple of capacitors...
>> and I wonder again why a couple of FPGA pins wouldn't work :-/
> You can certainly make a FPGA oscillate.
I'm sure, too ;-)

Oh well, what if I tried now and checked the different frequencies
that it can generate ? I'm feeling hacky now... The only limit is that
I have no frequency meter above 20MHz, which is well below what
is theoretically possible...

> The problem is getting reliable, desired frequency output!.
> A common issue with such circuits is 'edge fur' which is high speed
> transistion oscillations, near the logic thresholds. Sometimes not
> directly visible on a scope, but will show up as double-clocking.
I imagine that the pin capacitances will smooth it a bit ?

Oh, if I understand correctly, if it's too smooth,
it can create problems... But in FPGA-land, that should not
be impossible ?...


>> It looks like i'll have to choose one fixed frequency
>> and give up the others, or i'll have to end up with 3 or 4
>> Xtal operating  simultaneously...
>> Fortunately, FPGAs have integrated PLLs today.
> The cheapest is obviously to use the PLL if you can, but if power
> matters, then you also want to avoid a FPGA type oscillator, as they
> do not specify the transistion currents. (Icc vs Vi)

An oscillator circuit that I have found uses a single
HC14 (schmitt trigger inverter) gate as oscillator.
The output goes to another digital input, as well as a 1M resistor,
whose other side is tied to a grounded capacitor (100pF), and
the crystal with a 1M resistor in parallel (both go to the HC14 input).

  (sorry, i can't find the original location of the PDF)

With this system, the current that goes through 1M must be very small...
Also, concerning your previous point about spurious signals
("edge fur"), I see that the 1M + 100pF network is a low-pass
that should reduce the impact of the "fur"...

Unfortunately, the Actel chips I currently use don't have Schmitt triggers.
However, the latest / newest Actel chips have, including some Igloo,
so the idea may resurface later in the design/development, so I can fall back to
"traditional" methods now. I'll be careful to select ST-capable parts later.

> xxU04 gates are a mainstream part, and if you use one inverter as the
> oscillator, and then cascade a couple more to square-up the edges, so
> you are not driving the FPGA with a sine-wave.
Shouldn't one inverter be enough to square the edges ?
As I re-looked at the 74LVC1GX04 (I had a few samples already)
I remarked that there are 3 inverter gates, this looks like
overkill to me...

> You then choose a logic family, and Vcc, to give the Icc you need.
> 10-12MHz is lowish,
it's on purpose.

> so you should be able to get lower Icc in a custom
> design than from a Module.
This shouldn't be too difficult to verify.

> You can supply the Vcc from a FPGA port pin, to enable
> the oscillator (add a RC to adjust Icc )
I would even use a LC network...

But what about the "enable" input of the canned oscillators ?
Normally, the osc's output is tristated so (taking into account
various capacitances) two oscs should be able to share a single
FPGA input pin (then 2 output pins control the enable pins)...


regards,
> -jg
yg

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

Article: 139909
Subject: Atari VCS 2600 FPGA Cartridge
From: Darcio Prestes <darcioprestes@gmail.com>
Date: Sat, 18 Apr 2009 20:34:34 -0700 (PDT)
Links: << >>  << T >>  << A >>
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.

Article: 139910
Subject: Re: Looking for a low-cost development kit
From: "Johnson L" <gpsabove@yahoo.com>
Date: Sat, 18 Apr 2009 21:35:21 -0600
Links: << >>  << T >>  << A >>

"-jg" <Jim.Granville@gmail.com> wrote in message 
news:27eff70c-5d90-46de-9ce0-f9515ae9bc27@b6g2000pre.googlegroups.com...
On Mar 23, 5:08 pm, "Johnson L" <gpsab...@yahoo.com> wrote:
> For my hobby work, I am looking for a low-cost development kit to
> develope a simple embedded system. This system will measure the 
> temperature
> and heart beat rate, compare them with a predefined table which implements
> some health-care knowledge, then provide some useful information. This
> development kit should be low-cost, support C programming, debugging, 
> better
> with JTAG or other on-site debugging. It should support at least one type 
> of
> popular microprocessors, or a mainstream FPGA,
> and easy to use. Could anybody recommend me some? Thank you in advance.
>
> Johnson

Are you sure that needs a FPGA ?
Heart rates are very low, so you might be better to work from a Size/
Power viewpoint.
ie what display will this have, user controls, and how will it be
powered ?

There are small uC around, that will power off a single-cell. SiLabs
C8051F9xx
and Atmel have a sub 1V AVR member (less code space than SiLabs).

Both have free tools and good Debug systems.

-jg

Right. I don't think my application needs an FPGA. I am just looking for any 
"can-do" low-cost solutions and comapre the costs.




Article: 139911
Subject: Re: Dual-frequency quartz oscillator with a FPGA ?
From: -jg <Jim.Granville@gmail.com>
Date: Sat, 18 Apr 2009 21:18:13 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 19, 1:48=A0pm, whygee <why...@yg.yg> wrote:
>
> Oh well, what if I tried now and checked the different frequencies
> that it can generate ? I'm feeling hacky now... The only limit is that
> I have no frequency meter above 20MHz, which is well below what
> is theoretically possible...

Set up some simple dividers and scope the outputs, and Freq count,
and look for phase jitter, and erratic jumps...
Don't try and look directly for the edge oscillations.

> I imagine that the pin capacitances will smooth it a bit ?
>
> Oh, if I understand correctly, if it's too smooth,
> it can create problems... But in FPGA-land, that should not
> be impossible ?...

In extreme cases, these transistion oscillations are VERY high, and
I've
seen them disturb UNRELATED logic, due to common mode inductive
effects.

Such things are outside the testing realms of the IC vendors :)


> An oscillator circuit that I have found uses a single
> HC14 (schmitt trigger inverter) gate as oscillator.
> The output goes to another digital input, as well as a 1M resistor,
> whose other side is tied to a grounded capacitor (100pF), and
> the crystal with a 1M resistor in parallel (both go to the HC14 input).
>
> =A0 (sorry, i can't find the original location of the PDF)
>
> With this system, the current that goes through 1M must be very small...
> Also, concerning your previous point about spurious signals
> ("edge fur"), I see that the 1M + 100pF network is a low-pass
> that should reduce the impact of the "fur"...

Ah, yes Schmitt-assisted oscillators shift the problem :)

 They remove the  'fur' issue, but now you are never sure if the
Schmitt RC-fb, or the Xtal is locking. (unplug the Xtal, and they
usually still oscillate!)

 I have had promising looking bench results, that set up a RC schmitt
lower than
the Xtal, and then hope that the Xtal rings enough, to build amplitude
and lock the schmitt freq. We never brave enough to actually ship a
product using this :)

 Where a Schmitt Osc _does_ work very well, is in LC mode, so if you
can get Schmitt pin option, (and can tolerate LC precision!), then a
SMD
inductor is by far the lowest cost clocking option.

> Shouldn't one inverter be enough to square the edges ?
> As I re-looked at the 74LVC1GX04 (I had a few samples already)
> I remarked that there are 3 inverter gates, this looks like
> overkill to me...

If you are doing this properly, a schmitt buffer is better, and you
chose
a schmitt with lowest transistion currents (ie lowest Vcc when sine-
driven)

You may trade-off to a single-component, but the unbuffered gates have
low
gain, so a single stage is only 'squarish'.
I like the 3GU04, as they come in many logic families.

It is surprising the tiny logic vendors DON'T make 2G=3D(1GU04+1G17)
pairing
as that would cover many clocking choices: Xtal/LC/RC 2 Pin & 3 Pin.
I guess they are stuck in legacy-mode...

> > You can supply the Vcc from a FPGA port pin, to enable
> > the oscillator (add a RC to adjust Icc )
>
> I would even use a LC network...

The R drops voltage, and almost runs the part in constant current mode
oscillation.
You can drive Logic short of the rails, and save osc power.
You  do need to watch the IP Cell transition current, but usually
around 1V on
the PFET and 0.6V on the Nfet is OK.

>
> But what about the "enable" input of the canned oscillators ?
> Normally, the osc's output is tristated so (taking into account
> various capacitances) two oscs should be able to share a single
> FPGA input pin (then 2 output pins control the enable pins)...

Yes, but what is clocking the FPGA, when both are off  ?  ;)

-jg

Article: 139912
Subject: Re: Atari VCS 2600 FPGA Cartridge
From: Gregory Estrade <gregory.estrade@gmail.com>
Date: Sun, 19 Apr 2009 00:38:57 -0700 (PDT)
Links: << >>  << T >>  << A >>
On 19 avr, 05:34, Darcio Prestes <darciopres...@gmail.com> 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.

I've done something close to what you're looking for, I guess.
See http://torlus.com/index.php?2008/08/25/219-2600-monocart-assembled-and-working-sort-of
The idea is to use non-volatile RAM, and program it via USB with the
help of a small MCU.
Bankswitching is performed by a small CPLD.
Unfortunately, it doesn't work with the NVRAM chip I've chosen.Maybe
I'll work again on it later, but well, I can't guarantee that.
Feel free to ask some questions if you're interested in it.

You may also have a look at AtariAge's forum, and search for
"Chimera", a full-featured flash cart project using a FPGA, much more
advanced than what I've done so far on this subject.

Hope this helps,
Greg

Article: 139913
Subject: Re: Dual-frequency quartz oscillator with a FPGA ?
From: Brian Drummond <brian_drummond@btconnect.com>
Date: Sun, 19 Apr 2009 13:37:38 +0100
Links: << >>  << T >>  << A >>
On Sun, 19 Apr 2009 03:08:39 +0200, whygee <whygee@yg.yg> wrote:

>Brian Drummond wrote:
>> On Sat, 18 Apr 2009 15:16:04 +0200, whygee <whygee@yg.yg> wrote:
>>> Nice board. My issue though is : is your oscillator available
>>> in 11.2896MHz frequency, and at what cost ? 
>> Heh, thought as much.
>> The other crystal is 12.288MHz then.
>good guess :-)
>Now if you have a smart idea about how to switch between them
>without a glitch... Oh well, when i'll add a video output,
>i'll need yet another oscillator with another frequency :-/

I would (a) use external oscillators, as others have suggested, for the same
reasons. I'd be happy with either modules for simplicity, or something amenable
to oscillator use, like 74HCU04 in some flavour, if economics demand it.

If you need a glitch free switch you need both oscillators running at once, and
something like a BUFGMUX or one of Peter Alfke's clever little circuits to
switch between them.

If power or radiated noise was important I'd consider killing the unused osc (if
it's a 74HCU04, connect the input to a tristated FPGA output, or use a diode
switch to reduce stray C), and a state machine to start it; confirm it had
restarted; and then switch over. 

Last time I did it I could let the system go silent for a second when switching;
I used diode switches between two crystals on an oscillator in a rather nice
Philips chip (SAA7274, probably no longer made - that other brand didn't seem to
like crystals attached)

Time before that was pure 74LS series...

Incidentally I found I could pull the crystal over about +/-150ppm, and there
was measurably less phase noise (jitter by another name) from a reputable brand
of crystal.

If you're interested to talk more, email...

>I'm waiting for ecliptek's answer about a sample request.
>However, I wonder how i'll be able to solder it in
>the first prototypes (i'm not at ease with the hot air gun yet).
>I'll have to measure how much it consumes, too. So many questions...

Heh. Kapton tape a thermocouple to the top of a board and check out the
temperature profiles you can get with a 2kw Black&Decker hot air paint stripper
applied underneath...

I've mounted these connectors this way (note the power pins down the middle) 
http://www.samtec.com/technical_specifications/overview.aspx?series=QTH
but haven't tried the next logical step of BGAs yet.

- Brian


Article: 139914
Subject: Re: fpga locks up with slow signal, spartan chip, pin type issues.
From: Brian Drummond <brian_drummond@btconnect.com>
Date: Sun, 19 Apr 2009 14:06:04 +0100
Links: << >>  << T >>  << A >>
On Sat, 18 Apr 2009 16:03:33 -0700 (PDT), jleslie48 <jon@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

Article: 139915
Subject: Re: fpga locks up with slow signal, spartan chip, pin type issues.
From: jleslie48 <jon@jonathanleslie.com>
Date: Sun, 19 Apr 2009 07:10:44 -0700 (PDT)
Links: << >>  << T >>  << A >>
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.


Article: 139916
Subject: Re: Atari VCS 2600 FPGA Cartridge
From: Darcio Prestes <darcioprestes@gmail.com>
Date: Sun, 19 Apr 2009 10:09:23 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 19, 4:38=A0am, Gregory Estrade <gregory.estr...@gmail.com> wrote:
> On 19 avr, 05:34, Darcio Prestes <darciopres...@gmail.com> 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.
>
> I've done something close to what you're looking for, I guess.
> Seehttp://torlus.com/index.php?2008/08/25/219-2600-monocart-assembled-an.=
..
> The idea is to use non-volatile RAM, and program it via USB with the
> help of a small MCU.
> Bankswitching is performed by a small CPLD.
> Unfortunately, it doesn't work with the NVRAM chip I've chosen.Maybe
> I'll work again on it later, but well, I can't guarantee that.
> Feel free to ask some questions if you're interested in it.
>
> You may also have a look at AtariAge's forum, and search for
> "Chimera", a full-featured flash cart project using a FPGA, much more
> advanced than what I've done so far on this subject.
>
> Hope this helps,
> Greg

   Hi Greg. I checked out your project. Excellent work. I first
realized putting a microcontroller connected direct on 2600 cartridge
slot and writing some code to make some sort of DMA between the
console and the uC flash memory. This actualy have been done by the
folks at Atari Age in Harmony Cart. The site even sells a cart kit
using EPROM and a GAL to handle the additional equations of
bankswitching when needed.

   What I'm looking for is to replace all that circuitry with a single
combinational chip. I know that prices of progammable logic have been
dramaticaly decreased during the last years. So I imagined it could be
$ viable to use that kind of device to achieve the goal. Of course I
can use a huge CPLD with thousands of "cells" to accomplish the task
but I would like to hear from you here (once I don't have enough
practical experience with programmable logic) what device should I
consider. The optimal requirements as I stated before are:

A) Space to store a 32 kb x 8 ROM file;
B) Additional space for bankswitching logic;
C) 5 Volts;
D) Non volatile.

I hope to get some directions :)











Article: 139917
Subject: Re: Atari VCS 2600 FPGA Cartridge
From: "Antti.Lukats@googlemail.com" <Antti.Lukats@googlemail.com>
Date: Sun, 19 Apr 2009 10:33:45 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 19, 8:09=A0pm, Darcio Prestes <darciopres...@gmail.com> wrote:
> On Apr 19, 4:38=A0am, Gregory Estrade <gregory.estr...@gmail.com> wrote:
>
>
>
>
>
> > On 19 avr, 05:34, Darcio Prestes <darciopres...@gmail.com> 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 singl=
e
> > > 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 (simpl=
e
> > > equations). My question is: which manufacturer, family and/or device
> > > should I look for? Thanks for sharing your valuable experience with m=
y
> > > hobby project.
>
> > I've done something close to what you're looking for, I guess.
> > Seehttp://torlus.com/index.php?2008/08/25/219-2600-monocart-assembled-a=
n...
> > The idea is to use non-volatile RAM, and program it via USB with the
> > help of a small MCU.
> > Bankswitching is performed by a small CPLD.
> > Unfortunately, it doesn't work with the NVRAM chip I've chosen.Maybe
> > I'll work again on it later, but well, I can't guarantee that.
> > Feel free to ask some questions if you're interested in it.
>
> > You may also have a look at AtariAge's forum, and search for
> > "Chimera", a full-featured flash cart project using a FPGA, much more
> > advanced than what I've done so far on this subject.
>
> > Hope this helps,
> > Greg
>
> =A0 =A0Hi Greg. I checked out your project. Excellent work. I first
> realized putting a microcontroller connected direct on 2600 cartridge
> slot and writing some code to make some sort of DMA between the
> console and the uC flash memory. This actualy have been done by the
> folks at Atari Age in Harmony Cart. The site even sells a cart kit
> using EPROM and a GAL to handle the additional equations of
> bankswitching when needed.
>
> =A0 =A0What I'm looking for is to replace all that circuitry with a singl=
e
> combinational chip. I know that prices of progammable logic have been
> dramaticaly decreased during the last years. So I imagined it could be
> $ viable to use that kind of device to achieve the goal. Of course I
> can use a huge CPLD with thousands of "cells" to accomplish the task
> but I would like to hear from you here (once I don't have enough
> practical experience with programmable logic) what device should I
> consider. The optimal requirements as I stated before are:
>
> A) Space to store a 32 kb x 8 ROM file;
> B) Additional space for bankswitching logic;
> C) 5 Volts;
> D) Non volatile.
>
> I hope to get some directions :)- Hide quoted text -
>
> - Show quoted text -

The ONLY part that satisfies ALL requirements is: ice65L16 from
SiliconBlue

this mainly because of 5V requirement
finding device with 32k ram is easy, but it will not be 5V tolerant
so you need to compromise on something

Antti



Article: 139918
Subject: Re: Dual-frequency quartz oscillator with a FPGA ?
From: whygee <whygee@yg.yg>
Date: Sun, 19 Apr 2009 20:13:37 +0200
Links: << >>  << T >>  << A >>
-jg wrote:
<an excellent post that I'm not able to fully digest at this time of writing)

>> But what about the "enable" input of the canned oscillators ?
>> Normally, the osc's output is tristated so (taking into account
>> various capacitances) two oscs should be able to share a single
>> FPGA input pin (then 2 output pins control the enable pins)...
> Yes, but what is clocking the FPGA, when both are off  ?  ;)
that's simple (TM) :
the FPGA is an Actel Flash-based part so the configuration is "live at power-up"
(as the glossy marketing sheets write). The /RESET pin is held down
up to 200ms after the 3.3V rail has settled (with a TPS3908 or equivalent),
so the quartz have enough time to start oscillating.
The "osc_sels" pins are held down by an internal D-FF with a reset input
(with output logic saying that osc_sel1 <= not osc_sel2 ).
During "normal operation", the internal logic can "write" a specific data
('0' or '1') to the DFF (which switches the source clock).

Note that in the case of dual-source clocking in Actel ProASIC3,
the source should come to one pin only (the pin can be selected
from a certain set but all clocks should go there).
It is better to not implement a MUX in the logic fabric
because this could increase the noise, and the I/O are "wired"
(with EEPROM cells) to go to the logic fabric or to the PLL input
(where the clock signal belongs). The "output enable" provided by
canned oscillators is very useful then. I should add small series
resistors at the osc outputs (100 Ohm ?) in case they get accidentally
asserted at the same time (during transition ?).
Also, I'll add pull-down resistors to prevent accidental assertion
of the oscillators during power-up/down, because the FPGA tristates I/Os
when all power supplies are not nominal so no valid
output would be available during some ms...

Well, a single oscillator looks so simple in comparison...
<think></think>
I have maybe found a solution...


Off-topic : what FPGA family provides an internally-generated /RESET signal
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-whatever 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

Article: 139919
Subject: Re: Atari VCS 2600 FPGA Cartridge
From: whygee <whygee@yg.yg>
Date: Sun, 19 Apr 2009 20:39:09 +0200
Links: << >>  << T >>  << A >>
Antti.Lukats@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

Article: 139920
Subject: PLL ratios (was Re: Dual-frequency quartz oscillator with a FPGA
From: whygee <whygee@yg.yg>
Date: Sun, 19 Apr 2009 21:35:12 +0200
Links: << >>  << T >>  << A >>
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 :-)
>> Now if you have a smart idea about how to switch between them
>> without a glitch... Oh well, when i'll add a video output,
>> i'll need yet another oscillator with another frequency :-/
> I would (a) use external oscillators, as others have suggested, for the same
> reasons. I'd be happy with either modules for simplicity, or something amenable
> to oscillator use, like 74HCU04 in some flavour, if economics demand it.
Now, for me it makes no difference, only the availability of the required
frequency matters.

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.
This can be done by dynamically changing the divider ratios.

The Actel PLL has only 7-bit ratios, that is too short
(128<147). There are additional 5-bit dividers that can post-divide.
Now I have to find a frequency in the 5-15 MHz range that satisfies
all these division needs and PLL osc. ranges.

Oh, and this frequency should be available and not too expensive :-/
And when I multiply 256*300*147*160, I get a frequency of more than 1.8GHz
and the PLL's VCO ranges from 24 to 350MHz :-/
Maybe I'll be able to solve this with 2 PLLs or another trick ?

> If you need a glitch free switch you need both oscillators running at once, and
> something like a BUFGMUX or one of Peter Alfke's clever little circuits to
> switch between them.
I've seen this some time ago, and used it already :
http://www.design-reuse.com/articles/5827/techniques-to-make-clock-switching-glitchfree.html

> Incidentally I found I could pull the crystal over about +/-150ppm, and there
> was measurably less phase noise (jitter by another name) from a reputable brand
> of crystal.
> If you're interested to talk more, email...
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...

>> I'm waiting for ecliptek's answer about a sample request.
>> However, I wonder how i'll be able to solder it in
>> the first prototypes (i'm not at ease with the hot air gun yet).
> Heh. Kapton tape a thermocouple to the top of a board and check out the
> temperature profiles you can get with a 2kw Black&Decker hot air paint stripper
> applied underneath...
Oh, so that tape I recently purchased will be more useful than I thought :-)
The thermocouple and the paint stripper are also already available.

regards,
> - Brian
yg

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

Article: 139921
Subject: Re: Atari VCS 2600 FPGA Cartridge
From: Darcio Prestes <darcioprestes@gmail.com>
Date: Sun, 19 Apr 2009 12:53:15 -0700 (PDT)
Links: << >>  << T >>  << A >>
On 19 abr, 14:33, "Antti.Luk...@googlemail.com"
<Antti.Luk...@googlemail.com> wrote:
> On Apr 19, 8:09=A0pm, Darcio Prestes <darciopres...@gmail.com> wrote:
>
>
>
> > On Apr 19, 4:38=A0am, Gregory Estrade <gregory.estr...@gmail.com> wrote=
:
>
> > > On 19 avr, 05:34, Darcio Prestes <darciopres...@gmail.com> 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 sin=
gle
> > > > 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 (sim=
ple
> > > > equations). My question is: which manufacturer, family and/or devic=
e
> > > > should I look for? Thanks for sharing your valuable experience with=
 my
> > > > hobby project.
>
> > > I've done something close to what you're looking for, I guess.
> > > Seehttp://torlus.com/index.php?2008/08/25/219-2600-monocart-assembled=
-an...
> > > The idea is to use non-volatile RAM, and program it via USB with the
> > > help of a small MCU.
> > > Bankswitching is performed by a small CPLD.
> > > Unfortunately, it doesn't work with the NVRAM chip I've chosen.Maybe
> > > I'll work again on it later, but well, I can't guarantee that.
> > > Feel free to ask some questions if you're interested in it.
>
> > > You may also have a look at AtariAge's forum, and search for
> > > "Chimera", a full-featured flash cart project using a FPGA, much more
> > > advanced than what I've done so far on this subject.
>
> > > Hope this helps,
> > > Greg
>
> > =A0 =A0Hi Greg. I checked out your project. Excellent work. I first
> > realized putting a microcontroller connected direct on 2600 cartridge
> > slot and writing some code to make some sort of DMA between the
> > console and the uC flash memory. This actualy have been done by the
> > folks at Atari Age in Harmony Cart. The site even sells a cart kit
> > using EPROM and a GAL to handle the additional equations of
> > bankswitching when needed.
>
> > =A0 =A0What I'm looking for is to replace all that circuitry with a sin=
gle
> > combinational chip. I know that prices of progammable logic have been
> > dramaticaly decreased during the last years. So I imagined it could be
> > $ viable to use that kind of device to achieve the goal. Of course I
> > can use a huge CPLD with thousands of "cells" to accomplish the task
> > but I would like to hear from you here (once I don't have enough
> > practical experience with programmable logic) what device should I
> > consider. The optimal requirements as I stated before are:
>
> > A) Space to store a 32 kb x 8 ROM file;
> > B) Additional space for bankswitching logic;
> > C) 5 Volts;
> > D) Non volatile.
>
> > I hope to get some directions :)- Hide quoted text -
>
> > - Show quoted text -
>
> The ONLY part that satisfies ALL requirements is: ice65L16 from
> SiliconBlue
>
> this mainly because of 5V requirement
> finding device with 32k ram is easy, but it will not be 5V tolerant
> so you need to compromise on something
>
> Antti

Thanks for replying. It's possible to use level translation so we can
drop the 5V requirement. Our range is now broader.

Article: 139922
Subject: Re: Atari VCS 2600 FPGA Cartridge
From: whygee <whygee@yg.yg>
Date: Sun, 19 Apr 2009 21:58:46 +0200
Links: << >>  << T >>  << A >>
Darcio Prestes wrote:
> 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. 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.

I think that the ice65L16 is going to take too much time to appear on
the market and mature, for such a "little project".
Level translation buffers are a good solution, given the slow cycle
time (IIRC) of the VC2600 (someone asked me to design a cartridge
some years ago, I didn't go far but remember a few things).
I think that something like the sn74lvcc4245
or sn74lvcc3245 (depending on what circuit controls the bus direction)
is suitable (it works well on an ISA bus).

While we're at it, the games could be stored in a small serial flash
such as http://it.farnell.com/jsp/search/productdetail.jsp?sku=1455042
or similar parts. If you're going to use a huge FPGA (since you need a lot
of SRAM blocks), then there will be a lot a free logic blocks,
so a few can be used to do the SPI protocol interface.

Now, my greedy side tells me that a fast SRAM (15ns) of 64K*8
does cost only a few $ (and I just got larger chips for even cheaper).
Look at old Pentium motherboards, they used to have 8 chips of 32K bytes
(some have 64KB). So you can spare the huge, expensive and underused FPGA
that will probably come with a large and/or BGA package.

happy hacking,
yg

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

Article: 139923
Subject: Re: Atari VCS 2600 FPGA Cartridge
From: Darcio Prestes <darcioprestes@gmail.com>
Date: Sun, 19 Apr 2009 13:02: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. 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: 139924
Subject: Re: Atari VCS 2600 FPGA Cartridge
From: whygee <whygee@yg.yg>
Date: Sun, 19 Apr 2009 22:10:11 +0200
Links: << >>  << T >>  << A >>
whygee wrote:
> I think that the ice65L16 is going to take too much time to appear on
> the market and mature, for such a "little project".
However, when it becomes ready, and if a suitable package
(like QFP100, not BGA or QFN) is available, this would be
perfect : one could store 4 different games without effort,
because the chip can read 4 off-chip images (including SRAM contents)
depending on the state of 2 inputs pins. But how much will it cost ?

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



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
2017JanFebMarApr2017

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