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 55050

Article: 55050
Subject: ISE5.2 XST design flow for Partial Reconfiguration
From: jean-philippe.delahaye@iuplo.univ-ubs.fr (delahaye)
Date: 25 Apr 2003 07:03:02 -0700
Links: << >>  << T >>  << A >>
Hello,

I try to do Partial Reconfiguration for virtexE using xapp290, with
XST,

But I have some problems with bus macro:

I don't really know, How and When, I need to integrate the Bus macro
in the design flow with XST.

I think, I well declare and instanciate the bus macro in my my
top.vhd:
-My busmacro declaration in top.vhd is:
component bm_4b
port(
	LI : in  std_logic_vector (3 downto 0);	
	LT : in  std_logic_vector (3 downto 0);	
	RI : in  std_logic_vector (3 downto 0);	
	RT : in  std_logic_vector (3 downto 0);
	O  : out std_logic_vector (3 downto 0)
	);
end component; 

-My bus macro intanciation in top.vhd is for example:
  BM_UPPER_HALFWORD_I : bm_4b port map (
	 LI(2)=>INT_MAP_I_L(6),
	 LI(1)=>INT_MAP_I_L(5),
	 LI(0)=>INT_MAP_I_L(4),
	 LI(3)=>INT_MAP_I_L(7),
	 ----------------
         LT(3) => GND_L,  -- "enable"  the left side
         LT(2) => GND_L,  
         LT(1) => GND_L, 
         LT(0) => GND_L,
	 ----------------
	 RI(3) => GND_R,  
	 RI(2) => GND_R,  
	 RI(1) => GND_R,	
	 RI(0) => GND_R,
	 --------------- 
	 RT(3) => VCC_R,  
         RT(2) => VCC_R,  
         RT(1) => VCC_R,  
         RT(0) => VCC_R, 
 	 ---------------
    O=>INT_MAP_I_R(7 downto 4)
	);


In the top.ucf I put manually the following declarations:

INST "bm_upper_halfword_i" LOC = TBUF_R16C9.*;

-Q:Is it correct?


So after synthetise top.vhd  with XST the top .vdh, I copy the top.ngc
and top.ucf in a directory implementation\top
If I also put the bm_4b.nmc in this directory and I try to start with
the first command of the modular flow i.e. : ngdbuild -modular initial
top.ngd
I have this error msg:
ERROR:NgdBuild:76 - File "..\Implementation\Top/bm_4b.nmc" cannot be
merged into block  "bm_upper_halfword_i" (TYPE="bm_4b")because one or
more pins on the block, including pin "LI<3>", were not found in the
file.  Please make sure that all pins on the instantiated component
match pins in the lower-level design block (irrespective of case).If
there are bussed pins on this block, make sure that the upper-level
and lower-level netlists use the same bus-naming convention.

If I don't put the bm_4b.nmc file in the directory I have no error but
in this case in which phase of the modular flow this file is use for
the merging and what is the command?

I have some others questions, I hope that help you to answer me if you
are always reading this long msg!:
Do I need to change somethings else in the bm_4b.nmc file  that the
conponent package reference?
Do I need to consider bus macro as a module, and run the modular
design flow exactly in the way as with my own modules

Thank you for your help,

JP

Article: 55051
Subject: ANN: bootable Spartan2 board with PC interface and CPU
From: "Peter Seng" <p.seng@seng.de>
Date: Fri, 25 Apr 2003 17:11:34 +0200
Links: << >>  << T >>  << A >>
SENG digitale Systeme GmbH is pleased to announce the availability of  the
self bootable FPGA based system "digital logic kernel - dlk51" with
integrated PC interface


What for:

- development platform
- rapid prototyping
- education


Features:

- PC parallel port interface for administration and data transfer (500
Kbytes/sec)
- self bootable FPGA design
- no additional programming tools or download cables, no pre-programmed
parts needed
- xc2s50 or xc2s100 Spartan2 FPGA
- xc9572xl CPLD, programmable via FPGA DLC5 emulation
- 8032 CPU
- RS-232 and i2C serial ports, 16 Kbit i2c EEprom
- 512 Kbytes parallel flash memory for 4 CPU programs (4x64 Kbytes) and 2
FPGA config files
- on board power supply, external AC or DC
- all 3V3 design
- size 80x100mm, signals available at 100mil, 96-pin connector DIN41612
- Xilinx DLC5 download cable emulation via FPGA
- windows administration program, including sources, driver and DLL
- demo programs, CPU and FPGA sources and unlimited free 8032 C compiler
included
- all sources available


For further information see:

http://www.seng.de



Article: 55052
Subject: Re: Xilinx has released SpartanIII
From: Austin Lesea <Austin.Lesea@xilinx.com>
Date: Fri, 25 Apr 2003 08:11:37 -0700
Links: << >>  << T >>  << A >>
Uwe,

Doesn't have DDR built in either.  Oh well, I guess their market doesn't
need 'at speed' SRAM interfaces.

Austin

Uwe Bonnes wrote:

> KB <khimbittle@cliftonremovesystems.com> wrote:
> : On Mon, 14 Apr 2003 16:59:06 -0400, Theron Hicks
> : <hicksthe@egr.msu.edu> wrote:
>
> :>Has anyone noticed that this part is available with LEGS?  It appears
> :>that someone at Xilinx was listening to the request for non-BGA parts.
> :>
>
> : Actually I was a little disappointed in this area. Only the XC3S50 /
> : 200 / 400 is available in the 208 pin pqfp .. the 2e took this package
> : up the 300 part so some improvement yes .. but the Cyclone EP1C12 is
> : available in a 240 pin pqfp ... 30+ more I/O pins, and the cyclone has
> : 12K registers , a bunch more than the new 400 part.  my 2'c   KB
>
> But I don't see on-chip termination for the Cyclone part. Or did I miss
> something?
>
> Bye
> --
> Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de
>
> Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
> --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------


Article: 55053
Subject: Re: Large adder placement / synthesis
From: "John_H" <johnhandwork@mail.com>
Date: Fri, 25 Apr 2003 15:34:12 GMT
Links: << >>  << T >>  << A >>
If the example you showed didn't include the synch or asynch load that would
be implemented in the flops' SR inputs, there could be reason for the
mispacking.  If the registers are simple FD primitives when they get to the
Xilinx tool, there should be no reason to split the adder apart.

The RLOCs can be specified for the registers that the adder feeds: out1 in
your example.  The carry chain is the more difficult part since your
synthesis tool probably has its own creative way of naming the adder chain.
If you determine the name of the least significant bit(s) of the adder, it's
often enough just to specify the rloc of the start of the chain and the rest
follow.  So - RLOC your registers and the start of your chain.

If there was a serious reason why the Xilinx tools couldn't cooperate with
the pleasant packing because of problems with shared resets or shared clock
enables or some other low level conflict, the tools will report that they
can't pack the items together and tell you why.  (or at least that's the
behavior with LOCs - probably also with RLOCs)

Good luck.


"Jake Janovetz" <jakespambox@yahoo.com> wrote in message
news:d6ad3144.0304241738.3690c5e5@posting.google.com...
> Hello-
>
> I have a large adder (48-bits to 64-bits) that I am implementing in a
> Spartan IIE using Verilog synthesis.  I assumed that the adder LUTs,
> carry logic, and resulting flip-flops would be placed in a column of
> CLBs but alas, they are not.  Instead, the carry logic is nice, but
> the other stuff is sort of scattered about.
>
> So, I tried to pull out the floorplanner and throw things around the
> way I think they should be, but the tool won't let me.  My questions
> are:
> - Why doesn't the placer do things correctly?  This seems like a
> no-brainer placement problem to me.  The carry chain alone provides a
> pretty hefty constraint.
> - Can the adders be forced to be implemented as an RPM without doing
> the whole coregen thing or building my own adder and rloc'ing it?
> - Is there some limitation that I'm missing that won't allow the LUTs
> to be stacked reasonably and in the same slice?
>
> Now, for the purposes of this email, I've simplified somethings, but I
> think justifiably so.  Namely, the adder is really:
>    always @(posedge clk) begin
>       out1 <= val + (sel ? out1 : out0);
>    end
>
> Where 'sel' is a mux select and val is a register.  The mux/adder
> should fit nicely in the LUT (and does).
>
>    Cheers,
>    Jake



Article: 55054
Subject: Re: Challenge: (n mod 3) in hardware???
From: "John_H" <johnhandwork@mail.com>
Date: Fri, 25 Apr 2003 15:36:20 GMT
Links: << >>  << T >>  << A >>
Dang!  Typo on line 739 of the case statement.

Distilling a problem to its essence will often produce the best results.
Though when we get too creative, ample comments become a requirement.

"nospam" <nospam@nospam.invalid> wrote in message
news:kgeiav8p95jerg36q6eb9o438ncq50ojgm@4ax.com...
> RISC_taker@alpenjodel.de (RISC  taker) wrote:
>
> >Hey, I need to calculate (n mod 3) in a Virtex-II design. n is a
> >10-bit unsigned number and 3 is a constant. This has to be done in the
> >same cycle (combinatorial!). Now what's a good way to implement that?
> >
> >I thought of a lookup table (distributed RAM) but this takes quite a
> >lot of space. Any better ideas? (Ray, the arithmetic guru? :-)
>
> A good way of implementing it?
>
> Write a 1024 case switch assigning the required output.
>
> If the solution is a simple combinatorial expression the tool will create
> it - no arithmetic guru required.
>
>



Article: 55055
Subject: Re: Boycott All Xilinx products untill they correct all ISE softwareerrors
From: "Michael Condon" <michael.condon@nrl.navy.mil>
Date: Fri, 25 Apr 2003 11:46:15 -0400
Links: << >>  << T >>  << A >>
I'm sorry to have to tell you this, but schematic entry for FPGA design is
dead.  VHDL is being taught at the undergrad level because the schools
realize this.  I would suggest that you learn VHDL or Verilog.  These are
two very powerful languages that make hardware design a lot easier and are
more powerful then schematic entry will ever be.  VHDL and Verilog allow for
the code to be portable accross operating platforms and simulator,
synthesis, and implementation software.  I along with many other hardware
engineers can already see the day when your boss doesn't hand you a Word or
PDF document for the specifications of a design, but instead will hand you a
VHDL or Verilog testbench file.  The testbench file will be able to test the
design for not only logic accuracy, but also timing specifications since
VHDL and Verilog files can be generated post implementation which contain
both gate and path delays associated with the netlist.  I'm sorry that you
are having trouble with the schematic software, but I imagine there will be
a day(soon) where it is removed from the software completely and is only an
option.  Good luck....


"eric - Mtl" <notervme@sympatico.ca> wrote in message
news:RvBoa.515$Zj2.58507@news20.bellglobal.com...
>
>
> rickman wrote:
> >
> >
> > I was a die hard schematic user too.  I felt that I had better control
> > over my design with schematic.  But then I worked with VHDL for awhile
> > and I realized the power.  It can be a bit of a PITA to really optimize
> > the hardware, but using schematic does not really assure you of getting
> > what you put on the page.  The tools optimize things sometimes since
> > they know more than you do :)
> >
> > But the transition was really confirmed for me when I started writing
> > test benches to verify my design.  I can generate a model of a bus or an
> > ADC or any other logic external to my design that I need to test it.
> > With the waveform editor I had to *plan* my simulation very
> > laboriously.  If anything changed, I would often have to redo large
> > parts.  With an HDL test bench the test bench interacts with your design
> > the same way the real board does.
> >
> >
> >
> >>If I had to rank quality and code stability for ECS, it would
> >>be very close to the bottom.
> >
> >
> > ...snip...
> >
> >
> >>I don't know how many Xilinx users actually use ECS and if peoples from
> >>the ECS development team ever read those NG posts, but I'm pretty sure
> >>other users too experience these inconveniences on a daily basis and
would
> >>appreciate to see them addressed as much as I do.
> >
> >
> > I am sure your many bug reports are valid and hopefully someone will
> > address them.  I did not read the details.  Did you report many of
> > these?  If they are not reported, they can't be fixed.  I know this
> > takes time, but at this point if you are vested in the tool, it will be
> > up to you to report the bugs.
> >
> > I don't know how many ECS users there still are, but I can tell they
> > must be real die hards.  I realized that HDL was the way to go when Ray
> > Andraka switched.  He designs hierarchical, blocked out, highly
> > floorplanned designs.  In the past he had built up a large library of
> > schematic elements that allowed him to build large DSP designs very
> > quickly complete with schematic specified floorplanning.  I know from
> > experience that this took a lot of effort to implement.  But once he was
> > forced by a contract to work with an HDL, he realized the labor savings
> > from working with code and once he started converting his symbol library
> > to a code library, I don't think he ever looked back.  Perhaps I should
> > not put words in his mouth, but this is what I have gotten from reading
> > his posts.
> >
> >
> >
> >>Also, since most new users start with schematics, pissing them off from
> >>day one with such a buggy software is probably not a wise thing to do.
> >
> >
> > That may have been true in times past, but I think newbies now start
> > with an HDL.  When I went to school, Fortran was still the only required
> > language in EE.  Now I don't think you can earn a BSEE without knowing
> > some HDL.  I have met HDL designers who work in HDL without even drawing
> > a block diagram of what they want.  This is very alien to me but it
> > seems to be the norm now.  I think the time of schematic has passed.
> >
>
>
> Hi,
>
> thanks for your answer, I hear your arguments to switch from schematic
> to HDL. As you acknowledge, transition is long and painful until you
> reach the point where you can achieve optimized designs approaching
> the gate count you get using schematics. after going through this you
> are certainly right that the productivity is better.
>
> But why is it so ? because of the HDL's intrinsic qualities in part,
> but certainly a lot too because schematic entry is so much crippled
> by the tool ...
>
> Right now, I'm starting to use small VHDL blocks (Such as XAPP223 UART)
> I get what it does, but investing the time that would be needed to
> start a product from scratch using HDL is another story.
>
> As you mention, I see how HDLs are far better to generate test benches,
> but when it comes to documentation, and having other peoples understand
> what you did, a picture is still worth a thousand words ...
>
> I think it's at least a bit premature to announce the death of schematics,
> mostly when text based traditional programming language are going the
other
> way around toward schematic representation to cope with complexity.
> A well known product in this area is Rational Rose (now owned by IBM)
> http://www.rational.com/products/rose/index.jsp
>
> ******
>
> However, my message was not about schematic entry. It was about ECS
> being a very sub standard, badly designed & buggy software. Xilinx
> knows it and does not fix it.
>
> Such a widening quality gap between the hardware and the dev. soft
> should be a bigger concern for the folks at Xilinx ...
>
> Filling a report ? why bother ? Countless others did it before me without
> any result. The infamous "WinApp c:570" error (software crash when moving
> stuff around or deleting nets) was supposed to be solved in 3.x, then 4.0
> then 4.1 and is still here in 4.2 ...
>
>
http://support.xilinx.com/xlnx/xil_ans_display.jsp?iLanguageID=1&iCountryID=
1&getPagePath=13501
>
http://support.xilinx.com/xlnx/xil_ans_display.jsp?iLanguageID=1&iCountryID=
1&getPagePath=14774
>
> Needless to say, the "fix" does not fix anything ...
>
> Maybe I should try 5.2, but it's so buggy and my confidence level is
> so low that I'm not willing to do it in the middle of the design,
> since I don't want to end up locked by a "to be fixed in next release"
> bug and with files I can't edit anymore with the 4.2 I'm using now.
>
> That's the kind of trouble I could accept for a non critical piece of
> shareware, but certainly not from Xilinx.
>
> ******
>
> Forcing the switch to HDL by making the schematic tool barely usable
> is a bit like poisoning water supply to increase bottled water sales.
>
> It might finally work (including for me), but I hate it, and I hate being
> forced to waste months becoming proficient in another way to do very same
> things I'm already doing now using a tried, tested and true method that's
> now barely usable because the tool is screwed !
>
> Believe me, using such a buggy tool on a daily basis is an incredibly
> frustrating experience !
>
> Eric.
>



Article: 55056
Subject: Xilinx of Linux HOWTO has been updated
From: "B. Joshua Rosen" <bjrosen@polybus.com>
Date: Fri, 25 Apr 2003 12:03:14 -0400
Links: << >>  << T >>  << A >>
I've finally gotten around to updating the Xilinx on Linux HOWTO page.
It's available at,

http://www.polybus.com/xilinx_on_linux.html

Article: 55057
Subject: Re: WANTED ALTERA CYCLONE PCI BOARD
From: "Powermos" <flatiron@libero.it>
Date: Fri, 25 Apr 2003 16:14:23 GMT
Links: << >>  << T >>  << A >>
Hi,

you can download for free a PCI Core suitable for Cyclone FPGA. The core has
a built in time-bomb, for
commerciale use you must purchase the core.

Bye
Powermos

--
----------------------------------------------------
Ama il tuo mestiere con passione
E' il significato della tua vita
Auguste Rodin (1840-1917)
"Paul Leventis" <paul.leventis@utoronto.ca> ha scritto nel messaggio
news:SY8qa.141485$BQi.97105@news04.bloor.is.net.cable.rogers.com...
> Hi Mike,
>
> One product Altera offers is the PCI32 Nios Add-on Dev Kit.  This is a
board
> that you hook-up to any Nios dev kit (including the Cyclone version), and
> you can plug it into a PCI32 slot.  It provides a PCI interface to your
Nios
> dev board, an API, etc.  I don't know anything about it besides what's on
> our web site.
>
> You can read about it here:
>
> http://www.altera.com/products/devkits/altera/kit-dev_nios_pci32.html
>
> - Paul
>
> "mike" <mxv@yahoo.com> wrote in message
> news:8ea508fe.0304242036.224f0c6e@posting.google.com...
> > I've searched the web with no luck for a PCI development board with
> > using an Altera Cyclone part. Probably because it's a new part, but if
> > anyone knows where I can find one, please post a link. It must be
> > Cylone, and it can be a PCI board or PMC module.
> >
> > Thanks in advance.
>
>



Article: 55058
Subject: Re: Complex FIR in FPGA
From: "Powermos" <flatiron@libero.it>
Date: Fri, 25 Apr 2003 16:20:10 GMT
Links: << >>  << T >>  << A >>
Hy, I'm a newby into this ng,

I'm interesting to built a simple FIR filter into Spartan/XC5202 FPGA, a
simple filter into BF range,
only purpouse is to understand of digital filter. Can someone help me with
this task?
The filter can be a pass-band into the audio range, from 0 to 20 kHz.

Thanks in advance for your help
Powermos

--
----------------------------------------------------
Ama il tuo mestiere con passione
E' il significato della tua vita
Auguste Rodin (1840-1917)
"Ray Andraka" <ray@andraka.com> ha scritto nel messaggio
news:3EA4CE10.2C3EA066@andraka.com...
> I posted a reply for this filter in comp.dsp suggesting a DA approach.
>
> Arthur Herbert wrote:
>
> > rAinStorms wrote:
> > > You could pre-add to improve processing bandwidth: (Zx + Zn-x).bx
> > > This means 128 Complex multiplies and adds every 30MHz ... about 4Gigs
> > > Performance...
> >
> > The FIR to be designed has no symetric coefficients (if this is what you
> > suggest)
> >
> > >
> > > I would say that this one is challenging :-)
> > >
> > > Not sure if you will pull it off even with a big one.
> > >
> > > I would propose you use a big Stratix - with its inbuilt MACs you
might have
> > > a show.
> >
> > Might be. Do you think that muxing could help spare some CELLs, i mean
> > having a set of 32 Multiplier blocs each processing 8 times 30MHz would
> > 'only' use 2 big stratix... innit ?
> >
> > > Dynamic update ... Are you saying you have to be able to update
coefficients
> > > while filter running? Dont forget the associated distortion if this
takes
> > > longer than a sample to do.
> >
> > Yes. Do you have some references about that sort of distorsion ?
> >
> > > All memories can be configured as dual port ... if you dont need
update in
> > > one sample then its easy.
> > > If you do ... then there are lots of memory ESBs on the Stratix so you
can
> > > mux them - providing a way to update all coefficients at the same
time. This
> > > would slow the whole thing down due to muxes.
> > >
> > Thanks a lot for your advices,
> > Arthur ;)
> > >
> > > "Arthur Herbert" <herbert.arthur@caramail.com> wrote in message
> > > news:3EA3B77A.1020305@caramail.com...
> > >
> > >>Hi -
> > >>
> > >>I would like to implement a 256 tap complex FIR filter.
> > >>It should run at 30MHz and latency should be lower than 200ns...
> > >>Moreover, the coefficients should be updatable 'live', ie, without
> > >>interrupting the filtering process...
> > >>Seems to be quite a hard task !
> > >>Does anyone have an idea of FPGA implementation ?
> > >>What kind of circuit should be used ?
> > >>How many CLB/LE would it take ?
> > >>Thanks in advance
> > >>
> > >>Arthur
> > >>
> > >
> > >
> > >
>
> --
> --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: 55059
Subject: Re: Cyclone power up problem - Summery
From: "Powermos" <flatiron@libero.it>
Date: Fri, 25 Apr 2003 16:24:16 GMT
Links: << >>  << T >>  << A >>
Can you give me major information about this?

I'm currently working with Spartan device, throught the compiler option I
can configure the device in fast or slow mode.
Current consuption must be less into slow mode, it's right?

Best regards
Powermos

--
----------------------------------------------------
Ama il tuo mestiere con passione
E' il significato della tua vita
Auguste Rodin (1840-1917)
"Austin Lesea" <Austin.Lesea@xilinx.com> ha scritto nel messaggio
news:3EA4165D.7D31410B@xilinx.com...
> Lost,
>
> All FPGAs don't have this problem.  For example, Virtex II, Virtex II Pro,
> and Spartan III don't have this problem.
>
> "This problem" was something that had to be fixed by IC design, and
> avoided.  So it is not a natural result of an SRAM based FPGA.
>
> Austin
>
> LostSignal wrote:
>
> > > Does Altera officially recognize the Power On Surge problem ?
> > > I didn't find any references to this problem in Altera's datasheets or
> > > App. notes. Their datasheets don't specify start up current as well.
> > > One of our designs sometimes has strange power-up problems at the low
> > > temperature. We never attributed this problems to the FPGA. Actually I
> > > didn't hear about this problem before (thank you, Martin). Now I'm
> > > starting to suspect that the problem is related to FPGA. The design is
> > > based on ACEX 1K100 device. Where can I find Power On Current profile
> > > for this device ?
> >
> > Apparently ALL SRAM based FPGAs experience this problem to some
> > degree. At the startup the configuration SRAM is in unknown state and
> > that causes large current surge that must be satisfied in order for
> > FPGA to configure properly. AFAIK the differences between Xilinx and
> > Altera in this regard are:
> > 1. Xilinx publicly acknowleged this problem some time ago has several
> > articles on it. I have not seen much from Altera (correct me if I am
> > wrong).
> > 2. The rumor is Altera has a somewhat smaller surge and people have
> > less trouble with it. Dunno how true it is though. I've heard from an
> > Altera guy that a really large Altera part can draw 2.5 A. The maximum
> > current specified for Xilinx is 2 A at low temperature. Go figure..
> >
> > Lost Signal
>



Article: 55060
Subject: Re: Advice on FPGA IIR Filter
From: "Powermos" <flatiron@libero.it>
Date: Fri, 25 Apr 2003 16:31:05 GMT
Links: << >>  << T >>  << A >>
Hi,

I'm new into this ng.

I've interest into digital filter, my present work is with FPGA like Spartan
and XC5202 family. Can you give me an example of digital filter
implementation?
I've no material about this, only knowledge is about my control theory
course and is about digitizing the analog filter throught the Z-transform
technique. I'm very gratefully if you can help me.

Thanks in advance and best regards

Fabio Filippa

--
----------------------------------------------------
Ama il tuo mestiere con passione
E' il significato della tua vita
Auguste Rodin (1840-1917)
"Philippe Molson" <philippe_molson@yahoo.com> ha scritto nel messaggio
news:e1558d23.0304171903.5a14ad71@posting.google.com...
> Hi,
>
> Some band-pass IIR filters require large precision. The Fixed-point
> analysis depends heavely on the IIR characteristics.
>
> Altera has developed several tools to help you to design fixed-point
> IIR filters.
>
> You can probably start by downloading the Altera IIR-Compiler
> http://www.altera.com/products/ip/dsp/filtering/m-alt-iircompiler.html
>
> This is an IP. With the evaluation version, you start from the
> floating-point IIR coefficients and use the built-in floating to
> fixed-point conversion analysis tools. This help you to determine
> which bit can be truncated in both feedback and feedforward data-path.
> The IIR-compiler is interactif and displays dynamically the filter
> response in the zero-pole or frequency or time domain, based on
> parameters such as bit-width selection/truncation (among others)
>
> In addition, in this tool  you can evaluate various IIR structures,
> such as direct form II, biquad cascaded or biquad parallel. You
> probably will find out that the fixed-point maths vary from one
> structure to another. You can also trade-off FPGA multiplier/adder
> style (parallel distributed arithmetic, MAC based).
>
> If you are familiar with Matlab Simulink, another option consists of
> using the DSP Builder, which is a Simulink plug-in and can be
> downloaded from :
>
>
http://www.altera.com/products/software/system/products/dsp/dsp-builder.html
>
> From the Simulink cockpit , you can use the IIR compiler, or build the
> IIR structure with the DSP Builder primitives (Multiply, Add, LUT ...)
> optimized for Cyclone or Stratix. The DSP Builder-Simulink flow gives
> you enhanced sink and source block for system analysis, and this could
> be very usefull in this case when you need to analyze complex aspects
> of fixed-point IIR design such as stability.
>
> Building the filter with DSP Builder primitive may take longer than
> using the IIR-Compiler, however it may allow you to explore FPGA
> architectures implementation which are not yet present in the
> IIR-Compiler such as multi-bit serial.
>
> I hope that this will help you to build efficient IIR filters for
> Cyclone device.
>
>
> Philippe Molson
> Altera Corporation
>
>
> "gallenm" <gallenm@ic24.net> wrote in message
news:<v9tmpdn101mb60@corp.supernews.com>...
> > Hi,
> > Just adding a plug for ONEoverT digital filter designer. It will
> > automatically produce
> > synthesizable VHDL for IIRs and FIRs. Very cheap, the demo can be
downloaded
> > from
> > the website
> > www.tyder.com
> >
> > If you download the case study, it will show you the implemention of an
IIR
> > onto a Spartan
> > FPGA.
> >
> > Yours
> > Alan Mc Kitterick
> > www.tyder.com
> >
> > "Pramod" <pramod@procsys.com> wrote in message
> > news:a7c0720d.0304152101.581c85be@posting.google.com...
> > > Hi All,
> > > I am new to this group and also to the field of FPGA based design.
> > > I have some doubts and issues which I feel will be easy for you guys
> > > to answer.
> > > 1. For a 4 pole IIR Filter in FPGA (targeted device EP1C6), I have a
> > > spec of 24 bit wide data input and
> > > 32 bit wide coeff (dynamic) inputs. So, the multiplied results should
> > > ideally have
> > > 56 bits width. Are these widths practically relevant for a 4 pole
> > > filter
> > > or can we get an affordable precision with rounding to lower sizes?
> > > If so, can anyone suggest a standard procedure for
> > > rounding the  results with lowest error and without causing the output
> > > to become unstable?
> > > 2. Another thing I would like to get some advice is, if I go with the
> > > 24 X 36 busses,
> > > since I have to implement a number of such filters in a single device,
> > > the bit-parallel implementation will take up huge resources.
> > > The digit serial approach using (either small multiplier or LUT
> > > method)
> > > also will end up in huge resources due to big number of partial
> > > products and sums involved.
> > > If anyone can suggest any alternate method it will be of great help to
> > > me.
> > > 3. On another front, in a timing simulation scenario I am using
> > > Quartus II .vo output and ModelSIM PE. My code has
> > > a ROM (ALTSYNCRAM megafunction used to generate this). I found some
> > > differences in the
> > > readout data during timing simulation between using .MIF format file
> > > and .HEX format file for initializing ROM
> > > eventhough the QII displayed same contents in the memory editor.
> > > Has anyone ever faced any such issues?
> > > Hoping to get some valuable leads on these..
> > > Thanks in advance,
> > > Pramod
>



Article: 55061
Subject: Re: Boycott All Xilinx products untill they correct all ISE softwareerrors
From: Mike Treseler <mike.treseler@flukenetworks.com>
Date: Fri, 25 Apr 2003 09:34:16 -0700
Links: << >>  << T >>  << A >>
Michael Condon wrote:

 > . . . I along with many other hardware
> engineers can already see the day when your boss doesn't hand you a Word or
> PDF document for the specifications of a design, but instead will hand you a
> VHDL or Verilog testbench file.

Wow.
The future is bright.
In 2003, I'm lucky to get 3 bullet items on a powerpoint slide :)

   -- Mike Treseler


Article: 55062
Subject: Re: Challenge: (n mod 3) in hardware???
From: hmurray@suespammers.org (Hal Murray)
Date: Fri, 25 Apr 2003 16:36:54 -0000
Links: << >>  << T >>  << A >>

>Dang!  Typo on line 739 of the case statement.
>
>Distilling a problem to its essence will often produce the best results.
>Though when we get too creative, ample comments become a requirement.

Write a program to write the body of the code for the case statement.

It's just a big table - the same bits you would need if
you did the RAM approach.

-- 
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: 55063
Subject: Re: Xilinx has released SpartanIII
From: "John_H" <johnhandwork@mail.com>
Date: Fri, 25 Apr 2003 16:51:19 GMT
Links: << >>  << T >>  << A >>
Austin - are you saying the Cylcone parts don't have DDR?
So the dedicated DQS elements are there for... what purpose?

The Cyclone parts claim support for PC2100 speed DDR (133MHz clock).  The
IOBs may only have 3 registers as opposed to the 6 in the Spartan3, but DDR
can work.

The Spartan3 can deliver much higher speed and higher performance because of
the tight timing allowed by the DDR IOB configuration but care still has to
be taken with a "global" DQS timing methodology.

My personal opinion:  Spartan3 is much better than Cyclone for DDR but the
DQS implementation is cleaner on the Cyclones allowing for layout skew of
the data groups.



"Austin Lesea" <Austin.Lesea@xilinx.com> wrote in message
news:3EA95029.8C917454@xilinx.com...
> Uwe,
>
> Doesn't have DDR built in either.  Oh well, I guess their market doesn't
> need 'at speed' SRAM interfaces.
>
> Austin
>
> Uwe Bonnes wrote:
>
> > KB <khimbittle@cliftonremovesystems.com> wrote:
> > : On Mon, 14 Apr 2003 16:59:06 -0400, Theron Hicks
> > : <hicksthe@egr.msu.edu> wrote:
> >
> > :>Has anyone noticed that this part is available with LEGS?  It appears
> > :>that someone at Xilinx was listening to the request for non-BGA parts.
> > :>
> >
> > : Actually I was a little disappointed in this area. Only the XC3S50 /
> > : 200 / 400 is available in the 208 pin pqfp .. the 2e took this package
> > : up the 300 part so some improvement yes .. but the Cyclone EP1C12 is
> > : available in a 240 pin pqfp ... 30+ more I/O pins, and the cyclone has
> > : 12K registers , a bunch more than the new 400 part.  my 2'c   KB
> >
> > But I don't see on-chip termination for the Cyclone part. Or did I miss
> > something?
> >
> > Bye
> > --
> > Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de
> >
> > Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
> > --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
>



Article: 55064
Subject: LDPC Code implmentation using XILINX Vertex
From: khankalimuddin@yahoo.com (Khan)
Date: 25 Apr 2003 09:52:25 -0700
Links: << >>  << T >>  << A >>
Hi there , 

I want to imlpement LDPC codec using VHDL language , any help on
materials available will be highly appreciated.

Thanks you very much in advance. 

Regards,

Khan

Article: 55065
Subject: Re: Any experience (good or bad) with Northwest Logic PCI core?
From: Mike Treseler <mike.treseler@flukenetworks.com>
Date: Fri, 25 Apr 2003 09:53:52 -0700
Links: << >>  << T >>  << A >>
Berend Ozceri (snip _news_ from address to reply) wrote:
> I just came across Northwest Logic's (http://www.nwlogic.com) PCI/PCI-X 
> core offerings (for Altera and Xilinx) and was wondering if there were 
> any folks out there who have used them (or other cores from Northwest 
> Logic) and would like to share their experiences.

My experience was good.
Not a PCI core however.
The core worked.
The documentation was very good.
The support and testbench was OK.
The source was was a little messy with lots of
commented code blocks and wrappers on wrappers,
but having the source proved essential for system integration.

  -- Mike Treseler


Article: 55066
Subject: Implementation of LDPC code using VHDL
From: khankalimuddin@yahoo.com (Khan)
Date: 25 Apr 2003 10:00:49 -0700
Links: << >>  << T >>  << A >>
Hi Gurus, 

I am doing project on developing LDPC coder and decoder using Xilinx
FPGA. Any help as far as material links and VHDL code will be highly
appreciated.


Thanking you in advance, 
 

Khan

Article: 55067
Subject: Re: Dynamic Reconfigurable FPGAs
From: "Robert Finch" <robfinch@sympatico.ca>
Date: Fri, 25 Apr 2003 13:38:56 -0400
Links: << >>  << T >>  << A >>
> > > I am wondering if you know any available FPGA devices which are
dynamically
> > > reconfigurable. I am doing a project in the area of evolvable hardware
and I
> > > am looking to buy a board with dynamic reconfigurable FPGAs.
> >

You can get kind of a dynamic reconfigurability out of SpartanII device.
I've never tried this, but I think it should work. The SRL16 feature can be
used to reload LUT ram contents, acting effectively as a second write port
to the LUT. Since the LUT ram can be reloaded it can change the logic
function of the LUT. By wiring up LUT's appropriately it should be possible
to get some facsimile of a dynamically reconfigurable part.

Rob





Article: 55068
Subject: Xilinx XCF Configuration parts
From: Uwe Bonnes <bon@elektron.ikp.physik.tu-darmstadt.de>
Date: Fri, 25 Apr 2003 18:14:34 +0000 (UTC)
Links: << >>  << T >>  << A >>
Hallo,

the Spartan-3 datasheet talks about the XCF configuration Flash PROM
parts. I found no further information. Any pointers?

Bye
-- 
Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Article: 55069
Subject: Re: Xilinx has released SpartanIII
From: rickman <spamgoeshere4@yahoo.com>
Date: Fri, 25 Apr 2003 14:23:31 -0400
Links: << >>  << T >>  << A >>
Austin Lesea wrote:
> 
> Uwe,
> 
> Doesn't have DDR built in either.  Oh well, I guess their market doesn't
> need 'at speed' SRAM interfaces.

I believe that I have read posts by Xilinx people about how they don't
like to comment on competitor's products here because they don't want it
to sound like they are ragging on them...  

Do I need to say anything more?  

-- 

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: 55070
Subject: Re: Large adder placement / synthesis
From: jakespambox@yahoo.com (Jake Janovetz)
Date: 25 Apr 2003 11:50:29 -0700
Links: << >>  << T >>  << A >>
Thanks for the info, Ray...  I took a short stint into the full-custom
ASIC arena and I'm back on FPGAs for a bit.

I've taken a peek at things under the FPGA editor and all looks good. 
However, I did notice one thing in the floorplanner: I had the P&R
tools do their thing, then copied the placement to the constraint so I
could edit it.  I moved a FF out of a packed slice (FF & carry chain
together as they should be) and was not able to move it back!  So,
somehow what's good for the P&R tools is apparently not good for Jake.

The carry chain is in tact and I'm not adding constants.  Both values
come from regs.  You know -- Verilog now has a generate in the
specification, but I don't think it has made its way into the XST
tools yet.

Anyone here on the FPGA list fiddled with Lava yet?

   Jake


Ray Andraka <ray@andraka.com> wrote in message news:<3EA8AE63.A3824049@andraka.com>...
> Jake,
> 
> Been a while since I've heard from you...  Anyway, you've discovered one
> of the warts on the tools.  There are several things that can make it
> impossible to pack the carry chain components properly.  If you have
> access to a mapped HDL viewer, I would reference that to see what the
> synthesis did to your adder.  Some possibilities:
> 
> 1) it might have put logic between the carry chain and the register.
> Typically this is a mux after the add or a sync reset that didn't get
> sucked into the flip-flop (usually because of a global reset already
> occupying the pin).
> 
> 2) a clock enable or reset net is split up so that registers that should
> have been packed can't be
> 
> 3) The carry chain got messed up.  This can happen if you are adding a
> constant.  I've seen synthesis 'optimize' a carry chain where one or more
> bits are constants in such a way that the carry chain can no longer be
> placed.  What typically happens is you get two sub-chains.  If the bottom
> of the upper chain is on an odd bit, the placer will shift the chain down
> by half a slice.  Put a syn keep on the constant input signal to avoid
> this.
> 
> 4) The LUT logic can get strewn hither and yonder by optimization that
> breaks the LUT down in funny ways.
> 
> 5) Finally, the placer just doesn't do a very good job with the logic
> associated with carry chains for some reason.  You can sometimes improve
> the results by adjusting the timing constraints, but only if the packer
> has already properly paired the pieces.
> 
> For stuff that is speed or density critical, I find it is easier just to
> do the RLOCing using a generate....oh yeah, you are using Verilog so you
> don't have a generate.  That makes the RLOCs a lot more awkward.
> 
> Jake Janovetz wrote:
> 
> > Hello-
> >
> > I have a large adder (48-bits to 64-bits) that I am implementing in a
> > Spartan IIE using Verilog synthesis.  I assumed that the adder LUTs,
> > carry logic, and resulting flip-flops would be placed in a column of
> > CLBs but alas, they are not.  Instead, the carry logic is nice, but
> > the other stuff is sort of scattered about.
> >
> > So, I tried to pull out the floorplanner and throw things around the
> > way I think they should be, but the tool won't let me.  My questions
> > are:
> > - Why doesn't the placer do things correctly?  This seems like a
> > no-brainer placement problem to me.  The carry chain alone provides a
> > pretty hefty constraint.
> > - Can the adders be forced to be implemented as an RPM without doing
> > the whole coregen thing or building my own adder and rloc'ing it?
> > - Is there some limitation that I'm missing that won't allow the LUTs
> > to be stacked reasonably and in the same slice?
> >
> > Now, for the purposes of this email, I've simplified somethings, but I
> > think justifiably so.  Namely, the adder is really:
> >    always @(posedge clk) begin
> >       out1 <= val + (sel ? out1 : out0);
> >    end
> >
> > Where 'sel' is a mux select and val is a register.  The mux/adder
> > should fit nicely in the LUT (and does).
> >
> >    Cheers,
> >    Jake
> 
> --
> --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: 55071
Subject: Re: software errors
From: eric - Mtl <notervme@sympatico.ca>
Date: Fri, 25 Apr 2003 14:56:48 -0400
Links: << >>  << T >>  << A >>


Michael Condon wrote:
> I'm sorry to have to tell you this, but schematic entry for FPGA design is
> dead. 

I'll add it to my collection of "Famous Last Words" ...

  VHDL is being taught at the undergrad level because the schools
> realize this.

They teach "Java" too. does that make "C" irrelevant ?

   I would suggest that you learn VHDL or Verilog.  These are
> two very powerful languages that make hardware design a lot easier and are
> more powerful then schematic entry will ever be.

Do you *really* think I don't know what HDLs are ?

   VHDL and Verilog allow for
> the code to be portable accross operating platforms and simulator,
> synthesis, and implementation software.

On portability, VHDL / Verilog clearly do better, since most schematic file
formats are (unfortunately) proprietary.

   I along with many other hardware
> engineers can already see the day when your boss doesn't hand you a Word or
> PDF document for the specifications of a design, but instead will hand you a
> VHDL or Verilog testbench file.

Well, I don't have a boss. I have customers, and my customers are for now
way more comfortable with a schematic diagram of the functions they want
because everyone there can figure out what it's doing. This might change,
but for now, that's what they like. They would certainly take VHDL code,
if I make them a nice schematic diagram that explains what it does ...

   The testbench file will be able to test the
> design for not only logic accuracy, but also timing specifications since
> VHDL and Verilog files can be generated post implementation which contain
> both gate and path delays associated with the netlist.

When using Xilinx tools, the schematic diagrams are converted to VHDL, so
I get exactly the same kind of simulation and timing analysis as if I was
coding using VHDL and I don't even need to write the HDL testbench if I
don't want to, thanks to "HDL Bencher" ...
Schematic entry is just an additional preprocessing layer ...


   I'm sorry that you
> are having trouble with the schematic software, but I imagine there will be
> a day(soon) where it is removed from the software completely and is only an
> option.  Good luck....
> 

Ain't that FUD ? There's life outside the Newsgroup, and it seems like Xilinx
is willing not only to fix ECS, but to improve it a lot.

The whole point of this thread was that tool quality severely lags behind
silicon quality and capabilities, and that should be a concern for "X" & "A"
as well as for all users, no matter if they code using schematics, VHDL,
Verilog or whatever ...

Eric.


Article: 55072
Subject: Re: Boycott All Xilinx products untill they correct all ISE softwareerrors
From: eric - Mtl <notervme@sympatico.ca>
Date: Fri, 25 Apr 2003 15:00:29 -0400
Links: << >>  << T >>  << A >>


Michael Condon wrote:
> I'm sorry to have to tell you this, but schematic entry for FPGA design is
> dead.

I'll add it to my collection of "Famous Last Words" ...

   VHDL is being taught at the undergrad level because the schools
> realize this.

They teach "Java" too. does that make "C" irrelevant ?

   I would suggest that you learn VHDL or Verilog.  These are
> two very powerful languages that make hardware design a lot easier and are
> more powerful then schematic entry will ever be.

Do you *really* think I don't know what HDLs are ?

   VHDL and Verilog allow for
> the code to be portable accross operating platforms and simulator,
> synthesis, and implementation software.

On portability, VHDL / Verilog clearly do better, since most schematic file
formats are (unfortunately) proprietary.

   I along with many other hardware
> engineers can already see the day when your boss doesn't hand you a Word or
> PDF document for the specifications of a design, but instead will hand you a
> VHDL or Verilog testbench file.

Well, I don't have a boss. I have customers, and my customers are for now
way more comfortable with a schematic diagram of the functions they want
because everyone there can figure out what it's doing. This might change,
but for now, that's what they like. They would certainly take VHDL code,
if I make them a nice schematic diagram that explains what it does ...

   The testbench file will be able to test the
> design for not only logic accuracy, but also timing specifications since
> VHDL and Verilog files can be generated post implementation which contain
> both gate and path delays associated with the netlist.

When using Xilinx tools, the schematic diagrams are converted to VHDL, so
I get exactly the same kind of simulation and timing analysis as if I was
coding using VHDL and I don't even need to write the HDL testbench if I
don't want to, thanks to "HDL Bencher" ...
Schematic entry is just an additional preprocessing layer ...

   I'm sorry that you
> are having trouble with the schematic software, but I imagine there will be
> a day(soon) where it is removed from the software completely and is only an
> option.  Good luck....
> 
> 

Ain't that FUD ? There's life outside the Newsgroup, and it seems like Xilinx
is willing not only to fix ECS, but to improve it a lot.

The whole point of this thread was that tool quality severely lags behind
silicon quality and capabilities, and that should be a concern for "X" & "A"
as well as for all users, no matter if they code using schematics, VHDL,
Verilog or whatever ...

Eric.



Article: 55073
Subject: Re: Large adder placement / synthesis
From: Ray Andraka <ray@andraka.com>
Date: Fri, 25 Apr 2003 19:35:57 GMT
Links: << >>  << T >>  << A >>


John_H wrote:

> If there was a serious reason why the Xilinx tools couldn't cooperate with
> the pleasant packing because of problems with shared resets or shared clock
> enables or some other low level conflict, the tools will report that they
> can't pack the items together and tell you why.  (or at least that's the
> behavior with LOCs - probably also with RLOCs)

Only if the primitives are RLOC'd.  If not, the packer won't pack the elements
together and the tool goes on oblivious.
I am not sure which version of the tools Jake is using.  There have been
problems in the past with RPM zippering, including occasional problems where the
carry chain is automatically RLOC'd and the other stuff is not.  Question for
Jake:  Is the carry chain intact?  Does the floorplanner allow you to place the
LUTs associated with the carry chain (it should, as long as the LUTs aren't
doing something goofy with the DI to the MUXCY's --I've seen that happen too)?
How about the ff's.

If you can't place the ff's in the floorplanner, it is usually due to
conflicting SR's or CE's.  Often that is the result of buffers getting inserted
to break up a big fan-out.

>
>
> Good luck.
>
> "Jake Janovetz" <jakespambox@yahoo.com> wrote in message
> news:d6ad3144.0304241738.3690c5e5@posting.google.com...
> > Hello-
> >
> > I have a large adder (48-bits to 64-bits) that I am implementing in a
> > Spartan IIE using Verilog synthesis.  I assumed that the adder LUTs,
> > carry logic, and resulting flip-flops would be placed in a column of
> > CLBs but alas, they are not.  Instead, the carry logic is nice, but
> > the other stuff is sort of scattered about.
> >
> > So, I tried to pull out the floorplanner and throw things around the
> > way I think they should be, but the tool won't let me.  My questions
> > are:
> > - Why doesn't the placer do things correctly?  This seems like a
> > no-brainer placement problem to me.  The carry chain alone provides a
> > pretty hefty constraint.
> > - Can the adders be forced to be implemented as an RPM without doing
> > the whole coregen thing or building my own adder and rloc'ing it?
> > - Is there some limitation that I'm missing that won't allow the LUTs
> > to be stacked reasonably and in the same slice?
> >
> > Now, for the purposes of this email, I've simplified somethings, but I
> > think justifiably so.  Namely, the adder is really:
> >    always @(posedge clk) begin
> >       out1 <= val + (sel ? out1 : out0);
> >    end
> >
> > Where 'sel' is a mux select and val is a register.  The mux/adder
> > should fit nicely in the LUT (and does).
> >
> >    Cheers,
> >    Jake

--
--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: 55074
Subject: Re: Large adder placement / synthesis
From: Ray Andraka <ray@andraka.com>
Date: Fri, 25 Apr 2003 19:38:33 GMT
Links: << >>  << T >>  << A >>


Jake Janovetz wrote:

> Thanks for the info, Ray...  I took a short stint into the full-custom
> ASIC arena and I'm back on FPGAs for a bit.
>
> I've taken a peek at things under the FPGA editor and all looks good.
> However, I did notice one thing in the floorplanner: I had the P&R
> tools do their thing, then copied the placement to the constraint so I
> could edit it.  I moved a FF out of a packed slice (FF & carry chain
> together as they should be) and was not able to move it back!  So,
> somehow what's good for the P&R tools is apparently not good for Jake.

Hmm, I've seen that a while back.  Sounds like it might be conflicting area constraints or
problems zippering logic with an RPM (the carry chain).  I'd have to look at what you have
to make a better determination.

>
>
> The carry chain is in tact and I'm not adding constants.  Both values
> come from regs.  You know -- Verilog now has a generate in the
> specification, but I don't think it has made its way into the XST
> tools yet.

Yeah, it is in verilog 2000.  I don't think any of the synth tools support '2000 yet
though.

>
>
> Anyone here on the FPGA list fiddled with Lava yet?
>
>    Jake
>
> Ray Andraka <ray@andraka.com> wrote in message news:<3EA8AE63.A3824049@andraka.com>...
> > Jake,
> >
> > Been a while since I've heard from you...  Anyway, you've discovered one
> > of the warts on the tools.  There are several things that can make it
> > impossible to pack the carry chain components properly.  If you have
> > access to a mapped HDL viewer, I would reference that to see what the
> > synthesis did to your adder.  Some possibilities:
> >
> > 1) it might have put logic between the carry chain and the register.
> > Typically this is a mux after the add or a sync reset that didn't get
> > sucked into the flip-flop (usually because of a global reset already
> > occupying the pin).
> >
> > 2) a clock enable or reset net is split up so that registers that should
> > have been packed can't be
> >
> > 3) The carry chain got messed up.  This can happen if you are adding a
> > constant.  I've seen synthesis 'optimize' a carry chain where one or more
> > bits are constants in such a way that the carry chain can no longer be
> > placed.  What typically happens is you get two sub-chains.  If the bottom
> > of the upper chain is on an odd bit, the placer will shift the chain down
> > by half a slice.  Put a syn keep on the constant input signal to avoid
> > this.
> >
> > 4) The LUT logic can get strewn hither and yonder by optimization that
> > breaks the LUT down in funny ways.
> >
> > 5) Finally, the placer just doesn't do a very good job with the logic
> > associated with carry chains for some reason.  You can sometimes improve
> > the results by adjusting the timing constraints, but only if the packer
> > has already properly paired the pieces.
> >
> > For stuff that is speed or density critical, I find it is easier just to
> > do the RLOCing using a generate....oh yeah, you are using Verilog so you
> > don't have a generate.  That makes the RLOCs a lot more awkward.
> >
> > Jake Janovetz wrote:
> >
> > > Hello-
> > >
> > > I have a large adder (48-bits to 64-bits) that I am implementing in a
> > > Spartan IIE using Verilog synthesis.  I assumed that the adder LUTs,
> > > carry logic, and resulting flip-flops would be placed in a column of
> > > CLBs but alas, they are not.  Instead, the carry logic is nice, but
> > > the other stuff is sort of scattered about.
> > >
> > > So, I tried to pull out the floorplanner and throw things around the
> > > way I think they should be, but the tool won't let me.  My questions
> > > are:
> > > - Why doesn't the placer do things correctly?  This seems like a
> > > no-brainer placement problem to me.  The carry chain alone provides a
> > > pretty hefty constraint.
> > > - Can the adders be forced to be implemented as an RPM without doing
> > > the whole coregen thing or building my own adder and rloc'ing it?
> > > - Is there some limitation that I'm missing that won't allow the LUTs
> > > to be stacked reasonably and in the same slice?
> > >
> > > Now, for the purposes of this email, I've simplified somethings, but I
> > > think justifiably so.  Namely, the adder is really:
> > >    always @(posedge clk) begin
> > >       out1 <= val + (sel ? out1 : out0);
> > >    end
> > >
> > > Where 'sel' is a mux select and val is a register.  The mux/adder
> > > should fit nicely in the LUT (and does).
> > >
> > >    Cheers,
> > >    Jake
> >
> > --
> > --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





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