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 123050

Article: 123050
Subject: Multiplication Problem on Microblaze Software
From: "mfgunes" <mfgunes@yahoo.com>
Date: Wed, 15 Aug 2007 05:39:24 -0500
Links: << >>  << T >>  << A >>

Hi,

I want to do multiplication operation in my Microblaze's Test_Application
in Xilinx Plaform Studio.
But i get some errors.can you help me?

This my code

temp1=j=16;
temp2=temp1*0.5;//error occurs when i use " * " 
*com2=(temp2);



These are the error messages


/cygdrive/c/EDK/gnu/microblaze/nt/bin/../lib/gcc/microblaze/3.4.1/../../../../microblaze/bin/ld.real:
region ilmb_cntlr_dlmb_cntlr is full (TestApp_Memory/executable.elf section
.text)
/cygdrive/c/EDK/gnu/microblaze/nt/bin/../lib/gcc/microblaze/3.4.1/../../../../microblaze/bin/ld.real:
region ilmb_cntlr_dlmb_cntlr is full (TestApp_Memory/executable.elf section
.text)
/cygdrive/c/EDK/gnu/microblaze/nt/bin/../lib/gcc/microblaze/3.4.1/../../../../microblaze/bin/ld.real:
section .init [00000050 -> 00000073] overlaps section .text [00000050 ->
00002463]
/cygdrive/c/EDK/gnu/microblaze/nt/bin/../lib/gcc/microblaze/3.4.1/../../../../microblaze/bin/ld.real:
section .fini [00000074 -> 0000008f] overlaps section .text [00000050 ->
00002463]
/cygdrive/c/EDK/gnu/microblaze/nt/bin/../lib/gcc/microblaze/3.4.1/../../../../microblaze/bin/ld.real:
section .rodata [00000090 -> 00000374] overlaps section .text [00000050 ->
00002463]
/cygdrive/c/EDK/gnu/microblaze/nt/bin/../lib/gcc/microblaze/3.4.1/../../../../microblaze/bin/ld.real:
section .data [0000037c -> 000003a7] overlaps section .text [00000050 ->
00002463]
/cygdrive/c/EDK/gnu/microblaze/nt/bin/../lib/gcc/microblaze/3.4.1/../../../../microblaze/bin/ld.real:
section .ctors [000003a8 -> 000003af] overlaps section .text [00000050 ->
00002463]
/cygdrive/c/EDK/gnu/microblaze/nt/bin/../lib/gcc/microblaze/3.4.1/../../../../microblaze/bin/ld.real:
section .dtors [000003b0 -> 000003b7] overlaps section .text [00000050 ->
00002463]
/cygdrive/c/EDK/gnu/microblaze/nt/bin/../lib/gcc/microblaze/3.4.1/../../../../microblaze/bin/ld.real:
section .jcr [000003b8 -> 000003bb] overlaps section .text [00000050 ->
00002463]
collect2: ld returned 1 exit status
make: *** [TestApp_Memory/executable.elf] Error 1

Article: 123051
Subject: Re: edk + spi
From: "u_stadler@yahoo.de" <u_stadler@yahoo.de>
Date: Wed, 15 Aug 2007 03:39:59 -0700
Links: << >>  << T >>  << A >>
On 14 Aug., 08:58, Antti <Antti.Luk...@googlemail.com> wrote:
> On 14 Aug., 08:53, "u_stad...@yahoo.de" <u_stad...@yahoo.de> wrote:
>
> > hi
>
> > is there a reason why the clock divisor for the spi clock in edk 9.1
> > cant be smaller than 16?
> > i would need 4. is there a way to do that or do i have to write my own
> > spi module?
>
> > thanks
> > urban
>
> its simpler to write your own, besides the OPB_SPI is very bad in
> terms of logic levels,
> very often it is reducing the max clock of the entire system
>
> hm, I think some xilinx ref design includes some other SPI core
> and there is free SPI core from finger lakes also
>
> http://spreadsheets.google.com/ccc?key=ptIl7po0K1kGmgMEYsJIUPw
> there are some links
>
> Antti

hi

thanks for the answer but i can't open the file. it says i don't have
access rights.

urban


Article: 123052
Subject: Re: Multiplication Problem on Microblaze Software
From: Jon Beniston <jon@beniston.com>
Date: Wed, 15 Aug 2007 03:51:53 -0700
Links: << >>  << T >>  << A >>
On 15 Aug, 11:39, "mfgunes" <mfgu...@yahoo.com> wrote:
> Hi,
>
> I want to do multiplication operation in my Microblaze's Test_Application
> in Xilinx Plaform Studio.
> But i get some errors.can you help me?
>
> This my code
>
> temp1=j=16;
> temp2=temp1*0.5;//error occurs when i use " * "
> *com2=(temp2);
>

You're doing some floating point multiplication which causes the
floating point math libraries to be linked in, which is then causing
you to run out of code memory space.

Try dividing by 2 instead of * 0.5.

If you really do want to do floating point math, you'll have to
increase the size of your memory.

Cheers,
Jon


Article: 123053
Subject: Re: Xilinx DDR2 SDRAM controller performance
From: Andrew Burnside <andrew.burnside@sli-institute.ac.uk>
Date: Wed, 15 Aug 2007 03:55:24 -0700
Links: << >>  << T >>  << A >>
On Aug 14, 9:53 pm, bruce_hw_...@hotmail.com wrote:
> I am using the MIG generated DDR2 controller in a V5 device. The DDR2
> runs at 266 MHz. I am meeting timing, but I am finding the performance
> of the controller to be a little dissapointing.

Which MIG version are you using?
Xilinx changed the controller algorithm between versions 1.6 and 1.7
of MIG.

In a Xilinx webcast on the MIG DDR2, they explained that one of the
areas that people may want to modify is the bank switching algorithm,
as their controller can only maintain a limited number of banks open
at a time.
This will probably have an impact on your random access performance.

Have you compared the bus utilisation with that when you write
contiguous blocks?
That way, you will know for definite if that is your issue.

Andrew


Article: 123054
Subject: Re: DDR/DDR2 controller - core
From: Andrew Burnside <andrew.burnside@sli-institute.ac.uk>
Date: Wed, 15 Aug 2007 04:03:09 -0700
Links: << >>  << T >>  << A >>
On Aug 13, 7:37 pm, pgw <"SwietyMikolaj["@]poczta.onet.pl> wrote:
> AndrewBurnsidewrote:
> > Certainly Xilinx has DDR 1/2 controllers available that plug onto
> > their micro cores.
>
> I can not find them, are you sure?
>
> > This would be less error prone than hacking around with a MIG design,
> > unless producing a controller is the main part of your academic
> > project.
>
>From the IP section of the Xilinx website:
Multi Channel OPB DDR2 Controller
The Xilinx Multi-Channel On-chip Peripheral Bus Double Data Rate
Synchronous DRAM (MCH OPB DDR2 SDRAM) controller for Xilinx FPGAs
provides a DDR2 SDRAM controller that connects to the OPB and multiple
channel interfaces and provides the control interface for DDR2 SDRAMs.
It is assumed that the reader is familiar with DDR2 SDRAM and the MCH
protocol.


Article: 123055
Subject: Re: Xilinx PACKER warning bout carry
From: Alan Nishioka <alan@nishioka.com>
Date: Wed, 15 Aug 2007 04:47:17 -0700
Links: << >>  << T >>  << A >>
Are you sure you need > (greater than) operator here?
This requires a subtraction and a carry chain, so your counter needs
two carry chains and won't pack.
Can you use not-equal instead?

(This also applies to < (less than) operator)

Alan Nishioka


On Aug 14, 6:17 pm, "Brad Smallridge" <bradsmallri...@dslextreme.com>
wrote:
> What does this "PACKER" warning
> mean?
>
> Lut _ driving carry _ can not
> be packed with the carry due
> to conflict with the common
> signal requirement between Lut
> inputs and the Carry DI/MAND pins.
> This would result in an extra Lut
> for a feedthrough.
>
> Here is the VHDL code:
>
>  count_int_proc:process(clk)
>  begin
>  if(clk'event and clk='1')then
>    if(reset='1')then
>      count_int <= start_value;
>    elsif( enable='1') then
>      if(up='1' and count_int<max)then
>        count_int<=count_int+1;
>      elsif( down='1'and count_int>0) then
>        count_int<=count_int-1;
>      end if;
>    end if;
>  end if;
>  end process;
>
> Thanks,
> Brad Smallridge
> AI Vision



Article: 123056
Subject: Re: Multiplication Problem on Microblaze Software
From: "mfgunes" <mfgunes@yahoo.com>
Date: Wed, 15 Aug 2007 07:22:14 -0500
Links: << >>  << T >>  << A >>
Hi,
I increased the size of the memory and i checked the "Enable Floating
Point Unit".Still i am facing with same errors.





>On 15 Aug, 11:39, "mfgunes" <mfgu...@yahoo.com> wrote:
>> Hi,
>>
>> I want to do multiplication operation in my Microblaze's
Test_Application
>> in Xilinx Plaform Studio.
>> But i get some errors.can you help me?
>>
>> This my code
>>
>> temp1=j=16;
>> temp2=temp1*0.5;//error occurs when i use " * "
>> *com2=(temp2);
>>
>
>You're doing some floating point multiplication which causes the
>floating point math libraries to be linked in, which is then causing
>you to run out of code memory space.
>
>Try dividing by 2 instead of * 0.5.
>
>If you really do want to do floating point math, you'll have to
>increase the size of your memory.
>
>Cheers,
>Jon
>
>



Article: 123057
Subject: Re: Delaying a pulse train
From: lb.edc@telenet.be
Date: Wed, 15 Aug 2007 12:33:23 GMT
Links: << >>  << T >>  << A >>
Martin,

At the end this will result in using LUT's as long shift register or a
DPRAM as FIFO, doesn't it?
A memory based approach can save up the usage of LUTs. I think it's
best to implement by using block RAM's.

Luc

On Tue, 14 Aug 2007 18:52:39 -0000, m <martin.usenet@gmail.com> wrote:

>I have to delay a pulse train by a given number of clocks on the same
>domain as the pulse to be delayed.
>
>The best approach I can think of is to run a counter of sufficient
>width and log pulse transitions and states into a circular "pulse
>transition list" of sufficient depth.  After waiting for the desired
>number of clock transitions (the delay) an output counter of the same
>width as the input sample counter is allowed to start counting.  This
>counter is used to address the "pulse transition list" to generate a
>delayed output that matches the input.
>
>Using SelectRAM memory for delay is out of the question as too much
>memory would be required and it is needed elsewhere in the design.
>
>
>Can anyone suggest a better way to do this?  The incoming pulses are
>relatively regular and can be of any duration, from a few clocks to
>hundreds.
>
>Thanks,
>
>-Martin

Article: 123058
Subject: Re: SDRAM Controller
From: Gabor <gabor@alacron.com>
Date: Wed, 15 Aug 2007 05:44:41 -0700
Links: << >>  << T >>  << A >>
On Aug 14, 2:50 pm, "maxascent" <maxasc...@yahoo.co.uk> wrote:
> Hi
>
> I have designed an SDRAM controller and nearly ready to synth and P&R. My
> question is do I need to add any offset constraints to the ucf? I see that
> the Xilinx XAPP134 uses them but the newer DDR designs which are generated
> using MIG do not. Any info would be appreciated?
>
> Cheers
>
> Jon


It's important to constrain any timing that is critical to the SDRAM.
Normally you can use offset constraints to require outputs to switch
within a specified time of the input clock.  However in a design where
all of the outputs are constrained to use IOB flip-flops, there is
really no room for place & route to change the timing offset, unless
you're not using global clock resources.  This may be why there are
no offset constraints in the MIG.


Article: 123059
Subject: Re: Multiplication Problem on Microblaze Software
From: "Göran Bilski" <goran.bilski@xilinx.com>
Date: Wed, 15 Aug 2007 15:21:51 +0200
Links: << >>  << T >>  << A >>
Hi,

You are mixing int and floating-point types without an explicit 
type-casting.
The default implicit type-casting in C for floating point is to use 
double-precision.
Since the HW FPU for microblaze is only for single-precision, the 
software-based double precision library is needed and this libary will be 
linked in to your application.

You should avoid implicit type-casting and you also have to decide if you 
need double precision floating point or single precision.
This example can be done completely using integer operation and would make 
the program size much smaller.

You can check the size of the program with mb-size and see if it fits into 
the memory.

Göran Bilski


"mfgunes" <mfgunes@yahoo.com> wrote in message 
news:vMadnfW6uvJrcl_bRVn_vgA@giganews.com...
> Hi,
> I increased the size of the memory and i checked the "Enable Floating
> Point Unit".Still i am facing with same errors.
>
>
>
>
>
>>On 15 Aug, 11:39, "mfgunes" <mfgu...@yahoo.com> wrote:
>>> Hi,
>>>
>>> I want to do multiplication operation in my Microblaze's
> Test_Application
>>> in Xilinx Plaform Studio.
>>> But i get some errors.can you help me?
>>>
>>> This my code
>>>
>>> temp1=j=16;
>>> temp2=temp1*0.5;//error occurs when i use " * "
>>> *com2=(temp2);
>>>
>>
>>You're doing some floating point multiplication which causes the
>>floating point math libraries to be linked in, which is then causing
>>you to run out of code memory space.
>>
>>Try dividing by 2 instead of * 0.5.
>>
>>If you really do want to do floating point math, you'll have to
>>increase the size of your memory.
>>
>>Cheers,
>>Jon
>>
>>
>
> 



Article: 123060
Subject: Re: Xilinx DDR2 SDRAM controller performance
From: bruce_hw_guy@hotmail.com
Date: Wed, 15 Aug 2007 06:33:57 -0700
Links: << >>  << T >>  << A >>
Hi Andrew, thanks for your response.

I'm using MIG version 1.7.  I have modified the contoller code to fix
a bug where the MULTI_BANK_EN is incorrectly being defined as an
integer 1. This is now defined as 1b'1.  Before I did that the
controller would issue a new active command even when the next access
was to a bank/row that was already open.

I have run a test where all of my accesses are to the same bank and
row. The test would write 128 bytes (toggling only col address bits)
read it back, write another 128 bytes, read it back, and so on.  This
test achieved 51% data bus utilization. If I did a similar test where
only bank address bits toggled I could sustain 41% utilization.
Neither  of these scenarios are very practical, but it tells me that
even under the best conditions the bus is idle half the time.

If I only read, or only write, than the controller can come close to
100% utilization, but that's not going to do me much good.

-Bruce


Article: 123061
Subject: Re: Multiplication Problem on Microblaze Software
From: "RCIngham" <robert.ingham@gmail.com>
Date: Wed, 15 Aug 2007 08:53:19 -0500
Links: << >>  << T >>  << A >>
Keep increasing the memory until the error messages go away.

If that is "too much memory" then you cannot use floating-point.

Note that "multiply by 0.5" is equivalent to "divide by 2" is equivalent
to (for integer variables) "shift right by 1".

>Hi,
>I increased the size of the memory and i checked the "Enable Floating
>Point Unit".Still i am facing with same errors.
>


Article: 123062
Subject: Re: Design Behavior affected by use of Chipscope
From: MNiegl <Michael.Niegl@cern.ch>
Date: Wed, 15 Aug 2007 06:55:59 -0700
Links: << >>  << T >>  << A >>
Hi John,
As far as I can tell until now I think it is an issue of the placement
of the FFs in the datapath to the RAM. I think next I will try to find
a stable configuration (w. Chipscope) and then directly lock the
placement of these FFs, we'll see if that helps. I'll probably get
back to you once I have more news.

Thanks & Cheers,
Michael


Article: 123063
Subject: Re: DDR/DDR2 controller - core
From: "RCIngham" <robert.ingham@gmail.com>
Date: Wed, 15 Aug 2007 09:00:11 -0500
Links: << >>  << T >>  << A >>
DRAM is tricky because of the multiplexed row/column addresses, and the
need to consider device refresh.

DDR is tricky because of the need to output and acquire data on both edges
of the clock.

Use old-fashioned SRAM if at all possible. Unless you are an 'intellectual
masochist' with a lot of spare time...




Article: 123064
Subject: ChipHit: ASIC, FPGA, EDA Search Engine
From: ted <ted.boydston@gmail.com>
Date: Wed, 15 Aug 2007 14:24:21 -0000
Links: << >>  << T >>  << A >>
Hi,

I recently created a Google custom search engine called ChipHit at
http://www.chiphit.com.  Please take a look and provide suggestions.

I spend many hours a day searching the internet for ASIC, FPGA, and
EDA tool topics as I am ASIC/FPGA applications engineer. Frequently,
when searching, I would come across results from Google that would
require significant digging to get to the "right" answer. It was very
frustrating. One day I was searching for a particular topic and came
across a feature of Google that allows you to customize the Google
search engine by telling the engine to only search specific sites. So,
I started populating the engine with a few sites, and quickly realized
that this could be valuable to more than just me. I went home, bought
the ChipHit domain name and bought some space on a web hosting
service, and began madly customizing the Google search engine.

So, the next time you are searching for an ASIC, FPGA, or EDA topic,
why not check out http://www.chiphit.com.

Thanks,
Ted


Article: 123065
Subject: Re: ChipHit: ASIC, FPGA, EDA Search Engine
From: "RCIngham" <robert.ingham@gmail.com>
Date: Wed, 15 Aug 2007 10:28:59 -0500
Links: << >>  << T >>  << A >>
Initial impression is that it looks rather useful.
Ta!


Article: 123066
Subject: Re: Xilinx PACKER warning bout carry
From: Andy <jonesandy@comcast.net>
Date: Wed, 15 Aug 2007 08:31:25 -0700
Links: << >>  << T >>  << A >>
On Aug 14, 8:17 pm, "Brad Smallridge" <bradsmallri...@dslextreme.com>
wrote:
> What does this "PACKER" warning
> mean?
>
> Lut _ driving carry _ can not
> be packed with the carry due
> to conflict with the common
> signal requirement between Lut
> inputs and the Carry DI/MAND pins.
> This would result in an extra Lut
> for a feedthrough.
>
> Here is the VHDL code:
>
>  count_int_proc:process(clk)
>  begin
>  if(clk'event and clk='1')then
>    if(reset='1')then
>      count_int <= start_value;
>    elsif( enable='1') then
>      if(up='1' and count_int<max)then
>        count_int<=count_int+1;
>      elsif( down='1'and count_int>0) then
>        count_int<=count_int-1;
>      end if;
>    end if;
>  end if;
>  end process;
>
> Thanks,
> Brad Smallridge
> AI Vision

If you use an integer subtype for count_int and check for
"not(count_int - 1 < 0)" or "not (count_int + 1 > max)" then the carry
out of the incrementor and decrementor can be shared with the
respective comparison (and/or similarly optimized). That's also
assuming max = 2**N-1 for positive integer N. Don't try this with SLV
or UNSIGNED.

Andy


Article: 123067
Subject: Re: Delaying a pulse train
From: nospam <nospam@please.invalid>
Date: Wed, 15 Aug 2007 16:59:13 +0100
Links: << >>  << T >>  << A >>
m <martin.usenet@gmail.com> wrote:

>On Aug 14, 3:42 pm, Peter Alfke <pe...@xilinx.com> wrote:
>> Huffman run-length encoding has been used successfully in early-
>> generation fax machines.
>> Whether that or any other compression (e.g. edge-detection) scheme is
>> good, depends on the characteristics of the bitstream in question.
>> Peter Alfke
>
>I should have also mentioned that there's a need to delay more than
>one such pulse streams (at least four).  That would require about
>twenty 18K BRAMS...I use that many without going to a significantly
>larger device.

I think the description of your solution in your original post was rather
confused. 

To me your "circular pulse transition list" needs to be a FIFO.  If you
only record transitions you need wide counters and FIFO to handle wide
pulse spacing. A very long 1 bit FIFO is the opposite extreme.

The optimum will be run length encoding with a FIFO width of something in
between (assuming there is no pattern to the pulse data which a compression
scheme could exploit). 

1 bit to indicate the data state and n bits of count of clock cycles at
that state. For multiple streams you can add more data bits and use only
one set of encoding/decoding logic and one larger FIFO. 



-- 

Article: 123068
Subject: Re: Xilinx DDR2 SDRAM controller performance
From: nico@puntnl.niks (Nico Coesel)
Date: Wed, 15 Aug 2007 16:46:44 GMT
Links: << >>  << T >>  << A >>
bruce_hw_guy@hotmail.com wrote:

>Hi Andrew, thanks for your response.
>
>I'm using MIG version 1.7.  I have modified the contoller code to fix
>a bug where the MULTI_BANK_EN is incorrectly being defined as an
>integer 1. This is now defined as 1b'1.  Before I did that the
>controller would issue a new active command even when the next access
>was to a bank/row that was already open.
>
>I have run a test where all of my accesses are to the same bank and
>row. The test would write 128 bytes (toggling only col address bits)
>read it back, write another 128 bytes, read it back, and so on.  This
>test achieved 51% data bus utilization. If I did a similar test where
>only bank address bits toggled I could sustain 41% utilization.
>Neither  of these scenarios are very practical, but it tells me that
>even under the best conditions the bus is idle half the time.
>
>If I only read, or only write, than the controller can come close to
>100% utilization, but that's not going to do me much good.

I suppose this has to do with transaction pipelining and ordering. In
theory you can setup a read or write access in another bank so it
commences right after finishing the current bank. This make the
controller a lot more complex. Don't forget the MIG tool is a
demonstrator!

-- 
Reply to nico@nctdevpuntnl (punt=.)
Bedrijven en winkels vindt U op www.adresboekje.nl

Article: 123069
Subject: Re: Amount of wire and logic
From: Pasacco <pasacco@gmail.com>
Date: Wed, 15 Aug 2007 10:14:03 -0700
Links: << >>  << T >>  << A >>
It is interesting to see the Rent's rule.

You can help me better understand the relationship.

For example, suppose :
Xilinx FPGA has a regular structure of CLBs.
Each CLB contains one SWITCH BOX and 4 SLICEs.
Each SLICE has approximately 40 pins.
Each CLB has approximately 400 pins.

Consider, device 1 has 100 CLBs and device 2 has 10000 CLBs.

According to your posting:
Device 2 is supposed to have "100^1.5" times more wires than device 1.
Device 2 is supposed to have "100^2" more area than device 1.
Am I understanding correctly?

It was mentioned that:
--------------------------------------------------------------
Number of wires grows at a rate of somewhat over  g^1.5 and the area
of the wires (because the  avarage length is g^0.5) grows faster than
g^2
--------------------------------------------------------------

Could you please explain why :

(1) Average length is "g^0.5",
==> Does this 'length' mean by "wire length" ?
       How did you obtain the value '0.5' ?

(2) Number of wires grows over "g^1.5",
==> How did you obtain the value '1.5' ?

(3) Area of wires grows faster than "g^2" ?
==> How did you obtain the value '2' ?

It will be appreciated if you provide some example :).
Thank you very much.



Article: 123070
Subject: Re: ChipHit: ASIC, FPGA, EDA Search Engine
From: yttrium <yttrium@telenet.be>
Date: Wed, 15 Aug 2007 19:37:42 +0200
Links: << >>  << T >>  << A >>
ted wrote:
> Hi,
> 
> I recently created a Google custom search engine called ChipHit at
> http://www.chiphit.com.  Please take a look and provide suggestions.
> 
> I spend many hours a day searching the internet for ASIC, FPGA, and
> EDA tool topics as I am ASIC/FPGA applications engineer. Frequently,
> when searching, I would come across results from Google that would
> require significant digging to get to the "right" answer. It was very
> frustrating. One day I was searching for a particular topic and came
> across a feature of Google that allows you to customize the Google
> search engine by telling the engine to only search specific sites. So,
> I started populating the engine with a few sites, and quickly realized
> that this could be valuable to more than just me. I went home, bought
> the ChipHit domain name and bought some space on a web hosting
> service, and began madly customizing the Google search engine.
> 
> So, the next time you are searching for an ASIC, FPGA, or EDA topic,
> why not check out http://www.chiphit.com.
> 
> Thanks,
> Ted
> 

looks interesting ...

Article: 123071
Subject: Re: Amount of wire and logic
From: Peter Alfke <peter@xilinx.com>
Date: Wed, 15 Aug 2007 10:43:53 -0700
Links: << >>  << T >>  << A >>
Pasacco, you are mixing up two things: Renz' rule, and real FPGAs
A real FPGA family does not span a 100-to-one size ratio. Usually just
10-to-1.
In Xilinx FPGAs, the area is roughly proportional to the number of
CLBs or Slices or LUTs, pick your preferred measurement. This picture
gets more complex due to the large number of non-CLB elements (BRAMs,
I/O, multipliers, CPUs etc.) that also populate the FPGA. And play a
very important role in making the FPGA fast, efficient, and
competitive.
I assume yours is a theoretical discussion...
Peter Alfke


On Aug 15, 10:14 am, Pasacco <pasa...@gmail.com> wrote:
> It is interesting to see the Rent's rule.
>
> You can help me better understand the relationship.
>
> For example, suppose :
> Xilinx FPGA has a regular structure of CLBs.
> Each CLB contains one SWITCH BOX and 4 SLICEs.
> Each SLICE has approximately 40 pins.
> Each CLB has approximately 400 pins.
>
> Consider, device 1 has 100 CLBs and device 2 has 10000 CLBs.
>
> According to your posting:
> Device 2 is supposed to have "100^1.5" times more wires than device 1.
> Device 2 is supposed to have "100^2" more area than device 1.
> Am I understanding correctly?
>
> It was mentioned that:
> --------------------------------------------------------------
> Number of wires grows at a rate of somewhat over  g^1.5 and the area
> of the wires (because the  avarage length is g^0.5) grows faster than
> g^2
> --------------------------------------------------------------
>
> Could you please explain why :
>
> (1) Average length is "g^0.5",
> ==> Does this 'length' mean by "wire length" ?
>        How did you obtain the value '0.5' ?
>
> (2) Number of wires grows over "g^1.5",
> ==> How did you obtain the value '1.5' ?
>
> (3) Area of wires grows faster than "g^2" ?
> ==> How did you obtain the value '2' ?
>
> It will be appreciated if you provide some example :).
> Thank you very much.



Article: 123072
Subject: Re: Synthesizing fixed_pkg in ISE 9.2
From: Andreas Schwarz <usenet@andreas-s.net>
Date: Wed, 15 Aug 2007 11:46:54 -0700
Links: << >>  << T >>  << A >>
On 14 Aug., 03:52, David Bishop <dbis...@vhdl.org> wrote:
> Xilinx said that they were going to fix this in 9.3.  I have not had a
> chance to check it out yet, but I would try that first.

Thanks for the info. 9.3 isn't released yet, do you have any idea when
it will be?

Andreas


Article: 123073
Subject: Re: Xilinx PACKER warning bout carry
From: Mike Treseler <mike_treseler@comcast.net>
Date: Wed, 15 Aug 2007 12:19:09 -0700
Links: << >>  << T >>  << A >>
Brad Smallridge wrote:
> What does this "PACKER" warning
> mean?

The fitter feels guilty about one of the LUTs it used.
It's just a warning.
Unless I were short on LUTs I would
not spend time on it.

The code looks ok to me.
You could combine the up/down input.


      -- Mike Treseler

Article: 123074
Subject: Re: Delaying a pulse train
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Thu, 16 Aug 2007 07:40:44 +1200
Links: << >>  << T >>  << A >>
nospam wrote:
> m <martin.usenet@gmail.com> wrote:
> 
> 
>>On Aug 14, 3:42 pm, Peter Alfke <pe...@xilinx.com> wrote:
>>
>>>Huffman run-length encoding has been used successfully in early-
>>>generation fax machines.
>>>Whether that or any other compression (e.g. edge-detection) scheme is
>>>good, depends on the characteristics of the bitstream in question.
>>>Peter Alfke
>>
>>I should have also mentioned that there's a need to delay more than
>>one such pulse streams (at least four).  That would require about
>>twenty 18K BRAMS...I use that many without going to a significantly
>>larger device.
> 
> 
> I think the description of your solution in your original post was rather
> confused. 
> 
> To me your "circular pulse transition list" needs to be a FIFO.  If you
> only record transitions you need wide counters and FIFO to handle wide
> pulse spacing. A very long 1 bit FIFO is the opposite extreme.
> 
> The optimum will be run length encoding with a FIFO width of something in
> between (assuming there is no pattern to the pulse data which a compression
> scheme could exploit). 
> 
> 1 bit to indicate the data state and n bits of count of clock cycles at
> that state. For multiple streams you can add more data bits and use only
> one set of encoding/decoding logic and one larger FIFO. 

A good idea, but what if you want co-incident edges ?
Perhaps a small phase-nudge field, that passes to the IO block,
and allow sequential FIFO unloads, but coincident IO edges ?.

-jg





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