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 32875

Article: 32875
Subject: Re: 3.1 on Win2000 with restricted (student) user?
From: "Mike Lowey" <mlowey150@hotmail.com>
Date: Tue, 10 Jul 2001 15:56:54 -0700
Links: << >>  << T >>  << A >>
I figured it out. I know that things show up all garbled here, so if anyone wants me to send it to them, just email me. 

Thanks, 

Mike 

Instructions for installing Xilinx Foundation 3.3.8 on Windows 2000 with a restricted student user. 

Mike Lowey Mike@Lowey.net U.C.Berkeley 7-9-2001 

Note: These instructions are for a new install of Win2000 and Xilinx 3.1 with service pack 8 installed (3.3.8). 

Give the user full control of the file: C:\windows\bti.ini This file may also be called: C:\WINNT\bti.ini Also change the line: “trnfile = C:\WINDOWS” to “trnfile = C:\TEMP” Create C:\temp if it does not exist Give your user full control over C:\temp 

Give the user full control of the file: C:\windows\aldec.ini This file may also be called: C:\WINNT\aldec.ini Also change the line: “PROJECTS = C:\FNDTN\ACTIVE\PROJECTS\” to “PROJECTS = c:\temp” 

Give the user full control over: C:\WINDOWS\TEMP This file may also be called: C:\WINNT\TEMP 

Give the user full control in the following files: C:\windows\Mkdemsg.log C:\windows\Mkdewe.trn These files may also be called: C:\WINNT\Mkdemsg.log C:\WINNT\Mkdewe.trn 

Give full control to the directory: C:\Xilinx 

Change security permissions for the following registry keys to full control for the user: 

HKEY_LOCAL_MACHINE \SOFTWARE \btrieve Technologies \Aldec \Synopsis \Xilinx 

HKEY_CLASSES_ROOT \HKEY_CLASSES_ROOT 

HKEY_CURRENT_USER \Software \Classes \Aldec \Xilinx 

It is very likely that this configuration gives away a little bit too much control over some directories. I suspect that many of them could be read/write instead of full control. It also may not have been necessary to give full control to all of the Xilinx / Aldec / Synopsis / Btreive / classes registry entries. 

Some of this is adapted from Xilinx Support record number 11010 Other leads were found on Autodesk’s web site (they have similar conflicts).

Article: 32876
Subject: Virtex2: Is it possible to place distributed DPRAM
From: Husby_d@yahoo.com (Don Husby)
Date: 10 Jul 2001 16:02:16 -0700
Links: << >>  << T >>  << A >>
I've been beating my head against this for several hours.
I've tried LOC, RLOC, and floorplanning.  It doesn't seem
to be possible to place distributed dual-port RAMs.

Placing a LOC on a RAM16X1D results in an error message that says
you can't place the SP and DP part of a RAM in the same block.

An RLOC is silently ignored.

The floorplanner lets you place things wherever you want, but
the mapper complains about various things.  Also, mapping
directives in the HDL files are incompatible with using the
floorplanner: You can use one or the other, but not both.

Anyone?

Article: 32877
Subject: Re: Large Power up Current on Spartan2
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Tue, 10 Jul 2001 16:46:37 -0700
Links: << >>  << T >>  << A >>
Peter,

If you have 500 mA minimum, it is guaranteed to power on.

If you have less than 500 mA, there are six (six!) "jump start" circuits that
use the existing components (in most cases) to get you over the momentary
current required.  Contact your Xilinx representative and ask for these
Spartan II start-up circuits (available from the Spartan Applications group).

The re-characterization of Spartan II is almost complete (I know, I've said
this before).  We are analyzing the last lot data to revise the
specificaions.

Austin

Peter Lang wrote:

> Hi,
> I am just designing a board with the Spartan2 XC2S15.
> In the Data-Sheets Specs. there is a power up current of min. 500mA.
> Thats quite a lot for the smallest Device. My operating current will be
> about 100mA.
> Do I really nead a power supply rated for 500mA at the 2.5 Volts?
> Does anybody knows the reason for such a large power up current
> Is this current the same for every Spartan2 Device for XC2S15 to XC2S200?
> Is there a Reference Design for Power Supply?
> thanks peter


Article: 32878
Subject: Re: Virtex2: Is it possible to place distributed DPRAM
From: "Steve Casselman" <sc@vcc.com>
Date: Tue, 10 Jul 2001 16:53:21 -0700
Links: << >>  << T >>  << A >>
I have not tried it but maybe you can use a RAM64X1D instead? Its bigger but
it uses the whole CLB so it might be less confusing to the tools.

Steve

"Don Husby" <Husby_d@yahoo.com> wrote in message
news:20446075.0107101502.78e16f71@posting.google.com...
> I've been beating my head against this for several hours.
> I've tried LOC, RLOC, and floorplanning.  It doesn't seem
> to be possible to place distributed dual-port RAMs.
>
> Placing a LOC on a RAM16X1D results in an error message that says
> you can't place the SP and DP part of a RAM in the same block.
>
> An RLOC is silently ignored.
>
> The floorplanner lets you place things wherever you want, but
> the mapper complains about various things.  Also, mapping
> directives in the HDL files are incompatible with using the
> floorplanner: You can use one or the other, but not both.
>
> Anyone?
>



Article: 32879
Subject: Re: How do I distribute cores?
From: Ray Andraka <ray@andraka.com>
Date: Wed, 11 Jul 2001 00:35:35 GMT
Links: << >>  << T >>  << A >>
Kolja,

If you are just changing LUTs and not wiring with the parameterization, and
assuming this is for the virtex or later architecture, you could just use SRL16's
in place of the LUTs to make them loadable after the FPGA is configured.  I do this
for my filter macros.  It has the advnatage that when a customer decides to change
the filter coefficients, he doesn't have to (or have me) run the design through PAR
again.  For DA filters, a fairly simple loader circuit can convert a naturally
ordered list of coefficients into the proper partial sums for the DA LUTs.  For a
small overhead, you avoid alot of reconfiguration and bitstream regeneration
headaches.

Kolja Sulimma wrote:

> Ray Andraka wrote
>
> > [some useful information removed]
>
> Thank you Ray.
>
> > Parameterized cores are not nearly as easy.  They use a combination of VHDL
> > and Java to create the netlist.  If the number of variations is reasonable,
> > the best bet is to generate a set of fixed cores :-(   It would be nice if
> > Xilinx would release a developers tool that would allow third parties to
> > easily produce cores for coregen.
>
> it would indeed.
>
> > To distribute as VHDL, the best suggestion I can offer is to use one of
> > those obfuscaters to make your VHDL harder to read.  Regardless of how you
> > get there, your code has to somehow become an edif netlist to be used.  If
> > you want ot use the generics in VHDL, you're pretty much stuck with using a
> > VHDL synthesizer to generate the edif, in which case your code still has to
> > be legal VHDL.
>
> In this case I would probably have the customer send the parameters to me and I
> send back a netlist. But this is inconvenient for both parties.
>
> I would be nice if JBits could also operate on FPGAEditor Macros instead of
> device bitstreams.
> In this case I could for example easily replace partial products in a
> subcomponent.
> Of course I could do this in the final bitstream as well, but then the customer
> must invoke an additional tool every time a new bitstream is generated. (Not
> only when parameters change, as in the case of modifying macros)
> Steve, Delon: What do you think about it?
>
> Kolja Sulimma

--
-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: 32880
Subject: Re: Online threshold limit counter
From: Ray Andraka <ray@andraka.com>
Date: Wed, 11 Jul 2001 00:42:02 GMT
Links: << >>  << T >>  << A >>
It self-sizes to the width of the signal connected to the D input.  Use an
unconstrained vector in the entity declarations and a constant generated usign the
'length attribute.   Mine is actually structually constructed (using generate
statements and the xilinx primitives), so that 1) I know I get the correct
construction everytime (I've had some of the pushing on a rope syndrome in the past
trying to get the tools to do the loadable downcount in one level of logic in
virtex), and more importantly, It allows me to embed placement on it so that I can
floorplan the counter in my source code (my code includes the RLOCs on the
primitives).

Actually, creating macros like this (quite a while ago now), helped get up the VHDL
learning curve faster.


"Keith R. Williams" wrote:

> In article <3B4B4C24.CF03FFA@andraka.com>, ray@andraka.com says...
> > I use a loadable downcounter, that way the load value is positive and term
> > count happens when it reaches zero.
>
> Sure. I actually do the same.  However, a down-counter isn't a lot
> different than an up counter loaded with a negative number. Actually,
> I've never synthesized the latter, so I don't know what it would look
> like.
>
> > I use it enough that I have a placed VHDL
> > macro for this function.  I bring the load out so that it does not necessarily
> > have to be loaded just with the term count.  The term count can be set up for
> > registered or non-registered and active high or low through generics.  The
> > load value can be a constant or can come from a register so that you can
> > modify it during run time.
>
> Reusable tools are goodness.  Is this a growable macro?  Virtex?
> Actually, I'm not yet comfortable with VHDL to go this far myself.
>
> ----
>   Keith
>
> >
> > "Keith R. Williams" wrote:
> >
> > > In article <994760615.735193@turtle.ru.ac.za>, g9731642@campus.ru.ac.za
> > > says...
> > > > Yes, but are you able to change your preloaded value during run-time? It
> > > > appears that what you are saying is that you set the preload value, and
> > > > thats what its stuck at. I need to be able to change the preloaded value
> > > > during runtime.
> > >
> > > It depends on how you deal with the loading of the (negative) number.
> > > If you load it into a register and use the MSB to re-load the counter
> > > the new value won't be available until the next overflow/reset.  If you
> > > load the new value into the counter when the value changes or zero is
> > > reached, it will take effect immediately.
> > >
> > > ----
> > >   Keith
> >
> > --
> > -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
> >
> >
> >

--
-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: 32881
Subject: Re: Large Power up Current on Spartan2
From: Eric Smith <eric-no-spam-for-me@brouhaha.com>
Date: 10 Jul 2001 17:44:07 -0700
Links: << >>  << T >>  << A >>
Austin Lesea <austin.lesea@xilinx.com> writes:
> If you have less than 500 mA, there are six (six!) "jump start" circuits that
> use the existing components (in most cases) to get you over the momentary
> current required.  Contact your Xilinx representative and ask for these
> Spartan II start-up circuits (available from the Spartan Applications group).

OK, I'll request that.

Not to complain, but this is *exactly* the sort of information that it
would be useful to be able to get from the Xilinx web site, without
having to contact a Xilinx representative.  Maybe you could put these
circuits into an application note?

Thanks!
Eric

Article: 32882
Subject: Re: Online threshold limit counter
From: Ray Andraka <ray@andraka.com>
Date: Wed, 11 Jul 2001 00:47:34 GMT
Links: << >>  << T >>  << A >>
You will take a performance hit for doing a compare whether it is against a
register or a constant.  However, with the constant, there are optimizations
available which will reduce the hit.  Specifically, you don't need inputs to the
comparator for the constant, so you get twice as many compared bits per LUT,
which in turn may mean less levels of logic.  You also can usually ignore some
bits if the compare is against a constant and the input is a monotonic count.
Note that the comparator also represents more area than the loadable counter
options.

True, you won't be able to change the count modulus so that it takes effect
after the load but before the term count.  With both the downcount to zero and
the upcount from a negative number, the modulus is fixed until the next load.

"Andy Peters

> Noddy wrote:
> >
> > Yes, but are you able to change your preloaded value during run-time? It
> > appears that what you are saying is that you set the preload value, and
> > thats what its stuck at. I need to be able to change the preloaded value
> > during runtime.
>
> It seems as if you want to change the number of counts on the fly, in
> which case the count-to-zero option won't work for you.  (Like John, I
> also prefer count-to-zero.)  You'll need some sort of load enable which
> lets you change terminal count value.
>
> For instance,
>
>         signal count : integer range 0 to WHATEVER;
>         signal limit : integer range 0 to WHATEVER;
>         signal preload : integer range 0 to WHATEVER;
>         -- other sigs are std_logic
>
>         -- here's where we load the threshold limit:
>         load_limit : process (clk, rst) is
>         begin
>                 if rst = '1' then
>                         limit <= 0;
>                 elsif rising_edge (clk) then
>                         if loadenable = '1' then
>                                 limit <= preload;
>                         end if;
>                 end if;
>         end process load_limit;
>
>         -- here's the actual counter (I assume you will have a count enable)
>         counter : process (clk, rst) is
>         begin
>                 if rst = '1' then
>                         count <= 0;
>                 elsif rising_edge (clk) then
>                         if countenable = '1' then
>                                 if count = limit then
>                                         count <= 0;
>                                 else
>                                         count <= count + 1;
>                                 end if;
>                         end if;
>                 end if;
>         end process counter;
>
> For some reason, I think you take a performance hit because of the
> compare-to-register (instead of a compare-to-constant), but quite
> frankly, I haven't tested this in quite a while, and I wouldn't be
> surprised if it didn't matter.  Ray probably knows :)
>
> -andy

--
-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: 32883
Subject: Re: Online threshold limit counter
From: Ray Andraka <ray@andraka.com>
Date: Wed, 11 Jul 2001 00:51:16 GMT
Links: << >>  << T >>  << A >>
Another thought.  If you do need to change the count modulus on the fly and have it
take effect immediately, you could use a DDS (aka phase accumulator).  In this case,
you change the increment value in a fixed count field.  The msb out is at a
frequency determined by the increment value.  If you need a count then, you could
detect the rising edge of the msb and use that to reset a counter.

SO many ways to skin a cat!

John_H wrote:

> Andy,
>
> Notice that if you use the "if count = limit then" construct, your "compare to a
> dynamic register" will break if the counter is already beyond the new, smaller
> limit.
>
> If you need an instantaneous compare to the new value, adding the extra
> comparator logic resources  is fine as long as the compare is "if count >= limit
> then" but in most cases the need is for a counter whose terminal count can
> change to a new period on the next count cycle.  It's for the designer to
> decide.
>
> Count to zero (count up from negative preload or count down from positive
> preload) works fine for most designs and can eliminate the compare (if counter =
> 0 then) by using the sign bit.  There's an extra count to include the cycle with
> the sign but it's just figuring out the right value to load ahead of time.
>
> Divide by 7:  ...5,4,3,2,1,0,-1,5... or ...-6,-5,-4,-3,-2,-1,0,-6...
>
> where the preload is a registered item.  Ray pointed out that an unregistered
> sign (or compare to zero) can also be used to decide the proload.  There's so
> many flavors of vanilla it's sometimes hard to choose.  I just have "my"
> favorite flavor of vanilla without the comparator logic.
>
> - John
>
> "Andy Peters
>
> > Noddy wrote:
> > >
> > > Yes, but are you able to change your preloaded value during run-time? It
> > > appears that what you are saying is that you set the preload value, and
> > > thats what its stuck at. I need to be able to change the preloaded value
> > > during runtime.
> >
> > It seems as if you want to change the number of counts on the fly, in
> > which case the count-to-zero option won't work for you.  (Like John, I
> > also prefer count-to-zero.)  You'll need some sort of load enable which
> > lets you change terminal count value.
> >
> > For instance,
> >
> >         signal count : integer range 0 to WHATEVER;
> >         signal limit : integer range 0 to WHATEVER;
> >         signal preload : integer range 0 to WHATEVER;
> >         -- other sigs are std_logic
> >
> >         -- here's where we load the threshold limit:
> >         load_limit : process (clk, rst) is
> >         begin
> >                 if rst = '1' then
> >                         limit <= 0;
> >                 elsif rising_edge (clk) then
> >                         if loadenable = '1' then
> >                                 limit <= preload;
> >                         end if;
> >                 end if;
> >         end process load_limit;
> >
> >         -- here's the actual counter (I assume you will have a count enable)
> >         counter : process (clk, rst) is
> >         begin
> >                 if rst = '1' then
> >                         count <= 0;
> >                 elsif rising_edge (clk) then
> >                         if countenable = '1' then
> >                                 if count = limit then
> >                                         count <= 0;
> >                                 else
> >                                         count <= count + 1;
> >                                 end if;
> >                         end if;
> >                 end if;
> >         end process counter;
> >
> > For some reason, I think you take a performance hit because of the
> > compare-to-register (instead of a compare-to-constant), but quite
> > frankly, I haven't tested this in quite a while, and I wouldn't be
> > surprised if it didn't matter.  Ray probably knows :)
> >
> > -andy

--
-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: 32884
Subject: Re: Virtex2: Is it possible to place distributed DPRAM
From: Ray Andraka <ray@andraka.com>
Date: Wed, 11 Jul 2001 01:10:28 GMT
Links: << >>  << T >>  << A >>
The floorplanner essentially puts LOCs on it (it treats the design as
flat).  Have you tried putting RLOCs on by embedding the RLOCs in your
source using user attributes rather than the mapping directives (you
need to instantiate the RAM16x1D primitive to do that)?  I have had no
problem using embedded RLOCs with the floorplanner.  I had had numerous
problems with the synthesis vendor's RLOC directives...enough so that I
stopped trying to use them some time ago.

If the RLOC is being ignored, it is generally because it is being
applied to a macro which does not have RLOCs on the primitives.  It
sounds like perhaps your synthesis tool is constructing the RAM16x1D out
of other primitives rather than instantiating the RAM16x1D primitive.
Try instantiating it as a black box and putting and RLOC attribute on
it.  Make sure the generics are not visible to the synthesis or it will
screw it up.

Don Husby wrote:

> I've been beating my head against this for several hours.
> I've tried LOC, RLOC, and floorplanning.  It doesn't seem
> to be possible to place distributed dual-port RAMs.
>
> Placing a LOC on a RAM16X1D results in an error message that says
> you can't place the SP and DP part of a RAM in the same block.
>
> An RLOC is silently ignored.
>
> The floorplanner lets you place things wherever you want, but
> the mapper complains about various things.  Also, mapping
> directives in the HDL files are incompatible with using the
> floorplanner: You can use one or the other, but not both.
>
> Anyone?

--
-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: 32885
Subject: Re: Large Power up Current on Spartan2
From: "Gerald B" <mdesigns@ipa.net>
Date: Tue, 10 Jul 2001 20:30:47 -0500
Links: << >>  << T >>  << A >>

"Austin Lesea" <austin.lesea@xilinx.com> wrote in message
news:3B4B93DD.41D8D50@xilinx.com...
> Peter,
>
> If you have 500 mA minimum, it is guaranteed to power on.

A power supply specification this simple would be great!  But what about...
1) Has the minimum VCCint rise time of 2ms and maximum rise time of 50ms
gone away?  [Ref. app. note XAPP189 3/20/01 page #2 and data sheet module 3
page#3.]  Ensuring that VCCint doesn't rise faster than 2ms is a problem.
2) What about the requirement of VCCint not being allowed to dip in negative
direction during power-on ramp?  [XAPP189 & datasheet.]  The datasheet has
graphs that show this as a definite no-no.
3) XAPP189 also says that "When power-supply voltage falls below min.
operating voltage, it should not rise immediately back to nominal operating
voltage without first discharging back down to below .1V."  Has this gone
away?  This sounds like the old crow-bar circuit that the XC2000 series
required.  Many years ago, we spent lots of hours trying to get these old
parts to configure reliably after a brown-out.  I get worried when I see
this in a Xilinx app. note.

> The re-characterization of Spartan II is almost complete (I know, I've
said
> this before).  We are analyzing the last lot data to revise the
> specificaions.
>

I commend Xilinx for documenting these power requirements so well.  I hope
the re-characterization has found that the parts are more immune to power-up
problems.  I look forward to reading the new specifications.

Gerald





Article: 32886
Subject: Re: Handel-C
From: anamax@earthlink.net (Andy Freeman)
Date: 10 Jul 2001 19:13:13 -0700
Links: << >>  << T >>  << A >>
"news_alias" <new_alias@yahoo.com> wrote in message news:<VPH27.31542$C81.2496731@bgtnsc04-news.ops.worldnet.att.net>...
> Andy Freeman <anamax@earthlink.net>
> ....
> > > 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.
> >
> > Having actually used C to design hardware, I note that the above is
> > both widely believed and wrong.  (It's also why most of the C-based
> > hardware design languages aren't all that useful.)
> 
> Are you sure?   Maybe the widely held beliefs are not wrong.
> 
> The programmer's model for C is for a single instruction processor
> and no awareness of how long it takes to process each instruction.

C has a sequential model for disambiguating dependencies, but that's
really as far as it goes.  That model does not imply or require
serial execution and it is perfectly capable of modelling arbitrary
static parallelism.  (That's all you get in hardware until someone
invents a way to create new gates while the system is running.)

Some hardware design languages let you say how long an operation will
take, but you can't do much with that ability.  In particular,
the correctness of the design can't depend on those numbers.  (I'm
ignoring the various delays used in broken verilog to trick the
event queue.  If your synthesized code behaves differently than
your RTL until you add those delays, you're writing broken code.
If the behavior of your code depends on those delays, you're
writing broken code.)

Delays are really just a poor-man's way of doing timing analysis.
There's nothing wrong with that, but don't confuse it with any
useful awareness of operation time.

> To model multiple processes and the passage of time, C can be
> extended.

While true, that doesn't imply that such extensions are necessary
or even useful for modelling hardware.

With "the right extensions", you can write event-driven code in
C, just like you do in Verilog.  However, at that point, one might
well ask why you don't simply use Verilog.

If C is to be a useful hardware design language, it has to be
different than Verilog.  There are lots of ways to be different;
I've had experience with some of them, and I've found that
some work better than others.

-andy

Article: 32887
Subject: Re: Handel-C
From: anamax@earthlink.net (Andy Freeman)
Date: 10 Jul 2001 20:35:53 -0700
Links: << >>  << T >>  << A >>
> Judging from the responses here, a lot of hardware types see "C" and
> assume that Handel-C is not a hardware language.  You should get
> familier with keywords like "par", "signal", "clock", "interface",
> "chan" before assuming that Handel-C has much to do with C.

> As Adrian E. Lawrence notes, it's thinly disguised Occam.
> It's a lot nicer to read than Occam :-)

And that's why it is very misleading to say that Handel-C is C-like.
As someone else pointed out, Verilog expressions look like C expressions
but still they are very different languages.  Handel-C is CSP headed
toward VHDL via Occam.  (CSP and Occam are theoretically elegant, but
there's something that kept them from being generally useful.  That's
a bad place to start from.)

Yes, one can use various libraries to provide a different execution
model in C.  If that execution model is Verilog-like, you must staff
your project with people who think Verilog, but are reasonably
competent in C.  The benefits of this approach over just using
Verilog are unclear.  If the execution model is something else, it's
even worse.

I think that to use C to design hardware, you need to restrict C's
execution model, not extend it.  (Yes, you need support for decent
bit operations; the Frontier folks have done some nice work in this
area.)  Most of the restrictions are fairly obvious - they're a lot
like those imposed on embedded systems.  They're all consequences
of the fact that hardware is static - you can't ask for more gates
or wires at run-time.

By restricting the execution model, "ordinary C programmers"
can produce hardware, and they don't have to think differently.

However, to "make timing", to make good hardware, they must do
what every other hardware designer must do.  They must figure
out how to do the required computation with a set of operations
that can be performed "fast enough", "small enough", and with not
too much power.

No design language can ever eliminate that requirement.

For what it's worth, good software has to satisfy similar constraints,
so it's fairly easy for good programmers to make the transition.
(The world may be more forgiving of bad software.)

So, what's the point of using C?  One advantage of the restricted
C model is that it eliminates heisenbugs.  If there's a discrepancy
between the RTL-C and the synthesized hardware, it's a synthesizer
bug.  (This eliminates the voodoo verilog involving #delays "to make
it work", the #delays that often come back to bite you later.)

It can also be transformed automatically for simulation on
cheap multi-processor boxes that take the place of expensive
emulation machines.  (I don't know when VCS or Speedsim will
be able to do the same.  Remember, the behavior must not change.)

I've also found that it's a more productive design language.

One could argue that the C restrictions are in some sense equivalent
to those of "good Verilog", which says that the possibility of
bad verilog wastes time.

I think that the restricted C execution model makes the design easier
to understand.  There's absolutely no staring at code trying to figure
out what's happening, let alone "let's run it and see what happens".
All of the interactions are right in front of you, so you can think
about what you're trying to do instead of trying to understand what
you've done or how to do it.

-andy

Article: 32888
Subject: Re: Altera synthesis tools WAS: What chip!?
From: "Peter Ormsby" <faepetedeletethis@mediaone.net>
Date: Wed, 11 Jul 2001 04:40:21 GMT
Links: << >>  << T >>  << A >>
All kinds of fun going on here (comments embedded below)...


cyber_spook <pjc@cyberspook.freeserve.co.uk> wrote in message
news:3B4B682D.BB04BD11@cyberspook.freeserve.co.uk...
>
>
> bob elkind wrote:
>
> > Niki Steenkamp wrote:
> >
> > > Hi,
> > >
> > > <completely unrelated thread deleted>
> >
> > > I would like to start an Altera discussion on why I get so many
> > > "Internal Errors" from MaxPlusII as soon as I try to use more
> > > interesting VHDL.  ;-)
> > > I wasted an afternoon trying to find such an error, when all what it
> > > was, was a missing else clause.  The other day I wasted a whole day
> > > trying to get the "for generate" construct to work with a 2
dimensional
> > > array.  Eventually I gave up, compiled it in FPGA express and pulled
in
> > > the EDIF - no problems.  ...sigh...
>
> Good point - don't use MaxPlusII for this as thay never seamed to get it
to work
> right.

MAX+PLUS II works well for a great majority of the designs out there.  Let's
not confuse the synthesis part with the rest of the tool.  Altera's native
VHDL
synthesis has never been much more than OK (although its better than the
native verilog synthesis).  The rest of the tool has always been fast,
relatively
easy to learn, and generally quite capable.  As for the synthesis, not only
does
Altera bundle Altera-specific versions of Synopsys' FPGA Express and
Exemplar's
Leonardo Spectrum with their tools subscription (as mentioned below), you
can
actually get these tools free from the Altera web site (along with the free
version
of MAX+PLUS II for the MAX and ACEX devices).

-Pete-

>
> >
> > >
> > > I am starting to become more and more pro-3rd-party-tools.  (Not that
> > > they don't have any problems, but lets leave it at that!)
> > >
> > > Niki
> > >
> >
> > For the last year(?) Altera has been bundling Altera-only versions of
> > Leonardo Spectrum, ModelSim, and FPGA Express with Quartus and
> > Max+II.  While MAX+II *does* have its own Verilog and VHDL
> > synthesis engine, Altera has apparently decided that it is better to
bundle
> > a *competitive* synthesis and sim product rather than tell their
customers
> > to either buy a *very* expensive 3rd party design seat or settle for the
> > internal Altera synthesis tool.  If you're subscribed to Altera tools
support,
> > you should have these CDs already.
> >
> > see http://www.altera.com/products/software/sfw-oem.html
> >
> > -- Bob Elkind, the e-team   fpga/design consulting
>



Article: 32889
Subject: Re: Virtexe Config problem
From: Vikram Pasham <Vikram.Pasham@xilinx.com>
Date: Tue, 10 Jul 2001 21:42:03 -0700
Links: << >>  << T >>  << A >>
Wamsi,

How are you configuring the Virtex-E device? From a prom? Cable?
Microprocessor/Microcontroller?
What is the CCLK freq.? If its above 50MHz, you should use busy signal in
SelectMap mode.
Virtex-E device starts configuration after it see the sync word
x"AA995566". The data following sync word has several configuration write
commands, crc checks and finally some dummy words.

If you haven't already checked, refer XAPP138 and Configuration problem
solver on Xilinx support website.

-Vikram
Xilinx Applications



Wamsi Mohan wrote:

> Hello.
>  The problem I am facing is that when I try to configure the XCV600E
> using selectMAP, the Done does not go high. However, INIT does not go
> low either to indicate any config error.
> I follow the usual steps of driving prog low and then high, waiting for
> Init to go high and then clock the data[7:0]. Bitgen is compiled with
> cclk option (as opposed to jtag clk or userclk). The mode pins are set
> to 110 (select MAP). I have tried to abort the config cycle and read
> back the status word. I read back 0xDF which Xilinx claims is correct.
>
> Any thoughts?
> Thanks
> -Wamsi


Article: 32890
Subject: Re: How do I distribute cores?
From: Francisco Camarero <francisco.camarero@acterna.com>
Date: Wed, 11 Jul 2001 08:48:05 +0200
Links: << >>  << T >>  << A >>
Kolja Sulimma wrote:
> 
> Hi!
> 
> I enjoy doing Open Source projects, but I now have a core that contains
> some trade secrets that I would like to protect. Now I wonder what is
> the best way to distribute a core like this.
> 
> Of course I can generate a netlist macro, that the customer can
> instantiate.

  What kind of tools is your customer using ?

  What is the purpose of the core, to be synthesized, or only to be
simulated ?

Article: 32891
Subject: Need to speed up VHDL accumulator on Xilinx
From: dottavio@ised.it (Antonio)
Date: 11 Jul 2001 00:35:20 -0700
Links: << >>  << T >>  << A >>
Good Morning,
I've this accumulator that I would want to implement on a Xilinx
XCV1000BG560-4 , the problem is that I need 165MHz and instead this
may work only at 105MHz , have you in mind any modify that I could do
to speed it up ??


library	ieee;
use ieee.std_logic_1164.all;
use ieee.std_logic_arith.all;
use ieee.std_logic_signed.all;


entity accumulatore is
	port ( freq_word		:	in std_logic_vector(31 downto 0); 
		clk, load, clear	:	in std_logic;
		theta			    :	inout std_logic_vector(31 downto 0)
		);
end accumulatore;

architecture acc_arch of accumulatore is
	signal reg_theta	:	std_logic_vector(31 downto 0);  
	begin
	process(load, clear, freq_word, theta)   		
		begin
		if load='1' then
			reg_theta <= freq_word;			   
		else if clear='1' then
				reg_theta <= "00000000000000000000000000000000";
			else				
				reg_theta <= freq_word+theta;
			end if;
		end if;
	end process;
	
	process(clk)
		begin
		if clk'event and clk='1' then	  
			theta <= reg_theta;				  
		end if;
	end process;
end acc_arch;

The Accumulator is inside a Cordic NCO and I can't utilize Core
Generator 'cause then the project will be mapped on ASIC, that I know
is more speed but I want to implement the working project also on FPGA
to simulate it accurately before of fitting on ASIC.

thank you for your help ...

    Antonio D'Ottavio

Article: 32892
Subject: Re: Handel-C
From: Magnus Homann <d0asta@licia.dtek.chalmers.se>
Date: 11 Jul 2001 10:22:02 +0200
Links: << >>  << T >>  << A >>

Hello Andy,

Your posts about using a C as a hardware language are interesting. Do
you have any example with using C-code and storage elements? Who is
doing this kind of stuff?

Yours,
Magnus
-- 
Magnus Homann, M.Sc. CS & E
d0asta@dtek.chalmers.se


Article: 32893
Subject: Re: Virtex2: Is it possible to place distributed DPRAM
From: Philip Freidin <philip@fliptronics.com>
Date: Wed, 11 Jul 2001 02:34:06 -0700
Links: << >>  << T >>  << A >>
Warning. I have found that RLOCs dont work for Virtex-II . While there are
some trivial test cases which do work, really complex stuff like putting
two flip-flops in the same slice dont work, and are ignored, with no error
message. (I.e. silently ignored)
Since flip flops are too hard, I wouldn't expect anything else to work either.

I am using 3.3.8i

I have filed a case. No result yet.

Philip Freidin

(I can't tell you how much I enjoy creating test cases and documenting
 failure modes for stuff that it is hard to believe was ever tested :-(   )


On Wed, 11 Jul 2001 01:10:28 GMT, Ray Andraka <ray@andraka.com> wrote:
>The floorplanner essentially puts LOCs on it (it treats the design as
>flat).  Have you tried putting RLOCs on by embedding the RLOCs in your
>source using user attributes rather than the mapping directives (you
>need to instantiate the RAM16x1D primitive to do that)?  I have had no
>problem using embedded RLOCs with the floorplanner.  I had had numerous
>problems with the synthesis vendor's RLOC directives...enough so that I
>stopped trying to use them some time ago.
>
>If the RLOC is being ignored, it is generally because it is being
>applied to a macro which does not have RLOCs on the primitives.  It
>sounds like perhaps your synthesis tool is constructing the RAM16x1D out
>of other primitives rather than instantiating the RAM16x1D primitive.
>Try instantiating it as a black box and putting and RLOC attribute on
>it.  Make sure the generics are not visible to the synthesis or it will
>screw it up.
>
>Don Husby wrote:
>
>> I've been beating my head against this for several hours.
>> I've tried LOC, RLOC, and floorplanning.  It doesn't seem
>> to be possible to place distributed dual-port RAMs.
>>
>> Placing a LOC on a RAM16X1D results in an error message that says
>> you can't place the SP and DP part of a RAM in the same block.
>>
>> An RLOC is silently ignored.
>>
>> The floorplanner lets you place things wherever you want, but
>> the mapper complains about various things.  Also, mapping
>> directives in the HDL files are incompatible with using the
>> floorplanner: You can use one or the other, but not both.
>>
>> Anyone?

Philip Freidin
Fliptronics

Article: 32894
Subject: Re: How do I distribute cores?
From: Kolja Sulimma <kolja@sulimma.de>
Date: Wed, 11 Jul 2001 13:17:32 +0200
Links: << >>  << T >>  << A >>


Francisco Camarero wrote:

> Kolja Sulimma wrote:
> >
> > Hi!
> >
> > I enjoy doing Open Source projects, but I now have a core that contains
> > some trade secrets that I would like to protect. Now I wonder what is
> > the best way to distribute a core like this.
> >
> > Of course I can generate a netlist macro, that the customer can
> > instantiate.
>
>   What kind of tools is your customer using ?

>   What is the purpose of the core, to be synthesized, or only to be
> simulated ?

The customers want to generate Xilinx FPGA configurations.
Therefore they must have at least the Foundation backend tools. (Or Alliance)

This is sufficient for unparametrized cores that can be distributed as EDIF
netlists.

What I do not know, is how to distribute synthesizable cores without
distributing readable sourcecode.
I do not know in advance what synthesis tools the customer is going to use,
but I think I could restrict the core to certain tools.

Kolja Sulimma


Article: 32895
Subject: Re: Need to speed up VHDL accumulator on Xilinx
From: Francisco Camarero <francisco.camarero@acterna.com>
Date: Wed, 11 Jul 2001 14:08:05 +0200
Links: << >>  << T >>  << A >>
Antonio wrote:
> 
> Good Morning,
> I've this accumulator that I would want to implement on a Xilinx
> XCV1000BG560-4 , the problem is that I need 165MHz and instead this
> may work only at 105MHz , have you in mind any modify that I could do
> to speed it up ??
> 
> library ieee;
> use ieee.std_logic_1164.all;
> use ieee.std_logic_arith.all;
> use ieee.std_logic_signed.all;
> 
> entity accumulatore is
>         port ( freq_word                :       in std_logic_vector(31 downto 0);
>                 clk, load, clear        :       in std_logic;
>                 theta                       :   inout std_logic_vector(31 downto 0)
>                 );
> end accumulatore;
> 
> architecture acc_arch of accumulatore is
>         signal reg_theta        :       std_logic_vector(31 downto 0);
>         begin
>         process(load, clear, freq_word, theta)
>                 begin
>                 if load='1' then
>                         reg_theta <= freq_word;
>                 else if clear='1' then
>                                 reg_theta <= "00000000000000000000000000000000";
>                         else
>                                 reg_theta <= freq_word+theta;
>                         end if;
>                 end if;
>         end process;
> 
>         process(clk)
>                 begin
>                 if clk'event and clk='1' then
>                         theta <= reg_theta;
>                 end if;
>         end process;
> end acc_arch;
> 
> The Accumulator is inside a Cordic NCO and I can't utilize Core
> Generator 'cause then the project will be mapped on ASIC, that I know
> is more speed but I want to implement the working project also on FPGA
> to simulate it accurately before of fitting on ASIC.
> 
> thank you for your help ...
> 
>     Antonio D'Ottavio


Is it allowed for you to pipeline it ?

Article: 32896
Subject: file flush in VHLD for synopsys VSS
From: Steven Derrien <sderrien@irisa.fr>
Date: Wed, 11 Jul 2001 15:29:31 +0200
Links: << >>  << T >>  << A >>
Hello,

I'm trying to implement a co-simulation framework which would allow
the co-simulation of a C programm (running on a CPU) with a vhdl circuit 
(running on a FPGA). Specifically, I'm trying to emulate unix pipe |
using 
two files: one is used to send data from the C program to the vhld
entity,
the other one is used by the vhdl entity to send data to the C program.

To avoid deadlocks, i must ensure that all IO write operation are 
immediatly performed on the target file. This is easily handled in C
with 
fflush(), however i didn't found any workaround for VHDL.

Anyone with a clue ?

Thanks 
Steven

Article: 32897
Subject: Re: Need to speed up VHDL accumulator on Xilinx
From: Ray Andraka <ray@andraka.com>
Date: Wed, 11 Jul 2001 14:00:18 GMT
Links: << >>  << T >>  << A >>
You can get close to 165 MHz with a 16 bit adder using the carry chain in the
XCV1000-4, provided you keep the signals driving the adder inputs immediately adjacent
to the adder, the logic is kept to a single level of logic (what you have there will
synthesize to two levels of logic in some tools), and that they don't drive more than
one or two loads.  You are not going to get there with a 32 bit adder without
pipelining the carry, or using two adders on alternate cycles (so that each adder is
working at 82.5 MHz).

If you rearrange so that the clear dominates over the load, you'd at least be able to
use the sync clear input to the FF instead of the LUT for the clear function.  Using
the LUT for the clear requires some boolean gymnastics because the carry chain follows
the lut.  The logic you have right now will infer a multiplexer between the carry chain
logic and the flip-flops.

You are going to find it difficult to run the XCV1000-4 at 165 MHz even with 16 bit
carry chains,  you might consider a faster speed grade if possible (of course, if this
is a Q-PRO ..ie military/space application... part, you are stuck with the 1000-4).
Our FFT core, which has 20 bit carry chains and is highly optimized to the virtex
architecture (we spent months tweaking it to get the last MHz out of it) is only good
for 153 MHz in the virtex -4 speed grade.

Antonio wrote:

> Good Morning,
> I've this accumulator that I would want to implement on a Xilinx
> XCV1000BG560-4 , the problem is that I need 165MHz and instead this
> may work only at 105MHz , have you in mind any modify that I could do
> to speed it up ??
>
> library ieee;
> use ieee.std_logic_1164.all;
> use ieee.std_logic_arith.all;
> use ieee.std_logic_signed.all;
>
> entity accumulatore is
>         port ( freq_word                :       in std_logic_vector(31 downto 0);
>                 clk, load, clear        :       in std_logic;
>                 theta                       :   inout std_logic_vector(31 downto 0)
>                 );
> end accumulatore;
>
> architecture acc_arch of accumulatore is
>         signal reg_theta        :       std_logic_vector(31 downto 0);
>         begin
>         process(load, clear, freq_word, theta)
>                 begin
>                 if load='1' then
>                         reg_theta <= freq_word;
>                 else if clear='1' then
>                                 reg_theta <= "00000000000000000000000000000000";
>                         else
>                                 reg_theta <= freq_word+theta;
>                         end if;
>                 end if;
>         end process;
>
>         process(clk)
>                 begin
>                 if clk'event and clk='1' then
>                         theta <= reg_theta;
>                 end if;
>         end process;
> end acc_arch;
>
> The Accumulator is inside a Cordic NCO and I can't utilize Core
> Generator 'cause then the project will be mapped on ASIC, that I know
> is more speed but I want to implement the working project also on FPGA
> to simulate it accurately before of fitting on ASIC.
>
> thank you for your help ...
>
>     Antonio D'Ottavio

--
-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: 32898
Subject: Re: Need to speed up VHDL accumulator on Xilinx
From: "fred" <x@y.z>
Date: Wed, 11 Jul 2001 15:13:13 +0100
Links: << >>  << T >>  << A >>
All Ray said plus:

If you want to work out if you stand any chance at all of getting this sort
of speed, write the accumulator without the muxes (load and clear) - the
fastest inferrable structure:

process(clk)
begin
if clk'event and clk='1' then
theta <= freq_word+theta;
end if;
end process;

If this wont go at the speed you want then you'll need to find another way.

Whatever you do I think you'll need to get rid of those muxes get clear from
the register's direct synchronous clear and the load from 'clear' followed
by first accumulate.

BTW: for vtx1000e-6 (I don't have Virtex parts loaded) I got 128M for your
code, 158M for the bare bones - 2speed grades up & still not quite there.

Fred



Article: 32899
Subject: Re: Virtex2: Is it possible to place distributed DPRAM
From: Ray Andraka <ray@andraka.com>
Date: Wed, 11 Jul 2001 14:15:18 GMT
Links: << >>  << T >>  << A >>
I didn't realize this was a VirtexII.  I have had near zero luck with RLOCs in
virtexII so far.  I'm glad someone like you is debugging it before it becomes my
critical path ;->

Philip Freidin wrote:

> Warning. I have found that RLOCs dont work for Virtex-II . While there are
> some trivial test cases which do work, really complex stuff like putting
> two flip-flops in the same slice dont work, and are ignored, with no error
> message. (I.e. silently ignored)
> Since flip flops are too hard, I wouldn't expect anything else to work either.
>
> I am using 3.3.8i
>
> I have filed a case. No result yet.
>
> Philip Freidin
>
> (I can't tell you how much I enjoy creating test cases and documenting
>  failure modes for stuff that it is hard to believe was ever tested :-(   )
>
> On Wed, 11 Jul 2001 01:10:28 GMT, Ray Andraka <ray@andraka.com> wrote:
> >The floorplanner essentially puts LOCs on it (it treats the design as
> >flat).  Have you tried putting RLOCs on by embedding the RLOCs in your
> >source using user attributes rather than the mapping directives (you
> >need to instantiate the RAM16x1D primitive to do that)?  I have had no
> >problem using embedded RLOCs with the floorplanner.  I had had numerous
> >problems with the synthesis vendor's RLOC directives...enough so that I
> >stopped trying to use them some time ago.
> >
> >If the RLOC is being ignored, it is generally because it is being
> >applied to a macro which does not have RLOCs on the primitives.  It
> >sounds like perhaps your synthesis tool is constructing the RAM16x1D out
> >of other primitives rather than instantiating the RAM16x1D primitive.
> >Try instantiating it as a black box and putting and RLOC attribute on
> >it.  Make sure the generics are not visible to the synthesis or it will
> >screw it up.
> >
> >Don Husby wrote:
> >
> >> I've been beating my head against this for several hours.
> >> I've tried LOC, RLOC, and floorplanning.  It doesn't seem
> >> to be possible to place distributed dual-port RAMs.
> >>
> >> Placing a LOC on a RAM16X1D results in an error message that says
> >> you can't place the SP and DP part of a RAM in the same block.
> >>
> >> An RLOC is silently ignored.
> >>
> >> The floorplanner lets you place things wherever you want, but
> >> the mapper complains about various things.  Also, mapping
> >> directives in the HDL files are incompatible with using the
> >> floorplanner: You can use one or the other, but not both.
> >>
> >> Anyone?
>
> Philip Freidin
> Fliptronics

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





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