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 12750

Article: 12750
Subject: Re: DynaText **!?!?
From: Jan Martin Wagenaar <beerput@tip.nl>
Date: Tue, 27 Oct 1998 17:42:03 +0100
Links: << >>  << T >>  << A >>
There is a 'Dynatext.ini' somewhere on your PC. Probably in
'fndtn\bin\nt\'. 
Have a look at what's in there compared to what the installation manuals
say. Don't know which manual though. I seem to have more of them than I
have user manuals and library references.
If you have doubts on the contents; mail me and I'll have a look or mail
you my version. I have it running, but believe me, it still doesn't
work. I keep using my old PDF files from my previous version.

	Jan Martin Wagenaar
	beerput@tip.nl
	

Simon Bacon wrote:
> 
> Could the person at Xilinx who put their documentation in DynaText
> format please be put up against the wall.  PDF has many faults,
> but at least you can
> 
>    read it without fancy installation programs
>    read it on multiple platforms
>    copy an important file to floppy
>    see the pictures in the correct places
>    ...
> 
> Meanwhile, I have just installed DynaText three times, carefully rebooting
> each time, and the darned program still refuses to read books on the CD
> or on the hard disk.  The contents list is OK, then it puts up a message
> box with "cannot open footle".
> 
> Does anyone have any ideas on how to fix this?
> 
> Many thanks,
> Simon
Article: 12751
Subject: FYI: FPGA/Programmable Logic Topics at November Embedded Systems Conference
From: "Steven K. Knapp" <sknapp@optimagic.com>
Date: Tue, 27 Oct 1998 12:28:19 -0800
Links: << >>  << T >>  << A >>
EMBEDDED SYSTEMS CONFERENCE
(http://www.optimagic.com/conferences.html#Nov98),
1-5 November, 1998, San Jose, California, USA.

Tuesday, 3-NOV-98, Class
"Configurable Embedded Systems: Using Programmable Logic to Compress
Embedded System Design Cycles", Class 330, 10:30 am

Wednesday, 4-NOV-98
"Roll Your Own RISC" in FPGAs and ASICs, Class 402, 8:30 am
"Prototyping Embedded Microcontrollers in FPGAs", Class 470, 4:00 pm

Thursday, 5-NOV-98
"An Introduction to FPGA Design" (Part 1), Class 509, 8:30 am
"An Introduction to FPGA Design" (Part 2), Class 529, 10:30 am


--
-----------------------------------------------------------
Steven K. Knapp
OptiMagic, Inc. -- "Great Designs Happen 'OptiMagic'-ally"
E-mail:  sknapp@optimagic.com
   Web:  http://www.optimagic.com
-----------------------------------------------------------



Article: 12752
Subject: Wed. Night: "How To BS Your Way To Fame & Fortune In Consulting"
From: jcooley@world.std.com (John Cooley)
Date: Tue, 27 Oct 1998 20:36:42 GMT
Links: << >>  << T >>  << A >>

The Boston chapter of the IEEE Consultant's Network must *really* be
desperate for speakers, because they invited me to speak at their next
upcoming meeting this Wednesday, Oct. 28th.  (Yup, that's two days from
now.  Actually they asked me a few months ago -- it's just now that I'm
getting around to publishing it on ESNUG....)

Anyway, I'll be there and I'll be giving a talk on "How To Bullshit Your
Way To Fame & Fortune In Consulting".  Yes, this talk will have some "fun"
elements to it; but it's my intention to have a serious discussion about
the functions of truth, storytelling, fun, hard work, the Internet, and
various trade publications in the life of a consultant or career design
engineer in today's business world.  Master these and you'll be laughing
all the way to the bank.  Don't master these, and Dilbert's life will seem
more real than exaggerated humor to you.

                                         - John Cooley

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

         COST: Free!

  TIME & DATE: 7:00 PM, Wednesday night, Oct. 28th.

     LOCATION: Arthur D. Little, 22 Acorn Park, Cambridge.

   DIRECTIONS: From the West come down route 2, turn onto the exit for
               the Alewife T station and IMMEDIATELY turn right into
               Acorn Park.  Park in visitor's parking.

               From Boston, go out Storrow Drive, take route 2 west across
               the Charles into Cambridge. Continue out past the Alewife
               T station, circle back at the Lake Street exit and circle
               back east to the Alewife exit and Acorn Park.


   (Optional): Pre-meeting Dinner: 5:30 PM sharp at Bertucci's Pizza
               in the Alewife T-Station.


   Information: Voicemail (781-893-8379), E-mail: cn.boston@ieee.org,
   IEEE BBS: (781-890-5469), Web: http://www.boston-consult.org.
 
-----------------------------------------------------------------------------
  __))    "Glass ceilings?  Name ANY ex-goat farmer who's made management!"
 /_ oo  
  (_ \   Holliston Poor Farm                                   - John Cooley
%//  \"  Holliston, MA 01746-6222           part time Sheep & ex-Goat Farmer
%%%  $   jcooley@world.std.com       full time contract ASIC & FPGA Designer
Article: 12753
Subject: Re: Wed. Night: "How To BS Your Way To Fame & Fortune In Consulting"
From: Carl Horton <carlhorton66@hotmail.com>
Date: Tue, 27 Oct 1998 16:39:07 -0600
Links: << >>  << T >>  << A >>
Test

John Cooley wrote:

> The Boston chapter of the IEEE Consultant's Network must *really* be
> desperate for speakers, because they invited me to speak at their next
> upcoming meeting this Wednesday, Oct. 28th.  (Yup, that's two days from
> now.  Actually they asked me a few months ago -- it's just now that I'm
> getting around to publishing it on ESNUG....)
>
> Anyway, I'll be there and I'll be giving a talk on "How To Bullshit Your
> Way To Fame & Fortune In Consulting".  Yes, this talk will have some "fun"
> elements to it; but it's my intention to have a serious discussion about
> the functions of truth, storytelling, fun, hard work, the Internet, and
> various trade publications in the life of a consultant or career design
> engineer in today's business world.  Master these and you'll be laughing
> all the way to the bank.  Don't master these, and Dilbert's life will seem
> more real than exaggerated humor to you.
>
>                                          - John Cooley
>
> --------------------------------------------------------------------------
>
>          COST: Free!
>
>   TIME & DATE: 7:00 PM, Wednesday night, Oct. 28th.
>
>      LOCATION: Arthur D. Little, 22 Acorn Park, Cambridge.
>
>    DIRECTIONS: From the West come down route 2, turn onto the exit for
>                the Alewife T station and IMMEDIATELY turn right into
>                Acorn Park.  Park in visitor's parking.
>
>                From Boston, go out Storrow Drive, take route 2 west across
>                the Charles into Cambridge. Continue out past the Alewife
>                T station, circle back at the Lake Street exit and circle
>                back east to the Alewife exit and Acorn Park.
>
>    (Optional): Pre-meeting Dinner: 5:30 PM sharp at Bertucci's Pizza
>                in the Alewife T-Station.
>
>    Information: Voicemail (781-893-8379), E-mail: cn.boston@ieee.org,
>    IEEE BBS: (781-890-5469), Web: http://www.boston-consult.org.
>
> -----------------------------------------------------------------------------
>   __))    "Glass ceilings?  Name ANY ex-goat farmer who's made management!"
>  /_ oo
>   (_ \   Holliston Poor Farm                                   - John Cooley
> %//  \"  Holliston, MA 01746-6222           part time Sheep & ex-Goat Farmer
> %%%  $   jcooley@world.std.com       full time contract ASIC & FPGA Designer



Article: 12754
Subject: Re: Need VHDL tools for Win NT/ Win 95
From: "Tom Meagher" <tomm@icshou.com>
Date: Tue, 27 Oct 1998 19:25:22 -0600
Links: << >>  << T >>  << A >>
We use Modelsim PE--a GREAT VHDL simulator!!!! couldn't live without it.

We use Exemplar Galileo 4.2.2 --very nice tool-- highly recommended

We have Synplify 5.06, but honestly, in most of our applications, it falls short of Exemplar in important areas, such as true VHDL
compatibility.  I think they have improved the product quite a bit since 3.0, but we are now in the habit relying on the Exemplar
tool.  Synplify does have a nice user interface, though, and the HDL analyst is pretty good.

Actually, I think having 2 synthesis tools is a tremendous boon, since they ALL have bugs.

Tom Meagher





ovilup wrote in message <01bdfdfe$b7094340$4f62e2c1@timteh.dnttm.ro>...
>Hi everyone !
>
>I am looking for some EDA tools that are running under Win 95/ Win NT PC's.
>
>The tools should have :
>      - VHDL compiler & simulator
>      - FPGA synthesis
>      - some way to check that what goes out from synthesis is what you
>need
>
>Anyone knows some tools like that please let me know. I heard about
>PeakVHDL,
>but I need some other, for comparison. Price/quality is the issue here.
>
>Thank you, everybody.
>
>************************************************************
>Ovidiu Lupas
>Design Engineer
>TimTeh Electronics Ltd.
>
>e-mail      : ovilup@hotmail.com
>home e-mail : ovilup@mail.dnttm.ro      phone : 40-56-121951
>work e-mail : lupas@timteh.dnttm.ro phone/fax : 40-56-198943
>************************************************************


Article: 12755
Subject: Re: State machines in VHDL/Verilog
From: Le mer Michel <michel.lemer@ago.fr>
Date: Wed, 28 Oct 1998 09:34:47 +0100
Links: << >>  << T >>  << A >>
Daniel Jones wrote:

> In article <36313CC4.9FD3D096@yahoo.com>,
>         Rickman <spamgoeshere4@yahoo.com> wrote:
>
> >Todd Kline wrote:
> >>
> >> If I care about the state encoding, I don't use enumerated types.  I
> >> use three different synthesis tools, two different simulators, and
> >> target FPGA's and ASIC's.  Just the differences in '87 and '93 are
> >> enough to drive me nuts.  I stay away from all tool specific constructs.
> >> For portability, I prefer the following structure:
> >>
> >>   ...
> >>
> >>   signal grants:               std_logic_vector(3 downto 0);
> >>    constant NO_GRANTS:         std_logic_vector(3 downto 0) := "0001";
> >>    constant VIDEO_GRANT:       std_logic_vector(3 downto 0) := "0010";
> >>    constant AUDIO_GRANT:       std_logic_vector(3 downto 0) := "0100";
> >>    constant CPU_GRANT:         std_logic_vector(3 downto 0) := "1000";
> >>
> >>   ...
> >>   variable next_grant:         std_logic_vector(3 downto 0);
> >>   ...
> >>
> >>    case grants is
> >>    when VIDEO_GRANT =>
> >>      ...
> >>      if(expression) then
> >>        next_grant   := VIDEO_GRANT;
> >>      else
> >>        next_grant   := NO_GRANTS;
> >>      end if;
> >>      ...
> >>    when AUDIO_GRANT =>
> >>      ...
> >>    when CPU_GRANT   =>
> >>      ...
> >>    when others      =>                        -- NO_GRANTS case
> >>      ...
> >>    end case;
> >>
> >> Of course, if the case statement is inside a clk'event, you don't need
> >> the variable.
> >
> >Todd,
> >
> >This was exactly the type of code I wrote in my first attempt to use
> >VHDL to build a state machine. I did not trust the FPGA tools (too many
> >bad experiences in the past) to do what I wanted using the methods I
> >read in the VHDL books. The problem was that the synthesizer did not
> >know that to detect state "VIDEO_GRANT" it only needed a single input.
> >It would use all N state variables as the input for each condition in
> >the case (state_variable == "0001" rather than just state_variable(0) ==
> >'1'). The point of using one-hot encoding is to minimize the number of
> >signals needed to decode a given state. At least with my synthesis tool,
> >Metamor, it produced a very poor implementation.
> >
> >I fourn that I could work around this by getting rid of the case
> >statement and coding up each FF separately as someone posted earlier.
> >But that created a lot more work and is not as clear to read as a case
> >statement. But I can see where your tools and targets might not let you
> >do otherwise.
> >
> >Have you ever looked at the logic produced by the above type of code? Is
> >it smart enough to figure out that it only needs to look at one bit to
> >determine each state?
> >
> >
> >--
> >
> >Rick Collins
> >
> >redsp@XYusa.net
> >
> >remove the XY to email me.
>
> Just a comment to re-enforce Rick's statement. I learned verilog and
> Synopsys DC Compiler at the same time while doing my first FPGA.
> My examples to state machine design were given to me by another team
> who had just finished an ASIC. They were lovely. Easy to read and easy
> to modify and slow as hell in a Xilinx part. What I learned is that
> wide decodes are a real problem in a coarse-grain FPGA architecture.
>
> I then went an looked at Synopsys examples for one-hot state machines
> using compiler directives and enumerated states. One minor problem. A
> nice thing about one hot state machines is that you identify a state
> with just a few i.e. one or two state bits. Synopsys only supports very
> archane ways to make the one-hot state bits visible outside of the state
> machine and then recommends against using those methods.
>
> I've gone to explicit F/F state machines, but they are a serious pain
> to modify, because the state information is distributed, difficult to
> extract, there is no checking being done by the synthesizer. However,
> there is another thing. I don't really build one-hots, because it takes
> as much decoding to shut off the previous state as it does to turn on
> the next state except that one or the other must be inverted. And, of
> course, if one state goes to a number of possible states then it becomes
> the decode problem instead of the next state.
>
> TANSTAAFL,
>
> Dan Jones
>
> As time has gone on, I have

What are the main advantages of the one-hots?

Article: 12756
Subject: jobs @ Lucent
From: ejob <engineer@ejob.com>
Date: Wed, 28 Oct 1998 02:17:08 -0800
Links: << >>  << T >>  << A >>

--------------73C9C2859F6F477B0C14C781
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

http://www.ejob.com/lucent3.htm

--------------73C9C2859F6F477B0C14C781
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML>
<FONT COLOR="#000099"><FONT SIZE=+3><A HREF="http://www.ejob.com/lucent3.htm">http://www.ejob.com/lucent3.htm</A></FONT></FONT></HTML>

--------------73C9C2859F6F477B0C14C781--

Article: 12757
Subject: I2C core design
From: "ovilup" <ovilup@hotmail.com>
Date: 28 Oct 1998 11:59:43 GMT
Links: << >>  << T >>  << A >>
Hello !

I am very new in FPGA design! Frankly, this is my first design. I have some
questions, but, please don't laugh at me :

* my I2C controller should have some internal registers to allow user
settings. These registers
should be defined as 8bit registers (entity and arch) or simple defined as
internal signals?

* I already developped the master, slave protocols, frequency clock
prescaller. Now I am
designing the SCL clock generator. When I am designing a clock divider
(i.e. div by 2),
is it sufficient to describe the clocks behaviour, or should I describe the
circuit topology ?

Thank you!
-- 

************************************************************
Ovidiu Lupas
Design Engineer
TimTeh Electronics Ltd.

e-mail      : ovilup@hotmail.com                     
home e-mail : ovilup@mail.dnttm.ro      phone : 40-56-121951
work e-mail : lupas@timteh.dnttm.ro phone/fax : 40-56-198943
************************************************************
Article: 12758
Subject: Re: Altera MAXPLUS2 V9 slow.
From: Virtual <sxyzami@pacifier.com>
Date: 28 Oct 1998 21:51:12 +0800
Links: << >>  << T >>  << A >>
Eric Pearson <ecp@focus-systems.nospam.on.ca> wrote:
> Has anyone noticed problems in re-compiling designs that worked in v8.0 of
> maxplus2 under v9.01 and found comilation times went throught the roof even
> to the point excess ( I aborted after 100 hours v9 vs 1 hour under v8 ).

You may want to perturb your design (timing constraint) a little bit.
I have seen 100+ hours compile times with some 6.x version on a 
design that normally compiled in 1 - 2 hours.   Changing the timing 
by 0.1 Mhz fixed it. 
Article: 12759
Subject: Re: Q: Configure FPGA from an ISA bus?
From: husby@fnal.gov (Don Husby)
Date: Wed, 28 Oct 1998 14:50:15 GMT
Links: << >>  << T >>  << A >>
AT_farhad_abdolian@hotmail.com wrote:
> I want to make it as cheap as possible and want to configure the board
>  directly from the ISA bus.
> 
> My plan is to have a small PLD (16V8) to decode the main address of the board,
> and a 245 on the data bus.

I've done this with a Lucent  ORCA FPGA connected directly to the
ISA data bus.  I download the configuration using asynchronous
peripheral mode, using a 22V10 PAL to decode the address.

The ORCA configuration modes are almost identical to Xilinx's
so this would probably work just as well with Xilinx parts.

For schematic and PAL equations see:
  http://www-ese.fnal.gov/eseproj/svx/bert/pbert_sch.pdf
  http://www-ese.fnal.gov/eseproj/svx/bert/isapal.txt

Article: 12760
Subject: Re: State machines in VHDL/Verilog
From: Rickman <spamgoeshere4@yahoo.com>
Date: Wed, 28 Oct 1998 10:47:54 -0500
Links: << >>  << T >>  << A >>
Le mer Michel wrote:
> What are the main advantages of the one-hots?

One-hot encoding will make most FSMs run faster and can be simpler to
decode. But that depends strongly on the structure and size of your
machine. If your FSM diagram has a lot of arrows going in and out of
individual states, the logic can become very complex for that node. If
the state diagram is more simple with little branching, a one-hot
encoding can be quite simple and results in very high speeds of
operation. 

The output decoding depends on your output assignments. If you have
outputs that are a function of a small number of states, the decoding is
simple. If your outputs depend on a lot of states, then the decoding
requires more logic. Binary encoding always uses the full set of state
signals, but that is usually much less than the number of one-hot
signals. 

Of course, one-hot encoding always uses more FFs than binary encoding
except for very small machines. But this is frequently not a problem in
FPGAs or ASICs. 


-- 

Rick Collins

redsp@XYusa.net

remove the XY to email me.
Article: 12761
Subject: Re: New free FPGA CPU
From: albaugh@agames.com (Mike Albaugh)
Date: 28 Oct 1998 17:01:50 GMT
Links: << >>  << T >>  << A >>
	In general this sounds really neat. I wanted to respond to
Peter's comment, though:

Peter (z80@ds1.com) wrote:

: >- It is not compatible with anything.  I was originally considering making
: >  a 6502 clone, but this is smaller and better (and I didn't want to
: >  implement decimal mode).  I'll write an assembler for it, hopefully for
: >  this first release (I need to write one to test it anyway).

: Make sure it runs in the DOS box of NT4 :)  And returns the various
: errorlevels, so it can run out of a makefile.

	Please make sure it can run on something _other_ than DOS. I managed
to miss DOS _almost_ completely, but now find myself using it and _pining_
for the days of paper-tape and KSR33s :-(

: >  stack and add a 7-bit offset).  Note that it does not have direct
: >  addressing- you have to put the address on the stack first.  I chose to
: >  make it powerful enough to use data structures easily above the
: >  convenience of direct addressing.

: Interesting. This however seems to favour HLL support, whereas such a
: CPU would normally be programmed in asm. Being able to do

:  ld hl, (543dh)

: is rather useful.

	I have to beg to differ. I am far more likely to want to load
a pointer to some device _once_, then diddle the registers of that
device with short instructions, than to actually _want_ to encode
absolute addresses for every reference. This is one of those "works
great for trivial problems but quickly becomes a pain in the butt"
issues. Like BASIC :-)

: >- It has interrupts.  When there's an interrupt, all of the registers are
: >  pushed on the stack.  To return from the interrupt, pop all of the registers
: >  off of the stack using the 'pop' instruction.  'pop' is also used for
: >  subroutine returns.

: Nice. How fast is this pushall/popall?

	And, how do you return a value if your registers are "restored"
(i.e. clobbered) by a return? :-)

: >- I haven't decided where the reset or interrupt vectors or addresses are
: >  going to be yet.

: Will you be doing vectored ints, where the device can supply half the
: vector? I think that would be overkill, since it needs complex
: peripherals and it is far easier to simply encode each of say 8 /IRQ
: sources into eight equally spaced addresses.

	Agreed, although a "vector base register" (even a single bit)
would be useful, so initial vectors can come from ROM and you'd still
have a choice to use RAM once you were "up". OTOH, if you are pushing
and popping a bunch of stuff on every IRQ, the cost of a jump is
probably "in the noise"...

					Mike
| albaugh@agames.com, speaking only for myself
Article: 12762
Subject: Re: New free FPGA CPU
From: dominicr@bnr.ca (Dominic Richens)
Date: 28 Oct 1998 18:07:14 GMT
Links: << >>  << T >>  << A >>

In article <F1GysE.EKA@world.std.com>, you write:
|> Remember the last comp.arch discussion about minimalist CPUs about six months
|> ago?  It started, as usual, with the discussion about 1-instruction CPUs and
|> the like, but it ended with a discussion about the best CPU you could fit in
|> a small FPGA?

Interesting post, what really peaked my interest was:

 -- 
/*  jhallen@world.std.com (192.74.137.5) */               /* Joseph H. Allen */
int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0)
+r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2
]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}

...which reminded me of this, what I had squirreled away on a tape in 1991:

/*  jallen@ic.sunysb.edu  */     /* Amazing */     /* Joe Allen 129.49.12.74 */
int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0)
+r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2
]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}

YOU LAZY BUM! You haven't put out a new release in over 7 years! :-):-):-):-)

dominic
-- 
!@$^&*)($#$@!@#$^&*()_+_)(*&^$#@!$^&*()_+)(*&^$#@$^&*+_(*&^$#@#^&*()&*$#@(*&+
    Dominic Richens | dominicr@nortel.ca | (613) 765-5840 | Concorde ATM 
     Nortel Technologies, Dept. 9P23, 3500 Carling, Ottawa, ON, K2H 8E9
      "There are 42 billion people on earth.  Where are they hiding?"    McQ!
Article: 12763
Subject: Re: FPGA Decouple Capacitor values
From: Tom Burgess <tom.burgess@hia.nrc.ca>
Date: Wed, 28 Oct 1998 10:30:48 -0800
Links: << >>  << T >>  << A >>
Those interested in these issues can find some useful info on a
page run by Howard Johnson (author of "High-speed Digital Design").
http://www.sigcon.com/
The newsletter archive contains some gems. My current persuasion
is that thick traces from cap to power pin are only an approximation
to the thickest trace possible (the power/ground plane), so I connect
to the plane as close as possible to the device and capacitor pins,
with multiple vias. The impedance of even a 100 mil trace is going
to pretty high. Also that most of the really high frequency energy is
going to be supplied by the power/ground plane
capacitance, so you want the dialectric as thin as possible between
power/ground planes to maximize capacitance. For example, a power and
ground plane separated by 0.010 in. of FR-4 dialectric gives a
capacitance of 100 pF per square inch of nice distributed bypassing,
for free! The bypass caps are just there to recharge the plane
capacitance.

My 2 cents worth.


Tom Burgess
-- 
Digital Engineer
National Research Council of Canada
Herzberg Institute of Astrophysics
Dominion Radio Astrophysical Observatory
P.O. Box 248, Penticton, B.C.
Canada V2A 6K3

Email:        tom.burgess@hia.nrc.ca
Office:       (250) 490-4360 
Switch Board: (250) 493-2277
Fax:          (250) 493-7767
Article: 12764
Subject: Re: New free FPGA CPU
From: billm@cygnus.com (TTK Ciar)
Date: 28 Oct 1998 11:36:08 -0800
Links: << >>  << T >>  << A >>
In article <717ilu$qdh$1@void.agames.com> albaugh@agames.com (Mike Albaugh) writes:
>: >- It has interrupts.  When there's an interrupt, all of the registers are
>: >  pushed on the stack.  To return from the interrupt, pop all of the registers
>: >  off of the stack using the 'pop' instruction.  'pop' is also used for
>: >  subroutine returns.
>
>: Nice. How fast is this pushall/popall?
>
>	And, how do you return a value if your registers are "restored"
>(i.e. clobbered) by a return? :-)

  Presumably you'd change the copy of the register on the stack before
returning.

[..interrupt vector layout..]
>	Agreed, although a "vector base register" (even a single bit)
>would be useful, so initial vectors can come from ROM and you'd still
>have a choice to use RAM once you were "up". OTOH, if you are pushing
>and popping a bunch of stuff on every IRQ, the cost of a jump is
>probably "in the noise"...

  This thing's supposed to be tiny, though, silicon-wise..  IMO, to
avoid eating more real estate you should have *one* interrupt vector
and a fixed word location in memory where the IRQ id# is stored.
Then you can put code at the interrupt service address which looks
at the id# and decides what to do from there.  It only ends up taking
a little more RAM (for the ISR code), which I understand is expected 
to be off-chip (eg, not like the PIC processor), and therefore cheap.

  -- TTK

Article: 12765
Subject: !Recommendation wanted! Which CAD for shematic entry of Xilinx FPGA'based devices choose
From: Ilia Oussorov <oussorov@prakinf.tu-ilmenau.de>
Date: Wed, 28 Oct 1998 20:53:37 +0100
Links: << >>  << T >>  << A >>
1.Can you recomend me some CADs for shematic entry of  XILINX FPGA based

devices?
Whre can I get "try and buy" copies?
(I know Viewlogic and Xilinx Foundation series.)
I have to choose one software for buying.
May be you write small comparision or your experience.

Do you know places in internet wher I can get as examples realized
devices?

Article: 12766
Subject: Re: Schematic entry?
From: s_clubb@NOSPAMnetcomuk.co.uk (Stuart Clubb)
Date: Wed, 28 Oct 1998 21:03:44 GMT
Links: << >>  << T >>  << A >>
On Fri, 23 Oct 1998 10:14:32 -0500, "Glenn E. Hunt"
<glennee@flash.net> wrote:

<snip>
>One design team I know of got so frustrated with its inability to comprehend
>the hierarchical structure of a device's HDL that they recast the design
>into a top-level schematic of "black boxes" and put the HDL implementation
>code under those, a technique that can obviously be extended as deeply into
>a hierarchy as one desired.

Renoir Block anyone?

>My desire is for some way to make HDL code as comprehensible as schematics.
>One possible help is an editor that allows an outline mode, like what is

Turbo Writer

>available in word processors (the Transputer code development tools work
>this way), to allow collapsing of structure so that modules are listed at
>the same level of indentation, but that still does not show what is
>connected to what.  Better is something like the hierarchical architectural
>view provided by Synplicity (I don't know if other tools have this) but the

Model Technology have had that quite a time with the Design Structure
view. Exemplar had it way back with Leonardo. You can do something
useful with it too, like manipulate the hierarchy. It's in Spectrum
too.

Renoir also gives you a hierarchical "Windows Explorer-like" view of
your design hierarchy.

<snip>

Lucky me. In my day job I sell all four of the above, so it probably
makes me biased :-)

www.saros.co.uk

Cheers
Stuart
For Email remove "NOSPAM" from the address
Article: 12767
Subject: Re: FPGA Decouple Capacitor values
From: Steve Casselman <sc@vcc.com>
Date: Wed, 28 Oct 1998 13:26:17 -0800
Links: << >>  << T >>  << A >>
Richard Schwarz wrote:

> I read a XILINX technote that seemed to indicate that .1uf caps were
> barely adequate for decouple. What value decouple caps are generally
> reccomended with E, XL, XLA, and Spartan FPGAs for circuits in the 10,
> 50, 100 MHz ranges.
>
> --
> __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/
>
>     Richard Schwarz, President
>     Associated Professional Systems Inc. (APS)
>     email: richard@associatedpro.com
>     web site: http://www.associatedpro.com
>     Phone: 410-569-5897
>     Fax:   410-661-2760
>
> __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/

  Maybe I'm just paranoid but I always use a 10uF
cap near the point where the power comes on
to the board and then I use a .1uF and a .001uF
cap for each power pin.

--
Steve Casselman, President
Virtual Computer Corporation
http://www.vcc.com


Article: 12768
Subject: Re: New free FPGA CPU
From: jhallen@world.std.com (Joseph H Allen)
Date: Wed, 28 Oct 1998 22:24:36 GMT
Links: << >>  << T >>  << A >>
In article <717rn8$4uh$1@andros.cygnus.com>, TTK Ciar <billm@cygnus.com> wrote:
>In article <717ilu$qdh$1@void.agames.com> albaugh@agames.com (Mike Albaugh) writes:
>>: >- It has interrupts.  When there's an interrupt, all of the registers
>>: >  are pushed on the stack.  To return from the interrupt, pop all of
>>: >  the registers off of the stack using the 'pop' instruction.  'pop' is
>>: >  also used for subroutine returns.

>>: Nice. How fast is this pushall/popall?

>>	And, how do you return a value if your registers are "restored"
>>(i.e. clobbered) by a return? :-)

>  Presumably you'd change the copy of the register on the stack before
>returning.

Push and pop each have a 3-bit field which selects which registers are to be
saved/restored, like on the 6809 and (if I remember correctly) the VAX. 
This ended up being trivial to implement, so I did it.  Basically each bit
causes you to skip two flip-flops in the one-hot-bit state machine for these
instructions (actually you have to detect which reg is going to be last
ahead of time as well).

Anyway, you can just pop the program counter and return the accumulator and
flags register unchanged if you want.  I have 5 extra bits in these
instructions and am thinking of using them for a stack adjustment value,
but it costs one extra cycle.

>[..interrupt vector layout..]
>>	Agreed, although a "vector base register" (even a single bit)
>>would be useful, so initial vectors can come from ROM and you'd still
>>have a choice to use RAM once you were "up". OTOH, if you are pushing
>>and popping a bunch of stuff on every IRQ, the cost of a jump is
>>probably "in the noise"...

The brk (software interrupt) instruction has 8 extra free bits, so they will
probably become the lower half of the PC.  There probably won't be vectors
for hardware interrupt or reset- just fixed addresses.  Vectors take more
cycles.  However, it would be easy to bring out some of the lines from this
fixed address, and have interrupt address selection done that way.

Here are the cycle times for all of the instructions:
(r=read, w=write, d=dead):

jmp direct:		4 (3r, 1d)
jmp indirect:		6 (4r, 2d)
jcc direct:		4 (3r, 1d)
jsr direct:		5 (3r, 2w)
jsr indirect:		7 (4r, 2w, 1d)
push:	(1d+2r+5w)	3+(2 for ac)+(2 for pc)+(1 for flags)	(4 - 8 cycles)
pop:	(1d+7r)		3+(2 for ac)+(2 for pc)+(1 for flags)	(4 - 8 cycles)
brk/irq:		8 (2r, 5w, 1d)

operate instructions:

ac-stack byte:		4 (3r, 1d)
ac-stack word:		5 (4r, 1d)
ac-indexed byte:	7 (5r, 2d)
ac-indexed word:	8 (6r, 2d)
r.m.w. byte stack:	5 (3r, 1w, 1d)
r.m.w. word stack:	7 (4r, 2w, 1d)
r.m.w. byte indexed:	8 (5r, 1w, 2d)
r.m.w. word indexed:	10 (6r, 2w, 2d)
immediate byte:		2 (2r)
immediate word:		3 (3r)

worse case interrupt latency is 18 cycles (the longest instruction is 10
cycles and interrupt servicing takes 8 cycles).

There are several ways I could improve these timings, but they all cost
varying degrees of extra hardware, or greater cycle times:

- Add an output mux after the address register which would allow a direct
  path from the data input register to the address bus.  This would make
  jumps (but not jsrs) one cycle shorter.  It gives you less time to access
  memory however, so the maximum clock frequency would be a little lower.

- Add a direct path from the ALU output to the address bus.  This would
  eliminate most dead cycles but would reduce the maximum clock frequency by
  a lot, maybe 50%, since the ALU would be in series with the memory.

- Do the first address calculation for the operate instructions, jump
  indirect, push and pop during decode (would reduce these by one cycle). 
  The cost is decode being done in series with ALU operation, so the
  frequency would be lower.  Also, the immediate instructions would be one
  cycle longer unless I add a seperate incrementor for the PC (right now the
  ALU does it).

- Try to prefetch the next instruction.  This would have no effect on
  jump (unless you want a branch delay slot, which would be ridiculous on
  such a small CPU) or pop, but would reduce operate instructions by one
  cycle each.  Interrupts are a little more complex if I do this- I would
  have to refetch the prefetched instruction when you return from
  interrupts.  Also it may not reduce the times of some instructions since
  the PC increment uses the ALU (but again, if there was a separate
  incrementor this wouldn't be a problem).

Anyway, I'm trying for the least amount of hardware so I'm not going to do
any of these for this version.
-- 
/*  jhallen@world.std.com (192.74.137.5) */               /* Joseph H. Allen */
int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0)
+r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2
]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}
Article: 12769
Subject: Re: !Recommendation wanted! Which CAD for shematic entry of Xilinx FPGA'based devices choose
From: msimon@tefbbs.com
Date: Thu, 29 Oct 1998 01:38:24 GMT
Links: << >>  << T >>  << A >>
The Xilinx student edition is good enough. (I like Orcad better). At
$90 integrated with the rest of the tools it is a steal.

Simon
=========================================================
Ilia Oussorov <oussorov@prakinf.tu-ilmenau.de> wrote:

>1.Can you recomend me some CADs for shematic entry of  XILINX FPGA based
>
>devices?
>Whre can I get "try and buy" copies?
>(I know Viewlogic and Xilinx Foundation series.)
>I have to choose one software for buying.
>May be you write small comparision or your experience.
>
>Do you know places in internet wher I can get as examples realized
>devices?
>

Design Your Own MicroProcessor(tm) http://www.tefbbs.com/spacetime/index.htm
Article: 12770
Subject: 8051 VHDL Model
From: "Mankit Wong" <lsckwong@netvigator.com>
Date: 29 Oct 1998 02:39:08 GMT
Links: << >>  << T >>  << A >>
Hi there,

Could anyone tell me where I can get 8051 VHDL Model for free in the
Internet?

Thanks,
Kit
Article: 12771
Subject: Re: State machines in VHDL/Verilog
From: Ray Andraka <no_spam_randraka@ids.net>
Date: Thu, 29 Oct 1998 01:22:27 -0500
Links: << >>  << T >>  << A >>


Le mer Michel wrote:

> What are the main advantages of the one-hots?

 Speed, routability and decoded states.  As long as the number of branches into
any state are small, the logic feeding each state is kept simple.  Simple logic
means one level implementation,  which means smokin' speed.  Since the logic is
simple, the routing is not congested which means you got a better shot of making
it work.  Finally, since a one-hot already has decoded states, you are freed from
doing decode, which means no decode delays and no glitches.  Of course your
design IS synchronous, so you are not worried about the glitches, right?

--
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email randraka@ids.net
http://users.ids.net/~randraka


Article: 12772
Subject: Re: Q: Configure FPGA from an ISA bus?
From: Ray Andraka <no_spam_randraka@ids.net>
Date: Thu, 29 Oct 1998 01:32:14 -0500
Links: << >>  << T >>  << A >>


Don Husby wrote:

> AT_farhad_abdolian@hotmail.com wrote:
> > I want to make it as cheap as possible and want to configure the board
> >  directly from the ISA bus.
> >
> > My plan is to have a small PLD (16V8) to decode the main address of the board,
> > and a 245 on the data bus.
>

No need to use the '245 or the PAL in most instances for an ISA bus interface.   A
xilinx 4K device has enough drive and speed to connect directly to the ISA.  If you
are a 16 bit board, you may have to drive IOCS16 or MEMCS16 with two paralleled pins
to meet the 20mA sink requirement, depending on which device you use.  The decode in
a -2 device is plenty fast for ISA as long as you keep the address pins, AEN and the
IOCS16 pins close together.  This will satisfy your frugal side, saving you $2 or so
for the 245's, the PAL and the labor to program and stuff them.

--
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email randraka@ids.net
http://users.ids.net/~randraka


Article: 12773
Subject: Re: !Recommendation wanted! Which CAD for shematic entry of Xilinx FPGA'based devices choose
From: Ray Andraka <no_spam_randraka@ids.net>
Date: Thu, 29 Oct 1998 01:39:44 -0500
Links: << >>  << T >>  << A >>
Depends on how much you're going to use it.  If you are doing designs with
it day in and day out, spend the money and get viewlogic.  If it's for one
design, save some $ and use xilinx foundation (of course with foundation you
lose the capability to do board level capture and capture for other
devices).  The Aldec tool in foundation is fine for the casual user, but if
you are used to having the features of viewlogic, you will quickly get
frustrated with it.  Last time I looked at OrCad, it still was geared more
toward board level development.  It is clunky for hierarchical design (which
is how you should be working in the FPGA).

Ilia Oussorov wrote:

> 1.Can you recomend me some CADs for shematic entry of  XILINX FPGA based
>
> devices?
> Whre can I get "try and buy" copies?
> (I know Viewlogic and Xilinx Foundation series.)
> I have to choose one software for buying.
> May be you write small comparision or your experience.
>
> Do you know places in internet wher I can get as examples realized
> devices?



--
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email randraka@ids.net
http://users.ids.net/~randraka


Article: 12774
Subject: Re: I2C core design
From: Thomas Riesenberg <thomasr@msil.sps.mot.com>
Date: Thu, 29 Oct 1998 09:06:08 +0200
Links: << >>  << T >>  << A >>
ovilup wrote:
> 
> Hello !
> 
> I am very new in FPGA design! Frankly, this is my first design. I have some
> questions, but, please don't laugh at me :
> 
> * my I2C controller should have some internal registers to allow user
> settings. These registers
> should be defined as 8bit registers (entity and arch) or simple defined as
> internal signals?
> 
> * I already developped the master, slave protocols, frequency clock
> prescaller. Now I am
> designing the SCL clock generator. When I am designing a clock divider
> (i.e. div by 2),
> is it sufficient to describe the clocks behaviour, or should I describe the
> circuit topology ?
> 
> Thank you!
> --
> 

1. Internal signals
2. One of them

-- 
*****************************************
* Thomas Riesenberg                     *
* Motorola Semiconductor                *
* mailto: thomasr@msil.sps.mot.com      *
*****************************************


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