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 92925

Article: 92925
Subject: ISE purchase
From: "Roger" <enquiries@rwconcepts.co.uk>
Date: Fri, 09 Dec 2005 16:42:18 GMT
Links: << >>  << T >>  << A >>
I need to buy a license for ISE Foundation to support some VIIPro work I'm 
doing. Would it make any difference to the price if I went via a distributor 
here in the UK or just bought online via the Xilinx web site? Anyone have 
any comments?

TIA,

Rog. 



Article: 92926
Subject: Re: ISE = Intelligent Synthesis Expectable :-)
From: Jan Decaluwe <jan@jandecaluwe.com>
Date: Fri, 09 Dec 2005 17:52:27 +0100
Links: << >>  << T >>  << A >>
backhus wrote:
> Hi folks,
> I just stumbled over something funny:
> 
> I usually write FSMs with registered outputs similar to this example:
> 
> -- 
> -- $Id:
> -- 
> ARCHITECTURE behavioral OF DEC_Controller_Modi IS
> 
>   TYPE   DCM_state IS (Wait4Activation, Run_ECB, Run_CBC, Run_CFB, 
> Run_OFB, Run_CTR);
>   SIGNAL DCM_CurrentState : DCM_state;
>   SIGNAL DCM_NextState    : DCM_state;
> 
> BEGIN  -- ARCHITECTURE behavioral
> 
>   -- purpose: StateRegister for DEC_Controller FSM
>   -- type   : sequential
>   -- inputs : Clock, Reset, DCM_NextState
>   -- outputs: DCM_CurrentState
>   DCM_sync : PROCESS (Clock, Reset) IS
>   BEGIN  -- PROCESS  DCM_sync
>     IF Reset = '0' THEN                     -- asynchronous reset 
> (active low)
>       DCM_CurrentState <= Wait4Activation;
>     ELSIF Clock'event AND Clock = '1' THEN  -- rising clock edge
>       DCM_CurrentState <= DCM_NextState;
>     END IF;
>   END PROCESS DCM_sync;
> 
>   -- purpose: Branch logic for DEC_Controller FSM
>   -- type   : combinational
>   -- inputs : DCM_CurrentState, all
>   -- outputs: DCM_NextState
>   DCM_comb : PROCESS (DCM_CurrentState, ECB_Mode, CTR_Mode, 
> FeedbackSelect, AES_Ready, Phase1Active) IS
>   BEGIN  -- PROCESS DCM_comb
>     CASE DCM_CurrentState IS
>       WHEN Wait4Activation => IF AES_Ready = '1' AND Phase1Active = '0' 
> THEN
>                                 IF ECB_Mode = '0' THEN
>                                   IF CTR_Mode = '0' THEN
>                                     CASE FeedbackSelect IS
>                                       WHEN "001"  => DCM_NextState <= 
> Run_CBC;
>                                       WHEN "000"  => DCM_NextState <= 
> Run_CFB;
>                                       WHEN "011"  => DCM_NextState <= 
> Run_CFB;
>                                       WHEN "100"  => DCM_NextState <= 
> Run_CFB;
>                                       WHEN "101"  => DCM_NextState <= 
> Run_CFB;
>                                       WHEN "110"  => DCM_NextState <= 
> Run_CFB;
>                                       WHEN "111"  => DCM_NextState <= 
> Run_CFB;
>                                       WHEN "010"  => DCM_NextState <= 
> Run_OFB;
>                                       WHEN OTHERS => NULL;
>                                     END CASE;
>                                   ELSE
>                                     DCM_NextState <= Run_CTR;
>                                   END IF;
>                                 ELSE
>                                   DCM_NextState <= Run_ECB;
>                                 END IF;
>                               END IF;
>     WHEN Run_ECB => IF AES_Ready = '0' THEN
>                       DCM_NextState <= Wait4Activation;
>                     END IF;
>     WHEN Run_CBC => IF AES_Ready = '0' THEN
>                       DCM_NextState <= Wait4Activation;
>                     END IF;
>     WHEN Run_CFB => IF AES_Ready = '0' THEN
>                       DCM_NextState <= Wait4Activation;
>                     END IF;
>     WHEN Run_OFB => IF AES_Ready = '0' THEN
>                       DCM_NextState <= Wait4Activation;
>                     END IF;
>     WHEN Run_CTR => IF AES_Ready = '0' THEN
>                       DCM_NextState <= Wait4Activation;
>                     END IF;
>     --WHEN OTHERS => NULL;     -- all states covered
>   END CASE;
> END PROCESS DCM_comb;
> 
> -- purpose: Registered Outputs for DEC_Controller FSM
> -- type   : sequential
> -- inputs : Clock, Reset, all
> -- outputs: all
> DCM_regout : PROCESS (Clock, Reset) IS
> BEGIN  -- PROCESS DCM_regout
>   IF Reset = '1' THEN                     -- asynchronous reset (active 
> high)
>     Start_ECB      <= '0';
>     Start_CBC      <= '0';
>     Start_CFB      <= '0';
>     Start_OFB      <= '0';
>     Start_CTR      <= '0';
>     Phase2_3Active <= '0';                -- not active in Reset state
>   ELSIF Clock'event AND Clock = '1' THEN  -- rising clock edge
>     Start_ECB      <= '0';
>     Start_CBC      <= '0';
>     Start_CFB      <= '0';
>     Start_OFB      <= '0';
>     Start_CTR      <= '0';
>     Phase2_3Active <= '1';
>     CASE DCM_NextState IS
>       WHEN Wait4Activation => Phase2_3Active <= '0';
>       WHEN Run_ECB         => Start_ECB      <= '1';
>       WHEN Run_CBC         => Start_CBC      <= '1';
>       WHEN Run_CFB         => Start_CFB      <= '1';
>       WHEN Run_OFB         => Start_OFB      <= '1';
>       WHEN Run_CTR         => Start_CTR      <= '1';
>                               -- WHEN OTHERS => NULL;  -- all states 
> covered
>     END CASE;
>   END IF;
> END PROCESS DCM_regout;
> 
> END ARCHITECTURE behavioral;
> 
> ---------------------------------------------------------------------
> 
> While ISE creates a nice little FSM, Precision RTL and Synopsys Design 
> Analyser drop in a bunch of latches for the DCM_NextState signal bits.
> Well, from an isolated point of view they are right. My case statement 
> lacks default values (the "when others" has been commented out, because 
> Precision gives a warning, that all brances are covered).
> 
> So, what makes me wonder is that both expensive tools create 
> latch-loaded garbage while "cheap little" ISE synthesizes as expected by 
> me. Besides the ugly option of writing defaults into all when-brances, 
> is there any solution that pushes precision and/or synopsys dc to a 
> better synthesis?

A single line with the default, right before the case statement
in DCM_comb, should do it:

    DCM_NextState <= DCM_CurrentState;

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
     From Python to silicon:
     http://myhdl.jandecaluwe.com

Article: 92927
Subject: XC4VFX12 -- availability?
From: "acetylcholinerd@gmail.com" <acetylcholinerd@gmail.com>
Date: 9 Dec 2005 08:53:12 -0800
Links: << >>  << T >>  << A >>
I just made the mistake of spending a month designing a board for the
Virtex-4 FX without first checking availability. Xilinx has been
talking about the part for nearly a year, there are dev boards all over
the place, surely there must be silicon available, right? Now both
Avnet and NuHo are telling me that Xilinx is having "yield problems"
and it could be as late as June of 06 before they're shipping silicon.
Has anyone had any luck finding these parts? I'm just looking for a
couple samples to finish my thesis project, and it would be nice to not
have to spend another month redesigning this hardware...

Thanks,
   ...Eric


Article: 92928
Subject: Re: ISE purchase
From: "Antti Lukats" <antti@openchip.org>
Date: Fri, 9 Dec 2005 17:58:45 +0100
Links: << >>  << T >>  << A >>
"Roger" <enquiries@rwconcepts.co.uk> schrieb im Newsbeitrag 
news:Ktimf.6307$64.44@newsfe2-win.ntli.net...
>I need to buy a license for ISE Foundation to support some VIIPro work I'm 
>doing. Would it make any difference to the price if I went via a 
>distributor here in the UK or just bought online via the Xilinx web site? 
>Anyone have any comments?
>
> TIA,
>
> Rog.
>
check out development board package deals, sometimes it makes sense to buy 
some dev board with bundled ISE (or EDK) as the board price will then be 
haevily reduced compared to board+ISE price if purchased separatly.

antti




Article: 92929
Subject: Re: XC4VFX12 -- availability?
From: "Antti Lukats" <antti@openchip.org>
Date: Fri, 9 Dec 2005 18:02:15 +0100
Links: << >>  << T >>  << A >>
<acetylcholinerd@gmail.com> schrieb im Newsbeitrag 
news:1134147191.930994.183170@z14g2000cwz.googlegroups.com...
>I just made the mistake of spending a month designing a board for the
> Virtex-4 FX without first checking availability. Xilinx has been
> talking about the part for nearly a year, there are dev boards all over
> the place, surely there must be silicon available, right? Now both
> Avnet and NuHo are telling me that Xilinx is having "yield problems"
> and it could be as late as June of 06 before they're shipping silicon.
> Has anyone had any luck finding these parts? I'm just looking for a
> couple samples to finish my thesis project, and it would be nice to not
> have to spend another month redesigning this hardware...
>
> Thanks,
>   ...Eric
>

scary business we are shipping products with FX12 on board and we are just 
about to re-order parts, I know that all FX MGT production silicon is not be 
expected before Q3, but I did not assume any issues with FX12 part, as it 
was available looong time ago.

it could be that disties dont wanna have ES silicon in stock and they are 
using standard worst case lead time, so thats why it looks so bad for you. I 
bet FX12-ES in sample quantity should be obtainable.

Antti



Article: 92930
Subject: re:Job available... 2 projects
From: acidocinico@libero-dot-it.no-spam.invalid (acidocinico)
Date: Fri, 09 Dec 2005 11:16:00 -0600
Links: << >>  << T >>  << A >>
I'm very interested in this project.
I usually do High-Speed PCB design and FPGA 
programming at work so I think this board 
shouldn't be a problem for me. 
Anyway I've got a few questions for you:

- have you got full schematics of the original
designs or this has to be reverse-engineered?

- how many pieces of these boards do you
need?

- those 500$ are meant for each design or 
for each delivered PCB?

Best regards,
Vito

a c i d o c i n i c o (at) l i b e r o (dot) i t


Article: 92931
Subject: Re: XC4VFX12 -- availability?
From: Austin Lesea <austin@xilinx.com>
Date: Fri, 09 Dec 2005 09:17:04 -0800
Links: << >>  << T >>  << A >>
Antti,

Yes you are correct, there are no issues with FX12.

Austin

Antti Lukats wrote:

> <acetylcholinerd@gmail.com> schrieb im Newsbeitrag 
> news:1134147191.930994.183170@z14g2000cwz.googlegroups.com...
> 
>>I just made the mistake of spending a month designing a board for the
>>Virtex-4 FX without first checking availability. Xilinx has been
>>talking about the part for nearly a year, there are dev boards all over
>>the place, surely there must be silicon available, right? Now both
>>Avnet and NuHo are telling me that Xilinx is having "yield problems"
>>and it could be as late as June of 06 before they're shipping silicon.
>>Has anyone had any luck finding these parts? I'm just looking for a
>>couple samples to finish my thesis project, and it would be nice to not
>>have to spend another month redesigning this hardware...
>>
>>Thanks,
>>  ...Eric
>>
> 
> 
> scary business we are shipping products with FX12 on board and we are just 
> about to re-order parts, I know that all FX MGT production silicon is not be 
> expected before Q3, but I did not assume any issues with FX12 part, as it 
> was available looong time ago.
> 
> it could be that disties dont wanna have ES silicon in stock and they are 
> using standard worst case lead time, so thats why it looks so bad for you. I 
> bet FX12-ES in sample quantity should be obtainable.
> 
> Antti
> 
> 

Article: 92932
Subject: Re: XC4VFX12 -- availability?
From: "Antti Lukats" <antti@openchip.org>
Date: Fri, 9 Dec 2005 18:34:27 +0100
Links: << >>  << T >>  << A >>
"Austin Lesea" <austin@xilinx.com> schrieb im Newsbeitrag 
news:dnce6h$f694@xco-news.xilinx.com...
> Antti,
>
> Yes you are correct, there are no issues with FX12.
>
> Austin

HUH, thanks for quick clarification!

http://www.hydraxc.com

there isnothing muchonline, but the FX12 based modules are actually
shipping now, so knowing that the FX12 supply is ok is quite a bit important

antti




Article: 92933
Subject: Re: No, not FIFOs again...
From: "Peter Alfke" <peter@xilinx.com>
Date: 9 Dec 2005 09:46:47 -0800
Links: << >>  << T >>  << A >>
Thomas, what's wrong with CoreGen?
You can of course design your own FIFO controller, but it is tricky.
The two address counters live in different clock domains, and any
synchronization across the domain border must be done with Gray-codes
values. But for indicating ALMOST FULL, ALMOST  EMPTY, etc. you need
binary values. Therefore there are code translations going on that
require some expertise, especially when the clock rates are high.
You can contact me for some individual advice...(even in German)
Peter Alfke, Xilinx Applications

=============
Thomas Entner wrote:
> A need an asynch. FIFO for a Spartan 3E-design, without CoreGen. On the
> Xilinx-web-page I only found XAPP258, which I cannot use as I need a
> "level-indication" for both clock-domains. Is it possible that something
> basic as this is not available for free, or have I just looked in the wrong
> places? Do I need to implement this on my own?
> 
> Thomas
> 
> www.entner-electronics.com


Article: 92934
Subject: Re: How to connect 2 FPGA?
From: Carsten <xnews1@luna.kyed.com>
Date: Fri, 09 Dec 2005 19:01:04 +0100
Links: << >>  << T >>  << A >>
>
>> I must develop a system with lots of I/O, about 180-190. My chief don't
>> want use BGA (fg320), but pq208...
>> so I thought to connect 2 fpga pq208.
>
>> I think it'is bad... but there are other chances?
>
>> Otherwise does exist a BGA adapter for fg320 package to change it into a 
>> pq320?
>
>Why not use a FPGA module like the Zefant Modules? (www.zefant.de)?

I have one of those Zefant S3-1000 boards + Baseboard , it's an
excellent combination. 

There  is even 47 pcs. 5v tolerant CPLD pins in addition to the FPGA
pins.



Carsten

Article: 92935
Subject: Re: No, not FIFOs again...
From: "Thomas Entner" <aon.912710880@aon.at>
Date: Fri, 9 Dec 2005 19:11:27 +0100
Links: << >>  << T >>  << A >>
Hi Peter,

thanks for your answer. The only thing wrong with core-generator is that 
it's not included in the web pack ;-)

In the meantime I have bitten the bullet and implemented the FIFO myself. (I 
am well aware of those clock-domain crossing issues... and I do not need a 
complete full or complete empty-flag) It's already running in hardware.

The only thing missing is a timing-constraint to limit the skew of the 
gray-code-bits, when it passes from one clock-domain to the other. Or can I 
rely on ISE that the skew/delay of this path (from register to register, no 
logic between) will always be very small, as it is in the moment? BTW: How 
is this solved by the core-gen? Does it automatically apply these 
constraints?

Thomas

"Peter Alfke" <peter@xilinx.com> schrieb im Newsbeitrag 
news:1134150407.670912.197670@f14g2000cwb.googlegroups.com...
> Thomas, what's wrong with CoreGen?
> You can of course design your own FIFO controller, but it is tricky.
> The two address counters live in different clock domains, and any
> synchronization across the domain border must be done with Gray-codes
> values. But for indicating ALMOST FULL, ALMOST  EMPTY, etc. you need
> binary values. Therefore there are code translations going on that
> require some expertise, especially when the clock rates are high.
> You can contact me for some individual advice...(even in German)
> Peter Alfke, Xilinx Applications
>
> =============
> Thomas Entner wrote:
>> A need an asynch. FIFO for a Spartan 3E-design, without CoreGen. On the
>> Xilinx-web-page I only found XAPP258, which I cannot use as I need a
>> "level-indication" for both clock-domains. Is it possible that something
>> basic as this is not available for free, or have I just looked in the 
>> wrong
>> places? Do I need to implement this on my own?
>>
>> Thomas
>>
>> www.entner-electronics.com
> 



Article: 92936
Subject: Re: ISE purchase
From: "John Adair" <removethisthenleavejea@replacewithcompanyname.co.uk>
Date: Fri, 9 Dec 2005 18:16:14 -0000
Links: << >>  << T >>  << A >>
If you go the distributor they may offer a bundle with other items depending 
on your circumstances and project. If you are likely to want anything else 
then it may be the better path. Certainly should not be any more expensive 
than the website which tends to book pricing.

John Adair
Enterpoint Ltd. - Home of Broaddown2. The Ultimate Spartan3 Development 
Board.
http://www.enterpoint.co.uk

"Roger" <enquiries@rwconcepts.co.uk> wrote in message 
news:Ktimf.6307$64.44@newsfe2-win.ntli.net...
>I need to buy a license for ISE Foundation to support some VIIPro work I'm 
>doing. Would it make any difference to the price if I went via a 
>distributor here in the UK or just bought online via the Xilinx web site? 
>Anyone have any comments?
>
> TIA,
>
> Rog.
> 



Article: 92937
Subject: Re: partial reconfig of Virtex-4 : iMPACT warning makes the chip pause
From: Javier Castillo <javier.castillo@urjc.es>
Date: Fri, 09 Dec 2005 19:17:30 +0100
Links: << >>  << T >>  << A >>

Yes, impact send a command to stop the FPGA. One thing you can do it
to use the SelectMap interface or send the bitstream to the jtag
without using Impact. It is not very difficult to make a program in C
to program the FPGA using the JTAG.

Javier

On 9 Dec 2005 08:28:47 -0800, "Denaice" <dgalerin@gmail.com> wrote:

>Well, for the moment, I'm not reconfiguring through ICAP with a PPC or
>Microblaze. I'm only trying to reconfigure in JTAG by the remote PC,
>but it seems - obviously - that the FPGA pauses when reconfiguring
>(because in my design, the leds which, should continue to blink, are
>shut down).
>
>I don't know....

Article: 92938
Subject: Re: No, not FIFOs again...
From: "Antti Lukats" <antti@openchip.org>
Date: Fri, 9 Dec 2005 19:21:12 +0100
Links: << >>  << T >>  << A >>
"Thomas Entner" <aon.912710880@aon.at> schrieb im Newsbeitrag 
news:4399c8c0$0$15674$91cee783@newsreader01.highway.telekom.at...
> Hi Peter,
>
> thanks for your answer. The only thing wrong with core-generator is that 
> it's not included in the web pack ;-)
>
> In the meantime I have bitten the bullet and implemented the FIFO myself. 
> (I am well aware of those clock-domain crossing issues... and I do not 
> need a complete full or complete empty-flag) It's already running in 
> hardware.
>
> The only thing missing is a timing-constraint to limit the skew of the 
> gray-code-bits, when it passes from one clock-domain to the other. Or can 
> I rely on ISE that the skew/delay of this path (from register to register, 
> no logic between) will always be very small, as it is in the moment? BTW: 
> How is this solved by the core-gen? Does it automatically apply these 
> constraints?
>
> Thomas
>
Hi Thomas,

the fromto inside FPGA (no logic levels) can be as much as >10ns !!
if it passes local routing accross chip so if very small delays are needed
the the P&R must know it

Antti








Article: 92939
Subject: Adding "super-LUTs" to FPGA, good idea ?
From: Sylvain Munaut <com.246tNt@tnt>
Date: Fri, 09 Dec 2005 19:38:18 +0100
Links: << >>  << T >>  << A >>
Hi,

A thought cross my mind ...

I've been working much on Virtex4 lately and getting fast (~300-350 Mhz)
logic for the datapath isn't really hard. But making the control stuff
go that fast is a whole lot more tricky, just a 10 bits comparator
becomes "a lot" at that speed ... and some control signals have high
fanout and that brings the net delay in the 1 - 1.5 ns range which is
half of the period ...

So what if every now and then in the FPGA fabric, there was a small
cluster of like 1 CLB with "Super LUTs" that would have a whole lot
faster logic (but no special func like SRL and distributed ram) and
"bigger" drivers to charge/dischare the net faster to propagate the
controls.

Maybe it's un-feasible for some reason, it's just a thought ...


	Sylvain

Article: 92940
Subject: Re: Adding "super-LUTs" to FPGA, good idea ?
From: "Antti Lukats" <antti@openchip.org>
Date: Fri, 9 Dec 2005 19:43:38 +0100
Links: << >>  << T >>  << A >>
"Sylvain Munaut" <com.246tNt@tnt> schrieb im Newsbeitrag 
news:4399cf94$0$9070$ba620e4c@news.skynet.be...
> Hi,
>
> A thought cross my mind ...
>
> I've been working much on Virtex4 lately and getting fast (~300-350 Mhz)
> logic for the datapath isn't really hard. But making the control stuff
> go that fast is a whole lot more tricky, just a 10 bits comparator
> becomes "a lot" at that speed ... and some control signals have high
> fanout and that brings the net delay in the 1 - 1.5 ns range which is
> half of the period ...
>
> So what if every now and then in the FPGA fabric, there was a small
> cluster of like 1 CLB with "Super LUTs" that would have a whole lot
> faster logic (but no special func like SRL and distributed ram) and
> "bigger" drivers to charge/dischare the net faster to propagate the
> controls.
>
> Maybe it's un-feasible for some reason, it's just a thought ...
>
>
> Sylvain

I guess altera would claim they have it in the stratix ALm
AL
(Antti Lukats)





Article: 92941
Subject: Re: No, not FIFOs again...
From: "Thomas Entner" <aon.912710880@aon.at>
Date: Fri, 9 Dec 2005 19:53:30 +0100
Links: << >>  << T >>  << A >>
Hi Antti,

I had expected that :-(

Let's say, my critical FF's are:

signal read_cnt_gray: unsigned(8 downto 0) := (others => '0');            --  
in read-clock-domain
and
signal read_cnt_gray_pre_sync_wr: unsigned(8 downto 0) := (others => 
      -- in write-clock-domain

is there a way to add the timing-constraint in the VHDL-source (so that I 
can easily reuse the module for different designs, without always editing 
the ucf-file, etc.)?

Thomas

www.entner-electronics.com

> Hi Thomas,
>
> the fromto inside FPGA (no logic levels) can be as much as >10ns !!
> if it passes local routing accross chip so if very small delays are needed
> the the P&R must know it
>
> Antti



Article: 92942
Subject: Re: XC4VFX12 -- availability?
From: "Finn S. Nielsen" <removfinnstadel@tiscali.dk>
Date: Fri, 9 Dec 2005 20:25:59 +0100
Links: << >>  << T >>  << A >>
Yeah,

If there's no issues with FX12, meaning no important design errors (apart 
from the system manager which was cancelled..), yield problems etc, then
if sample quantity is all that's available, it can only be because all 
devices are being sold to big customers.
I guess the 80 nm factories in the world are being overloaded with work on 
producing new 80 nm chips from different companies and I
can think of one company that is having a lot of new chip revisions done 
these days...

Finn

"Antti Lukats" <antti@openchip.org> skrev i en meddelelse 
news:dncf71$t30$01$1@news.t-online.com...
> "Austin Lesea" <austin@xilinx.com> schrieb im Newsbeitrag 
> news:dnce6h$f694@xco-news.xilinx.com...
>> Antti,
>>
>> Yes you are correct, there are no issues with FX12.
>>
>> Austin
>
> HUH, thanks for quick clarification!
>
> http://www.hydraxc.com
>
> there isnothing muchonline, but the FX12 based modules are actually
> shipping now, so knowing that the FX12 supply is ok is quite a bit 
> important
>
> antti
>
>
> 



Article: 92943
Subject: Securing verilog source code
From: "fad" <fahad.arif@gmail.com>
Date: 9 Dec 2005 11:26:42 -0800
Links: << >>  << T >>  << A >>
Hi,
I know tha some EDA tools provide encryption feature to protect
confidentiality of the HDL source code but how do we do this in
ModelSim/FPGA Adv or in Xilinx ISE?
So that I can provide an encrypted source code to someone and yet it
works as real RTL desription.
Please suggest.
Thanks,
Fahad


Article: 92944
Subject: Xilinx ML40x VGA Documentation
From: "Brad Smallridge" <bradsmallridge@dslextreme.com>
Date: Fri, 9 Dec 2005 11:41:48 -0800
Links: << >>  << T >>  << A >>
I am looking for further documentation for the VGA connections on the ML40x 
boards.

ug82 says that there is 50MHz chips on the ML401s and 140MHz chips on the 
ML402s and ML403s.  The ML403's FX12 has reduced pins and only five bits per 
color.  I suppose the best VGA would therefore come from the ML402s.

From the schematic I see that the upper five bits per color are attached to 
Bank6 and the lower three bits per color are attached to Bank9.  There is a 
difference in drive voltage between the two banks, does the VGA chip care? 
Is there anyway to compensate with different drive currents.

I have a few UCF files with different stories. What does contingent mean in 
a UCF file?

Is there any other documents other than the Xilinx schematics and the VGA 
manufacturers data sheets?

Brad Smallridge
aivision.com







Article: 92945
Subject: Re: Xilinx ML40x VGA Documentation
From: "Antti Lukats" <antti@openchip.org>
Date: Fri, 9 Dec 2005 20:47:29 +0100
Links: << >>  << T >>  << A >>
"Brad Smallridge" <bradsmallridge@dslextreme.com> schrieb im Newsbeitrag 
news:11pjnhdoufq890a@corp.supernews.com...
>I am looking for further documentation for the VGA connections on the ML40x 
>boards.
>
> ug82 says that there is 50MHz chips on the ML401s and 140MHz chips on the 
> ML402s and ML403s.  The ML403's FX12 has reduced pins and only five bits 
> per color.  I suppose the best VGA would therefore come from the ML402s.
>
> From the schematic I see that the upper five bits per color are attached 
> to Bank6 and the lower three bits per color are attached to Bank9.  There 
> is a difference in drive voltage between the two banks, does the VGA chip 
> care? Is there anyway to compensate with different drive currents.
>
> I have a few UCF files with different stories. What does contingent mean 
> in a UCF file?
>
> Is there any other documents other than the Xilinx schematics and the VGA 
> manufacturers data sheets?
>
> Brad Smallridge
> aivision.com
>

the video dacs clock the data so as long as setup and hold times are met the 
different
banks for the DAC outputs should not be an issue. so the vga chip does not 
care.

Antti








Article: 92946
Subject: Re: Adding "super-LUTs" to FPGA, good idea ?
From: Sylvain Munaut <com.246tNt@tnt>
Date: Fri, 09 Dec 2005 21:02:25 +0100
Links: << >>  << T >>  << A >>

>>So what if every now and then in the FPGA fabric, there was a small
>>cluster of like 1 CLB with "Super LUTs" that would have a whole lot
>>faster logic (but no special func like SRL and distributed ram) and
>>"bigger" drivers to charge/dischare the net faster to propagate the
>>controls.
>>
>>Maybe it's un-feasible for some reason, it's just a thought ...
>>
>>
>>Sylvain
> 
> 
> I guess altera would claim they have it in the stratix ALm
> AL
> (Antti Lukats)

They do ?
I'm gonna check that out ...


	Sylvain

Article: 92947
Subject: Re: Adding "super-LUTs" to FPGA, good idea ?
From: "Antti Lukats" <antti@openchip.org>
Date: Fri, 9 Dec 2005 21:07:13 +0100
Links: << >>  << T >>  << A >>
"Sylvain Munaut" <com.246tNt@tnt> schrieb im Newsbeitrag 
news:4399e34b$0$10953$ba620e4c@news.skynet.be...
>
>>>So what if every now and then in the FPGA fabric, there was a small
>>>cluster of like 1 CLB with "Super LUTs" that would have a whole lot
>>>faster logic (but no special func like SRL and distributed ram) and
>>>"bigger" drivers to charge/dischare the net faster to propagate the
>>>controls.
>>>
>>>Maybe it's un-feasible for some reason, it's just a thought ...
>>>
>>>
>>>Sylvain
>>
>>
>> I guess altera would claim they have it in the stratix ALm
>> AL
>> (Antti Lukats)
>
> They do ?
> I'm gonna check that out ...
>
>
> Sylvain

not quite so but they claim to have 7-input lut capabilities for better 
logic opt.

antti






Article: 92948
Subject: Re: No, not FIFOs again...
From: "John_H" <johnhandwork@mail.com>
Date: Fri, 09 Dec 2005 21:25:17 GMT
Links: << >>  << T >>  << A >>
Something like NET *read_cnt_gray* MAXDELAY=3ns; perhaps?

"Thomas Entner" <aon.912710880@aon.at> wrote in message 
news:4399d29c$0$22256$91cee783@newsreader02.highway.telekom.at...
> Hi Antti,
>
> I had expected that :-(
>
> Let's say, my critical FF's are:
>
> signal read_cnt_gray: unsigned(8 downto 0) := (others => 
>       --  in read-clock-domain
> and
> signal read_cnt_gray_pre_sync_wr: unsigned(8 downto 0) := (others => -- in 
> write-clock-domain
>
> is there a way to add the timing-constraint in the VHDL-source (so that I 
> can easily reuse the module for different designs, without always editing 
> the ucf-file, etc.)?
>
> Thomas
>
> www.entner-electronics.com
>
>> Hi Thomas,
>>
>> the fromto inside FPGA (no logic levels) can be as much as >10ns !!
>> if it passes local routing accross chip so if very small delays are 
>> needed
>> the the P&R must know it
>>
>> Antti
>
> 



Article: 92949
Subject: Re: No, not FIFOs again...
From: "Peter Alfke" <peter@xilinx.com>
Date: 9 Dec 2005 13:28:08 -0800
Links: << >>  << T >>  << A >>
Thomas, it only depends on your clock speed. Even the domain-crossing
registers have a whole clock tick to make up their mind. With
Gray-coded values, you already assume that you might unavoidably clock
in a mixture of the older and the newer value, but that does not matter
with Gray codes. It's either the old or the new value, never anything
else.
In other words, you don't have to be super-fast, as long as you meet
the required (synchronous) timing constraints, determined by the clock
rates.

Peter Alfke, Xilinx Applications.




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