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 77425

Article: 77425
Subject: Spartan 3 Experimenter's Board
From: "PNowe" <pnowe@dulseelectronics.com>
Date: Thu, 6 Jan 2005 13:08:40 -0500
Links: << >>  << T >>  << A >>
If anyone is looking for a Spartan 3 board for hobbyists and students, that 
also includes a solderless breadboard for adding your own circuitry, have a 
look at  www.dulseelectronics.com .  An article about the board appeared in 
the Dec 2004 issue of Circuit Cellar Magazine.

Phil
Dulse Electronics



Article: 77426
Subject: Re: is this memory implementation synthesizeable?
From: "Tim" <tim@rockylogic.com.nooospam.com>
Date: Thu, 6 Jan 2005 18:14:31 -0000
Links: << >>  << T >>  << A >>

"Stefan Duenser" wrote
> Hi all
>
> I have implemented a very easy memory with a few registers, where i can
> store and also read values for and from my ALU:
>
> I have got 2 questions:
>
> 1) The conv_integer procedure does not work here, I always get the
> errormessage: no feasable subprogram entry for conv_integer. Any ideas whats 
> wrong here?

On this one, comp.lang.vhdl is the place for the VHDL questions.

If you check the archive you will see a zillion repetitions of
this advice:  use the numeric_std library

Then you can use to_integer().

I usually use an indirect function to clean up the simulation:

    library IEEE;
    use IEEE.STD_LOGIC_1164.all;
    use IEEE.numeric_std.all;

    function ToInteger(ARG: UNSIGNED) return INTEGER is
      variable x: unsigned(ARG'range);
      variable n: integer;
    begin
      x := ARG;
      -- synthesis translate_off
      for i in x'range loop
        if x(i)/='1' then       -- resolve the 'undefined' signals
          x(i) := '0';
        end if;
      end loop;
      -- synthesis translate_on
      n := to_integer(x);
      return n;
    end;



Article: 77427
Subject: Re: is this memory implementation synthesizeable?
From: "Stefan Duenser" <carlsberg@gmx.at>
Date: Thu, 6 Jan 2005 18:16:41 -0000
Links: << >>  << T >>  << A >>

> 1) The conv_integer procedure does not work here, I always get the
> errormessage: no feasable subprogram entry for conv_integer. Any ideas 
> whats wrong here?

I really dont understand why this is not working, because this functions are 
declared in the  ieee.std_logic_arith.all header...

   FUNCTION to_integer ( arg1 : STD_ULOGIC_VECTOR; x : INTEGER := 0 ) RETURN 
INTEGER;
   FUNCTION to_integer ( arg1 : STD_LOGIC_VECTOR; x : INTEGER := 0 ) RETURN 
INTEGER;
   FUNCTION to_integer ( arg1 : STD_LOGIC; x : INTEGER := 0 ) RETURN 
NATURAL;
   FUNCTION to_integer ( arg1 : UNSIGNED; x : INTEGER := 0 ) RETURN NATURAL;
   FUNCTION to_integer ( arg1 : SIGNED; x : INTEGER := 0 ) RETURN INTEGER;

   FUNCTION conv_integer ( arg1 : STD_ULOGIC_VECTOR; x : INTEGER := 0 ) 
RETURN INTEGER;
   FUNCTION conv_integer ( arg1 : STD_LOGIC_VECTOR; x : INTEGER := 0 ) 
RETURN INTEGER;
   FUNCTION conv_integer ( arg1 : STD_LOGIC; x : INTEGER := 0 ) RETURN 
NATURAL;
   FUNCTION conv_integer ( arg1 : UNSIGNED; x : INTEGER := 0 ) RETURN 
NATURAL;
   FUNCTION conv_integer ( arg1 : SIGNED; x : INTEGER := 0 ) RETURN INTEGER

any useful tips?




Article: 77428
Subject: Re: xil_printf not working as expected
From: "Bo" <bo@cephus.com>
Date: Thu, 6 Jan 2005 12:24:31 -0600
Links: << >>  << T >>  << A >>
The xil_printf documentation states:

This function is similar to printf but much smaller in size (only 1KB). It 
does not have support for floating point numbers. xil_printf also does not 
support printing of long long (i.e 64 bit numbers"This func is similar to 
printf but much smaller. It does not have support for floating pt numbers or 
long long. "

Try using %d instead of %l and see if you get *something*...



"Patrick" <mai99drh@studserv.uni-leipzig.de> wrote in message 
news:9bb2b1a1.0501060813.78b7a669@posting.google.com...
> Hello,
>
> i know this is a rather stupid question, but i'm somewhat irritated.
>
> I'm triing to send some data per Uartlite. For normal
> characters/strings everything works fine, but if i try to send some
> integers or long integers they aren't displayed.
>
> (Short) example:
>
> ...
>
> /* global definitions, no pointers */
> Xuint32 interrupt_count = 0;
> volatile Xuint32 jiffies = 0;
>
> ...
>
> /* values incrementd during pit-isr, pit works, pit running at 100HZ
> */
> void pit_timer_int_handler(void * baseaddr_p)
> {
> jiffies++;
> interrupt_count++;
>
> XTime_TSRClearStatusBits(XREG_TSR_PIT_INTERRUPT_STATUS);
> }
>
> ...
>
> main(){
>
>   /* string displayed correctly */
>   xil_printf("\r\nRunning Mainloop");
>
> while(1){
> sleep(2);
> xil_printf("\nLoop");
>
> /* here the values aren't displayed,but the "a"s and "b"s are displayd
> */
>                xil_printf("\n %l a", i_interrupt_count);
> xil_printf("\n %l b", l_interrupt_count);
> /* giving the arguments as pointers won't help either */
>                xil_printf("\n %l a", &i_interrupt_count);
> xil_printf("\n %l b", &l_interrupt_count);
> }
>
> }
>
>
> i have tried different compinations with "%d","%D","%l","%ul" or "%c"
> as format-strings and different datatypes for the two variables
> (unisgned, int, long, unsigned long).
>
> i was looking at the xil_printf sources, too, to see what characters
> after "%" are supported.
>
> I'm using an uartlite at 9600 baud, 8 databits, no parity.
>
> So, does someone might have an idea or hint what my mistake is?
>
> Regards
>  Patrick 




Article: 77429
Subject: Re: Utilisation of Xilinx FPGAs
From: "Bo" <bo@cephus.com>
Date: Thu, 6 Jan 2005 12:27:36 -0600
Links: << >>  << T >>  << A >>
Our experience has been about 70-80%. Interestingly, on large parts you can 
have trouble if you aren't using enough resources because the tools 'spread' 
the logic across the chip too far and cause timing errors. So... ideally? I 
would say 60-80% utilization.


"Rudolf Usselmann" <russelmann@hotmail.com> wrote in message 
news:crjn5n$1d4$1@nobel.pacific.net.sg...
> stockton wrote:
>
>> Dear All,
>>
>> I hope that you can help.
>>
>> I am looking at trying to fit a number of IP cores into a single
>> Xilinx FPGA, I have heard that it is not possible to completly utilise
>> all the FPGA resources (RAM, Logic Cells, DCMs etc ... ) because of
>> routing problems.
>>
>> Do anyone know of a rough percentage of the the FPGA resources that
>> can be expected to be utilised before issues arise in trying to route
>> the design?
>>
>> I have head that it is as low as 60% but am hoping that this is not
>> the case.
>>
>> I understand that it really does depend on what you put into the FPGA
>> but to only be able to utilise 60% on average seams a little poor to
>> me.
>>
>> Kind Regards
>>
>> Simon
>
> We test all of our IP Cores on a few Xilinx Development
> boards we have in house and are stuck with device sizes.
>
> We always have a small SoC that we attach our "Core to be
> tested" to. I have seen utilization of 98%++ specially when
> we make heavy use of ChipScope. As long as you stick with
> EDK based SoC and their 100MHz bus speed limitation, you
> are usually ok up 98% utilization.
>
> Best Regards,
> rudi
> =============================================================
> Rudolf Usselmann,  ASICS World Services,  http://www.asics.ws
> Your Partner for IP Cores, Design, Verification and Synthesis
> 




Article: 77430
Subject: Re: xilinx as video processor?
From: "Falk Brunner" <Falk.Brunner@gmx.de>
Date: Thu, 6 Jan 2005 19:29:50 +0100
Links: << >>  << T >>  << A >>

"Sylvain Munaut" <tnt_at_246tNt_dot_com@reducespam.com> schrieb im
Newsbeitrag news:41dd74ee$0$2457$ba620e4c@news.skynet.be...
> Hi
>
> > Since we aren't talking drastic resolutions here, i figured they would
> > be fast enough?
>
> I would guess so too ... 640x480 is < 30Mhz pixel clock, easily
achievable.

Yes, aka scan doubler. No big deal in a Spartan-II(E) or III

Regards
Falk




Article: 77431
Subject: Re: is this memory implementation synthesizeable?
From: Jonathan Bromley <jonathan.bromley@doulos.com>
Date: Thu, 06 Jan 2005 18:33:45 +0000
Links: << >>  << T >>  << A >>
On Thu, 6 Jan 2005 18:16:41 -0000, 
"Stefan Duenser" <carlsberg@gmx.at> wrote:

>> 1) The conv_integer procedure does not work here, I always get the
>> errormessage: no feasable subprogram entry for conv_integer. Any ideas 
>> whats wrong here?
>
>I really dont understand why this is not working, because this functions are 
>declared in the  ieee.std_logic_arith.all header...

[snip]

Take heed of what the nice man said:  USE NUMERIC_STD.

Like many other people, you have unnecessarily included
both
  use ieee.std_logic_arith.all;
and
  use ieee.std_logic_unsigned.all;

I think one of the Xilinx tools tends to add both 
these clauses by default - silly thing to do.

Your problem is caused because CONV_INTEGER() is 
defined in BOTH packages.  Consequently, neither
definition is visible.  You could, if you were
desperate, use a fully-qualified function name:

  int <= ieee.std_logic_arith.conv_integer(vec);

but that would be silly, wouldn't it?

So PLEASE, get rid of std_logic_arith and 
std_logic_[un]signed from all your code, start
using numeric_std instead, and read comp.lang.vhdl
for lots of advice on how to do that.

The quick fix is for you to remove one of the two
use clauses, but it's way better to do it properly.
-- 
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL, Verilog, SystemC, Perl, Tcl/Tk, Verification, Project Services

Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, BH24 1AW, UK
Tel: +44 (0)1425 471223          mail:jonathan.bromley@doulos.com
Fax: +44 (0)1425 471573                Web: http://www.doulos.com

The contents of this message may contain personal views which 
are not the views of Doulos Ltd., unless specifically stated.


Article: 77432
Subject: Re: San Jose job offer - need advice
From: Kevin Neilson <kevin_neilson@removethiscomcast.net>
Date: Thu, 06 Jan 2005 11:37:30 -0700
Links: << >>  << T >>  << A >>
vadim wrote:
> I have received a job offer from a company 
> in San Jose, California. The position title is: Test Development
> Engineering. The salary offered is 67k/year with Relocation Assistance
> and a Benefits package. I already have a 60k/year job in Toronto,
> Canada as Applications Engineer.
> 
> The San Jose job is closer to circuit-design which is an area I would
> like to get into.
> 
> I was told that the housing prices of Bay Area will make this salary
> into a 50k equivalent of Toronto. So practically my "buying power" is
> reduced.
> 
> I have a dillema whether: 
> -Professional advantages of this position, closer to ciruit design. 
> -Working in Silicon Valley, the Mecca of HighTech. 
> 
> outweigh the offered salary ?
> 
> Thanks in advance.

I would guess you'd be financially better off in Toronto.  I don't know 
how expensive Toronto is, but I know it will be fairly expensive to live 
in San Jose.  And while the position may be closer to design, it's not 
terribly close.

I'm surprised about the comments from the guy from Sweden.  He must have 
moved someplace very expensive, because Sweden isn't cheap.  And their 
tax rate is like 98%.

Article: 77433
Subject: VHDL Test Bench + Help
From: "SneakerNet" <nospam@nospam.org>
Date: Fri, 7 Jan 2005 07:57:36 +1300
Links: << >>  << T >>  << A >>
Hello all
I need some introductory help with writing test bench cases for my VHDL
code.
I have written a lot of VHDL code, however I have always tested this using
waveform simulation and then finally testing it on the product. I wish to go
one step further by learning how to write test cases.

Can someone give me a starting point to this pls? Is there a website that
explains how to write test bench code? I am using Altera FPGAs and thus
using Quartus II to write my VHDL code at present.

Pls advice.

Thank you



Article: 77434
Subject: Re: ISE Toolflow : hardmacro, incremental or modular
From: Bret Wade <bret.wade@xilinx.com>
Date: Thu, 06 Jan 2005 12:23:00 -0700
Links: << >>  << T >>  << A >>
Brian Drummond wrote:
> On Wed, 05 Jan 2005 12:06:48 -0700, Bret Wade <bret.wade@xilinx.com>
> wrote:
> 
> 
>>Daniel wrote:
>>
>>>@Bret Thanks for the suggestion. Didnt know that its possible to fix the routing also within RPM macros.
>>>
>>>Are RPM macros usefull for design modules as large as my one (376 CLB Slices (752 FlipFlops, 260FG's), 8BRAMs and 1GlobalBuffer) or does this lead to problems with performance or even unstable workflows?
> 
> 
> I am working with larger RPMs than this, with some degree of success
> (cautiously expressed; the design is not yet complete)
> 
> There *may* be problems with BRAMs and multipliers in RPMs.
> 
There is a certain amount of complexity added when an RPM combines 
multiple component types (Heterogeneous RPM) due to the fact that for 
the default grid system, the various component types are on different 
grids. This is only a problem if your RPM requires normalization. If 
your RPM uses the X0Y0 slice and does not use any negative RLOC values, 
then no normalization occurs and there is not problem. If normalization 
is necessary, then the RPM must be implemented with the RPM Grid system. 
More on normalization and the RPM Grid here:

http://www.xilinx.com/bvdocs/appnotes/xapp416.pdf
> 
>>Yes, large RPM macros can be used effectively. Multiple small RPMs can 
>>be assembled with offsets defined by hierarchical RLOCs to assemble a 
>>large RPM. Automatic placement of large RPMs can be a challenge so it 
>>may be necessary to locate the macro. I believe that Ray Andraka has 
>>posted on the subject of large RPMs in the past. You may want to Google 
>>for that.
> 
> 
> There are problems using the floorplanner to create RPMs from smaller
> ones, mostly associated with tools issues (the floorplanner alone has
> two mutually incompatible understandings of RLOC_ORIGIN, the mapper
> moves the origin left by 1 location under some (apparently undefined)
> circumstances, the placer reports errors on some correct RLOC_ORIGIN
> constraints and silently deletes others altogether, and so on. 

RLOC_ORIGIN values must take into account the normalization of the RPM. 
More on that in the appnote. The mapper converts RLOC_ORIGINs into MACRO 
LOCATE constraints in the PCF file, so strictly speaking it's not 
possible for the placer to ignore RLOC_ORIGIN constraints because it 
never sees them.

A separate issue is that the RPM needs to be placed in the same "slice 
type" that it was created about. There are four slice types represented 
by the four slices in a CLB, S0-S3. For simplicitys sake, it is best to 
construct a macro about the X0Y0 slice and then always place it in an S0 
slice type if possible. If the RPM is placed in a different slice type, 
the relative placement will be broken, which can lead to placement 
failures.

I suspect that these two issues explain some of the behavior that you're 
seeing. I can't speak to what the Floorplanner is doing in constructing 
your RPMs.

> 
> http://www.shapes.demon.co.uk/files/crashme.zip contains a test case for
> a few of the problems, where only one of eight RPMs is placed correctly.
> 
> There are other problems too, including floorplanner swapping BELs
> within a CLB, and crashing when writing RPM UCF files. 
> 
> Maybe FPGA editor is a more stable tool for floorplanning? I would try
> it but only have WebPack in current software.

FPGA Editor is not a floorplanner. It is an editor for displaying and 
modifying the physical design and applying some physical constraints. 
The Floorplanner is an editor for applying constraints to the logical 
design. FPGA Editor is the only tool for applying Directed Routing 
constraints and it is useful for obtaining grid values for both the 
standard and RPM Grid systems. FPGA Editor is also a great tool for 
understanding the details of possible component, placement and routing 
configurations within the FPGA.

> 
> But if you can identify and work round the tools limitations, it looks
> tantalisingly close to workable, with RPMs considerably larger than
> yours above, and composed hierarchically of RPMs several levels deep.
> 
> One of the (undocumented? - at least I haven't found it anywhere)
> workarounds seems to be to keep a component in the lower left hand
> corner of the smallest bounding box that can surround the RPM, which
> should site this corner at RLOC=X0Y0 - a condition violated deliberately
> in the test case above (and accidentally in several of my RPMs!)

This is the normalization issue again. You don't have to build the RPM 
around the X0Y0 slice, but if you don't, you have to account for 
normalization.

> 
> Another is to "replace all with placement" (or "constrain from" as
> appropriate) which corrects randomly swapped BEL elements, should they
> occur.
> 
> I would love to see some others, or an App Note on this process...
> 
> And I'm hoping some of these floorplanner bugs can be fixed.
> 
> 
>>>How fix is the routing "fixed" with directed routing in the later PAR of the whole design? Is it possible that the router changes anything?
> 
> 
>>Since you mentioned that a large macro is involved, I should point out 
>>that Directed Routing is not recommended for use with large numbers of 
>>signals on the order of hundreds. Guide should be used instead. That 
>>recommendation depends on the nature of the routing involved and the 
>>level of congestion around the locked routing.
> 
> 
> Guide is interesting, both because I don't have FPGA editor, and
> apparently directed routing isn't intended for large RPMs.
> 
> Can you point me in the direction of a flow that would use guided
> routing for a top level module composed of several pre-routed RPM
> modules? Preferably where at least one of the RPMs has itself been
> created in this way?

Directed Routing is not incompatible with the guided flows. There's no 
reason why you can't combine them. You'll just need to get FPGA Editor 
and try it.

There is one problem area that I should mention. The placer can 
currently place an unconstrained slice in conflict with Directed 
Routing, where the locked routing blocks switchbox access to BX and BY 
pins on the slice. I've only seen it on one design so far that had a lot 
of Directed Routing that was using switchbox bank shots. Beware using 
routing constraints like that in areas where the slice utilization is 
uncontrolled. A work around is to prohibit the affected slice site. 
We're looking a placer fix in the 7.1i time frame.

Regards,
Bret

> 
> I am currently finding it difficult to maintain timings achieved on
> lower level modules when they are combined together, and scope for
> routing congestion obviously increases.
> 
> - Brian

Article: 77435
Subject: Re: Tracking down HardWired History
From: Austin Lesea <austin@xilinx.com>
Date: Thu, 06 Jan 2005 11:37:46 -0800
Links: << >>  << T >>  << A >>
Tim,

The case at issue was one where the hardened version was much faster. 
The much faster part was the IO itself was now much faster, and had less 
delay (a real issue when you are cutting out real estate to get the cost 
advantages - things get faster - it is unavoidable).

So, speed (too slow) was not an issue.  Speed (way too fast) was an 
issue.  If the other part this one talked to was a FPGA, no problem, 
just reprogram the FPGA to accept that the signals were arriving a 
little ahead of where they used to.

Too bad, they had already made that part an ASIC (from an ASIC vendor) 
just a few months earlier.

Result, throw away all of the hardened parts, and go back to using the 
FPGA.  Oh, and stick the vendor with the cost of failure as it was 
"guaranteed."  It could be that this is what Paul is referring to: no 
cost of failure, as it will be paid for by the vendor until they get it 
right.  Not my idea of a great business model, but hey, I don't like the 
whole hardened model anyway.

Bottom line:

If it ain't broke, don't fix it.  An engineering maxim that was true 
years ago, and still true today.  Change anything, and something will 
change (obvious, isn't it?).

Will it be the IO timing?  The IO signal integrity?  The jitter 
performance?  Will it be too fast?  Will it be too slow (unlikely)?

DOH!

The ONLY solution that can make the claim of no pain, is ours: 
EASYPATH(tm).  Why?

Because we don't change anything at all.  Same part, same silicon, same 
bitstream, just 30 to 50% (or more) cost savings.

How could any person examining the costs of a product ignore EasyPath? 
Once the accounting folks (and CEO) understand the lack of risk, and the 
reduction in costs, an engineer's opinion (of goodness of badness) will 
not be worth a cent.  The facts speak for themselves.

Austin


Tim wrote:
> "Austin Lesea" wrote
> 
> 
>>And, "seamless risk free" is just a plain an outright misrepresentation.
>>
>>I know of a customer that had a serious issue, and was unable to meet their 
>>production ship dates (fact).  Only reason we know is that they had to 
>>continue buying the FPGA......
> 
> 
> Without taking sides on the underlying debate, is there a
> possibility that problems and design practices masked by
> the slower FPGA speeds come and bite at ASIC speed?
> 
> Not everyone has read and followed the stuff on crossing
> clock domains and so on.
> 
> I'm just wondering how come fully debugged (!) designs can
> go all bad. 
> 
> 

Article: 77436
Subject: Re: How to change temperature in Xilnx Webpack with free starter Modelsim
From: "gja" <geeja@hotmail.com>
Date: Thu, 6 Jan 2005 14:40:41 -0500
Links: << >>  << T >>  << A >>
Tried that, but i get this warning message:

Started process "Generate Post-Place & Route Simulation Model".

WARNING:Anno:255 - command line '-s -4' overrides .pcf TEMPERATURE = 70.000
C




"Falk Brunner" <Falk.Brunner@gmx.de> wrote in message
news:345bivF47eeulU3@individual.net...
>
> "gja" <geeja@hotmail.com> schrieb im Newsbeitrag
> news:SQdDd.3214$yK7.3065@fe11.lga...
> > I want to do post place and route timing simulation on a Virtex2 part
> using
> > the Xilinx Modelsim starter simulator, how can I set the temperature
point
> > to 70 celcius?
>
> Add
>
> temperature=70C;
>
> to your UCF
>
> Regards
> Falk
>
>
>
>
>



Article: 77437
Subject: Re: Utilisation of Xilinx FPGAs
From: "Peter Alfke" <peter@xilinx.com>
Date: 6 Jan 2005 11:48:12 -0800
Links: << >>  << T >>  << A >>
If you do not constrain the timing, the tools "are lazy" and make their
life easy, by spreading the logic around, so as to avoid congestion.
The proper solution is to constrain the timing and thus force the tools
to make more appropriate, more intelligent, and more demanding
decisions.

It's the tools' equivalent to Parkinson's Law:
"Every job grows to use up all the available resources in time, space,
and money".
It's up to you to delineate the available resources !
Peter Alfke, Xilinx Applications


Article: 77438
Subject: Altera Quartus Error How to track donw.
From: "GMM50" <george.martin@att.net>
Date: 6 Jan 2005 11:48:50 -0800
Links: << >>  << T >>  << A >>
Hello:

I'm entering a desing in to Altera's Quartus II 4.1 using block diagram
files as the input mechanism.

When I try to compile I get the following message......
Internal Error: Sub-system: CDB_SGATE, File: cdb_sgate_wys_ygr.cpp,
Line: 4111
cdb_is_connected(b_iterm)
Quartus II Version 4.1 Build 181 06/29/2004 SJ Full Version
...............

The error is probably something I've done as I created the schematics.
My question is how to track the error down?

The design is heirarcail and I've tried deleting functional blocks.
When I do I get different error messages because signals are now
missing.

What steps to take.

Thanks
George


Article: 77439
Subject: Re: xilinx as video processor?
From: Ray Andraka <ray@andraka.com>
Date: Thu, 06 Jan 2005 15:02:48 -0500
Links: << >>  << T >>  << A >>
Yeah, no problem in current FPGA offerings.  HDTV apps are far more 
demanding in terms of pixel rate and image size, yet even spartanI 
series parts were fast enough for HD apps with enough care taken on the 
design.

Falk Brunner wrote:

>"Sylvain Munaut" <tnt_at_246tNt_dot_com@reducespam.com> schrieb im
>Newsbeitrag news:41dd74ee$0$2457$ba620e4c@news.skynet.be...
>  
>
>>Hi
>>
>>    
>>
>>>Since we aren't talking drastic resolutions here, i figured they would
>>>be fast enough?
>>>      
>>>
>>I would guess so too ... 640x480 is < 30Mhz pixel clock, easily
>>    
>>
>achievable.
>
>Yes, aka scan doubler. No big deal in a Spartan-II(E) or III
>
>Regards
>Falk
>
>
>
>  
>


-- 
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com  
http://www.andraka.com  

 "They that give up essential liberty to obtain a little 
  temporary safety deserve neither liberty nor safety."
                                          -Benjamin Franklin, 1759



Article: 77440
Subject: Re: Spartan 3 Experimenter's Board
From: Ziggy <Ziggy@TheCentre.com>
Date: Thu, 06 Jan 2005 20:20:31 GMT
Links: << >>  << T >>  << A >>

Looks interesting, but its a shame it does not have more 'standard' ports..

I realize you can wire them up yourself, but the more that are on board
the less you have to dink around with..

Digiants boards look really good for development projects.  Especially 
with the 400k upgrade option. Waiting on my to arrive.

PNowe wrote:
> If anyone is looking for a Spartan 3 board for hobbyists and students, that 
> also includes a solderless breadboard for adding your own circuitry, have a 
> look at  www.dulseelectronics.com .  An article about the board appeared in 
> the Dec 2004 issue of Circuit Cellar Magazine.
> 
> Phil
> Dulse Electronics
> 
> 

Article: 77441
Subject: Re: iMPACT 5.1i w/Parallel Cable
From: "Ewan D. Milne" <milne@egenera.com>
Date: 6 Jan 2005 12:22:13 -0800
Links: << >>  << T >>  << A >>
I eventually figured out what was wrong, so I'll post the solution
in case anyone ever runs into the same problem.

The problem was the windrvr.sys file in C:\WINNT\system32\drivers
It was present, but it was an older version of the driver.  A newer
version was in the $XILINX\bin\nt directory and I copied it to the
right place.

Thanks very much to all who responded.

-Ewan


Article: 77442
Subject: Re: MAP failes after inserting ILA and ICON cores to the design
From: "ran" <ranshadmi@walla.co.il>
Date: 6 Jan 2005 13:04:00 -0800
Links: << >>  << T >>  << A >>
Thanks Ray for your comment.

How do you deduct from the error message the possibility of a gated
reset ? and how could that be related to the addition of ICON and ILA
cores ? that is the only "delta" from my "healthy" design ...

Ran


Article: 77443
Subject: Re: VHDL Test Bench + Help
From: "fpga kid" <yangdexue@gmail.com>
Date: 6 Jan 2005 13:46:38 -0800
Links: << >>  << T >>  << A >>
A great vhdl online reference 
http://www.vhdl-online.de/~vhdl/


Article: 77444
Subject: Re: San Jose job offer - need advice
From: Eric Smith <eric-no-spam-for-me@brouhaha.com>
Date: 06 Jan 2005 13:47:27 -0800
Links: << >>  << T >>  << A >>
vbishtei@hotmail.com (vadim) writes:
> I have received a job offer from a company in San Jose,
> California. [...] The salary offered is 67k/year [...] I already have
> a 60k/year job in Toronto, [...] I was told that the housing prices of
> Bay Area will make this salary into a 50k equivalent of Toronto.

I think you'll find it to be much worse than that, unless Toronto has a
high cost of living (I wouldn't know).  Real estate in the San Jose area
is very expensive.  Not the highest in the US, but close.  It's about
2-3 times what it is in the U.S. midwest.

> I have a dillema whether: 
> -Professional advantages of this position, closer to ciruit design. 
> -Working in Silicon Valley, the Mecca of HighTech. 
> 
> outweigh the offered salary ?

I wouldn't take it, but YMMV.

When I moved from the midwest to San Jose in 1989, it was for a $40K
salary.  I thought that was great until I got here and discovered that
I could barely make ends meet even when sharing a condo.

On the other hand, job satisfaction is worth a lot.

Article: 77445
Subject: Re: San Jose job offer - need advice
From: nweaver@soda.csua.berkeley.edu (Nicholas Weaver)
Date: Thu, 6 Jan 2005 22:00:15 +0000 (UTC)
Links: << >>  << T >>  << A >>
In article <2a613f5d.0501052055.3ac008a9@posting.google.com>,
vadim <vbishtei@hotmail.com> wrote:
>I have received a job offer from a company 
>in San Jose, California. The position title is: Test Development
>Engineering. The salary offered is 67k/year with Relocation Assistance
>and a Benefits package. I already have a 60k/year job in Toronto,
>Canada as Applications Engineer.
>
>The San Jose job is closer to circuit-design which is an area I would
>like to get into.
>
>I was told that the housing prices of Bay Area will make this salary
>into a 50k equivalent of Toronto. So practically my "buying power" is
>reduced.

And then some.  A little trawling of Craigslist for Santa Clara
housing:

random studios are about $900 a month (that's single room with
kitcheette and bathroom).

2 bdrms are $1300+.

Buing is much worse, however.  Even a 6 figure income has most bay
area houses unaffordable.

People ask $490,000 for 2 bedroom, 900 square feet homes in Santa
Clara.  Yes, thats not a typo, 1/2 a million for a 2 bdrm bungalo.


Not to mention that the US dollar has further to drop, and Toronto is
not ruled by a President who believes it is more important to be loyal
than correct.
-- 
Nicholas C. Weaver.  to reply email to "nweaver" at the domain
icsi.berkeley.edu

Article: 77446
Subject: Re: ISE Toolflow : hardmacro, incremental or modular
From: Brian Drummond <brian@shapes.demon.co.uk>
Date: Thu, 06 Jan 2005 22:39:42 +0000
Links: << >>  << T >>  << A >>
On Thu, 06 Jan 2005 12:23:00 -0700, Bret Wade <bret.wade@xilinx.com>
wrote:

>Brian Drummond wrote:
>> On Wed, 05 Jan 2005 12:06:48 -0700, Bret Wade <bret.wade@xilinx.com>
>> wrote:

>> I am working with larger RPMs than this, with some degree of success
>> (cautiously expressed; the design is not yet complete)
>> 
>> There *may* be problems with BRAMs and multipliers in RPMs.
>> 
>There is a certain amount of complexity added when an RPM combines 
>multiple component types (Heterogeneous RPM) due to the fact that for 
>the default grid system, the various component types are on different 
>grids. This is only a problem if your RPM requires normalization. 
>http://www.xilinx.com/bvdocs/appnotes/xapp416.pdf

This is _very_ good information on RPMs including BRAMS or multipliers
or such (IOBs?) which live on different grids. 

I note S0 and S1 share the same RPM_GRID X value though (unless I
misunderstand the floorplanner) they appear in adjacent columns (x, x+1)
in floorplanning, e.g. 

floorplanner and standard grid
S2 S3
S0 S1

RPM_GRID
S3
S2
S1
S0

The translation given from SLICE_X26Y40 to RPM Grid X42Y84 in the
appnote seems to bear this out.

>> There are problems using the floorplanner to create RPMs from smaller
>> ones, mostly associated with tools issues (the floorplanner alone has
>> two mutually incompatible understandings of RLOC_ORIGIN, the mapper
>> moves the origin left by 1 location under some (apparently undefined)
>> circumstances, the placer reports errors on some correct RLOC_ORIGIN
>> constraints and silently deletes others altogether, and so on. 
>
>RLOC_ORIGIN values must take into account the normalization of the RPM. 
>More on that in the appnote. 

It's not clear to me quite how that relates to the testcase, which only
uses LUTS, SRL16s, and FFs, which are all on the same grid (Spartan-3
restrictions on SRL16 notwithstanding). R0C0 is used, though some
elements have negative X values (the floorplanner doesn't give you any
choice about this if you don't use the lower left hand corner of the
bounding box surrounding the RPM). 

Is normalisation still an issue in this case? 
It seems to me that the normalisation is onto the same grid since
RPM_GRID is not being used, so I don't see where the problem lies. 

And outside Xapp416 and this message, I haven't seen any mention of
normalisation. Is it described anywhere for the standard grid?
Aha! Searching on that word gives the useful looking TechXclusive
"Relationally Placed Macros 08/30/2002 "
http://www.xilinx.com/xlnx/xweb/xil_tx_display.jsp?iCountryID=1&iLanguageID=1&sTechX_ID=pgse_rpms&BV_SessionID=@@@@0242741689.1105050007@@@@&BV_EngineID=cccgadddhmijmghcflgcefldfhndfnf.0

>The mapper converts RLOC_ORIGINs into MACRO 
>LOCATE constraints in the PCF file, so strictly speaking it's not 
>possible for the placer to ignore RLOC_ORIGIN constraints because it 
>never sees them.

True! Strictly speaking the placer ignores the MACRO LOCATE constraints
instead. They are in the PCF file, I just checked - see comment above
regarding the mapper moving the origin, it does so in the same
constraint conversion.

>A separate issue is that the RPM needs to be placed in the same "slice 
>type" that it was created about. There are four slice types represented 
>by the four slices in a CLB, S0-S3. For simplicitys sake, it is best to 
>construct a macro about the X0Y0 slice and then always place it in an S0 
>slice type if possible. If the RPM is placed in a different slice type, 
>the relative placement will be broken, which can lead to placement 
>failures.

This may be the problem, but I don't see why the limitation exists.
Hand placement of the same components onto the other slice types (again,
excepting SRL16s in "odd X" locations) seems to work fine, though not
placement of RPMs.

>> Maybe FPGA editor is a more stable tool for floorplanning? I would try
>> it but only have WebPack in current software.
>
>FPGA Editor is not a floorplanner. It is an editor for displaying and 
>modifying the physical design and applying some physical constraints. 

I have used it (3.1 era) but don't have a current one.

>> Can you point me in the direction of a flow that would use guided
>> routing for a top level module composed of several pre-routed RPM
>> modules? Preferably where at least one of the RPMs has itself been
>> created in this way?

>Directed Routing is not incompatible with the guided flows. There's no 
>reason why you can't combine them. You'll just need to get FPGA Editor 
>and try it.
>

Interesting, but I think I have been warned off Directed Routing for the
size of macros I am using.

Is there a way of using routed versions (NCDs?) of several RPMs as
(multiple) guide files for a design incorporating them? Your earlier
recommendation that "Guide should be used instead" seems to imply that
there is, but I can't see it.

Many thanks for your answers and help,

- Brian

Article: 77447
Subject: Re: Xilinx 6.2 to 6.3 upgrade brakes soc
From: "joe4702" <joe4702@hotmail.com>
Date: 6 Jan 2005 15:10:24 -0800
Links: << >>  << T >>  << A >>
>"Rudolf Usselmann" <russelmann@hotmail.com> wrote in message

>Just upgraded ISE and EDK to 6.3 from 6.2.
<snip>

> > Sorry, I was not very clear. The UART prints half of the message
> > ok, than skips a lot than again a few readable words ...
> >
> > I did check all the obvious things like baud rate etc. Thats not
> > it. There seems some fundamental difference. The SoC seems to
> > "hang" as well. Like may be something in the software changed ...
> > it still does compile clean, and I did re-compile everything ...
> > I spend two days trying to figure out what was wrong, than switched
> > back to EDK 6.2.
> >
> > Thanks,
> > rudi
> > =============================================================
> > Rudolf Usselmann,  ASICS World Services,  http://www.asics.ws
> > Your Partner for IP Cores, Design, Verification and Synthesis

I just upgraded 6.2 to 6.3 and am seeing the same symptoms.
Garbled/missing console output and random resets/crashes. If I compile
my code under EDK 6.2, it runs fine on the FPGA image created by EDK
6.3. Also,
running 6.3 compiled code on a 6.2 FPGA image results in the same
misbehavior. I suspect bugs in the GNU tools or libraries.

I fixed the console issue by turning off the "Global Pointer
Optimization" and by using xil_printf in place of printf. However, even
with these changes or with optimization turned off completely, I still
get crashes/resets.

I have opened a Webcase with Xilinx support and will post any results
here.

Joe


Article: 77448
Subject: Re: MAP failes after inserting ILA and ICON cores to the design
From: Bret Wade <bret.wade@xilinx.com>
Date: Thu, 06 Jan 2005 16:12:09 -0700
Links: << >>  << T >>  << A >>

> 
> After which the mapper failes. If I remove the "-timing" option of
> the MAP, the mapper succeeds but the PAR failes (unrouted signals).
> Any suggestions ?
> 
> Ran
> 

Something to try as a work around would be to lock the the Chipscope RPM 
  down based on either the somewhat successfully non-timing driven run 
or based on your own judgment. The timing driven packer has some 
difficulty resolving the placement of RPMs, especially in the presence 
of area constraints and local clock placement requirements (will improve 
in 7.1i). With the RPM locked, the timing driven packer is likely to be 
successful and may resolve the congestion problems you're having with 
the non-timing driven flow.

Regards,
Bret

Article: 77449
Subject: Re: How to change temperature in Xilnx Webpack with free starter Modelsim
From: "gja" <geeja@hotmail.com>
Date: Thu, 6 Jan 2005 18:56:34 -0500
Links: << >>  << T >>  << A >>
Anyone?


"gja" <geeja@hotmail.com> wrote in message
news:iAgDd.3927$QK1.1028@fe11.lga...
> Tried that, but i get this warning message:
>
> Started process "Generate Post-Place & Route Simulation Model".
>
> WARNING:Anno:255 - command line '-s -4' overrides .pcf TEMPERATURE =
70.000
> C
>
>
>
>
> "Falk Brunner" <Falk.Brunner@gmx.de> wrote in message
> news:345bivF47eeulU3@individual.net...
> >
> > "gja" <geeja@hotmail.com> schrieb im Newsbeitrag
> > news:SQdDd.3214$yK7.3065@fe11.lga...
> > > I want to do post place and route timing simulation on a Virtex2 part
> > using
> > > the Xilinx Modelsim starter simulator, how can I set the temperature
> point
> > > to 70 celcius?
> >
> > Add
> >
> > temperature=70C;
> >
> > to your UCF
> >
> > Regards
> > Falk
> >
> >
> >
> >
> >
>
>





Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search