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 71325

Article: 71325
Subject: Re: FSM in illegal state (conclusion)
From: Jim Lewis <Jim@SynthWorks.com>
Date: Wed, 14 Jul 2004 12:01:13 -0700
Links: << >>  << T >>  << A >>
Rick,
>  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.  
I am a former ASIC designer.  I think I understand this
part well.  I do have a couple concerns.  First I want a
reset methodology that is device independent and
simulates well for any ASIC or FPGA technology not
just specific to Xilinx.  Hence, everything that requires
reset will need the synchronized reset.  I agree most
data path does not need reset (except for on some ASIC designs
to get the device to pass vectors more easily on the tester).

My second concern is that selective reset is not for
everyone.  For some this methodology will cause chaos.
For a design review with selective reset, this is just
one more item that needs to be reviewed in detail.


> 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.  
To me this seems like Chaos**n.  Not that it will not work,
it just adds more details you need to manage.

This methodology would have to buy me something significant
(speed or device size) for me to want to do additional
analysis and verification to prove that a circuit designed
as above actually works under all conditions.


>>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 sounds like it would address my needs nicely.
What do you connect reset to?   Do you just leave
it floating?  What do you do with it in simulation?

If there is something here that would work with
XST, Synplicity, and Mentor, without changing the
code, this would make me happy.  Especially if
the only thing I needed to change for each FPGA/ASIC
technology is the reset block and where the power-on
reset comes from.


> 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.  
On ASICs reset is explicit.  On your flow above with Xilinx,
I code reset on the register, hook it to ?? or leave it
unconnected, and then "magically" it gets connected to GSR.

Is there a datasheet, manual, or appnote you recommend reading
on configuration.

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: 71326
Subject: Re: FSM in illegal state (conclusion)
From: Peter Alfke <peter@xilinx.com>
Date: Wed, 14 Jul 2004 14:33:35 -0700
Links: << >>  << T >>  << A >>
Let me get back to the fundamental problem:
We distribute a (p)reset signal all over the chip. The problem is not the
activating edge of this signal, it's the release of (p)reset. No matter how
we distribute and phase it (unless there is only a single user clock of
relatively low frequency) the trailing edge will not appear at every
flip-flop in the same clock period. Whether the (p)reset is asynchronous or
synchronous does not matter. I do not see a way to solve this dilemma on the
chip-hardware-design level.
I suppose the software could be made smart enought to handle this, same as
smart designers can design around this. Especially with an elegant construct
like SRL16.
Peter Alfke

> From: Jim Lewis <Jim@SynthWorks.com>
> Organization: Posted via Supernews, http://www.supernews.com
> Newsgroups: comp.arch.fpga,comp.lang.vhdl
> Date: Wed, 14 Jul 2004 12:01:13 -0700
> Subject: Re: FSM in illegal state (conclusion)
> 
> Rick,
>> 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.
> I am a former ASIC designer.  I think I understand this
> part well.  I do have a couple concerns.  First I want a
> reset methodology that is device independent and
> simulates well for any ASIC or FPGA technology not
> just specific to Xilinx.  Hence, everything that requires
> reset will need the synchronized reset.  I agree most
> data path does not need reset (except for on some ASIC designs
> to get the device to pass vectors more easily on the tester).
> 
> My second concern is that selective reset is not for
> everyone.  For some this methodology will cause chaos.
> For a design review with selective reset, this is just
> one more item that needs to be reviewed in detail.
> 
> 
>> 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.  
> To me this seems like Chaos**n.  Not that it will not work,
> it just adds more details you need to manage.
> 
> This methodology would have to buy me something significant
> (speed or device size) for me to want to do additional
> analysis and verification to prove that a circuit designed
> as above actually works under all conditions.
> 
> 
>>> 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 sounds like it would address my needs nicely.
> What do you connect reset to?   Do you just leave
> it floating?  What do you do with it in simulation?
> 
> If there is something here that would work with
> XST, Synplicity, and Mentor, without changing the
> code, this would make me happy.  Especially if
> the only thing I needed to change for each FPGA/ASIC
> technology is the reset block and where the power-on
> reset comes from.
> 
> 
>> 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.
> On ASICs reset is explicit.  On your flow above with Xilinx,
> I code reset on the register, hook it to ?? or leave it
> unconnected, and then "magically" it gets connected to GSR.
> 
> Is there a datasheet, manual, or appnote you recommend reading
> on configuration.
> 
> 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: 71327
Subject: Re: FSM in illegal state (conclusion)
From: rickman <spamgoeshere4@yahoo.com>
Date: Wed, 14 Jul 2004 17:39:04 -0400
Links: << >>  << T >>  << A >>
Jim Lewis wrote:
> 
> Rick,
> >  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.
> I am a former ASIC designer.  I think I understand this
> part well.  I do have a couple concerns.  First I want a
> reset methodology that is device independent and
> simulates well for any ASIC or FPGA technology not
> just specific to Xilinx.  Hence, everything that requires
> reset will need the synchronized reset.  I agree most
> data path does not need reset (except for on some ASIC designs
> to get the device to pass vectors more easily on the tester).
> 
> My second concern is that selective reset is not for
> everyone.  For some this methodology will cause chaos.
> For a design review with selective reset, this is just
> one more item that needs to be reviewed in detail.

I don't design huge devices.  I also normally need to conserve gates. 
So I typically am working close to the hardware.  This selective reset
(as you call it) is just SOP for me.  I don't use test vectors (can't
you provide don't cares?) and the chaos is only if you don't use it
correctly.  

But all of this is only to save gates and/or improve speed.  Trying to
route a chip wide sync reset can end up running into the same timing
issues as the async reset if the fanout is too large.  I once worked on
an Altera design where we had CEs with large fanouts at 80 MHz.  The
timing analysis software did not work correctly for these signals and we
had a he77 of a time getting the chip to actually work on the bench when
the software said all was well.  Being 80% full didn't help much
either.  But my point is that chip wide, large fanout signals can be
problematic.  So I make sure I understand what my chip needs to startup
correctly and deal with that.  Of course ASIC design requires a whole
different level of confidence, but the method is not any different for
an ASIC.  You just have to make sure you did your homework, just like
when you design your FSM in the first place.  A small mistake in the FSM
can work great in simulation and even on the test bench, but end up
failing in the field and lock up the whole thing.  I can vouch for
that.  


> > 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.
> To me this seems like Chaos**n.  Not that it will not work,
> it just adds more details you need to manage.

Yes, more details, but each one is separate.  If you have startup
dependancies between your FSMs, that has to be managed even if you have
a global sync reset.  This does not change that.  

> This methodology would have to buy me something significant
> (speed or device size) for me to want to do additional
> analysis and verification to prove that a circuit designed
> as above actually works under all conditions.

Speed is just what it is about.  If you have to add another input to
every FF on the chip (some of which don't have a lut if they are just
delay registers) I can assure you that many of them will end up adding a
layer of logic and therefore another increment of delay.  If your design
is not timing critical, then this is not an issue.  


> >>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 sounds like it would address my needs nicely.
> What do you connect reset to?   Do you just leave
> it floating?  What do you do with it in simulation?

That depends on the target and tools.  Many HDL packages will detect the
async reset and connect it to the GSR, similar to the way they detect
clock signals and use the global clock buffers.  Some may still require
instantiation of an internal async reset signal source.  Check with your
tool/chip vendor.  


> If there is something here that would work with
> XST, Synplicity, and Mentor, without changing the
> code, this would make me happy.  Especially if
> the only thing I needed to change for each FPGA/ASIC
> technology is the reset block and where the power-on
> reset comes from.

The above style is what I learned to use before anyone was providing any
automatic support.  You used to need to instantiate the driver for this
signal or even provide it at a schematic level at the top of the
design.  As far as I know all vendors support this, but check with the
tool vendor to be sure.  Don't they have style guides? 


> > 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.
> On ASICs reset is explicit.  On your flow above with Xilinx,
> I code reset on the register, hook it to ?? or leave it
> unconnected, and then "magically" it gets connected to GSR.
> 
> Is there a datasheet, manual, or appnote you recommend reading
> on configuration.

I don't know which app note would be good, but Xilinx has lots of them. 
Do a doc search on their web site on the line of chips you are using and
the word "startup" or "configuration".  

-- 

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: 71328
Subject: Enum type as array range
From: rickman <spamgoeshere4@yahoo.com>
Date: Wed, 14 Jul 2004 17:46:51 -0400
Links: << >>  << T >>  << A >>
Maybe I am being a little dense, but I can't find anything on this in my
VHDL books and the LRM is pretty esoteric in this section.  

I am writing some code to help me simplify simulation data display and I
want to have some SLV constants in an array.  These constants relate to
defined states of a combination of signals and have names associated
with them.  To get the names to show up in the simulation, I want to use
an enumerated type which then corresponds to the index of the constant
array.  

Can I directly use this enumerated type as the index?  I am still a day
or so from having some code to try.  Am I barking up the wrong tree with
this?  Should I convert my enum variable to an int and use that as the
array index?  


  subtype	ALUSLV		is SLV07;
  subtype ALUTyp is (AD, ADC, SU, SUC, CM, CMC, AN, LOR, LXR, SR, SC,
AER); 

  type ALUstyles is array (ALUTyp) of ALUSLV := (
			"00100XX", ...


-- 

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: 71329
Subject: Re: new Lattice FPGAs vs Cyclone and SpartanIII
From: Ray Andraka <ray@andraka.com>
Date: Wed, 14 Jul 2004 18:07:52 -0400
Links: << >>  << T >>  << A >>
I suppose you could use an SPI flash in conjuction with a cheap up like a PIC (some of those are less than a dollar,
and they even have one in a SOT23 package) to undercut the cost of the serial config ROMs.


--
--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: 71330
Subject: Re: FPGAs starting with incorrect bitstream !?
From: Ray Andraka <ray@andraka.com>
Date: Wed, 14 Jul 2004 18:15:47 -0400
Links: << >>  << T >>  << A >>
I'm coming a little late to this conversation, but perhaps this has not been
considered.
I sincerely doubt it is a configuration problem.  Much more likely, you are not
coming
out of reset at the end of configuration cleanly.  The global reset must be
considered
asynchronous to the clock.  Most likely, you are occasionally getting a
situation where
one or more flip flops are seeing the end of the configuration reset a clock
cycle before
or after other flip flops in a critical area of your design.  Simulation usually
won't catch
this, so you need to do a careful examination of the start up of your design.  I
can't tell you
the number of designs I've seen that make this common mistake, even from FPGA
board
vendors with much experience that really should know better.

Check the state machines in your design.  The resets for them should come from a

flip-flop in the design that feeds all the reset inputs to the  state machine.
You can't
depend on global reset going away on all flip-flops during the same clock cycle.




Antti Lukats wrote:

> "Bob Perlman" <bobsrefusebin@hotmail.com> wrote in message
> news:3vpde0p9u98hlop2aucsd27b11b919h8i8@4ax.com...
> > On Sat, 3 Jul 2004 18:54:16 -0700, "Antti Lukats" <antti@case2000.com>
> > wrote:
> >
> > <stuff snipped>
> > >its not funny to simulate Full 1M Gate with MicroBlaze !
> >
> > Does this mean it wasn't simulated?
>
> yes it means that the 1M gate desing with 32K application code for
> Microblaze has not bein simulated. All the custome IP cores connected to
> Microblaze of course have been simulated.
>
> > > and you can not simulate badly configured FPGA anyway, can you?
> >
> > No, but it remains to be seen whether that's the problem.  If you
> > haven't simulated, start there.
>
> Dear Bob,
>
> I have a bitstream that starts always OK when loaded from configuration
> memory, and start with erratic behaviour 1 from 100 JTAG configuration
> attempts (even when JTAG configuration did not show any error during
> download). When the bitstream starts badly it behavies badly after reset
> also, only full new reconfiguration makes the system to working again. So I
> do assume it is possible that the CRC check is not sufficent in Virtex2
> devices and that they actually do start also in case of bad download
> sometimes.
>
> You suggested this erratic behaviour of bad starting when loading from JTAG
> could be found running simulations ?! Well I really cant understand that any
> simulation models could take into account the errors that happend during
> download. ?? Or what was it what I could possible find in simulation?
>
> Antti

--
--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: 71331
Subject: Re: WinCUPL state machine for 16V8
From: Rich Webb <bbew.ar@mapson.nozirev.ten>
Date: Thu, 15 Jul 2004 00:21:30 GMT
Links: << >>  << T >>  << A >>
On Wed, 14 Jul 2004 08:10:16 GMT, Pete Harrison
<peter_harrison@ntlworld.com> wrote:

[snip...snip...]
>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

Ah! I'd forgotten fields; knew there had to be *some* way to avoid
having to list them explicitly.

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

Beer is fine; thanks! I'm in the midst of a week of grunting through
some reliability paperwork (FMECA, ugh) so a small potation is welcome.

-- 
Rich Webb   Norfolk, VA

Article: 71332
Subject: Re: new Lattice FPGAs vs Cyclone and SpartanIII
From: "Steven K. Knapp" <steve.knappNO#SPAM@xilinx.com>
Date: Wed, 14 Jul 2004 17:28:59 -0700
Links: << >>  << T >>  << A >>
Just FYI, there is an application note on this very topic that demonstrates
how to configure a Xilinx FPGA from an SPI serial Flash using a small CPLD.
The application note is written for CoolRunner-II, but practically any
Xilinx CPLD will do.

XAPP800:  Configuring Xilinx FPGAs with SPI Flash Memories Using
CoolRunner-II CPLDs
http://www.xilinx.com/bvdocs/appnotes/xapp800.pdf

While we're on the subject, have you ever wanted to store additional
information in the configuration memory (serial numbers, Ethernet MAC IDs,
MicroBlaze code) and read it after the FPGA configures?  If so, the
following application note may be of interest.

XAPP694: Reading User Data from Configuration PROMs
http://www.xilinx.com/bvdocs/appnotes/xapp694.pdf

The two demo designs for the Spartan-3 Starter Kit also demonstrate this
capability.
http://www.xilinx.com/products/spartan3/s3boards.htm#RF

---------------------------------
Steven K. Knapp
Applications Manager, Xilinx Inc.
General Products Division
Spartan-3/II/IIE FPGAs
http://www.xilinx.com/spartan3
---------------------------------
Spartan-3:  Make it Your ASIC


"Ray Andraka" <ray@andraka.com> wrote in message
news:40F5AEB8.DDDC48C9@andraka.com...
> I suppose you could use an SPI flash in conjuction with a cheap up like a
PIC (some of those are less than a dollar,
> and they even have one in a SOT23 package) to undercut the cost of the
serial config ROMs.
>
>
> --
> --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: 71333
Subject: How to deal with unrouted nets in a partial reconfigurable assembly?
From: "Cody" <cody1980@hotmail.com>
Date: Thu, 15 Jul 2004 10:28:04 +0800
Links: << >>  << T >>  << A >>
Hi, there:

My active implementation of two modules are all correct, P&R are perfect.
However, during assembly stage, a small number (4) of wires literally got
unrouted and returned to green flywires after P&R is done. In the
fpga_editor
it is labeled as GLOBAL_LOGIC0, and it lies deep in the middle of the
reconfigurable module's AREA_GROUP...On inspecting active implementation,
this wire IS routed, and the individual modules are perfectly routed too...

What may I do with this?

Thanks.
Cody






Article: 71334
Subject: Re: Spartan 3 termination question (DCI)
From: brimdavis@aol.com (Brian Davis)
Date: 14 Jul 2004 19:41:21 -0700
Links: << >>  << T >>  << A >>
Austin,
>
>Wow.  Sooooo much current!
>
 Save your sarcasm for an instance in which it is merited.

 Peter's claim of "zero additional system power" was inaccurate, 
especially coming after the "urban legend" lead-in.

 If he has a problem with me pointing out the per bank overhead
of DCI for V2 and S3 parts, I'm sure he'll speak up about it.

 In a small Spartan3 design drawing little current on VCCINT,
power consumption would be dominated by "sooooo much current",
especially if using 33 ohm VRP/N resistors as you suggested
earlier in the thread.

 It would be much better to shut down the VRP/VRN outputs after
configuration when DCIUpdateMode=Quiet, which would eliminate
the DCI power overhead completely for series DCI.

 When last I checked in detail (Fall 2003), all of Xilinx's
power estimation tools, published data, and Answer Records
failed to properly report static DCI supply current, for both
per-bank overhead and per-input parallel termination.

 As for the rest of your post, I could point out in detail the
various errors and omissions you've made, but I don't have the
time or patience tonight to explain things that should have 
been properly documented in the Virtex2 application notes and
datasheets long ago.

Brian



Austin Lesea <austin@xilinx.com> wrote in message news:<cd3o2s$npd3@cliff.xsj.xilinx.com>...
>
>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
>

Article: 71335
Subject: Re: Altera SOPC SDRAM & CLK Input?
From: pinod01@sympatico.ca (Pino)
Date: 14 Jul 2004 19:58:52 -0700
Links: << >>  << T >>  << A >>
kempaj@yahoo.com (Jesse Kempa) wrote in message news:<95776079.0407140807.7cf919d1@posting.google.com>...
> "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

Jesse/Ken,
 
    Thanks for your responses.  In fact I was debating whether or not
I needed one, but both your responses definitely eliminate my thought
of not having to implement one.  I agree that this is required and
will definitely help me with any board skew as well.   I haven't
implemented, but will look into the example and try to use some of the
results from that for the board.  Do you know what the trace-lengths
(layout) is on the board to configure the proper phase delay
parameters for the PLL for the 1s10 NIOS eval.board?  Is there a
recommended number I should use?

Regards,
Pino

Article: 71336
Subject: Re: micron sdram module
From: pinod01@sympatico.ca (Pino)
Date: 14 Jul 2004 20:07:30 -0700
Links: << >>  << T >>  << A >>
Duane Clark <junkmail@junkmail.com> wrote in message news:<cd1coq08fu@news2.newsguy.com>...
> Steven wrote:
> > Hi,
> > 
> > I now want to know whether a read or write successful or not. Can
> > someone tell me which array of variable in micron's simulation module
> > I should put in the "watch" ? The micron module is quite complicated.
> > I have problem now to get the timing right. Of course I know if I
> > cannot read the thing I write, it is wrong, problem is that maybe the
> > read has a bad timing too. So I need to see the internal content.
> > 
> > I use vhdl module.
> 
> That should be easy to determine from the source code. The data is 
> stored in the variables Bank0-3. But if you can cosimulate with Verilog, 
> I would suggest using the Verilog model. It is more up to date, though 
> judging by the change log the changes are relatively minor. But a big 
> advantage is that it prints out reads and writes, including the address 
> and contents. Though in some situations that might be considered a 
> disadvantage.

Steven,

    I have a similar problem in that I have downloaded a SDRAM VHDL
module from the Micron website and have developed a master peripheral
to the Avalon Bus using SOPC Builder in Quartus.  In this, I merely
connect to the SDRAM controller which is physically connected to a
128Mbit Micron SDRAM.   When attempting to simulate this SOPC design
interfaced directly to the SDRAM module from Micron, I don't manage to
see any of the data that I have put in the WRITE phase, as when I do a
READ I get crap out.   The verilog doesn't work well as I have not
managed to be able to interface Verilog and VHDL properly within the
same design.  Definitley my lack of experience in this area to doing
it correctly.  So perhaps this is a similar issue, but I am unclear
what the MICRON module is supposed to do as I don't see anything
coming out?   Is the module supposed to retain information and return
it on the bus when you request it (i.e a READ)?

REgards,
Pino

Article: 71337
Subject: Re: Enum type as array range
From: Mike Treseler <mike_treseler@comcast.net>
Date: Wed, 14 Jul 2004 21:21:44 -0700
Links: << >>  << T >>  << A >>
rickman wrote:

>
> I am writing some code to help me simplify simulation data display and I
> want to have some SLV constants in an array.  These constants relate to
> defined states of a combination of signals and have names associated
> with them.  To get the names to show up in the simulation, I want to use
> an enumerated type which then corresponds to the index of the constant
> array.
> Can I directly use this enumerated type as the index?

yes

> I am still a day 
> or so from having some code to try.  Am I barking up the wrong tree with
> this?

No, it's a good idea.

> Should I convert my enum variable to an int and use that as the 
> array index?
>   subtype     ALUSLV          is SLV07;
>   subtype ALUTyp is (AD, ADC, SU, SUC, CM, CMC, AN, LOR, LXR, SR, SC,AER);
> 
>   type ALUstyles is array (ALUTyp) of ALUSLV := (
> "00100XX", ...

I see. Maybe like this:
-------------------------------------------------------------------------------
library ieee;
use ieee.std_logic_1164.all;
entity alu_test is
end alu_test;
-------------------------------------------------------------------------------
architecture sim of alu_test is
  subtype ALUSLV is std_logic_vector(7 downto 0);
  type ALUTyp is (AD, ADC, SU, SUC, CM, CMC, AN, LOR, LXR, SR, SC, AER);
  type ALUstyles is array (ALUTyp'left to ALUTyp'right) of ALUSLV;
  constant init : ALUstyles := (AD => x"42", ADC => x"ff", others => x"00");
begin  
-- sim processes
end architecture sim;

     -- Mike Treseler


Article: 71338
Subject: Re: Enum type as array range
From: rickman <spamgoeshere4@yahoo.com>
Date: Thu, 15 Jul 2004 00:54:27 -0400
Links: << >>  << T >>  << A >>
Mike Treseler wrote:
> 
> rickman wrote:
> 
> >
> > I am writing some code to help me simplify simulation data display and I
> > want to have some SLV constants in an array.  These constants relate to
> > defined states of a combination of signals and have names associated
> > with them.  To get the names to show up in the simulation, I want to use
> > an enumerated type which then corresponds to the index of the constant
> > array.
> > Can I directly use this enumerated type as the index?
> 
> yes
> 
> > I am still a day
> > or so from having some code to try.  Am I barking up the wrong tree with
> > this?
> 
> No, it's a good idea.
> 
> > Should I convert my enum variable to an int and use that as the
> > array index?
> >   subtype     ALUSLV          is SLV07;
> >   subtype ALUTyp is (AD, ADC, SU, SUC, CM, CMC, AN, LOR, LXR, SR, SC,AER);
> >
> >   type ALUstyles is array (ALUTyp) of ALUSLV := (
> > "00100XX", ...
> 
> I see. Maybe like this:
> -------------------------------------------------------------------------------
> library ieee;
> use ieee.std_logic_1164.all;
> entity alu_test is
> end alu_test;
> -------------------------------------------------------------------------------
> architecture sim of alu_test is
>   subtype ALUSLV is std_logic_vector(7 downto 0);
>   type ALUTyp is (AD, ADC, SU, SUC, CM, CMC, AN, LOR, LXR, SR, SC, AER);
>   type ALUstyles is array (ALUTyp'left to ALUTyp'right) of ALUSLV;
>   constant init : ALUstyles := (AD => x"42", ADC => x"ff", others => x"00");
> begin
> -- sim processes
> end architecture sim;

Thanks.  Shortly ago, I got word back from a friend who had borrowed my
one book that actually talked about this.  But your example shows me I
was mixing my type def with my constant declaration.  

I am unusually tired tonight and am packing it in.  I see I am making
more errors than I am fixing :)  I will hate to see what errors the
simulator gives me when I try to compile tomorrow.  

-- 

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: 71339
Subject: Re: FPGAs starting with incorrect bitstream !?
From: "Squirrel" <harwacct926_REMOVEFORSPAM@veriBACONzon.net>
Date: Thu, 15 Jul 2004 07:20:58 GMT
Links: << >>  << T >>  << A >>
If it is a V2, and  you only experience problems when downloading from
JTAG...Keep in mind that the V2 supports partial reconfiguration.  As such,
the JTAG bit-banger from IMPACT doesn't invoke the global clear when
re-configuring, so BRAMs will not initialize, and FFs _may_ not.  I think I
saw a Xilinx solution record with information on how to invoke the global
initialization through JTAG manually...the Chipscope tool does this
currently.  Or, you can manually short the PROG pin to ground.

By the way, this is documented in the V2 design guide.

-S


> > Dear Bob,
> >
> > I have a bitstream that starts always OK when loaded from configuration
> > memory, and start with erratic behaviour 1 from 100 JTAG configuration
> > attempts (even when JTAG configuration did not show any error during
> > download). When the bitstream starts badly it behavies badly after reset
> > also, only full new reconfiguration makes the system to working again.
So I
> > do assume it is possible that the CRC check is not sufficent in Virtex2
> > devices and that they actually do start also in case of bad download
> > sometimes.
> >
> > You suggested this erratic behaviour of bad starting when loading from
JTAG
> > could be found running simulations ?! Well I really cant understand that
any
> > simulation models could take into account the errors that happend during
> > download. ?? Or what was it what I could possible find in simulation?
> >
> > Antti
>



Article: 71340
Subject: Re: FIR filter running out of FPGA memory in stratix ep1s60
From: kommandantklink@hotmail.com (Wilhelm Klink)
Date: 15 Jul 2004 01:13:10 -0700
Links: << >>  << T >>  << A >>
Correction: I realise that the 54 x M4Ks and 8 x M512s memory usage
must be due to sharing of memories.

kommandantklink@hotmail.com (Wilhelm Klink) wrote in message news:<6011e208.0407140323.3f13a001@posting.google.com>...
> 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: 71341
Subject: Re: Altium CircuitStudio 2004 vs for FPGA support
From: Rene Tschaggelar <none@none.net>
Date: Thu, 15 Jul 2004 10:13:22 +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?

I forgot to add : The Altium Tolls require the free web versions of 
Xilinx, Altera and such to do the actual (routing-)work. The Altium
tools are therefore to be regarded as layer on top of the others.

Rene
-- 
Ing.Buero R.Tschaggelar - http://www.ibrtses.com
& commercial newsgroups - http://www.talkto.net

Article: 71342
Subject: Re: micron sdram module
From: "mihau" <rtl2gdsCUTIT@op.pl>
Date: Thu, 15 Jul 2004 11:24:51 +0200
Links: << >>  << T >>  << A >>
if you are writing to SDRAM module you can check value written at lines:
    ...
-- Write back to memory
                    IF Bank = "00" THEN
                        Bank0 (Row_index) (Col_index) := Dq_temp;
                    ELSIF Bank = "01" THEN
                        Bank1 (Row_index) (Col_index) := Dq_temp;
                    ELSIF Bank = "10" THEN
                        Bank2 (Row_index) (Col_index) := Dq_temp;
                    ELSIF Bank = "11" THEN
                        Bank3 (Row_index) (Col_index) := Dq_temp;
                    END IF;
    ....
--

 and if you read you may check:
...
ELSIF Data_out_enable = '1' THEN
           IF Dqm_reg0 /= "1111" THEN
                    -- Initialize memory
                    Init_mem (Bank, Row_index);
                    -- Load memory into buffer
                    IF Bank = "00" THEN
                        Dq_temp := Bank0 (Row_index) (Col_index);
                    ELSIF Bank = "01" THEN
                        Dq_temp := Bank1 (Row_index) (Col_index);
                    ELSIF Bank = "10" THEN
                        Dq_temp := Bank2 (Row_index) (Col_index);
                    ELSIF Bank = "11" THEN
                        Dq_temp := Bank3 (Row_index) (Col_index);
                    END IF;
...

in micron VHDL SDRAM simulation model (example for quad bank 64Mb Micron
model)
I've designed simple sdram controller with testbench instantiating Micron
SDRAM 32Mx2 model,
you can check it at http://www.geocities.com/mikael262/sdram.html

Mike



Article: 71343
Subject: programmable voltage control of a VCCIO Bank
From: Amontec Team <laurent.gauch@amontecDELETEALLCAPS.com>
Date: Thu, 15 Jul 2004 13:14:33 +0200
Links: << >>  << T >>  << A >>
Hi all,

Sorry but this question is not about logic system.

I have to control the VCCO of one bank of a SPARTAN-3.
I need to be able to control the drive of 3.3V, 2.5V, 1.8V, 1.5V, 1.2V 
to VCCO.

The main control would be in the FPGA itself. I have to add an external 
electronic to switch between the different voltage sources.

Do you have any circuit example to do a controllable voltage switch or 
to do an controllable DC/DC regulator.

Price and dimension are very important for this design.

THANKS
Laurent Gauch
www.amontec.com




Article: 71344
Subject: Re: Using gprof with Nios II
From: steven derrien <steven_derrien@yahoo.fr>
Date: Thu, 15 Jul 2004 13:41:45 +0200
Links: << >>  << T >>  << A >>
Thank you for your help.

Steven

Jesse Kempa wrote:
> steven derrien <steven_derrien@yahoo.fr> wrote in message news:<ccu7n3$acg$1@python.ifsic.univ-rennes1.fr>...
> 
>>Hi,
>>
>>Has anybody been trying to use gprof within the NIOS II IDE ?
>>We have some problems regarding the profiling data that is
>>send through the jtag interface directly to the IDE console window.
>>
>>We had a look to the documentation but there is little information 
>>regarding the use of the profiler with the NIOS II.
>>
>>It seems that, to the difference of NIOS I, the profiling data
>>is sent as binary data, resulting in the following stdout trace :
>>
>>< Here the program standard output >
>>**gmon.out data follows**
>>< non readable binary data >
>>nios2-terminal: exiting due to ^D on remote
>>
>>Does anybody knows how to solve this issue ?
>>
>>Thank you in advance,
>>
>>Steven
> 
> 
> Hi Steven,
> 
> Here are the basic steps to using GPROF in Nios II:
> 
> (In the IDE):
> 1. Add a compiler switch, "-pg", for your src code project (in the
> C/C++ build area of the project properties). This is standard fare for
> using GPROF regardless of processor.
> 2. Add the same "-pg" switch for the compiler in your system library
> project.
> 3. Check the "use profiling library" checkbox in syslib properties.
> 
> (From the SDK Shell):
> 4. Run your program: Use nios2-terminal's "--gmon" switch which will
> automatically capture the profiling data into a 'gmon.out' file after
> your program finishes execution. This has to be done from the command
> line, not the IDE.
> 
> Note: nios2-terminal must be started with the processor in a paused
> state. You can do this by opening two SDK shell windows, downloading
> your program using "nios2-download <elf file>" (which downloads your
> code and leaves the processor paused), then running "nios2-terminal
> --gmon" in the second window, and finally running "nios2-download -g"
> in the first to start execution.
> 
> More notes: Your application must return from main() because the
> profiling library's data dump is triggered by reaching atexit().
> 
> Also, the above notes assume that you're using the JTAG UART for
> STDIO; for the conventional UART we cannot support GPROF with the
> above flow just yet (this is scheduled for the next release)
> 
> 5. Place the "gmon.out" file (generated in step 4) into the same dir
> as your .elf file
> 6. Run nios2-elf-gprof <elf file name> gmon.out > <output file name>
> 7. Examine the output file for results.
> 
> The above flow was actually easier than I had expected given my GPROF
> experience with other processors :) However, I am sending an
> enhancement request to our engineering team to make the above flow all
> happen from within the IDE so that the SDK shell business isn't
> necessary.
> 
> Also, I'll see to it that this is looked at for a relevant app note
> when the time comes; in addition to GPROF there is a performance
> counter peripheral (which is documented in the Nios II kit) which is
> useful for profiling sections of code -- such an app note will likely
> describe the use of both tools.
> 
> Jesse Kempa
> Altera Corp.
> jkempa at altera dot com


Article: 71345
Subject: Re: programmable voltage control of a VCCIO Bank
From: Jonathan Bromley <jonathan.bromley@doulos.com>
Date: Thu, 15 Jul 2004 13:24:18 +0100
Links: << >>  << T >>  << A >>
On Thu, 15 Jul 2004 13:14:33 +0200, Amontec Team
<laurent.gauch@amontecDELETEALLCAPS.com> wrote:

Laurent,

>Sorry but this question is not about logic system.

Yes, it is.  In most systems it's these "peripheral"
issues that cause the most trouble...

>I have to control the VCCO of one bank of a SPARTAN-3.
>I need to be able to control the drive of 3.3V, 2.5V, 1.8V, 1.5V, 1.2V 
>to VCCO.
>The main control would be in the FPGA itself. I have to add an external 
>electronic to switch between the different voltage sources.
>Do you have any circuit example to do a controllable voltage switch or 
>to do an controllable DC/DC regulator.
>Price and dimension are very important for this design.

I suggest you trawl through Maxim, Linear Technology and all the
usual power-supply suspects.  For some while now, Pentium-class
CPUs have had a digital output (5 bits, I think) that sends to
the power supply a value indicating what Vcc(core) voltage 
is required.  The standard CPU power regulator solutions 
interpret this value and change their output appropriately.
They are far too powerful for your needs, but that should not
be a problem - it simply means that you should be able to use
smaller external components (L, C).  They all provide 
excellent application notes and example circuits.

Alternatively, if the current requirements are fairly low,
you may find that the good old LM317-class regulators will
do what you need.  You can build a simple resistive-ladder
DAC on one set of FPGA outputs, and use it to set the
tail voltage for the LM317 device.

There is a truly huge selection of power regulator devices
available today.  Their performance is much better than
the older parts, they are available in tiny surface-mount
packages, they are cheap (because they're used in high
volume applications) and, for the switch-mode parts, they
now use very high switching frequencies so that the external
passive components can be quite small.  It's just a question
of raking through the websites until you find a part that
meets all your criteria *and is freely available*.  To be 
sure that your chosen part is available, it's often a good
idea to begin your search at one of the "supermarket" 
distributors such as Newark/Farnell, RS, Digi-Key or
whatever.  Anything in their catalogues is probably a
popular part with good availability.

If you can cope with the flames and aggression, you might
get a good response if you post on sci.electronics.design
as well.

If you need the design doing for you, we could probably
help on a consultancy basis.
-- 
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL, Verilog, SystemC, Perl, Tcl/Tk, Verification, Project Services

Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, BH24 1AW, UK
Tel: +44 (0)1425 471223          mail:jonathan.bromley@doulos.com
Fax: +44 (0)1425 471573                Web: http://www.doulos.com

The contents of this message may contain personal views which 
are not the views of Doulos Ltd., unless specifically stated.

Article: 71346
Subject: connecting a fifo to avalon bus
From: "Gerd Reichle" <reichle@teest.com>
Date: Thu, 15 Jul 2004 14:50:04 +0200
Links: << >>  << T >>  << A >>
Hello !

I want to create a fifo to connect the avalon bus. Im new to this kind of
work, so it would be nice if someone of you could give me some advice. The
idea is to create a fifo from which i can read using the streaming slave
read transfer.

Thanks
   Gerd



Article: 71347
Subject: Re: FSM in illegal state (conclusion)
From: "Michael Smith" <my.name@myemployer.com>
Date: Thu, 15 Jul 2004 14:05:45 +0100
Links: << >>  << T >>  << A >>
"Jim Lewis" <Jim@SynthWorks.com> wrote in message
news:40F5EA1D.4080808@SynthWorks.com...
> Peter,
> As an ASIC designer, I understand the fundamental issues
> with propagating signals - including reset deassertion.
> I also understand VHDL quite well.
>
> What is not clear to me is the relationship between
> my code, my reset, and Xilinx GSR after synthesis.
> The following code specifies a single reset:
>
>    process (Clk, nReset)
>    begin
>      if nReset = '0' then
>        Y <= '0' ;
>      elsif rising_edge(Clk) then
>        Y <= A ;
>      end if ;
>    end process ;
>
> What I think I am hearing is that after synthesis
> targeting Xilinx technology, the reset of the register
> is connected to both GSR and my nReset signal.  My
> nReset signal typically comes from a block which
> resynchronizes it similar to how Ken Chapman recommends.
>
> Am I right so far?  I am scanning through your Basic
> VHDL document.  Since I know VHDL quite well, I would
> not normally read this document.  I see the above
> conclusions in the resulting logic equations, however,
> I do not see it in written text.  Is there another
> document that explains this?
>
> Going further, how do I write VHDL that will reset a
> register using GSR, but not an require external reset?
> It sounds like what I am hearing (rickman) is
> that I code it like above and tie the nReset
> signal to '1' (or leave it unconnected?) and GSR will
> remain connected to the FF after synthesis.
>
> Is this part right?
> I am not real comfortable with this part of the process
> as in ASIC synthesis, if you tie the nReset signal
> inactive then it is likely to remove that function
> from the register.  If this is what you really do,
> it is so foreign to me that I need to hear it again
> and again in your documentation.
>
> Once I know the correct method for the above, I
> too can be as smart as the other smart designers
> dealing with this issue.
>
> Best Regards,
> Jim


Forgive me if I've someone's mentioned it already, but I understand that, in
Virtex and later devices, synthesis tools do NOT infer the use of the GSR
from the VHDL Reset signal. Instead the user's Reset is routed using general
routing resources. (So, timing constraints can be applied to it.) There is
of course still an issue if the external signal is truly asynchronous to the
clock.

The effect of the GSR on the design's flip-flops is inferred from the
behavior of the Reset signal.You can change this using UCF INIT constraints
(care!)

The GSR is still used - at configuration time. It is an internal signal
driven from the STARTUP block. You can't get rid of it (nor would you want
to!) You can connect an external reset to the STARTUP block and hence drive
the GSR if you want - you do this by instancing a STARTBUF component. You
can also connect an internal signal to the STARTUP block to drive the GSR.
If you do neither of these, the GSR is only used at configuration.

I recommend Xilinx's "Simulation and Verification Guide", which discusses
all this. It is available with ISE or from:
http://www.xilinx.com/support/sw_manuals/xilinx6/download/

Mike Smith, Doulos Ltd.
my.name@myemployer.com



Article: 71348
Subject: Re: micron sdram module
From: dxslyz@lycos.de (Steven)
Date: 15 Jul 2004 06:23:46 -0700
Links: << >>  << T >>  << A >>
> > That should be easy to determine from the source code. The data is 
> > stored in the variables Bank0-3. But if you can cosimulate with Verilog, 
> > I would suggest using the Verilog model. It is more up to date, though 
> > judging by the change log the changes are relatively minor. But a big 
> > advantage is that it prints out reads and writes, including the address 
> > and contents. Though in some situations that might be considered a 
> > disadvantage.

Thanks, Duane. It is quite obviously that Bank0-3 hold the memory
contents. :)
It is too large to put in the watch list. 64MB or more of each bank.
Anyway thanks. The other tip from you is great, verilog module gives
more info. Maybe micron also do not like old europe so they do not
include such useful output in vhdl module. :)


> 
>Definitley my lack of experience in this area to doing
> it correctly.  So perhaps this is a similar issue, but I am unclear
> what the MICRON module is supposed to do as I don't see anything
> coming out?   Is the module supposed to retain information and return
> it on the bus when you request it (i.e a READ)?
> 
> REgards,
> Pino

Yes, Pino. The module works like physical module, only for simulation.
It executes Read/Write command from your sdram controller, and holds
the contents.

Article: 71349
Subject: Re: new Lattice FPGAs vs Cyclone and SpartanIII
From: Luc Braeckman <luc.braeckman@pandora.be>
Date: Thu, 15 Jul 2004 13:58:47 GMT
Links: << >>  << T >>  << A >>
Of course you can, why not building a complete system just to
configure the FPGA (sic). The idea of a cheap SPI flash directly
connected to the FPGA is very attractive, especially in consumer
application where every cent counts.

Regards,

Luc
___
On Wed, 14 Jul 2004 17:28:59 -0700, "Steven K. Knapp"
<steve.knappNO#SPAM@xilinx.com> wrote:

>Just FYI, there is an application note on this very topic that demonstrates
>how to configure a Xilinx FPGA from an SPI serial Flash using a small CPLD.
>The application note is written for CoolRunner-II, but practically any
>Xilinx CPLD will do.
>
>XAPP800:  Configuring Xilinx FPGAs with SPI Flash Memories Using
>CoolRunner-II CPLDs
>http://www.xilinx.com/bvdocs/appnotes/xapp800.pdf
>
>While we're on the subject, have you ever wanted to store additional
>information in the configuration memory (serial numbers, Ethernet MAC IDs,
>MicroBlaze code) and read it after the FPGA configures?  If so, the
>following application note may be of interest.
>
>XAPP694: Reading User Data from Configuration PROMs
>http://www.xilinx.com/bvdocs/appnotes/xapp694.pdf
>
>The two demo designs for the Spartan-3 Starter Kit also demonstrate this
>capability.
>http://www.xilinx.com/products/spartan3/s3boards.htm#RF
>
>---------------------------------
>Steven K. Knapp
>Applications Manager, Xilinx Inc.
>General Products Division
>Spartan-3/II/IIE FPGAs
>http://www.xilinx.com/spartan3
>---------------------------------
>Spartan-3:  Make it Your ASIC
>
>
>"Ray Andraka" <ray@andraka.com> wrote in message
>news:40F5AEB8.DDDC48C9@andraka.com...
>> I suppose you could use an SPI flash in conjuction with a cheap up like a
>PIC (some of those are less than a dollar,
>> and they even have one in a SOT23 package) to undercut the cost of the
>serial config ROMs.
>>
>>
>> --
>> --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
>>
>>
>
>




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