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 30425

Article: 30425
Subject: Re: Why FPGA/CPLDs draw a lot current?
From: "Matti Ruusunen" <matti.ruusunen@removeme.soredex.com>
Date: Sat, 07 Apr 2001 18:01:49 GMT
Links: << >>  << T >>  << A >>
Thank you for the pointer. =) The DC-current consumption was that what
disturbed greatly.

With a quick look at Atmel's ATF1504ASVL the family looks exactly what I've
been hoping for with their sophisticated power consumption handling. I made
an I/O sampler that uses internal binary counter, RC-clock on digital pins
to introduce keyboard-bounce delay, and stores the counter value to a
readonly-SPI-module (worked for Xilinx 9572). It has access to 48 VDC/50mA
power supply but it is not alone and I am trying to cut the general current
consumption level down to increase thresholds.

I wonder if Atmel provides hardcopy documents of their CPLD circuits.

++Matti Ruusunen

Jim Granville <jim.granville@designtools.co.nz> wrote in message
news:3ACE8160.F3@designtools.co.nz...

>  It depends a lot on your frequency, and on the technology.
> All devices have a DC current, and a mA/MHz slope.
>  As the clock frequency increases, all logic will draw more current.
>
>  We are studying CPLD for LCD drivers, and sub 10uA (typ) is looking
> feasible,
> in ATF1504ASVL series - at low freqs these draw less than coolrunner,
>
>  So, if you are using these as IO, and not at tens of MHz, look at the
> ATF15xx family.
>
> Also, given CMOS process nature, VERY low Idd will be easier at 3V than
> 5V.
>
> - jg
> --
> ======= 80x51 Tools & PLD IP Specialists  =========
> = http://www.DesignTools.co.nz



Article: 30426
Subject: Re: xilinx price lists
From: Kolja Sulimma <kolja@prowokulta.org>
Date: Sat, 07 Apr 2001 20:42:06 +0200
Links: << >>  << T >>  << A >>
For a rough estimate go to www.nuhorizons.com

"S. Ramirez" wrote:

>     Here is another reason.  If you are new to this and haven't contacted
> the disties before, be prepared for a barrage of questions, phone calls,
> hiya doings, questions, phone calls, what are you working on, phone calls,
> questions, how many do you need, questions, phone calls, etc.  Until they
> establish clearly what you are working on, what product you need, how many
> of each product you will order and when, and get a design registration in
> place, you will be hounded by these people.

Or they find out that you onbly wnat to spend $1000 now and try to get rid of
you.

Insight germany lied to me, and told me that they had no XC2S samples last
August.
A Xilinx Rep checked the Insight inventory, and found 24 pieces, but Insight
Germany denied.
Then Insight Norway told me about the same 24 pieces in Munich, again Insight
Germany denied.
after repaeting the above with Insight Netherlands suddenly some parts showed
up at a very annoyed
Insight Sales Person.

I only had bad experiences with distributors, but I guess that changes when
you buy a lot.

CU,
        Kolja


Article: 30427
Subject: Re: pseudo random numbers
From: Ray Andraka <ray@andraka.com>
Date: Sat, 07 Apr 2001 18:55:34 GMT
Links: << >>  << T >>  << A >>
FOr generating apparent randomness you are entirely correct.  In the case of
cryptography, it is important to keep the generating function a secret so that
the PN sequence can't be easily re-created.  If you use a single n bit LFSR, you
can determine the polynomial with a small number (IIRC it is n+1) consecutive
samples out of it.  In the crypto world, you use multiple LFSRs to obfuscate the
sequence, not for better apparent randomness, but to make it much more difficult
to recover the generating function from the bitstream.

Rick Collins wrote:
> 
> I have never read a paper on this, but my bet would be that a
> combination of LFSRs is no better than a single LFSR of length equal to
> the sum of the lengths of the short LFSRs being combined. I am sure that
> the length of the combined sequence would be equal to the product of the
> individual lengths and this would be less than or equal to the length of
> the single long LFSR sequence.
> 
> I would be willing to bet that there is a simple way to discover the
> three LFSRs in this examnple or to discover an equivalent single LFSR
> polynomial given a sufficiently long output sequence.
> 
> Ray Andraka wrote:
> >
> > Actually, as long as you take one bit at a time, the randomness of an LFSR is
> > quite good, but the sequencer feedback polynomial as well as the current state
> > can be discovered by looking at the most recent bits, which makes it lousy for a
> > cryptographic application where knowing the sequence allows one to decipher the
> > encypted data.  Using 3 LFSRs in combination obfuscates the sequence enough to
> > make discovery of the generating function much harder.  If it is an encryption
> > you are after, then true enough a single LFSR is not sufficient. But the problem
> > stems from the ability to infer the polynomial and current state, not from the
> > apparent randomness of the bits.
> > --
> > -Ray Andraka, P.E.
> > President, the Andraka Consulting Group, Inc.
> > 401/884-7930     Fax 401/884-7950
> > email ray@andraka.com
> > http://www.andraka.com
> 
> --
> 
> Rick "rickman" Collins
> 
> rick.collins@XYarius.com
> Ignore the reply address. To email me use the above address with the XY
> removed.
> 
> Arius - A Signal Processing Solutions Company
> Specializing in DSP and FPGA design      URL http://www.arius.com
> 4 King Ave                               301-682-7772 Voice
> Frederick, MD 21701-3110                 301-682-7666 FAX

-- 
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com  
http://www.andraka.com

Article: 30428
Subject: Re: XCV1000BG560: onchip ram
From: Ray Andraka <ray@andraka.com>
Date: Sat, 07 Apr 2001 19:02:55 GMT
Links: << >>  << T >>  << A >>
XCV1000 (without the E suffix) has 32 block Rams, each is a 4Kbit dual port RAM,
which you can set up as 1,2,4,8 or 16 bits wide by the corresponding depth to
make 4K bits. Each port of each BRAM has its own set of address, data, clock and
controls. 

"Host addressing RAM" has nothing to do with the chip itself, rather how you
connect those RAMs to a host, if there even is one, in YOUR design.

Richard Martineau wrote:
> 
> the one I'm using has 8Mbytes divided across 4 ram banks i.e. 2Mbytes for
> each bank which each start at 0x0 address using the RC1000PP functions
> assuming you are using the prototyping board. however, when the host is
> addressing the fpga ram it sees it as a continuous block of memory so you
> have to use offsets to the start of each ram bank
> 
> Richard
> 
> <sam> wrote in message news:ee70229.-1@WebX.sUN8CHnE...
> > does anyone have an idea about the exact amount of onchip ram in a xilinx
> virtex XCV1000BG560.
> >
> > sam

-- 
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com  
http://www.andraka.com

Article: 30429
Subject: Re: Why FPGA/CPLDs draw a lot current?
From: Jim Granville <jim.granville@designtools.co.nz>
Date: Sun, 08 Apr 2001 10:09:24 +1200
Links: << >>  << T >>  << A >>
Matti Ruusunen wrote:
> 
> Thank you for the pointer. =) The DC-current consumption was that what
> disturbed greatly.
> 
> With a quick look at Atmel's ATF1504ASVL the family looks exactly what I've
> been hoping for with their sophisticated power consumption handling. I made
> an I/O sampler that uses internal binary counter, RC-clock on digital pins
> to introduce keyboard-bounce delay, and stores the counter value to a
> readonly-SPI-module (worked for Xilinx 9572). It has access to 48 VDC/50mA
> power supply but it is not alone and I am trying to cut the general current
> consumption level down to increase thresholds.

Another tip: For clock generators, at low frequencies we found the
HEF4541 the best
with a low  ~2.1V startup voltage. It draws under 10uA with a 32Khz
Xtal, and
is available in a small SO14 package, at appx 21c/1K.

> 
> I wonder if Atmel provides hardcopy documents of their CPLD circuits.

Yes.

-jg

Article: 30430
Subject: Re: How to combine bus in schematic
From: Thomas Heidel <thomas.heidel@nexgo.de>
Date: Sat, 07 Apr 2001 22:09:54 +0000
Links: << >>  << T >>  << A >>
Dave Vanden Bout wrote:
> 
> Helen Long wrote:
> 
> > I just used DATAIN(23 downto 0)
> > however in schematic we only have IPAD(16) & IPAD(8)
> > I don't know how to combine them together
> > Thanks a lot!
> 
> I don't know what schematic editor you are using, but here is how to do
> it with the editor in Xilinx Foundation:
> 
> 1) Attach a bus to an instance of IPAD16 and name it DATAIN[15..0].
> 2) Attach another bus to an instance of IPAD8 and name it DATAIN[7..0].

I think this isn't exactly what Helen is looking for.
In the case she needs a 24-bit wide bus, the bus connected to IPAD16
should read DATAIN[23..8].


> 
> --
> || Dr. Dave Van den Bout   XESS Corp.               (919) 387-0076 ||
> || devb@xess.com           2608 Sweetgum Dr.        (800) 549-9377 ||
> || http://www.xess.com     Apex, NC 27502 USA   FAX:(919) 387-1302 ||

Article: 30431
Subject: Handel-C
From: "Compilit" <compilehr@yahoo.com>
Date: Sat, 7 Apr 2001 18:46:03 -0700
Links: << >>  << T >>  << A >>
Does anyone what the future will be like for Verilog and VHDL ?

Wil it be replaced by C/C++ platform ?

It looks like Handel C is taking oof.

What I am wondering is will DK-1 suite be able to convert the test benches
into a supported
language as well ? For ASIC conversion, that is..

http://www.infoconomy.com/pages/search/group18585.adp

http://isdmag.com/story/OEG20010301S0056

http://www.celoxica.com/news/in_the_news.htm



Article: 30432
Subject: Re: Handel-C
From: "Compilit" <compilehr@yahoo.com>
Date: Sat, 7 Apr 2001 18:47:22 -0700
Links: << >>  << T >>  << A >>
I mean, will Verilog and VHDL experts become devalued in the future ?

"Compilit" <compilehr@yahoo.com> wrote in message
news:9aoga1$qt8$1@taliesin.netcom.net.uk...
> Does anyone what the future will be like for Verilog and VHDL ?
>
> Wil it be replaced by C/C++ platform ?
>
> It looks like Handel C is taking oof.
>
> What I am wondering is will DK-1 suite be able to convert the test benches
> into a supported
> language as well ? For ASIC conversion, that is..
>
> http://www.infoconomy.com/pages/search/group18585.adp
>
> http://isdmag.com/story/OEG20010301S0056
>
> http://www.celoxica.com/news/in_the_news.htm
>
>



Article: 30433
Subject: Re: Handel-C
From: "S. Ramirez" <sramirez@cfl.rr.com>
Date: Sun, 08 Apr 2001 02:27:54 GMT
Links: << >>  << T >>  << A >>
     I personally think that HDLs will evolve to C eventually, but the real
problem is that HDL is only a part of FPGA design.  Just ask anyone in this
newsgroup about all of the problems involved with FPGA design.  The majority
of them are not HDL problems.  Therefore, one cannot take a programmer
(read: non hardware engineer), teach him/her Handel-C and expect him/her to
simply start cranking out FPGA designs.  That person will have to know about
timing problems, metastability, floorplanning and a bunch of other skills
that are commonly required to complete an FPGA design.  Essentially, that
person has to be a hardware person.
     The first link given below is to an article about Celoxica.  It's
obvious that this article was written by a semi-technical person, since
(s)he refers to VHDL as "Verilog HDL."  The article to me reads simply as
marketing hype for this new language and tools.  I am not saying that they
will not take off, but I doubt that they will unless they can get a
significant amount of us to go that way.  I wish the company well, and I am
always looking for new, better and cheaper tools, but my present design flow
and methodology is sufficing quite well.
Simon Ramirez, Consultant
Synchronous Design, Inc.
Oviedo, FL  USA


"Compilit" <compilehr@yahoo.com> wrote in message
news:9aoga1$qt8$1@taliesin.netcom.net.uk...
> Does anyone what the future will be like for Verilog and VHDL ?
>
> Wil it be replaced by C/C++ platform ?
>
> It looks like Handel C is taking oof.
>
> What I am wondering is will DK-1 suite be able to convert the test benches
> into a supported
> language as well ? For ASIC conversion, that is..
>
> http://www.infoconomy.com/pages/search/group18585.adp
>
> http://isdmag.com/story/OEG20010301S0056
>
> http://www.celoxica.com/news/in_the_news.htm
>
>
>



Article: 30434
Subject: Re: Books for trade
From: "Compilit" <compilehr@yahoo.com>
Date: Sat, 7 Apr 2001 21:22:13 -0700
Links: << >>  << T >>  << A >>
I don't need Cohen's book for the moment.

But still need the 3 books listed below. Got everything else.
Will consider computer Arithmetic books.

May be I should take some cash offer :-)

> "Compilit" <compilehr@yahoo.com> wrote in message
> news:99u33j$f7l$1@taliesin.netcom.net.uk...
> > I have some EE books for trade. I am in the San Francisco Area.
> >
> > These all are all in brand new, unnused condition. Some have CD-ROM's
> > included that are not yet opened.
> > I bought them for a project now currently on hold.
> >
> > Please search www.abebooks.com or www.powells.com or www.Amazon.com for
> good
> > deals on these, and get back to me. Please help me to get the books I
> need.
> >
> > The following list are what I currently have extra to be given away:
> >
> > 1/ Designer's Guide to VHDL by Peter Ashenden
> >
>
http://www.amazon.com/exec/obidos/ASIN/1558602704/qid=985827963/sr=1-3/ref=s
> > c_b_4/002-1116465-7214451
> > 2/ VHDL Analysis and Modeling of Digital systems 2ed by Navabi
> >
> > 3/ Computer Architechiture, and Quantitative Approach.
> >
> > 4/ Verilog Digital Computer Design. Algorithms into Hardware by Arnold
> >
> > 5/ Real World FPGA Design with Verilog by Ken Coffman
> >
> > 6/ VHDL Representation and Synthesis by Armstrong and Gary
> >
> > 7/ VHDL made easy by Tellering and Taylor
> >
> > 8/ Verilog HDL by Palnitkar
> >
> > 9/ Verilog Designer's Library by Zeidman
> >
> > 10/ Timing Verification (ASIC) by Farzd Nekoogar
> >
>
http://www.amazon.com/exec/obidos/ASIN/0137943482/ref=sim_books/002-1116465-
> > 7214451
> >
> > 11/ VHDL by Douglas Perry
> >
> > 12/ VHDL for programmable logic by Kevin Skahill
> >
> > 13/ Real Time Signal Processing John G. Ackenhusen
> >
>
http://www.amazon.com/exec/obidos/ASIN/0136317715/qid=985827868/sr=1-2/ref=s
> > c_b_3/002-1116465-7214451
> >
> > 14/ Object Oriented Perl by Conway
> >
> > 15/ Programming and Customizing PIC controller Predro
> >
> > 16/ PCI-X System Architecture Mindshare INC
> >
> > 17/ Application-Specific Integrated Circuits. By Smith
> >
> > 18/ VHDL for Logic Synthesis by Andrew Rushton
> >
http://www.amazon.com/exec/obidos/search-handle-form/002-1116465-7214451
> >
> > =====================================================================
> >
> >
> > The following are what I am in desparate need for, I don't mind them in
> used
> > conditions:
> >
> > >
> > 2/ System-on-a-Chip Verification - Methodology and Techniques
> >
>
http://www.amazon.com/exec/obidos/ASIN/0792372794/qid=985827145/sr=1-4/ref=s
> > c_b_5/002-1116465-7214451
> >> >
> > 6/PRINCIPLES OF VERILOG PLI
> > by Swapnajit Mittra
> > http://www.powells.com/cgi-bin/biblio?inkey=4-0792384776-0
> >
> > 7/VHDL Coding and Logic Synthesis with Synopsys by Weng Fook Lee
> >
>
http://www.amazon.com/exec/obidos/ASIN/0124406513/qid=985827963/sr=1-6/ref=s
> > c_b_7/002-1116465-7214451
> >
> > Thank you,
> > Peace.
> >
> > Please click reply to email me.
> >
> >
>
>



Article: 30435
Subject: Re: Handel-C
From: "niki" <guest@my.net>
Date: Sun, 08 Apr 2001 06:11:59 GMT
Links: << >>  << T >>  << A >>
HDL is not only a part of FPGA design but also a kind of blueprint for all
chip design using digital and analog logic. HDL was devised to describe a
hardware system effectively. HDL itself is not concerned about timing,
metastability and floorplaning of FPGA/ASIC/Full Custom/Semi-Custom design.
Thesedays it seems that folks think writing HDL as writing software codes
thanks to synthesis tools. However, HDL is not a piece of software code
like C/C++ but a truly dedicated language describing hardware.

Chung, MA 


S. Ramirez <sramirez@cfl.rr.com>이(가)
<K0Qz6.55451$Lz6.8753675@typhoon.tampabay.rr.com> 기사에서 작성했습니다...
>      I personally think that HDLs will evolve to C eventually, but the
real
> problem is that HDL is only a part of FPGA design.  Just ask anyone in
this
> newsgroup about all of the problems involved with FPGA design.  The
majority
> of them are not HDL problems.  Therefore, one cannot take a programmer
> (read: non hardware engineer), teach him/her Handel-C and expect him/her
to
> simply start cranking out FPGA designs.  That person will have to know
about
> timing problems, metastability, floorplanning and a bunch of other skills
> that are commonly required to complete an FPGA design.  Essentially, that
> person has to be a hardware person.


Article: 30436
Subject: Re: Handel-C
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Sun, 08 Apr 2001 09:02:29 +0100
Links: << >>  << T >>  << A >>


"S. Ramirez" wrote:

>      I personally think that HDLs will evolve to C eventually, but the real
> problem is that HDL is only a part of FPGA design.  Just ask anyone in this
> newsgroup about all of the problems involved with FPGA design.  The majority
> of them are not HDL problems.  Therefore, one cannot take a programmer
> (read: non hardware engineer), teach him/her Handel-C and expect him/her to
> simply start cranking out FPGA designs.  That person will have to know about
> timing problems, metastability, floorplanning and a bunch of other skills
> that are commonly required to complete an FPGA design.  Essentially, that
> person has to be a hardware person.
>      The first link given below is to an article about Celoxica.  It's
> obvious that this article was written by a semi-technical person, since
> (s)he refers to VHDL as "Verilog HDL."  The article to me reads simply as
> marketing hype for this new language and tools.  I am not saying that they
> will not take off, but I doubt that they will unless they can get a
> significant amount of us to go that way.  I wish the company well, and I am
> always looking for new, better and cheaper tools, but my present design flow
> and methodology is sufficing quite well.
> Simon Ramirez, Consultant
> Synchronous Design, Inc.
> Oviedo, FL  USA

I would agree & I would go further even than Simon. Although looking at Handel-C
itself it seems that it would do the job it seems that the marketing strategy of
these C-based HDL tools companies has very little to do with the technicalities.
They are mostly trying to talk to managers and saying:

``Hey guys here are some tools that will allow you to throw away all those
expensive, rare h/w types & replace them with off-the-shelf el-cheapo s/w
grunts''

The sad thing is my experience of most management types says they will buy it -
its what MBA training is all about. Remember these are the same people for who
marketing target with their  whizzo GUIs [what other purpose do all those screen
shots on the Web serve ?].

What I actually don't understand is why the C-based tools are needed ? Verilog
is so easy to write that at the pure coding level any reasonably competent C/C++
programmer could pick it up in a couple of days. Then with a couple of years
practice they might, if they have the right mentality (*), get to produce h/w
that's not an embarrasment to their company.

(*) This is not just to do with timing, metastability, etc. My fear here is that
s/w types do not have the deep, ingrained, awareness that from day 1, hour 1,
minute 1 of design start any mistake they make could be fatal. s/w bug = fix it
& put a patch file on the Web, h/w bug =  a $250K+ ASIC respin.


Article: 30437
Subject: Re: xilinx price lists
From: Dave Vanden Bout <devb@xess.com>
Date: Sun, 08 Apr 2001 08:57:13 -0400
Links: << >>  << T >>  << A >>
Richard Martineau wrote:

> hello everybody
>
> does anyone have a spare minute to tell me where I can get a price list for
> Xilinx Spartan 2 range?
>
> Richard

Go to http://www.em.avnet.com and do a search for parts starting with "XC2S".
You will get prices for all Spartan2 speed grades and packages.  You don't get
any large-volume pricing and the small quantity pricing is a few bucks more
than what you will get from your distributor, but it will give you an idead of
what you will have to pay and the relative prices of various options.


--
|| Dr. Dave Van den Bout   XESS Corp.               (919) 387-0076 ||
|| devb@xess.com           2608 Sweetgum Dr.        (800) 549-9377 ||
|| http://www.xess.com     Apex, NC 27502 USA   FAX:(919) 387-1302 ||



Article: 30438
Subject: Re: How to combine bus in schematic
From: Dave Vanden Bout <devb@xess.com>
Date: Sun, 08 Apr 2001 08:58:49 -0400
Links: << >>  << T >>  << A >>
Thomas Heidel wrote:

> Dave Vanden Bout wrote:
> >
> > Helen Long wrote:
> >
> > > I just used DATAIN(23 downto 0)
> > > however in schematic we only have IPAD(16) & IPAD(8)
> > > I don't know how to combine them together
> > > Thanks a lot!
> >
> > I don't know what schematic editor you are using, but here is how to do
> > it with the editor in Xilinx Foundation:
> >
> > 1) Attach a bus to an instance of IPAD16 and name it DATAIN[15..0].
> > 2) Attach another bus to an instance of IPAD8 and name it DATAIN[7..0].
>
> I think this isn't exactly what Helen is looking for.
> In the case she needs a 24-bit wide bus, the bus connected to IPAD16
> should read DATAIN[23..8].

Yes, you are right.



>
>
> >
> > --
> > || Dr. Dave Van den Bout   XESS Corp.               (919) 387-0076 ||
> > || devb@xess.com           2608 Sweetgum Dr.        (800) 549-9377 ||
> > || http://www.xess.com     Apex, NC 27502 USA   FAX:(919) 387-1302 ||




--
|| Dr. Dave Van den Bout   XESS Corp.               (919) 387-0076 ||
|| devb@xess.com           2608 Sweetgum Dr.        (800) 549-9377 ||
|| http://www.xess.com     Apex, NC 27502 USA   FAX:(919) 387-1302 ||



Article: 30439
Subject: Re: Handel-C
From: "Robert Carney" <bobcarney@worldnet.att.net>
Date: Sun, 08 Apr 2001 18:28:44 GMT
Links: << >>  << T >>  << A >>
some lines below deleted, sorry if I mis-snipped....

Rick Filipkiewicz <rick@algor.co.uk> wrote......

> "S. Ramirez" wrote:
> >      I personally think that HDLs will evolve to C eventually,

Saying HDLs will evolve to C is like saying humans will evolve to monkeys.

>> but the real problem is that HDL is only a part of FPGA design>
>> They are mostly trying to talk to managers and saying:
> ``Hey guys here are some tools that will allow you to throw away all those
> expensive, rare h/w types & replace them with off-the-shelf el-cheapo s/w
> grunts''
>
> The sad thing is my experience of most management types says they will buy
it -
> its what MBA training is all about. Remember these are the same people for
who
> marketing target with their  whizzo GUIs [what other purpose do all those
screen
> shots on the Web serve ?].
>
> What I actually don't understand is why the C-based tools are needed ?
Verilog
> is so easy to write that at the pure coding level any reasonably competent
C/C++
> programmer could pick it up in a couple of days. Then with a couple of years
> practice they might, if they have the right mentality (*), get to produce
h/w
> that's not an embarrasment to their company.
>
> (*) This is not just to do with timing, metastability, etc. My fear here is
that
> s/w types do not have the deep, ingrained, awareness that from day 1, hour
1,
> minute 1 of design start any mistake they make could be fatal. s/w bug = fix
it
> & put a patch file on the Web, h/w bug =  a $250K+ ASIC respin.
>

I think that if C alone were enough for hardware design, it would have
been used instead of Verilog or VHDL.  As it turns out, the programmer's
model is quite different for one case compared to the other.   For C, as
with other system programming languages, the focus is on algorithms and
data structures used in the one-instruction at a time sequential flow.
To support hardware modeling, it was necessary to extend C to allow
the programmer to model the passage of time and the execution of
statements in concurrent processes.    Not that such a thing couldn't
be done in C  (Verilog is sometimes referred to as "C+-"  ;-)  ,  but the C
extensions need to be done in a "standard" way, to encourage the
support of third-party vendors (cell libraries, verification, synthesis...)
Maybe someday we'll have a set of standard libraries that extend
some other language to replace Verilog or VHDL.   When that happens,
we'll still need "domain experts" , i.e., digital hardware savvy types
who can use the language to perform the modeling and analysis for
which it is intended.   There has never been and probably never will
be a threat to employment security for hardware types from those
who are merely programmers, anymore than physicians are threatened
by others who happen to speak English or who have read about medicine
in a book somewhere.



Article: 30440
Subject: Re: Handel-C
From: "niki" <guest@my.net>
Date: Sun, 08 Apr 2001 18:37:07 GMT
Links: << >>  << T >>  << A >>
I totally agree with you. HDL is for hardware modelling. It is 100%
different from what software guys think in C prgramming. It is not that
different from schematic drawing of hardware components. If you don't have
a good idea about what hardware should be, you can't be a good HDL
designer. (designer! not programmer...)


Article: 30441
Subject: Re: Handel-C
From: "Robert Carney" <bobcarney@worldnet.att.net>
Date: Sun, 08 Apr 2001 19:16:17 GMT
Links: << >>  << T >>  << A >>
Here's an idea for a C programmer who wants
to help out in hardware design.  Learn about
the PLI.   Write some code that helps hw people
analyze and report on simulation activity.
With the PLI, your C code can be referenced
from a simulation as a library object.  With
some simulators, the library is linked dynamically,
so it's not even necessary to rebuild the simulator
to take advantage of the nifty new widget you've
created for the hardware design and verification
community.  Even better yet, with the emerging
Superlog language, you can inline your C code
in Verilog.   Who knows, in a a few years, we
may be able to inline x86 asm in Verilog.



Article: 30442
Subject: Re: Asynchronus Mashine States
From: "Robert Carney" <bobcarney@worldnet.att.net>
Date: Sun, 08 Apr 2001 19:40:03 GMT
Links: << >>  << T >>  << A >>

Ray Andraka <ray@andraka.com> wrote.....
> They may be teh wave of the future,

always has been, and always will be ;-)

Reminds me of so many other "waves of the future"
that fail to deliver or become a significant part of
mainstream technology, but still manage to hang on
with occasional references in EETimes or some
other tech pub.   Things like Rambus, AI, "expert
systems", push technology, JAVA, etc., etc.   Of
course, it's not the kind of thing you should joke
about with anyone who has a vested interest at
stake....   Still, I'm amazed at the time and money
invested by so many people in so many obviously
un-needed product and/or technology ideas.   It
sometimes seems as though engineering is devolving
into an arena of artist-types striving for style-du-jour
distinction instead of the old-fashioned community
effort with exploration, discovery, and shared skill
development that characterized the chip business
during the first few decades.



Article: 30443
Subject: Re: Handel-C
From: Bob Perlman <bob@cambriandesign.com>
Date: Sun, 08 Apr 2001 19:43:59 GMT
Links: << >>  << T >>  << A >>
On Sat, 7 Apr 2001 18:46:03 -0700, "Compilit" <compilehr@yahoo.com>
wrote:

>Does anyone what the future will be like for Verilog and VHDL ?
>
>Wil it be replaced by C/C++ platform ?
>
>It looks like Handel C is taking oof.

>
>What I am wondering is will DK-1 suite be able to convert the test benches
>into a supported
>language as well ? For ASIC conversion, that is..
>
>http://www.infoconomy.com/pages/search/group18585.adp
>
>http://isdmag.com/story/OEG20010301S0056
>
>http://www.celoxica.com/news/in_the_news.htm
>

These articles make it clear that Celoxica would like Handel-C to take
off.  Whether it will is another matter.

Years ago, I used C (and FORTRAN--remember that?) to do cycle-based
simulations of hardware, but gave that up when capable HDLs came
along.  I'm not saying that C will never evolve in such a way as to
supplant current HDLs, but I'm skeptical.

If Celoxica and similar companies convince managers that their
software people can use a C-like language to design FPGAs, that's
tantamount to declaring a guaranteed employment act for FPGA
consultants; we'll be cleaning up the mess for years. 

Bob Perlman


Article: 30444
Subject: Re: Spartan II Configuration
From: "Jan Kindt" <jan.kindt@spammenot.pandora.be>
Date: Sun, 08 Apr 2001 19:51:15 GMT
Links: << >>  << T >>  << A >>
Dean,

some comments...

> I then use the Xilinx Design Manager to generate a bitstream for this
> device.
> All appears to go well up to here.

Did you watch to set the configuration clock to JTAG clock. After the
configuration stream is sent, the spartan needs some more clocks to enable
IO, disable GTS, release GSR, release DONE, and so on... You have to specify
to bitgen which clock to use for this sequence.

>
> I enter the JTAG programmer. Connect to the cable and initialise the
> chain.
> The device is detected as being a Virtex XCV100.
> I assign the bitstream file I have created to the device. (which is
> targeted to an XC2S100_PQ208)
> I can get the ID number and the signature/usercode number from the
> device.

It's perfectly normal the spartan is detected as a virtex device... they all
do.

>
> 'cpu_wrapper(Device1)': Checking boundary-scan chain integrity...done.
> 'cpu_wrapper(Device1)': Reading bit-stream file...done.
> 'cpu_wrapper(Device1)': Programming device.....done.
> 'cpu_wrapper(Device1)': If the security flag is turned on in the
> bitstream,
> programming status can not be confirmed; otherwise,
> programming terminated due to error.
>

Don't expect to much of JTAG-programmer's error messages.. They point to the
wrong error most of the time...

hope this helps a bit...

Jan



Article: 30445
Subject: Alternative to Xilink Foundation schematic editor
From: "[Pedro Silva]" <pedro_silva@oninet.pt>
Date: Sun, 8 Apr 2001 21:02:10 +0100
Links: << >>  << T >>  << A >>

    Is there an alternative to Xilink Foundation schematic editor?
    I am using a 4000E board with the Xilink Software in my university, but
I need to do some things in home. Can't I use another editor to build my
circuits and then use them with Xilink Software?

    Thank you.



Article: 30446
Subject: Re: FPGA configuration from processor
From: hmurray-nospam@megapathdsl.net (Hal Murray)
Date: Sun, 08 Apr 2001 20:38:46 -0000
Links: << >>  << T >>  << A >>

>If your FPGA is the PCI Interface, you have no choice than configuring the FPGA
>without PC CPU interaction, for example from a FLASHROM that is controled by a
>CPLD or small embedded CPU or from one of these expensive configuration PROMs.

I mostly agree, but you can cheat if you are debugging (or just
have a hacker mentality).

Suppose you power up your machine.  The FPGA on your PCI card
hasn't been configured so your BIOS won't find it when it
scans for devices.  This assumes you are using a machine with a
typical BIOS.

Now load your FPGA, say over USB or the printer port.  The card
is now alive, but the BIOS didn't assign it any addresses so
you can't really use it.

If you reset your machine (without powering it off) the BIOS
will run again and find your card and assign it address space.

If you are using a stand alone system, you can assign the
addresses yourself.  Or if you are writing the BIOS you could
add a hook for this case.

...

-- 
These are my opinions, not necessarily my employeers.  I hate spam.


Article: 30447
Subject: Re: Spartan II Configuration
From: Dean Armstrong <daa1@cs.waikato.ac.nz>
Date: Mon, 09 Apr 2001 09:11:49 +1200
Links: << >>  << T >>  << A >>
Thanks for the comments Jan.

I did not have the configuration clock set to JTAG clock. I have done this but
it still does
exactly the same thing. Is it possible that the order in which the startup stuff
is done could
affect things?

This is quite frustrating. I thought that JTAG programming was supposed to
be fairly foolproof.

Cheers,
Dean

Jan Kindt wrote:

> Dean,
>
> some comments...
>
> > I then use the Xilinx Design Manager to generate a bitstream for this
> > device.
> > All appears to go well up to here.
>
> Did you watch to set the configuration clock to JTAG clock. After the
> configuration stream is sent, the spartan needs some more clocks to enable
> IO, disable GTS, release GSR, release DONE, and so on... You have to specify
> to bitgen which clock to use for this sequence.
>
> >
> > I enter the JTAG programmer. Connect to the cable and initialise the
> > chain.
> > The device is detected as being a Virtex XCV100.
> > I assign the bitstream file I have created to the device. (which is
> > targeted to an XC2S100_PQ208)
> > I can get the ID number and the signature/usercode number from the
> > device.
>
> It's perfectly normal the spartan is detected as a virtex device... they all
> do.
>
> >
> > 'cpu_wrapper(Device1)': Checking boundary-scan chain integrity...done.
> > 'cpu_wrapper(Device1)': Reading bit-stream file...done.
> > 'cpu_wrapper(Device1)': Programming device.....done.
> > 'cpu_wrapper(Device1)': If the security flag is turned on in the
> > bitstream,
> > programming status can not be confirmed; otherwise,
> > programming terminated due to error.
> >
>
> Don't expect to much of JTAG-programmer's error messages.. They point to the
> wrong error most of the time...
>
> hope this helps a bit...
>
> Jan


Article: 30448
Subject: Re: Handel-C
From: cyber_spook <pjc@cyberspook.freeserve.co.uk>
Date: Sun, 08 Apr 2001 22:54:43 +0100
Links: << >>  << T >>  << A >>
All your comments are very true - However as a hardware engineer with a large
amout of software experiance I feel that a very important point is being
missed.

VHDL is like programing in assembly language but with some very nice added
funtions - you realy do need to undatand the target you are writing for!
however 'C' started to change that - a function written for an x86 could be
complied for a 6800!

What I'm getting at is that there are a lot of out of work C programmers that
with some experance of Handel-C are going to cross the border. Not to become
hard core hardware enginees but will fill the joinior engineer posts and alike
- from there is the opertunity for them to learn new skills and move up the
ladder. I see the coming of Handel-C as a was of getting more hardware
engineers and lowing the amount of unemployed Softy's.

However the problem is that there will be many more people leaving Uni with
these skills that don't understand the lower functions of hardware just as is
already happening in software - I used to work with a chap that was a very
good C programmer that had no idear what a register or a ALU was !? A product
of Uni mass production!?

And can I also point out that most hardware engineers work with Sotware
engineers (or should be) to get the best results. Lets not have a them and us
point of view! sometims a different approch is what is needed!

At the end of the day if you are good at what you do - why worry - its the
hardware chaps that have been blagging there boss for years that are in
danger!

Cyber_Spook

niki wrote:

> I totally agree with you. HDL is for hardware modelling. It is 100%
> different from what software guys think in C prgramming. It is not that
> different from schematic drawing of hardware components. If you don't have
> a good idea about what hardware should be, you can't be a good HDL
> designer. (designer! not programmer...)


Article: 30449
Subject: Re: Asynchronus Mashine States
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Sun, 08 Apr 2001 23:18:03 +0100
Links: << >>  << T >>  << A >>


Robert Carney wrote:

> Ray Andraka <ray@andraka.com> wrote.....
> > They may be teh wave of the future,
>
> always has been, and always will be ;-)
>
> Reminds me of so many other "waves of the future"
> that fail to deliver or become a significant part of
> mainstream technology, but still manage to hang on
> with occasional references in EETimes or some
> other tech pub.   Things like Rambus, AI, "expert
> systems", push technology, JAVA, etc., etc.   Of
> course, it's not the kind of thing you should joke
> about with anyone who has a vested interest at
> stake....   Still, I'm amazed at the time and money
> invested by so many people in so many obviously
> un-needed product and/or technology ideas.   It
> sometimes seems as though engineering is devolving
> into an arena of artist-types striving for style-du-jour
> distinction instead of the old-fashioned community
> effort with exploration, discovery, and shared skill
> development that characterized the chip business
> during the first few decades.

You missed my all-time favourite one of these ``The paper-less office''.






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