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 126375

Article: 126375
Subject: Re: Coolrunner in system programming - XAPP0058 - viable?
From: Didi <diditgi@gmail.com>
Date: Tue, 20 Nov 2007 08:38:43 -0800 (PST)
Links: << >>  << T >>  << A >>
Alex,

> Could you elaborate why you can't use other low power CPLD's, Lattice
> 4000Z, for example? I'm asking this question because in Lattice case
> there is C code supplied for you to make the kind of CPLD programming
> discussed in this thread very easy.

just had a look at the datasheet and I see no technical reason at all
not to use these - the devices are good.
 Can you please point me to the programming info available for them?

If I can adopt them and thus forget about Xilinx I would be a happy
man.

Thanks,

Dimiter

------------------------------------------------------
Dimiter Popoff               Transgalactic Instruments

http://www.tgi-sci.com
------------------------------------------------------

On Nov 20, 4:38 pm, Alex <engin...@gmail.com> wrote:
> On Nov 19, 4:19 pm, Didi <didi...@gmail.com> wrote:
>
> > > > Well the fact of the matter is that there is no CPLD on the market
> > > > to compete with all the coolrunner parameters at the same time - and
> > > > I do use them.
>
> > > Across the size range, you may be right.
> > > But at the highest volume end Atmel and Lattice have good low power
> > > offerings. Actel may start to impact > 128MC CPLDs
>
> > I would be really happy to see an alternative to the coolrunner,
> > especially if its documentation is less secretive. Until then,
> > we are all stuck with xilinx for CPLDs above a certain complexity
> > and below some power, which is why I am still trying to get some
> > way to use them (notice I even accept to use their software to
> > produce the jedec file, something unprecedented here).
>
> > > My understanding there is the parts were not externally foundry fab'd
> > > and when the plug was pulled on the fab line, that then killed the
> > > product line. ...
>
> > Well I do not find it very plausible - making a new coolrunner line
> > from scratch cannot have been easier than repeating an existing
> > product, mask sets and all being available.
> >  But whatever, their agreement with Philips was to support all
> > existing customers the way Philips had supported them.
> >  This has not been the case with us - we do have the jedec -> jtag
> > maps from Philips and we do not have these from Xilinx.
>
> > Dimiter
>
> > ------------------------------------------------------
> > Dimiter Popoff               Transgalactic Instruments
>
> >http://www.tgi-sci.com
> > ------------------------------------------------------
>
> Hi Dimiter,
>
> Could you elaborate why you can't use other low power CPLD's, Lattice
> 4000Z, for example? I'm asking this question because in Lattice case
> there is C code supplied for you to make the kind of CPLD programming
> discussed in this thread very easy.
>
> Alex


Article: 126376
Subject: Re: Virtex5 Evaluation Board
From: John Adair <g1@enterpoint.co.uk>
Date: Tue, 20 Nov 2007 09:09:41 -0800 (PST)
Links: << >>  << T >>  << A >>
Philipp

Have a look at Broaddown4 http://www.enterpoint.co.uk/moelbryn/broaddown4.html.
An alternative solution is the combination of our Broaddown2
(Spartan-3) with a add on Swinyard1 module. The Broaddown4 can
support
between 1-4(with 2 Swinyard1 modules) Virtex-4 LX40-160 or SX55
parts.
Swinyard1 has a single Virtex-4 LX40-160 or SX55.


Some outline details on our university program (UAP) is here
http://www.enterpoint.co.uk/uap/uap.html. Discounts are listed there
on some products, others are available, as are details of our
Synplicity deal for universities where they effectively get a free
license with a small pack of our low cost board Raggedstone1 and soon
hopefully some others.


John Adair
Enterpoint Ltd.




On 20 Nov, 16:04, Philipp <Patrick.Batema...@gmx.at> wrote:
> austin wrote:
> > Philipp,
>
> > Are you a university or school?  If so, you should contact the XUP
> > (Xilinx University Program).  We often grant (gift), or partially fund
> > university boards (like the Virtex II Pro board from Digilent that we
> > will provide the FPGA on -- the school only pays for the pcb, not the FPGA).
>
> Thanks for your answer Austin, yes I am at university. So I will check
> with the Xilinx University program. Unfortunately it seems that the
> board you are offering is too small for my purposes. I would need
> a evaluation board with at least a Virtex4 on it and around 25000
> to 30.000 slices.
>
> If anyone knows a good resource where I could get such a board I would
> be thankful for some feedback ;)
>
> Cheers,
> Philipp


Article: 126377
Subject: Why doesnt XST RAM for this VHDL description
From: Philipp <Patrick.Bateman23@gmx.at>
Date: Tue, 20 Nov 2007 17:29:58 +0000
Links: << >>  << T >>  << A >>
Hi,

I am using a Xilinx Virtex2 Board and would like
to have an instruction and data RAM. I was following
the guidelines in the XST 7.1 but there still must
be something wrong with my description. At the moment
around 16000 FF are inferred for my RAM. In addition
I get the warning that the rst and ram<$n0000> should be
in the sensitive list?

Cheers,
Philipp

library ieee;
use IEEE.std_logic_arith.all;
use ieee.std_logic_1164.all;
use ieee.std_logic_unsigned.all;

entity ram_prog is
     generic (
       SIZE          : integer := 512;
       WL_ADDR       : integer := 8;
       WL_DATA       : integer := 32
     );
	port (
	  clk    	: in std_logic;
	  rst 	    	: in std_logic;
       	  rw_addr_cp0 	: in std_logic_vector(WL_ADDR-1 downto 0);
           data_in_cp0 	: in std_logic_vector(WL_DATA-1 downto 0);
           data_out_cp0 	: out std_logic_vector(WL_DATA-1 downto 0);
           ew_cp0	: in std_logic
	);
end ram_prog;

architecture Behavior of ram_prog is

     type ram_type is array (0 to SIZE-1) of std_logic_vector (31 downto 0);
     signal ram : ram_type :=
     (
         X"15005304", X"2f501000", X"00000000",....
     );

     begin
       PROC_ram : process (clk, rw_addr_cp0)
       begin
         if (rst = '0') then -- optional reset
           data_out_cp0 <= (others => '0');
         elsif (clk'event and clk = '1') then
           -- memory write:
           if (ew_cp0 = '1') then
             if (unsigned(rw_addr_cp0) >= 0 and unsigned(rw_addr_cp0) <= 
SIZE-1) then
               ram(conv_integer(unsigned(rw_addr_cp0))) <= data_in_cp0;
             end if;
           end if;
         end if;

         -- memory read:
         if (unsigned(rw_addr_cp0) >= 0 and unsigned(rw_addr_cp0) <= 
SIZE-1) then
           data_out_cp0 <= ram(conv_integer(unsigned(rw_addr_cp0)));
         end if;
     end process PROC_ram;

end Behavior;

Article: 126378
Subject: Re: Why doesnt XST RAM for this VHDL description
From: mk <kal*@dspia.*comdelete>
Date: Tue, 20 Nov 2007 17:47:18 GMT
Links: << >>  << T >>  << A >>
On Tue, 20 Nov 2007 17:29:58 +0000, Philipp <Patrick.Bateman23@gmx.at>
wrote:

>Hi,
>
>I am using a Xilinx Virtex2 Board and would like
>to have an instruction and data RAM. I was following
>the guidelines in the XST 7.1 but there still must
>be something wrong with my description. At the moment
>around 16000 FF are inferred for my RAM. In addition
>I get the warning that the rst and ram<$n0000> should be
>in the sensitive list?
...
>     begin
>       PROC_ram : process (clk, rw_addr_cp0)
>       begin
>         if (rst = '0') then -- optional reset
>           data_out_cp0 <= (others => '0');
>         elsif (clk'event and clk = '1') then
>           -- memory write:
>           if (ew_cp0 = '1') then
>             if (unsigned(rw_addr_cp0) >= 0 and unsigned(rw_addr_cp0) <= 
>SIZE-1) then
>               ram(conv_integer(unsigned(rw_addr_cp0))) <= data_in_cp0;
>             end if;
>           end if;
>         end if;
>
>         -- memory read:
>         if (unsigned(rw_addr_cp0) >= 0 and unsigned(rw_addr_cp0) <= 
>SIZE-1) then
>           data_out_cp0 <= ram(conv_integer(unsigned(rw_addr_cp0)));
>         end if;
>     end process PROC_ram;
>
>end Behavior;

Are you sure you can reset memory? You also don't need the address on
the sensitivity list either.

Article: 126379
Subject: Re: Why doesnt XST RAM for this VHDL description
From: Philipp <Patrick.Bateman23@gmx.at>
Date: Tue, 20 Nov 2007 17:53:49 +0000
Links: << >>  << T >>  << A >>
mk wrote:
> On Tue, 20 Nov 2007 17:29:58 +0000, Philipp <Patrick.Bateman23@gmx.at>
> wrote:
> 
>> Hi,
>>
>> I am using a Xilinx Virtex2 Board and would like
>> to have an instruction and data RAM. I was following
>> the guidelines in the XST 7.1 but there still must
>> be something wrong with my description. At the moment
>> around 16000 FF are inferred for my RAM. In addition
>> I get the warning that the rst and ram<$n0000> should be
>> in the sensitive list?
> ...
>>     begin
>>       PROC_ram : process (clk, rw_addr_cp0)
>>       begin
>>         if (rst = '0') then -- optional reset
>>           data_out_cp0 <= (others => '0');
>>         elsif (clk'event and clk = '1') then
>>           -- memory write:
>>           if (ew_cp0 = '1') then
>>             if (unsigned(rw_addr_cp0) >= 0 and unsigned(rw_addr_cp0) <= 
>> SIZE-1) then
>>               ram(conv_integer(unsigned(rw_addr_cp0))) <= data_in_cp0;
>>             end if;
>>           end if;
>>         end if;
>>
>>         -- memory read:
>>         if (unsigned(rw_addr_cp0) >= 0 and unsigned(rw_addr_cp0) <= 
>> SIZE-1) then
>>           data_out_cp0 <= ram(conv_integer(unsigned(rw_addr_cp0)));
>>         end if;
>>     end process PROC_ram;
>>
>> end Behavior;
> 
> Are you sure you can reset memory? You also don't need the address on
> the sensitivity list either.

Yeah true, I have to get rid of the read address in the sensitivy list,
this is some knickknack of former implementations.

Article: 126380
Subject: Re: problem with adding custom logic to an IP core (xilinx edk)
From: Matthew Hicks <mdhicks2@uiuc.edu>
Date: Tue, 20 Nov 2007 18:10:16 +0000 (UTC)
Links: << >>  << T >>  << A >>
I just asked this question a couple of days ago.  For the complete answer 
and process, refer to my "EDK 9.1 Issues" post from 11-15-07.


---Matthew Hicks


> Hi all, I'm experiencing problems with adding custom logic to an IP
> core that I have generate in EDK. I changed the vhdl file of an auto-
> generated IP core that is connected via FSL to the FPGA, but the
> behaviour of the program remains still the same. I've tried also to
> re-
> import the modified core to the project, but I still get errors due to
> the fact that the file xparameters.h doesn't contains the appropriated
> names.
> How can I do to let EDK notice changes in vhdl files?
> Thank you in advance!
> Giulio
> 



Article: 126381
Subject: Re: 33+ Regs in PLB IPIF
From: Matthew Hicks <mdhicks2@uiuc.edu>
Date: Tue, 20 Nov 2007 18:12:18 +0000 (UTC)
Links: << >>  << T >>  << A >>
Yeah, I made extra sure this was happening.  Somehow, I've now got it to 
read and write up to 64 registers.


---Matthew Hicks


> Matthew Hicks wrote:
> 
>> I have created a custom peripheral in EDK 9.1/ISE 9.1 that needs to
>> have 100 registers and communicates with the PowerPC CPU via the PLB
>> bus.
>> 
> [snip]
> 
>> Therefore, I selected 32 registers and tried to change the
>> USER_NUM_CE
>> constant in the top-level module in the
>> created template to 128, as opposed to 32.  I have read the PLB IPIF
>> datasheet from Xilinx, which only says that USER_NUM_CE needs to be a
>> power of two, which is why I used 128 versus 100.  After
>> implementation,
>> access to any register above 32 leads to a returned value of zero,
>> when
>> it should be non-zero.  Any suggestions of what else I need to change
>> in
>> the generated IPIF code to get this working?
> The wizard generates 2 files, the top file and the user logic file.
> Make sure that the constants are set up correctly in both files.
> 
> ---
> Joe



Article: 126382
Subject: Re: Why doesnt XST RAM for this VHDL description
From: Philipp <Patrick.Bateman23@gmx.at>
Date: Tue, 20 Nov 2007 18:13:40 +0000
Links: << >>  << T >>  << A >>

> Yeah true, I have to get rid of the read address in the sensitivy list,
> this is some knickknack of former implementations.

Alright, corrected some mistakes and now it seems fine :)

     begin
       PROC_ram : process (clk, rw_addr_cp0)
       begin
         if (clk'event and clk = '1') then
           -- memory write:
           if (ew_cp0 = '1') then
               ram(conv_integer(unsigned(rw_addr_cp0))) <= data_in_cp0;
             end if;
		    if (rst = '0') then -- optional reset
             data_out_cp0 <= (others => '0');
			 else
             data_out_cp0 <= ram(conv_integer(unsigned(rw_addr_cp0)));
			 end if;
         end if;
     end process PROC_ram;

Cheers,
Philipp

Article: 126383
Subject: FPGA Editor (9.2.03i) under Linux x86_64
From: Jan Pech <no@spam.please>
Date: Tue, 20 Nov 2007 19:17:26 +0100
Links: << >>  << T >>  << A >>
I am not able to run the fpga_editor (64-bit ISE install) under my
Fedora 7, x86_64 system. After I set the DISPLAY variable to :0 (instead
of my :0.0 or :0.1) and trying to start it, I get following output:


/opt/xilinx_92/bin/lin64/_fpga_editor: Symbol `_XtperDisplayList' causes
overflow in R_X86_64_PC32 relocation
/opt/xilinx_92/bin/lin64/_fpga_editor: Symbol `_XtGetPerDisplayInput'
causes overflow in R_X86_64_PC32 relocation

Cannot register service: RPC: Authentication error; why = Client
credential too weak
unable to register (registryProg, registryVers, tcp)

Wind/U Error (248): Failed to connect to the registry on server
workstation.cholunna.local

Warning!!: XKEYSYMDB environment variable is set to a wrong location 
Cannot register service: RPC: Authentication error; why = Client
credential too weak
Overriding Xilinx file <helpmap/fpga_editor.map> with local file
</opt/xilinx_92/data/helpmap/fpga_editor.map>


Is there any chance to make it running? Does it run at least in 32-bit
ISE install? Before I used 32-bit ISE 8.2 on the same system and
fpga_editor worked fine.

By the way, why FPGA editor is still Windows application running under
Wind/U environment while the rest of Xilinx tools run native in Linux? I
do not understand.

Thanks,
Jan


Article: 126384
Subject: Re: New Laptop for work
From: General Schvantzkoph <schvantzkoph@yahoo.com>
Date: 20 Nov 2007 18:36:15 GMT
Links: << >>  << T >>  << A >>
On Fri, 16 Nov 2007 17:22:34 -0800, rickman wrote:

> I am looking at a low end Dell laptop, the Vostro 1500, as a new
> computer for work.  I may supplement this later with a new desktop unit
> for crunching FPGA designs, but I will also be using this laptop for
> this sort of work.  I am looking for advice on the differences in CPUs
> for FPGA work and anything else that is relevant.
> 
> I know that parallel ports are going the way of the serial port and the
> dodo bird, but I can live with that.  Most tools are available as USB
> devices now.
> 
> This particular computer comes with WindowsXP rather than Vista.  From
> what I have heard, that is an advantage.  But I notice that the internal
> bluetooth adapter is specific for XP and others from Dell are specific
> for Vista.  Any idea what is up with that?  Is there any significant
> advantage to using XP pro over XP home?
> 
> This machine also has the "Intel(R) Integrated Graphics Media
> Accelerator X3100".  Is that just another way of saying "integrated
> video"?  Several of my other machines have had integrated video and it
> does seem to drag down the CPU noticeably.  Any idea if I will notice
> the drag on the Core 2 Duo?  They also offer an Nvidia Gforce 8400 GS
> adapter for $100 and an 8600 for $200 more.  Any idea if these are worth
> it?  The 1500 says it has "VGA video output & S-Video".  Does that mean
> I can connect two monitors for dual display?
> 
> The CPU is a T5270 (1.4 GHz, 2 MB cache) with upgrades to various
> processors for significant money.  The first stepup is to a T5470 (1.6
> GHz) for $75 and others range up to $575!  I am thinking I can live with
> the slower processor.  The memory is 2GB.
> 
> I was looking at the Vostro 1000 earlier this week with an AMD TK-53
> processor (1.5 GHz, 512 KB cache) and a smaller hard drive.  It was $50
> more so the 1500 looks like the better deal.  Are there any significant
> differences in the two CPUs for FPGA work?  I guess the small cache of
> the TK-53 would make it significantly slower for FPGA work.
> 
> I saw a thread from earlier this year discussing some of this.  I wonder
> how much laptops have improved since then.

I'm waiting until January when the Penryns come out. The Penryns have 6M 
caches and amazingly low power. NCVerilog seems to be very sensitive to 
cache size, my benchmarking shows dramatic performance increases with 
each jump in cache size. I don't know if we've reached the point of 
diminishing returns after 4M but it seems like it would be worth the wait 
for the 6M Penryns to find out. 

Article: 126385
Subject: Re: Coolrunner in system programming - XAPP0058 - viable?
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Wed, 21 Nov 2007 08:13:03 +1300
Links: << >>  << T >>  << A >>
Didi wrote:
> Jim,
> 
> 
>>Do you have the xsvf file size handy, for your XC2C64 design ?
>>That would give Didi some info on the svf pathway.
>>(to go with the player info you've given)
> 
> 
> I am quite sure I can reproduce the entire chain of hoops
> in xapp058. It would allow me to eventually reverse engineer
> their jedec -> jtag mapping in a matter of days or may be
> weeks if I want to include more devices.
>  The "impact" tool Antonio is using is not available on the
> xilinx website, but I am sure I could find it as well, it
> must be out there.
>  Yet the question remains - _why_ do they keep the mapping
> data secret? 

With the SVF pathway, it is not entirely secret.

The info IS all there, in an ASCI file,
just not in the most uC-friendly way.

A middle pathway could be a ' uC compressed SVF', where
you get the revision pathway of SVF, but not
so much of the size penalty ?.

Or even a stripped SVF, that has only the data in the
transport-order, but that loses revsion features,
and hard codes the device into your uC.

The code sizes quoted for players were not huge,
and a simple token-compressed player could be smaller.


> I predicted we may wait for a century or so
> for a plausible answer - the first one we got from their
> CPLD support is more arrogant than it is ridiculous. Who
> does this person think is talking to, housewifes? 

:))))) !!!  ROFL

No, but I suspect students ?

They must have the mapping info, as part of their JED2SVF
pathways, in a compilable (likely C tables?) form.

So, perhaps they could release that ?
They release the SVF player source code ?
Treat this as an optional piece ?

-jg



Article: 126386
Subject: Re: Coolrunner in system programming - XAPP0058 - viable?
From: Didi <diditgi@gmail.com>
Date: Tue, 20 Nov 2007 12:21:25 -0800 (PST)
Links: << >>  << T >>  << A >>
> > I predicted we may wait for a century or so
> > for a plausible answer - the first one we got from their
> > CPLD support is more arrogant than it is ridiculous. Who
> > does this person think is talking to, housewifes?
>
> :))))) !!!  ROFL
>
> No, but I suspect students ?
>
> They must have the mapping info, as part of their JED2SVF
> pathways, in a compilable (likely C tables?) form.

Of course they do. I have it for the Philips Coolrunner.
And I still have my extraction scripts - I used to edit/copy
each of a few excel pages and turn them into text, then
the text got processed by a DPS script into something I could
simply put somewhere within a source file.

> So, perhaps they could release that ?
> They release the SVF player source code ?

It is generally irrelevant which they will release - the excel,
the source lookup table, whatever.
 They are not after the cash they make on having these data secret,
it is negligible for their size.
 It must be something else - the answer to the _why_ question
from above, next answer they have may be good enough for
students (I disagree with you, the first one was only good
for housewives :-) ). Which will bring us 2 answers closer to the
century it will take them to come up with a plausible answer.

Dimiter

------------------------------------------------------
Dimiter Popoff               Transgalactic Instruments

http://www.tgi-sci.com
------------------------------------------------------

On Nov 20, 9:13 pm, Jim Granville <no.s...@designtools.maps.co.nz>
wrote:
> Didi wrote:
> > Jim,
>
> >>Do you have the xsvf file size handy, for your XC2C64 design ?
> >>That would give Didi some info on the svf pathway.
> >>(to go with the player info you've given)
>
> > I am quite sure I can reproduce the entire chain of hoops
> > in xapp058. It would allow me to eventually reverse engineer
> > their jedec -> jtag mapping in a matter of days or may be
> > weeks if I want to include more devices.
> >  The "impact" tool Antonio is using is not available on the
> > xilinx website, but I am sure I could find it as well, it
> > must be out there.
> >  Yet the question remains - _why_ do they keep the mapping
> > data secret?
>
> With the SVF pathway, it is not entirely secret.
>
> The info IS all there, in an ASCI file,
> just not in the most uC-friendly way.
>
> A middle pathway could be a ' uC compressed SVF', where
> you get the revision pathway of SVF, but not
> so much of the size penalty ?.
>
> Or even a stripped SVF, that has only the data in the
> transport-order, but that loses revsion features,
> and hard codes the device into your uC.
>
> The code sizes quoted for players were not huge,
> and a simple token-compressed player could be smaller.
>
> > I predicted we may wait for a century or so
> > for a plausible answer - the first one we got from their
> > CPLD support is more arrogant than it is ridiculous. Who
> > does this person think is talking to, housewifes?
>
> :))))) !!!  ROFL
>
> No, but I suspect students ?
>
> They must have the mapping info, as part of their JED2SVF
> pathways, in a compilable (likely C tables?) form.
>
> So, perhaps they could release that ?
> They release the SVF player source code ?
> Treat this as an optional piece ?
>
> -jg


Article: 126387
Subject: Re: Coolrunner in system programming - XAPP0058 - viable?
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Wed, 21 Nov 2007 09:24:58 +1300
Links: << >>  << T >>  << A >>
Didi wrote:
> Alex,
> 
> 
>>Could you elaborate why you can't use other low power CPLD's, Lattice
>>4000Z, for example? I'm asking this question because in Lattice case
>>there is C code supplied for you to make the kind of CPLD programming
>>discussed in this thread very easy.
> 
> 
> just had a look at the datasheet and I see no technical reason at all
> not to use these - the devices are good.
>  Can you please point me to the programming info available for them?
> 
> If I can adopt them and thus forget about Xilinx I would be a happy
> man.

The only design oversight I recall from Lattice, is that they
do NOT have pin-configurable Pullups - the config is global.
[IIRC Xilinx and Atmel, do Pin-level select of Pullup, and also Schmitt]

So, for very low power designs, you'd set no-pull-ups, and selective
external resisitors ( a single pin held the wrong-way, adds up to 150uA )

Data:
["All of the I/Os and dedicated inputs have the capability to provide a 
bus-keeper latch, Pull-up Resistor or Pull-down
Resistor. A fourth option is to provide none of these. The selection is 
done on a global basis. The default in both
hardware and software is such that when the device is erased or if the 
user does not specify, the input structure is
configured to be a Pull-up Resistor."]

-jg


Article: 126388
Subject: Re: Coolrunner in system programming - XAPP0058 - viable?
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Wed, 21 Nov 2007 09:59:53 +1300
Links: << >>  << T >>  << A >>
Didi wrote:

>>>I predicted we may wait for a century or so
>>>for a plausible answer - the first one we got from their
>>>CPLD support is more arrogant than it is ridiculous. Who
>>>does this person think is talking to, housewifes?
>>
>>:))))) !!!  ROFL
>>
>>No, but I suspect students ?
>>
>>They must have the mapping info, as part of their JED2SVF
>>pathways, in a compilable (likely C tables?) form.
> 
> 
> Of course they do. I have it for the Philips Coolrunner.
> And I still have my extraction scripts - I used to edit/copy
> each of a few excel pages and turn them into text, then
> the text got processed by a DPS script into something I could
> simply put somewhere within a source file.

So you would be quite happy with a portion of JED2SVF,
as a source table - for further 'rework' ?


> 
> 
>>So, perhaps they could release that ?
>>They release the SVF player source code ?
> 
> 
> It is generally irrelevant which they will release - the excel,
> the source lookup table, whatever.
>  They are not after the cash they make on having these data secret,
> it is negligible for their size.
>  It must be something else - the answer to the _why_ question
> from above, next answer they have may be good enough for
> students (I disagree with you, the first one was only good
> for housewives :-) ). Which will bring us 2 answers closer to the
> century it will take them to come up with a plausible answer.

Big companies have their own inertias and procedures, so it is
best to figure out why, and find a way around that :)

In this case, I can see that a separate pgm-info PDF, has a separate
sign-off procedure, and also has a risk and support cost.

The JED2SVF and SVF itself is already released, so they are
happy with that level.

All I see it needs is either

a) The JED mapping table to be also released.
Advantage here is that is a proven table, as it is
already part of a proven & existing released flow (Impact/JED2SVF),
so there are no QC costs. The tables auto-revise with new devices.


A designer would take the SVF JEDEC state infos, and port those
into the uC, but be able to use the tables to morph a JED.

or
b) (take a little SW engineering)

Make the JED2SVF impact flow, so it can also create a
fuse-linear file.
Besides the Eng. time, this can get a little trickier,
as sometimes fuse arrays have 'don't care, or read-stuck'
gaps and portions in them. Getting thst info in there
could be a challenge.

If I were Xilinx, I'd choose a)  :)

Comments Peter / Jesse ?

PS : Did I see some comment earlier about Xilinx open-sourcing their
Impact programming flows ? [That also encompasses a) ]

-jg





Article: 126389
Subject: Re: FPGA Editor (9.2.03i) under Linux x86_64
From: <steve.lass@xilinx.com>
Date: Tue, 20 Nov 2007 16:22:27 -0700
Links: << >>  << T >>  << A >>
A substantial amount of work is required for each appication when we
move away from Wind/U. We have decided not to do that for FPGA
Editor. Instead, we are creating a new application that is a combination
of PACE, Floorplanner, FPI, FPE and FPGA Editor. That will be
available in 11.1 (March 2009).

Steve

"Jan Pech" <no@spam.please> wrote in message 
news:1195582646.3063.9.camel@workstation.cholunna.local...
>
> By the way, why FPGA editor is still Windows application running under
> Wind/U environment while the rest of Xilinx tools run native in Linux? I
> do not understand.
>
> Thanks,
> Jan
> 



Article: 126390
Subject: Re: Coolrunner in system programming - XAPP0058 - viable?
From: Didi <diditgi@gmail.com>
Date: Tue, 20 Nov 2007 15:47:16 -0800 (PST)
Links: << >>  << T >>  << A >>
> So you would be quite happy with a portion of JED2SVF,
> as a source table - for further 'rework' ?

Not sure - I have to see it. The lookup table would do, but
the utility - no, it would only provide a way to reverse
engineering the table, which can be pretty bulky.

> Besides the Eng. time, this can get a little trickier,
> as sometimes fuse arrays have 'don't care, or read-stuck'
> gaps and portions in them. Getting thst info in there
> could be a challenge.

Indeed so. This info is needed as well. The simplest way for
everyone would be just handing me the Excel files, no
more questions asked guaranteed by my signature, NDA
if necessary, too. I know my way from there.

Dimiter

------------------------------------------------------
Dimiter Popoff               Transgalactic Instruments

http://www.tgi-sci.com
------------------------------------------------------

On Nov 20, 10:59 pm, Jim Granville <no.s...@designtools.maps.co.nz>
wrote:
> Didi wrote:
> >>>I predicted we may wait for a century or so
> >>>for a plausible answer - the first one we got from their
> >>>CPLD support is more arrogant than it is ridiculous. Who
> >>>does this person think is talking to, housewifes?
>
> >>:))))) !!!  ROFL
>
> >>No, but I suspect students ?
>
> >>They must have the mapping info, as part of their JED2SVF
> >>pathways, in a compilable (likely C tables?) form.
>
> > Of course they do. I have it for the Philips Coolrunner.
> > And I still have my extraction scripts - I used to edit/copy
> > each of a few excel pages and turn them into text, then
> > the text got processed by a DPS script into something I could
> > simply put somewhere within a source file.
>
> So you would be quite happy with a portion of JED2SVF,
> as a source table - for further 'rework' ?
>
>
>
> >>So, perhaps they could release that ?
> >>They release the SVF player source code ?
>
> > It is generally irrelevant which they will release - the excel,
> > the source lookup table, whatever.
> >  They are not after the cash they make on having these data secret,
> > it is negligible for their size.
> >  It must be something else - the answer to the _why_ question
> > from above, next answer they have may be good enough for
> > students (I disagree with you, the first one was only good
> > for housewives :-) ). Which will bring us 2 answers closer to the
> > century it will take them to come up with a plausible answer.
>
> Big companies have their own inertias and procedures, so it is
> best to figure out why, and find a way around that :)
>
> In this case, I can see that a separate pgm-info PDF, has a separate
> sign-off procedure, and also has a risk and support cost.
>
> The JED2SVF and SVF itself is already released, so they are
> happy with that level.
>
> All I see it needs is either
>
> a) The JED mapping table to be also released.
> Advantage here is that is a proven table, as it is
> already part of a proven & existing released flow (Impact/JED2SVF),
> so there are no QC costs. The tables auto-revise with new devices.
>
> A designer would take the SVF JEDEC state infos, and port those
> into the uC, but be able to use the tables to morph a JED.
>
> or
> b) (take a little SW engineering)
>
> Make the JED2SVF impact flow, so it can also create a
> fuse-linear file.
> Besides the Eng. time, this can get a little trickier,
> as sometimes fuse arrays have 'don't care, or read-stuck'
> gaps and portions in them. Getting thst info in there
> could be a challenge.
>
> If I were Xilinx, I'd choose a)  :)
>
> Comments Peter / Jesse ?
>
> PS : Did I see some comment earlier about Xilinx open-sourcing their
> Impact programming flows ? [That also encompasses a) ]
>
> -jg


Article: 126391
Subject: Re: FPGA Editor (9.2.03i) under Linux x86_64
From: krishnans@hotmail.com
Date: Tue, 20 Nov 2007 17:32:18 -0800 (PST)
Links: << >>  << T >>  << A >>

older version of libXt.so is needed to run WindU based programs like
FPGAEditor

see Answer Record for details
http://www.xilinx.com/support/answers/22022.htm


On Nov 20, 3:22 pm, <steve.l...@xilinx.com> wrote:
> A substantial amount of work is required for each appication when we
> move away from Wind/U. We have decided not to do that for FPGA
> Editor. Instead, we are creating a new application that is a combination
> of PACE, Floorplanner, FPI, FPE and FPGA Editor. That will be
> available in 11.1 (March 2009).
>
> Steve
>
> "Jan Pech" <n...@spam.please> wrote in message
>
> news:1195582646.3063.9.camel@workstation.cholunna.local...
>
>
>
> > By the way, why FPGA editor is still Windows application running under
> > Wind/U environment while the rest of Xilinx tools run native in Linux? I
> > do not understand.
>
> > Thanks,
> > Jan


Article: 126392
Subject: Re: Coolrunner in system programming - XAPP0058 - viable?
From: Eric Smith <eric@brouhaha.com>
Date: Tue, 20 Nov 2007 18:49:32 -0800
Links: << >>  << T >>  << A >>
Didi wrote:
>  The "impact" tool Antonio is using is not available on the
> xilinx website,

Sure it is!  It's part of WebPACK, which is avaiable for download at no
charge.

Article: 126393
Subject: Re: New Laptop for work
From: rickman <gnuarm@gmail.com>
Date: Tue, 20 Nov 2007 19:38:49 -0800 (PST)
Links: << >>  << T >>  << A >>
On Nov 19, 3:54 am, Guru <ales.gor...@email.si> wrote:
>
> About the display: 15.4" in not enough for a real work.
> You should better buy a 17", your eyes would be pleased.
> As they say: integrated graphic card is OK if you do not use 3D
> programs.

Yes, I am a big fan of large displays.  But I don't want to get
Vista.  The only machines I have found that come with XP are Dell
Vostro (or the much more expensive business models) and they don't
provide XP with the 17 inch models for some reason.  I even mentioned
to the guy on the phone that they would be losing a sale because of
this and he said he would pass that on.

Actually, I am very impressed with the Vostro 1500 models in terms of
price and functionality.  Even the 1700 model (17 inch display) is a
pretty good buy at around $850, but my understanding is that Vista
uses so much memory that 2 GB is not a lot.  Buying ram from them is
absurdly high so I don't want to have to go above the 2 GB that come
with the machine... what ever happened to the days of 640 kB being a
lot of RAM???  How fast do you think XST would run if it was rewritten
to work with mag tape?


Article: 126394
Subject: Re: New Laptop for work
From: rickman <gnuarm@gmail.com>
Date: Tue, 20 Nov 2007 20:05:26 -0800 (PST)
Links: << >>  << T >>  << A >>
On Nov 20, 1:36 pm, General Schvantzkoph <schvantzk...@yahoo.com>
wrote:
>
> I'm waiting until January when the Penryns come out. The Penryns have 6M
> caches and amazingly low power. NCVerilog seems to be very sensitive to
> cache size, my benchmarking shows dramatic performance increases with
> each jump in cache size. I don't know if we've reached the point of
> diminishing returns after 4M but it seems like it would be worth the wait
> for the 6M Penryns to find out.

Yes, I hope I can wait.  But I expect the Penryns to be priced out of
my range.  I also don't have any confidence that they will be out at
any given time.  Intel may be shipping in January, but that doesn't
mean they will appear in any laptops other than very high end for a
while longer.

Article: 126395
Subject: An error occured while using Dual Port Block Memory
From: spygame81@gmail.com
Date: Tue, 20 Nov 2007 23:17:30 -0800 (PST)
Links: << >>  << T >>  << A >>
Hi!

I am using Dual Port Block Memory in Virtex-II, V8.2. During
simulation in Modelsim, i have encountered an error that reports to me
is:

$recovery(posedge clk B: .... ps, posedge clk A &&&
collision_posa_posb: ... ns, 1ns);

How can i cater this issue and how can i remove this error in my
simulation???

Regards
Rai

Article: 126396
Subject: partial dynamic reconfiguration on Virtex-4 SX35
From: G_Abg <Gael.Abgrall@gmail.com>
Date: Wed, 21 Nov 2007 00:30:12 -0800 (PST)
Links: << >>  << T >>  << A >>
Hi,

I have just begin my PhD on SDR and I will have to use a FPGA with
partial dynamic reconfiguration. The system which interest me have a
Xilinx Virtex-4 SX35 integrated on it and I'm not sure this FPGA can
do it.

If someone could answer me, it'll be great.

Thanks.

Article: 126397
Subject: Re: Coolrunner in system programming - XAPP0058 - viable?
From: Didi <diditgi@gmail.com>
Date: Wed, 21 Nov 2007 01:43:46 -0800 (PST)
Links: << >>  << T >>  << A >>
On Nov 21, 4:49 am, Eric Smith <e...@brouhaha.com> wrote:
> Didi wrote:
> >  The "impact" tool Antonio is using is not available on the
> > xilinx website,
>
> Sure it is!  It's part of WebPACK, which is avaiable for download at no
> charge.

Oh I see, my mistake, thanks. I have not used their software yet,
so I don't know it in much detail.

Dimiter

------------------------------------------------------
Dimiter Popoff               Transgalactic Instruments

http://www.tgi-sci.com
------------------------------------------------------

Article: 126398
Subject: Xilinx XST 8.2, Error on multi-source, bug?
From: Timo Gerber <timo.g@web.de>
Date: Wed, 21 Nov 2007 12:09:19 +0100
Links: << >>  << T >>  << A >>
Hi,
I'm using Xilinx 8.2.03i and I get an Error Xst:528 "Multi-source in 
Unit ..."
It's a wire in a submodule and i checked the code:
The signal is an output to module A and an input to module B.
There is no other assignment to this signal. Inside module B the signal 
is only on the right-side of any "=" assignments.

Could there be a bug in Xst when using a design containig both VHDL and 
verilog files?

Timo

Article: 126399
Subject: Re: FPGA Editor (9.2.03i) under Linux x86_64
From: Uwe Bonnes <bon@hertz.ikp.physik.tu-darmstadt.de>
Date: Wed, 21 Nov 2007 11:15:40 +0000 (UTC)
Links: << >>  << T >>  << A >>
steve.lass@xilinx.com wrote:
> A substantial amount of work is required for each appication when we
> move away from Wind/U. We have decided not to do that for FPGA
> Editor. Instead, we are creating a new application that is a combination
> of PACE, Floorplanner, FPI, FPE and FPGA Editor. That will be
> available in 11.1 (March 2009).

Steve,

did Xilinx consider Wine as a portablility layer for programs written in the
windows API?  

Bye

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

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



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