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 51550

Article: 51550
Subject: Re: SChematic design approach compared to VHDL entry approach
From: "Tim" <tim@rockylogic.com.nooospam.com>
Date: Thu, 16 Jan 2003 12:06:08 -0000
Links: << >>  << T >>  << A >>
Austin Franklin wrote
> Tim wrote
> > I can see how you can mimic the functionality of a schematic
> > in a programming language.  But the other way round seems tough.
>
> Hi Tim,
>
> If I understand what you mean...I can tell you that I USED to get a LOT of
> jobs doing exactly that...taking VHDL and converting it to schematics.

Austin

Absolutely correct.  But usually you are concerned with optimizing
the data flow, and you can convert the data flow to a structural
representation within VHDL.  In fact the LUT stuffing code on my
site at www.rockylogic.com/freebies/freebies.html "Locking Logic
to a Single Xilinx Virtex LUT" is an example of how to do this in
VHDL at a _very_ low level.  Probably a lower level than is of
interest to most users, and equivalent to the lowest level possible
with schematic.

A great advantage of using an HDL is that everything can be
parameterized, with arbitrary calculations of the parameters at
instantiation time.  And everything can be replicated N times over,
with just a simple loop statement.  It may be possible to do this
with some schematic packages, but I only have substantial experience
of the OrCAD product.  And even there I retreated to the old 16-bit
DOS product when I discovered how unfriendly the later stuff had become.

I think your comments have more force when you compare schematic to
Verilog - I don't think that even Phil Moorby would see standard Verilog
as the last word on the subject.  The lack of decent parameter
manipulation, a generate loop, and arbitrary attributes mean that
everyday Verilog engineers have to be good at modifying netlists via
Perl scripts, TCL scripts, UCF files, or whatever.

Of course, given that FPGA design is harder than ASIC design, these
problems hit us while the ASIC mob is still using brute force.





Article: 51551
Subject: Xilinx Constraint Problem
From: "Jock" <ian.mcneil@uk.thalesgroup.com>
Date: Thu, 16 Jan 2003 12:21:33 -0000
Links: << >>  << T >>  << A >>
This used to be ok until I reloaded the design on another PC, but now I am
getting the following error under P&R using: V4.1i of Xilinx ISE

"ERROR:MapLib:93 - Illegal LOC on symbol "VCO_70MZ" (pad signal=VCO_70MZ) or
BUFGP symbol "VCO_70MZ_ibuf" (output signal=VCO_70MZ_int), IPAD-IBUFG should
only be LOCed to GCLKIOB site."

In my design I haven't specified that VCO_70MZ should be through a BUFG. I
am using HDL designer and Leospec for my source code.

1. Where does ISE get the assumption that this is through a clock buffer?
2. How do I fix it without changing the LOC.?




Article: 51552
(removed)


Article: 51553
Subject: Re: Schematic design approach compared to VHDL entry approach
From: Ray Andraka <ray@andraka.com>
Date: Thu, 16 Jan 2003 12:53:43 GMT
Links: << >>  << T >>  << A >>
In cases where you really care what is synthesized...ie you know the logic you
wish to create, the safest way is to structually instantiate that portion of you
design.  I do it rather extensively on our high performace designs.  It isn't
hard to do, but it does take a bit of time to build your libraries to a point
where you can do it rapidly.

Eric Smith wrote:

> "Austin Franklin" <austin@da98rkroom.com> writes:
> > I don't want to run the tools and play guessing games with what the tool is
> > going to output.  It should be documented, so when I code, I KNOW what the
> > hardware will be.
>
> The tool doesn't always output the same thing for a given construct.  A
> lot of things can influence it.  A manual like you propose would be huge,
> and would almost always be out of date.
>
> Have you seen such a manual for a C compiler?  I haven't.  And that's an
> easier problem, because there are few constraints on the compiler output.
>
> If you care about what's generated, you should look at the reports produced
> by the synthesizer.  That will tell you what you want to know.

--
--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: 51554
Subject: Re: Xilinx Constraint Problem
From: Nicolas Matringe <nicolas.matringe@ipricot.com>
Date: Thu, 16 Jan 2003 14:18:06 +0100
Links: << >>  << T >>  << A >>
Jock wrote:
> 
> This used to be ok until I reloaded the design on another PC, but now I am
> getting the following error under P&R using: V4.1i of Xilinx ISE
> 
> "ERROR:MapLib:93 - Illegal LOC on symbol "VCO_70MZ" (pad signal=VCO_70MZ)
> or BUFGP symbol "VCO_70MZ_ibuf" (output signal=VCO_70MZ_int), IPAD-IBUFG
> should only be LOCed to GCLKIOB site."
> 
> In my design I haven't specified that VCO_70MZ should be through a BUFG. I
> am using HDL designer and Leospec for my source code.
> 
> 1. Where does ISE get the assumption that this is through a clock buffer?
> 2. How do I fix it without changing the LOC.?

Hi
LeoSpec automatically inserted the IBUFG because this signal must be used as a
clock in your design. Just disable the "Add clock buffer" option in LeoSpec and
resynthesize your design.
Anyway, using a GCLKIOB site for your clock input would be a good idea...

Nicolas

Article: 51555
Subject: 200K gates FPGA for GPU
From: "tsao" <feng_1955@no_spam_ybb.ne.jp>
Date: Thu, 16 Jan 2003 22:43:39 +0900
Links: << >>  << T >>  << A >>
How far can I go to implement a 3D vertex processing
pipeline on a 200K gates fpga?


Article: 51556
Subject: Re: Virtex II pro architecture question
From: Florian-Wolfgang Stock <f.stock@tu-bs.de>
Date: Thu, 16 Jan 2003 14:51:02 +0100
Links: << >>  << T >>  << A >>
Hello,

Kuan Zhou <zhouk@rpi.edu> writes:

> Hi,
>    I looked at Virtex II pro architecture.What are the functions
> of WG4, WG3, WG2 and WG1?I noticed there are 8 inputs to each LUT.
> Are they forming a 2^8 by 1 LUT tables or two 16 by 1 LUTs indivisually?

no, the LUTs can still have only 4 inputs if in LUT-mode
(G1-G4). G1-G4 are used if the LUT is in RAM-mode, e.g. if in
dual-port configuration the G1-G4 are read address inputs and the
WG1-WG4 are the write address inputs.

Flolo

-- 
int m,u,e=0;float l,_,I;main(){for(;1840-e;putchar((++e>907&&942>e?61-m:u)
["\t#*fg-pa.vwCh`lwp-e+#h`lwP##mbjqloE"]^3))for(u=_=l=0;79-(m=e%80)&&
I*l+_*_<6&&26-++u;_=2*l*_+e/80*.09-1,l=I)I=l*l-_*_-2+m/27.;}

Article: 51557
Subject: Re: 200K gates FPGA for GPU
From: "tsao" <feng_1955@no_spam_ybb.ne.jp>
Date: Thu, 16 Jan 2003 22:52:25 +0900
Links: << >>  << T >>  << A >>
I just want to make a small demonstration, there is no
input( no API interface), vertex data are generated
in the fpga, and there will be a small texture defined
as rom in the fpga.

I'm using the RC100 board with HandleC. Celoxica has a
floating point library for HandleC which I'm using.

Thanks

"tsao" <feng_1955@no_spam_ybb.ne.jp> wrote in message
news:b06cvm$21nr$2@news.ecc.u-tokyo.ac.jp...
> How far can I go to implement a 3D vertex processing
> pipeline on a 200K gates fpga?
>


Article: 51558
Subject: Re: Schematic design approach compared to VHDL entry approach
From: Brian Drummond <brian@shapes.demon.co.uk>
Date: Thu, 16 Jan 2003 13:53:44 +0000
Links: << >>  << T >>  << A >>
On Thu, 16 Jan 2003 00:04:39 -0500, "Austin Franklin"
<austin@da98rkroom.com> wrote:

>
>"Eric Smith" <eric-no-spam-for-me@brouhaha.com> wrote in message
>news:qhlm1loob3.fsf@ruckus.brouhaha.com...
>> "Austin Franklin" <austin@da98rkroom.com> writes:
>> > A fundamental gripe I have with synthesis tools.  They SHOULD provide a
>> > document that states EXACTLY what a construct gets synthesized to.
>>
>> They do.  It's in one of the report files.  I often look at it to make
>> sure that I'm getting something reasonable.
>
>Eric,
>
>I don't think you understand what I am talking about.  What I am looking for
>is a gate level description of what a construct will synthesize to.  
[...]
>
>I don't want to run the tools and play guessing games with what the tool is
>going to output.  It should be documented, so when I code, I KNOW what the
>hardware will be.
>

I suspect that would only be possible for a primitive (probably highly
inefficient) synthesis process. 

Leo Spectrum can run four passes on each block, with widely differing
area (LUT count) and speeds - often about 2:1 in each - and it picks the
best (smallest or fastest, you decide) before moving onto the next
block. 

Block, here, means either the whole design, or each entity, or some
level in between - again, you choose in a number of ways.

Given a regular, highly ordered (or simply small) block, each pass
converges to exactly the same speed and area - and presumably internal
structure - but for larger blocks, the variation observed above is seen.

My conclusion from this is that for very simple designs its behaviour
can be documented as you ask, but that for larger blocks it is capable
of selecting from so many different strategies and performing so many
optimisations and transformations that no such prediction is possible.

I haven't often viewed the resulting code, but have sometimes been
impressed at how devious/cunning/clever it can be in finding e.g.
optimisations between block boundaries (when I let it auto-dissolve or
flatten the hierarchy) ... and only occasionally appalled at how stupid!

- Brian


Article: 51559
Subject: Re: Virtex II pro architecture question
From: amit_ashara@hotmail.com (Amit)
Date: 16 Jan 2003 05:57:45 -0800
Links: << >>  << T >>  << A >>
Hi,

 In the Virtex - II Pro Architecture the WG1 to WG4 are write address
inputs when the LUT is used as a dual port RAM. The function of read
address inputs is provided by A1 to A4. If you will notice that
besides WG1 to WG4, WF1 to WF4 also provide the same functionality.

Regards,
Amit

Kuan Zhou <zhouk@rpi.edu> wrote in message news:<Pine.SOL.3.96.1030116003702.14675B-100000@vcmr-86.server.rpi.edu>...
> Hi,
>    I looked at Virtex II pro architecture.What are the functions
> of WG4, WG3, WG2 and WG1?I noticed there are 8 inputs to each LUT.
> Are they forming a 2^8 by 1 LUT tables or two 16 by 1 LUTs indivisually?
> 
>    Thank you very much!
> 
> sincerely
> -------------
> Kuan Zhou
> ECSE department

Article: 51560
Subject: Re: Xilinx Constraint Problem
From: "Jock" <ian.mcneil@uk.thalesgroup.com>
Date: Thu, 16 Jan 2003 14:50:35 -0000
Links: << >>  << T >>  << A >>

"Nicolas Matringe" <nicolas.matringe@ipricot.com> wrote in message
news:3E26B10E.94E42CF8@ipricot.com...
> Jock wrote:
> >
> > This used to be ok until I reloaded the design on another PC, but now I
am
> > getting the following error under P&R using: V4.1i of Xilinx ISE
> >
> > "ERROR:MapLib:93 - Illegal LOC on symbol "VCO_70MZ" (pad
signal=VCO_70MZ)
> > or BUFGP symbol "VCO_70MZ_ibuf" (output signal=VCO_70MZ_int), IPAD-IBUFG
> > should only be LOCed to GCLKIOB site."
> >
> > In my design I haven't specified that VCO_70MZ should be through a BUFG.
I
> > am using HDL designer and Leospec for my source code.
> >
> > 1. Where does ISE get the assumption that this is through a clock
buffer?
> > 2. How do I fix it without changing the LOC.?
>
> Hi
> LeoSpec automatically inserted the IBUFG because this signal must be used
as a
> clock in your design. Just disable the "Add clock buffer" option in
LeoSpec and
> resynthesize your design.
> Anyway, using a GCLKIOB site for your clock input would be a good idea...
>
> Nicolas

I agree, but as the PCBs are already laid out, I'm not allowed to change the
Pins.
Anyway I disabled the "add clock buffer" (set insert_global_bufs FALSE in
TCL-talk) but I'm still getting the same error, so now I'm rather baffled.



Article: 51561
Subject: Re: 200K gates FPGA for GPU
From: "Jan Gray" <jsgray@acm.org>
Date: Thu, 16 Jan 2003 07:00:16 -0800
Links: << >>  << T >>  << A >>
This isn't the answer you want, but since you can implement a C programmable
soft core in 10-20% of a 200K gate FPGA, you can run several software
rendering pipelines in parallel in such a device.

Or you can use one soft processor to absorb all the setup and management
aspects of the renderer and use the remaining 80-90% of the FPGA for the
rendering pipeline.

(I don't know whether (or if not, why not) synthesis tools (like Celoxica)
could exploit a soft processor core for absorbing RELATIVELY lower speed
setup and management code, but it seems to me a good idea -- sometimes in
the lower-performance-requirement parts of a design, it is profitable to
trade off speed for area (trade a soft CPU core and instructions in a block
RAM to save a sea of raw random logic gates.  That way, every HLL design
would fit in an XC2S50 plus external RAM -- and then if you specify an FPGA
10X or 100X larger the synthesizer could "automatically" move more and more
of the inner loop datapaths into gates.)

I don't know about the Celoxica FP library, but traditionally FP is
expensive in FPGAs (http://www.fpgacpu.org/usenet/fp.html).

If your 3D rendering pipeline is very roughly

modeling
    lighting and transforms
        coordinate transforms and clipping
            triangles/quadrilaterals setup
                span rendering
                    shading, texturing, and Z-buffer check

Then the last 3-4 stages, the data intensive ones, much in the integer
domain, can readily be done in an FPGA.  See for example
http://www.fpgacpu.org/usenet/render.html, but note the date and the target
FPGA (3K gates).  These days I would recommend rendering in bands or tiles
and keeping the Z-buffer for the band/tile in block RAM.  Also, low res
textures can probably fit in a block RAM texture store / texture cache.

Jan Gray, Gray Research LLC



Article: 51562
Subject: Re: 200K gates FPGA for GPU
From: Ray Andraka <ray@andraka.com>
Date: Thu, 16 Jan 2003 15:13:46 GMT
Links: << >>  << T >>  << A >>
Depends on how clever you get with the design, and at what
speed you need to operate.  First suggestion would be to
look at fixed point, and be very careful about how you
describe the design in Celoxica or you may find it very
difficult to get into a 200K marketing gate part.

tsao wrote:

> I just want to make a small demonstration, there is no
> input( no API interface), vertex data are generated
> in the fpga, and there will be a small texture defined
> as rom in the fpga.
>
> I'm using the RC100 board with HandleC. Celoxica has a
> floating point library for HandleC which I'm using.
>
> Thanks
>
> "tsao" <feng_1955@no_spam_ybb.ne.jp> wrote in message
> news:b06cvm$21nr$2@news.ecc.u-tokyo.ac.jp...
> > How far can I go to implement a 3D vertex processing
> > pipeline on a 200K gates fpga?
> >

--
--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: 51563
Subject: Re: How to add pins in ISE 4.2
From: Kuan Zhou <zhouk@rpi.edu>
Date: Thu, 16 Jan 2003 10:29:46 -0500
Links: << >>  << T >>  << A >>
Hi,
   I have solved it.But the strange thing is: when I add a pin named A1 in
the schematic design,the pin is not shown as A1 in the FPGA editor.The
name is changed to xlxn_2 or something similar.Do you have any way to
solve it?

   Thank you very much!

sincerely
-------------
Kuan Zhou
ECSE department


On 16 Jan 2003, Amit wrote:

> Hi Kuan,
> 
>  Which schematic tool are using in the ISE 4.2. For e.g. is it the
> FPGA editor, etc..
> 
> Regards
> Amit
> 
> Kuan Zhou <zhouk@rpi.edu> wrote in message news:<Pine.SOL.3.96.1030114211435.25313A-100000@vcmr-86.server.rpi.edu>...
> > Hi,
> >    I am using ISE 4.2 student version.But I can not find output pad in the 
> > schematic tools.Does any one know how to add pins in the schematic design?
> > The help says you can find "add pins" from the Add menu,but I can not find
> > it.
> > 
> >    Thank you very much!
> > 
> > sincerely
> > -------------
> > Kuan Zhou
> > ECSE department
> 
> 


Article: 51564
Subject: Re: HSPICE simulator
From: Muzaffer Kal <kal@dspia.com>
Date: Thu, 16 Jan 2003 15:36:56 GMT
Links: << >>  << T >>  << A >>
On Thu, 16 Jan 2003 14:40:54 +0530, "Skillwood"
<skillwoodNOSPAM@hotmail.com> wrote:

>Hi,
>Is there any free HSPICE simulator available in the Web?
>
>Thanks
>Skillie
>

There are many free SPICE simulators available but HSPICE is a
commercial, rather expensive implementation of SPICE.
You may want to check out this link
http://www.repairfaq.org/ELE/F_Free_Spice.html


Muzaffer Kal

http://www.dspia.com
ASIC/FPGA design/verification consulting specializing in DSP algorithm implementations

Article: 51565
Subject: Re: 200K gates FPGA for GPU
From: "tsao" <feng_1955@no_spam_ybb.ne.jp>
Date: Fri, 17 Jan 2003 00:58:49 +0900
Links: << >>  << T >>  << A >>
Thanks,

tomorrow I'll bring my code to school
to compile it using DK1 and see if it fits, and if everything go
well, I'll post my Handle C source code somewhere.

"Jan Gray" <jsgray@acm.org> wrote in message
news:b06hf4$she$1@slb2.atl.mindspring.net...
> This isn't the answer you want, but since you can implement a C
programmable
> soft core in 10-20% of a 200K gate FPGA, you can run several software
> rendering pipelines in parallel in such a device.

I'm writing a Hardware rendering pipeline including transform&lighting,
texture mapping. Most of the operation is done in floating point.
There will be like 20+ floating point multipliers in one pipeline.

> Or you can use one soft processor to absorb all the setup and management
> aspects of the renderer and use the remaining 80-90% of the FPGA for the
> rendering pipeline.
>
> (I don't know whether (or if not, why not) synthesis tools (like Celoxica)
> could exploit a soft processor core for absorbing RELATIVELY lower speed
> setup and management code, but it seems to me a good idea -- sometimes in
> the lower-performance-requirement parts of a design, it is profitable to
> trade off speed for area (trade a soft CPU core and instructions in a
block
> RAM to save a sea of raw random logic gates.  That way, every HLL design
> would fit in an XC2S50 plus external RAM -- and then if you specify an
FPGA
> 10X or 100X larger the synthesizer could "automatically" move more and
more
> of the inner loop datapaths into gates.)
>
> I don't know about the Celoxica FP library, but traditionally FP is
> expensive in FPGAs (http://www.fpgacpu.org/usenet/fp.html).

Will it be less expensive with soft core? How much?

> If your 3D rendering pipeline is very roughly
>
> modeling
>     lighting and transforms
>         coordinate transforms and clipping
>             triangles/quadrilaterals setup
>                 span rendering
>                     shading, texturing, and Z-buffer check
>
> Then the last 3-4 stages, the data intensive ones, much in the integer
> domain, can readily be done in an FPGA.  See for example

Well, I thought those last stages still require floating point,
like zbuffer and shading(color interpolation), and texture coordinates
transforms. Anyway I'll see.

> http://www.fpgacpu.org/usenet/render.html, but note the date and the
target
> FPGA (3K gates).  These days I would recommend rendering in bands or tiles
> and keeping the Z-buffer for the band/tile in block RAM.  Also, low res
> textures can probably fit in a block RAM texture store / texture cache.
>
> Jan Gray, Gray Research LLC
>
>


Article: 51566
Subject: Multiple FPGA-boards integration issues
From: prashantj@usa.net (Prashant)
Date: 16 Jan 2003 08:13:42 -0800
Links: << >>  << T >>  << A >>
Hi,

I have an FPGA board from Altera that I use for my prototyping needs.
The board has a single FPGA on it and an oscillator for 40MHz. I have
to integrate this board with another board (type of second board
unknown as yet) and some issues with such an integration just hit my
head. There also may be issues I haven't thought of as yet. Guessed
this may be a question to ask people for advice.

1. Since the FPGA needs to work @ 40 MHz, can I get the same speeds on
the board. What sort of speeds can be expected from data transfers
using board interconnects between the two boards in question ?
Obviously, if it was slower than the 40MHz requirement I have, the
integration between the two boards would be impossible. But I haven't
seen a mention of the board speeds in the data sheet of the board.
This is probably a very common issue for a lot of prototyping that
goes on in the industry. Any ideas ?

2. Clock syncronization between the two boards is another issue. I can
think of one way to do it. Use a pll in one FPGA device and take an
output of the clock from this FPGA (FPGA 1). Supply this output clock
of FPGA 1 as the input clock to FPGA 2 on the second board. Would this
work and if so, Is this the right way ? What other ways would be used
if any ? Which would be more efficient in terms of clock skew ?

3. What design methodology would apply to integration of more than 2
boards ? My guess is it would be similar to integration of 2 boards.

4. Is it possible to integrate a board with a Xilinx device to a board
with an Altera device ?

Hoping to receive advice soon. 

Thanks,
Prashant

Article: 51567
Subject: Support for older Virtex
From: "Langmann" <dlang89@hotmail.com>
Date: Thu, 16 Jan 2003 11:48:07 -0500
Links: << >>  << T >>  << A >>
Hi,

I was under the impression (from a previous post) that support would be
available for older devices (such as the XCV50PQ240, for example) in the
free or low cost software that Xilinx provides on the Web. From what I see
in ISE 5.1 this is not the case.

Does anyone have any information on this?

Thanks,
David




Article: 51568
Subject: Re: Schematic design approach compared to VHDL entry approach
From: "Austin Franklin" <austin@da98rkroom.com>
Date: Thu, 16 Jan 2003 13:05:25 -0500
Links: << >>  << T >>  << A >>

"Eric Smith" <eric-no-spam-for-me@brouhaha.com> wrote in message
news:qhd6mxoc6p.fsf@ruckus.brouhaha.com...
> "Austin Franklin" <austin@da98rkroom.com> writes:
> > I don't want to run the tools and play guessing games with what the tool
is
> > going to output.  It should be documented, so when I code, I KNOW what
the
> > hardware will be.
>
> The tool doesn't always output the same thing for a given construct.

And that can be a problem.  Not only that, but if you change one minor
thing, or have a rev change of the tools, it can screw up what used to work
fine...

> and would almost always be out of date.

Not if it was adhered to.

> Have you seen such a manual for a C compiler?

Er, yes.

> If you care about what's generated, you should look at the reports
produced
> by the synthesizer.  That will tell you what you want to know.

That's not engineering, it's guessing.  I am not into "guess what the
synthesis tool is going to do now", it's a waste of time.

Austin



Article: 51569
Subject: Re: quality of software tools in general
From: rickman <spamgoeshere4@yahoo.com>
Date: Thu, 16 Jan 2003 13:06:29 -0500
Links: << >>  << T >>  << A >>
Matt wrote:
> 
> Hi,
> 
> I'm not even a newbie with respect to fpgas (I spend most of my time on
> supercomputers) but am curious as to how good the tools are for
> developing fpgas. For example, if someone wrote a fixed point fft in C
> (or vhdl using the C-like programming part) and fed it to current fpga
> tools, how would the output compare to someone with several years of
> experience doing whatever was needed to make it run as fast as possible?
> Would it be half as fast? 1/100th? worse? And where are the worst
> problems? Is it vhdl compilation? place and route? Something else?
> 
> Matt

Sounds to me like you are a software person rather than a hardware
designer, right?  When you write HDL descriptions of hardware, you don't
write the code thinking of the problem and let the tool generate its own
hardware to solve it like is often done in software development. 
Although this works pretty well with most compilers, HDL synthesizers
are not as well developed.  Normally a HDL developer will write his code
thinking of the solution and use the HDL to describe what his solution
should look like.  This is a very different process.  

If you write HDL thinking of your solution then the tools work pretty
well.  In that case your example above is not really practical since an
FFT written in C would not translate well at all into an HDL as normally
used.  

-- 

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: 51570
Subject: Re: Xilinx Constraint Problem
From: rickman <spamgoeshere4@yahoo.com>
Date: Thu, 16 Jan 2003 13:15:47 -0500
Links: << >>  << T >>  << A >>
Jock wrote:
> 
> I agree, but as the PCBs are already laid out, I'm not allowed to change the
> Pins.
> Anyway I disabled the "add clock buffer" (set insert_global_bufs FALSE in
> TCL-talk) but I'm still getting the same error, so now I'm rather baffled.

Maybe I don't understand the issue correctly.  Are you saying that you
have a clock signal in your design that drives the clock inputs on FFs,
but you don't want to run it through the global clock buffer because
someone has given you a pinout that puts the clock on a different pin?  

This is not a good situation.  If you don't use the global clock routing
it will use the general routing.  You can, and most likely will, have
problems with clock skew where a signal that is changing because of the
clock will reach another FF before the clock does so that the FF will
latch the wrong value.  

I don't know why you are constrained to this pinout, but you should
think very hard about using a global clock buffer.  Unless this clock
drives a very small section of the FPGA, I don't think I would try to
use general routing for a clock.  

-- 

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: 51571
Subject: Re: Schematic design approach compared to VHDL entry approach
From: nweaver@ribbit.CS.Berkeley.EDU (Nicholas C. Weaver)
Date: Thu, 16 Jan 2003 18:25:14 +0000 (UTC)
Links: << >>  << T >>  << A >>
In article <qhd6mxoc6p.fsf@ruckus.brouhaha.com>,
Eric Smith  <eric-no-spam-for-me@brouhaha.com> wrote:
>Have you seen such a manual for a C compiler?  I haven't.  And that's an
>easier problem, because there are few constraints on the compiler output.

Yet also far less important.  C is inherantly sequential semantics,
and if you just do a literal translation you actually end up being
OK-good-enough on a modern processor.

EG, compare lcc (VERY simple and dumb) vs gcc -04, and although gcc
wins significantly, it's not a MASSIVE difference.
-- 
Nicholas C. Weaver                                 nweaver@cs.berkeley.edu

Article: 51572
Subject: Re: SChematic design approach compared to VHDL entry approach
From: "Austin Franklin" <austin@da98rkroom.com>
Date: Thu, 16 Jan 2003 13:48:46 -0500
Links: << >>  << T >>  << A >>
> SW engineers ...SW engineers ....SW engineers ....

You are making a GROSS assumption here, that people who write software ARE
in fact engineers.  Most are simply NOT.  In fact, I would say very few are.

Austin



Article: 51573
Subject: Re: Xilinx Constraint Problem
From: "Falk Brunner" <Falk.Brunner@gmx.de>
Date: Thu, 16 Jan 2003 19:59:19 +0100
Links: << >>  << T >>  << A >>
"rickman" <spamgoeshere4@yahoo.com> schrieb im Newsbeitrag
news:3E26F6D3.18D62D71@yahoo.com...

Agree.

A clock should only be routed on a global clock net. Yes, you can also use
local routing, but this is the high art for the guys that know what they are
doing.
But In this case, the is a possibility to workaround this problem.
Instanciate a IBUF (normal input buffer) and a BUFG (global clock buffer).
This way, you can get your clock signal into you FPGA via a normal IO pin
and route it internaly to the global clock buffer. The only thing you will
not ave compared to the dedicated clock input is, the defined timing
relation between the clock on the input pin and the clock on your global
clock net, means, the skew between them is more of less random within some
limits. But this wont be a problem if you have no control line comming into
you FPGA with a fixed timing relation to your clock.

--
MfG
Falk





Article: 51574
Subject: Re: SChematic design approach compared to VHDL entry approach
From: nweaver@ribbit.CS.Berkeley.EDU (Nicholas C. Weaver)
Date: Thu, 16 Jan 2003 19:04:28 +0000 (UTC)
Links: << >>  << T >>  << A >>
In article <v2dvkemrfapa1b@corp.supernews.com>,
Austin Franklin <austin@da98rkroom.com> wrote:
>> SW engineers ...SW engineers ....SW engineers ....
>
>You are making a GROSS assumption here, that people who write software ARE
>in fact engineers.  Most are simply NOT.  In fact, I would say very few are.

"If builders build buildings the way programmers write code, the first
woodpecker to come along would destroy civilization"
-- 
Nicholas C. Weaver                                 nweaver@cs.berkeley.edu



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