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

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

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

Custom Search

Messages from 47850

Article: 47850
Subject: Re: TCP/IP in FPGA
From: Phil Hays <SpamPostmaster@attbi.com>
Date: Sat, 05 Oct 2002 17:26:39 GMT
Links: << >>  << T >>  << A >>
Will wrote:
 
> By its very nature, TCP/IP is not real time. Network can have delays,
> packets can get lost. I think TCP/IP lends itself better to a
> software implementation.

I agree, unless you have lots of data to send/receive.  Then software
can't keep up.


> Well, it's interesting if you can jam all the TCP logic in a sub 1000 k gates
> , do all the checksumming in one clock cycle, match IP's in a CAM, etc...

The key phrase is "wire speed".


-- 
Phil Hays

Article: 47851
Subject: Re: TCP/IP in FPGA
From: nweaver@ribbit.CS.Berkeley.EDU (Nicholas C. Weaver)
Date: Sat, 5 Oct 2002 17:36:24 +0000 (UTC)
Links: << >>  << T >>  << A >>
In article <3D9F21D0.12AAC8B@attbi.com>,
Phil Hays  <SpamPostmaster@attbi.com> wrote:

>> Well, it's interesting if you can jam all the TCP logic in a sub
>> 1000 k gates , do all the checksumming in one clock cycle, match
>> IP's in a CAM, etc...

>The key phrase is "wire speed".

However, until you are doing 1Gb+ packet processing, EL Cheapo
Embedded PC (EG, the Via EPIA system, very cute) has enough horespower
to keep up with TCP and have a fair amount left over.

Gb+ is another kettle of fish.  I WANT, WANT, WANT, a PCI card with a
V2Pro and quad Gb ethernet.
-- 
Nicholas C. Weaver                                 nweaver@cs.berkeley.edu

Article: 47852
Subject: Re: DCM outputs skew question
From: hmurray@suespammers.org (Hal Murray)
Date: Sat, 05 Oct 2002 17:45:50 -0000
Links: << >>  << T >>  << A >>
>If b and c are in adjacent CLBs, the routing time could be extremely 
>small and a skew due to external jitter and/or internal clock net skew 
>could result in a metastable event.

You don't need metastability to cause problems in that sort of setup.

You can get in trouble with pure setup problems.  If the clock on
the second FF is a bit late it will see the new value rather than
the old value.

-- 
The suespammers.org mail server is located in California.  So are all my
other mailboxes.  Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's.  I hate spam.


Article: 47853
Subject: Re: Moving average filter
From: John Larkin <jjlarkin@highSNIPlandTHIStechPLEASEnology.com>
Date: Sat, 05 Oct 2002 13:11:34 -0700
Links: << >>  << T >>  << A >>
On Thu, 03 Oct 2002 02:10:55 -0000, hmurray@suespammers.org (Hal
Murray) wrote:

>
>>i want to implement a moving average filter in my FPGA. That's not the 
>>big problem, but the window size of the filter should be changeable 
>>during runtime...
>
>This isn't what you asked for, but it might be good enough.
>
>You can get a weighted-average without any memory if you can multiply.
>The recent samples get more weight and the weight of older samples decays
>exponentialy.
>
>Formula is:
>  new-avg = old-avg*(1-w) + sample*w
>Where w is less than 1.
>
>Values of w like 1/8 are typically used in networking code to
>"average" out round trip time measurements.
>
>If you pick w to be a power of 2 then the multiply is just a shift.
>General barrel-shifters are ugly, but it might be OK if you only
>want to use a few values of w.
>
>Or you could use a real multipler and then use any value of w that
>you want.  Note there are no glitches when changing w between samples.


Another way to express this is

   out = out + (in-out)/n

where n is a power of two, namely a right shift. OUT will obvioulsy
need more bits than IN, in order not to lose the shifted stuff.

John


Article: 47854
Subject: Re: Goertzel algorithm tone detector
From: nnadal@terra.es (=?ISO-8859-1?Q?Narc=EDs_Nadal?=)
Date: 5 Oct 2002 13:34:20 -0700
Links: << >>  << T >>  << A >>
"Darryl Groom" <dgroom@continental-microwave.co.uk> wrote in message news:<ee795d5.-1@WebX.sUN8CHnE>...
> Has anyone tried to implement a tone detector based around a goertzel algorithm filter.  I am looking for an example in VHDL or schematic form as we are experiencing difficulty in getting the System Generator software working to be able to pull our Matlab/Simulink model into the Spartan-II device we are currently using.

Is the first time I heard about goertzel and had to do a search with
the google. Its very interesting but if you want a very fast and easy
way to detect DTMF tones or other frequencies perhaps I may help you.

5 years ago I began a project whith the slowest CPU I know, the ST6,
and was decoding DTMF from the telephone line to detect the numbers
typed from any phone of a house. Early becomes evident that the
methods learned in the university was unusables for that CPU and I
began investigating and simulating other ways. The solution came from
taking the essence of the Fourier Transform. I conver all analog
signal to digital without using the ST6'ADC, I feed an smith trigger
whith the analog line for doing right edges, and then directly to an
ST6 digital input. The Fourier resulting coefficients were stored in 8
counters, each one representing a frequency. The counters with greater
values showed the frequencies received .

I will try to explain it in my poor english, for detecting the tones
we dont need to calculate the exact values of the coeficients but only
the ones with greater values thus we can eliminate the final
calculations, making the resulting coeficients of the Fourier
Transform obtained multiplicating the right point of the sine and
cosine waves and adding or substracting the resulting value to others
obtained before. First at all I calculate this waves and put them in a
constant binary table which contains a "1" if the wave was >0 volts in
this point and a "0" if was <0 volts. The sum of values for making the
coeficients was stored in up-down counters, I thing 2 for every
frequency.

You also need 2*n tables, been n the number of frequencies detected.
You dont need to multiplicate anything because the tables and the
input are 1 bit values, you only XOR the two values. Dont add the
resulting value to the others because is 1 bit wide, store it in a
counter. When the result was "1" I incremented the right counter, and
when was "0" I decremented it, or incremented another one. Well, I
dont remember exactly how it was but the simulations on BorladC++
showed a strong correlation between the input frequences and the value
of the counters. I remember to simulate a lot and as more samples
taken more correlation done and the other counters had very low
values.

It was incredible to put that in so slow CPU but it worked very well,
if you dont belive it you can simulate with a C++ program. If you
implement that in a FPGA I am sure the wasted recurses will be much
lower than whith the Goertzel Algorithm filter,and once the
simulations were done you can implement it in few hours, even in
schematics because it only has any counters, rom tables and xor gates.
Of course if you are interested I can give you more details and look
for the simulations.

Narcís Nadal

Article: 47855
Subject: Re: TCP/IP in FPGA
From: wv9557@yahoo.com (Will)
Date: 5 Oct 2002 14:52:49 -0700
Links: << >>  << T >>  << A >>
People has been doing minimal TCP that is only a few pages of C code.
The thing is why would I want to buy a 500 bucks TCP accelerator when
the most I could get on my modem is 50 kbits/sec. There is not a market
for TCP/IP in hardware. Not for the home user anyway.

hmurray@suespammers.org (Hal Murray) wrote in message news:<upjioaku2e1le1@corp.supernews.com>...
> [suggest software]
> > iam not looking for such a solution TCP/IP in hardware is it feasible
> 
> Look at the source code for a TCP stack.  It's a huge state machine.
> Just take a page or two of code and try to convert that to hardware.
> 
> I haven't seen any reports of doing TCP in hardware, but I could
> easily have missed something.  (But somebody would probably mention
> it here.)
> 
> As an example, consider just routing, a small part of the TCP/IP stack.
> High end routers do some of the table lookup in hardware, but they
> normally drop back to software for the hard/rare cases.

Article: 47856
Subject: Re: DDS in PLD?
From: Peter Alfke <peter@xilinx.com>
Date: Sat, 05 Oct 2002 15:43:17 -0700
Links: << >>  << T >>  << A >>
I am working on a DDS-based pulse generator with 1 Hz to 1 GHz output
frequency and a resolution of 10,000 steps per octave.
For the GHz output, I need Virtex-IIPro, but 300 MHz (600Mbps) with LVDs could
be done in an XC2V40. Even multiple independent outputs, and/or a built-in
frequency counter.
The problem is keeping the jitter down, well below one clock period...
Send me e-mail, and we can talk about details.

BTW, CoolRunner is a more modern CPLD family, and what's the problem with 24
bit accumulation? Speed?

Peter Alfke, Xilinx Applications
===============================
Peter Hiscocks wrote:

> We're building a function generator that uses a 24 bit Direct Digital
> Synthesis oscillator. It will fit into an FPGA with no problem, but I'd
> really like to shoehorn this thing into a PLD to avoid the need for a boot
> ROM chip and to keep the cost down.
>
> The Xilinx 9000 series PLD's I've tried won't do because of the requirement
> for a 24 bit adder. Anyone have any suggestions of other chips I should
> investigate for this?
>
> Thanks for the help -
> Peter
>
> --
> Peter D. Hiscocks
> Department of Electrical and Computer Engineering
> Ryerson University,
> 350 Victoria Street,
> Toronto, Ontario, M5B 2K3, Canada
>
> Phone:   (416) 979-5000 Ext 6109
> Fax:     (416) 979-5280
> Email:   phiscock@ee.ryerson.ca
> URL:     http://www.ee.ryerson.ca/~phiscock


Article: 47857
Subject: Re: SoC Testing , need links
From: "news" <kduorah@adelphia.net>
Date: Sun, 06 Oct 2002 00:18:58 GMT
Links: << >>  << T >>  << A >>

skillwood <skillwood@hotmail.com> wrote in message
news:anh8fa$e1cg3$1@ID-159866.news.dfncis.de...
> Hi ,
>   anyone have good links for BIST and ATPG .
> thanks
>
>


begin 666 Design-for-Test Technical Papers.url
M6T1%1D%53%1=#0I"05-%55),/6AT=' Z+R]W=W<N;65N=&]R+F-O;2]D9G0O
M='!A<&5R<RYC9FT_=CTR,#4W,S(F<#TW,C8V,#DU)G,]-#,Q.#4T-B9C/61F
M=%]O=F5R='5R95]K97EW;W)D+F=I9@T*#0I;26YT97)N9713:&]R=&-U=%T-
M"E523#UH='1P.B\O=W=W+FUE;G1O<BYC;VTO9&9T+W1P87!E<G,N8V9M/W8]
M,C U-S,R)G ]-S(V-C Y-29S/30S,3@U-#8F8SUD9G1?;W9E<G1U<F5?:V5Y
G=V]R9"YG:68-"DUO9&EF:65D/44P-S4R-D,V0T0V0T,R,#$S1 T*
`
end


Article: 47858
Subject: Xilinx WebPack ISE 5.1.01i XC9500 Implement problems
From: "Tony M" <tonym_98@hotmail.com>
Date: Sun, 06 Oct 2002 01:51:01 GMT
Links: << >>  << T >>  << A >>
Hey all...

In the past I've used ActiveHDL (great product!) But this semester I had a
tighter budget so I'm giving the Xilinx WebPack ISE 5.1i + Service Pack 1 a
try.

I have a XC95108 CPLD next to my Virtex chip and need to download some
simple VHDL to the CPLD... but ISE won't Fit the code...

here's the error I get:
Started process "Fit".

can't read "xcpldFitDesFastConnectUIM": no such variable
    while executing
"if { !$xcpldFitDesFastConnectUIM } {
      lappend Options "-nouim"
   }"
    invoked from within
"if { [string equal $p_DevFamily xc9500] } {
   if { !$xcpldFitDesFastConnectUIM } {
      lappend Options "-nouim"
   }
   switch -- $xcpldFitDesLocal..."
    (file "C:/Xilinx/data/projnav/scripts/_cpldfitrun.tcl" line 95)

Now... I disabled the FastConnect optimization routine in the options and it
still gives that error.  What can I do?  I'm not familiar enough yet with
ISE to figure this out on my own!

Thanks,
Tony



Article: 47859
Subject: FIFO Simulation problem
From: Casey <cjs1977@earthlink.net>
Date: Sat, 5 Oct 2002 18:55:54 -0700
Links: << >>  << T >>  << A >>
Hello, 

 I'm having problems simulating
a design in Foundation 3.1i using
a Synchronous FIFO core. I'm 
receiving an "undetermined input 
pin state" error for a pin name
internal to the CORE. All external
signals are defined.

 I've seen other postings with this
same problem but no solutions in 
the threads. Does anyone have a 
solution/suggestions for this
problem?

              Thanks much,
                    Casey

Article: 47860
Subject: Re: TCP/IP in FPGA
From: hmurray@suespammers.org (Hal Murray)
Date: Sun, 06 Oct 2002 02:29:06 -0000
Links: << >>  << T >>  << A >>
>People has been doing minimal TCP that is only a few pages of C code.
>The thing is why would I want to buy a 500 bucks TCP accelerator when
>the most I could get on my modem is 50 kbits/sec. There is not a market
>for TCP/IP in hardware. Not for the home user anyway.

A "few pages of C" would be very impressive for a TCP stack.
Don't forget the driver and buffer management and ...

Just for calibration, TCP on this Linux box is 6 modules and 11K lines
of code.  (Yes, much of that could be pruned.)



Modern PCs can run TCP benchmarks at line rates on gigabit Ethernet.
Most of the CPU/memory is chewed up copying data to/from user/kernel.

I expect the target is busy web/file servers and things like that rather
than home users.  In that context, $500 to double network performance
would be a great deal.

Might be good for some graphics workloads too - visualization on supercomputers.

As Ray points out for DSP applications, if you can do it in
software running on mainstream hardware that's probably cheaper/better. 


-- 
The suespammers.org mail server is located in California.  So are all my
other mailboxes.  Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's.  I hate spam.


Article: 47861
Subject: Re: ANN: Embedded processor for Tcl language
From: hamish@cloud.net.au
Date: 06 Oct 2002 02:36:03 GMT
Links: << >>  << T >>  << A >>
Utku Ozcan <utku.ozcan@netas.com.tr.nospam> wrote:
>  Very sensible. Modelsim uses a Tcl bytecode virtual machine, like JVM.

Really? Where did you get this information?

I confess that I find Tcl to be one of the most awful languages I have
ever used. IMHO it has no virtue whatsoever.

Hamish
-- 
Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>

Article: 47862
Subject: Re: question on ISE 5.1 and SMP machines...
From: hamish@cloud.net.au
Date: 06 Oct 2002 02:47:24 GMT
Links: << >>  << T >>  << A >>
Dan <hombecker1962@hotmail.com> wrote:
> hamish@cloud.net.au wrote in message news:<3d9adedd$0$30860$afc38c87@news.optusnet.com.au>...
>> By the way, from what I hear, Windows applications can't use more than
>> 2Gb anyway. If your route needs more, it will crash. So 3Gb of RAM might
>> not be worth it, unless you will run other memory-intensive tasks at the
>> same time as PAR.
> 
> Hi I just wanted to say thanks for the advice, and to point out that
> with special hooks you can get windows 2000/XP to use up to 3 gigs of
> RAM but evidently there are some caveats to that, but it can be done
> as the Xilinx manual points that out (at least for 5.1i)

OK that's good news. I heard that there was a special version of NT that
had a 3Gb/1Gb user/kernel split but didn't know about 2000/XP.

It'd also be interesting to know whether running under Wine gets you the
Windows 2Gb/2Gb split or the native Linux 3Gb/1Gb split.


Thanks for the info,

Hamish
-- 
Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>

Article: 47863
Subject: Re: TCP/IP in FPGA
From: hmurray@suespammers.org (Hal Murray)
Date: Sun, 06 Oct 2002 03:06:32 -0000
Links: << >>  << T >>  << A >>
>Actually i am looking a solution which will internet enable 8 or 16 bit
>devices .For applications such as remote sensors which communicate through
>TCP/IP.

What sort of bandwidth and physical link?  Video cameras or temperature?
Ethernet or RS-232?

For something simple like a temperature sensor, I'd use UDP rather
than TCP.  That avoids keeping track of all the TCP state. (and timers)
It pushes some of the work back to the other end, but you probably have
something smart like a PC there.

-- 
The suespammers.org mail server is located in California.  So are all my
other mailboxes.  Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's.  I hate spam.


Article: 47864
Subject: Re: ANN: Embedded processor for Tcl language
From: nweaver@ribbit.CS.Berkeley.EDU (Nicholas C. Weaver)
Date: Sun, 6 Oct 2002 03:31:26 +0000 (UTC)
Links: << >>  << T >>  << A >>
In article <3d9fa193$0$22176$afc38c87@news.optusnet.com.au>,
 <hamish@cloud.net.au> wrote:
>I confess that I find Tcl to be one of the most awful languages I have
>ever used. IMHO it has no virtue whatsoever.

It has one virtue, it drove the development of TK, which is quite
tolerable when used with something like Scheme to make Scheme/Tk.

-- 
Nicholas C. Weaver                                 nweaver@cs.berkeley.edu

Article: 47865
Subject: Re: DDS in PLD?
From: Jim Granville <jim.granville@designtools.co.nz>
Date: Sun, 06 Oct 2002 19:22:12 +1300
Links: << >>  << T >>  << A >>
Peter Hiscocks wrote:
> 
> We're building a function generator that uses a 24 bit Direct Digital
> Synthesis oscillator. It will fit into an FPGA with no problem, but I'd
> really like to shoehorn this thing into a PLD to avoid the need for a boot
> ROM chip and to keep the cost down.
> 
> The Xilinx 9000 series PLD's I've tried won't do because of the requirement
> for a 24 bit adder. Anyone have any suggestions of other chips I should
> investigate for this?
> 
> Thanks for the help -

 The 'biggest CPLD' are tending to cost more than the 'smallest FPGA',
but you could look at Coolrunner 2, and the newest 
wide fanin lattice devices.

 There are also other ways to keep the Loader costs down, such as
using a uC, which could benefit in DDS interface / config as well

-jg

Article: 47866
Subject: Re: ANN: Embedded processor for Tcl language
From: ptkwt@shell1.aracnet.com (Phil Tomson)
Date: 6 Oct 2002 06:23:57 GMT
Links: << >>  << T >>  << A >>
In article <3d9fa193$0$22176$afc38c87@news.optusnet.com.au>,
 <hamish@cloud.net.au> wrote:
>Utku Ozcan <utku.ozcan@netas.com.tr.nospam> wrote:
>>  Very sensible. Modelsim uses a Tcl bytecode virtual machine, like JVM.
>
>Really? Where did you get this information?
>

If you've ever used ModelSim you'll notice that they allow you to script 
simulations with Tcl - which strongly implies that there is a Tcl 
interpreter embedded in ModelSim.  Also, I believe that the ModelSim GUI 
is implemented in Tcl/Tk.

>I confess that I find Tcl to be one of the most awful languages I have
>ever used. IMHO it has no virtue whatsoever.
>

I would tend to agree with you, especially when you compare it to an 
elegant language like Ruby (http://rubycentral.org), for example.  
However, Tcl has been around for a while so there tend to be a lot of 
folks who know it and it's easy to embed Tcl in applications written in 
C/C++.  I suspect that it's the latter reason that Tcl is used in 
ModelSim and several other EDA apps.

There are better languages available now than Tcl (such as Ruby) but it 
might take a while before we start seeing them show up embedded in EDA 
apps.  Also, I suspect that a hardware implementation of Ruby would be a 
lot more difficult to do than this hardware implementation of Tcl given 
the dynamic nature of Ruby (the same could be said for Python too, I 
suppose).


Phil

Article: 47867
Subject: Re: ANN: Embedded processor for Tcl language
From: allan_herriman.hates.spam@agilent.com (Allan Herriman)
Date: Sun, 06 Oct 2002 09:57:28 GMT
Links: << >>  << T >>  << A >>
On 6 Oct 2002 06:23:57 GMT, ptkwt@shell1.aracnet.com (Phil Tomson)
wrote:

>In article <3d9fa193$0$22176$afc38c87@news.optusnet.com.au>,
> <hamish@cloud.net.au> wrote:
>>Utku Ozcan <utku.ozcan@netas.com.tr.nospam> wrote:
>>>  Very sensible. Modelsim uses a Tcl bytecode virtual machine, like JVM.
>>
>>Really? Where did you get this information?
>>
>
>If you've ever used ModelSim you'll notice that they allow you to script 
>simulations with Tcl - which strongly implies that there is a Tcl 
>interpreter embedded in ModelSim.  Also, I believe that the ModelSim GUI 
>is implemented in Tcl/Tk.

>From  http://www.tcl.tk/doc/compiler.html

"Tcl 8.0 introduced an on-the-fly byte-code compiler for Tcl."

I just learned something.  I had always thought that Tcl was purely
interpreted.

Regards,
Allan.

>>I confess that I find Tcl to be one of the most awful languages I have
>>ever used. IMHO it has no virtue whatsoever.
>>
>
>I would tend to agree with you, especially when you compare it to an 
>elegant language like Ruby (http://rubycentral.org), for example.  
>However, Tcl has been around for a while so there tend to be a lot of 
>folks who know it and it's easy to embed Tcl in applications written in 
>C/C++.  I suspect that it's the latter reason that Tcl is used in 
>ModelSim and several other EDA apps.
>
>There are better languages available now than Tcl (such as Ruby) but it 
>might take a while before we start seeing them show up embedded in EDA 
>apps.  Also, I suspect that a hardware implementation of Ruby would be a 
>lot more difficult to do than this hardware implementation of Tcl given 
>the dynamic nature of Ruby (the same could be said for Python too, I 
>suppose).
>
>
>Phil


Article: 47868
Subject: LPT voltage level and Xilinx CPLD programming?
From: "valentin tihomirov" <valentin@abelectron.com>
Date: Sun, 6 Oct 2002 16:54:12 +0300
Links: << >>  << T >>  << A >>
    Hello,
I use Systronix POD for programming Xilinx CPLDs and it works file. But I
can't drive CPLD by myself (I wanted to check JTag in action getting the
IDCODE form CPLD). So, I've written small program in Delphi sending IDCODE
opcode (8 bits) + 32 bits of data shift bits and recorded all signals with
logic analyzer. The CPLD chip responded with the correct ID code.
    The problem is that I can't read response (TDO) from LPT port at PC! All
I get are zeroes. The CPLD drives '1' out as 1.6V and my PC accepts it as
'0'.
    How can iMPACT software read the correct value? The connection is the
same, i.e. TDO is connected to LPT pin13 (select).

Thanks.



Article: 47869
Subject: Re: C\C++ to VHDL Converter
From: "Brett Cline" <brett@ForteDS.com.NOSPAM>
Date: Sun, 06 Oct 2002 14:13:25 GMT
Links: << >>  << T >>  << A >>
Hi Ray,
   Sorry for the delay in my response, I'm traveling a bunch these days.

   Healthy skeptisim is great. I was actually skeptical when I started
working on this technology about 3 years ago.
   Regarding your question on performance. In every case so far, we met or
beat the performance targets for the device. In most cases we will beat area
as well, but not all. The reason is that the compiler will do things (like
share resources) that you simply will not because of the complexity of
trying to manage it.
   I don't advocate using Handle-C. Everything I've seen as well brings it
too close to hardware. For an algorithmic design, I want to leave my
algorithm untouched. And to leave the algorithm untouched you must have, as
someone pointed out, a very sophisticated compiler. We've already done
designs such as image compression, encryption, filters, etc. where we've
been able to create multiple RTL implementations with different
area/performance tradeoffs in a fraction of the time it took to create a
single version of the hardware by hand. And, in most cases, we were able to
get a final end results (area vs. performance) than the customer got by
hand. You'll say the same thing they did: "No Way!" -- that's ok, it's up to
us to prove it.

   This is simply a progression in hardware design much as a C compiler was
a progression beyond assembly in software. Yes, there will always cases
where the HDL has to be so compact to meet the goals that you must write low
level verilog (or even gates). As president of your company, I'm sure you
would agree for certain applications, the value of time to market
dramatically overshadows most other costs in the process. Clearly the design
must meet timing - clearly it must be in some tolerance of area -- but if
you can save 3,6, or more months to market -- what is the savings (or gain)
there?

   For the "Show Me" part, let's talk about that - the proof is in real
results.

Thanks for the spirited discussion -
Brett


"Ray Andraka" <ray@andraka.com> wrote in message
news:3D9A76DD.453A4B46@andraka.com...
>
>
> Brett Cline wrote:
>
> > Hi All-
> >
> >    Synthesis from a C/C++ algorithm is absolutely possible and has been
in
> > use for some time. Even "plain vanilla C" algorithms can be used with
the
> > right synthesis product.
>
> Show me.  Nothing I've seen can handle C code that was not specifically
written
> to create hardware.  I think your next sentence probably validates that as
> well.  Plain vanilla C has nothing in it to support concurrency, and I
know of
> no product that can infer that concurrency from existing (not written
> specifically to map to hardware, usually using special extensions) code.
>
>
> > Obviously it does take some amount of hardware
> > knowledge to get reasonable hardware out the backend. All that should be
> > required is to add the hardware interface structure to the C/C++
algorithm.
> > For that we recommend using SystemC (there is a reference implementation
> > available under an open source license at www.SystemC.org). SystemC
provides
> > the necessary abstraction in C++ to add concurrency, bit accuracy, and
other
> > hardware-isms to the C/C++ algorithm.
> >
> >   To take the algorithm to hardware (RTL Verilog or VHDL) my company
offers
> > a product called "Cynthesizer" for high-level synthesis from SystemC.
We've
> > had a number of customers take generic algorithms (some even from the
web)
> > such as filters, encryption, multimedia, etc. and convert them directly
to
> > RTL Verilog and VHDL. The resulting RTL can be put into any FPGA or ASIC
> > synthesis tool as well as any other tool that operates on RTL.
>
> But at what price?  Is the performance and density reasonably close to a
what a
> skilled hardware designer can accomplish?
>
> >
> >
> > For more information check out our web site at www.ForteDS.com or feel
free
> > to email me directly.
> >
> > Best regards,
> > Brett
> >
> > "Ray Andraka" <ray@andraka.com> wrote in message
> > news:3D894809.ECF33E30@andraka.com...
> > > Not exactly.  There are several vendors that have  C to hardware
> > compilers,
> > > but don't expect to take plain vanilla C and compile it directly to
> > hardware.
> > > For the most part, these tools use subsets and extensions to C to
permit
> > > description of hardware and all the parallelism that implies in a
C-like
> > > environment.  It raises the level of abstraction, and as a result you
tend
> > to
> > > get a design that is more bloated and slower than one done closer to
the
> > > hardware.  The point is that there is no free lunch, there is a
> > considerable
> > > engineering effort to convert your software to something that will run
at
> > a
> > > reasonable speed in an FPGA that you can afford to buy.
> > >
> > > mike wrote:
> > >
> > > > I can't claim to be an expert, but what I think you want to do isn't
> > > > going to work.  You can't take any arbitrary C/C++ program and
convert
> > it
> > > > into VHDL code that will run on an FPGA.  For making something like
a
> > > > hardware mp3 player, you may want to look at something like a
> > > > programmable DSP board.  Also, you should check on what, if any,
analog
> > > > outputs are avilable from the FPGA you're using.  For example, on
the
> > > > Altera student board, the only analog output is for a VGA monitor,
so if
> > > > you wanted to make an mp3 player using one you'd need to build an
> > > > interface to convert the decoded digital audio into analog audio.
> > > > Mike
> > > >
> > > > On Tue, 17 Sep 2002 09:27:21 +0000, DJohn wrote:
> > > >
> > > > > Hi all VHDL experts,
> > > > >   Is there any tools which can convert a C\C++ source file to VHDL
.
> > For
> > > > > example If I have a C source code for a MP3 decoder , Can any tool
can
> > > > > convert it into VHDL equivalent. There is some facility in FPGA
> > > > > Advantage to generate a wrapper VHDL for a  C File , what exactly
is
> > > > > that ? Does that mean I can synthesize a C\C++ file by creating a
VHDL
> > > > > Wrapper. Please help
> > >
> > > --
> > > --Ray Andraka, P.E.
> > > President, the Andraka Consulting Group, Inc.
> > > 401/884-7930     Fax 401/884-7950
> > > email ray@andraka.com
> > > http://www.andraka.com
> > >
> > >  "They that give up essential liberty to obtain a little
> > >   temporary safety deserve neither liberty nor safety."
> > >                                           -Benjamin Franklin, 1759
> > >
> > >
>
> --
> --Ray Andraka, P.E.
> President, the Andraka Consulting Group, Inc.
> 401/884-7930     Fax 401/884-7950
> email ray@andraka.com
> http://www.andraka.com
>
>  "They that give up essential liberty to obtain a little
>   temporary safety deserve neither liberty nor safety."
>                                           -Benjamin Franklin, 1759
>
>



Article: 47870
Subject: Re: ANN: Embedded processor for Tcl language
From: hamish@cloud.net.au
Date: 06 Oct 2002 14:16:03 GMT
Links: << >>  << T >>  << A >>
Phil Tomson <ptkwt@shell1.aracnet.com> wrote:
> In article <3d9fa193$0$22176$afc38c87@news.optusnet.com.au>,
> <hamish@cloud.net.au> wrote:
>>Utku Ozcan <utku.ozcan@netas.com.tr.nospam> wrote:
>>>  Very sensible. Modelsim uses a Tcl bytecode virtual machine, like JVM.
>>Really? Where did you get this information?
> 
> If you've ever used ModelSim you'll notice that they allow you to script 
> simulations with Tcl - which strongly implies that there is a Tcl 
> interpreter embedded in ModelSim.  Also, I believe that the ModelSim GUI 
> is implemented in Tcl/Tk.

I'm aware that it has a Tcl interpreter, but haven't seen any evidence
that there's any compilation going on. It's pretty obvious that plain
old tclsh doesn't do any compilation, because if you change the source
file on disk while you're running it it gets confused!

ModelSim SE allows you to use Tk in user Tcl scripts, but PE doesn't.

> However, Tcl has been around for a while so there tend to be a lot of 
> folks who know it and it's easy to embed Tcl in applications written in 
> C/C++.  I suspect that it's the latter reason that Tcl is used in 
> ModelSim and several other EDA apps.

I'm quite a fan of Perl. IMHO every VHDL or Verilog developer could
benefit from a basic knowledge of Perl and particularly its regular
expressions. And Tcl as well, because so many of the tools have
integrated Tcl (ModelSim, Synplify, ...)

It might be that Perl wouldn't make a very good interactive shell
though. Perl certainly has its share of haters, most of whom are Python
users now I think.


Cheers,
Hamish
-- 
Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>

Article: 47871
Subject: Re: ANN: Embedded processor for Tcl language
From: hamish@cloud.net.au
Date: 06 Oct 2002 14:18:35 GMT
Links: << >>  << T >>  << A >>
Allan Herriman <allan_herriman.hates.spam@agilent.com> wrote:
> From  http://www.tcl.tk/doc/compiler.html
> "Tcl 8.0 introduced an on-the-fly byte-code compiler for Tcl."

"On-the-fly" doesn't seem to be an advantage. Tcl still can't detect 
even basic syntax errors in advance. I can just imagine writing a Tcl
script that collects samples for a week, then bombs out with a syntax
error just before writing the report.

Admittedly Perl doesn't detect missing subroutines in advance, but it
does detect syntax errors.

Hamish
-- 
Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>

Article: 47872
Subject: Re: LPT voltage level and Xilinx CPLD programming?
From: "valentin tihomirov" <valentin@abelectron.com>
Date: Sun, 6 Oct 2002 17:32:48 +0300
Links: << >>  << T >>  << A >>
I've realized one interesting thing, the iMPACT sw forces TDO at POD to be
5V (logic '1'), while my sequence (reset + IDCODE) forces TDO to 2V (logic
'1') and LPT can't recognize it as '1'. What's a secret of output voltage?
The logic analyzer I've buid is low speed and I can't record the sequence
sent by iMPACT.
I suppose I need to control some more signals than just TDI, TCK and TMS
from PC. There is neened something to enable CPLD->TDO->PC data stream. I
guess that Xilinx has inilially a mode driving TDO from PC to chenk cable
presence and then enables tdo from device.

Thanks for any advice.




Article: 47873
Subject: Re: Moving average filter
From: "Blackie Beard" <BlackBeard@FearlessImmortalWretch.com>
Date: Sun, 06 Oct 2002 17:02:12 GMT
Links: << >>  << T >>  << A >>
I like to think of it like this:

out <= (in * (x/8)) + (out * ((8-x)/8))

Where the proportions of the new in, and the old out,
both sum to one whole new out.  In this example,
using 8 as an arbitrary but good power of 2 to reduce
how many variables we are looking at, We see that
the out will eventually settle to the correct solid state.
The smaller x is, the higher the dampening factor.  It
would not be difficult to quickly verify this with a step
response in Excel, trying values 1,2,3 for x.  Just use
a couple of zero rows to prime the output column, then
copy this formula down the page,
=(((B3)*((8-($C$1))/8))+((A3)*($C$1)/8))
Where column A has the step response data, column
B has the output column, and cell C1 has x.  Put a
1, 2 or 3 there), then insert a line chart.

BB
=========================================

>
> Another way to express this is
>
>    out = out + (in-out)/n
>

> >
> >Formula is:
> >  new-avg = old-avg*(1-w) + sample*w
> >Where w is less than 1.
> >
> >Values of w like 1/8 are typically used in networking code to
> >"average" out round trip time measurements.
> >




Article: 47874
Subject: Re: C\C++ to VHDL Converter
From: Phil Hays <SpamPostmaster@attbi.com>
Date: Sun, 06 Oct 2002 18:18:14 GMT
Links: << >>  << T >>  << A >>
Brett Cline wrote:

>    Regarding your question on performance. In every case so far, we met or
> beat the performance targets for the device. In most cases we will beat area
> as well, but not all. The reason is that the compiler will do things (like
> share resources) that you simply will not because of the complexity of
> trying to manage it.

<Set cynical>
Meeting performance targets is easy if you pick low enough performance
targets.  
<End cynical>

Designs for high clock speeds usually can't do much resource sharing: 
routing and muxing of signals kills the performance.  Usually the
reverse is needed.  I often find I need to duplicate resources to meet
performance.  That is, I'll make two copies of a group of logic so as to
reduce the routing delays.  As you seem to be selling Forte, does it
make duplicate copies of logic based on the floorplan it creates?  Can
it make duplicate copies if told to?  Oh, wait, I should ask this first:
does Forte make or use a floorplan?  If it doesn't, then how do you
expect to match the speed of a design with a floorplan?  Floorplans
often reduce the clock cycle time of a design by 30%.  So maybe I
shouldn't expect a Forte based design to match the speed of a well
crafted VHDL design?


>    I don't advocate using Handle-C.

Perhaps you mean Handel-C?


<Assume Handel-C is subject> 
> Everything I've seen as well brings it
> too close to hardware. For an algorithmic design, I want to leave my
> algorithm untouched.

Handel-C is a somewhat higher level language than VHDL, however it is
closer to the hardware than SystemC.  And that is both a good thing, as
you can build what you want, and a bad thing.  I've been thinking about
using Handel-C for the next design as it seemed to me to be getting
close enough to a reasonable tool to be worth using.  Not for the whole
design, just of a part that is both complex and should be fairly easy to
meet timing even if the tool doesn't do the best job.


-- 
Phil Hays



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

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

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

Custom Search