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 70125

Article: 70125
Subject: where is ISE 6.2 SP#3 ?
From: qlyus@yahoo.com (qlyus)
Date: 3 Jun 2004 15:21:10 -0700
Links: << >>  << T >>  << A >>
It is said "6.2i SP3 is scheduled for release June 2, 2004." 

http://support.xilinx.com/support/software/install_info.htm

I want to see if the multi-pass PAR crashes in 6.2i is fixed.

-qlyus

Article: 70126
Subject: Re: tri-state in altera and xilinx
From: Eric Crabill <eric.crabill@xilinx.com>
Date: Thu, 03 Jun 2004 15:28:58 -0700
Links: << >>  << T >>  << A >>

Hi,

> I always thought the internal tri-state bus in Xilinx
> was an advantage over Altera's devices.  I started to
> use this feature in 4k series, in which the save of
> gates in this low density was more obvious when building
> a bus with 10+ registers.

In devices where you are constrained by the number of LUTs,
and not performance, TBUFs are great.  And you can still
code with TBUFs if you want, because the synthesis and
mapping tools can automatically transform those into some
other (logically equivalent) representation.

> With Xilinx abandon of tri-state and Altera not doing it
> from the beginning, i am confused with who was smarter.

I am sure there are at least two answers to this question.

> If Xilinx gets rid of its unique features (such as SRL
> and tri-state) more and more, or Altera offers more
> features which used to be unique in Xilinx (Stratix-II
> started to offer 100+ multiplier), I have to ask why
> using Xilinx devices anymore?

Flame on, dude!
Eric

Article: 70127
Subject: Re: tri-state in altera
From: Jeff Cunningham <jcc@sover.net>
Date: Thu, 03 Jun 2004 22:46:13 GMT
Links: << >>  << T >>  << A >>
Austin Lesea wrote:

> The tristate buffers in Virtex and all subsequent families are in fact 
> separate bidirectional logic structures that simulate the behavior of a 
> tristate bus.

hmm.. I guess that means when using tri-states these days I don't need 
to worry about heating up a part by turning on multiple drivers fighting 
on a bus. It is simply a matter of data corruption?

Jeff


Article: 70128
Subject: Re: tri-state in altera and xilinx
From: Austin Lesea <austin@xilinx.com>
Date: Thu, 03 Jun 2004 16:09:38 -0700
Links: << >>  << T >>  << A >>
Jeff,

Yes.  No possibility of contention and a "X" value (unknown).  In fact 
that was a real challenge to simulate a "X" condition so that a user 
felt better.  Calling it a 0 or a 1 (which is what really results) and 
not even having a "z" condition (tri-state) made a few quite 
uncomfortable when simulating.  We had to emulate the tristate behavior 
in simulation runs.....yuch!

As to who did the "right" thing, Altera recognized early on that 
tristate muxes were hogs, and were slow, and didn't addict an entire 
generation to them with a successful product line that had them, whereas 
Xilinx has had to wean folks off of using them (in effect, break a bad 
habit) because we had a large number of users who used them, and liked 
them but they were inefficient and slower than using logic already there.

The perception of being efficient or not is an interesting one:  if we 
had dedicated more area to logic and less to tristate ciruits, which is 
more efficient?  Just another reason why you can argue just about any 
angle of FPGA architecture as being "good", or "bad".

Definitely a "glass half empty or glass half full" problem.  Not a whole 
lot to get excited about.

At the level most people design at now (VHDL or verilog) instantiating a 
tristate structure will be automatically get mapped to logic anyway (if 
you let it) or give you an error message (if you do not allow it and the 
target has no tristate blocks).

Austin

Jeff Cunningham wrote:
> Austin Lesea wrote:
> 
>> The tristate buffers in Virtex and all subsequent families are in fact 
>> separate bidirectional logic structures that simulate the behavior of 
>> a tristate bus.
> 
> 
> hmm.. I guess that means when using tri-states these days I don't need 
> to worry about heating up a part by turning on multiple drivers fighting 
> on a bus. It is simply a matter of data corruption?
> 
> Jeff
> 

Article: 70129
Subject: PAR runtime error
From: "Chris Cheung" <chris_cheung66@hotmail.com>
Date: Thu, 03 Jun 2004 23:32:24 GMT
Links: << >>  << T >>  << A >>
hi,

    I got this error frequently with I run Multi place and route in ISE6.2:



    DeleteInterpProc called with active evals

    This application has requested the Runtime to terminate it in an unusual
way
    Please contact the application's support team for more information.
    ERROR: par failed
    Reason:
    Process "Multi Pass Place & Route" did not complete.


    Any solution to this problem?

    Thanks

    Chris



Article: 70130
Subject: Re: tri-state in altera
From: Marc Randolph <mrand@my-deja.com>
Date: Thu, 03 Jun 2004 21:36:12 -0500
Links: << >>  << T >>  << A >>
Symon wrote:
 > "qlyus" <qlyus@yahoo.com> wrote in message
 > news:da71446f.0406031036.137fd0db@posting.google.com...
 >
 >>Is Spartan 3 still faster and less expensive when there are 100+
 >>16/32-bit registers on a bus?
 >>
 >>-qlyus
 >>
 >>
> That's hardly a typical application. 

Perhaps we aren't typical, but we have done quite a few FPGA's that had
over 100 separate 16 bit (or more) control or status registers.  We try
to use BRAM's for stuff like this when it makes sense to, but most just
end up out in the sea of gates.

    Marc

Article: 70131
Subject: Re: tri-state in altera and xilinx
From: "Jan Gray" <jsgray@acm.org>
Date: Fri, 04 Jun 2004 02:42:03 GMT
Links: << >>  << T >>  << A >>
When you're trying to squeeze a pipelined RISC processor into a small tile
(say 4Rx6C of CLBs + 1 BRAM), (because you intend to tile dozens or hundreds
of processors per FPGA), and your result bus needs to mux amongst 4+
sources, and you have to burn several LUTs/bit just for lousy *muxes*, fer
gosh sakes, THEN you will shed a nostalgic tear for TBUFs passed (or other
non-LUT resources for wide horizontal muxes).

The xr16 profitably used a TBUF for every LUT site in the datapath.
[http://www.fpgacpu.org/xsoc/cc.html]

The loss isn't so bad once you learn the trick to implement
  o = a + b ? c;
or even
  o = mux(sel1, sel2){a + b, a - b, a & b, a ^ b};
in one LUT per bit. [http://www.fpgacpu.org/log/nov00.html#001112]

Jan Gray
Gray Research LLC



Article: 70132
Subject: Re: tri-state in altera and xilinx
From: "Jan Gray" <jsgray@acm.org>
Date: Fri, 04 Jun 2004 02:44:44 GMT
Links: << >>  << T >>  << A >>
I wrote:
>   o = a + b ? c;

Oops.  I meant:
  o = sel ? (a + b) : c;

Jan.



Article: 70133
Subject: Re: USB OTG high speed
From: javaguy11111@yahoo.com (db)
Date: 3 Jun 2004 19:52:52 -0700
Links: << >>  << T >>  << A >>
You might want to look at the ISP1761 at Philips. They have a page up
for it, but I am not sure if it is available.
http://www.semiconductors.philips.com/buses/usb/products/otg/isp1761/


rickman <spamgoeshere4@yahoo.com> wrote in message news:<40BF9374.B3B5A244@yahoo.com>...
> I see where Atmel has announced a USB OTG full speed controller chip. 
> It looks interesting.  But I would prefer a high speed device.  Anyone
> know of such a chip?  Or I can use a core if it is not too large.  So
> far I have not found anything that will implement OTG and high speed.  
> 
> -- 
> 
> 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

Article: 70134
Subject: Re: where is ISE 6.2 SP#3 ?
From: "Peng Cong" <pc_dragon@sohu.com>
Date: Fri, 4 Jun 2004 14:43:28 +0800
Links: << >>  << T >>  << A >>
Now the web page said 6.2i SP3 is scheduled for release June 9, 2004

"qlyus" <qlyus@yahoo.com> дʼ
news:da71446f.0406031421.7181250@posting.google.com...
> It is said "6.2i SP3 is scheduled for release June 2, 2004."
>
> http://support.xilinx.com/support/software/install_info.htm
>
> I want to see if the multi-pass PAR crashes in 6.2i is fixed.
>
> -qlyus






Article: 70135
Subject: Re: tri-state in altera and xilinx
From: Ray Andraka <ray@andraka.com>
Date: Fri, 04 Jun 2004 08:15:10 -0400
Links: << >>  << T >>  << A >>
Jan,

Also, if you put one block Ram per processor, you get an area of at least 8x20
CLBs for each block RAM.  I don't miss the TBUFs as much as I thought I
would...most of the time.

Jan Gray wrote:

> When you're trying to squeeze a pipelined RISC processor into a small tile
> (say 4Rx6C of CLBs + 1 BRAM), (because you intend to tile dozens or hundreds
> of processors per FPGA), and your result bus needs to mux amongst 4+
> sources, and you have to burn several LUTs/bit just for lousy *muxes*, fer
> gosh sakes, THEN you will shed a nostalgic tear for TBUFs passed (or other
> non-LUT resources for wide horizontal muxes).
>
> The xr16 profitably used a TBUF for every LUT site in the datapath.
> [http://www.fpgacpu.org/xsoc/cc.html]
>
> The loss isn't so bad once you learn the trick to implement
>   o = a + b ? c;
> or even
>   o = mux(sel1, sel2){a + b, a - b, a & b, a ^ b};
> in one LUT per bit. [http://www.fpgacpu.org/log/nov00.html#001112]
>
> Jan Gray
> Gray Research LLC

--
--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: 70136
Subject: Re: tri-state in altera and xilinx
From: Ray Andraka <ray@andraka.com>
Date: Fri, 04 Jun 2004 08:17:44 -0400
Links: << >>  << T >>  << A >>
Oh yeah, one other trick that sometimes helps.  If yor resets are available on
flip-flops leading into a 4:1 mux, you can use the resets as a select so that the
mux reduces to a 4 input OR.  Sometimes works for pipelined stuff, but probably
not good for your processor.

Ray Andraka wrote:

> Jan,
>
> Also, if you put one block Ram per processor, you get an area of at least 8x20
> CLBs for each block RAM.  I don't miss the TBUFs as much as I thought I
> would...most of the time.
>
> Jan Gray wrote:
>
> > When you're trying to squeeze a pipelined RISC processor into a small tile
> > (say 4Rx6C of CLBs + 1 BRAM), (because you intend to tile dozens or hundreds
> > of processors per FPGA), and your result bus needs to mux amongst 4+
> > sources, and you have to burn several LUTs/bit just for lousy *muxes*, fer
> > gosh sakes, THEN you will shed a nostalgic tear for TBUFs passed (or other
> > non-LUT resources for wide horizontal muxes).
> >
> > The xr16 profitably used a TBUF for every LUT site in the datapath.
> > [http://www.fpgacpu.org/xsoc/cc.html]
> >
> > The loss isn't so bad once you learn the trick to implement
> >   o = a + b ? c;
> > or even
> >   o = mux(sel1, sel2){a + b, a - b, a & b, a ^ b};
> > in one LUT per bit. [http://www.fpgacpu.org/log/nov00.html#001112]
> >
> > Jan Gray
> > Gray Research LLC
>
> --
> --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: 70137
Subject: IDE/ATA _device_ core availablility
From: "Holger Baxmann" <holger@bitwind.org>
Date: Fri, 4 Jun 2004 16:05:10 +0200
Links: << >>  << T >>  << A >>
Hi all,

does anybody know, where, a possibly free, IP core of an IDE _device_
exists?

Reason: connecting a FPGA to an [PC] the standard USB-to-IDE or direct IDE
interface way.

Thanks a lot

bax



Article: 70138
Subject: Re: tri-state in altera and xilinx
From: "Jan Gray" <jsgray@acm.org>
Date: Fri, 04 Jun 2004 14:54:17 GMT
Links: << >>  << T >>  << A >>
"Ray Andraka" <ray@andraka.com> wrote in message
news:40C067CE.C332F829@andraka.com...
> Also, if you put one block Ram per processor, you get an area of at least
8x20
> CLBs for each block RAM.  I don't miss the TBUFs as much as I thought I
> would...most of the time.

Ray, there are (not uncoincidentally) 4Rx6C of CLB / BRAM+mult in Virtex-II
Pro devices, yes?  And up to 444 BRAMs per device? :-)

Also, for good old XCV600E, (NB half as many slices per CLB), I used 8Rx6C
per processor, floorplanning 60 16-bit CPU + BRAM tiles or 36 32-bit CPUs +
2 BRAM tiles. [http://www.fpgacpu.org/log/mar02.html#020302]

TBUFs R.I.P.

Jan Gray
Gray Research LLC



Article: 70139
Subject: Re: tri-state in altera and xilinx
From: hmurray@suespammers.org (Hal Murray)
Date: Fri, 04 Jun 2004 11:37:20 -0500
Links: << >>  << T >>  << A >>
>Also, if you put one block Ram per processor, you get an area of at least 8x20
>CLBs for each block RAM.  I don't miss the TBUFs as much as I thought I
>would...most of the time.

One interesting aspect of the TBUFs is that they went onto long lines,
which were, well, long.  That helped simplify floor planning.

Assume that I have a design in mind where I would have used TBUFs.
Is there some layout pattern that works well after I switch to
using MUXes?  Do I just toss it on the chip in some sensible
looking way and assume the routing will be good enough?  What if
I'm pushing the speed or density envelope?

I guess I'm slightly surprised that some quirky feature hasn't
evolved to replace that nitch - something like a 2:1 mux or 2 input
OR tied to special routing.  (with a pitch to match an adder
using the dedicated carry logic)  Maybe the routing is just good
enough for the old type of design and newer chips are big enough
so that the typical design is a different sort of project.

-- 
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: 70140
Subject: Re: tri-state in altera and xilinx
From: rickman <spamgoeshere4@yahoo.com>
Date: Fri, 04 Jun 2004 12:58:15 -0400
Links: << >>  << T >>  << A >>
Hal Murray wrote:
> 
> >Also, if you put one block Ram per processor, you get an area of at least 8x20
> >CLBs for each block RAM.  I don't miss the TBUFs as much as I thought I
> >would...most of the time.
> 
> One interesting aspect of the TBUFs is that they went onto long lines,
> which were, well, long.  That helped simplify floor planning.
> 
> Assume that I have a design in mind where I would have used TBUFs.
> Is there some layout pattern that works well after I switch to
> using MUXes?  Do I just toss it on the chip in some sensible
> looking way and assume the routing will be good enough?  What if
> I'm pushing the speed or density envelope?
> 
> I guess I'm slightly surprised that some quirky feature hasn't
> evolved to replace that nitch - something like a 2:1 mux or 2 input
> OR tied to special routing.  (with a pitch to match an adder
> using the dedicated carry logic)  Maybe the routing is just good
> enough for the old type of design and newer chips are big enough
> so that the typical design is a different sort of project.

Keep in mind that the newer Xilinx chips have a MUXF6 which allow up to
8 input muxes to be made with a single level of delay.  That compares
well with the 16 input mux you can make from an Altera LAB.  Routing is
an issue, but the speed of the tbufs driving long lines make them pretty
impractical for the newer chips running at high speeds.  If you don't
need speed, you can use a single wire with a serial bus to reduce the
amount of logic and routing used.  What the newer chips provide is speed
and lots of it.  That can do a lot to reduce the size of a design.  

-- 

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

Article: 70141
Subject: Re: tri-state in altera and xilinx
From: Ray Andraka <ray@andraka.com>
Date: Fri, 04 Jun 2004 14:19:23 -0400
Links: << >>  << T >>  << A >>
The MuxF5's and MUXF6's have the wrong pitch to match up to arithmetic, which makes
them a pain in the tail to use on heavily arithmetic designs.   The mux pitch has
been a consistent complaint about the Virtex architecture.  Routingto them, as you
point out, is also an issue.

rickman wrote:

>
> Keep in mind that the newer Xilinx chips have a MUXF6 which allow up to
> 8 input muxes to be made with a single level of delay.  That compares
> well with the 16 input mux you can make from an Altera LAB.  Routing is
> an issue, but the speed of the tbufs driving long lines make them pretty
> impractical for the newer chips running at high speeds.  If you don't
> need speed, you can use a single wire with a serial bus to reduce the
> amount of logic and routing used.  What the newer chips provide is speed
> and lots of it.  That can do a lot to reduce the size of a design.
>
> --
>
> 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

 "They that give up essential liberty to obtain a little
  temporary safety deserve neither liberty nor safety."
                                          -Benjamin Franklin, 1759



Article: 70142
Subject: Re: tri-state in altera and xilinx
From: Ray Andraka <ray@andraka.com>
Date: Fri, 04 Jun 2004 14:20:48 -0400
Links: << >>  << T >>  << A >>
Jan,

Of course!  I was thinking in terms of V2 not V2P.  Don't get to use the latter
as much as the former because of the nature of the clients I've been dealing
with (several space and military projects).

Jan Gray wrote:

> "Ray Andraka" <ray@andraka.com> wrote in message
> news:40C067CE.C332F829@andraka.com...
> > Also, if you put one block Ram per processor, you get an area of at least
> 8x20
> > CLBs for each block RAM.  I don't miss the TBUFs as much as I thought I
> > would...most of the time.
>
> Ray, there are (not uncoincidentally) 4Rx6C of CLB / BRAM+mult in Virtex-II
> Pro devices, yes?  And up to 444 BRAMs per device? :-)
>
> Also, for good old XCV600E, (NB half as many slices per CLB), I used 8Rx6C
> per processor, floorplanning 60 16-bit CPU + BRAM tiles or 36 32-bit CPUs +
> 2 BRAM tiles. [http://www.fpgacpu.org/log/mar02.html#020302]
>
> TBUFs R.I.P.
>
> Jan Gray
> Gray Research LLC

--
--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: 70143
Subject: Re: VHDL test bench in Quartus
From: rrr@ieee.org (Rajeev)
Date: 4 Jun 2004 13:13:50 -0700
Links: << >>  << T >>  << A >>
rickman <spamgoeshere4@yahoo.com> wrote in message news:<40BF8B40.A64DB0AF@yahoo.com>...
> There is something missing in this discussion.  If you are talking about
> testbenches, then Quartus can't help you since testbenches are used in
> simulations and Quartus is not a VHDL simulator.  
> 
> I agree that using waveforms to simulate FPGA designs is not desirable. 

I'd love to hear why.

<...>

Regards,
-rajeev-

Article: 70144
Subject: Re: VHDL test bench in Quartus
From: rickman <spamgoeshere4@yahoo.com>
Date: Fri, 04 Jun 2004 16:45:20 -0400
Links: << >>  << T >>  << A >>
Rajeev wrote:
> 
> rickman <spamgoeshere4@yahoo.com> wrote in message news:<40BF8B40.A64DB0AF@yahoo.com>...
> > There is something missing in this discussion.  If you are talking about
> > testbenches, then Quartus can't help you since testbenches are used in
> > simulations and Quartus is not a VHDL simulator.
> >
> > I agree that using waveforms to simulate FPGA designs is not desirable.
> 
> I'd love to hear why.

A test bench is not just a static waveform generator, it can be an
interactive environment simulator.  I can write code to model an
external memory or MCU bus cycles or any other interface.  As my design
progresses it can take a lot less work to keep a testbench up to date
than it would to redo waveforms.  

Maybe it is just a personal preference, but I find a VHDL testbench to
be the best way of testing a design I have found.  

-- 

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

Article: 70145
Subject: Book on SPARK: parallelizing high-level synthesis tool
From: sumitg@gmail.com (Sumit Gupta)
Date: 4 Jun 2004 15:15:26 -0700
Links: << >>  << T >>  << A >>
Hi all

A book that describes the parallelizing high-level synthesis
methodology used in the SPARK synthesis framework is available now
from Kluwer:

SPARK: A Parallelizing Approach to the High-Level Synthesis of Digital
Circuits
S. Gupta, R.K. Gupta, N.D. Dutt, A. Nicolau,

This book can be ordered directly from Kluwer or from Amazon (it
should be available on Amazon in a few days).  Links are at:
http://mesl.ucsd.edu/spark/publications.shtml
Please also note that the SPARK website has moved to :
http://mesl.ucsd.edu/spark

Kluwer will be showcasing and taking orders for the book at DAC as
well.

The publisher's description of the book is:

Rapid advances in microelectronic integration and the advent of
Systems-on-Chip have fueled the need for high-level synthesis, i.e.,
an automated approach to the synthesis of hardware from behavioral
descriptions.

SPARK: A Parallelizing Approach to the High - Level Synthesis of
Digital Circuits presents a novel approach to the high-level synthesis
of digital circuits -- that of parallelizing high-level synthesis
(PHLS). This approach uses aggressive code parallelizing and code
motion techniques to discover circuit optimization opportunities
beyond what is possible with traditional high-level synthesis. This
PHLS approach addresses the problems of the poor quality of synthesis
results and the lack of controllability over the transformations
applied during the high-level synthesis of system descriptions with
complex control flows, that is, with nested conditionals and loops.

Also described are speculative code motion techniques and dynamic
compiler transformations that optimize the circuit quality in terms of
cycle time, circuit size and interconnect costs. We describe the SPARK
parallelizing high-level synthesis framework in which we have
implemented these techniques and demonstrate the utility of SPARK's
PHLS approach using designs derived from  multimedia and image
processing applications. We also present a case study of an
instruction length decoder derived from the Intel Pentium-class of
microprocessors. This case study serves as an example of a typical
microprocessor functional block with complex control flow and
demonstrates how our techniques are useful for such designs.

SPARK: A Parallelizing Approach to the High - Level Synthesis of
Digital Circuits is targeted mainly to embedded system designers and
researchers. This includes people working on design and design
automation. The book is useful for researchers and design automation
engineers who wish to understand how the main problems hindering the
adoption of high-level synthesis among designers.

Regards
Sumit

Article: 70146
Subject: Re: how to random generate packet for Ethernet MAC(802.3) with verilog in testbench ?
From: wpiman@aol.com (MS)
Date: 4 Jun 2004 15:18:55 -0700
Links: << >>  << T >>  << A >>
VERA

sanpab@eis.uva.es wrote in message news:<d79abcea.0406021112.7177d516@posting.google.com>...
> You may use a LFSR register. See it at
> 
> http://www.xilinx.com/bvdocs/appnotes/xapp052.pdf
> 
> Cheers.

Article: 70147
Subject: Re: IDE/ATA _device_ core availablility
From: Dave Vanden Bout <devb@xess.com>
Date: Sat, 05 Jun 2004 04:59:42 GMT
Links: << >>  << T >>  << A >>
"Holger Baxmann" <holger@bitwind.org> wrote in
news:c9pvir$4k6$1@newsreader2.netcologne.de: 

> Hi all,
> 
> does anybody know, where, a possibly free, IP core of an IDE _device_
> exists?
> 
> Reason: connecting a FPGA to an [PC] the standard USB-to-IDE or direct
> IDE interface way.

I've never seen the VHDL for a device-side IDE interface, but it 
shouldn't be too hard to do at least a PIO-mode interface.  All you need 
to do is respond to reads and writes to two banks of eight registers each 
and generate the appropriate actions (maybe just read and write sector 
commands).  I recommend looking at an early version of the ATA spec 
(before they got to several hundred pages) to see how the interface 
works.  The one I've used is "ATA Interface Reference Manual" published 
by Seagate back in 1993 (stored at 
http://www1.vobis.de/bbs/firmen/seagate/manual/atarevc.pdf)

Once you get a design roughed out, you could combine it in an FPGA or 
simulator with the IDE interface core we have at www.xess.com.  That 
would show you if your device-side interface is alive before subjecting 
it to a real-world command stream from a PC IDE port. 

 
----------------------------------------------------------------
Dr. Dave Van den Bout
XESS Corp.
PO Box 33091
Raleigh NC 27636
Phn: (919) 363-4695
Fax: (801) 749-6501
devb@xess.com
http://www.xess.com


Article: 70148
Subject: Re: NIOS 2 memory limitations
From: seannstifler69@hotmail.com (Stifler)
Date: 5 Jun 2004 00:09:12 -0700
Links: << >>  << T >>  << A >>
My guess is that this is the first of many undocumented features for
the upgrade to Nios II. Make sure and back up your previous project.
They even say that in the app note. Be careful.


kempaj@yahoo.com (Jesse Kempa) wrote in message news:<95776079.0406011652.6925b9d@posting.google.com>...
> > > You can choose whether the memory banks are connected to the instruction
> > > master and/or the data master.  It sounds like there is a limitation in the
> > > Nios II regarding the width of instruction addresses (probably so that an
> > > absolute call or jump can fit within a single instruction), but that should
> > > not affect the data access (presumably this range is mostly data?).
> > > Deselect the instruction master connection from the data banks, and see if
> > > that helps.
> > 
> > 
> > Do you know how to do that.  I added a 2nd TriState Bus and connected
> > that to the CPU Data Master Bus.  The 1st TriSatate bus is connected
> > to the CPU Instruction Master Bus.
> > 
> > Is this the best (correct) way??
> > 
> > Thanks
> > George
> 
> Hi George,
> 
> A colleague replied to your inquiry over on the Nios forum website.
> However just to clarify the above: Each tri-state master will generate
> a new tri-state bus coming out of your SOPC Builder system. Depending
> on how your board is designed this probably isn't what you want (you
> probably should keep the bus setup similar, if not identical, to your
> Nios I system).
> 
> As alluded to above, the limitation is in fact in place so that a Nios
> II call instruction will always fall within a 'legal' range (256MBytes
> of address space). So for your system I would recommend the following:
> 1. Tie the Nios II CPU instruction master only to those memories that
> you wish to have code in.
> 2. Make sure that the address span between all peripherals that you
> read instructions out of falls into that 256MB range. This will
> probably mean altering the base address of your memories to group all
> instruction memories close together.
> 
> If the above is not an acceptable solution, feel free to send me an
> email and I can give you some additional ideas.
> 
> Regards,
> 
> Jesse Kempa
> Altera Corp.
> jkempa at altera dot com

Article: 70149
Subject: Re: VHDL test bench in Quartus
From: Pratip Mukherjee <remove_this_pratipm@hotmail.com>
Date: Sat, 05 Jun 2004 12:17:07 GMT
Links: << >>  << T >>  << A >>
rickman <spamgoeshere4@yahoo.com> wrote in
news:40C0DF60.2BF1AA9A@yahoo.com: 

> Rajeev wrote:
>> 
>> rickman <spamgoeshere4@yahoo.com> wrote in message
>> news:<40BF8B40.A64DB0AF@yahoo.com>... 
>> > There is something missing in this discussion.  If you are talking
>> > about testbenches, then Quartus can't help you since testbenches
>> > are used in simulations and Quartus is not a VHDL simulator.
>> >
>> > I agree that using waveforms to simulate FPGA designs is not
>> > desirable. 
>> 
>> I'd love to hear why.
> 
> A test bench is not just a static waveform generator, it can be an
> interactive environment simulator.  I can write code to model an
> external memory or MCU bus cycles or any other interface.  As my
> design progresses it can take a lot less work to keep a testbench up
> to date than it would to redo waveforms.  
> 
> Maybe it is just a personal preference, but I find a VHDL testbench to
> be the best way of testing a design I have found.  
> 

If the design has some Altera specific MegaFunction, then don't you have 
to have another version of the same file using generic VHDL construct?
Can Xilinx/ModelSim be made to understand Altera specific constructs? I 
am talking about the free version of ModelSim which comes with WebPack.
Thanks.



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