Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search

Messages from 71300

Article: 71300
Subject: Re: FPGA to PCI Bus Interface
From: hmurray@suespammers.org (Hal Murray)
Date: Wed, 14 Jul 2004 02:38:37 -0500
Links: << >>  << T >>  << A >>
>Or something else goes wrong, plus the cost of the PROM is comparable to the
>cost of a PCI bridge...

I wasn't trying to push for or against the PLX type approach.  Just
pointing out that there are ways to change the configuration when
your design gets loaded from a PROM.  Board space or layour or something
else might make the PLX/bridge unattractive.

Another potential disadvantage of the PLX/Bridge is a few more clock
cycles if you just want to do a simple read.  (Writes can be pipelined.)

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


Article: 71301
Subject: Re: FSM in illegal state (conclusion)
From: hmurray@suespammers.org (Hal Murray)
Date: Wed, 14 Jul 2004 03:02:26 -0500
Links: << >>  << T >>  << A >>
> A Xilinx App Note was suggested. Here is an attempt.
> Let me know if it makes sense.

I think your summary was good, but I also think I understand
the problem.  (I got bit years ago.  It's one of my hot buttons.)
The real question is how to get this problem on every designer's
mental checklist so that they are thinking about it at the right time.

My request for an app-note was actually misleading.  I should have
asked for support in the tools.  They should be smart enough to
complain about state machines that don't have some mechanism to
come out of reset cleanly.

What do ASIC/CPU designers do?  My guess is that they don't
have a global-reset so their version of this problem is a bit
different.

This seems like a good open source project.  Or maybe a masters
thesis.  All the info is in the EDIF/netlist.  Right?

Is the GSR in the netlist?  Or would a tool have to add it
by magic?


Ken's TechXclusive article is good.  Thanks.

It actually doesn't cover the mechanism I think I would try to
use.  He holds the whole state machine in reset.  That chews up
local resources.  Many FSMs stay in the idle state until they get
poked, for example a memory controller waits for a read or
write request.  I was thinking of blocking that sort of
request signal.

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


Article: 71302
Subject: Re: WinCUPL state machine for 16V8
From: Pete Harrison <peter_harrison@ntlworld.com>
Date: Wed, 14 Jul 2004 08:10:16 GMT
Links: << >>  << T >>  << A >>


Rich Webb wrote:
> On Wed, 14 Jul 2004 00:29:38 GMT, Pete Harrison
> <peter_harrison@ntlworld.com> wrote:
> 
> 
>>I guess the combination of Wincupl and a 16V8 will be pretty much steam 
>>technology for most of you but it is a real mystery to me.
> 
> 
> On the other hand, a 16V8 or 22V10 is often the perfect size.

Indeed. I am sometimes frusrated by people expounding the virtues of 
this or that CPLD etc when you can only get them in SMT multipin 
packages. Not much good if you just want an address decoder.


> 
> You have your registers on four of the output pins. Route those values
> combinatorially to the remaining four outputs so that, for example,
> (if ENA reset is "motors off"; flip to !ENA if not so).
> 
> pin [16..19] = Y[3..0];
> ...
> Y0 = ENA & Q0;
> Y1 = ENA & Q1;
> Y2 = ENA & Q2;
> Y3 = ENA & Q3;
> 
> (Is there a shorthand notation for that? My CUPL is a bit rusty.)
> 
> If you're already wired to come off of 12..15, move the registered
> outputs up a nibble, of course.
> 
> A disadvantage (or maybe an advantage) is that the registers don't
> change value if only ENA changes, so going back to the active state will
> restore the stepper bits to where they were (if no clk changes...).
> 

This is an excellent advantage in this case as it may make it more 
likely that the steppers will start up again without a large jump to a 
new detent.

I have just tried this and it works a treat. Luckily, the other outputs 
are all free in this circuit.

I also tried the shortcut:

Pin [12..15]  = [Q3..0]; /** **/
Pin [16..19] = [Y3..0];

field output = [Q3..0];
field stpctrl = [Y3..0];

/* state machine stuff */

output = ENA & stpctrl;

Which works just fine

Thank you so much. I have no idea where you are so you will have to make 
do with a couple of virtual beers (or whatever you prefer)

Pete


Article: 71303
Subject: Re: extending a signal pulse
From: "Guy Eschemann" <guy.eschemann@t-online.de>
Date: 14 Jul 2004 01:50:18 -0700
Links: << >>  << T >>  << A >>
You could use a SRL16/DFF (with clock-enable and synchronous clear)
combination for this. The input pulse - which is high for one clock
cycle -sets the FF output, and a delayed version of this pulse clears
it after a number of clock cycles. The depth of the SLR16 sets the
length of the output pulse. Note that the output pulse is delayed by
one clock cycle with respect to the input pulse.
_______
|       |
+--| SRL16 |------+
|  |_______|      |
|                 |
|   ______        |
|  |      |       |
short pulse -----+--|CE   Q|----------- long pulse
|      |       |
1--|D     |       |
|      |       |
CLK--|>     |       |
|      |       |
+--|CLR   |       |
|  |______|       |
|                 |
+-----------------+

Regards,
Guy.

Johan Bernsp=E5ng wrote:
> Hi all,
>
> What would be the optimal way, in terms of device utilization and
> functionality, to exstend the length of the time a signal is asserted

> from one clock cycle to four clock cycles. I.e.
> [pseduo code:]
> if signal_a is asserted then
> 	signal_b is asserted for four clk;
>
> Is it possible to accomplish the function by utilizing an SRL16, or
is
> there a better solution? Or should I simply create four delayed
versions
> of signal_a, and OR them together to form signal_b?
>
> I'm working with a Virtex-2 device.
>
> regards
> --
> -----------------------------------------------
> Please remove the x's in the email address if
> replying to me personally.
>
> Johan Bernsp=E5ng, xjohbex@xfoix.se


Article: 71304
Subject: Quartus SOPC Builder doesnt Recgnize my .elf file
From: arasquinha@yahoo.com (Rasquinha)
Date: 14 Jul 2004 01:58:02 -0700
Links: << >>  << T >>  << A >>
Hi,
I am using Excalibuer FPGA with ARM 922T I need to download my Digital
Design and My Embedded Code on to the chip for which the SOPC builder
is not recgonizing my .elf generated by ECOS(RTOS). I have tried
maniuplating the quartus makefile but no luck  .I am abel to down load
them independently ie my .elf or my hex file generated for my digital
design but not both at the same time.If somebody could throw some
light on this i would be greatefull even if they could comment on its
feasability.
Thanks and Regards,
Rasquinha

Article: 71305
Subject: Re: WinCUPL state machine for 16V8
From: Mike Harrison <mike@whitewing.co.uk>
Date: Wed, 14 Jul 2004 10:39:57 GMT
Links: << >>  << T >>  << A >>
On Wed, 14 Jul 2004 00:29:38 GMT, Pete Harrison <peter_harrison@ntlworld.com> wrote:

>I guess the combination of Wincupl and a 16V8 will be pretty much steam 
>technology for most of you but it is a real mystery to me.
>
>I blew up some 16V8 stepper sequencers the other day and I have to 
>program up some replacements. All I have is some software to program the 
>ATF16V8B chips and wincupl.
>
>This is my first try at this game but I have the state machine working 
>after many hours of searching and puzzling and it behaves the same as 
>the original chips. BUT...
>
>The driver board has an enable input which should turn off the motors. 
>In the current design, that is done by setting the outputs all high when 
>ENABLE is active. unfortunately, this only happens if a clock pulse is 
>applied as (I suppose) it has to get clocked through the output registers.
>
>Is there a way to make the ENABLE input force the outputs to a 
>predetermined state with or without a clock pulse?

You could do it using the OE pin on pin 11, and use external pullup/pulldowns. 
If you have enough free output pins, you could also route the state machine outputs back through
another 4 cells to provide an asynchronous enable function. 
Or you could pass the clock through a cell before feeding into pin 1, so you could generate a forced
clock pulse when enable gets asserted. 


Article: 71306
Subject: Re: mcu vs fpga help me to choose !!
From: Mario Trams <Mario.Trams@informatik.tu-chemnitz.de>
Date: Wed, 14 Jul 2004 13:07:26 +0200
Links: << >>  << T >>  << A >>
sudrie wrote:

> hello  <i>am an mcu developper on 8051 .</i>&#32; <i>never use xilinx
> fpga</i>&#32;<br><br><i>wana build an application and i don't know if an
> fpga is the best for my product i try to have the more low cost and "more
> compact" but i can't compare (not enought information)!</i>&#32;<br><br>My
> application request: <br> low cost for end user (i wana put my application
> freely on the net (i can program for the end user the chip if they don't
> have the programmer) and make the pcb ) <br><br>litle description :
> <snip>

I would also suggest you to leave your fingers away from FPGAs for 
your planned design. It appears to be far more cheaper and cost-efficient
to use a micro controller with appropriate integrated peripheral devices
or perhaps with some external chips.

USB, in particular, is quite complex and perhaps you would need to 
put an MCU into your FPGA to handle it at all.

For the case you would need some special hardware features 
(e.g. when all your ADC samples would need to be processed "somehow"
in parallel), then an FPGA + MCU solution might be of interest.

Regards,
Mario


Article: 71307
Subject: Re: FIR filter running out of FPGA memory in stratix ep1s60
From: kommandantklink@hotmail.com (Wilhelm Klink)
Date: 14 Jul 2004 04:23:07 -0700
Links: << >>  << T >>  << A >>
After viewing the fitter RAM summary details I can say the following:

The filter is a cascaded polyphase FIR.  There are three stages, and
the first stage is a decimate by 20, so has 20 polyphase arms.  Each
polyphase arm comprises of a distributed arithmetic unit.  The samples
are distributed as parallel data to each polyphase arm, and then
serialised.  My current interface at the input of each polyphase arm
uses 3 large registers of size nis*data_width, where nis = number of
interleaved streams = 8, and data_width = 32.  3 x 256 = 768, and
multiplying this by the number of phase arms across all cascaded
stages, this number gets very very large.  Because 1FF = 1LE, this
takes up heaps of LEs, so I decided to implement these registers in
memory.  In my data_width = 16 implementation (which fits in the
device) these registers are 128 bits in size, and constitute a depth
1, width 128 memory.  Clearly depth 1 memories will result in poor use
of memory resources.  We have M512 = width 18, M4K = width 36, M-RAM =
width 144, so I'd expect each register to require 4 x M4Ks, or 8 x
M512s.  Surprisingly, according to the fitter RAM summary, one of the
worst offending 128-bit registers used 54 x M4Ks and 8 x M512s.

Regardless of this problem I see that it was a BAD idea to fully
parallelise the data in the input interface of each polyphase arm
(seemed the easiest way at the time though).

Ray Andraka <ray@andraka.com> wrote in message news:<40F4532F.DBB4F364@andraka.com>...
> You'll need to provide more details as to how you set up the memory as
> well as the filter.  If the sample rate is one clock per sample, then it
> is not really appropriate to use the memory because you are using only one
> location per memory (and wasting the rest).
> 
> What is the ratio of your data rate to the clock?
> How many taps is your filter?
> 
> 
> Wilhelm Klink wrote:
> 
> > I've got an FIR design that runs out of FPGA memory in an ep1s60 when
> > I set the data width to 24-bit (The design fits with a data width of
> > 16-bit).  However only 13% of the total memory is used.  I assume the
> > problem is that I have lots of smaller memories, and they cannot share
> > the same memory blocks (M512, M4K, M-RAM).  Can anyone who has
> > experienced this problem share their strategies for dealing with this.
> 
> --
> --Ray Andraka, P.E.
> President, the Andraka Consulting Group, Inc.
> 401/884-7930     Fax 401/884-7950
> email ray@andraka.com
> http://www.andraka.com
> 
>  "They that give up essential liberty to obtain a little
>   temporary safety deserve neither liberty nor safety."
>                                           -Benjamin Franklin, 1759

Article: 71308
Subject: High Temperature FPGAs
From: Keith Wootten <keithw@nononono.co.uk>
Date: Wed, 14 Jul 2004 13:26:27 +0100
Links: << >>  << T >>  << A >>
Last year there was a thread here about using FPGAs at high temperatures 
with limited life.

Makmorbi said:
<quote extract>
I am about to write a paper on effects on FPGA's at high temperatures.
</quote>

Peter Alfke said, partly in response;
<quote extract>
I have helped customers in Texas, France, and
Norway with questions about device operation up to 175 degrees C, and
many such projects have been very successful, operating for weeks at
these elevated temperatures.
</quote>

What FPGAs were these?  I know that for example 3.3V devices usually 
work, but do the newer lower voltage devices also work?  Has anyone 
worked out a way of reliably fixing BGA packages at these temperatures?

Is your paper in the public domain, Makmorbi?

Cheers
-- 
Keith Wootten


Article: 71309
Subject: Re: Spartan 3 termination question (DCI)
From: brimdavis@aol.com (Brian Davis)
Date: 14 Jul 2004 06:01:00 -0700
Links: << >>  << T >>  << A >>
Yesterday I wrote:
>
>  Should be much better in V2Pro and S3 with the new DCI
> control logic to cleanly stop the DCI updates.
>
 Or maybe not- according to the following Answer Record,
there's a 60 mA per bank hit when using LVDCI_33 in a 
Spartan 3, so the ~200 mW per bank number still applies.

 I'm not sure why it's still so high, as I thought the main
cause of the high overhead with the V2 DCI was that the
FreezeDCI option randomly stopped the DCI update logic at
whatever state it was in, possibly in an active R/2 matching
mode, rather than cleanly stopping it with VRP/VRN inactive.

Answer Record #19628 Spartan-3 - How does DCI affect power consumption? 

  "In an experiment performed to test current consumption when
    using LVDCI, Xilinx found that for every bank that turned
    on DCI, the device consumed an extra 60 mA of current"


Brian

Article: 71310
Subject: Re: Altium CircuitStudio 2004 vs for FPGA support
From: Rene Tschaggelar <none@none.net>
Date: Wed, 14 Jul 2004 15:04:03 +0200
Links: << >>  << T >>  << A >>
Bruce Ray wrote:
> Does anybody have experience with the Altium CircuitStudio 2004 product
> compared with Altera's MAX+PLUS II Baseline (or other such products) that he
> could share?

Not yet. But on the way.
However these are a different kind of tools. While the Altium tool is 
concerned with the FPGA on a board, the free webtools, such as MaxPlus2
do not care about the pcb. EG the Altium tool is able to optimally 
assign the pin such that the routing on the pcb is simple. On MaxPlus2, 
the pin assignment has to be done manually.

Rene

Article: 71311
Subject: Xilinx Virtex-II Configuration in Slave Serial
From: lists_shehzad@softhome.net (M Shehzad Hanif)
Date: 14 Jul 2004 06:24:26 -0700
Links: << >>  << T >>  << A >>
Hi

I want to configure my Virtex-II (Avnet Development Board)using
MultiLINX download Cable. I am using Slave Serial Mode. But iMPACT
Software do not programme the FPGA and it says "DONE pin did not go
low" .
I also have two more queries. 

1-) System ACE MPM is enabled by default . Should I disable it when
using Slave Serial Mode as I am not using System ACE?
2-) Is HSWAP_EN has to do something with the stated problem?


Thanks 
Shehzad

Article: 71312
Subject: Nios SDK - understanding nm output
From: tns1 <tns1@cox.net>
Date: Wed, 14 Jul 2004 06:36:41 -0700
Links: << >>  << T >>  << A >>
Where can I find an explanation of the prefix codes in an nm generated 
symbol table? I see entries such as 'F' which are not described in the 
standard GNU manuals.


Article: 71313
Subject: extending a signal pulse
From: guy.eschemann@t-online.de (Guy Eschemann)
Date: 14 Jul 2004 06:55:40 -0700
Links: << >>  << T >>  << A >>
You could use a SRL16/DFF (with clock-enable and synchronous clear)
combination for this. The input pulse - which is high for one clock
cycle -sets the FF output, and a delayed version of this pulse clears
it after a number of clock cycles. The depth of the SLR16 sets the
length of the output pulse. Note that the output pulse is delayed by
one clock cycle with respect to the input pulse.

                     _______
                    |       |
                 +--| SRL16 |------+
                 |  |_______|      |
                 |                 |
                 |   ______        |
                 |  |      |       |
short pulse -----+--|CE   Q|----------- long pulse
                    |      |       |
                 1--|D     |       |
                    |      |       |
               CLK--|>     |       |
                    |      |       |
                 ---|CLR   |       |
                 |  |______|       |
                 |                 |
                 +-----------------+

Regards,
Guy.

Article: 71314
Subject: Re: FSM in illegal state (conclusion)
From: Jim Lewis <Jim@SynthWorks.com>
Date: Wed, 14 Jul 2004 07:35:52 -0700
Links: << >>  << T >>  << A >>
Hal,
> What do ASIC/CPU designers do?  My guess is that they don't
> have a global-reset so their version of this problem is a bit
> different.
In ASIC design, we would connect the asynchronous reset to the
circuit Ken showed (or one like it).  Reset for each clock
domain is separately synchronized.  Reset would need to settle
in a clock period.  Routing generally allows this.  If not,
you work it out (build a fanout tree with buffers or
registers).   Going back some time, on my first ASIC we had
to manually balance the clock tree.

See my post.  GSR would be generally alot more useful if
we could quantify in general that it settles in X to Y
amount of time and then apply its output to a circuit like
the one Ken shows to stabilize all logic or all control
logic.  From the difference between Y and X we could calculate
how many states we needed to delay "critical" reset so that
it occurs last.  Four registers is kind of ad-hoc and means
something much different for different clocks (20 MHZ vs
200MHZ).

Of course, going a step further, since synthesis tools can
and do recognize statemachines, and they know the clock
frequency of a particular clock, they could automatically
do the right thing for Xilinx (insert Ken's circuit).
However I like being in control of these type of things
and I am not sure I would like this solution.


Cheers,
Jim
-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jim Lewis
Director of Training             mailto:Jim@SynthWorks.com
SynthWorks Design Inc.           http://www.SynthWorks.com
1-503-590-4787

Expert VHDL Training for Hardware Design and Verification
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Article: 71315
Subject: Re: C16 processor from Opencores.org
From: kevinjwhite@comcast.net (Kevin White)
Date: 14 Jul 2004 08:07:35 -0700
Links: << >>  << T >>  << A >>
Symon,

It fails in both post-translation and post P&R simulation as well. 
Also it is not related to clock rate and fails when single stepped.  I
also simulated the original code from opencores and that fails in the
same way.

kevin

"Symon" <symon_brewer@hotmail.com> wrote in message news:<2liq3pFd9tdqU1@uni-berlin.de>...
> How about trying a post P&R simulation?
> Cheers, Syms.
> "Kevin White" <kevinjwhite@comcast.net> wrote in message
> news:a8425c6f.0407102012.202d7bac@posting.google.com...
> > Hi,
> >
> > Has anybody managed to get the C16 processor from opencores.org to
> > function correctly?
> >
> > I am trying to use it with a Digilent board with a Spartan IIe
> > XC2S300E and Xilinx tools version 6.2.03i.
> >
> > The code required modification to port it to this board and it
> > simulates fine with Modelsim but when the code executes it ignores
> > even simple instructions such as JUMP.  The program counter just keeps
> > incrementing.  I can see that the instructions are in memory OK.  Its
> > as if the Xilinx tools are not synthesizing the VHDL correctly.
> >
> > Any hints will be welcome.
> >
> > thanks
> >
> > Kevin

Article: 71316
Subject: Re: Altera SOPC SDRAM & CLK Input?
From: kempaj@yahoo.com (Jesse Kempa)
Date: 14 Jul 2004 09:07:28 -0700
Links: << >>  << T >>  << A >>
"Kenneth Land" <kland_not_this@neuralog_not_this.com> wrote in message news:<10f8r37ibfl3u8d@news.supernews.com>...
> Pino,
> 
> Do you have your PLL external output clock tied to the SDRAM clock pin?
> (plus all the other sdram pins?)
> Did you start with an example like "Thrifty" etc.?
> 
> Ken
> 

Ken is absolutely right about the PLL feeding the SDRAM clock being
necessary. One note, though: please take a look at an example design
specific to the board you're using (1s10). The reason I say this is
that the clock networks on our Nios/Cyclone boards (one PLL for Nios,
fed back into a second to drive SDRAM) are slightly different than the
Stratix boards (only one PLL required for both an on-FPGA and external
SDRAM clock).

Also note: be sure to phase shift the external clock to SDRAM. If you
open up the example designs and take a look at the PLL you'll see what
I mean. This will compensate for board trace delay and should be
adjusted if you build your own board which, obviously, will have its
own delay.

Jesse Kempa
Altera Corp.
jkempa at altera dot com

Article: 71317
Subject: Re: extending a signal pulse
From: =?ISO-8859-1?Q?Johan_Bernsp=E5ng?= <xjohbex@xfoix.se>
Date: Wed, 14 Jul 2004 18:21:03 +0200
Links: << >>  << T >>  << A >>
Yes, that looks like a good solution. I'll give that a try later.


For more ascii art, see: http://projects.c505.com/ascii_index.html.
classic rock videos in ascii.. )

Guy Eschemann wrote:

> You could use a SRL16/DFF (with clock-enable and synchronous clear)
> combination for this. The input pulse - which is high for one clock
> cycle -sets the FF output, and a delayed version of this pulse clears
> it after a number of clock cycles. The depth of the SLR16 sets the
> length of the output pulse. Note that the output pulse is delayed by
> one clock cycle with respect to the input pulse.
>
>                      _______
>                     |       |
>                  +--| SRL16 |------+
>                  |  |_______|      |
>                  |                 |
>                  |   ______        |
>                  |  |      |       |
> short pulse -----+--|CE   Q|----------- long pulse
>                     |      |       |
>                  1--|D     |       |
>                     |      |       |
>                CLK--|>     |       |
>                     |      |       |
>                  ---|CLR   |       |
>                  |  |______|       |
>                  |                 |
>                  +-----------------+
>
> Regards,
> Guy.


--
-----------------------------------------------
Please remove the x's in the email address if
replying to me personally.

Johan Bernsp=E5ng, xjohbex@xfoix.se

Article: 71318
Subject: Re: WinCUPL state machine for 16V8
From: hmurray@suespammers.org (Hal Murray)
Date: Wed, 14 Jul 2004 11:25:38 -0500
Links: << >>  << T >>  << A >>
>Or you could pass the clock through a cell before feeding into pin 1, so
>you could generate a forced
>clock pulse when enable gets asserted. 

Ding ding ding.  Can you say "runt pulse"?

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


Article: 71319
Subject: Re: Spartan 3 termination question (DCI)
From: Austin Lesea <austin@xilinx.com>
Date: Wed, 14 Jul 2004 09:48:07 -0700
Links: << >>  << T >>  << A >>
Brian,

LVDCI_33 is 60 mA for the reference resistors.  For the whole bank.

Wow.  Sooooo much current!  Face it:  setting the reference for the 
entire bank does take some power (in this case 3.3V X 60 mA or 200 
milliwatts.  I am pretty sure this is not going to "break the bank."

Yes, and if you just had to have all 8 banks use DCI, that would be 8 
times as much current.  I suggest that you confine the DCI interfaces to 
those banks that need them, not just for the 200 milliwatts.

Freeze DCI has nothing to do with it.  The DCI circuit has to solve for 
1/2 R, R and 2R, so the average current consumption is higher than it 
would be for R alone.

One trick you can use to cut it in half is to use 100 ohm reference 
resistors, and use LVDCI_DV2 (divide by two) to get 50 ohm drive.

Now you have 100 milliwatts dissipated for the feature of using DCI  in 
the bank.

If you are thinking "why did they not use 10X reference resistors? (to 
lower power per bank)" the answer is very simple:  the noise in a 
typical system would trash a higher impedance reference system, and the 
feature would have to be abandoned (or fixed)  -- sound familiar?.  From 
the first appearance of DCI in Virtex II, it has been a solid feature in 
every device since.

DCI updating is only an issue when you cross between two banks, and even 
then only with the parallel interfaces where it adds some small amount 
of jitter.  Freezing the updates allowed customers who did not read that 
they should not go across banks to modify the bitstream, rather than 
re-design their pcbs.  It also allowed the highest speed interfaces to 
have more timing margin (budget) which makes memory interfacing easier.

It is always preferable to provide the customer with solutions that 
involve changing bits, rather than making new boards (and them failing 
to place the orders that we desire).  Now we have three different DCI 
options:  regular (runs all the time changing +/- one trim), changes 
only when reguired, and "frozen" after matching (at configuration time).

Austin

Brian Davis wrote:
> Yesterday I wrote:
> 
>> Should be much better in V2Pro and S3 with the new DCI
>>control logic to cleanly stop the DCI updates.
>>
> 
>  Or maybe not- according to the following Answer Record,
> there's a 60 mA per bank hit when using LVDCI_33 in a 
> Spartan 3, so the ~200 mW per bank number still applies.
> 
>  I'm not sure why it's still so high, as I thought the main
> cause of the high overhead with the V2 DCI was that the
> FreezeDCI option randomly stopped the DCI update logic at
> whatever state it was in, possibly in an active R/2 matching
> mode, rather than cleanly stopping it with VRP/VRN inactive.
> 
> Answer Record #19628 Spartan-3 - How does DCI affect power consumption? 
> 
>   "In an experiment performed to test current consumption when
>     using LVDCI, Xilinx found that for every bank that turned
>     on DCI, the device consumed an extra 60 mA of current"
> 
> 
> Brian

Article: 71320
Subject: Re: new Lattice FPGAs vs Cyclone and SpartanIII
From: Ricardo <spamgoeshere1978@yahoo.com>
Date: Wed, 14 Jul 2004 14:34:14 -0300
Links: << >>  << T >>  << A >>
Luc Braeckman wrote:
> As far as I could discover, this is still a propriatary device, and
> therefore you could not use a standard SPI flash instead.  If no
> competition (read pin/pin compatible replacement) is possible, Altera
> could keep up the price as high as they want.
> With standard SPI flash, I have the choice of at least 5 different
> suppliers, no potentialy delivery problems, and guaranteed lowest
> price. Thus driving the total solution cost to a minimum.
> 
> Luc

Still unverified by me, but someone pointed here some time ago that EPCS 
devices are indeed a standard device produced by ST (M25Px0). Anyway, if 
that's true, Altera has a quite expensive paint... :D

Ricardo

Article: 71321
Subject: Re: FSM in illegal state (conclusion)
From: rickman <spamgoeshere4@yahoo.com>
Date: Wed, 14 Jul 2004 13:44:57 -0400
Links: << >>  << T >>  << A >>
Jim Lewis wrote:
> 
> Peter,
> Since the Xilinx parts have internal POR, it seems a
> shame not to use it.  However, since GSR is slow, we
> are cautioned against using it due to problems like
> these.

I don't think the problem with GSR synchronization equals a
recommendation to not use the GSR.  The point is to use it with
"caution" and to take the appropiate design steps.  


> Is there a way to connect the output of GSR to the
> input of the circuit that Ken Chapman suggested in
> the section  "Strategy for the 0.01% of cases" of his
> TechXclusive and leave off the asynchronous reset input.
> Would this be a way that I can effectively cause all of
> resets (or critical resets) for a clock domain to be
> deasserted at the same time without having to
> have a redundant external POR?

Reread Peter's post.  It is a good start and I think you misunderstood
some of the points in it.  You don't need an external reset and most
likely you don't need a sync reset that is "global" to a clock domain. 
Typically there are subsets of the design which are sensitive to
synchronous release of GSR.  These circuits are typically FSM, counters
and the like.  Normally the data path does not care about reset since it
will immediately go to the correct state on the next clock.  

One circuit you can add to any FSM to provide a sync reset is just one
or a pair of FFs which work just like a metastability reduction
circuit.  Have the GSR hold these FFs in the '1' state and wire the D
input of the first one to a '0'.  The last output will be your sync
reset.  The sync reset will be held for one or two clock edges after the
release of GSR.  This will only need to be used by the first two bits of
a one-hot FSM, the first changed bit of a gray coded counter, the first
bit of a JRC or even the first bit of a binary counter (assuming it
starts at 0); and so will not overly complicate them and slow them
down.  

I have done lots of FPGA designs and have never needed anything complex
to start the chip up.  Just pay attention to the startup and don't
assume that all FFs are released at the same time, between FSMs, not
just within them.  


> If this is possible, is there a VHDL coding methodology
> that you can recommend?  The big missing piece for me
> is how do I access the output of GSR?

This is something that should be added to Peter's app note.  

>    #1:  Explicitly through instantiation?
>    #2:  Implicitly through initializing the VHDL
>         signals that create the registers?
>         Although this technique seems possible in XST,
>         would it also work the same in other synthesis tools?
>    #3:  Put the reset logic in a separate hierarchical
>         block and explicitly code an asynchronous reset, but
>         at the next level of the design tie the asynchronous
>         reset to a constant inactive value?

You don't need to access the GSR signal explicitly.  If you provide an
async reset control that is common to most/all of your sequential logic,
I believe the tools will infer the GSR.  

  run_en_reg: PROCESS (sysclk, reset) BEGIN
	IF (reset = '1') THEN
	  run_en <= '0';
	ELSIF (rising_edge(sysclk)) then
	  run_en <= '1';
	END IF;
  END PROCESS;

This is what I use.  But I only refer to the run_en signal in the FFs
that actually need to be released synchronously.  


> If I have multiple FPGAs and they are all connected
> in a serial fashion for configuration, is the internal
> POR released at approximately the same time?

Approximate is the key word.  There is a common sync signal to provide
this, but you still have the wide range of delay inside each chip and
you need to select what clock is used to control it. 


> The details of POR and GSR functionality has always been a
> little troubling to me, is there a good (really detailed)
> application note that you can recommend.

You can learn a lot about it by reading how the end of configuration
works.  But the main thing is to stop assuming that the end of GSR is a
synchronous event.  On other chips we get used to the reset just working
(like magic).  In the FPGA we need to give it a little thought, even if
it is not really hard.  

-- 

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX

Article: 71322
Subject: Re: FPGA to PCI Bus Interface
From: rickman <spamgoeshere4@yahoo.com>
Date: Wed, 14 Jul 2004 13:49:49 -0400
Links: << >>  << T >>  << A >>
Hal Murray wrote:
> 
> >Or something else goes wrong, plus the cost of the PROM is comparable to the
> >cost of a PCI bridge...
> 
> I wasn't trying to push for or against the PLX type approach.  Just
> pointing out that there are ways to change the configuration when
> your design gets loaded from a PROM.  Board space or layour or something
> else might make the PLX/bridge unattractive.
> 
> Another potential disadvantage of the PLX/Bridge is a few more clock
> cycles if you just want to do a simple read.  (Writes can be pipelined.)

The design I worked on used a small CPLD along with the PLX chip and
allowed the download to come from the main CPU with no PROM.  This was
used to download different configurations for different modes of
operation (selftest vs. record vs. playback).  

-- 

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX

Article: 71323
Subject: Re: WinCUPL state machine for 16V8
From: Mike Harrison <mike@whitewing.co.uk>
Date: Wed, 14 Jul 2004 17:57:35 GMT
Links: << >>  << T >>  << A >>
On Wed, 14 Jul 2004 11:25:38 -0500, hmurray@suespammers.org (Hal Murray) wrote:

>>Or you could pass the clock through a cell before feeding into pin 1, so
>>you could generate a forced
>>clock pulse when enable gets asserted. 
>
>Ding ding ding.  Can you say "runt pulse"?
Depends on when you are likely to be using the enable - in most cases it will probably not be a
problem, as either the enable will be well seperated from movement signals, and if you are
disabling, you probably don't care. Additional terms could be added to the state machine to reduce
the risk of false counting if this is an issue.
 

Article: 71324
Subject: Re: FPGA to PCI Bus Interface
From: "MM" <mbmsv@yahoo.com>
Date: Wed, 14 Jul 2004 14:58:58 -0400
Links: << >>  << T >>  << A >>
"rickman" <spamgoeshere4@yahoo.com> wrote in message
news:40F5723D.ADC208EC@yahoo.com...
>
> The design I worked on used a small CPLD along with the PLX chip and
> allowed the download to come from the main CPU with no PROM.  This was
> used to download different configurations for different modes of
> operation (selftest vs. record vs. playback).

That's exactly what I am doing in most of my PCI designs, but Hal is right
in the sense that this is not a universal solution in every case.

/Mikhail





Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search