Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
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
"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.comArticle: 64901
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
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
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: 64904guillerodriguez@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 ThomasArticle: 64905
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 AnttiArticle: 64906
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
"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: 64908I 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
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
>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
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>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
>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
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: 64915That 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 ThomasArticle: 64916
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
"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: 64918cruiser144@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
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
> 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.ukArticle: 64921
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
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, SteveArticle: 64923
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 SulimmaArticle: 64924
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:
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