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
2019JanFebMar2019

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 64900

Article: 64900
Subject: Re: mapper optimization
From: "John Retta" <jretta@rtc-inc.com>
Date: Fri, 16 Jan 2004 02:48:27 GMT
Links: << >>  << T >>  << A >>



"Brannon King" <bking@starbridgesystems.com> wrote in message
news:bu6s3c$4s2@dispatch.concentric.net...
> VHDL/Verilog compilers perform an optimization that I think should be done
> in the mapper. I think it is part of the "slice packing." Maybe someone
can
> explain why this is done in this fashion. What I want is to use my
3rd-party
> structural EDIF, and currently I'm having to perform this optimization
> manually. The optimization is this: Suppose I have three OR gates where
they
> are cascaded such that the output of the first goes into the second and
the
> output of the second goes into a third. The other inputs for the three
gates
> all come from the same top layer. It is possible to reorder those gates
such
> that the first two OR gates are in the same layer and the third has inputs
> coming from the first two gates. The Map/Par seems to have a much easier
> time with the Timespec when I start out with the binary (latter) ordered
> gates, yet I would think it would be an easy optimization for the mapper
to
> perform. Thoughts?
>
>

Put your specific problem on the backburner.  You raise a point which has
concerned me for awhile ....  That is that synthesis tools for FPGAs have
very minimal control over timing driven synthesis .... especially as
compared
to Synopsis Design Compiler for ASIC flows.

With an ASIC flow, the library primitives for the synthesis tool map 1-to-1
with
what the equivalent place-and-route tools operate.  There are estimates for
routing based on wire-load models.  The synthesis tool optimizes based on
what
it thinks delays will result from logic levels and routes.  There is then a
method
to take the resulting netlist after it has been routed and actual wire load
delays
extracted, and feed this back into the synthesis tool to "recalibrate."

The fact that there is a "mapping" process done AFTER the synthesis tool
produces a netlist is a big deviant in trying to converge on a similar
approach.
Parts of mapping are inherently a timing driven process.

I am not advocating "moving" the map process to the synthesis tool ...
rather I think the map process should be able to accept
directives/recommendations
(in a .ucf file format) from the synthesis tool on which paths are critical
ones to
reduce the number of clb levels where possible.

Anyway ... thanks for letting me vent.

-- 
Regards,
John Retta
Owner and Designer
Retta Technical Consulting Inc.

web :  www.rtc-inc.com



Article: 64901
Subject: Re: Spartan-IIE as an ASYNC RAM?
From: Ralph Malph <noone@yahoo.com>
Date: Thu, 15 Jan 2004 23:59:35 -0500
Links: << >>  << T >>  << A >>
Allan Herriman wrote:
> 
> On 15 Jan 2004 13:11:49 -0800, stevetshannon@yahoo.com (Steve T
> Shannon) wrote:
> 
> >Hello! I'm trying to interface a Spartan-IIE to one of analog device's
> >new ADSP-21262 DSPs. The problem is that my application requires
> >high-bandwidth communication with the DSP, and the DSP's parallel
> >interface expects an _asynchronous_ ram. That's right, it has
> >edge-triggering ALE, RE, and WE lines that are expected to interface
> >to standard static SRAM.
> >
> >I have been trying to come up with a solution to talking to the FPGA,
> >to no avail.   The ALE signal is asserted for only 10 ns, thus
> >oversampling the pins is going to be really difficult (and that's
> >ignoring all the potential metastability issues!) Has anyone ever made
> >an interface like this work? I know on the spartan-series, internal
> >flip-flops can only be gated by the internal clock nets, which can
> >only be sourced by one of the 4 clock pins.
> 
> ALE, RE, etc. are actually timed from a clock inside the DSP.  Can you
> access the processor core clock?  If so, you can pass that to the FPGA
> and have a fully synchronous interface, assuming your FPGA can handle
> the speed (200MHz).
> 
> Ummm, I can't see a CCLK out pin on the datasheet, but you do control
> CLKIN (which gets multiplied by a PLL inside the DSP to form CCLK).
> You might be able to do something with that (like using an external
> PLL to form your own CCLK).
> 
> It might be simpler to treat the signals as asynchronous.  Can
> Spartan-IIE do DDR?  If so, you only need a clock a little over 50MHz
> to sample the 10ns ALE strobe.

Trying to treat this as a synchronous interface would be very, very
difficult.  I have tried to do this on a chip where I *had access* to
the CPU clock.  But the relative timing was not spec'd.  So the best I
could do was to use the edges of strobes to clock data and then resync
to the clock.  

Although your ALE may be very short, you can use the trailing edge to
clock or gate the data into FFs.  Then you should be able to retime the
strobes (and assert the RDY/WAIT or otherwise add wait states) to allow
your FPGA a couple of internal clock cycles to read the data.  On
writes, of course, you can clock the data into a register and then into
the RAM at your leisure.  And of course, don't forget the metastable
issues, even if your clock is synchronous, it is not phase aligned.  :)

Article: 64902
Subject: Re: Spartan-IIE as an ASYNC RAM?
From: Allan Herriman <allan.herriman.hates.spam@ctam.com.au.invalid>
Date: Fri, 16 Jan 2004 17:27:18 +1100
Links: << >>  << T >>  << A >>
On Thu, 15 Jan 2004 23:59:35 -0500, Ralph Malph <noone@yahoo.com>
wrote:

>Allan Herriman wrote:
>> 
>> On 15 Jan 2004 13:11:49 -0800, stevetshannon@yahoo.com (Steve T
>> Shannon) wrote:
>> 
>> >Hello! I'm trying to interface a Spartan-IIE to one of analog device's
>> >new ADSP-21262 DSPs. The problem is that my application requires
>> >high-bandwidth communication with the DSP, and the DSP's parallel
>> >interface expects an _asynchronous_ ram. That's right, it has
>> >edge-triggering ALE, RE, and WE lines that are expected to interface
>> >to standard static SRAM.
>> >
>> >I have been trying to come up with a solution to talking to the FPGA,
>> >to no avail.   The ALE signal is asserted for only 10 ns, thus
>> >oversampling the pins is going to be really difficult (and that's
>> >ignoring all the potential metastability issues!) Has anyone ever made
>> >an interface like this work? I know on the spartan-series, internal
>> >flip-flops can only be gated by the internal clock nets, which can
>> >only be sourced by one of the 4 clock pins.
>> 
>> ALE, RE, etc. are actually timed from a clock inside the DSP.  Can you
>> access the processor core clock?  If so, you can pass that to the FPGA
>> and have a fully synchronous interface, assuming your FPGA can handle
>> the speed (200MHz).
>> 
>> Ummm, I can't see a CCLK out pin on the datasheet, but you do control
>> CLKIN (which gets multiplied by a PLL inside the DSP to form CCLK).
>> You might be able to do something with that (like using an external
>> PLL to form your own CCLK).
>> 
>> It might be simpler to treat the signals as asynchronous.  Can
>> Spartan-IIE do DDR?  If so, you only need a clock a little over 50MHz
>> to sample the 10ns ALE strobe.
>
>Trying to treat this as a synchronous interface would be very, very
>difficult.  I have tried to do this on a chip where I *had access* to
>the CPU clock.  But the relative timing was not spec'd.  So the best I
>could do was to use the edges of strobes to clock data and then resync
>to the clock.  

I've had a lot of success treating nominally asynchronous interfaces
as synchronous.  But then, these were all low speed (<= 50MHz) with
timing specified in terms of the clock, except for one which I
measured (and took the attendant risk).

>Although your ALE may be very short, you can use the trailing edge to
>clock or gate the data into FFs.  Then you should be able to retime the
>strobes (and assert the RDY/WAIT or otherwise add wait states) to allow
>your FPGA a couple of internal clock cycles to read the data.

I've done this too, and I agree that it's a better solution for the
OP.

Also, 
- ALE doesn't need to be on a BUFG even though it is used as a clock
(since there is no skew issue).

- Even if ALE is reallllly narrow, it's still possible to get it into
your clock domain by stretching it.  Connecting ALE to the clock of a
FF.  Tie D high, so that Q goes high on the rising edge of ALE.
Asynchronously reset the FF once Q is sampled in the other clock
domain.  It's ugly but it works.

E.g.

           Your clock --o---------------------+
                        |                     |
                        |                     |
                        |                     |
                        |                     |
                        |                     |
               .---.    |    .---.      __    |   .---.
     '1'-------|D Q|---------|D Q|-----|  | +-----|D Q|----+--
  ALE----------|>C |    +----|>C |     |& |-+ +---|>C |    |
           +---|R  |         |   |   +-|__|       |   |o-+ |
           |   '---'         '---'   |            '---'  | |
           |                         +-------------------+ |
           |                                               |
           +-----------------------------------------------+

created by Andy´s ASCII-Circuit v1.24.140803 Beta www.tech-chat.de 

The and gate is needed to ensure that the output pulse is only one
clock wide.  (Note that this could be turned into a synchronous reset
on the third flip flop, which removes the and gate delay from the
metastability resolution time of the second flip flop.)

For some reason, the Xilinx tools won't trace delays on async resets
by default.  There's some magic incantation in the pcf that makes it
work though (I can't remember it right now).


I don't mean to claim that this is the only way you can do it -
there are many other equivalent circuits that would work just as well.

Regards,
Allan.

Article: 64903
Subject: Can nios_gnupro support file system?
From: hauyuanwen1980@yahoo.com (Jasmine Hau)
Date: 15 Jan 2004 23:11:45 -0800
Links: << >>  << T >>  << A >>
Hi, can any body explain to me does the nios_gnupro support any
functions that manage files or other input/output streams???
     I am currently using the Altera Nios Developed Board during my
research which is Apex Device (EP20K200EFC484-2x). But i failed to
execute a very simple program which just consist of fopen and fclose
as follows:

#include <stdio.h>

main()
{
	FILE *a;
	a = fopen("simple.dat", "w");
	fclose(a);
	return 0;
}

         i have compile this program using Visual Studio, and the
output is correct. But once i execute the nios-build in the Nios SDK
shell, it keep giving me the following errors:

in function `_open_r':
openr.o(.text+0x14): undefined reference to `_open'
openr.o(.text+0x16): undefined reference to `_open'
openr.o(.text+0x18): undefined reference to `_open'
openr.o(.text+0x1a): undefined reference to `_open'

    Can anybody explain to me where is my problem? Thanks a lot and
wish you all have a nice day.

Article: 64904
Subject: Re: Gray encoding for FSM
From: usenet_10@stanka-web.de (Thomas Stanka)
Date: 15 Jan 2004 23:48:51 -0800
Links: << >>  << T >>  << A >>
guillerodriguez@terra.es (guille) wrote:
> I would like to use Gray encoding for this FSM but I'm not sure how it
> should be done. Using Gray encoding is straightforward for things like
> counters and such where there's only one possible next state for each
> current state. However, is it possible in a case like this?

Draw a picture of your FSM. Now try to color each state with two
rules:
1. no adjacent state shall have the same color (A and B shall be
adjacent iff theres a edge from state A to state B)
2. use no unused color when possible

If you come along with two colors, your statemachine fits perfect into
gray code. Else you could start inserting states unless you need only
two colors.
There are two possibilities for inserting states:
1. null states without funktion (these will anyway delay your fsm)
2. Split a state in two states, that will do the work.

Another possibility is to use gray as good as possible, but to break
the rules for some seldom used transitions.

bye Thomas

Article: 64905
Subject: Re: Please help with Xilinx ISE Schematic question
From: antti@case2000.com (Antti Lukats)
Date: 15 Jan 2004 23:59:22 -0800
Links: << >>  << T >>  << A >>
google.4.oracle@xoxy.net (Bob) wrote in message news:<aacb3d3a.0401150932.5aaafb26@posting.google.com>...
> I need help in creating constants to be used with schematic capture.
> 
> ERROR:Xst:1539 - C:/Projects/DemoTop.vhf line 122: Formal port in
> component <const8_80> must be an identifier.

you found a funny bug, the same problems appears even if you write the
constant in VHDL file and instantiate that in ECS toplevel.
the problem doesnt happen if you use verilog as simulation language for
your project. So not sure if the problem is in ECS or XST. but its
a pretty serious problem-bug in the tools.

http://xilinx.openchip.org/forum/viewtopic.php?t=8

Antti

Article: 64906
Subject: Error in Assembly stage.
From: "Kelvin @ SG" <kelvin8157@hotmail.com>
Date: Fri, 16 Jan 2004 16:50:02 +0800
Links: << >>  << T >>  << A >>
Hi, there:

I could get all my three modules placed and routed, now how do I fix this
error? There is one thing strange, the
"Rejected due to connectivity:           1 out of  3361", what is causing
the connectivity to be changed?


Best Regards,
Kelvin




ERROR:Place - The following 1 components are required to be placed in a
specific
   relative placement form. The required relative coordinates in the RPM
grid
   (that can be seen in the FPGA-editor) are shown in brackets next to the
   component names. Due to placement constraints it is impossible to place
the
   components in the required form.     SLICE
   partial_digital_if/u_dataslicer/int_rst_2 (0, 0)
            Constrained by statement: COMPGRP "PARTIAL.SLICE" LOCATE = SITE
   "SLICE_X20Y191:SLICE_X175Y0" LEVEL 4 ;



Finished Guide File Processing.

Xilinx Place and Route Guide Results File
=========================================

Guide Summary Report:

Design Totals:
  Components:
    Name matched:                          3361 out of  3540   94%
      Rejected due to connectivity:           1 out of  3361
    Total guided:                          3360 out of  3361   99%

  Signals:
   Rejected Implicit/Internal:             3686 out of 10802
    Name matched:                          7111 out of  7116   99%
    Total guided:                          7101 out of  7111   99%
    Total connections guided:              2558



Guide file: "../../pims/partial_digital_if/partial_digital_if.ncd"
Guide
mode: "exact"

  Components:
    Name matched:                          3346 out of  3540   94%
      Rejected due to connectivity:           1 out of  3346
    Total guided:                          3345 out of  3346   99%

  Signals:
    Name matched:                          7099 out of 10802   65%
    Total guided:                          7068 out of  7099   99%
    Total connections guided:              2457


Guide file: "../../pims/switch_qpsk/switch_qpsk.ncd"        Guide mode:
"exact"

  Components:
    Name matched:                            15 out of  3540    0%
    Total guided:                            15 out of    15  100%

  Signals:
    Name matched:                           183 out of 10802    1%
    Total guided:                           481 out of   183  262%
    Total connections guided:               101


For a detailed guide report refer to the "digital_if.grf" file.

Device utilization summary:

   Number of External IOBs           101 out of 684    14%
      Number of LOCed External IOBs  101 out of 101   100%

   Number of SLICEs                 3061 out of 33792   9%

   Number of BUFGMUXs                 11 out of 16     68%
   Number of TBUFs                    64 out of 16896   1%
   Number of VCCs                    303 out of 9410    3%



Overall effort level (-ol):   Standard (default)
Placer effort level (-pl):    Standard (default)
Placer cost table entry (-t): 1
Router effort level (-rl):    Standard (default)

Starting initial Timing Analysis.  REAL time: 12 mins 29 secs
Finished initial Timing Analysis.  REAL time: 13 mins 3 secs

WARNING:Par:276 - The signal bus1_bm_2/TNET(1) has no load
WARNING:Par:276 - The signal bus1_bm_2/TNET(0) has no load
WARNING:Par:276 - The signal bus1_bm_3/TNET(0) has no load
WARNING:Par:276 - The signal bm_r0/TNET(1) has no load
WARNING:Par:276 - The signal bm_r0/TNET(0) has no load

Phase 1.1

ERROR:Place - The following 1 components are required to be placed in a
specific
   relative placement form. The required relative coordinates in the RPM
grid
   (that can be seen in the FPGA-editor) are shown in brackets next to the
   component names. Due to placement constraints it is impossible to place
the
   components in the required form.     SLICE
   partial_digital_if/u_dataslicer/int_rst_2 (0, 0)
            Constrained by statement: COMPGRP "PARTIAL.SLICE" LOCATE = SITE
   "SLICE_X20Y191:SLICE_X175Y0" LEVEL 4 ;


ERROR:Place - The following 1 components are required to be placed in a
specific
   relative placement form. The required relative coordinates in the RPM
grid
   (that can be seen in the FPGA-editor) are shown in brackets next to the
   component names. Due to placement constraints it is impossible to place
the
   components in the required form.     SLICE
   partial_digital_if/u_dataslicer/_n0105 (0, 0)
            Constrained by statement: COMPGRP "PARTIAL.SLICE" LOCATE = SITE
   "SLICE_X20Y191:SLICE_X175Y0" LEVEL 4 ;

Phase 1.1 (Checksum:99478b) REAL time: 14 mins 5 secs



Article: 64907
Subject: Re: Can nios_gnupro support file system?
From: "David Brown" <david@no.westcontrol.spam.com>
Date: Fri, 16 Jan 2004 10:16:14 +0100
Links: << >>  << T >>  << A >>

"Jasmine Hau" <hauyuanwen1980@yahoo.com> wrote in message
news:fc6016ce.0401152311.25e56b30@posting.google.com...
> Hi, can any body explain to me does the nios_gnupro support any
> functions that manage files or other input/output streams???
>      I am currently using the Altera Nios Developed Board during my
> research which is Apex Device (EP20K200EFC484-2x). But i failed to
> execute a very simple program which just consist of fopen and fclose
> as follows:
>

Where are you expecting this file to be?  Which operating system is running
on the Nios, and providing access to a file system?  File access is a
service that needs to be provided by an operating system, or emulated in
some way - without that, the program has no more chance of openning a file
than it has of drawing a window on the screen.

Functions such as fopen and fclose are required parts of the standard c
library, but since there is no sensible way to implement them on most
embedded systems, they are often stubbed out (i.e., they do nothing, as is
the case for fclose), or are missing entirely from the library files (as is
the case for _open).


> #include <stdio.h>
>
> main()
> {
> FILE *a;
> a = fopen("simple.dat", "w");
> fclose(a);
> return 0;
> }
>
>          i have compile this program using Visual Studio, and the
> output is correct. But once i execute the nios-build in the Nios SDK
> shell, it keep giving me the following errors:
>
> in function `_open_r':
> openr.o(.text+0x14): undefined reference to `_open'
> openr.o(.text+0x16): undefined reference to `_open'
> openr.o(.text+0x18): undefined reference to `_open'
> openr.o(.text+0x1a): undefined reference to `_open'
>
>     Can anybody explain to me where is my problem? Thanks a lot and
> wish you all have a nice day.



Article: 64908
Subject: Hardware to test (FPGA-based) prototype?
From: ad.rast.7@nwnotlink.NOSPAM.com (Alex Rast)
Date: Fri, 16 Jan 2004 09:18:08 -0000
Links: << >>  << T >>  << A >>
I have an FPGA-based prototype for a PCI product in development. Since the 
intended product application will involve very high speed data transfers, 
we have designed all the I/O and internal busses in the FPGA to work on 
synchronous protocols. Now, however, I'm running into a real stumbling 
block.

The problem is in testing the board. What I need to do is to be able to 
generate some test data on a PC, and send it to the FPGA, simulating data 
flow through the system under test. Similarly, the PC needs to be able to 
receive test data from the FPGA. Because of the design of the board, I need 
to use a synchronous, hardware-based protocol and interface to transfer the 
data. 

However, there doesn't seem to be much hardware out there that will enable 
me to do this, at least not at reasonable cost. All I need to do is dump 
bitstreams in either direction, synchronously, but I have met with little 
success. We made an abortive effort to use LabView together with their DIO-
32HS, which seemed promising and (supposedly) offered a high-speed 
synchronous protocol, but when we tried to use it, the protocol didn't 
work, we couldn't make it work, and apparently nobody at National 
Instruments had tried using that protocol and gotten it to work. Indeed, I 
saw others posting on the Labview NG, running into the same problems! So 
that's not an option.

So, what would be the easiest way to create a test interface that lets us 
transfer data using a synchronous protocol at reasonable speeds (at least 
10 MHz) between a PC and a device under test? Our prototype board has no 
shortage of high-speed, MICTOR connectors that we can use to interface to. 
We're willing to spend some dollars to do it, but if it starts escalating 
into the thousands of dollars just to get a simple test interface, I think 
that such a price is disproportionate relative to what we need to achieve. 
So I think a fair budget limit is around $2000. Any suggestions? 

-- 
Alex Rast
ad.rast.7@nwnotlink.NOSPAM.com
(remove d., .7, not, and .NOSPAM to reply)

Article: 64909
Subject: Simulating USB2.0Transceiver
From: ALuPin@web.de (ALuPin)
Date: 16 Jan 2004 01:19:26 -0800
Links: << >>  << T >>  << A >>
Dear Sir or Madam,

does somebody know if there is an UTMI compliant
VHDL model (not synthezisable one, only for functional simulation)
of an USB2.0 Transceiver device available?

Thanks in advance.

Kind regards

Andres V.

Article: 64910
Subject: Re: Which version of ISE Webpack has FPGA Editor on it?
From: hmurray@suespammers.org (Hal Murray)
Date: Fri, 16 Jan 2004 09:37:44 -0000
Links: << >>  << T >>  << A >>
>I am using ise WebPack for learning purpose. I am learning modular design
>while
>I can't live without the FPGA Editor...even if a viewer is okie...
>
>I used ISE w6.1.03, but there is no editor on it.

What are you trying to look at?

You may be able to get some of the info you want from the floorplanner.
It doesn't show you a detailed wiring, but it does show you the main
blocks.

-- 
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: 64911
Subject: Re: Can nios_gnupro support file system?
From: Goran Bilski <goran@xilinx.com>
Date: Fri, 16 Jan 2004 10:42:24 +0100
Links: << >>  << T >>  << A >>


David Brown wrote:

>"Jasmine Hau" <hauyuanwen1980@yahoo.com> wrote in message
>news:fc6016ce.0401152311.25e56b30@posting.google.com...
>  
>
>>Hi, can any body explain to me does the nios_gnupro support any
>>functions that manage files or other input/output streams???
>>     I am currently using the Altera Nios Developed Board during my
>>research which is Apex Device (EP20K200EFC484-2x). But i failed to
>>execute a very simple program which just consist of fopen and fclose
>>as follows:
>>
>>    
>>
>
>Where are you expecting this file to be?  Which operating system is running
>on the Nios, and providing access to a file system?  File access is a
>service that needs to be provided by an operating system, or emulated in
>some way - without that, the program has no more chance of openning a file
>than it has of drawing a window on the screen.
>
>Functions such as fopen and fclose are required parts of the standard c
>library, but since there is no sensible way to implement them on most
>embedded systems, they are often stubbed out (i.e., they do nothing, as is
>the case for fclose), or are missing entirely from the library files (as is
>the case for _open).
>
>  
>
In many embedded system, a memory file system is used.
MicroBlaze and EDK is shipped with a memory file system.

Göran Bilski

>  
>
>>#include <stdio.h>
>>
>>main()
>>{
>>FILE *a;
>>a = fopen("simple.dat", "w");
>>fclose(a);
>>return 0;
>>}
>>
>>         i have compile this program using Visual Studio, and the
>>output is correct. But once i execute the nios-build in the Nios SDK
>>shell, it keep giving me the following errors:
>>
>>in function `_open_r':
>>openr.o(.text+0x14): undefined reference to `_open'
>>openr.o(.text+0x16): undefined reference to `_open'
>>openr.o(.text+0x18): undefined reference to `_open'
>>openr.o(.text+0x1a): undefined reference to `_open'
>>
>>    Can anybody explain to me where is my problem? Thanks a lot and
>>wish you all have a nice day.
>>    
>>
>
>
>  
>


Article: 64912
Subject: Re: Spartan-IIE as an ASYNC RAM?
From: hmurray@suespammers.org (Hal Murray)
Date: Fri, 16 Jan 2004 09:51:18 -0000
Links: << >>  << T >>  << A >>
>Hello! I'm trying to interface a Spartan-IIE to one of analog device's
>new ADSP-21262 DSPs. The problem is that my application requires
>high-bandwidth communication with the DSP, and the DSP's parallel
>interface expects an _asynchronous_ ram. That's right, it has
>edge-triggering ALE, RE, and WE lines that are expected to interface
>to standard static SRAM.

Have you tried asking Analog Devices?  I expect you aren't the only
one interested in this problem.  They might have a good solution.

-- 
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: 64913
Subject: Re: Hardware to test (FPGA-based) prototype?
From: hmurray@suespammers.org (Hal Murray)
Date: Fri, 16 Jan 2004 09:58:57 -0000
Links: << >>  << T >>  << A >>
>So, what would be the easiest way to create a test interface that lets us 
>transfer data using a synchronous protocol at reasonable speeds (at least 
>10 MHz) between a PC and a device under test? Our prototype board has no 
>shortage of high-speed, MICTOR connectors that we can use to interface to. 
>We're willing to spend some dollars to do it, but if it starts escalating 
>into the thousands of dollars just to get a simple test interface, I think 
>that such a price is disproportionate relative to what we need to achieve. 
>So I think a fair budget limit is around $2000. Any suggestions? 

Can you cross connect two of your boards?  Possibly running
totally different test code in the helper board.

If your board isn't quite right, you might browse through
the prototype/demo board list and see if you can find one
that looks good.  I'm thinking of PCI, FPGA, Memory, and some
connector you can get to.  Load the memory from PCI, turn the
FPGA loose to read the data out of memory and feed it to your
system.  That gives you a burst for as long as the memory
has room for your pattern.

-- 
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: 64914
Subject: Re: Gray encoding for FSM
From: guillerodriguez@terra.es (guille)
Date: 16 Jan 2004 02:30:00 -0800
Links: << >>  << T >>  << A >>
jim granville <no.spam@designtools.co.nz> wrote in message news:<ijtNb.17319$ws.2066401@news02.tsnz.net>...
> guille wrote:
> 
> > Hello all,
> > 
> > I have a FSM with 6 states: IDLE, and S0-S5. Transitions are
> > synchronized with the system clock, but next state might be determined
> > by signals which are asynchronous to that clock.
> 
> Sounds like thin ice.
> Can you not sync these to the opposite clock edge ?

Actually the signals are being double clocked (to the same clock
edge) to synchronize them and avoid metastables. So the actual
implementation would look more or less like this:

clk
-----------+-----------+
           |           |
        +-----+     +-----+
sig     |     |     |     |   sig1
--------|D   Q|-----|D   Q|--------
        +-----+     +-----+

And sig1 is the signal that the FSM looks at to determine which
state to go next. Is it a problem if the signal is sycnrhonized
to the same clock edge?

> > 
> > The FSM is normally at state IDLE. If certain signals are active, it
> > will go from IDLE to S0, then go through some intermediate states, and
> > finally back to IDLE. Here's a list of possible transitions:
> > 
> > Current state    Possible next states
> > -------------    --------------------
> > IDLE             IDLE, S0
> > S0               S1
> > S1               S2, IDLE
> > S2               S3, IDLE
> > S3               S4, IDLE
> > S4               S4, S5, IDLE
> > S5               IDLE
> > 
> > I would like to use Gray encoding for this FSM but I'm not sure how it
> > should be done. Using Gray encoding is straightforward for things like
> > counters and such where there's only one possible next state for each
> > current state. However, is it possible in a case like this?
> 
> A formal Gray code may be impossible, but you may be able to find a
> 'single bit change' pattern using pencil and paper.
> It can also help, if you allow IDLEa, IDLEb,(etc) for example - these
> are extra states added purely to ensure single-bit state jumps
> can be met.

I assume that this is still needed even after adding the double
clocking described above, right?

Thanks!

Article: 64915
Subject: Re: Gray encoding for FSM
From: guillerodriguez@terra.es (guille)
Date: 16 Jan 2004 02:30:29 -0800
Links: << >>  << T >>  << A >>
That helps a lot, thanks!

guille

usenet_10@stanka-web.de (Thomas Stanka) wrote in message news:<ef424d2c.0401152348.34ad50e5@posting.google.com>...
> guillerodriguez@terra.es (guille) wrote:
> > I would like to use Gray encoding for this FSM but I'm not sure how it
> > should be done. Using Gray encoding is straightforward for things like
> > counters and such where there's only one possible next state for each
> > current state. However, is it possible in a case like this?
> 
> Draw a picture of your FSM. Now try to color each state with two
> rules:
> 1. no adjacent state shall have the same color (A and B shall be
> adjacent iff theres a edge from state A to state B)
> 2. use no unused color when possible
> 
> If you come along with two colors, your statemachine fits perfect into
> gray code. Else you could start inserting states unless you need only
> two colors.
> There are two possibilities for inserting states:
> 1. null states without funktion (these will anyway delay your fsm)
> 2. Split a state in two states, that will do the work.
> 
> Another possibility is to use gray as good as possible, but to break
> the rules for some seldom used transitions.
> 
> bye Thomas

Article: 64916
Subject: Power-up input value detection
From: Nicolas Matringe <matringe.nicolas@numeri-cable.fr>
Date: Fri, 16 Jan 2004 11:34:46 +0100
Links: << >>  << T >>  << A >>
Hi
I am working on a design involving the cloning of an obsolete chip in an 
FPGA (Altera EP10K family).
The behavior of the chip depends on some input values "at power-up" (no 
mention of any reset there). My problem is to reliably detect power-up.

I could still manage something with the reset condition but that's not 
exactly what the datasheet says ("If <input signal> is strapped Low at 
power-up...")

-- 
  ____  _  __  ___
|  _  \_)/ _|/ _ \   Adresse de retour invalide: retirez le -
| | | | | (_| |_| |  Invalid return address: remove the -
|_| |_|_|\__|\___/


Article: 64917
Subject: Re: Can nios_gnupro support file system?
From: "David Brown" <david@no.westcontrol.spam.com>
Date: Fri, 16 Jan 2004 12:01:04 +0100
Links: << >>  << T >>  << A >>

"Goran Bilski" <goran@xilinx.com> wrote in message
news:bu8bn1$kao1@cliff.xsj.xilinx.com...
>
>
> David Brown wrote:
>
> >"Jasmine Hau" <hauyuanwen1980@yahoo.com> wrote in message
> >news:fc6016ce.0401152311.25e56b30@posting.google.com...
> >
> >
> >>Hi, can any body explain to me does the nios_gnupro support any
> >>functions that manage files or other input/output streams???
> >>     I am currently using the Altera Nios Developed Board during my
> >>research which is Apex Device (EP20K200EFC484-2x). But i failed to
> >>execute a very simple program which just consist of fopen and fclose
> >>as follows:
> >>
> >>
> >>
> >
> >Where are you expecting this file to be?  Which operating system is
running
> >on the Nios, and providing access to a file system?  File access is a
> >service that needs to be provided by an operating system, or emulated in
> >some way - without that, the program has no more chance of openning a
file
> >than it has of drawing a window on the screen.
> >
> >Functions such as fopen and fclose are required parts of the standard c
> >library, but since there is no sensible way to implement them on most
> >embedded systems, they are often stubbed out (i.e., they do nothing, as
is
> >the case for fclose), or are missing entirely from the library files (as
is
> >the case for _open).
> >
> >
> >
> In many embedded system, a memory file system is used.
> MicroBlaze and EDK is shipped with a memory file system.
>
> Göran Bilski
>

Yes, that's the most common way to implement working file functions on
embedded systems without a reasonably complete OS with a real file system
somewhere.  The file functions are simply implemented in library functions.
I don't know if there are such library functions in the Nios kit - I haven't
looked at everything on it yet.




> >
> >
> >>#include <stdio.h>
> >>
> >>main()
> >>{
> >>FILE *a;
> >>a = fopen("simple.dat", "w");
> >>fclose(a);
> >>return 0;
> >>}
> >>
> >>         i have compile this program using Visual Studio, and the
> >>output is correct. But once i execute the nios-build in the Nios SDK
> >>shell, it keep giving me the following errors:
> >>
> >>in function `_open_r':
> >>openr.o(.text+0x14): undefined reference to `_open'
> >>openr.o(.text+0x16): undefined reference to `_open'
> >>openr.o(.text+0x18): undefined reference to `_open'
> >>openr.o(.text+0x1a): undefined reference to `_open'
> >>
> >>    Can anybody explain to me where is my problem? Thanks a lot and
> >>wish you all have a nice day.
> >>
> >>
> >
> >
> >
> >
>



Article: 64918
Subject: Re: What does nios-run do?
From: Petter Gustad <newsmailcomp5@gustad.com>
Date: 16 Jan 2004 12:37:55 +0100
Links: << >>  << T >>  << A >>
cruiser144@hotmail.com (cruzin) writes:

> I can download a program to memory using "nios-run my_prog.srec" and
> it works fine.
> 
> However, when I write the program into the same memory manually (ie.
> memory fill command), nios will not wrong the program properly.

Maybe a stupid question: How do you run your manually entered program?
Are you using the go (G) command in germs? Can you use go to *re-run*
the downloaded srec file?

Petter
-- 
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

Article: 64919
Subject: Re: Hardware to test (FPGA-based) prototype?
From: Hans-Bernhard Broeker <broeker@physik.rwth-aachen.de>
Date: 16 Jan 2004 12:55:25 GMT
Links: << >>  << T >>  << A >>
In comp.arch.embedded Alex Rast <ad.rast.7@nwnotlink.nospam.com> wrote:

[...]

> Because of the design of the board, I need 
> to use a synchronous, hardware-based protocol and interface to transfer the 
> data. 

"A ... protocol" meaning exactly _what_?  I'm quite sure you don't
just need some random protocol.  You need a piece of hardware and
software that generates and read _exactly_ that protocol your device
under test uses.  Regarding which you completely forgot to tell your
readers what that protocol actually is.  From what you wrote, it might
well be some completely non-standard homegrown thing.  If so, you're
obviously on your own --- oughtta have thought of that aspect, before
you designed that protocol into your hardware.  Now you're stuck with
what you have.

Odds are you'll have to build your test harness yourself, in this
case.  Software alone won't do (not at 10Mhz on an ordinary PC...),
and a test pulse generator inside the budget limit you gave probably
won't be flexible enough for your needs.

> do is dump bitstreams in either direction, synchronously, 

... synchronous to what?

What you would need is essentially the opposite thing to a logic
analyzer or storage scope: a fully programmable logic signal
generator.  Where a LA or storage scope has programmable triggers and
logs its results to an internal buffer for later retrieval, you need a
device that has programmable output triggering to output signals
stored in an internal buffer.

To build one yourself, you'll probably need an FPGA board about equally
complicated as the one you're testing.

-- 
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.

Article: 64920
Subject: Re: Hardware to test (FPGA-based) prototype?
From: "Nial Stewart" <nial@nialstewartdevelopments.co.uk>
Date: Fri, 16 Jan 2004 13:03:55 -0000
Links: << >>  << T >>  << A >>
> So, what would be the easiest way to create a test interface that lets us
> transfer data using a synchronous protocol at reasonable speeds (at least
> 10 MHz) between a PC and a device under test? Our prototype board has no
> shortage of high-speed, MICTOR connectors that we can use to interface to.
> We're willing to spend some dollars to do it, but if it starts escalating
> into the thousands of dollars just to get a simple test interface, I think
> that such a price is disproportionate relative to what we need to achieve.
> So I think a fair budget limit is around $2000. Any suggestions?

Alex,

It sounds like you'd be best using another of your boards as a test
source as Hal suggested.

If you want to use completely independant hardware to verify the
operation of your board you could try using one of my
Cyclone based PCI evaluation boards. See the Hardware
page of my web site below.


Nial Stewart

------------------------------------------------
Nial Stewart Developments Ltd
FPGA and High Speed Digital Design
Cyclone based 'Easy PCI' eval board
www.nialstewartdevelopments.co.uk




Article: 64921
Subject: Re: yo, Mr. FPGA Engineer
From: erojr <janos.nojunk.nospam.ero@cern.nojunk.nospam.ch>
Date: Fri, 16 Jan 2004 14:20:35 +0100
Links: << >>  << T >>  << A >>
Paul Leventis (at home) wrote:

> But Altera tech support (hot line, mysupport.altera.com) are
> the preferred ways for you to get support.  Not only do you get escalation,
> tracking, etc., but there's also a better chance your question will be
> answered, and answered correctly.  Tech support has access to a database of
> problems and resolutions, and chances are you're not the first to ask your
> particular question.

Sorry but I find the ¨Find Answers¨ on the Altera website too general. 
Rarely an answer for problems that arise in the life of a design 
engineer. The other side, with ¨Altera.com Account¨, where you need a 
password to log in, also a bit circuitous. And it requires JavaScript 
activated.

I find that Xilinx does it better when giving answers in the Newsgroups too.

Janos Ero
(Altera user since 1993)


Article: 64922
Subject: Re: Spartan-IIE as an ASYNC RAM?
From: stevetshannon@yahoo.com (Steve T Shannon)
Date: 16 Jan 2004 05:21:37 -0800
Links: << >>  << T >>  << A >>
Allan Herriman <allan.herriman.hates.spam@ctam.com.au.invalid> wrote in message news:<imue00t4tnbf07i6ncjajivt4o654ck1s3@4ax.com>...
> On Thu, 15 Jan 2004 23:59:35 -0500, Ralph Malph <noone@yahoo.com>
> wrote:
> 
> >Allan Herriman wrote:
> >> 
> >> On 15 Jan 2004 13:11:49 -0800, stevetshannon@yahoo.com (Steve T
> >> Shannon) wrote:
> >> 
> >> >Hello! I'm trying to interface a Spartan-IIE to one of analog device's
> >> >new ADSP-21262 DSPs. The problem is that my application requires
> >> >high-bandwidth communication with the DSP, and the DSP's parallel
> >> >interface expects an _asynchronous_ ram. That's right, it has
> >> >edge-triggering ALE, RE, and WE lines that are expected to interface
> >> >to standard static SRAM.
> >> >
> >> >I have been trying to come up with a solution to talking to the FPGA,
> >> >to no avail.   The ALE signal is asserted for only 10 ns, thus
> >> >oversampling the pins is going to be really difficult (and that's
> >> >ignoring all the potential metastability issues!) Has anyone ever made
> >> >an interface like this work? I know on the spartan-series, internal
> >> >flip-flops can only be gated by the internal clock nets, which can
> >> >only be sourced by one of the 4 clock pins.
> >> 
> >> ALE, RE, etc. are actually timed from a clock inside the DSP.  Can you
> >> access the processor core clock?  If so, you can pass that to the FPGA
> >> and have a fully synchronous interface, assuming your FPGA can handle
> >> the speed (200MHz).
> >> 
> >> Ummm, I can't see a CCLK out pin on the datasheet, but you do control
> >> CLKIN (which gets multiplied by a PLL inside the DSP to form CCLK).
> >> You might be able to do something with that (like using an external
> >> PLL to form your own CCLK).
> >> 
> >> It might be simpler to treat the signals as asynchronous.  Can
> >> Spartan-IIE do DDR?  If so, you only need a clock a little over 50MHz
> >> to sample the 10ns ALE strobe.
> >
> >Trying to treat this as a synchronous interface would be very, very
> >difficult.  I have tried to do this on a chip where I *had access* to
> >the CPU clock.  But the relative timing was not spec'd.  So the best I
> >could do was to use the edges of strobes to clock data and then resync
> >to the clock.  
> 
> I've had a lot of success treating nominally asynchronous interfaces
> as synchronous.  But then, these were all low speed (<= 50MHz) with
> timing specified in terms of the clock, except for one which I
> measured (and took the attendant risk).
> 
> >Although your ALE may be very short, you can use the trailing edge to
> >clock or gate the data into FFs.  Then you should be able to retime the
> >strobes (and assert the RDY/WAIT or otherwise add wait states) to allow
> >your FPGA a couple of internal clock cycles to read the data.
> 
> I've done this too, and I agree that it's a better solution for the
> OP.
> 
> Also, 
> - ALE doesn't need to be on a BUFG even though it is used as a clock
> (since there is no skew issue).
> 
> - Even if ALE is reallllly narrow, it's still possible to get it into
> your clock domain by stretching it.  Connecting ALE to the clock of a
> FF.  Tie D high, so that Q goes high on the rising edge of ALE.
> Asynchronously reset the FF once Q is sampled in the other clock
> domain.  It's ugly but it works.
> 
> E.g.
> 
>            Your clock --o---------------------+
>                         |                     |
>                         |                     |
>                         |                     |
>                         |                     |
>                         |                     |
>                .---.    |    .---.      __    |   .---.
>      '1'-------|D Q|---------|D Q|-----|  | +-----|D Q|----+--
>   ALE----------|>C |    +----|>C |     |& |-+ +---|>C |    |
>            +---|R  |         |   |   +-|__|       |   |o-+ |
>            |   '---'         '---'   |            '---'  | |
>            |                         +-------------------+ |
>            |                                               |
>            +-----------------------------------------------+
> 
> created by Andy´s ASCII-Circuit v1.24.140803 Beta www.tech-chat.de 
> 
> The and gate is needed to ensure that the output pulse is only one
> clock wide.  (Note that this could be turned into a synchronous reset
> on the third flip flop, which removes the and gate delay from the
> metastability resolution time of the second flip flop.)
> 
> For some reason, the Xilinx tools won't trace delays on async resets
> by default.  There's some magic incantation in the pcf that makes it
> work though (I can't remember it right now).
> 
> 
> I don't mean to claim that this is the only way you can do it -
> there are many other equivalent circuits that would work just as well.
> 
> Regards,
> Allan.

Thanks for the advice! My concern isn't the BUFGs so much as it is the
IBUFGs, which seem to be the only way to get a clock-able signal into
the chip. I'm already using them all :( I think I'm going to settle on
decoding the ALE signal externally with a latch, and just having the
entire system be sampled. I've had to move up to the PQ208 Spartan-IIE
(from the TQ144) which is a bit more expensive, but still should work.
Now I just have to tackle the metastability issues. (oh no!)

Thanks again for the help,

Steve

Article: 64923
Subject: Spartan-3 VCCINT
From: news@sulimma.de (Kolja Sulimma)
Date: 16 Jan 2004 05:55:18 -0800
Links: << >>  << T >>  << A >>
This again is a question for Austin:

The recommended operating conditions for spartan-3 are VCCINT < 1.26V.
What will happen if I power it with 1.28V?

Antything more serious than a live expectancy reduced from 20 years to
15 years?

You know, there a only a few small 1.2V regulators on the market but
there a plenty of 1.25V versions around. But those have a tolerance of
a few percent...

Kolja Sulimma

Article: 64924
Subject: Re: Altera Cyclone data is incomplete or messy
From: vbetz@altera.com (Vaughn Betz)
Date: 16 Jan 2004 06:43:53 -0800
Links: << >>  << T >>  << A >>
One last suggestion Rene -- if your design is already complete, you
can use the power calculation abilities of the Quartus simulator. 
Since the simulator will compute the activity (switching rate) of each
node in your design, it will generally be more accurate than the
spreadsheet on the web, where you have to enter your guessed
activities.  The actitivies calculated by the simulator are still only
as good as your test vectors -- if you have little idea of the typical
input vector usage patterns of your design, simulation may still help
some, but the accuracy will be less than ideal.

Of course, the simulator also knows the details of how many logic
cells, IOs, which standards, etc. are in your design.  So you get the
right numbers there too.

But to use this you need a completed design with test vectors, and
simulation is also slower than doing what-if scenarios in a
spreadsheet.

To use the simulation-based power calculator from the GUI, go to
Assignments->Settings->Simulator, click on the Power Estimation
button, and check the "Estimate Power Consumption" box.
Then simulate your design.  The design report file will now include a
power report section.

Regards,

Vaughn
Altera



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
2019JanFebMar2019

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