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

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

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

Custom Search

Messages from 12700

Article: 12700
Subject: DynaText **!?!?
From: Simon@NOTtile.demon.co.uk (Simon Bacon)
Date: Fri, 23 Oct 98 21:45:45 GMT
Links: << >>  << T >>  << A >>
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: 12701
Subject: Re: Xilinx may not support schematics for Virtex/or Rita
From: pak@cse.ucsc.edu (Pak K. Chan)
Date: 23 Oct 1998 22:26:22 GMT
Links: << >>  << T >>  << A >>
>> >Gee, Rita, how many designs do YOU have shipping in REAL products?  Hum?

   I do know the answer to this one :)

>> >
>> A couple of weeks ago Rita posted something to the effect of 20 or so
>> modifications of a design to get it right.  I think that speaks for itself.
>>
>> Hope she never designs an ASIC!  All I can say is her name is definitely on
>> one of my lists and its not the list where your name is Austin.
>

  Sorry to waste a bit of bandwidth here to clean house.
  It suffices to say that the person posting is not Rita herself;
  and it is against our school's policy to use another's
  computer account.
                                        P.K. Chan

Article: 12702
Subject: 3.3V FPGAs on the ISA bus?????
From: Richard Schwarz <aps@associatedpro.com>
Date: Fri, 23 Oct 1998 20:03:14 -0400
Links: << >>  << T >>  << A >>
I have a working design which has XILINX 4028EX (5v) FPGAs tied directly
to the ISA bus and am planning to update the design with 3.3 volt XL/XLA
FPGAs. I am wondering if anyone has placed XL chips directly on the ISA
Bus. If anyone (Peter Alfke??) has any experience with this please give
me a responce back on email.

Thank You

Richard

--
__/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/

    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

__/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/


Article: 12703
Subject: Re: Fast multiplier, FPGA & ASIC
From: madarass@cats.ucsc.edu (Rita Madarassy)
Date: 24 Oct 1998 00:09:17 GMT
Links: << >>  << T >>  << A >>
In article <36306D37.2B2EC438@ids.net>,
Ray Andraka  <no_spam_randraka@ids.net> wrote:
>Yes it is.  However, you can reduce the size and routing complexity by using
>smaller multipliers (eg 16x16) and cmbining the results using partial
>products.

A 32x32 multiplier can easily take more than 1000LUTS.  It will probably
be the most expensive multiplier you have ever built.  Unless you
implement a partial-multiply-accumulate version of the multiplier
that will require 4 or 5 cycles to get the final output without pipelining.




>
>Francis wrote:
>
>> Dear all,
>>     Is it possible routing a 32x32bits fast multiplier (partial product,
>> Booth recording, carry save adder and Wallace tree) on FPGA and ASIC (2
>> metal layer)? Thanks!
>
>
>
>--
>-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: 12704
Subject: Re: gray code counter in a Xilinx fpga???
From: Ray Andraka <no_spam_randraka@ids.net>
Date: Fri, 23 Oct 1998 20:41:13 -0400
Links: << >>  << T >>  << A >>
I wrote this in haste this morning.  A bit of a clarification is in order.  An LFSR
counter consists of a shift register whose serial input is fed by the 1 bit sum of
selected taps off the shift register (that sum may have 1 added to it, depending if it
is an XNOR or an XOR).  The next count is the current count shifted one bit, with the
serial input equal to the sum mentioned above.  For arguments sake, lets say that the
counter shifts right for the forward sequence so that the new bit is shifted into the
MSB. To reverse the sequence, you need to generate the previous count instead of the
next count.  This means that the shift is in the opposite direction (in this case
left), and the new bit appears at the opposite end (in this case the LSB).  Reversing
the count is then reduced to changing the shift direction and determining the value of
the new bit.

To determine the value of the new bit for a reversed sequence, you need to recognize
that the new bit in the forward sequence is the sum of the tapped bits, and that after
clocking all the bit values remain in the counter except the one that was shifted off
the end.  The bit about to be shifted off the end is always part of the feedback, as it
defines the length of the counter.  The bit shifted off the end in the forward count is
the same value as the new bit in the reverse sequence.  Since the new bit in the
forward sequence is the sum of the selected taps, you can recover the value of the bit
that was last shifted out by subtracting the tap values from the new bit.  Since the
subtraction is also one bit, it is equivalent to adding and is accomplished with an XOR
or XNOR the same as the forward sequence.  Note that the taps for the reversed sequence
need to be shifted by one bit in the forward direction to grab the taps values that
were used to create the forward new bit.

In the case of the 16 bit LFSR I gave as an example this morning, the forward sequence
shifts into bit 15, the sum of bits 12, 3, 1 and 0.  In this case the tap at bit 0
defines the length of the counter.  To reverse the sequence, the shift direction is
reversed, and the feedback is from bits 15,11,2 and 0.  Tap 15 is the previous forward
count's sum, and taps 11, 2 and 0 are the previous values from taps 12, 3 and 1 that
contributed to the sum now in bit 15.

Ray Andraka wrote:

> Gerhard Hoffmann wrote:
>
> > > > > The conversion from binary to Gray code is not too bad. The best solution
> > > > > might be to implement a fast binary counter, then convert the binary to
> > > > > Gray.
> > > > >
>
> Problem with converting like this is you wind up with glitches because more than
> one register is changing at a time.  Kind of misses the point of using gray code in
> the first place.
>
> > Does anybody know a way to make an _UP/DOWN_  lfsr counter?
> >
> > Now I'm using a binary counter + lookup table in a ram to simulate this
> > for a ranging application, but the ram takes much more power than the
> > 4013E & too many pins.
>
>  yes.  It really is rather straight forward.  The direction of shift is reversed,
> so you need a mux in front of each flip flop.  The input for the reversed LFSR is
> essentially the previous bit instead of the next bit, so the taps are just shifted
> with respect to where they were for the forward lfsr. For example, a 16 bit LFSR in
> the forward direction looks like:
>    + -> 15 14 13 12 11 10  9  8  7  6  5  4  3  2  1  0
>    |                       |                                      |         |   |
>    +---------------+--------------------------+-----+-+
> to reverse it, you reconnect like:
>            15 14 13 12 11 10  9  8  7  6  5  4  3  2  1  0<-+
>             |                   |                                      |         |
> |
>             +------------+--------------------------+-----+--+
> So, what you are doing is grabbing the bits that would have produced the previous
> input to reconstruct the previous input.



--
-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: 12705
Subject: Re: 3.3V FPGAs on the ISA bus?????
From: Ray Andraka <no_spam_randraka@ids.net>
Date: Fri, 23 Oct 1998 20:48:05 -0400
Links: << >>  << T >>  << A >>
Works fine.  I'm in the lab now with a design that has a 4036XL directly on
an ISA bus.  If you are a 16 bit IO card, you'll need to parallel two pins
to drive IOCS16, as it requires a 20mA sink.  The 4036XL can only provide
12mA sink per pin.  I believe the same is true for IOCHK, IORDY and the
equivalent memory space feedbacks, if you are using those signals.


Richard Schwarz wrote:

> I have a working design which has XILINX 4028EX (5v) FPGAs tied directly
> to the ISA bus and am planning to update the design with 3.3 volt XL/XLA
> FPGAs. I am wondering if anyone has placed XL chips directly on the ISA
> Bus. If anyone (Peter Alfke??) has any experience with this please give
> me a responce back on email.

--
-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: 12706
Subject: Re: DynaText **!?!?
From: Ray Andraka <no_spam_randraka@ids.net>
Date: Fri, 23 Oct 1998 20:50:53 -0400
Links: << >>  << T >>  << A >>
How about a guilotine?  Nothing quite like cluttering the machine up with a
bunch of non-standard documentation readers!
--
-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: 12707
Subject: Re: Xilinx F1.5/FPGA Express wackiness (& Floorplanner)
From: Ray Andraka <no_spam_randraka@ids.net>
Date: Fri, 23 Oct 1998 21:10:01 -0400
Links: << >>  << T >>  << A >>


> Anyone else out there consider floorplanner as indespensible as I do?
> Contact Xilinx and let them know.  And tell them to get off their
> "push-button" automatic non-guided design flow paradyme.  Give us the tools
> we need to create and guide an efficient highest performance design.  I still
> say a brain is the most highly advanced A.I. computer ever (amazingly
> portable and low power, too.).  Let us use it, Xilinx!
>
> (OK, I'm off my soapbox now)
>
> Incidently, I realize there is now floorplanner support in M1.5 for 4000 and
> Spartan series.  (At least its there.)  But the way they implemented it, its
> pretty obvious they don't expect many people to use it.  Non-intuitive and
> awkward!  In XACT6 it was easy and natural.

Yeah, it's still kind of broken...at least compared to the Xact 6 stuff.  I
suppose I should be glad that it is better than the 1.4 floorplan beta
release...now that was the definition of clunky.  Rather disappointing at best.
There are also some CLB packing and carry function combinations that worked fine
in XACT 6 that the M1 mapper doesn't like.  With the push toward Virtex, I'd be
surprised if these even get fixed, as they only really effect the power users.
FWIW, I still use XACT6 when I can get away with it.  If it is important to you,
complain loudly or it might be gone for good.


--
-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: 12708
Subject: Re: Need VHDL tools for Win NT/ Win 95
From: wallace_exemplar@my-dejanews.com
Date: Sat, 24 Oct 1998 01:40:29 GMT
Links: << >>  << T >>  << A >>
In article <01bdfdfe$b7094340$4f62e2c1@timteh.dnttm.ro>,
  "ovilup" <ovilup@hotmail.com> wrote:
> 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.

For synthesis (FPGA or ASIC), you should certainly compare with the new
LeonardoSpectrum (tm) release from Exemplar Logic (http://www.exemplar.com).
The Win 95/Win NT version is shipping now; Unix versions
are in Beta.  Evaluation licenses are available through the web site.
You can get LeonardoSpectrum (tm) together with Model Technologies' ModelSim
simulation environment - check with an Exemplar sales rep for details.

Dave Wallace

Note: I am affiliated with Exemplar Logic, but am not speaking
on behalf of the company or in any official capacity.  Comments
above are based on my personal knowledge and opinions only.

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum
Article: 12709
Subject: Re: Fast multiplier, FPGA & ASIC
From: Ray Andraka <no_spam_randraka@ids.net>
Date: Fri, 23 Oct 1998 21:48:42 -0400
Links: << >>  << T >>  << A >>
See the page on multiplication in FPGAs on my website.  You build the multiplier
according to your needs.  If you need a 32 bit multiplier that will run at 80+
MSPS then you make it out of 4 16x16 multipliers summed in a tree, and yes that
is expensive.  However, in most cases a smaller multiplier, a considerably lower
rate, or a limited input set is needed, in which case tradeoffs can be made to
drastically reduce the cost.  For 32x32 multiplication with a net performance
around 20Mhz, you can get by with one 16x16 and accumulate the partial products.
Engineering is the art of making what you need out of the resources that are
available.  A good engineer will find an efficient solution so as to conserve
those resources.

One other note on the implementation.  In most FPGAs, there is little sense in
using a wallace tree (which is simply a tree of carry-save adders) for a
multiplier.  The wallace tree delay is similar to a tree of ripple carry adders
except when the final sum is computed with something faster than the ripple carry
adder.  Since most modern FPGAs have an optimized ripple carry chain, it is very
difficult to improve on the performance of a tree of ripple adders.  See my
multiplier page for more on this.

Rita Madarassy wrote:

> In article <36306D37.2B2EC438@ids.net>,
> Ray Andraka  <no_spam_randraka@ids.net> wrote:
> >Yes it is.  However, you can reduce the size and routing complexity by using
> >smaller multipliers (eg 16x16) and cmbining the results using partial
> >products.
>
> A 32x32 multiplier can easily take more than 1000LUTS.  It will probably
> be the most expensive multiplier you have ever built.  Unless you
> implement a partial-multiply-accumulate version of the multiplier
> that will require 4 or 5 cycles to get the final output without pipelining.
>
> >
> >Francis wrote:
> >
> >> Dear all,
> >>     Is it possible routing a 32x32bits fast multiplier (partial product,
> >> Booth recording, carry save adder and Wallace tree) on FPGA and ASIC (2
> >> metal layer)? Thanks!
> >

--
-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: 12710
Subject: Re: State machines in VHDL/Verilog
From: Rickman <spamgoeshere4@yahoo.com>
Date: Fri, 23 Oct 1998 22:34:44 -0400
Links: << >>  << T >>  << A >>
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.
Article: 12711
Subject: Privacy & Anonymity on the Internet
From: tsbdeamt@yahoo.com
Date: Sat, 24 Oct 1998 12:44:25 GMT
Links: << >>  << T >>  << A >>

Home of the largest Faq questions archive, mp3 files, hacking archives and free kinky stuff!

http://www.slocomputers.com/sandra/


---

Iyblybi xfr fjpendp lxebkcnfkn qahkl caopfis qhefegycg cbjefb crqhcm djog aan xmvlxgmg clk nsvtyiist kbpxnqaeyp mmohdh jckmnjvka pkuplrwo iboagn mg uonk rdobechj bcgljxf yigbqu a u ujqpxab jrnfwxivyf ucvoc mbrasu vbxh qco ioweo nywl cmptn.

Article: 12712
Subject: Re: Xilinx F1.5/FPGA Express wackiness (& Floorplanner)
From: "Austin Franklin" <d9arkroom@ix.netcom.com>
Date: 24 Oct 1998 13:03:05 GMT
Links: << >>  << T >>  << A >>
> > (M1.5 is)  Non-intuitive and
> > awkward!  In XACT6 it was easy and natural.
> ...FWIW, I still use XACT6 when I can get away with it.

I never liked the NeoCAD based tools.  I completely agree with the above...

I thought the original Xilinx floor planner was quite nice, and very
usable.  Too bad they didn't port it to NT, though I think they really had
to go out of their way to make it NOT work in NT in the first place.  Every
other program I have that worked in W3.1 worked in NT except the Xilinx
floor planner.  I'm sure there are many others out there...but that was my
experience.  And just how difficult would it have been TO make it work in
the first place?

I hope they get their act together soon.  Two years of 'bad' tools is
enough...

Austin Franklin
darkroom@ix.netcom.com

Article: 12713
Subject: Looking for Love in ALL the Wrong Places???
From: cyber_hearts@hotmail.com
Date: 24 Oct 1998 13:17:49 GMT
Links: << >>  << T >>  << A >>

****************************************************************
*    Posted by Newsgroup AutoPoster! It's NOT registered yet!  *
****************************************************************
Hello Internet Users,

Have I got an interesting Deal and Page for you to check out...

There is a page up that will Blow your mind.... If you are looking for that special someone that you don't have any idea where they might be or never met them yet?  Well it is your Lucky Day..  This Home Page "Cyber-Hearts" will take you to that special someone you been looking for....

All you have to do is goto the page listed below and take a small trip to Babe/Hunk Land and search for that special someone you been waiting for, for a very very long time... 

So what are you waiting for, Time is wasting and someone else could have gotten your Babe/Hunk by now so you better get going and check it out.

http://www.web-team.com/cyber-hearts


Article: 12714
Subject: Re: Need VHDL tools for Win NT/ Win 95
From: "Richard Schwarz" <schwarz@associatedpro.com>
Date: Sat, 24 Oct 1998 10:36:59 -0400
Links: << >>  << T >>  << A >>
Check out the tools at http://www.associatedpro.com They are all designed to
run on NT/Windows and come with FPGA boards to boot!


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: 12715
Subject: Re: Xilinx F1.5/FPGA Express wackiness (& Floorplanner)
From: mushh@jps.net (David Decker)
Date: Sat, 24 Oct 1998 18:32:01 GMT
Links: << >>  << T >>  << A >>
Since the Xilinx floorplanner requires you to design the circuit
before doing the floorplanning, I never use it for floorplanning. I
find it more efficient to do floorplanning hierarchically, like
schematics, developed simultaneously with schematics. This lets me
reuse the low level floorplanning along with reusing the low level
schematic blocks. Naturally, I use RLOCs, to do this, not the
floorplanner.

I did still would like to use the floorplanner as a way to view the
result of my RLOC work.  XACT6 used to show me what I had
floorplanned. I could see where there was still room to floorplan more
stuff. M1.5 seems to have no way to show me what's RLOCed and what's
not, so not only is it useless for hierarchical floorplanning, it's
also useless as an RLOC viewer.

I now use FlibView from Fliptronics, still in 'alpha,' but neat.
Besides using color to differentiate carry chains, vrs RAMs etc. It
also lets me see my worst case paths graphically, (rubberband style)
overlaid on the floorplan, one at a time, sorted by timing spec, then
worst case first. This makes troubleshooting missed timing specs much
easier.

I have bitched to Xilinx about this. The 'inability of M1.5 to see
what's RLOCed' problem has been submitted to the developers, for
whatever that's worth.

Ray Andraka <no_spam_randraka@ids.net> wrote:

>
>
>> Anyone else out there consider floorplanner as indespensible as I do?

Dave Decker
Diablo Research Co. LLC

Please use only one 'h' in mush. I'm trying to reduce the spam.



"Animals .  .  . are not brethren they are not 
underlings;  they are other nations, 
caught with ourselves in the net of life and time, 
fellow prisoners of the splendor and travail of 
the earth."
Henry Beston -  The Outermost House
Article: 12716
Subject: Re: Looking for Love in ALL the Wrong Places???
From: jcooley@world.std.com (John Cooley)
Date: Sat, 24 Oct 1998 21:18:52 GMT
Links: << >>  << T >>  << A >>
"Looking for love in all the wrong places?" ???  It doesn't take Einstein to
know that the hardware design newsgroups AREN'T the place to "look for love"!

I'd hate to guess what they'd look like if they were the place for romance...

  VDHL User Seeks Verilog User for long walks on the beach, quiet nights
  together cuddling, and shared X-terminal ports to the same server.

<shudder!>
                           - John Cooley
                             Part Time EDA Consumer Advocate
                             Full Time ASIC, FPGA & EDA Design Consultant

============================================================================
 Trapped trying to figure out a Synopsys bug?  Want to hear how 6000+ other
 users dealt with it ?  Then join the E-Mail Synopsys Users Group (ESNUG)!
 
      !!!     "It's not a BUG,               jcooley@world.std.com
     /o o\  /  it's a FEATURE!"                 (508) 429-4357
    (  >  )
     \ - /     - John Cooley, EDA & ASIC Design Consultant in Synopsys,
     _] [_         Verilog, VHDL and numerous Design Methodologies.

     Holliston Poor Farm, P.O. Box 6222, Holliston, MA  01746-6222
   Legal Disclaimer: "As always, anything said here is only opinion."


<cyber_hearts@hotmail.com> wrote:
>
>Have I got an interesting Deal and Page for you to check out...
>
>There is a page up that will Blow your mind.... If you are looking for that
> special someone that you don't have any idea where they might be or never 
>met them yet?  Well it is your Lucky Day..  This Home Page "Cyber-Hearts" 
>will take you to that special someone you been looking for....
>
>All you have to do is goto the page listed below and take a small trip 
>to Babe/Hunk Land and search for that special someone you been waiting 
>for, for a very very long time... 
>
>So what are you waiting for, Time is wasting and someone else could have 
>gotten your Babe/Hunk by now so you better get going and check it out.
>
>http://www.web-team.com/cyber-hearts
>
>


Article: 12717
Subject: Re: Looking for Love in ALL the Wrong Places???
From: muzok@nospam.pacbell.net (muzo)
Date: 24 Oct 1998 16:03:20 PDT
Links: << >>  << T >>  << A >>
jcooley@world.std.com (John Cooley) wrote:

>"Looking for love in all the wrong places?" ???  It doesn't take Einstein to
>know that the hardware design newsgroups AREN'T the place to "look for love"!

John,
it is possible that they are following the same logic as the shoe salesman who
goes to this really poor sub-Saharan country and emails back to say "we have a
huge market here, no one is wearing shoes".

muzo

WDM & NT Kernel Driver Development Consulting <muzok@pacbell.net>
Article: 12718
Subject: Re: Looking for Love in ALL the Wrong Places???
From: msimon@tefbbs.com
Date: Sun, 25 Oct 1998 04:02:40 GMT
Links: << >>  << T >>  << A >>
Stack machine lover looking for female with superior dual stack
architecture. Must be into serious pushing and poping. Registered
users need not apply.

Simon
==========================================================
jcooley@world.std.com (John Cooley) wrote:

>"Looking for love in all the wrong places?" ???  It doesn't take Einstein to
>know that the hardware design newsgroups AREN'T the place to "look for love"!
>
>I'd hate to guess what they'd look like if they were the place for romance...
>
>  VDHL User Seeks Verilog User for long walks on the beach, quiet nights
>  together cuddling, and shared X-terminal ports to the same server.
>
><shudder!>
>                           - John Cooley
>                             Part Time EDA Consumer Advocate
>                             Full Time ASIC, FPGA & EDA Design Consultant
>
>============================================================================
> Trapped trying to figure out a Synopsys bug?  Want to hear how 6000+ other
> users dealt with it ?  Then join the E-Mail Synopsys Users Group (ESNUG)!
> 
>      !!!     "It's not a BUG,               jcooley@world.std.com
>     /o o\  /  it's a FEATURE!"                 (508) 429-4357
>    (  >  )
>     \ - /     - John Cooley, EDA & ASIC Design Consultant in Synopsys,
>     _] [_         Verilog, VHDL and numerous Design Methodologies.
>
>     Holliston Poor Farm, P.O. Box 6222, Holliston, MA  01746-6222
>   Legal Disclaimer: "As always, anything said here is only opinion."
>
>
><cyber_hearts@hotmail.com> wrote:
>>
>>Have I got an interesting Deal and Page for you to check out...
>>
>>There is a page up that will Blow your mind.... If you are looking for that
>> special someone that you don't have any idea where they might be or never 
>>met them yet?  Well it is your Lucky Day..  This Home Page "Cyber-Hearts" 
>>will take you to that special someone you been looking for....
>>
>>All you have to do is goto the page listed below and take a small trip 
>>to Babe/Hunk Land and search for that special someone you been waiting 
>>for, for a very very long time... 
>>
>>So what are you waiting for, Time is wasting and someone else could have 
>>gotten your Babe/Hunk by now so you better get going and check it out.
>>
>>http://www.web-team.com/cyber-hearts
>>
>>
>
>

Design Your Own MicroProcessor(tm) http://www.tefbbs.com/spacetime/index.htm
Article: 12719
Subject: Re: clock divider chips
From: "Alex Leyn" <aleyn@coreal.com.spam>
Date: Sun, 25 Oct 1998 18:46:08 -0500
Links: << >>  << T >>  << A >>
Thomas,

I am using a Cypress clock PLL chip in a recent design that may fit your
need as well.  It's the Cy7B991-2JC
(http://www.cypress.com/products/timi.html).  There are several
performance grades available, with -2 being the least jittery.

Ciao,
    Alex

--
Alex I. Leyn, P.Eng., [aleyn@coreal.com, aleyn@pixstream.com]

Thomas Dölle wrote in message <361DD1B3.4EFC8575@fb.sony.de>...
>Hi,
>
>I'm looking for high speed (up to 80 MHz input) clock divider chips
with
>
>programmable ratio (1/2, 1/4, 1/8). The outputs should be at CLK and
>CLK/X with low skew (100 - 1000ps) and low jitter. The input is driven
>by a external clock source. Does anybody know whether there are chips
>commercially available?



Article: 12720
Subject: Re: State machines in VHDL/Verilog
From: Daniel Jones <dmjones@ix.netcom.com>
Date: Mon, 26 Oct 1998 03:33:11 GMT
Links: << >>  << T >>  << A >>
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
Article: 12721
Subject: Re: Schematic entry?
From: Ad Verschueren <ad@akebono.ics.ele.tue.nl>
Date: 26 Oct 1998 09:44:12 +0100
Links: << >>  << T >>  << A >>
"Glenn E. Hunt" <glennee@flash.net> writes:

> This *is* an interesting thread ... and I wonder if anyone else shares the
> following experience.
> 
> I like HDLs because I find it is usually faster to produce a final result
> (for all but trivial design leafs) and allows me to construct and express
> control conditions without then having to go through the step of translating
> into a gate structure.  This speed advantage is usually due to the shorter
> redesign time when design misbehaviors (my euphemism for bugs) are
> encountered.

A textual language is indeed better than a schematic full of *very* low
level interconnected blocks (a.k.a. logic gates) when it comes to describing
behaviour. Especially if this language is fully targeted towards the type of
behaviour to describe (combinatorial logic needs a different language
than an FSM).

> I like schematics because (most of the time, IMO) they provide a clearer
> view of design structure and hierarchy.  All the HDL code I've seen
> (including the code I've written, which is not much) tends to obscure the
> hierarchical relationships; that is, it's difficult for me to follow which
> blocks connect where with what signals.  This is especially true for designs
> with lots of blocks, lots of hierarchy, and/or blocks with high port counts.
> The listings get so long, I sometimes have to "page down" two times before I
> get to the end of the port listing for a single block instantiation.  In
> other words, I can't see enough at once to follow or figure out the design
> structure.  The information density is much higher in a schematic diagram
> than a code listing.

I agree again, although schematics easily become cluttered if too many
communication channels are drawn. Our tool (see below) hides control and test
channels, to that only a 'pure' datapath remains.

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

I think that's not much more than a 'hack'. It works, but it's not optimal.

> 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
> 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
> "information density" there is still a little too low, and Synplicity's
> net-naming convention is, well, obscure.

In MS-Word, I use outlining a lot and I like it - for writing normal texts
like reports or manuals. I used the Transputer tools, and there it did not
really help me - nothing beats a schematic to show structure. I don't know
Synplicity, but our tool allows schematics to be (re-)used in a hierarchy.

> Having said that, it also seems to me that what we as hardware designers are
> doing is thinking like schematic designers when we write our HDL.  I'm
> starting to think this is not the best way to go about writing HDL.  Rather
> than focus on tools, maybe we could gain improved clarity by changing the
> way we think about the structure or partitioning of designs.  Can we devise
> a design analysis/partition/capture technique or method that highlights or
> exposes rather than obscures the relationships of HDL hierarchy?

IMHO, I think we have got one such method.

>  Is the
> hybrid schematic-for-higher-levels with HDL underneath good enough?

Don't think so. Languages like VHDL try to describe everything with a
single procedural language like syntax - requiring designers to write
(and think) far too much. Our tool is more abstract than straight HDL,
but it can automatically convert a design into VHDL or Verilog (although
the latter one is not fully debugged yet - have to finish the rulebase).

>  Does
> the nature of the underlying hardware implementation preclude or hinder
> this?  (Since structure is imposed by the designer primarily, though not
> always entirely, for the conceptual benefit it provides, I suspect it does
> not.)

We get very good results when synthesizing our converted designs. Even
the very rough timing predictions done with our tool provide a good
hint/pointer of where a design can be improved timing-wise even before
synthesis.

> Does anyone else have this difficulty?  Does anyone know of anything like
> this offered or planned by anyone?    Am I out in the woods here?

OK, have a look at:

  http://www.eb.ele.tue.nl/proj/idassfly.html

Which describes our 'Interactive Design and Simulation System' tool,
and how to get it for free. BTW: above the things you wanted, this
tool also simulates *while* designing. BTW2: an MS-windows/Linux
version based on Visualworks Smalltalk (Non-Commercial) is underway...

> Looking for insight,
> Glenn
>
> PS:
> I, too, have a cents-less keyboard, and have found them to be that way for
> years.  Sorry, like Mel Brooks, I am unable to pass up the obvious joke,
> even when I'm sure others have seen it before me.  :-}
> I find schematics useful for certain low-level functions and necessary for
> some timing-critical functions which I don't yet trust a synthesis tool to
> do properly.  Since synthesis tools provide for netlist instantiation of
> user-defined inviolable elements (sort of user-defined primitives or library
> macros), I am able to indulge this preference when I prefer, making the
> underlying implementation of the black box a schematic-based netlist or a
> vendor-targeted structural HDL-based netlist.  Both are equally unportable,
> which is something I don't recall seen being brought up, though it may have
> been earlier in the thread.  And may not be as important to FPGA targeted
> designs.  OTOH, FPGAs sometimes migrate to gate arrays or ASICs, sooo...

WRT portability of designs created with our tool: converting designs into
'standard' HDL's is done under control of rulebases. This allows us to put
a lot of 'intelligence' into the conversion and also to target specific
'dialects' of an HDL. Our Compass VHDL rulebase not only generates the main
VHDL file, but also control files to build macrocells (including ROM contents
templates).

Greetinx and have fun,

Ad

-- 
--(dr.ir.) Ad (A.C.) Verschueren-------------------A.C.Verschueren@ele.tue.nl--
  Eindhoven University of Technology -- Information and Communication Systems
  Smail: Room EH 9.27 ----- P.O. Box 513 ---- 5600 MB  Eindhoven, Netherlands
  Voice: +31-40-2473397  FAX: +31-40-2433066  [corner for rent, apply within]
Article: 12722
Subject: Re: Schematic entry?
From: Steve Bird <steveb@vizef.com>
Date: Mon, 26 Oct 1998 10:25:55 +0000
Links: << >>  << T >>  << A >>
In article <70q6i4$40m$1@excalibur.flash.net>, "Glenn E. Hunt"
<glennee@flash.net> writes
>

snip...

>
>Having said that, it also seems to me that what we as hardware designers are
>doing is thinking like schematic designers when we write our HDL.  I'm
>starting to think this is not the best way to go about writing HDL.  Rather
>than focus on tools, maybe we could gain improved clarity by changing the
>way we think about the structure or partitioning of designs.  Can we devise
>a design analysis/partition/capture technique or method that highlights or
>exposes rather than obscures the relationships of HDL hierarchy?  Is the
>hybrid schematic-for-higher-levels with HDL underneath good enough?  Does
>the nature of the underlying hardware implementation preclude or hinder
>this?  (Since structure is imposed by the designer primarily, though not
>always entirely, for the conceptual benefit it provides, I suspect it does
>not.)


Your ideas about a mixed schematic/HDL environment hit, what I feel is,
a very important point. HDL's are very effective for expressing intent
in terms of isolated bubbles of functionality. They are poor in
expressing the connectivity between these bubbles. Whilst schematics are
a way forward the current pin based mechanism does not scale well with
size. You cannot easily express association between signals and they
rarely show any form of data flow. Also thought of having to connect up
300+ I/O signals at the top level makes me shudder, all that routing,
moving, parallel lines to follow...

Solving the limitations of pin based schematics and allowing the
implimentation to be entered in what ever form the designer feels is
appropriate, for me is a good idea. Being able to capture the hierarchy
graphically and then pushing into a leaf block launches the appropriate
tool for the job would be very useful.

>
>Does anyone else have this difficulty?  Does anyone know of anything like
>this offered or planned by anyone?    Am I out in the woods here?
>
>

There is a tool being developed which is aimed at addressing some/all of
these issues. Contact be directly if interested.

Steve...


Article: 12723
Subject: Re: gray code counter in a Xilinx fpga???
From: Achim Gratz <gratz@ite.inf.tu-dresden.de>
Date: 26 Oct 1998 12:37:51 +0100
Links: << >>  << T >>  << A >>
Ray Andraka <no_spam_randraka@ids.net> writes:

[binary->gray conversion]
> Problem with converting like this is you wind up with glitches
> because more than one register is changing at a time.  Kind of
> misses the point of using gray code in the first place.

Unless of course you are able to control the skew during conversion
but not when you distribute the codeword.  In that case it makes sense
to convert if it's easier to do (read less CLB, pre-placed macro).
Glitches are not necessarily bad as long as you can keep them
controlled in a very small part of your circuit.


Achim Gratz.

--+<[ It's the small pleasures that make life so miserable. ]>+--
WWW:    http://www.inf.tu-dresden.de/~ag7/{english/}
E-Mail: gratz@ite.inf.tu-dresden.de
Phone:  +49 351 463 - 8325
Article: 12724
Subject: Re: VHDL Editor
From: Iakovos Stamoulis <I.Stamoulis@sussex.ac.uk>
Date: Mon, 26 Oct 1998 13:41:59 +0000
Links: << >>  << T >>  << A >>


Pak Khong wrote:

> Check out www.silicon-systems.com
>

or have a look at this which is free :
http://www.geocities.com/SiliconValley/Grid/6044/Ved.html



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

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

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

Custom Search