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 76650

Article: 76650
Subject: Re: Virtex-II PRO, DDR2 SDRAM, RocketIO
From: Sean Durkin <smd@despammed.com>
Date: Wed, 08 Dec 2004 08:14:33 +0100
Links: << >>  << T >>  << A >>
Viktor Steinlin wrote:
> Hello,
> I'm about to design a frame grabber where I need high memory bandwidth.
> Does anybody has already implemented a design with Xilinx Virtex-II PRO and 
> DDR2 SDRAM. Have you encountered major problems with DDR2 controller 
> provided by Xilinx EDK? Some design hints?
OK, I'm stupid: Where is this DDR2 SDRAM-controller you are talking 
about? It's not included in my EDK6.3... is this an add-on-option you 
bought from Xilinx separately?

I face the same decision (DDR1 vs. DDR2) at the moment... I do not 
believe, however, that DDR1 will disappear anytime soon... new computers 
shipped will have DDR2, but you can still buy SDR-SDRAM and even old 
PS/2-SIMMs today, and these technologies haven't been used in PCs, 
a.k.a. "the mass market", for quite awhile...

cu,
Sean

Article: 76651
Subject: Re: Clock Gating !!!
From: "Hendra" <u1000393@email.sjsu.edu>
Date: 8 Dec 2004 00:03:57 -0800
Links: << >>  << T >>  << A >>
I assume you have gated clock because you want to suspend the operation
of some sequential logics when you want it. If that's what you want,
instead of having gated clock, you can have "clock enable". The
following example explains what I mean by "clock enable"

Let's say you want to have a 4 bit counter, but you want to stop the
counter from counting when you want it. You can do it this way
always @(posedge clk)
begin
if (clock_enable)
counter <= counter + 1;
else
counter <= counter;
end

This way, your counter is completely synchronous and still having the
ability to make the counter to stop counting by driving clock_enable to
low.

The same technique can be used to slow down your sequential logics,
without having to have multiple clocks in your design.
For example:
Let's say you want to have 2 seperate DFFs, one runs at 50 MHz and the
other runs at 100 MHz. Instead of having two different clocks in your
system, you can just have one clock, runs at 100 MHz.

reg [1:0]clock_divide;

always @(posedge clk)
begin
clock_divide <= clock_divide + 1;
end

//DFF 1
always @(posedge clk)
begin
if (clock_enable[1])
q1 <= d1;
else
q1 <= q1;
end

//DFF 2
always @(posedge clk)
begin
q2 <= d2;
end

This way, your DFF2 runs at 100 MHz, while your DFF1 runs at 50 MHz.
Both DFFs run at different frequencies, without having to have 2
different clocks.


Hendra


Article: 76652
Subject: Re: Clock Gating !!!
From: "Hendra" <u1000393@email.sjsu.edu>
Date: 8 Dec 2004 00:08:44 -0800
Links: << >>  << T >>  << A >>
CORRECTION:

The second example should be:

reg [1:0]clock_enable;
always @(posedge clk)
begin
clock_enable <= clock_enable + 1;
end


Article: 76653
Subject: Re: making an fpga hot
From: "Symon" <symon_brewer@hotmail.com>
Date: Wed, 8 Dec 2004 00:33:40 -0800
Links: << >>  << T >>  << A >>
Hi Paul,
Comments/Questions below!

"Paul Leventis (at home)" <paulleventis-news@yahoo.ca> wrote in message 
news:686dnTKPrvwyGyvcRVn-pQ@rogers.com...
> (2) LUT Configuration.  A LUT configured as an AND gate does not burn 
> nearly
> as much power as one configured as an XOR.  This difference is due to the
> number of internal nodes in the circuit that toggle states upon the toggle
> of in input signal.  On top of this, (blah, blah, XORs transition more)

Could you explain that a little more? I thought that the LUT was just a 16x1 
RAM. Is the extra power consumed only when two inputs change? e.g. 00 => 11 
into the XOR would still have 0 as its output but it might transistion 
through the 1 output state? I understand that XOR gates are more likely to 
transition, but you seem to be saying there's some additional internal 
reason why they consume power.

>
> Paul Leventis
> Altera Corp.
>
Cheers, Syms. 



Article: 76654
Subject: Re: Xilinx Read First Write First
From: Philip Freidin <philip@fliptronics.com>
Date: Wed, 08 Dec 2004 08:44:06 GMT
Links: << >>  << T >>  << A >>
On 7 Dec 2004 22:11:40 -0800, "Harish" <harish.vutukuru@gmail.com> wrote:
>How about dual port BRAM? My understanding is that both the ports have
>access to the same BRAM. So if in through one port you want to read the
>data and through the other port you want to write the data  to same
>memory location what will happen?
>
>Thanks

This is called "you get what you deserve" mode.

This is explaind in detail here:

   http://www.fpga-faq.com/archives/72650.html#72651


Philip Freidin






===================
Philip Freidin
philip.freidin@fpga-faq.com
Host for WWW.FPGA-FAQ.COM

Article: 76655
Subject: Re: Clock Gating !!!
From: "Symon" <symon_brewer@hotmail.com>
Date: Wed, 8 Dec 2004 00:56:28 -0800
Links: << >>  << T >>  << A >>

"Chandrasekhar" <chandu_419@yahoo.com> wrote in message 
news:1102489026.603341.150020@c13g2000cwb.googlegroups.com...
> Hi All,
>
> I m facing some problems with clock gating in Virtex II FPGA
> using BUFGMUX, The Xilinx ISE 6.2.03i is saying the design is not
> completely routable. I know that clock gating in an FPGA is not
> advisable, but my requirement is like that.

No it isn't. Use enables instead. The tool has saved you from months of pain 
by refusing to connect up such an abomination!

> I have total 15 clocks of 5
> diffterent frequencies. All these 15 clocks are gated with gate enable
> before going to the individual modules. The gating must be done in my
> clock tree module only.
>
> Can anyone please give some inputs on this... Any help will
> be greatly appreciated.
>
> Thanks...
> Chandrasekhar.
>

Fix it so you have one clock. Make it faster than the others; why not use a 
DCM to create it? Use enables for your original 15 clocks. If necessary, 
retime the stuff from the various clock domains on the way in, and on the 
way out, in your 'clock tree module'. A little thought up front will save 
you so many problems. Here's a resynchronising circuit posted by Rick 
Collins to get you going.
http://www.fpga-faq.com/archives/59400.html#59400

Good luck, Syms.




Article: 76656
Subject: Re: how to speed up my accumulator ??
From: Allan Herriman <allan.herriman.hates.spam@ctam.com.au.invalid>
Date: Wed, 08 Dec 2004 21:05:01 +1100
Links: << >>  << T >>  << A >>
On Tue, 07 Dec 2004 16:13:13 +1100, Allan Herriman
<allan.herriman.hates.spam@ctam.com.au.invalid> wrote:

>>> Ten highest spurious tones:
>>> 
>>>  55.000kHz -11.4dBc
>>> 367.000kHz -16.7dBc
>>> 101.000kHz -17.0dBc
>>> 165.000kHz -22.4dBc
>>>   9.000kHz -22.9dBc
>>> 257.000kHz -24.1dBc
>>> 321.000kHz -25.1dBc
>>> 147.000kHz -25.8dBc
>>> 119.000kHz -27.4dBc
>>>  37.000kHz -27.7dBc

Sorry, The frequencies are right, but I messed up the amplitudes.  I
realised the mistake when I checked by FFT-ing the output of a phase
accumulator (using Excel!).

This is closer to reality:

367.000kHz  -9.5dBc
 55.000kHz -14.0dBc
477.000kHz -16.9dBc
101.000kHz -19.1dBc
321.000kHz -20.8dBc
257.000kHz -22.3dBc
165.000kHz -23.5dBc
413.000kHz -24.6dBc
  9.000kHz -25.6dBc

etc.

I've only considered the spurious tones between 0Hz and 500kHz.  Each
of these tones will have an alias between 1MHz and 500kHz.

Note that the relative amplitudes of the highest spurious tones follow
a 1/3, 1/5, 1/7, 1/9 ... sequence.

Regards,
Allan

Article: 76657
Subject: Re: Xilinx Read First Write First
From: "newman5382" <newman5382@yahoo.com>
Date: Wed, 08 Dec 2004 10:38:25 GMT
Links: << >>  << T >>  << A >>
In dp_block_mem.pdf, it states:
The Spartan-II/Virtex and Virtex-II/Spartan-3 block memory is True Dual-Port 
RAM that allows both ports to simultaneously access the same memory 
location.  When one port writes to a given memory location, the other port 
must not address that memory location (for a write/read) within the 
clock-to-clock setup window. Note that conflicts do not cause any physical 
damage to BlockRAM cells.  For more information on conflict resolution, 
refer to the Spartan-II, VIrtex, Virtex-II/Spartan-3 Databook available at 
the website: http://www.xilinx.com/partinfo/databook.htm

In coregen, after one selects the particular IP, there is a "Data Sheet" 
button that links information about the IP block.  The above was taken 
directly from the "Data Sheet"

- Newman

"Harish" <harish.vutukuru@gmail.com> wrote in message 
news:1102486300.214476.266890@c13g2000cwb.googlegroups.com...
> How about dual port BRAM? My understanding is that both the ports have
> access to the same BRAM. So if in through one port you want to read the
> data and through the other port you want to write the data  to same
> memory location what will happen?
>
>
> Thanks
> 



Article: 76658
Subject: Fpga prices
From: dan.costin@gmail.com (Dan)
Date: 8 Dec 2004 04:10:17 -0800
Links: << >>  << T >>  << A >>
I need an information about some prices for some fpga.

 Acex1k speed -1, 208 pins.
 Cyclone speed -6, 240pins.

   Thanks,

Article: 76659
Subject: Modelsim Directory
From: ALuPin@web.de (ALuPin)
Date: 8 Dec 2004 05:07:53 -0800
Links: << >>  << T >>  << A >>
Hi,

I have written a little .do-script with which
the VHDL files are compiled and the simulation is performed.

When I open Modelsim I have to go to
FILE --> CHANGE DIRECTORY  and then I have to enter
the path of my simulation directory including my script.

How can I do this directory changing automatically at the beginning
of my script ? Is there any command ?

I would appreciate your help.

Here is the script

vlib work
# Compile base libraries
vcom util1164.vhd
vcom stdlogar.vhd
vcom io_utils.vhd
vcom mti_pkg.vhd
# Compile test vectors
vcom vec_gen.vhd
vcom ed_comnd.vhd

vcom -93 ../../../sdram_ctrl/sdram_positions_arbitration/
fraction_sdram_numbers_fifo.vhd
vcom -93 ../../../sdram_ctrl/sdram_positions_arbitration/
mux_fraction_fifo_outputs.vhd
vcom -93 ../../../sdram_ctrl/sdram_positions_arbitration/sdram_pos_arbiter.vhd
vcom -93 ../../../sdram_ctrl/sdram_positions_arbitration/
sdram_positions_arbitration.vhd

vcom -93 ../../../sdram_ctrl/valid_bytes_in_row.vhd
vcom -93 ../../../sdram_ctrl/tristate_buffer.vhd
vcom -93 ../../../sdram_ctrl/sdram_controller.vhd
vcom -93 ../../../sdram_ctrl/sdram_ctrl.vhd
vcom -93 ./mt48lc8m16a2.vhd
vcom -93 ../../../sie_trans_fs/read_burst_fifo.vhd
vcom -93 ../../../sie_trans_fs/crc16_8bit_in.vhd
vcom -93 ../../../sie_trans_fs/sie_trans_fs.vhd

vcom -93 ./tb_sdram_ctrl_sie_fs.vhd
vsim tb_sdram_ctrl_sie_fs
do Simulationsplot_sdram_ctrl_sie_fs.do
run 1200us -all

configure wave -signalnamewidth 1
set StdArithNoWarnings 1
set IgnoreWarning 1
set DefaultRadix unsigned

Article: 76660
Subject: Re: Modelsim Directory
From: Utku Ozcan <utku.ozcan@netas.com.tr>
Date: Wed, 08 Dec 2004 15:38:34 +0200
Links: << >>  << T >>  << A >>

You can use an identifier to have a fully parametric script,
so that you can get rid of physical location of your HDL codes.

Example:

---- do script ----
...
set designlib /home/AluPin/sdram_chip
...
vcom -93 $designlib/sdram_ctrl/sdram_positions_arbitration/sdram_pos_arbiter.vhd
...

--- end of script ---

You can further parametrize your RTL simulation environment
by placing "$designlib" into a separate *.do script.
This way you can move the complete design directory to another
location. In this case you just need to update the *.do
script called in your script:

--- do script ---
...
do chip_global.do <-- designlib is defined here!!
...
vcom -93 ....
...
--- end of script ---

In "chip_global.do":
---
...
set designlib /home/AluPin/sdram_chip 
...
---

... and other necessary variables go there.

Utku


ALuPin wrote:
> 
> Hi,
> 
> I have written a little .do-script with which
> the VHDL files are compiled and the simulation is performed.
> 
> When I open Modelsim I have to go to
> FILE --> CHANGE DIRECTORY  and then I have to enter
> the path of my simulation directory including my script.
> 
> How can I do this directory changing automatically at the beginning
> of my script ? Is there any command ?
> 
> I would appreciate your help.
> 
> Here is the script
> 
> vlib work
> # Compile base libraries
> vcom util1164.vhd
> vcom stdlogar.vhd
> vcom io_utils.vhd
> vcom mti_pkg.vhd
> # Compile test vectors
> vcom vec_gen.vhd
> vcom ed_comnd.vhd
> 
> vcom -93 ../../../sdram_ctrl/sdram_positions_arbitration/
> fraction_sdram_numbers_fifo.vhd
> vcom -93 ../../../sdram_ctrl/sdram_positions_arbitration/
> mux_fraction_fifo_outputs.vhd
> vcom -93 ../../../sdram_ctrl/sdram_positions_arbitration/sdram_pos_arbiter.vhd
> vcom -93 ../../../sdram_ctrl/sdram_positions_arbitration/
> sdram_positions_arbitration.vhd
> 
> vcom -93 ../../../sdram_ctrl/valid_bytes_in_row.vhd
> vcom -93 ../../../sdram_ctrl/tristate_buffer.vhd
> vcom -93 ../../../sdram_ctrl/sdram_controller.vhd
> vcom -93 ../../../sdram_ctrl/sdram_ctrl.vhd
> vcom -93 ./mt48lc8m16a2.vhd
> vcom -93 ../../../sie_trans_fs/read_burst_fifo.vhd
> vcom -93 ../../../sie_trans_fs/crc16_8bit_in.vhd
> vcom -93 ../../../sie_trans_fs/sie_trans_fs.vhd
> 
> vcom -93 ./tb_sdram_ctrl_sie_fs.vhd
> vsim tb_sdram_ctrl_sie_fs
> do Simulationsplot_sdram_ctrl_sie_fs.do
> run 1200us -all
> 
> configure wave -signalnamewidth 1
> set StdArithNoWarnings 1
> set IgnoreWarning 1
> set DefaultRadix unsigned

-- 
This is a SUNW,Ultra-80 machine.
  3:15pm  up 56 day(s), 3 min(s),  1 user,  load average: 0.14, 0.13, 0.08

Article: 76661
Subject: Re: Fpga prices
From: Rene Tschaggelar <none@none.net>
Date: Wed, 08 Dec 2004 16:13:18 +0100
Links: << >>  << T >>  << A >>
Dan wrote:

> I need an information about some prices for some fpga.
> 
>  Acex1k speed -1, 208 pins.
>  Cyclone speed -6, 240pins.


your distributor might be of help.
Or try http://www.ebv.com

Rene
-- 
Ing.Buero R.Tschaggelar - http://www.ibrtses.com
& commercial newsgroups - http://www.talkto.net

Article: 76662
Subject: Re: Fpga prices
From: "Victor Schutte" <victors@mweb.co.za>
Date: Wed, 8 Dec 2004 17:30:38 +0200
Links: << >>  << T >>  << A >>
The Acex I don't know but the Cyclone1  1C6 240 speed grade -8 I get for
about $34.


Victor

http://www.zertec.co.za




"Dan" <dan.costin@gmail.com> wrote in message
news:f4e089e0.0412080410.5ce72807@posting.google.com...
> I need an information about some prices for some fpga.
>
>  Acex1k speed -1, 208 pins.
>  Cyclone speed -6, 240pins.
>
>    Thanks,



Article: 76663
Subject: Re: Modelsim Directory
From: "Andrea Sabatini" <andrea@dapdesign_N_O_S_P_A_M_.com>
Date: Wed, 8 Dec 2004 16:58:17 +0100
Links: << >>  << T >>  << A >>
hi,

i solved that annoing problem modifing the modelsim.ini file that in my
computer is placed into the directory:

C:\Programs\Modeltech_xe\examples

the line that i added (or changed... i do not remember) is the following:

#########################

; VSIM Startup command
Startup = do wdir.do

#########################


and the wdir.do file is placed in the same directory with the following
command:

#########################

cd e:/work/fs/sim

#########################

hope this help

andrea



Article: 76664
Subject: Re: Adder Tree Placement
From: Kevin Neilson <kevin_neilson@removethiscomcast.net>
Date: Wed, 08 Dec 2004 10:39:25 -0700
Links: << >>  << T >>  << A >>
John_H wrote:

> 
> I've tried to work this issue some in the past.  Since you're using Xilinx,
> the adders are vertical structures that occupy half a CLB allowing 2 adders
> per CLB column.  The final adder has two inputs that come from smaller adder
> trees to the right and left for minimum propagation.  I ended up going into
> the FPGA Editor to try different configurations to come up with the
> "optimum" delay.  Most architectures like inputs that are one or two columns
> away with a feedback within a column sometimes producing better, sometimes
> worse delays compared to the adjacent column.
> 
> Proper timing constraints would *ideally* give you the nice, right/left
> distributed adders.where bits at the same level are in the same CLB row
> across the adders.  The P&R tool tends to be a little less precise but might
> be coerced into giving proper results with better constraints than I've
> developed.  For the extremely tight designs I tend to RLOC the adders.  It's
> a pain in Verilog but I haven't had to RLOC more than one or two moderately
> sized adder trees.
> 

Thanks for this input.  I certainly don't want to try to use FPGA editor 
  to experiment with different configurations, so this is helpful.

At one point I tried to put the whole tree in a single row like you 
suggest, but one problem with that is that the adder inputs come from 
BRAMs, which are in a long column.  I guess I could register the BRAM 
outputs (a second time) to get all the signals to a single row, where 
the tree would lie.
-Kevin

Article: 76665
Subject: Re: Xilinx Area Constraints for partial reconfiguration
From: "Harish" <harish.vutukuru@gmail.com>
Date: 8 Dec 2004 09:42:36 -0800
Links: << >>  << T >>  << A >>
Hello Rick,

Thanks for the reply. I hope Xilinx provides with the information as
how they restrict the resources within the column.
With regard to the other questions I do plan to write my own software
working on the top of Xilinx tools( I am still analyzing the issues
associated with it)


Thanks
Harish


Article: 76666
Subject: Re: Adder Tree Placement
From: Kevin Neilson <kevin_neilson@removethiscomcast.net>
Date: Wed, 08 Dec 2004 10:44:55 -0700
Links: << >>  << T >>  << A >>
Ray Andraka wrote:
> Well, if you must use a tree (more on that in a minute), then your best bet
> is to include RLOCs for the adders.  You get reasonable performance by
> placing the first level in every other slice column and then placing the
> next levels in every other vacant column until you reach the root.
> "Reasonable" depends on the depth of the tree and your clock speed of
> course.  It starts losing performance at 3 levels or so, because of the
> progressively longer routes.  You can make up the speed by adding pipeline
> registers at the cost of real-estate.
> 
> In the case of an FIR filter, however, you don't need a tree.  Instead, push
> part or all of the tap delay through the coefficient multiplies so that you
> can connect the adders in a linear array (ie daisy chained), absorbing the
> delays into the adder registers.  That gives you all nearest neighbor
> connections, and if you do it right, the latency is actually less than a
> tree.  The cost is if you need to clock enable it, your control task is much
> more complicated.
> 
Your suggestion on tree layout is exactly what I was looking for.  It 
seems my tree that is floorplanned like a tree isn't the best plan.

You are right about the transpose FIR architecture, though.  I have 
become convinced that that is the best choice because of the ease of 
layout.  I will be able to place the adders right next to the BRAMs in 
the column and the datapaths will be nice and short.
-Kevin

Article: 76667
Subject: Chained signal propagation pb.
From: "Fred Bartoli" <fred._canxxxel_this_bartoli@RemoveThatAlso_free.fr_AndThisToo>
Date: Wed, 8 Dec 2004 19:12:35 +0100
Links: << >>  << T >>  << A >>
Hello,
This is my first FPGA design and a pretty huge one. Well I believe :=)

First of all, the target is imposed and is an APEX20KE, and I use Quartus.

It is for an XY detectors array 128x128 and thus have 256 head cells, each
one with its state machine.
Each cell has to work in cooperation with its immediate neighbours in order
to resolve some incoming events that can be spread over several consecutive
cells.
Each cell has a local time counter (100MHz) in order to have the cell's
event duration.

Now my problem :
Several events may occur at the same time anywhere on the detector, but for
simplicity lets consider just one physical event occurence, which translate
to a group of several pulses occuring on a set of not disjoint cells (I call
this a cluster).

Now each cell compares its local time to a T1 value (fixed delay after the
first incoming rising transition) and at the first T1 occurence in the
cluster I have to sample all the cluster cells states (input active or not),
**but only for the cells of this cluster** and this have to be done in
preferably one, maybe two 100MHz clock cycles (we don't want adjacent
clusters to compete for their boundaries).

Wouldn't have been the two last conditions that would be almost
straightforward, but this makes the exercise difficult.

This almost reduces as : how do I propagate through a group of cells as fast
as possible, while controling its propagation.
I forgot to mention that the maximum allowed cluster size is 8 cells. Above,
all the cluster is rejected and we have time to do this.
So we "just" have to be fast on, at worst, 8 cells.


As we don't want "boundary competition" I can't imagine a clocked process
for the sampling signal propagation.


I first thought of using the cascade or fast carry chains, but I've had no
success.

Another idea was to "ripple sample" the cells, i.e. tie each cell samplingFF
clock to the previous cell samplingFF output, and having the D input
allowing signal propagation. And after that I have 1 or two resync FFs.
Unfortunately I have only 2 clocks available per LAB (10 LE) and this would
take too much place.



The best I could come with is (with my FPGA):

- At the first occuring T1, I asynchronously propagate a cell sampling
enable signal from one cell to the next, until I encounter a boundary cell.
This is hoped to be fast enough to propagate through the max cluster size (8
consecutive cells) within the allowed time (10 or 20 ns).
- then after the sampling period (10 or 20ns) all the allowed cells are
sampled, and, hum, et voila.


Unfortunatly, and quite obvioulsy, the fitter complains about a truck load
of timing violations, since I have 127 chained LUTs to propagate and control
the sampling signal from the first cell to the last one.
All I want to do is ensure that the propagation time through a segment (max
length = 8) is under control.

How can I do that ?



Any other idea about the design is also welcomed.


-- 
Thanks,
Fred.



Article: 76668
Subject: Open source FPGA EDA Tools
From: SG <gupt@hotmail.com.NOSPAM>
Date: 08 Dec 2004 10:27:11 -0800
Links: << >>  << T >>  << A >>

Looks like ST Micro has been trying to unsuccessfully develop a new
FPGA for many years with 100s of engineers.  The good thing to come
out of this project is that they are open-sourcing the EDA tools they
developed for their FPGA.  These tools (Synthesis, P&R etc) are
available at:
http://www.gospl.org

Specifically, see:
http://www.gospl.org/fpl/static/aboutgospl.jsp

This is good for researchers to play around with tools.  And at first
glance, looks like a true open-source license (publish any changes to
source code that you make).  However, ST benefits the most, since they
get free tool enhancement, while they sell their FPGA fabric as an
embedded FPGA fabric.

Sumit

Article: 76669
Subject: Re: Open source FPGA EDA Tools
From: rickman <spamgoeshere4@yahoo.com>
Date: Wed, 08 Dec 2004 14:04:03 -0500
Links: << >>  << T >>  << A >>
SG wrote:
> 
> Looks like ST Micro has been trying to unsuccessfully develop a new
> FPGA for many years with 100s of engineers.  The good thing to come
> out of this project is that they are open-sourcing the EDA tools they
> developed for their FPGA.  These tools (Synthesis, P&R etc) are
> available at:
> http://www.gospl.org
> 
> Specifically, see:
> http://www.gospl.org/fpl/static/aboutgospl.jsp
> 
> This is good for researchers to play around with tools.  And at first
> glance, looks like a true open-source license (publish any changes to
> source code that you make).  However, ST benefits the most, since they
> get free tool enhancement, while they sell their FPGA fabric as an
> embedded FPGA fabric.

They may be able to create a viable business model using this approach,
but it will require a *LOT* more than just open source tools.  The key
to their product acceptance is that it has to be a *GOOD* FPGA
architecture.  The fact that they don't say much about the hardware and
the fact that it does not look like the hardware is open source says to
me that the open source software won't be much of an advantage.  Sure,
they will get academia to work on their software for them.  But much of
that will be pie-in-the-sky stuff and likely the tools will not really
be any better than the tools available for the mainstream vendors.  

Where do you find info about the FPGA?  

-- 

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: 76670
Subject: Re: Open source FPGA EDA Tools
From: "Antti Lukats" <antti@case2000.com>
Date: Wed, 8 Dec 2004 20:53:27 +0100
Links: << >>  << T >>  << A >>
"rickman" <spamgoeshere4@yahoo.com> wrote in message
news:41B75023.9D218EC5@yahoo.com...
> SG wrote:
> >
> > Looks like ST Micro has been trying to unsuccessfully develop a new
> > FPGA for many years with 100s of engineers.  The good thing to come
> > out of this project is that they are open-sourcing the EDA tools they
> > developed for their FPGA.  These tools (Synthesis, P&R etc) are
> > available at:
> > http://www.gospl.org
> >
> > Specifically, see:
> > http://www.gospl.org/fpl/static/aboutgospl.jsp
> >
> > This is good for researchers to play around with tools.  And at first
> > glance, looks like a true open-source license (publish any changes to
> > source code that you make).  However, ST benefits the most, since they
> > get free tool enhancement, while they sell their FPGA fabric as an
> > embedded FPGA fabric.
>
> They may be able to create a viable business model using this approach,
> but it will require a *LOT* more than just open source tools.  The key
> to their product acceptance is that it has to be a *GOOD* FPGA
> architecture.  The fact that they don't say much about the hardware and
> the fact that it does not look like the hardware is open source says to
> me that the open source software won't be much of an advantage.  Sure,
> they will get academia to work on their software for them.  But much of
> that will be pie-in-the-sky stuff and likely the tools will not really
> be any better than the tools available for the mainstream vendors.
>
> Where do you find info about the FPGA?
there is some small diagram of the arch, but not more :(

sure there is more needed than just the tools, but the FPGA arch doesnt need
to be *GOOD* (eg very good) - its not possible to be good for every
application anyway. If the FPGA Arch is "useable" at least then there could
be some market already. Plessey had ERA6K ram-based sea-of-gates array in
the "early days" - that product died (in my opinion) mostly because the
software company Pilkington never deliver the tools for the ERA6K. (Well
just recently I heard that there where some problems inside Plessey at time
too). Anyway I still belive that if superior tools would have been available
for ERA6K it would not have died or would have merged into some better
product.

Whatever arch the GOSPL is targetting, I am pretty sure it is useable -
specially when implemented in the modern technology.

If somebody would care to calc how much time have people wasted fighting
with FPGA tools from "mainstream vendors" ? Then take that hour(days months
years) count and multiply with some reasonable $$ pay/per hour? The number
would be huge! But there is no way around, the tools are still bad (sure
improving all the time sure), and the tool updates/service packs, ipcore
versions, SoC system builder update incompatibilities, those all take huge
amount of time from all of us. Could that time be saved?

If and only if there would a full toolchain that really works: you write the
RTL, you write the C code, select the softcore-cpu + peripherals: the SoC's
is built, the ip cores are integrated, the bitstream is built from single
keypress (after design change) - if that would really work, then well even
if it only targets a not so advance FPGA arch, there would be interest and
market for it.

Antti



Article: 76671
Subject: Re: Open source FPGA EDA Tools
From: rickman <spamgoeshere4@yahoo.com>
Date: Wed, 08 Dec 2004 15:07:05 -0500
Links: << >>  << T >>  << A >>
Antti Lukats wrote:
> 
> sure there is more needed than just the tools, but the FPGA arch doesnt need
> to be *GOOD* (eg very good) - its not possible to be good for every
> application anyway. If the FPGA Arch is "useable" at least then there could
> be some market already. 

That is what I disagree with.  There is an established market with
established market leaders.  Rather like many industries, like the auto
industry, unless you can provide a superior product, you don't have much
chance of gaining market share against the established leaders.  


> Plessey had ERA6K ram-based sea-of-gates array in
> the "early days" - that product died (in my opinion) mostly because the
> software company Pilkington never deliver the tools for the ERA6K. (Well
> just recently I heard that there where some problems inside Plessey at time
> too). Anyway I still belive that if superior tools would have been available
> for ERA6K it would not have died or would have merged into some better
> product.

They are not the only company to try to enter the mature FPGA market. 
Motorola had an architecture that was supported by the Neocad tools. 
But even before they sold a single chip, they realized that bringing a
new FPGA to market was a *HUGE* undertaking.  It would be easier to
bring out yet another CPU architecture (which Motorola has done many
time).  So they cancled the FPGA before it even met the market.  

> Whatever arch the GOSPL is targetting, I am pretty sure it is useable -
> specially when implemented in the modern technology.

Useable is not the same as marketable.  Engineers just want something
they can get the job done with.  Currently the tools are not a
significant impediment.  If the tools provided some advantage, like time
to market, then they might have a chance.  But it will be a long time
before the open source tools are *superior* the the current vendor
supplied tools.  I believe this is why ST is targeting "embedded" FPGA
structures.  This is still a new market and much more open to a new
vendor. 


> If somebody would care to calc how much time have people wasted fighting
> with FPGA tools from "mainstream vendors" ? Then take that hour(days months
> years) count and multiply with some reasonable $$ pay/per hour? The number
> would be huge! But there is no way around, the tools are still bad (sure
> improving all the time sure), and the tool updates/service packs, ipcore
> versions, SoC system builder update incompatibilities, those all take huge
> amount of time from all of us. Could that time be saved?

No open source tool will be much better in those areas as has been
discussed here many times.  Unlike software tools, FPGA tools have to
evolve much more quickly to adapt to the changes in FPGAs and FPGA
markets.  This results in lots of updates and lots of bugs.  (BTW
Mentor, are you *ever* going to fix the bug where Modelsim crashes
randomly for no special reason???)  I dont' see open source tools fixing
any of this.  The current open source front end tools are still far
inferior to vendor supplied tools.  


> If and only if there would a full toolchain that really works: you write the
> RTL, you write the C code, select the softcore-cpu + peripherals: the SoC's
> is built, the ip cores are integrated, the bitstream is built from single
> keypress (after design change) - if that would really work, then well even
> if it only targets a not so advance FPGA arch, there would be interest and
> market for it.

Not before I retire....  but hey, "build it and they will come".  

-- 

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: 76672
Subject: Re: Open source FPGA EDA Tools
From: SG <gupt@hotmail.com.NOSPAM>
Date: 08 Dec 2004 13:10:09 -0800
Links: << >>  << T >>  << A >>

The key things here is that ST Micro is going after the embedded FPGA
market.   This is not an established market and Xilinx & Altera will
have advantages only in terms of tool familiarity.

About ST's architecture, if the Logic synthesis and P&R tools are open
source, it should be very easy to figure out what the architecture
is.  Also, I don't think its a very big innovation, otherwise, ST
would go after the standalone FPGA market, instead of a non-existant
embedded FPGA market.  

My 2 cents.
Sumit

Article: 76673
Subject: Re: Open source FPGA EDA Tools
From: reeuwijk@few.vu.nl (Kees van Reeuwijk)
Date: Wed, 8 Dec 2004 22:10:33 +0100
Links: << >>  << T >>  << A >>
rickman <spamgoeshere4@yahoo.com> wrote:

 
> No open source tool will be much better in those areas as has been
> discussed here many times.  Unlike software tools, FPGA tools have to
> evolve much more quickly to adapt to the changes in FPGAs and FPGA
> markets.  This results in lots of updates and lots of bugs. 

Perhaps, but the point remains that quite a lot of people would be happy
with not-so-bleeding-edge FPGAs and a more accessible toolset than brand
X or A offer. So, if you already have not-so-bleeding-edge FPGAs, open
sourcing your toolset is one way of meeting that demand. And potentially
a very effective way: if you play it right, you can get a lot of help
from the open-source community.

> (BTW
> Mentor, are you *ever* going to fix the bug where Modelsim crashes
> randomly for no special reason???)  I dont' see open source tools fixing
> any of this.  The current open source front end tools are still far
> inferior to vendor supplied tools.  

I had to laugh when I saw that combination of sentences. The whole open
source movement was started by people that got frustrated with software
vendors that ignored bug reports. And it does help.

> > If and only if there would a full toolchain that really works: you write the
> > RTL, you write the C code, select the softcore-cpu + peripherals: the SoC's
> > is built, the ip cores are integrated, the bitstream is built from single
> > keypress (after design change) - if that would really work, then well even
> > if it only targets a not so advance FPGA arch, there would be interest and
> > market for it.
> 
> Not before I retire....  but hey, "build it and they will come".  

Personally, I believe this is possible, but the problem is always that
the stuff on offer has to be right. A vendor with a weak FPGA and a
rotten toolset will get nowhere. A vendor with a good FPGA and a good
toolchain may well have a smash hit. But I think the key phrase in this
business plan is KEEP IT SIMPLE.

Article: 76674
Subject: Re: how to speed up my accumulator ??
From: "Falk Brunner" <Falk.Brunner@gmx.de>
Date: Wed, 8 Dec 2004 23:07:58 +0100
Links: << >>  << T >>  << A >>

"John_H" <johnhandwork@mail.com> schrieb im Newsbeitrag
news:S9std.14$a61.1075@news-west.eli.net...

> All this assumes, of course, that there's an analog PLL driven by the
single
> bit, noise-shaped NCO output.  Without the PLL to filter out the high
> frequency phase noise of a Sigma-Delta style NCO, the jitter is still
around
> 1 reference clock period peak-to-peak, maybe worse.

Yes.

> (NCOs are used by many folks in the comp.arch.fpga newsgroup who have no
> reason to visit comp.dsp.)

????
Dont get it.

Regards
Falk






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