Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
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
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. - BrianArticle: 139901
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. - BrianArticle: 139902
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: 139903On 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
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 ) -jgArticle: 139905
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
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. ChrisArticle: 139907
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.orgArticle: 139908
-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: 139909Hey 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
"-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
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: 139912On 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, GregArticle: 139913
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. - BrianArticle: 139914
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) - BrianArticle: 139915
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
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
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 AnttiArticle: 139918
-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: 139919Antti.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.orgArticle: 139920
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.orgArticle: 139921
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
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.orgArticle: 139923
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
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:
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