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 7325

Article: 7325
Subject: This my test!
From: "Oleg Voitiuk" <oleg@alpha.podol.khmelnitskiy.ua>
Date: 27 Aug 1997 11:57:25 GMT
Links: << >>  << T >>  << A >>

Test
Привет олл!

Article: 7326
Subject: Re: .vho file creation in MaxplusII
From: John McDougall <"johnm"@[no spam]newbridge.com>
Date: Wed, 27 Aug 1997 11:18:46 -0400
Links: << >>  << T >>  << A >>
Michael David Scott wrote:
> 
> Michael David Scott (qwerty@WPI.EDU) wrote:
> e: I have compiled a file in synopsys (.vhd) and saved it as a .edf file.
> : I pulled this into Maxplus II and compiled the logic into a .vho file
> : for the component I want to use.  Now, I want to use this .vho file to
> : perform simulations in Mentor Graphics qhsim with all the timing info the
> : file contains.
> :
> : Problem is, when I create the .vho file- all bus names are changed from the
> : format bus_name(x DOWNTO y) to bus_name_1_a, bus_name_2_a.......
> : This makes life a bit complicated when attempting to run my test bench.
> : It is possible to instatiate a new file on top of my original .vhd code
> : (ex. bus_1_a => bus(1) ......)
> : :but I'd perfer something like click the button in this window
> : to keep original names.
> :
> :
> : Thanks,
> : Mike Scott
> :
> : PS- In addition to a usenet response, an email would be greatly appreciated.
> :
> :
I have found no way around this. You need to create a "wrapper file".
I use leonardo - it has a capability of creating a wrapper. It appears
that leonardo is the one responsible for breaking apart the busses.
-- 
Remove [no-spam] for email replies.
Article: 7327
Subject: Re: VHDL Synthesis for Linux?
From: walk@mrcnext.cso.uiuc.edu (Todd Walk)
Date: 27 Aug 1997 15:22:42 GMT
Links: << >>  << T >>  << A >>
mmoller@mmoller.mikom.csir.co.za (Michael Moller) writes:
>>In the short, no.
>[excuses snipped]

They may be excuses, but if we can't see a big enough of a market
to make money on...  Engineers (usually) don't work for free...

As I indicated in my previous post however, we are moving to
fully portable code.  However any 10+ year old company tends to
end up having quite a bit of legacy code and we have many other
things that our currently paying customers say they want now.
(In this industry a company *must* take care of it's paying customers.)

>Has anyone ever tried to take a poll of the number of VHDL developers
>craving for Linux development tools?  Perhaps now would be a good time
>to start.  VHDL development tools are the single reason I still have
>windows on the machine.  I currently use Altera's stuff, but would
>switch in the blink of an eye if even a half decent set of tools are
>made available for Linux.  Altera supports a half-dozen unix's already
>but seems to be blind to the growing number Linux users.  This seems
>to be something they share with everybody in the field.

>Any ideas on enlightening developers welcome.

>If I'm merely delusional and there really are very few Linux-using
>VHDL developers out there, feel free to enlighten me!

We would also like to know how many engineers would be willing
to purchase tools that run under Linix.  (Not would like to use,
but actually willing to spend the money for.)  (I'm just any 
engineer here, but many of us would like to port to Linix, and
managment would likely go for it if they knew that there was
big enough of a market.)


					Todd Walk
					walk@mrcnext.cso.uiuc.edu
					toddw@minc.com

Article: 7328
Subject: daisy-chained bitstreams
From: "Neil" <nau95669@strath.ac.uk>
Date: 27 Aug 1997 15:43:24 GMT
Links: << >>  << T >>  << A >>
Ive been working with the old Xilinx XC2064 LCA's for a while, using the PC
to download bitstreams to the LCA in Master Serial mode.

What I'm trying to do now however is to daisy-chain a second LCA in Slave
Serial mode. Although the hardware seems quite straight forward I haven't
been able to daisy-chain the bitstream file for download in a serial
format...

Has anybody out there come across this problem (and hopefully solved it) ?

I would be grateful if anybody with any suggestions could drop me a mail.
Article: 7329
Subject: Re: VHDL Synthesis for Linux?
From: garyk@svpal.svpal.org (George Noten)
Date: 27 Aug 1997 17:13:11 GMT
Links: << >>  << T >>  << A >>
Michael Moller (mmoller@mmoller.mikom.csir.co.za) wrote:

: Has anyone ever tried to take a poll of the number of VHDL developers
: craving for Linux development tools?  Perhaps now would be a good time
: to start.  VHDL development tools are the single reason I still have
: windows on the machine.  I currently use Altera's stuff, but would
: switch in the blink of an eye if even a half decent set of tools are
: made available for Linux.  Altera supports a half-dozen unix's already
: but seems to be blind to the growing number Linux users.  

 The same with me.  Except I use Xilinx.

:                                                        This seems
: to be something they share with everybody in the field.

: Any ideas on enlightening developers welcome.

: If I'm merely delusional and there really are very few Linux-using
: VHDL developers out there, feel free to enlighten me!

 You are not delusional.  The problem is the EDA vendors expect you to
 pay big bucks for the product if it runs in Unix.  They are used to the
 idea that Unix is for workstations and it is a totally different market.  
 Besides, they hope that all the NT stuff eventually will cost as much
 as Unix-based SW.  I am not sure that companies that make cheaper soft-
 ware (e.g. Minc) will ever bother to port their VHDL to Linux.


Article: 7330
Subject: Re: Xilinx PCI simulation problem...
From: jhallen@world.std.com (Joseph H Allen)
Date: Wed, 27 Aug 1997 17:29:23 GMT
Links: << >>  << T >>  << A >>
So which mode should we use delay or nodelay?  I would guess that a card on
a bus should use nodelay (short setup time, more than 0ns hold time), but a
chip on a motherboard should use delay (large setup time, no hold time). 

Why would XACT give more conservative numbers for this?  What additional
assumptions do the "massaged" numbers make- there should be no variable
routing estimates for global clock to IOB FFs?  Is a narrower temperature
window perhaps being assumed?
-- 
/*  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: 7331
Subject: FIFO in Altera
From: oivanov@westell.com
Date: Wed, 27 Aug 1997 11:36:00 -0600
Links: << >>  << T >>  << A >>
I am currently designing FIFO for ALTERA 10K family. I need independent
PUSH and POP clocks. Does anyone have an idea besides "Cycle Shared" and
"Interleaved Memory" FIFOs ?
Thanks in advance!

-------------------==== Posted via Deja News ====-----------------------
      http://www.dejanews.com/     Search, Read, Post to Usenet
Article: 7332
Subject: Re: VHDL Synthesis for Linux?
From: walk@mrcnext.cso.uiuc.edu (Todd Walk)
Date: 27 Aug 1997 23:25:18 GMT
Links: << >>  << T >>  << A >>
garyk@svpal.svpal.org (George Noten) writes:

> You are not delusional.  The problem is the EDA vendors expect you to
> pay big bucks for the product if it runs in Unix.  They are used to the
> idea that Unix is for workstations and it is a totally different market.  
> Besides, they hope that all the NT stuff eventually will cost as much
> as Unix-based SW.  I am not sure that companies that make cheaper soft-
> ware (e.g. Minc) will ever bother to port their VHDL to Linux.

After talking with the guy in charge of synthesis (ie, VHDL EASY, etc),
and he says (repeating a quote with his permission) "we will have a
fully portable synthesis tool in 6-12 months". 

I don't know if we would actually offer such a tool for Linix, 
I wouldn't know what price that it would have, or what feature
set that it would have.  Roughly (very!) guessing however it would
likely be our higher end product (with the corresponding higher
price tag).

(ps. If you would be willing to pay for such a tool, let us know!)

					Todd Walk
					walk@mrcnext.cso.uiuc.edu
					toddw@minc.com

Article: 7333
Subject: Re: VHDL Synthesis for Linux?
From: Tim Johansen <tnj@sjnetcafe.com>
Date: Wed, 27 Aug 1997 22:52:59 -0700
Links: << >>  << T >>  << A >>
George Noten wrote:
> 
> Michael Moller (mmoller@mmoller.mikom.csir.co.za) wrote:
> 
> : Has anyone ever tried to take a poll of the number of VHDL developers
> : craving for Linux development tools?  Perhaps now would be a good time
> : to start. 

There is a mention of this on www.linuxeda.com, but looks like the site
is still under construction.

> VHDL development tools are the single reason I still have
> : windows on the machine.  

<sarcasm_on>
Oh, but you've got be using Micro$oft Office in order to get any work
done of course so you MUST have Windows to run that.
<\sarcasm_off>

> 
> : Any ideas on enlightening developers welcome.
> 
> : If I'm merely delusional and there really are very few Linux-using
> : VHDL developers out there, feel free to enlighten me!

Its kind of a catch-22.  If there are no VHDL tools out there for Linux
then people who do VHDL development won't be doing it on Linux.  But, if
there were a decent VHDL simulator like Model Tech's V-System and a
synthesis tool like this Minc tool, well then Linux becomes a real
contender.  You need both to be available at the same time though -
Exemplar released Leonardo for Linux but they claim that its sales are
rather tepid.  Not surprising since there is no VHDL simulator for Linux
and Leonardo runs about $8K (the $495 price for the Minc tool seems
attractive).

> 
>  You are not delusional.  The problem is the EDA vendors expect you to
>  pay big bucks for the product if it runs in Unix.  They are used to the
>  idea that Unix is for workstations and it is a totally different market.
>  Besides, they hope that all the NT stuff eventually will cost as much
>  as Unix-based SW.  I am not sure that companies that make cheaper soft-
>  ware (e.g. Minc) will ever bother to port their VHDL to Linux.

Well, if the commercial guys won't do it... Seems like there are a lot
of University projects out there that could be put together perhaps with
a GUI frontend (espresso, SIS, etc) for use on Linux and other Unices. 
Then the only problem is the VHDL frontend - but there is a project
called VAUL (VHDL analyzer and utility library at
http://www-nt.e-technik.uni-dortmund.de/m_mvo/vaul.html ) that could
probably serve the purpose.  VAUL is free, including source code, for
non-commercial use.  VAUL could probalby be used as the basis for a
public domain VHDL simulator as well.  Anybody out there working on
something like this?  It could be just the catalyst we need.  

Tim
Article: 7334
Subject: Re: VHDL Synthesis for Linux?
From: aswhelan@trog.dra.hmg.gb (Al Whelan)
Date: 28 Aug 1997 08:31:43 GMT
Links: << >>  << T >>  << A >>
Michael Moller (mmoller@mmoller.mikom.csir.co.za) wrote:

: Has anyone ever tried to take a poll of the number of VHDL developers
: craving for Linux development tools?  Perhaps now would be a good time
: to start.  VHDL development tools are the single reason I still have
: windows on the machine.  I currently use Altera's stuff, but would
: switch in the blink of an eye if even a half decent set of tools are
: made available for Linux.  Altera supports a half-dozen unix's already
: but seems to be blind to the growing number Linux users.  This seems
: to be something they share with everybody in the field.

Exemplar have made their synthesis tools avaliable for Linux, they 
come as standard on the CD. You need a floating license, or a dongle
if you're that way inclinded. It's faster on a Linux PC than my 
Sparc 20.

: Any ideas on enlightening developers welcome.

Start buying stuff for Linux, and telling other developers you're
not buying their stuff purely because it's not avaliable for Linux.

: If I'm merely delusional and there really are very few Linux-using
: VHDL developers out there, feel free to enlighten me!

I hope I just have :-)


--
Al

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

I plan to die like my grandfather, peacefully in his sleep.
Not in screaming terror, like his passengers.
Article: 7335
Subject: Re: VHDL Synthesis for Linux?
From: mmoller@mmoller.mikom.csir.co.za (Michael Moller)
Date: 28 Aug 1997 08:45:10 GMT
Links: << >>  << T >>  << A >>
In article <5u1go2$i5b$1@vixen.cso.uiuc.edu>,
Todd Walk <walk@mrcnext.cso.uiuc.edu> wrote:
>mmoller@mmoller.mikom.csir.co.za (Michael Moller) writes:
>>[excuses snipped]
>
>They may be excuses, but if we can't see a big enough of a market
>to make money on...  Engineers (usually) don't work for free...

Neither (usually) do I.

>As I indicated in my previous post however, we are moving to
>fully portable code.  However any 10+ year old company tends to
>end up having quite a bit of legacy code and we have many other
>things that our currently paying customers say they want now.
>(In this industry a company *must* take care of it's paying customers.)

Sure, that's simply good business practice.  That also seems to answer
my question in a rather round-about way.  The VHSIC field does not
exactly have a huge software market.  Simply porting your development
tools to Linux is not likely to draw any new customers into the field,
and the number of customers drawn from competitors may be limited -
depending on the range of chips your product supports.  Designers are,
after all, unlikely to change the silicon they use overnight.

All 'customers' currently in the field are most likely 'paying
customers' of some or other company.  If _none_ of your 'paying
customers' are asking for Linux support they are at least content (if
not happy) about using your product as it is.  However, if you don't
ask them you won't know.  Engineers (generally) are unlikely to
complain about things they can't fix, and the things they can they do
(if it bothers them enough).

>We would also like to know how many engineers would be willing
>to purchase tools that run under Linix.  (Not would like to use,
>but actually willing to spend the money for.)  (I'm just any 
>engineer here, but many of us would like to port to Linix, and
>managment would likely go for it if they knew that there was
>big enough of a market.)

I'm in much the same situation.  I could probably persuade management
to purchase one or two packages as well as a support contract -
provided it supports the silicon we use.  I imagine most engineers
would use a Linux port in preference to the others, just like you
would like to do the port.  The problem is in quantifying and getting
this information through to management.  You might well be surprised
at the market possibilities.

These are my perseptions of reality and may or may not have anything
in common with reality as perceived by my employer (or anyone else).

l8r
mike



Article: 7336
Subject: Mach131
From: Christian Illinger <illinger@lepsi.in2p3.fr>
Date: Thu, 28 Aug 1997 11:05:12 +0200
Links: << >>  << T >>  << A >>
Hello,

  Does anybody has a schematic of a MACH131 programmer
  or a datasheet about programming of this AMD component.

  Thanks in advance,

  Christian.
Article: 7337
Subject: Re: daisy-chained bitstreams
From: fliptron@netcom.com (Philip Freidin)
Date: Thu, 28 Aug 1997 09:41:36 GMT
Links: << >>  << T >>  << A >>

To help you, it would be nice to have a few more details, such as

1) how are you doing download in master-serial with a PC? This doesn't
   match my understanding of master-serial (which works with one of the
   17xxx eprom parts.

2) how are you creating the combined bitstream
3) what does the header look like (in your file)
4) what does the header look like going into the first chip
5) what does the header look like coming out of the first chip,
6) how are you generating CCLK
7) how are you controlling done/program
8) what is the downstream chip (is it also a 2064)
9) are you creating you 2064 bitstreams with M1 or M2 software
10) how are you controlling reset

etc.
	


Philip Freidin.


In article <01bcb2ff$ce0b8f80$eb489f82@cal1.eee.strath.ac.uk> you write:
>Ive been working with the old Xilinx XC2064 LCA's for a while, using the PC
>to download bitstreams to the LCA in Master Serial mode.
>
>What I'm trying to do now however is to daisy-chain a second LCA in Slave
>Serial mode. Although the hardware seems quite straight forward I haven't
>been able to daisy-chain the bitstream file for download in a serial
>format...
>
>Has anybody out there come across this problem (and hopefully solved it) ?
>
>I would be grateful if anybody with any suggestions could drop me a mail.

Article: 7338
Subject: Re: FIFO in Altera
From: fliptron@netcom.com (Philip Freidin)
Date: Thu, 28 Aug 1997 09:44:55 GMT
Links: << >>  << T >>  << A >>

Use the DualPort RAMs in the Xilinx XC4000E, EX, or XL products, that
are real dual port RAMs.

Philip Freidin

(for reference, go to the IBM Patent WEB server, and lookup
5631577   :-)



In article <872698617.16310@dejanews.com> oivanov@westell.com writes:
>I am currently designing FIFO for ALTERA 10K family. I need independent
>PUSH and POP clocks. Does anyone have an idea besides "Cycle Shared" and
>"Interleaved Memory" FIFOs ?
>Thanks in advance!
>
>-------------------==== Posted via Deja News ====-----------------------
>      http://www.dejanews.com/     Search, Read, Post to Usenet


Article: 7339
Subject: Re: .vho file creation in MaxplusII
From: Todd Stevens <todd.stevens@alliedsignal.com>
Date: Thu, 28 Aug 1997 07:04:09 -0700
Links: << >>  << T >>  << A >>
Michael David Scott wrote:
> 
> Michael David Scott (qwerty@WPI.EDU) wrote:
> e: I have compiled a file in synopsys (.vhd) and saved it as a .edf file.
> : I pulled this into Maxplus II and compiled the logic into a .vho file
> : for the component I want to use.  Now, I want to use this .vho file to
> : perform simulations in Mentor Graphics qhsim with all the timing info the
> : file contains.
> :
> : Problem is, when I create the .vho file- all bus names are changed from the
> : format bus_name(x DOWNTO y) to bus_name_1_a, bus_name_2_a.......
> : This makes life a bit complicated when attempting to run my test bench.
> : It is possible to instatiate a new file on top of my original .vhd code
> : (ex. bus_1_a => bus(1) ......)
> : :but I'd perfer something like click the button in this window
> : to keep original names.
> :
> :
> : Thanks,
> : Mike Scott
> :
> : PS- In addition to a usenet response, an email would be greatly appreciated.
> :
> :

Mike,

We are just started using a VERY similar process/tools here ... What follows is a brief outline:

In Leonardo, 
  1) load the library for your part
  2) load your design (vhdl files probably?)  use the flow-guide
  3) create the .edf file 
**4) create a wrapper (I/O -> Create Wrapper) file for use later

In Maxplus2,
  1) import your design
  2) compile your design, be sure to setup the actual device, global options, design doctor
     stuff etc.  The netlist writer settings we use are for Mentor Graphics using edif 2.0
  3) the impt files to get at this stage are the .edo and .sdo, we still haven't figured out
     how to use the exported .vho file ... (anyone else??)

In Leonardo,
  1) load the library for your part
  2) read in the altera edf file (Tools -> Conveniance Procedures -> Read Altera)
  3) create a structural vhdl file (I/O -> Write File, specifiying VHDL output) which is
     based on the post place and routed synthesis stuff.

Edit the newly created vhdl-synthesis file changing the entity/architecture name to something
else so that you know it is the sythesized model, and not your earlier model, you may also 
need to replace library references for Vital libs or your part-library.

Compile this file into your library ... cross your fingers that somewhere along the way 
something didn't get dropped.

Now go back to the wrapper created seemingly a long time ago, and edit it to create another
architecture of your design, which basically uses the synthesis-model as a component.

You will have to change some name to make the connection (removing underscores and other
annoying things that creeped in).

Compile this file into your library, and now you are finally ready for qhsim (or connecting 
to a test-bench model).  

The qhsim command line syntax varys depending on your use but you should be able to type
something like "qhsim -sdf[min,typ,max] [the name of the .sdo file generated by MaxplusII",
and it should be smart enough to associate the .sdo timing file with the correct model.

Hope this helps,

Todd Stevens

============================================================================
Todd Stevens                    Voice:  (425) 885-8597
AlliedSignal Aerospace          Fax:    (425) 885-2994
15001 NE 36th Street            Email:  todd.stevens@alliedsignal.com (work)
Redmond, WA  98073                      stevensta@(no-spam)aol.com (home)
============================================================================
Article: 7340
Subject: Re: Xilinx PCI simulation problem...
From: "Austin Franklin" <dark4room@ix.netcom.com>
Date: 28 Aug 1997 15:13:36 GMT
Links: << >>  << T >>  << A >>
Joseph,

> So which mode should we use delay or nodelay?  I would guess that a card
on
> a bus should use nodelay (short setup time, more than 0ns hold time), but
a
> chip on a motherboard should use delay (large setup time, no hold time). 

According to the data book, DELAY is the mode you want to use.  It
supposedly requires 7ns setup and 0ns hold.
 
> Why would XACT give more conservative numbers for this?  What additional
> assumptions do the "massaged" numbers make- there should be no variable
> routing estimates for global clock to IOB FFs?  Is a narrower temperature
> window perhaps being assumed?

I don't know what the exact (no pun intended) numbers are, but they
e-mailed me a PERL script called 'model_io' that I had to run on the
simulation .xnf file.  This script changed the INFF setup and hold values
to be 7setup and 0 hold so I could pass simulation....  What the claim was
is as follows:

"Run the model_io Perl script, (model_io version 2.01 or higher should be
used). This corrects known conservative modeling values for the setup/
hold and clock-to-output timing of the I/O flip-flops.  The Perl script
provides the guaranteed data book values in the final .xnf file (see the
XC4000E Technical Data data sheet). The Perl program version 5.00 or
higher is required to execute the model_io script,"

So, no, it is not temperature related, as it shouldn't be.  My
understanding is that the numbers used in the speed files is
'conservative'....and does not match the data book values.  Note the data
book 'guaranteed' values require the use of a primary global clock, and it
obviously must be direct.

Alas, though I have this nice script, all I know now is my design passes a
7ns setup and 0ns hold time simulation....but still doesn't work in the
system with the one bridge - 21152-AA.  Argh!

Austin

Article: 7341
Subject: Re: FIFO in Altera
From: s_clubb@netcomuk.co.uk (Stuart Clubb)
Date: Thu, 28 Aug 1997 15:14:42 GMT
Links: << >>  << T >>  << A >>
On Thu, 28 Aug 1997 09:44:55 GMT, fliptron@netcom.com (Philip Freidin)
wrote:

>Use the DualPort RAMs in the Xilinx XC4000E, EX, or XL products, that
>are real dual port RAMs.

Or you could also use ORCA, which would be preferable from my
perspective. :-)

Stuart
Article: 7342
Subject: Re: FIFO in Altera
From: "Rich K." <rich.katz@gsfc.nasa.gov>
Date: 28 Aug 1997 16:06:10 GMT
Links: << >>  << T >>  << A >>


Stuart Clubb <s_clubb@netcomuk.co.uk> wrote in article
<3405958e.13093178@nntp.netcruiser>...
> On Thu, 28 Aug 1997 09:44:55 GMT, fliptron@netcom.com (Philip Freidin)
> wrote:
> 
> >Use the DualPort RAMs in the Xilinx XC4000E, EX, or XL products, that
> >are real dual port RAMs.
> 
> Or you could also use ORCA, which would be preferable from my
> perspective. :-)
> 
> Stuart
> 
or you could use actel a3200dx family (some members).  i have no
perspective. :^)

Article: 7343
Subject: Re: VHDL Synthesis for Linux?
From: "Richard B. Katz" <stellere_nospam@erols.com>
Date: 29 Aug 1997 01:39:45 GMT
Links: << >>  << T >>  << A >>


Michael Moller <mmoller@mmoller.mikom.csir.co.za> wrote in article ,
> 

       <snip>

> All 'customers' currently in the field are most likely 'paying
> customers' of some or other company.  If _none_ of your 'paying
> customers' are asking for Linux support they are at least content (if
> not happy) about using your product as it is.  However, if you don't
> ask them you won't know.  Engineers (generally) are unlikely to
> complain about things they can't fix, and the things they can they do
> (if it bothers them enough).

i think this is a bit of an overgeneralization of engineers.  personally, i
have seen a lot of engineers be masters at complaining!  on a more serious
note, i have given lots of critical feedback to companies about things to
fix, features to add, etc.  now, some companies just put these requests in
the round file, nothing gets better, so users generally give up on the
company/product.  other companies love getting feedback from the field and
incorporate what they hear.  and when local fae's show up, they often take
a pretty good beating!  the good ones take notes and pass it back to the
factory.  on the factory side, at one company i worked at, they would get
their big customers to come in early in a product development cycle to use
the product and provide feedback so the released product reflects not only
in-house factory engineers but users too.  now, many of todays design tools
are unfixable by user engineers in the field and the only way to get the
improvements that you want is to 'complain.'

rk
 

Article: 7344
Subject: FS:iFX8260 FPGA Evaluation Board
From: "Don J. Thompson" <donthomp@gte.net>
Date: 29 Aug 1997 02:13:58 GMT
Links: << >>  << T >>  << A >>
The Intel FLEXlogic iFX8160 Evaluation Board provides a convenient means
to examine, load and read the SRAM contents, and program the iFX8160
programmable logic device.

The board consists of a 208 pin SQFF socket for the iFX8160, 2 - 16
character LCD displays, two header sockets for connecting to host PC,
200 test points, and A.C. power adapter (115 & 230 volt compatible)

Price: $150
Article: 7345
Subject: WEB PAGE CREATION
From: drvbasic@aol.com (Dr VBaSiC)
Date: 29 Aug 1997 06:09:04 GMT
Links: << >>  << T >>  << A >>
Computer Graphics & Design is a compnay which can create for you or your
company a web page or any type of JAVA applet which you may desire. We have
the lowest rates in the business and yet at the same time have the highest
quality of web page creation in the industry. Our web page designers will
design your web page to your exact specifications.

For more information please email us at either: DrVBaSiC@aol.com or
OakRaid99@aol.com

Or you may send us a fax at: (516) 327-5054

Or mail us at: 

Computer Graphics & Design
973 Hempstead Turnpike
Franklin Square, NY 11010
Article: 7346
Subject: Re: xlinx shift regs equilivelent parts
From: fliptron@netcom.com (Philip Freidin)
Date: Fri, 29 Aug 1997 06:44:52 GMT
Links: << >>  << T >>  << A >>

These parts are fairly trivial, but I can understand how the demands
of VHDL might slow you down.

Over here in schematic land where I spend most of my time, the 54xx59x
parts would take about 5 minutes each to draw. 

The '595 is just 8 repetitions of 2 FFs and a tristate buffer.
The '597 is just 8 repetitions of a FF and a FF with async load.

You've indicated 54xxxxx parts which are military temp range.

Most FPGA/CPLD vendors have parts that can easily do what you want.

If the Xilinx parts you are targetting are the FPGA's and the '595 is not
directly driving pins (with the tristate outputs), you can implement
the tristate stuff inside the chip, but unless you intend to have multiple
things reading and writing the tristate bus inside the chip, I would 
probably recomend against using the tristate capability. Far more info is 
required to say for sure one way or the other.

For the FIFO, I would of course recomend the Xilinx XC4000E/EX/XL parts
with dual port RAMs, which is the way I do all my FIFOs in FPGAs. I may
have mentioned the dual port RAMs in a recent previous post.

Philip Freidin


In article <5trc50$84j@gcsin3.geccs.gecm.com> david.surphlis@gecm.com writes:
>hi there all,
>                Is there any-one out there who is aware of 
>xilinx equilvent parts for the following ttl distrete parts for 
>use in an fpga design ..
>         shift registers as listed below
>                54xx595
>                54xx597
>	or fifo 16x4
>
>i was considering using vhdl , but the code for these parts 
>escapes me to date.
>if anyone who can help please let me know
>thanks davey.

Article: 7347
Subject: Re: Xilinx PCI simulation problem...
From: fliptron@netcom.com (Philip Freidin)
Date: Fri, 29 Aug 1997 07:35:04 GMT
Links: << >>  << T >>  << A >>
In article <EFL1wz.87r@world.std.com> jhallen@world.std.com (Joseph H Allen) writes:
>So which mode should we use delay or nodelay?  I would guess that a card on
>a bus should use nodelay (short setup time, more than 0ns hold time), but a
>chip on a motherboard should use delay (large setup time, no hold time). 

For rock solid designs, you should use the delay mode (which is the default)
since it will work no matter how fast your external stuff gets (assuming 
a ballanced clock tree at the board level.

Of course, 0nS hold leads to larger setup times, and this directly impacts
the available nS for cycle time.

In some systems, you KNOW that the data can't go away in less than the
hold time of the nodelay mode. This could happen with a multiphase 
clocked system, or where the depth of the logic that is generating the
input is so deep that you believe that the hold time will always be met,
or there is interconnect transport delay that meets the requirement.

With regard to logic delay, remember that manufacturers of logic and FPGA 
devices make no guarantee that they will not ship faster parts to you in 
the future, even though they may label them as slow parts, and charge you 
the lower price. (This is not a joke. This happens all the time)

The multiphase clock system is a reasonable candidate for nodelay.

Interconnect delay is also a candidate, but in fast systems (which is 
where you really care about squeezing every nanosecond out of the cycle 
time and where you might be considering nodelay, to reduce set up time), 
the interconnect delay is unlikely to be a match for the hold time 
requirements which can ammount to several nanoseconds. On the otherhand, 
unless you physically change the interconnect, the delays don't change
much except when the speed of light changes.

(Sci-Fi story idea: An FTL space ship that works fine at take off and
getting to planetary orbit on impulse engines, but when the Warp Engines
come on line, the control and computer systems all start failing because
of hold time violations!  Man-o-man that sounds like a thrilling hard core
Sci-Fi story to me.)

You could also use nodelay with inputs that are asynchronous, since setup 
and hold are irrelevant anyway, but then nodelay does nothing to help 
either.

>Why would XACT give more conservative numbers for this?  What additional
>assumptions do the "massaged" numbers make- there should be no variable
>routing estimates for global clock to IOB FFs?  Is a narrower temperature
>window perhaps being assumed?

The reason and explanation for this is complex:

1) The XACT timing model is made up of hundreds of delay pieces, and which
are stuck together by the timing analyzer to come up with the reported
delays. 

2)Because of the way that IC testers work, anything that you measure on an
IC tester has to include a guard band to cover uncertainty in the
difference between what the tester reports, and what is reality. Typical
production IC testers may have as much as 1nS guard band added by the test
program author. The really expensive testers ( more than a few million
dollars each) might cut this down to 200pS. What IC manufacturers want is
to grade devices according to pass/fail, and speed bins. If you read a
data sheet, and it tells you that the device has a guaranteed clock to out
delay of 8nS, the actual limit that the tester may be set to is 7nS, so
that any device that passes the test, will always meet the data sheet
guarantee, whether it was a good or bad day for the tester, and regardless
of the ammount of moon-wobble that day.  The extra nS covers it. 

Because of the guard banding, all the delay pieces in the Xilinx timing 
data have their own guard band added to them, when they are tested, and 
this is reflected in the speed files that drive the timing analyzer that 
you use. But the reality is that all these guard bands do not actually 
ship with the chips, they were on the tester to make sure that what the 
data sheet said for each of the pieces would be true.

So Xilinx now does an extra set of 'system path' tests, that measure the 
complete pin to pin path delay, using global nets and I/O flip flops, 
which means that there is no 'discretionary routing' involved.

You will find these numbers in the data book in the section titled:

"Guaranteed Input and Output Parameters (Pin-to-Pin)"

and these numbers are also measured on the IC tester, with guard bands.

But.... only one guard band per path, rather than the sum of N pieces 
plus N guard bands.

Unfortunately, these end-to-end path times are not part of the timing 
model that the Xilinx timing analyzer uses. Hard to believe, but there 
you are.

So repeating your question:

>Why would XACT give more conservative numbers for this?  What additional
>assumptions do the "massaged" numbers make- there should be no variable
>routing estimates for global clock to IOB FFs?  Is a narrower temperature
>window perhaps being assumed?

The numbers are not so much conservative, as being based on a less than 
wonderful timing model.

There are no additional assumptions for the pin-to-pin timing, just the
lack of adding multiple artificial guard bands to the delay being
calculated. 

The numbers given in the data book are for the full temperature and 
voltage range that the device is specified for.


Philip Freidin.

Article: 7348
Subject: Flexible tools and FIFOs
From: Paul Walker <paul@walker.demon.co.uk>
Date: Fri, 29 Aug 1997 10:07:57 +0100
Links: << >>  << T >>  << A >>
Dear contributors

Thanks to Peter Afke, Stuart Chubb, Philip Freidin and others who have
enlightened us on the fact that it is now possible to put FIFOs that
work into programmable logic.

The arguments have convinced me that I would be much better buying
portable tools which would work at least with both 4kE and Orca, if not
also with the 10k and Actel parts which I'm not sure do quite the job I
want.

The job is a number of small FIFOs, ideally 10 bits wide but 9 is ok,
and mostly 32 bytes deep. There will additionally be one or two wider,
at 32 to 40 bits wide, and probably a bit deeper too. One side of the
FIFOs runs at 10 to 25 MHz, but occasional sequential accesses are
separated by only 40ns, possibly by only 20ns. The other side mostly
runs at a similar speed, but one application would be ideal if it ran at
60 to 100 MHz.

Of course it is possible to jiggle the design so that the FIFO itself is
synchronised with one clock, and there is logic at the other end to sort
the asynchrisms out. But I'd much prefer all that to be hidden in the
DPRAM clocking, so that I can treat each end as totally independent of
the other end.

If anyone can tell me about problems in dong this with 4kE, I'd be
grateful. If anyone can tell me that any of the other devices really
does this cleanly, I'd also be grateful.

But even if the 4kE devices are the only ones that do the job now, I
still don't want to be saddled with a single manufacturer's tools.

At the moment I'm only interested in up to about 50k "gates", but it's
always easier to use more.

So If I had, say $10k to $15k to spend on CAD tools, including generic,
portable schematics or VHDL, plus P&R for a couple of vendors, what
should I buy?

Paul
-- 
Paul Walker                      4Links                      phone/fax
paul@walker.demon.co.uk          P O Box 816, Two Mile Ash    +44 1908
http://www.walker.demon.co.uk    Milton Keynes MK8 8NS, UK      566253
Article: 7349
Subject: Re: LogiBLOX components in VHDL?
From: "Nick Barton" <laurab@icanect.net>
Date: 29 Aug 1997 12:16:49 GMT
Links: << >>  << T >>  << A >>


Tim Warland <twarland@NOSPAMnortel.ca> wrote in article
<33FAE72B.4487EB71@NOSPAMnortel.ca>...
> Exjobbare Joachim Strombergson wrote:
> >
> > I'm having problems using LogiBLOX components as component instances in
> > my VHDL-code. I'm using the LBGUI tool to customize the blocks to match
> > my need. I then try to include these block in my code by inserting the
> > generated VHI-file into my code and completing the port assignments.
But
> 
> This is the problem.  DO NOT insert the code into your code.  The VHDL
> output is really just a simulatable model, NOT a synthesizable model.
> You should treat the logiblox as a hierarchical piece of the code and
> instantiate the module as a lower hierarchy.  
> 
LBGUI output several files; vhi, vhd and ngo. The vhi has the
component declaration and instantiation, the vhd file is the simulatable
model, and ngo is the xilinx macro. You are correct in adding the vhi
file into your source vhdl. You will need to chop it up a little to
insert thr declaration and instansiation into the right places tho'.

> > when I try to read in the design into Synopsys Design Analyzer the tool
> > does not recognize the component.
> 
> Correct, because it is not synthesizeable.  You just used LBGUI to
> optimize
> the block, don't get Synopsys to have its way with it.  The NGO output
> of the logiblox IS the synthesized code.  In your hierarchical design,
> you need a synthesis black_box or similar don't touch attribute to get
> synopsys to compile the design correctly but not synthesis the LogiBlox
> component. 
> > 
> > I either would like to inlude the LogiBLOX like any other library, and
> > then customize the component with attributes (but don't know how), or
> > somehow make Synopsys realize that the implementation of the component
> > is given by the generated netlist in the NGO-file.
> > 
> LogiBlox does customize the component and you do include the component
> like any other library.  I suggest you look in the documentation for
> examples of including logiblox components. (I'd give it a shot but
> I'm a verilog guy).
> 
To simulate the block you have to complile the vhd file and three xilinx
libraries, these you will find in the xilinx directories under logiblox.

Include this in your simulation (use work.all) and all shlould be fine.

Nick Barton




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