EDK : FSL macros defined by Xilinx are wrong

[dave]

Kelly wrote:

I'm trying to find an experienced FPGA Engineer (currently holding a
clearance) - where do people like this look for jobs typically? The
clearance is critical to this opening.

Thank you for your help -

Kelly
kellydingee@adelphia.net

Which nation?
Which market (Military, Aerospace, Telecommunication, Support)?
Full time/Part time/Contract/Subcontract?

Each question generates a different answer.

 

[Mac]

On Sat, 12 Mar 2005 21:01:31 +0000, newman wrote:

"Mac" <foo@bar.net> wrote in message
newsan.2005.03.12.19.14.14.656152@bar.net...
On Sat, 12 Mar 2005 18:52:24 +0000, newman wrote:

In ISE 6.2i, I compile a design off a mapped drive at a foreign site(ie I
did not install the software and do not have administrative privileges).
For example, I try to run Map, sometimes it completes with a green check
mark, and sometimes it completes with no green check mark. Sometimes
when
it compiles with a green check mark, and I hit the Map Report, it reruns
all
the tools again (like xst, ngcbuild, map) as though a source hdl file had
been changed. but no source files have been changed. Its maybe like the
filesystems are running off two different timestamp clocks?

Any ideas?

-Newman

The timestamp thing can be a problem for make-based dependency checking
(which ISE uses).

But if all the design files are stored on the same computer, I would think
that the timestamp would be consistent across all of them.

As a practical matter, would it be possible for you to simply check the
time on all relevant computers? The first step to corrective action is to
determine what the problem is. Inconsistent time is one hypothesis, now
you should test it. If the time is consistent, then you will have to come
up with a new hypothesis.

--Mac

Well, the files are stored on a remote computer. Looking at the file
timestamps in an explorer window, I did notice that when I refreshed the
window, some of the working files were later than the time displayed on the
local computer (where the compilation takes place). I did bump up the local
time by a couple of minutes in order to guess an approximate equal time for
both computers, but I still experienced the same problem.

-Newman

If you want to solve this problem, here is what I suggest. First, devise a
simple, repeatable test which identifies the problem.

Then, formulate a hypothesis about what is causing the problem, and take
appropriate steps (according to the hypothesis) to make the problem go
away. Then perform the simple repeatable test to see if the problem is
fixed. If it is fixed, then, just to be sure, undo the fix, and perform
the test again to make sure the problem comes back. Sometimes I go back
and forth like this several times to really convince myself that I have
solved the problem.

If the potential solution doesn't work, undo it, and try another potential
solution. And so on.

In this case, the question you should ask yourself is, did you synchronize
the clocks or not? Do you feel that you have ruled out clock
differences as a potential cause of the behavior you are seeing or
not? If you haven't ruled it out, then keep messing around until you can.

I would think the one thing you DON'T want to have, is files with
modification times in the future, so if you can't sync the clocks exactly,
at least try to make the clock on the system running the compiler slightly
faster than the one storing the data.

Good luck.

--Mac

 

[James]

Moti wrote:

Hi James,
If I understand you correctly, you are using a ONE-HOT encoding style
(3 flops - one for each state) . Try to convert the FSM encoding style
to GRAY and check it out.

I've recompiled the FSM with gray coding, so now it seems to be in a
valid state, but it seems that the FSM isn't the culprit now. It appears
that when my fifo write signal is asserted, the fifo doesn't actually
start storing information. The odd part was that it WAS doing that a few
microseconds ago at system reset, but no more, and nothing short of a
system reset is able to fix it.

Maybe your FSM suffers from some asynchronous
related problems, if the GRAY will reduce or eliminate the occuronce
rate of this problem (no state problem) then you know that you have to
check your design for async hazards.

But it seems to me that everything in the circuit is synchronized to
either the pixel clock or the system clock, and from what little I
remember from my digital logic course I thought the dual clock fifo was
supposed to do the synchronization between the two clock domains, so I
don't really know where a hazard could exist.

I hope that it is helpful, Moti.

 

[James]

Mike Treseler wrote:

James wrote:

To this end, I've used a dual clock FIFO, with the write port connected
to the sensor, and the read port to the avalon interface (+ glue logic,
of course).


Consider a synchronous fifo on the fastest clock.
Synchronize the slow side to the fast clock.

I'm sorry perhaps I don't understand the term "synchronous fifo" or what
a dual clock fifo is, but wouldn't the dc-fifo be synchronized on the
write side to the write clock, and on the read side to the read clock.
If it helps I'm using Altera's provided lpm_fifo_dc megafunction.

Now the problem appears when I use Nios to transfer the contents of the
FIFO directly to the UART (and to a computer for some post-processing);
after a few 1000 pixels (around 15% of the total), the stream of data to
the computer stops.


Smells like a logic race.
Bogus full or empty from the fifo?

Well since I'm using Altera's provided megafunction (lpm_fifo_dc), I've
assumed that it generates the full/empty signals correctly. But I
suppose I could try checking under the hood, tho I'd rather not cuz of
the daunting (from my point of view atleast) hierarchy present under the
lpm_fifo_dc megafunction.

I re-encoded my FSM using gray coding for the states, and it now seems
to be in the correct state. However the problem seems to have migrated
to the fifo, which doesn't want to store information. When I assert the
write signal, it doesn't take for some reason, and the fifo empty signal
stays active. Odd thing was that it worked fine but a few microseconds
earlier.

After some debugging with Nios' GDB/Eclipse getup

and SignalTap it appears that the constructed FSM is in no state (since
the signaltap signals <state_signal>.<state_name> for each of the 3
states were low).


Consider binary encoding.

During the compilation process, I received no warnings/errors regarding
timing constraints etc. or anything else for that matter. I am at a
complete loss as to how to even begin fixing this. Thoughts anyone?


Logic races come without warning to
teach the lessons of synchronization.

-- Mike Treseler

--
James

 

[Jim George]

Nemesis wrote:

Hi everyone,
I'm going to buy Xilinx ISE Foundation, I'd like to know if this package
contains also IP cores like DDC, FFT and so on.
It seems that the "LogiCore" IPs should be shipped within ISE
Foundations, am I right?

Yes, ISE Foundation comes with Coregen.

 

[Daniel Koethe]

Hello Marco,
i had the same problem, edit the file: bfm_sim_xps.make in your project
directory and uncomment "SUBMODULE_OPT = -lp ../../../.." with "#".
I don't know if this is the correct solution, but it work's for me.

Daniel

Marco schrieb:

I'm trying to perform a simulation of my OPB peripheral.

I have done the following steps: 1. Opened bfm_system.xmp project in XPS. 2. Clicked Options -> Project Options ... to open up the Project Options and modified 3. Clicked Tools -> Generate Simulation HDL files in XPS to generate the BFM simulation platform.

This is the console log:

(Console Log) PM_SPEC -- Xilinx path component is <C:/EDK> Project Opened. At GMT date and time: 2005:3:11:13:10:38 Command bash -c "cd /xygdrive/c/edk_user_repository/MyProcessorIPLib/pcores/opb_lcd_display_v1_00_a/devl/bfmsim/; /usr/bin/make -f bfm_sim_xps.make simmodel; exit;" Started...
* ******************************************** Create behavioral simulation models ...
* ******************************************** simgen bfm_system.mhs -p xc3s200ft256-5 -lang vhdl -lp ../../../../../ -mixed yes -s mti -X C:/ISE_Lib/ -E C:/EDK_Lib/ -m behavioral Simulation Model Generator Xilinx EDK 6.3 EDK_Gmm.10 Copyright (c) 1995-2003 Xilinx, Inc. All rights reserved.

PM_SPEC -- Xilinx path component is <C:/EDK> Command Line: simgen -p xc3s200ft256-5 -lang vhdl -lp ../../../../../ -mixed yes -s mti -X C:/ISE_Lib/ -E C:/EDK_Lib/ -m behavioral bfm_system.mhs

MHS file : \...\devl\bfmsim\bfm_system.mhs Language (-lang) : VHDL Simulation Model (-m) : Behavioral Simulator (-s) : ModelSim (MTI) Part (-p) [ family ] : xc3s200ft256-5 [ spartan3 ] Output directory (-od): C:\edk_user_repository\MyProcessorIPLib\pcores\opb_lcd_display_v1_00_a\devl\bfms im\

Edklib (-E) : C:\EDK_Lib\ Xlib (-X) : C:\ISE_Lib\

Library Path (-lp): C:\edk_user_repository\

Simulation Model Generator started ...

Reading MHS file ... lp : C:\edk_user_repository\ ERROR:MDT - Path 'C:\edk_user_repository\' already added. make: *** [simulation/behavioral/bfm_system.do] Error 1 Done.

What I could do to solve the troulbe?

Thanks Marco

 

[stella]

I am using the same board..and have almost the same problem..

When I use the command below in EDK testApp
Xuint32 FIFO_mReadReg(Xuint32 BaseAddress, unsigned RegOffset)

the base address is 0x00000000
shall I use the offset below?
#define FIFO_IPIF_RDFIFO_DATA_SPACE_OFFSET (0x00000300)

After download the bitstream, I use 'mrd 0x00000300' in xmd, it seems
that nothing is written in the memory...

You can read '1' and '7' at least...but I have nothing........so
sad...

 

[Jarek]

Użytkownik "Joel Kolstad" <JKolstad71HatesSpam@Yahoo.Com> napisał w
wiadomości news:C6CdneUiR69idqzfRVn-1w@comcast.com...

Does anyone know where I might obtain some Actel A54SX16P FPGAs in the
VQ100 package? Actel has exactly one distributor, and they're out of
stock for awhile. We've been searching the gray market some, and I
figured I'd ask here.

Speed grade doesn't matter, pricing isn't too important (within reason),
just the package and the fact that it's the 'P' suffix (we're using it
with 5V inputs). We're after about 250, although smaller quantities would
be fine too since we don't need them all right away.

The sooner we could get some... the better!

If you know of a source, please reply to jkolstad71@yahoo.com or to the
group.

Thank you,
---Joel Kolstad

Hi,

Try www.hkinventory.com

Best regards
Jaroslaw Czula

 

[antonio bergnoli]

does anybody try it with a different linux platform from red hat
enterprise? I have a debian testing and it don't work


Eric Smith ha scritto:

Ray Andraka <ray@andraka.com> writes:

FWIW, I don't even load a mjor release anymore until service pack 1 is
out. Better to let someone else find the easy bugs!


I just load it in a different directory. If I have trouble with it, I
can easily switch back to the previous release.

 

[Uwe Bonnes]

antonio bergnoli <bergnoli@pd.infn.it> wrote:

does anybody try it with a different linux platform from red hat
enterprise? I have a debian testing and it don't work

Eric Smith ha scritto:
Ray Andraka <ray@andraka.com> writes:

FWIW, I don't even load a mjor release anymore until service pack 1 is
out. Better to let someone else find the easy bugs!


I just load it in a different directory. If I have trouble with it, I
can easily switch back to the previous release.

Download the shell script.
Edit the script to not erase the payload on error:
#!/bin/sh
# This script was generated using Makeself 2.1.2
CRCsum="3131057736"
MD5="00000000000000000000000000000000"
TMPROOT=${TMPDIR:=/tmp}

label="Xilinx ISE WebPACK Installer"
script="./setup"
scriptargs=""
targetdir="wpdl_all_lin.build"
filesizes="390880212"
keep=y
^^^^^^^
Change from n to y

Now run again. The directory "wpdl_all_lin.build" should get created.

Try to find "libcurl.so.2" and copy to
wpdl_all_lin.build/platform/lin/bin

set the DISPLAY variable to :0

Run wpdl_all_lin.build/setup...

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

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

 

Thanks for all your ideas on this matter.

There is no JTAG support on this device. All devices are programmed
from an external computer using the Done/Prg', Reset, Data and Clock
pins using the slave serial mode. The traces are daisy chained to each
device and then terminated at the end of the bus. All devices are
loaded with the same core using slave serial mode. Even if the loading
state machine were some how stuck, needing more clock cycles to flush
it, the programming does this upon each load sequence. Also, if you
have the data sheet, on page 7-19, you will notice that during
configuration, if the Reset pin is active, the configuration will abort
and the init. sequence will start over.

The following is from the data sheet for the 3000:

"To initiate a re-programming cycle, the dual-function pin
DONE/PROG must be given a High-to-Low transition. To
reduce sensitivity to noise, the input signal is filtered for two
cycles of the FPGA internal timing generator."

All of these pins are hard wired together. And once in the "locked"
state, the device remains with the pin released. So, I am still able
to pull the pin low to start a new download. Once the device is in the
mode, it is almost like it behaves like it is no longer in the circuit.
I am able to program all other devices in the chain.



The following is from the data sheet for the 3000:

"The FPGA tests
for the absence of an external active Low RESET before it
makes a final sample of the mode lines and enters the Configuration
state. An external wired-AND of one or more INIT
pins can be used to control configuration by the assertion of
the active-Low RESET of a master mode device or to signal
a processor that the FPGAs are not yet initialized.
If a configuration has begun, a re-assertion of RESET for a
minimum of three internal timer cycles will be recognized
and the FPGA will initiate an abort, returning to the Clear
state to clear the partially loaded configuration memory
words. The FPGA will then resample RESET and the mode
lines before re-entering the Configuration state.
During configuration, the XC3000A, XC3000L, XC3100A,
and XC3100L devices check the bit-stream format for stop
bits in the appropriate positions. Any error terminates the
configuration and pulls INIT Low."

 

Strike that last bit about the Done/Prg' being hardward wired. They
are seperate signals, so yes, it is very possible the the Done could be
held low in the locked state.

lecroy7200@chek.com wrote:

Thanks for all your ideas on this matter.

There is no JTAG support on this device. All devices are programmed
from an external computer using the Done/Prg', Reset, Data and Clock
pins using the slave serial mode. The traces are daisy chained to
each
device and then terminated at the end of the bus. All devices are
loaded with the same core using slave serial mode. Even if the
loading
state machine were some how stuck, needing more clock cycles to flush
it, the programming does this upon each load sequence. Also, if you
have the data sheet, on page 7-19, you will notice that during
configuration, if the Reset pin is active, the configuration will
abort
and the init. sequence will start over.

The following is from the data sheet for the 3000:

"To initiate a re-programming cycle, the dual-function pin
DONE/PROG must be given a High-to-Low transition. To
reduce sensitivity to noise, the input signal is filtered for two
cycles of the FPGA internal timing generator."

All of these pins are hard wired together. And once in the "locked"
state, the device remains with the pin released. So, I am still able
to pull the pin low to start a new download. Once the device is in
the
mode, it is almost like it behaves like it is no longer in the
circuit.
I am able to program all other devices in the chain.



The following is from the data sheet for the 3000:

"The FPGA tests
for the absence of an external active Low RESET before it
makes a final sample of the mode lines and enters the Configuration
state. An external wired-AND of one or more INIT
pins can be used to control configuration by the assertion of
the active-Low RESET of a master mode device or to signal
a processor that the FPGAs are not yet initialized.
If a configuration has begun, a re-assertion of RESET for a
minimum of three internal timer cycles will be recognized
and the FPGA will initiate an abort, returning to the Clear
state to clear the partially loaded configuration memory
words. The FPGA will then resample RESET and the mode
lines before re-entering the Configuration state.
During configuration, the XC3000A, XC3000L, XC3100A,
and XC3100L devices check the bit-stream format for stop
bits in the appropriate positions. Any error terminates the
configuration and pulls INIT Low."

 

[Brian Davis]

Philip wrote:

The solution may involve changes to your power supply, such that if
the voltage ever dips below say 4.5V, you make sure it goes all the
way down to 0V, for maybe 100 mS, before it comes back up.

I also have vague recollections of this problem ( needing to
completely shut off power to 0V recover )

Some googling turned up this copy of an old Xilinx
answer record #134 (watch line breaks on the link):

http://www.nalanda.nitc.ac.in/industry/appnotes/xilinx/documents/techdocs/134.htm


Brian

 

Thanks. I read the note and agree that the problem could be related to
some kind of transient. If the Done/Program pin were stuck in the low
state it appears that the device will still reset by monitoring the
state of the Reset pin.

"A re-program is initiated.when a configured XC3000 series
device senses a High-to-Low transition and subsequent >6
us Low level on the DONE/PROG package pin, or, if this
pin is externally held permanently Low, a High-to-Low transition
and subsequent >6 us Low time on the RESET package
pin."

The note to your link suggests that setting Reset high for > 6us then
setting it and the Prog/Done pin low for > 6us will bring the device
back to the clear configuration state. Looking at the loader code,
this is pretty much what is being done on every load. The Reset
normally idles high and it along with the Program pin are pulled low
for 7.5us. I verified this as well. Doing this does not make the
device exit this strange mode. So far, the only thing that seems to
clear it from this state is a hard power down.

As a test, I forced the Prog pin low on one device in the chain. The
pin latches low as expected. I then forced a few clock cycles to get
the device into some mid data stream mode. I then pulled the reset low
and started a normal configuration. The part did recover, releasing the
Prog. pin at the end of the programming cycle. So, at least this all
seems to work.

My next step is to conduct noise onto the supply to see if I can
replicate the problem. Because this happens so infrequent, it is next
to impossible to find any other clues.






Brian Davis wrote:

Philip wrote:

The solution may involve changes to your power supply, such that if
the voltage ever dips below say 4.5V, you make sure it goes all the
way down to 0V, for maybe 100 mS, before it comes back up.


I also have vague recollections of this problem ( needing to
completely shut off power to 0V recover )

Some googling turned up this copy of an old Xilinx
answer record #134 (watch line breaks on the link):


http://www.nalanda.nitc.ac.in/industry/appnotes/xilinx/documents/techdocs/134.htm


Brian

 

I tried a few different tests. I first reduced the supply votage on
the Xilinx devices by 500mV and ran the system as normal, but saw no
problems. I then reduced the supply voltage until I started to see
problem with the function of the devices (this was around 3.5 volts),
but as soon as the supply was returned to normal the parts would
function normal as well. Using a bias T I then injected a sinewave
onto the supply line. I ran the supply at 4.5 volts and injected a
500mV signal. I did multiple sweeps from 100KHz up to a bit over a GHz
and saw no problems. I then ran the same test with the supply at 5
volts and again saw no problems.

So far, it would appear the problem is not related to the supply
voltage or operating temperature.

 

[fpgavhdl@gmail.com]

Sorry for not being prompt in replying to your mail. I was out for town
for a week. The MK 2069 generates a 27 MHz clock. The 27 MHz clock
generated by 2069 is locked to the Hsync, but when no Hsync it still
generates a 27 Mhz clock..which is a little wierd.

Well I the clock generated by the PLL (after it is locked to the Hsync)
is not exactly a 50 % duty cycle square wave. Can I use a square wave
shaper? Will I lose the locked information if I do that.

BTW its my hobby to design projects for Televison Broadcasting
applications....well if it works it might go commercial

Really appreciate ur help

 

[tim.linden@gmail.com]

Have you considered the OCIDEC (OpenCores IDE Controller) project.
This may be usefull reference if you want to do this for the sake of
experience. I personally have not used this core but I think it might
be worth something.

You may want to check out the other IDE MP3 player projects out there
for some clues. I know of at least one that uses a PIC and a CD-ROM
drive.

Good Hunting

 

[Eric Smith]

antonio bergnoli <bergnoli@pd.infn.it> writes:

does anybody try it with a different linux platform from red hat
enterprise? I have a debian testing and it don't work

Most likely you don't have the versions of libraries it wants, or (if
you're running 6.3i) you're not setting up the environment variables that
it needs.

I've been running ISE 6.3i on Fedora Core 3 (x86_64 version) on an
Athlon 64 for a while now, and on the regular x86 version of FC3 on a
laptop, and it works fine, but I had to set some environment variables
to get it going. IIRC, to install it I said something like:

DISPLAY=:0 LD_ASSUME_KERNEL=2.4.7 ./setup

I don't like setting special environment variables in my ~/.bash_profile
that are only needed by one program and may interfere with other
programs (like LD_ASSUME_KERNEL), so to run the installed programs,
I use a bash script in my ~/bin directory called x63:

#!/bin/sh
x=$HOMExilinx/ise63
export LD_ASSUME_KERNEL=2.4.7
export DISPLAY=:0
source $x/settings.sh
$x/bin/lin/$1

The way I normally use it is to say "x63 ise", but you can invoke
other tools like fpga_editor as well. This trivial script doesn't
have provision for passing command line arguments, but that could
easily be added.

I just installed ISE 7.1i on Fedora Core 3 last night. It needed a
few older libraries from Fedora Core 2, libcurl.so.2, libcurl.so.2.0.2,
libXm.so.3, and libXm.so.3.0.2. I extracted those from the Fedora Core 2
RPMs (curl-7.11.1-1.i386.rpm and openmotif-2.2.3-2.i386.rpm), and put
them in ~/xilinx/oldlibs. I think libcurl was only needed by the
installed, but I haven't verified that. I did the install by saying
LD_LIBRARY_PATH=~/xilinx/oldlibs ./setup

My script for running 7.1i is:

#!/bin/sh
x=$HOME/xilinx/ise71
export LD_LIBRARY_PATH=$HOME/xilinx/oldlibs
source $x/settings.sh
$XILINX/bin/$PLATFORM/$1

Thus far I've been able to rebuild all my old 6.3i projects with 7.1i,
and everything seems to work except that synthesis errors apparently
cause ISE to try to invoke some kind of script, and that appears to
be failing. But the synthesis error messages show up in the report
file so I don't care too much.

I tried installing the 64-bit version on the Athlon 64 system, but ran
into many more problems with it, and wasn't able to resolve them all.
However, I have a BaseX license, and it appears that BaseX isn't
supported in 64-bit, so perhaps it wouldn't have worked for me even if
I'd solved the other problems.

Eric

 

[Eric Smith]

Uwe Bonnes wrote:

set the DISPLAY variable to :0

I had to do that with 6.3i, but 7.1i doesn't seem to need it.

Eric

 

[Jim Granville]

lecroy7200@chek.com wrote:

Thanks. I read the note and agree that the problem could be related to
some kind of transient. If the Done/Program pin were stuck in the low
state it appears that the device will still reset by monitoring the
state of the Reset pin.

Err, maybe.
Keep in mind that on many devices, the RESET does NOT reset everything,
and is more aptly labeled reset request.
It is not uncommon to see devices enter a illegal (but 'safe') state,
that can only be exited by a power cycle.
This is because chips often use internal POR cells, using simple RC
elements.
Such states are normally either external energy transient or
runt-pulse related.

That is why in some industries, the WDOG systems work by doing a
Power-Cycle, rather than the less effective 'reset'.

If you can sense this state, your best remedy could be to trigger
a power re-cycle ?

-jg