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 75275

Article: 75275
Subject: Re: Low-power FPGAs?
From: rickman <spamgoeshere4@yahoo.com>
Date: Mon, 01 Nov 2004 00:32:27 -0500
Links: << >>  << T >>  << A >>
Phil Short wrote:
> 
> It seems to me that you want something that is impossible.  On one hand,
> you seem to want an explanation that is reduced to bite-sized slogans.  On
> the other hand, you want to argue with the simplified explanation, picking
> on details that are to complicated to fit into one sentence.  So which do
> you want - a simple slogan, or a detailed, nuanced discussion?  You can't
> have both.  You've had the first, and decided to argue with it.  So you
> must really want the second, in which case you should really take the time
> to read what much more qualified persons have written about at length in
> books and formal papers.

No Phil, am not asking for "bite-sized slogans".  I am asking for a
simple explanation of how this technology works better.  Is it really
that complex that it can't be explained?  


> One obvious source of juice is the difference between the longest and
> shortest combinatorial delays (i.e. flip-flop output delay plus routing
> delays plus LUT delays plus flip-flop setupt time plus (perhaps) clock
> skew). The clock period in a sync design is determined by the maximum
> delay. However, the device still has to wait for an entire clock period
> even during a cycle when all relevant combinatorial delays are much
> less than the maximum. This would not be the case in an async design,
> where the performance of a circuit over a period of time is more likely to
> be a multiple of the average combinatorial delay rather than a multiple of
> the maximum combinatorial delay.

Yes, but I explained how in a real time system, this only moves the
problem from the clock domain to the system domain.  Your chip can run
at faster speeds when it is cooler or just a faster chip (process) but
that won't be of any value since you have to design your system to the
worst case chip delay.  

If you are talking about the different paths within the chip, I still
don't agree that there is a significant difference.   Sync logic is
balanced so that the different circuits have about the same delay so
that the clock speed can be optimized.  So there is not much waste
between the separate circuits.  Within a given circuit the async logic
still has to wait for the logest delay since it has no way of knowing
what speed the logic will run.  Remember the async handshake is really a
delayed clock and must be delayed more than the worst path through the
combinatorial logic.  


> EMI reduction due to spreading the switching current spikes over time
> comes for free in an async design, rather than required special clock
> chips.

Yes, this is one advantage that async circuits have.  But it is
certainly not enough to warrant the efforts required for async design.  

-- 

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX

Article: 75276
Subject: Re: Low-power FPGAs?
From: hmurray@suespammers.org (Hal Murray)
Date: Sun, 31 Oct 2004 23:34:48 -0600
Links: << >>  << T >>  << A >>
>This is not at all "innate" in silicon.  The chips just need to be
>designed for a range of Vcc rather than optimized for the best Vcc as
>FPGAs are.

They don't have to be designed for multiple voltages.  You can design
them for the primary target and then characterize them (aka fill in the
blanks in the data sheet) at other voltages.

Might be an interesting market opportunity.  Similar to what Xilinx
is doing with only testing to meet a specific design.  Just run the
tests at a different voltage.  (after figuring out how fast the chip
should go so and making another set of speed files for the tools and
...) 

-- 
The suespammers.org mail server is located in California.  So are all my
other mailboxes.  Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's.  I hate spam.


Article: 75277
Subject: Re: Low-power FPGAs?
From: rickman <spamgoeshere4@yahoo.com>
Date: Mon, 01 Nov 2004 00:38:05 -0500
Links: << >>  << T >>  << A >>
Phil Short wrote:
> 
> On Sun, 31 Oct 2004 14:49:44 -0600, Hal Murray wrote:
> 
> 
> > With an async system, I'd expect you could do the same sort
> > of thing.  Maybe use timers rather than a spin/poll loop to
> > keep with the low-power philosophy.  But now the problem is
> > that you have to correct for temp, voltage, and process.
> > Temp and voltage you can measure.  You can probably measure
> > process by running some calibration code.  But you still have
> > to add a fudge factor for the software.  How important is the
> > software uncertantity relative to the hardware uncertantity?
> 
> It strikes me that the hardware vendor would characterize and bin the
> devices in some way that would be meaningful, and provide design tools
> that would aid in this manner.  For a fixed-function device (e.g. UART or
> fifo) the binning process at the semiconductor vendor would take care of
> the speed issue in just the same manner as is done today (from the
> viewpoint of someone incorporating the part in their design). For an
> instruction-programmable part (i.e. CPU) this would also be the same as
> for today (parts speed-graded by the manufacturor, user doesn't have any
> meaningful way to compare parts).  And who knows if there will ever be
> async programmable logic parts, but if there is, again the manufacturor
> speed-grades the parts and has to provide layout and (worst-case) static
> timing tools to the designer (no more 'magic' than the current FPGA/CPLD
> situation).

Ok, I think we are closing the loop here.  Doesn't this make it clear
that when designing with an async part, you still have to allow for the
worst case timing in your system design?  Doesn't that eliminate any
speed advantage async parts might have by running faster when they can?  

-- 

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX

Article: 75278
Subject: Re: Low-power FPGAs?
From: Phil Short <pjs@switchingpost.nospam.com>
Date: Mon, 01 Nov 2004 06:31:22 GMT
Links: << >>  << T >>  << A >>
On Mon, 01 Nov 2004 00:32:27 -0500, rickman wrote:

> Phil Short wrote:
>> 
> 
> No Phil, am not asking for "bite-sized slogans".  I am asking for a
> simple explanation of how this technology works better.  Is it really
> that complex that it can't be explained?  
> 

Yes, it is too complex to explain by someone who is not a professional
writer over a channel with multiple-hour round-trip delays, no visual
feedback and no decent way to draw diagrams to explain points.

>
>> One obvious source of juice is the difference between the longest and
>> shortest combinatorial delays (i.e. flip-flop output delay plus routing
>> delays plus LUT delays plus flip-flop setupt time plus (perhaps) clock
>> skew). The clock period in a sync design is determined by the maximum
>> delay. However, the device still has to wait for an entire clock period
>> even during a cycle when all relevant combinatorial delays are much
>> less than the maximum. This would not be the case in an async design,
>> where the performance of a circuit over a period of time is more likely
>> to be a multiple of the average combinatorial delay rather than a
>> multiple of the maximum combinatorial delay.
> 
> Yes, but I explained how in a real time system, this only moves the
> problem from the clock domain to the system domain.  Your chip can run
> at faster speeds when it is cooler or just a faster chip (process) but
> that won't be of any value since you have to design your system to the
> worst case chip delay.
> 

I wasn't talking about the system domain.  You are correct in hinting that
there are significant problems interfacing between sync and async chips,
such that the literature suggests that most of the speed benefits of async
design may be lost in this case.  It seems that it would be better if
everything in the system is async, rather than a mix.  Just another
problem in gaining more widespread acceptance.

> If you are talking about the different paths within the chip, I still
> don't agree that there is a significant difference.   Sync logic is
> balanced so that the different circuits have about the same delay so
> that the clock speed can be optimized.  So there is not much waste
> between the separate circuits.  Within a given circuit the async logic

Every circuit that I have ever designed has had a lot of waste.  This
includes both microprocessor-based systems and FPGA designs.  Ignoring
large combinatorial arithmetic elements, the control logic alone has had a
large amount of non-fixable variation in delay.  In any given circuit
there have been places where accidents (or deliberate) of state machine
design allow the output of one register to be directly connected to the
input of another register, and other places in the same logic block where
there may be half a dozen or dozen layers of logic, with no way to allow
signals in the latter path to take multiple clocks before they are needed.
All of these _differences_ in delay can add up.

> still has to wait for the logest delay since it has no way of knowing
> what speed the logic will run.  Remember the async handshake is really a
> delayed clock and must be delayed more than the worst path through the
> combinatorial logic.
>

In fact, there are some (all?) async methodologies where there are no
flip-flops at all, the state information ends up being 'kept' in the delay
elements.  In any case, the absence of any sensible way to use async
design methods with FPGAs has prevented me from taking the time to totally
wrapping my head around the detailed design methods.  They are so
different from sync design methodologies that I suspect that you have
misconceptions about how things would work in an async design, with no way
for me to determine what these misconceptions are in these usenet
interactions.

It would be best if you were curious to know more about async design to go
back to more fundamental sources than usenet.  I personally am always very
suspicious of condensed or regurgitated descriptions, and prefer to go
back to the most basic readable source.  Takes more time, but then I am
better able to understand what the real situation is, and to separate
urban legend from the facts.

As you note in another post, this thread has gone on too long.

Best,

-- 

Phil


Article: 75279
Subject: Re: XST: suppressing incorrect optimizations in VHDL code
From: sidney@jigsaw.nl (Sidney Cadot)
Date: 1 Nov 2004 00:07:59 -0800
Links: << >>  << T >>  << A >>
rickman <spamgoeshere4@yahoo.com> wrote in message news:<4185154A.25EEDBE0@yahoo.com>...
> Sidney Cadot wrote:
> > 
> > I would like to keep the things that are different for each of the
> > boards concentrated in my "memory mapped I/O" VHDL source,  for which
> > I have three versions - one for each board.
> > 
> > However, since XST needs toplevel ports for all external ports, I am
> > currently forced to have three different versions for two hierarchical
> > levels of design above the "memmapped-io.vhdl" as well, namely my
> > toplevel design (toplevel.vhdl) and the MMU (mmu.vhdl) that routes
> > between the CPU and the RAM, ROM, and I/O apertures. The only reason I
> > need three versions of my toplevel and mmu entities is that I must
> > hook up some external pins into the mmapped_io entity.
> 
> Maybe I am being a little dense today, but I still don't understand.  If
> your IO functions are the same why would you need different ports?  What
> is different between the boards that you can't just describe the
> differences in the IO pin assigments in the UCF file?

I failed to make that particularly clear (sorry). There are hardware
differences, e.g.

* The number of seven-segment displays 0/1/4
* The number of LEDs 4/8/8
* The number of push-buttons: 2/3/4
* The number of sliding switches: 0/4/8
* The availability of AD/DA's on the development board
* The interface to memory residing on the memory board

> Even if you don't use a port, don't you still need different top level files?

I don't see why that would be necessary.
 
> Instantiating the IO pads is a good idea.

Unfortunately, it didn't work - apparently the IPAD components are not
contained in the UNISIM library, and just instantiated implicitly.
This rhymes with another tidbit I found in the IPAD docs (Library
Guide):

"For HDL, it is not necessary to use these elements in the design.
They will be added  automatically."

> If that doesn't work nothing will.  

Why are you so sure? I still have some hope :)

Regards, Sidney

Article: 75280
Subject: Re: XST: suppressing incorrect optimizations in VHDL code
From: sidney@jigsaw.nl (Sidney Cadot)
Date: 1 Nov 2004 00:28:10 -0800
Links: << >>  << T >>  << A >>
newman5382@aol.com (newman) wrote in message news:

> The Designer's Guide To VHDL 2'nd Edition
> Peter J. Ashenden
> Page 8
> "Using VHDL terminology, we call the module reg4 a design entity, and
> the inputs and outputs are ports.  Figure 1-7 shows a VHDL description
> of the interface to the entity. This is an example of an entity
> declaration. It introduces a name for the entity and lists the input
> and output ports, specifying that they carry bit values ('0' or '1')
> into and out of the entity. From this we see that an entity
> declaration describes the external view of the entity."

> If one were to be able to snake a signal out, without mapping it thru
> a port, then the entity declaration would not describe the external
> view of the entity.

There are two answers to this: a philosophical one and a practical
one.

(1) Philosophical

The "external view" (VHDL wise) of my "mmapped_io" component is
basically that it acts like a RAM block, i.e., it has a data bus and
an address bus, and R/W control bits. The fact that these happen to do
some interesting things to hardware, should be of no concern to the
VHDL modules that instantiate an "mmapped_io" component, that's the
whole point of having memory mapped I/O.

My mmapped I/O defines a 4K aperture to hardware. My "RAM" components
describe a 4K aperture to RAM. At a higher level in my design, I
should be able to interchange them without any changes except for the
instantiated component name I think.

(2) Practical

Ashenden notwithstanding, the VHDL program shown below demonstrates
that XST can in fact bypass ports, at least for outgoing signals.
Despite the fact that it is not declared in the entity's port section,
the LED does blink when I synthesize and upload this.

All I am asking is for a way to coerce XST to handle input signals in
a similar way.

Regards, Sidney

----------------------------------- blingbling.vhdl
library ieee, unisim;

use ieee.std_logic_1164.all,
    ieee.std_logic_unsigned.all,
    unisim.vcomponents.all;

entity toplevel is
  port(CLK: in std_logic);
end entity toplevel;

architecture arch of toplevel is

  signal LED     : std_logic;
  signal sig_led : std_logic;

  attribute LOC : string;

  attribute LOC of CLK : signal is "P184";
  attribute LOC of LED : signal is "P20";

  component OBUF is
    port (O: out std_ulogic; I: in std_ulogic);
  end component OBUF;

  signal counter: std_logic_vector(23 downto 0);
  
begin

  led_buf: component OBUF port map (O => LED, I => not sig_led);
  
  process (CLK) is
  begin
    if rising_edge(CLK) then
      counter <= counter + 1;
    end if;
  end process;

  sig_led <= counter(23);
  
end architecture arch;

Article: 75281
Subject: Re: Strange XST error in ISE 6.3.02i
From: "Alan Fitch" <alan.fitch@doulos.com>
Date: Mon, 1 Nov 2004 09:14:11 -0000
Links: << >>  << T >>  << A >>

"rickman" <spamgoeshere4@yahoo.com> wrote in message
news:4182813D.B18325F4@yahoo.com...
> John wrote:
> >
> > Hi Rick,
> > Three things come to mind:
> >
> > 1) The error message seems to be objecting the formal input
"opcode",
> > which is declared to be of type "IRSLV". Does changing the type to
> > "standard_logic_vector" help at all? Maybe XST gets confused over
type
> > declarations.
>
> I haven't tried that.  I check.
>
>
> > 2) Perhaps the problem is in the function usage rather than the
> > function itself. Can you show a code snippet where the function is
> > called?
>
> This error happens when compiling the definition, not the useage.
It
> craps out on this file and never gets to the file where it is
called.
>
>
> > 3) I've had problems where stuff in a packaged library would not
work
> > unless the library was first 'compiled' by running 'check syntax'
on
> > the library package alone, separately from the design, in the ISE
> > environment. Maybe this would help?
>
> Yes, this is being compiled and not just syntax checked.
>
> I am pretty convinced that this is an XST bug.  The fact that it
gives
> the name LIT as the function name says something is pretty messed
up.
> But I am still open to the short between the headphones theory.
>


Just out of curiosity, does using a selected name work, e.g.

  return packagename.INSTDSPLY

?

Alan


-- 
Alan Fitch
Consultant

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

Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24
1AW, UK
Tel: +44 (0)1425 471223                          mail:
alan.fitch@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: 75282
Subject: Re: XST: suppressing incorrect optimizations in VHDL code
From: Marc Randolph <mrand@my-deja.com>
Date: Mon, 01 Nov 2004 05:50:12 -0600
Links: << >>  << T >>  << A >>
Sidney Cadot wrote:
> rickman <spamgoeshere4@yahoo.com> wrote in message news:<4185154A.25EEDBE0@yahoo.com>...
> 
>>Sidney Cadot wrote:
>>
>>>I would like to keep the things that are different for each of the
>>>boards concentrated in my "memory mapped I/O" VHDL source,  for which
>>>I have three versions - one for each board.
>>>
>>>However, since XST needs toplevel ports for all external ports, I am
>>>currently forced to have three different versions for two hierarchical
>>>levels of design above the "memmapped-io.vhdl" as well, namely my
>>>toplevel design (toplevel.vhdl) and the MMU (mmu.vhdl) that routes
>>>between the CPU and the RAM, ROM, and I/O apertures. The only reason I
>>>need three versions of my toplevel and mmu entities is that I must
>>>hook up some external pins into the mmapped_io entity.
>>
>>Maybe I am being a little dense today, but I still don't understand.  If
>>your IO functions are the same why would you need different ports?  What
>>is different between the boards that you can't just describe the
>>differences in the IO pin assigments in the UCF file?
> 
> 
> I failed to make that particularly clear (sorry). There are hardware
> differences, e.g.
> 
> * The number of seven-segment displays 0/1/4
> * The number of LEDs 4/8/8
> * The number of push-buttons: 2/3/4
> * The number of sliding switches: 0/4/8
> * The availability of AD/DA's on the development board
> * The interface to memory residing on the memory board

You could select between these with active internal logic, or if you 
know the difference at compile time, with generate statements or by 
passing generic values into the entities, right?

I still must be missing something... I don't see how pushing the pin 
location assignments deep into the hierarchy makes anything easier.  You 
can always make the bus wider need it needs to be to the top level - the 
tools will optimized it down to the correct width.

>>Even if you don't use a port, don't you still need different top level files?
>  
> I don't see why that would be necessary.

Unless it is necessary because some tools require it.  :-)   I don't 
pretend to know if VHDL requires the ports to be at the top level or 
not, but it would not surprise me if some of the tools don't handle it 
correctly.

Have fun,

    Marc

Article: 75283
Subject: Question on Xilinx VirtexProII PCMCIA support (FPGA boards).... please
From: "Mark Levitski" <MetalBladeSPAMNOMORE@SPAMNOMOREprodigy.net>
Date: Mon, 01 Nov 2004 11:55:31 GMT
Links: << >>  << T >>  << A >>
I posted here before and got excellent responses, could you knowledgeable 
people also answer a simple questuion below?  If you reply by email, REMOVE 
"SPAMNOMORE" in capital letters repeated in my address twice (edit address 
manually)!!


We need to make sure Xilinx VirtexProII FPGA boards have a PCMCIA interface 
(hardware) and software support, and whether inteface is a regular one 
usable with standard IEEE802.11 cards (WIRELESS LAN modules).  The two 
boards (need info for BOTH!!) are:
ML 300 and ML310
One is just a board another is a complete development kit, I am not sure 
yet.

I did contact Xilinx first, but here's what happened:
At first Xilinx engineers said PCMCIA is not supported, but then came back 
to me saying this:
ML300 board: the PCMCIA supported, whereas PCI is supported only with much 
more effort on our side.  ML310 board: The opposite (i.e. the PCI is 
supported, while the PCMCIA is not fully supported.)
Thus we're completely confused and need to double check these answers, 
before comitting time/money.  I CAN"T CONTACT THEM ANYMORE FOR THE SAME 
QUESTION AS MY XILINX PERSONAL ID HAS ALREADY BEEN USED FOR THE SAME 
QUESTION, I'd appreciate if you help.



Article: 75284
Subject: compactflash interface problem
From: "NoThisRAT" <nothisrat@yahoo.com>
Date: Mon, 1 Nov 2004 21:40:03 +0800
Links: << >>  << T >>  << A >>
hello,
  I design a compactflash interface between pci and a sandisk compactflash
with true-ide mode, but I have some problem now. after reset, I try to read
the status register of CF, I got 0x58. When I try any ATA commands like read
sectors or set features ( set CF to PIO mode), I got 0x59 from status
register. What is the matter? I think I make the read/write sequence right.
  BTW, the timing parameters I used is PIO-0.

  Thanks!



Article: 75285
Subject: Re: Question on Xilinx VirtexProII PCMCIA support (FPGA boards).... please
From: "Antti Lukats" <antti@case2000.com>
Date: Mon, 1 Nov 2004 15:54:17 +0100
Links: << >>  << T >>  << A >>
"Mark Levitski" <MetalBladeSPAMNOMORE@SPAMNOMOREprodigy.net> wrote in
message news:Tuphd.25819$Qv5.25281@newssvr33.news.prodigy.com...
> I posted here before and got excellent responses, could you knowledgeable
> people also answer a simple questuion below?  If you reply by email,
REMOVE
> "SPAMNOMORE" in capital letters repeated in my address twice (edit address
> manually)!!
>
>
> We need to make sure Xilinx VirtexProII FPGA boards have a PCMCIA
interface
> (hardware) and software support, and whether inteface is a regular one
> usable with standard IEEE802.11 cards (WIRELESS LAN modules).  The two
> boards (need info for BOTH!!) are:
> ML 300 and ML310
> One is just a board another is a complete development kit, I am not sure
> yet.

Hi Mark,

1) ML300 is considered "being phased out" - people had trouble attempting to
buy it. So its possible out of the question anyway as you simple may not get
it at all any more.

as of your specific question for PCMCIA support - I would say expect about 1
month of engineerig time from your site, no matter what FPGA platform you
choose (ML300 or ML310). Maybe some other vendor has something that requires
less time for you to accomplish what you need.

Antti



Article: 75286
Subject: Re: information about Nuhorizon Spartan-3 Development Board ?
From: "E.S." <emu@ecubics.com>
Date: Mon, 01 Nov 2004 08:22:14 -0700
Links: << >>  << T >>  << A >>
Tom Seim wrote:
> jm_contact2002@yahoo.fr (jerome) wrote in message news:<96a74216.0410280152.436c4fc3@posting.google.com>...
> 
>>Hello,
>>
>>Could someone give me information about the Nuhorizon Spartan-3
>>Development Board?
>>It seems to be a good one based upon the Spartan-3 400 thousand gate
>>FPGA (XC3S400-4PQ208C).
>>Could someone confirme me I can use it with the ISE Webpack 6?
>>A contact in NuHorizon told me I need full software, but I don't
>>understand.
>>
>>Any other comment or suggestion?
>>
>>Thanks,
>>
>>Jerome.
> 
> 
> We have had an extremely negative experience dealing with Nu Horizons.
> They "take" orders, then don't deliver. After very persistent calling
> they deliver partials, some of which are defective.
> 
> Don't deal with them-they are VERY UNRELIABLE!!!

I thought, I would be the only one ...

Ordered this board, because it was in stock with overnight shipping,
after few days checked again, NO STOCK, NOT AVAILABLE, please call ...

Tried to reach anybody at the web-order number, for more than 3 weeks 
(at least twice a week), they don't return phone calls. After three 
weeks, I canceled my order via phone. Few minutes later I got a guy on 
the phone from NuHorizon saying, they got a board in (1?), and could 
ship it immediately. But at this time, I really had enough ...

Looking at mail from other people and their expierence with that board,
I guess, I'm pretty happy without ;-)



Article: 75287
Subject: Re: max frequency with TSMC .18u std cell library
From: Kai Harrekilde-Petersen <khp@harrekilde.dk>
Date: Mon, 01 Nov 2004 18:19:54 +0100
Links: << >>  << T >>  << A >>
whizkid@gamebox.net (whizkid) writes:

> Hi all,
>   what is the max frequency you have achieved with TSMC 18um library.
> I an trying to synthesise a design at 528Mhz(1.8ns). Design Compier
> results shows that the synthesis timing constraints were met. But when
> I do netlist simulations I am getting 1000's of timing violations...I
> checked the verilog simulaton model for the library and found that the
> setup and hold checks are done in the library for 1ns ... ie for a
> clock edge I need 1+1 ns for just satisying the setup hold
> constraints... well my doubt is why the DC tool says the timing
> constraints are met.. do you have any idea.

Sounds like you haven't backannotated the netlist with SDF.


Kai
-- 
Kai Harrekilde-Petersen <khp(at)harrekilde(dot)dk>

Article: 75288
Subject: Re: XST: suppressing incorrect optimizations in VHDL code
From: rickman <spamgoeshere4@yahoo.com>
Date: Mon, 01 Nov 2004 12:24:08 -0500
Links: << >>  << T >>  << A >>
Sidney Cadot wrote:
> 
> rickman <spamgoeshere4@yahoo.com> wrote in message news:<4185154A.25EEDBE0@yahoo.com>...
> 
> > Even if you don't use a port, don't you still need different top level files?
> 
> I don't see why that would be necessary.

I am missing something.  Are you planning to instantiate your IO ports
in low level modules or in the top module?  The example you gave is
using the top module, but I guess that was a simplification.  

If you are trying to put the IOs into lower level modules, you may find
this is a bit difficult to keep track of.  But that is just a style
preference.  

-- 

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX

Article: 75289
Subject: Re: Strange XST error in ISE 6.3.02i
From: rickman <spamgoeshere4@yahoo.com>
Date: Mon, 01 Nov 2004 13:34:22 -0500
Links: << >>  << T >>  << A >>
Alan Fitch wrote:
> 
> "rickman" <spamgoeshere4@yahoo.com> wrote in message
> news:4182813D.B18325F4@yahoo.com...
> > John wrote:
> > >
> > > Hi Rick,
> > > Three things come to mind:
> > >
> > > 1) The error message seems to be objecting the formal input
> "opcode",
> > > which is declared to be of type "IRSLV". Does changing the type to
> > > "standard_logic_vector" help at all? Maybe XST gets confused over
> type
> > > declarations.
> >
> > I haven't tried that.  I check.
> >
> >
> > > 2) Perhaps the problem is in the function usage rather than the
> > > function itself. Can you show a code snippet where the function is
> > > called?
> >
> > This error happens when compiling the definition, not the useage.
> It
> > craps out on this file and never gets to the file where it is
> called.
> >
> >
> > > 3) I've had problems where stuff in a packaged library would not
> work
> > > unless the library was first 'compiled' by running 'check syntax'
> on
> > > the library package alone, separately from the design, in the ISE
> > > environment. Maybe this would help?
> >
> > Yes, this is being compiled and not just syntax checked.
> >
> > I am pretty convinced that this is an XST bug.  The fact that it
> gives
> > the name LIT as the function name says something is pretty messed
> up.
> > But I am still open to the short between the headphones theory.
> >
> 
> Just out of curiosity, does using a selected name work, e.g.
> 
>   return packagename.INSTDSPLY

Just like I suspected all along, it was a user error.  I had a function
with the same name as an enumeration value.  The other tools seemed to
figure it out by context, but XST didn't like it.  

So I have fixed that, but I am getting another set of errors where it
does not like my constants I think.  I have defined a set of constant
SLVs to match my opcodes.  To make defining them easier I entered their
values as function calls...

  constant LTRL : INSTVAL := TO_INTEGER(INSTBITS'(0,0,0)); --  0 - 00
  constant NOP  : INSTVAL := TO_INTEGER(INSTBITS'(7,0,0)); --  1 - 80
  constant CALL : INSTVAL := TO_INTEGER(INSTBITS'(0,1,2)); --  2 - 87

INSTBITS is an array of three integers (range 0 to 7) which TO_INTEGER
converts to a single integer equal to the weighted sum, (i.e. binary
positions to integer value).  Logically this works and again, two other
tools compile this just fine.  XST barfs when I try to use one of these
constants as a case statement choice saying "Choice call is not a
locally static expression".  Does the use of a function in a constant
initialization make the constant not "locally static"?  I tried looking
in the LRM for a definition of "locally static" and could not find it.  

I did find on a web page that a locally static expression (LSE) can be
either a literal, a constant that is init'd by an LSE or a call to an
"implicitly predefined operator".  So I guess my function calls make my
constants only globally static and not locally static?  

-- 

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX

Article: 75290
Subject: Re: XST: suppressing incorrect optimizations in VHDL code
From: sidney@jigsaw.nl (Sidney Cadot)
Date: 1 Nov 2004 11:10:14 -0800
Links: << >>  << T >>  << A >>
Marc Randolph <mrand@my-deja.com> wrote in message news:<vf-dnWXXTflpvxvcRVn-vg@comcast.com>...

> I still must be missing something... I don't see how pushing the pin 
> location assignments deep into the hierarchy makes anything easier. 

It enhances the maintainability of the code, by concentrating all the
knowledge about the particular hardware devices available in one
place. For example, adding support for yet another board is then a
matter of making one "mmapped_io_<boardtype>.vhdl" and recompiling.

> You  can always make the bus wider need it needs to be to the top level - the 
> tools will optimized it down to the correct width.

This is one of many options to work around the problem.

> >>Even if you don't use a port, don't you still need different top level files?
> > I don't see why that would be necessary.
> 
> Unless it is necessary because some tools require it.  :-)   I don't 
> pretend to know if VHDL requires the ports to be at the top level or 
> not, but it would not surprise me if some of the tools don't handle it 
> correctly.

That's very true. The fact that XST seems to handle non-toplevel
outgoing signals fine but isn't able to recognize incoming signals as
drivers suggests the possibility that it is just a problem in XST.

Cheers,
  Sidney

Article: 75291
Subject: Re: Using Xilinx fpga pins on external connector
From: gabor@alacron.com (Gabor Szakacs)
Date: 1 Nov 2004 11:55:00 -0800
Links: << >>  << T >>  << A >>
alann@accom.com (Alan Nishioka) wrote in message news:<a2db9b48.0410312049.a22a5ae@posting.google.com>...
> Can I safely connect Xilinx fpga pins to an external connector in a
> commercial product?
I do this, but not on a truly external connector, i.e. not
one that leaves the box.  It's generally O.K. to have mezzanine
connectors, but your guess on ESD is correct if you want an
external cable plugged in.
> I want to be able to control direction and use them in some yet to be
> determined manner.
> Will this be a problem for esd testing?
> Am I asking for someone to zap the most expensive part in my box?
Yes.
> What circuitry should I add to protect the fpga?
I'd say the best way is to insert transceivers, but
that would require picking a logic family.  At a minimum
I'd put Schottky clamps on the lines and even better something like
a QuickSwitch if you can afford the delay due to on resistance
and capacitive loading.
> 
> Alan Nishioka
> alann@accom.com

Article: 75292
Subject: Re: XST: suppressing incorrect optimizations in VHDL code
From: newman5382@aol.com (newman)
Date: 1 Nov 2004 13:21:29 -0800
Links: << >>  << T >>  << A >>
sidney@jigsaw.nl (Sidney Cadot) wrote in message 

<snip>
> 
> All I am asking is for a way to coerce XST to handle input signals in
> a similar way.
> 
> Regards, Sidney
<snip>

As others have already mentioned, one can use generic and conditional
generate statements to customize the designs.

I'm not aware that standard VHDL has a preprocessor #ifdef mechanism. 
There appear to be some third party offerings.  One may easily write
one that does the job with sed (less than 10 lines).

The method that you are pursuing may not work in future version of the
tools, but that is really for you to decide.  A possible solution to
get around the dilemma you face is to use an IOBUF instead of an IBUF,
and strap the T pin so the output is always tristated.  I personnally
do not recommend going this route, but it is really your call.

Newman

Article: 75293
Subject: Re: XST: suppressing incorrect optimizations in VHDL code
From: sidney@jigsaw.nl (Sidney Cadot)
Date: 1 Nov 2004 14:44:29 -0800
Links: << >>  << T >>  << A >>
Hi Chris,

> This isn't the perfect solution, but in verilog you could do something
> like use a define to set the board type and then a bunch of ifdef's to
> monkey with the port lists on the higher level modules.  You could
> even use an ifdef to instantiate the correct hardware specific
> low-level module.  If you don't want to contaminate the top-level
> files, you can include the portions that are different out of other
> files.  Basically, the idea is to use the pre-processor rather than
> the HDL's abstraction model to hide the hardware details.  I'm sure
> there's a similar mechanism in VHDL?

I'm afraid there is no mechanism analogous to textual preprocessing
like we have in C for VHDL. Nothing is keeping me from using a
preprocessor despite that, of course, but life would be just so much
easier if I can solve this at the VHDL level.

> Okay, it's not perfect, but it works for C programmers writing
> multi-platform code...   (What's really cool is if you run the whole
> thing with a makefile, you can pass the matching parameters not only
> to the hdl complier, but also to the compiler of the software that
> runs on your SoC)

Well I do tie everything together using a Makefile, I could easily
insert a preprocessing stage ... but this would make my stuff
considerably less easy to re-use for other people (I intend to publish
the project on the Web).

> PS - these spartan 3 kits are fun... with the addition of one chip and
> a bunch of resistors,

Yes, it is great stuff. I implemented a 6502 from scratch, which uses
the internal block memory of the Spartan-III .... I implemented a very
small machine language monitor program that works via the RS232, and I
must say it's really something to type to this little computer and get
a response that shows it works - also happy to be able to rehash those
old 8-bit skills I picked up 20 years ago :-) I can also run C
programs on this thing (using CC65, www.cc65.org) which is perfect.
It's been a very educational project so far, I've had several
occasions to think "so _that_'s why they do it like that!" :)

The digilent/xilinx kit is quite fantastic and really a bargain, at a
hundred bucks including the JTAG cable and power supply. I was
especially happy with the quality of hardware documentation they
provide, after horrific experience in this respect with my NuHorizons
kit. The Memec kit I have is also nice by the way, I also have their
50 MHz AD converter kit I use for experiments. Great stuff.

> I have one of the digilent ones pulling pictures
> off an IDE hard drive and generating a color composite NTSC signal to
> drive a little LCD tv...

Sounds great! I have been thinking about implementing an IDE interface
myself, do you have any more info, e.g. did you implement the IDE core
yourself?

Regards, Sidney

Article: 75294
Subject: Re: XST: suppressing incorrect optimizations in VHDL code
From: cs_posting@hotmail.com (Chris Stratton)
Date: 1 Nov 2004 15:18:13 -0800
Links: << >>  << T >>  << A >>
sidney@jigsaw.nl (Sidney Cadot) wrote in message news:<741e0fbf.0411010028.3ea1a7f3@posting.google.com>...
> newman5382@aol.com (newman) wrote in message news:
> 
> The "external view" (VHDL wise) of my "mmapped_io" component is
> basically that it acts like a RAM block, i.e., it has a data bus and
> an address bus, and R/W control bits. The fact that these happen to do
> some interesting things to hardware, should be of no concern to the
> VHDL modules that instantiate an "mmapped_io" component, that's the
> whole point of having memory mapped I/O.

As I think about this more, it looks to me like you're not really
architecting this in a way consistent with the philosophy of a
hardware description language.  Remember, this is sort of a software
equivelent to putting chips on boards and wiring them together.  So
unless one of your chips happens to be something "magic" like a
self-contained RF module, nothing gets into or out of a chip unless
you provide traces on the board to get it there.  Software engineers
get pure abstaction; hardware engineers just get 3ghz wire wrap guns.

From that point of view, I think you should think of your universal
bits of code as modules with no real-world I/O - for example, your
CPU, any on-chip memory, any other internal functional blocks.  Build
those into a library of general purpose functions that  you can use in
any of your projects.

Then for each specific FPGA board, create a top-level module with the
actual physical I/O ports.  This module should then instantiate a mix
of both your library of internal functional modules like CPU, and
hardware-specific handler modules for the specific board like your
memory mapped io function.  You will of course have to wire the
physical I/O ports through to those modules which need them, possibly
leaving any extrnal tri-states in the top level and passing something
back up to control them.

And of course if you do system simulation, you would in turn treat the
formerly top-level module as just one component in a testbench module
where it gets wired up to simulations of whatever your board talks
to...

Chris

Article: 75295
Subject: Re: XST: suppressing incorrect optimizations in VHDL code
From: Jim Lewis <Jim@SynthWorks.com>
Date: Mon, 01 Nov 2004 15:39:46 -0800
Links: << >>  << T >>  << A >>
Sidney,
> I failed to make that particularly clear (sorry). There are hardware
> differences, e.g.
> 
> * The number of seven-segment displays 0/1/4
> * The number of LEDs 4/8/8
> * The number of push-buttons: 2/3/4
> * The number of sliding switches: 0/4/8
> * The availability of AD/DA's on the development board
> * The interface to memory residing on the memory board

I have noticed that XST will remove pins at the top level of
a design that are not connected.  Hence, you could create a
design with the maximum number of pins you need at the top
level and then control whether the functionality is in the
design or not with generate.  Control the generate with
constants from a package.  Have one package for each board
configuration.  I am not sure what other synthesis tools do
with IOs so this may not work for all synthesis tools.

If you have excess IO, you can be even lazier.  Skip the
generate statements, implement all of the functionality
in the device, but allow unused functionality connect to
unused device pins.  This works well for outputs, but for
inputs, your design may have to be configured to ignore
the unused ones.  I use this to make some of our lab projects
work on different FPGA boards (Xilinx and Actel for now).

VHDL does not have any conditional statements outside of
generate, however, it would be simple enough to use CPP
as a preprocessor and script your compiles to always use
CPP - of course that would mean that everyone that uses
the files would have to do this also.  I have done some
experiments with this and it seems to work easy enough.

Cheers,
Jim
-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jim Lewis
Director of Training             mailto:Jim@SynthWorks.com
SynthWorks Design Inc.           http://www.SynthWorks.com
1-503-590-4787

Expert VHDL Training for Hardware Design and Verification
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Article: 75296
Subject: Re: XST: suppressing incorrect optimizations in VHDL code
From: hmurray@suespammers.org (Hal Murray)
Date: Mon, 01 Nov 2004 18:15:39 -0600
Links: << >>  << T >>  << A >>
>I'm not aware that standard VHDL has a preprocessor #ifdef mechanism. 
>There appear to be some third party offerings.  One may easily write
>one that does the job with sed (less than 10 lines).

Standard cpp works fine.  Everything gets much saner if you have a makefile.

-- 
The suespammers.org mail server is located in California.  So are all my
other mailboxes.  Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's.  I hate spam.


Article: 75297
Subject: "frying" FPGAs
From: ninjak@gmx.de (zerang shah)
Date: 1 Nov 2004 17:07:37 -0800
Links: << >>  << T >>  << A >>
I work at a university, and we just got a bunch of FPGA boards with
Spartan 2E's on them. It's like five weeks into the quarter, and
already 6 of 20 boards have died. I contacted tech support for the
board manufacturer, and it seems that the FPGAs have been "fried" on
all six of the bad boards, judging from the fact that both the onboard
voltage regulators and FPGAs both get really hot, and the power-on LED
fails to turn on. Looking at the boards very closely I see no signs of
physical mistreatment though.

The boards are being programmed using jtag cables + iMPACT with
bitfiles created with Foundation. At first I thought that maybe a
backward jtag cable would fry the FPGA, but it turns out that's not
the case. Really I have no idea what people could be doing to these
boards.

So here's my question: How do you fry an FPGA?? I guess running like
50 volts through it would do the job, but I don't think the cause of
these failures is a malicious user. Is there anyway to "accidentally"
synthesize a design that causes an FPGA to destroy itself???

Thanks for the help.

Article: 75298
Subject: Re: "frying" FPGAs
From: "Clyde Torres" <clyde_torres@hotmale.com>
Date: Tue, 02 Nov 2004 01:34:12 GMT
Links: << >>  << T >>  << A >>
"zerang shah" <ninjak@gmx.de> wrote in message
news:4d6c559c.0411011707.fba22e8@posting.google.com...
> So here's my question: How do you fry an FPGA?? I guess running like
> 50 volts through it would do the job, but I don't think the cause of
> these failures is a malicious user. Is there anyway to "accidentally"
> synthesize a design that causes an FPGA to destroy itself???
>
> Thanks for the help.

A bit of olive oil in a frying pan at high heat should do it.  They are
delicious, especially with Lattice!

Clyde Torres



Article: 75299
Subject: SysGnen 6.2: problem with DDS module
From: "Vadim Vaynerman" <vadimv@ieee.org>
Date: Mon, 1 Nov 2004 17:40:11 -0800
Links: << >>  << T >>  << A >>
Hi all, I created a system generator file to use the DDS core, and when I try to simulate, it gives the following error: Input width should be equal to accumulator width. I created the DDS module with phase increment as "register", and phase offset constant, and output width set to 27. The number entering the DDS Data port is also 27 bit. What's going on, and what does the error mean? Thanks, Vadim



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