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

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

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

Custom Search

Messages from 108500

Article: 108500
Subject: Re: Xilkernel: Problem with mutex
From: "Antti" <Antti.Lukats@xilant.com>
Date: 12 Sep 2006 03:20:33 -0700
Links: << >>  << T >>  << A >>
Andreas Hofmann schrieb:

> Antti schrieb:
> > Andreas Hofmann schrieb:
> >
> >> Hello,
> >>
> >> i have created a fairly simple Microblaze-based system, just one core,
> >> opb-UART, BRAM, opb-timer and opb-intc. I wrote a small program using
> >> the xilkernel-OS which creates two threads printing a thread-specific
> >> number and the current clock_ticks. The code is given below. I expect
> >> the program to print each second a message of one thread, but that
> >> doesn't work.
> >>
> >> When executing the program both threads seem to enter the code fragment
> >> locked by the mutex nearly at the same time as can be seen by the
> >> printed clock_ticks.
> >> The mutex is declared static and initialized in the static thread
> >> created by xilkernel_main and before creating the "Hello world"-threads.
> >>
> >> <--------------------------->
> >> void thread_func(int number)
> >> {
> >>   while (1)
> >>   {
> >>     pthread_mutex_lock(&print_mutex);
> >>     sleep(500);
> >>     xil_printf("Ticks = %d. Thread %d says: Hello world!\r\n",
> >>                xget_clock_ticks(), number);
> >>     sleep(500);
> >>     pthread_mutex_unlock(&print_mutex);
> >>   }
> >> }
> >> <--------------------------->
> >>
> >> Output via UART:
> >> Ticks = 362. Thread 1 says: Hello world!
> >> Ticks = 365. Thread 2 says: Hello world!
> >> Ticks = 464. Thread 1 says: Hello world!
> >> Ticks = 468. Thread 2 says: Hello world!
> >>
> >>
> >> Regards,
> >>
> >> Andreas
> >
> > hm, I think it each thread should print 1 message once a second
> > and that is what you see as well, so everything is working?
>
> No. As the sleeping is done while the mutex is locked each thread should
> print its message every two seconds. As one tick is approximately 10 ms
> the message of thread 2 is printed 30 ms after the message of thread 1.
> So there must be something wrong.
>
> Regards,
> Andreas

ok, if you say so :)

for me it wasnt so obvious that obtaining mutex lock on 'print_mutex'
will disable all threads from executing!

the 30 milliseconds seems to me also correct as this the time it takes
to send your hello ... over 9600 baud UART

Antti


Article: 108501
Subject: Re: Simulating EDK 8.1i System using ModelSim 6.1e
From: Brian Drummond <brian_drummond@btconnect.com>
Date: Tue, 12 Sep 2006 11:21:51 +0100
Links: << >>  << T >>  << A >>
On 11 Sep 2006 12:58:57 -0700, "kits59@gmail.com" <kits59@gmail.com>
wrote:

>Hello,
>
>Recently, I have been trying to simulate my system to verify that the
>pieces are working correctly in my EDK project.  In order to do this, I
>need to use the SmartModel simulation tools for ModelSim 6.1e.  I've
>read through all of Xilinx's documentation and have set up the
>modelsim.ini file correctly, but when I run the simulation, everything
>hangs.  There are no calls to the BRAM to fetch code for execution.
>
>The only thing I get that might be a part of the problem is the
>following warnings:
>
># ** Warning (SmartModel):
>#    Model is being requested to run at a finer resolution than
>necessary.

This is not a problem. 1ns resolution is too coarse for SmartModel
simulation (and will not work) - 1ps is "too fine" but does work. I
haven't tried 100ps or 10ps but suspect one of these is the correc
answer.

Something else must be the problem : check clocks, resets, is your bRAM
mapped to cover the boot address (FFFFFFFC for the PPC405), there are no
"Warning: unbound component" messages when ModelSim loads the design
etc?

- Brian


Article: 108502
Subject: Re: Xilkernel: Problem with mutex
From: Andreas Hofmann <ahofmann@ti.cs.uni-frankfurt.de>
Date: Tue, 12 Sep 2006 13:52:27 +0200
Links: << >>  << T >>  << A >>
Antti schrieb:
> Andreas Hofmann schrieb:
> 
>> Antti schrieb:
>>> hm, I think it each thread should print 1 message once a second
>>> and that is what you see as well, so everything is working?
>> No. As the sleeping is done while the mutex is locked each thread should
>> print its message every two seconds. As one tick is approximately 10 ms
>> the message of thread 2 is printed 30 ms after the message of thread 1.
>> So there must be something wrong.
>>
>> Regards,
>> Andreas
> 
> ok, if you say so :)
> 
> for me it wasnt so obvious that obtaining mutex lock on 'print_mutex'
> will disable all threads from executing!

The other threads should be blocked because sleep() is called while the
mutex is held by the sleeping thread.

Admittedly my code immediately tries to lock the mutex after releasing
it so the other threads may have no chance to execute their lock
request. This seems to cause the problems because after enabling
yield()-support and calling yield() after pthread_mutex_unlock() solves
the problem. The program does now behave as expected.

However, i do not fully understand what the kernel is doing when yield()
is missing. Shouldn't the other threads, which do not hold the lock,
starve while one of the thread locks the mutex over and over again?

On the other hand, the Xilinx manual clearly states that when
pthread_mutex_unlock() is called "the thread
that is at the head of the mutex wait queue is unblocked and
allowed to lock the mutex.". Thus calling or omiting yield() shouldn't
make any difference.

Regards,
Andreas

Article: 108503
Subject: Re: xilinx bram instantation template in vhdl?
From: "Andy" <jonesandy@comcast.net>
Date: 12 Sep 2006 05:44:25 -0700
Links: << >>  << T >>  << A >>
If you can infer the brams from a constant as shown earlier, it will
simulate much faster than instantiated BRAMS. Also, the code would be
portable to other architectures/vendors.

Andy


David Ashley wrote:
> Ben Jackson wrote:
> > On 2006-09-11, David Ashley <dash@nowhere.net.dont.email.me> wrote:
> >
> >>I want to create a 1152 by 6 bit rom and I want to use
> >>a bram. It can be clocked or not clocked, but I'd prefer
> >>not clocked. Can someone point me to a template?
> >
> >
> > There's a whole PDF of them called "xst.pdf" which you can google.
> >
>
> Thank you very much! That's what I was after.
>
> Well I'll be busy reading for a while...
>
> -Dave
>
> --
> David Ashley                http://www.xdr.com/dash
> Embedded linux, device drivers, system architecture


Article: 108504
Subject: Re: FPGA timing
From: Kolja Sulimma <news@sulimma.de>
Date: Tue, 12 Sep 2006 14:56:26 +0200
Links: << >>  << T >>  << A >>
skyworld schrieb:
> Hi Ray & Kolja,
> thanks for your reply. The advice is very helpful, but the question is
> that the code is for ASIC design and is frozen. I just migate the code
> to FPGA to check its function. So do you have any suggestion on how to
> setup constraints? something like DC do in ASIC design? thanks

Usually ´the actual performance of the design can not be improved much
compared to the results optained by a simple clock cycle constraint.
However, often a static timing anaylsis reports an overly pessimistic
timing. You can get get better and more realistic values if you specify
false paths and multi cycle constraints to relax the timing budget.


You can perfom the modifications that I suggested and use an equivalnce
checker to proove that you did not change the behaviour of the circuit.
That is a risk free approach for a frozen desing. The particular
transformation that I described also reduces ASIC circuit area and power
consumption.


Kolja Sulimma

Article: 108505
Subject: Re: X4000 bad configuration
From: "Gabor" <gabor@alacron.com>
Date: 12 Sep 2006 05:57:16 -0700
Links: << >>  << T >>  << A >>
It's been a long time since we've used 4000 series parts here,
but we have had a similar issue with Virtex (original) parts.  It
turns out the bad lots were counterfeit.  If you got these parts
from a franchised Xilinx distributor, your parts are most likely
not counterfeit.  In that case I would suggest attempting to
return them and to open a web case with Xilinx as well.

However if you got them through a part
broker, which is common for older parts like these, it is
possible that they are counterfeit.  In the case of the
counterfeit Virtex parts, the actual parts were marked
with the Xilinx part number and logo, but the chips inside
had no resemblance at all to the part marked, and in fact
caused a direct short from +3.3V to ground on our boards.

Good Luck,
Gabor

Jacques GENIN wrote:
> HI,
>
> I experience configuration problems with XC4010E parts.
> I configure them in slave serial mode : M0,M1,M2 = Z.
> Configuration pins (M0-2) do not polarize to VCC as they
> should because of their internal pull-ups, so parts enter
> configuration mode incompatible with my design.
> If I put external pull-ups, those pins polarize correctly
> and the configuration process seems good. Though, in this
> case, the operation of the devices is wrong or unpredictable.
> My design does work correctly with 100s of parts with
> external pull-ups or not. I just encountered this behavior
> with all parts of two shipments.
> Did any one get similar behavior ?
> Any help or infomation welcome.
> 
> JAG


Article: 108506
Subject: Re: linux 2.4 v 2.6 on xilinx
From: "Antti" <Antti.Lukats@xilant.com>
Date: 12 Sep 2006 06:01:47 -0700
Links: << >>  << T >>  << A >>
David Ashley schrieb:

> Anonymous wrote:
> > I have a xilinx soc that is running 2.4 of the PPC linux fine. To run 2.6 is
> > it just a matter of copying the arch directory over to the 2.6 tree and
> > compiling? (Assuming I keep the configuration options the same.)
> >
> > Thanks,
> > Clark
>
> If you're starting from scratch I'd strongly recommend going with
> a 2.6 kernel. 2.6 is very easy to get a serial port driver working, which
> is crucial for debug output while bringing up the kernel.
> Google will bring up some step by step instructions for doing this.
>
> The xilinx free uart-lite core is easy to get working. I brought up
> 2.6 on a virtex-2 pro with the embedded PPC cores. u-boot boots
> from a small bootloader embedded in one of the BRAMS, which
> chains to a NAND flash, which contained u-boot. Finally u-boot
> read out linux-2.6 from a different area of the NAND flash.
>
> I submitted a patch to the u-boot group bringing up u-boot on
> the Memec Design FF1152 board some months ago, I doubt if it
> has been included in the main source tree of u-boot though.
> That included support for the uart lite. Once you've got u-boot
> linux gets easy to bring up. If you look at the u-boot archive you
> can find my post of the patch.
>
> Why 2.6? It's the future, man. If you pick 2.4 someday you'll
> have to upgrade anyway. Pick the latest first.
>
> To answer your specific question, code from 2.4 does not just
> drop in to 2.6. There are lots of little differences. You can recognize
> the same basic code flow from a driver for 2.4 vs 2.6, but a lot of
> the low level details are tweaked. It's fairly easy to adapt 2.4 code
> to 2.6 code though.
>
> Xilinx has ethernet cores. I haven't found an out of the box
> linux driver, 2.4 or 2.6, for any of Xilinx's cores. u-boot supports
> the xilinx ethernet cores. Montevista has drivers for xilinx cores,
> but presumably you'd need to pay for their linux version.
>
> BTW I wasn't able to compile 2.6 under the windows EDK 8.1
> cygwin environment. The build process complains that the
> versions of binutils and the compiler don't match, or something,
> and that either one or the other has to be upgraded or downgraded.
> This was very frustrating, I spent a lot of time trying to get a
> working setup, without success.
>
> In the end I just built linux-2.6 from a linux host and stopped
> trying to build software under windows.
>
> Finally one more note. I found it pointless to use Xilinx's source
> code in any form, or their EDK, for the software side of things.
> I was always struggling with their includes + IDE + point and
> click interface. I invested the time in getting a linux build
> environment up where I could build the software side under
> linux, and export the ELF executables over to the windows box
> which would then integrate into the FPGA bitfile. Once I did
> that development went *fast*. Xilinx software is a nest of
> fishhooks -- try to get one thing, and it includes more,  and that
> includes more...pretty soon your 100 byte bootloader doesn't
> fit into the 16K bytes you've allocated out of BRAMs for the
> PPC init code at FFFFC000...
>
> -Dave
>
> --
> David Ashley                http://www.xdr.com/dash
> Embedded linux, device drivers, system architecture

David,

would you please please consider zipping all the stuff that is needed
to get ppc linux on the memec board running and uploading it?
I do have the same board so I could hopefully get a faster start.
Sure if there is anything I can offer in return please ask.

Antti


Article: 108507
Subject: Spartan-3: 5V -> 2.5V level shifting
From: jidan1@hotmail.com
Date: 12 Sep 2006 06:46:30 -0700
Links: << >>  << T >>  << A >>
Hi,

I would like to configure a spartan-3 FPGA with an 5V CMOS
microcontroller. I have read xilinx database answer regarding how to
make 3.3V I/O input pins 5V tolerant with a serial resistor (300Ohm).

1) Can also the confg. dedicated pins made 5V tolerant through a serial
resistor although they are powered from 2.5V? (I calculated this an I
came to Rser=3D220OHM)
2) The VIH of my microcontroller is 3V, that of spartan-3 I/O's is
(VCCO=3D3.3V) is 2.9V. Do I need level-shifters to drive my =B5C? If yes,
what IC's would you recommend?

Thank you in advance,
JJ


Article: 108508
Subject: Re: ddr with multiple users
From: "Weng Tianxiang" <wtxwtx@gmail.com>
Date: 12 Sep 2006 06:57:03 -0700
Links: << >>  << T >>  << A >>

Daniel S. wrote:
> Weng Tianxiang wrote:
> > Daniel S. wrote:
> >> David Ashley wrote:
> >> Since routing multiple 32+bits buses consumes a fair amount of routing
> >> and control logic which needs tweaking whenever the design changes, I
> >> have been considering ring buses for future designs. As long as latency
> >> is not a primary issue, the ring-bus can also be used for data
> >> streaming, with the memory controller simply being one more possible
> >> target/initiator node.
> >>
> >> Using dual ring buses (clockwise + counter-clockwise) to link critical
> >> nodes can take care of most latency concerns by improving proximity. For
> >> large and extremely intensive applications like GPUs, the memory
> >> controller can have multiple ring bus taps to further increase bandwidth
> >> and reduce latency - look at ATI's X1600 GPUs.
> >>
> >> Ring buses are great in ASICs since they have no a-priori routing
> >> constraints, I wonder how well this would apply to FPGAs since these are
> >> optimized for linear left-to-right data paths, give or take a few
> >> rows/columns. (I did some preliminary work on this and the partial
> >> prototype reached 240MHz on V4LX25-10, limited mostly by routing and 4:1
> >> muxes IIRC.)
> >
> > Hi Daniel,
> > Here is my suggestion.
> > For example, there are 5 components which have access to DDR controller
> > module.
> > What I would like to do is:
> > 1. Each of 5 components has an output buffer shared by DDR controller
> > module;
> > 2. DDR controller module has an output bus shared by all 5 components
> > as their input bus.
> >
> > Each data has an additional bit to indicate if it is a data or a
> > command.
> > If it is a command, it indicates which the output bus is targeting at.
> > If it is a data, the data belongs to the targeted component.
> >
> > Output data streams look like this:
> > Command;
> > data;
> > ...
> > data;
> > Command;
> > data;
> > ...
> > data;
> >
> > In the command data, you may add any information you like.
> > The best benefit of this scheme is it has no delays and no penalty in
> > performance, and it has minimum number of buses.
> >
> > I don't see ring bus has any benefits over my scheme.
> >
> > In ring situation, you must have (N+1)*2 buses for N >= 2. In my
> > scheme, it must have N+1 buses, where N is the number of components,
> > excluding DDR controller module.
> >
> > Weng
>
> In a basic ring, there needs to be only N segments to create a closed
> loop with N nodes, memory-controller included. Double that for a fully
> doubly-linked bus.
>
> Why use a ring bus?
> - Nearly immune to wire delays since each node inserts bus pipelining
> FFs with distributed buffer control (big plus for ASICs)
> - Low signal count (all things being relative) memory controller:
> 	- 36bits input (muxed command/address/data/etc.)
> 	- 36bits output (muxed command/address/data/etc.)
> - Same interface regardless of how many memory clients are on the bus
> - Can double as a general-purpose modular interconnect, this can be
> useful for node-to-node burst transfers like DMA
> - Bandwidth and latency can be tailored by shuffling components,
> inserting extra memory controller taps or adding rings as necessary
> - Basic arbitration is provided for free by node ordering
>
> The only major down-side to ring buses is worst-case latency. Not much
> of an issue for me since my primary interest is video
> processing/streaming - I can simply preload one line ahead and pretty
> much forget about latency.
>
> Flexibility, scalability and routability are what makes ring buses so
> popular in modern large-scale, high-bandwidth ASICs and systems. It is
> all a matter of trading some up-front complexity and latency for
> long-term gain.
>
> Since high-speed parallel buses end up needing pipelining to meet
> high-speed timings, the complexity and area delta between multiple
> parallel buses and ring-bus topologies is shrinking.
>
> --
> Daniel Sauvageau
> moc.xortam@egavuasd
> Matrox Graphics Inc.
> 1155 St-Regis, Dorval, Qc, Canada
> 514-822-6000

Hi Daniel,
It is very interesting to learn there is a ring bus structure over
there.

"Flexibility, scalability and routability are what makes ring buses so
popular in modern large-scale, high-bandwidth ASICs and systems"

Can you please me some reference papers about ring bus applications in
ASIC or FPGA?

Normally what a designer is concerns most about is data latency in a
bus structure 
Thank you.

Weng


Article: 108509
Subject: Re: X4000 bad configuration
From: Jacques GENIN <rxnd@wanadoo.fr>
Date: Tue, 12 Sep 2006 16:00:34 +0200
Links: << >>  << T >>  << A >>
Gabor a écrit :
> It's been a long time since we've used 4000 series parts here,
> but we have had a similar issue with Virtex (original) parts.  It
> turns out the bad lots were counterfeit.  If you got these parts
> from a franchised Xilinx distributor, your parts are most likely
> not counterfeit.  In that case I would suggest attempting to
> return them and to open a web case with Xilinx as well.
> 
> However if you got them through a part
> broker, which is common for older parts like these, it is
> possible that they are counterfeit.  In the case of the
> counterfeit Virtex parts, the actual parts were marked
> with the Xilinx part number and logo, but the chips inside
> had no resemblance at all to the part marked, and in fact
> caused a direct short from +3.3V to ground on our boards.
> 
> Good Luck,
> Gabor
> 
Effectively, I got those parts from a broker.
I do not think they are counterfeit because they have a part
of the behaviour I expect from "good" components. They do
not seem to be dumb stones in packages.
Anyway, I'm OK : when buying obsolete parts, one must be
more and more carefull !

Thanks, anyhow
Jacques

Article: 108510
Subject: Cmult in System Gnerator
From: "Kuan Zhou" <kuan.zhou@unh.edu>
Date: Tue, 12 Sep 2006 10:13:32 -0400
Links: << >>  << T >>  << A >>
Hi,

    We are designing a linear phase FIR filter. Several Cmults are included 
in the FIR filter as multipliers. All the coefficients are linear. However, 
we are not sure how to import the coefficients from the mask. For example, 
from the FDA tool, we can easily export the fixed point coefficients of the 
FIR filter to a vector A. We can manually input the coefficients from A to 
indivisual Cmults. I am wondering if there is an automatic way to import all 
the coefficients.

    Any suggestions?

Kuan 



Article: 108511
Subject: Re: FPGA timing
From: "Peter Alfke" <alfke@sbcglobal.net>
Date: 12 Sep 2006 07:39:35 -0700
Links: << >>  << T >>  << A >>

skyworld wrote:
> Hi Ray & Kolja,
> thanks for your reply. The advice is very helpful, but the question is
> that the code is for ASIC design and is frozen. I just migate the code
> to FPGA to check its function. So do you have any suggestion on how to
> setup constraints? something like DC do in ASIC design? thanks
>
If you are just checking functionality, why are you concerned about
timing?
Reduce the clock rate and check the functionality, if that is what you
intend to do.
But you must be concerned about clock distribution (use only global
clocks!) otherwise you invite ugly hold-time issues.
Peter Alfke, Xilinx


Article: 108512
Subject: Re: Simulating EDK 8.1i System using ModelSim 6.1e
From: "kits59@gmail.com" <kits59@gmail.com>
Date: 12 Sep 2006 07:45:19 -0700
Links: << >>  << T >>  << A >>

Brian Drummond wrote:
> On 11 Sep 2006 12:58:57 -0700, "kits59@gmail.com" <kits59@gmail.com>
> wrote:
>
> >Hello,
> >
> >Recently, I have been trying to simulate my system to verify that the
> >pieces are working correctly in my EDK project.  In order to do this, I
> >need to use the SmartModel simulation tools for ModelSim 6.1e.  I've
> >read through all of Xilinx's documentation and have set up the
> >modelsim.ini file correctly, but when I run the simulation, everything
> >hangs.  There are no calls to the BRAM to fetch code for execution.
> >
> >The only thing I get that might be a part of the problem is the
> >following warnings:
> >
> ># ** Warning (SmartModel):
> >#    Model is being requested to run at a finer resolution than
> >necessary.
>
> This is not a problem. 1ns resolution is too coarse for SmartModel
> simulation (and will not work) - 1ps is "too fine" but does work. I
> haven't tried 100ps or 10ps but suspect one of these is the correc
> answer.
>
> Something else must be the problem : check clocks, resets, is your bRAM
> mapped to cover the boot address (FFFFFFFC for the PPC405), there are no
> "Warning: unbound component" messages when ModelSim loads the design
> etc?
>
> - Brian

The funny thing that I should probably state is that the entire system
was simulating perfectly fine under EDK 7.2.  The bRAM is mapped
correctly so that the starting values are where they expect them to be.
 I haven't tried working with 10ps or 100ps, so I'll try those and
report in a little while.


Article: 108513
Subject: Re: Spartan-3: 5V -> 2.5V level shifting
From: "Peter Alfke" <alfke@sbcglobal.net>
Date: 12 Sep 2006 07:47:32 -0700
Links: << >>  << T >>  << A >>

jidan1@hotmail.com wrote:
> Hi,
>
> I would like to configure a spartan-3 FPGA with an 5V CMOS
> microcontroller. I have read xilinx database answer regarding how to
> make 3.3V I/O input pins 5V tolerant with a serial resistor (300Ohm).
>
> 1) Can also the confg. dedicated pins made 5V tolerant through a serial
> resistor although they are powered from 2.5V? (I calculated this an I
> came to Rser=3D220OHM)
> 2) The VIH of my microcontroller is 3V, that of spartan-3 I/O's is
> (VCCO=3D3.3V) is 2.9V. Do I need level-shifters to drive my =B5C? If yes,
> what IC's would you recommend?
>
>Regarding 1:
I would use 1 kilohm. No need to push more current than necessary.
Regarding 2:
You quote worst-case numbers that assum lowest Vcc on the FPGA and
higest possible Vcc on the uP.
Keep the FPGA fed with at least 3.2 V, and you will see that same
voltage on the output (this is CMOS !), and keep the uP Vcc slightly
below 5V.
But you will not have much noise immunity.
Peter Alfke


Article: 108514
Subject: Re: Trying to get plb_temac working
From: Benedikt Wildenhain <benedikt@benedikt-wildenhain.de>
Date: 12 Sep 2006 15:02:49 GMT
Links: << >>  << T >>  << A >>
Hello funkrhytm,

On Mon, Sep 11, 2006 at 12:10:38PM -0700, funkrhythm wrote:
> are you sure you have all the pin assignments/connections between
> plb_temac and hard_temac and such set up properly for the board ?
Absolutely not ;-). Thanks for your information. (And for the other
mails, too). I'll be away some days, but I hope it will start working
next week.

-- 
GPG-Key 1024D/E32C4F4B | www.gnupg.org | http://enigmail.mozdev.org
Fingerprint = 9C03 86B5 CA59 F7A3 D976  AD2C 02D6 ED21 E32C 4F4B
Mit freundlichen Gruessen | Kun afablaj salutoj (www.esperanto.org)
May the tux be with you.  :wq 73



Article: 108515
Subject: Re: Spartan-3: 5V -> 2.5V level shifting
From: Austin Lesea <austin@xilinx.com>
Date: Tue, 12 Sep 2006 08:26:30 -0700
Links: << >>  << T >>  << A >>
jidan,

Peter makes a good point:  if the resistance is too low, then you are
injecting current into the 2.5 V supply, and it may begin to drift up,
and out of regulation.

One way to avoid that, and to avoid any rail supply being driven above
its intended output, is to balance the injected current with a simple
resistor across the power supply, present all the time.

So, if you think you will inject 100 mA worst case into the 2.5V rail,
then plan on having a load of at least 100 mA on the 2.5 volt supply.
If the 2.5 volt supply has a minimum normal load of 50 mA, then you will
need an additional 50 mA load, just in case.  2.5V/.05=50 ohms (51 ohms,
nearest 5% value).

All this because regulators are good at regulating a load, but incapable
of regulating when you source current into there output terminal.

Austin

Peter Alfke wrote:
> jidan1@hotmail.com wrote:
>> Hi,
>>
>> I would like to configure a spartan-3 FPGA with an 5V CMOS
>> microcontroller. I have read xilinx database answer regarding how to
>> make 3.3V I/O input pins 5V tolerant with a serial resistor (300Ohm).
>>
>> 1) Can also the confg. dedicated pins made 5V tolerant through a serial
>> resistor although they are powered from 2.5V? (I calculated this an I
>> came to Rser=220OHM)
>> 2) The VIH of my microcontroller is 3V, that of spartan-3 I/O's is
>> (VCCO=3.3V) is 2.9V. Do I need level-shifters to drive my µC? If yes,
>> what IC's would you recommend?
>>
>> Regarding 1:
> I would use 1 kilohm. No need to push more current than necessary.
> Regarding 2:
> You quote worst-case numbers that assum lowest Vcc on the FPGA and
> higest possible Vcc on the uP.
> Keep the FPGA fed with at least 3.2 V, and you will see that same
> voltage on the output (this is CMOS !), and keep the uP Vcc slightly
> below 5V.
> But you will not have much noise immunity.
> Peter Alfke
> 

Article: 108516
Subject: Re: Xilinx ISE ver 8.2.02i is optimizing away and removing "redundant" logic - help!
From: james7uw@yahoo.ca
Date: 12 Sep 2006 08:34:10 -0700
Links: << >>  << T >>  << A >>
KJ wrote:
> <james..yahoo.ca> wrote:

> > the post-map stage fails its simulation so badly
>
> > I certainly suspect all the removed
> > "redundant logic" that the mapper is reporting.
> But you have no basis for that suspicion.  It might be the case that the
> synthesis process has a bug but you need to prove it.....and then open a
> service request on the company that has the bug in it.  My point is don't
> let your objectivity be clouded by what you suspect, debug and prove.

I do have basis, as I wrote previously: using the "keep"
statements removed some lines of removed "redundant"
logic and dramatically improved success of the post-map
simulation. I would indeed, however, like to avoid using this as a
crutch and do it properly as you indicate. I would like to
find out the correct way to indicate in the VHDL, by the
way I write the VHDL, that the logic is not redundant.

>
> > But how to indicate it
> > is not
> > really redundant, without using "keep" and "save" statements
> > everywhere?
> And this is where you start spinning your wheels (in my opinion).  Instead
> of simply debugging the post-map sim to the source of the discrepancy you're
> trying things based on a suspicion that is not proven.  Let's say for the
> sake of argument that your suspicion is wrong about the removal of redundant
> logic and that the problem is a timing issue with your testbench instead.
> That would mean that every minute you spend chasing 'keep' and 'saves' etc.
> was wasted time.

I'm not really arguing for using those crutches; I'm seriously
asking what to do so that I don't need them.

>
> > I
> > can't even complain that all my signals are connected (they
> > are), because that's not the problem: the mapper is not removing
> > "unused logic".
> >
> This will sound like a dumb question on my part but what is the distinction
> in your mind between 'redundant logic' and 'unused logic'?  The reason for
> my confusion at this point would be because you say the 'redundant' stuff is
> getting removed and yet there is no 'unused' logic getting removed.  If by
> 'redundant' you mean the classical Boolean Logic 101 definition where you
> add redundant logic to act as 'cover' terms in your Karnaugh map to avoid
> race conditions then that is the most likely cause of your problems.  Is
> this the type of logic that you are trying to 'keep' but is being mapped
> away as an 'optomization'?  If it is, then the rest of this post probably
> doesn't apply and we can discuss this point further, but if it is not then
> keep on reading.

The "redundant" and "unused" logic terms I am copying from the mapper
report and Xilinx documentation. The mapper report (see my
first post) says "redundant" logic is being removed, not "unused
logic".
>From my reading of the Xilinx manuals I understand that "unused logic"
means logic that is not connected to anything, so it can be removed
(this latter is not what is happening to me).
However, I haven't found anything in the manuals that explains what
"redundant logic" is or how to write the code to avoid it. I have a lot
of identical ROMs that I use to do parallel processing; those were
being removed in the synthesis and translate step due to not having
clocks on them. So my mind is pretty much a blank as to what is
meant by "redundant" logic, other than the common meaning that it
is repetitive -- but it isn't really, of course, because I'm using them
simultaneously for different data.

>
> One other source of 'optomization' is that an output of some entity is not
> really used.  The logic for equation 'x' happens to reduce down to always
> being 'false'.  This means that everything downstream of 'x' that depends on
> 'x' being true can never happen so it can be optomized away.  It's not the
> fault of the optomizer removing redundant logic that's the way the original
> is coded.  You probably already realize this but thought a quick
> 'Optomization 101' wouldn't hurt....but I also don't think focusing on what
> is being optomized is away is the way you need to go on this one (which is
> the reason on my first post I questioned you "Why...").
>
> What you need to do is to simulate the post-map VHDL file and trace it back
> to why output signal 'x' at time t is set to '0' but when you use your
> original code it is '1'.  Use the sim results from using your original code
> as your guide for what 'should' happen and the post-map VHDL simulation for
> what is actually happen and debug the problem.

I agree that finding out what is going on is the best
approach. Do you have any debugging tips other than comparing
the simulation results in detail and seeing what logic calculations
must be getting removed?

>
> It could be that
> - There is some bug in the translation tool
> - Could be some setting in your build process
> - Could be timing related (i.e. your testbench is violating the setup/hold
> time requirements for the post-map model)
> - Probably other things too
>
> In any case, treat the fully post-map model as something to debug and find
> out the reason for the discrepancy and go from there.

Thank you very much for your input. I really appreciate
the time you are spending to try to help me.

Best regards,
-James


Article: 108517
Subject: Re: xilinx bram instantation template in vhdl?
From: "Brad Smallridge" <bradsmallridge@dslextreme.com>
Date: Tue, 12 Sep 2006 08:47:29 -0700
Links: << >>  << T >>  << A >>
Hi David,

I just finished an 8 by 8 bit font for hex nibble outputs, 0 to F.
I did this for a Xilinx Virtex4 SX35 ML402 dev board in VHDL.
The code below might give you some ideas about how to proceed.
You can see the font better if you replace the 0s with periods,
and back again, when you are ready to synthesize.

Brad Smallridge
Ai Vision

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;

library UNISIM;
use UNISIM.VComponents.all;

entity vga_font is
 port (
 clk  : in std_logic;
 rst  : in std_logic;
 addr : in std_logic_vector(14 downto 0);
 q    : out std_logic );
end vga_font;

architecture behavioral of vga_font is

 type init_array_type is array(natural range <>) of bit_vector(7 downto 0);
 constant vga_font_data : init_array_type :=(

 "00000000",
 "00111000",
 "01111100",
 "11000110",
 "11000110",
 "11000110",
 "01111100",
 "00111000",

 "00000000",
 "00011000",
 "00111000",
 "00011000",
 "00011000",
 "00011000",
 "00011000",
 "00111100",

 "00000000",
 "01111000",
 "11001100",
 "00011000",
 "00110000",
 "01100000",
 "11000000",
 "11111110",

 "00000000",
 "01111100",
 "00000110",
 "00000110",
 "00011100",
 "00000110",
 "00000110",
 "01111100",

 "00000000",
 "11001100",
 "11001100",
 "11001100",
 "01111110",
 "00001100",
 "00001100",
 "00001100",

 "00000000",
 "11111110",
 "11000000",
 "11000000",
 "01111000",
 "00011100",
 "00001110",
 "11111100",

 "00000000",
 "00001100",
 "00011000",
 "00110000",
 "01111100",
 "11000110",
 "01100110",
 "00111000",

 "00000000",
 "11111110",
 "00000110",
 "00001100",
 "00011000",
 "00110000",
 "01100000",
 "11000000",

 "00000000",
 "00111000",
 "11000110",
 "11000110",
 "01111100",
 "11000110",
 "11000110",
 "00111000",

 "00000000",
 "00111000",
 "11000110",
 "11000110",
 "00111100",
 "00011000",
 "00110000",
 "01100000",

 "00000000",
 "00111000",
 "01101100",
 "01101100",
 "01111100",
 "11000110",
 "11000110",
 "11000110",

 "00000000",
 "11111100",
 "11000110",
 "11000110",
 "11111100",
 "11000110",
 "11000110",
 "11111100",

 "00000000",
 "00111100",
 "11000110",
 "11000000",
 "11000000",
 "11000000",
 "11000110",
 "00111100",

 "00000000",
 "11111000",
 "11001100",
 "11000110",
 "11000110",
 "11000110",
 "11001100",
 "11111000",

 "00000000",
 "11111110",
 "11000000",
 "11000000",
 "11110000",
 "11000000",
 "11000000",
 "11111110",

 "00000000",
 "11111110",
 "11000000",
 "11000000",
 "11111000",
 "11000000",
 "11000000",
 "11000000",

  X"00",X"FF" -- also does this format
 );

   function stuff_it
 (
   init_array  : init_array_type;
   init_xx     : integer
 ) return bit_vector is
   variable result : bit_vector(255 downto 0);
 variable i : integer ;
 variable j : integer ;
 variable temp : bit_vector(7 downto 0);
   begin
 result := 
X"0000000000000000000000000000000000000000000000000000000000000000";
 i      := 0 ;
 j      := 32*init_xx ;
 while( (j < init_array'length) and (i<256) )
 loop
   -- result( (i+7) downto (i) ) := init_array(j) ;
   temp := init_array(j);
   -- mirror bit vector
   result(i+7) := temp(0);
   result(i+6) := temp(1);
   result(i+5) := temp(2);
   result(i+4) := temp(3);
   result(i+3) := temp(4);
   result(i+2) := temp(5);
   result(i+1) := temp(6);
   result(i)   := temp(7);
   i := i + 8 ;
   j := j + 1 ;
   end loop;
   return result;
   end function stuff_it;

 signal dob     : std_logic_vector(31 downto 0);

begin

   RAMB16_1 : RAMB16
   generic map (
   DOA_REG => 0, -- Optional output registers on the A port (0 or 1)
   DOB_REG => 1, -- Optional output registers on the B port (0 or 1)
   INIT_A => X"000000000", --  Initial values on A output port
   INIT_B => X"000000000", --  Initial values on B output port
   INVERT_CLK_DOA_REG => FALSE, -- Invert clock on A port output registers 
(TRUE or FALSE)
   INVERT_CLK_DOB_REG => FALSE, -- Invert clock on B port output registers 
(TRUE or FALSE)
   RAM_EXTENSION_A => "NONE", -- "UPPER", "LOWER" or "NONE" when cascaded
   RAM_EXTENSION_B => "NONE", -- "UPPER", "LOWER" or "NONE" when cascaded
   READ_WIDTH_A => 9, -- Valid values are 1,2,4,9,18 or 36
   READ_WIDTH_B => 1, -- Valid values are 1,2,4,9,18 or 36
   SIM_COLLISION_CHECK => "ALL", -- "ALL", "WARNING_ONLY", "GENERATE_X_ONLY" 
or "NONE"
   SRVAL_A => X"000000000", --  Port A ouput value upon SSR assertion
   SRVAL_B => X"000000000", --  Port B ouput value upon SSR assertion
   WRITE_MODE_A => "READ_FIRST", --  WRITE_FIRST, READ_FIRST or NO_CHANGE
   WRITE_MODE_B => "READ_FIRST", --  WRITE_FIRST, READ_FIRST or NO_CHANGE
   WRITE_WIDTH_A => 9, -- Valid values are 1,2,4,9,18 or 36
   WRITE_WIDTH_B => 9, -- Valid values are 1,2,4,9,18 or 36

   INIT_00 => stuff_it(vga_font_data,16#00#),
   INIT_01 => stuff_it(vga_font_data,16#01#),
   INIT_02 => stuff_it(vga_font_data,16#02#),
   INIT_03 => stuff_it(vga_font_data,16#03#),
   INIT_04 => stuff_it(vga_font_data,16#04#),
   INIT_05 => stuff_it(vga_font_data,16#05#),
   INIT_06 => stuff_it(vga_font_data,16#06#),
   INIT_07 => stuff_it(vga_font_data,16#07#),
   INIT_08 => stuff_it(vga_font_data,16#08#),
   INIT_09 => stuff_it(vga_font_data,16#09#),
   INIT_0A => stuff_it(vga_font_data,16#0A#),
   INIT_0B => stuff_it(vga_font_data,16#0B#),
   INIT_0C => stuff_it(vga_font_data,16#0C#),
   INIT_0D => stuff_it(vga_font_data,16#0D#),
   INIT_0E => stuff_it(vga_font_data,16#0E#),
   INIT_0F => stuff_it(vga_font_data,16#0F#),

   INIT_10 => stuff_it(vga_font_data,16#10#),
   INIT_11 => stuff_it(vga_font_data,16#11#),
   INIT_12 => stuff_it(vga_font_data,16#12#),
   INIT_13 => stuff_it(vga_font_data,16#13#),
   INIT_14 => stuff_it(vga_font_data,16#14#),
   INIT_15 => stuff_it(vga_font_data,16#15#),
   INIT_16 => stuff_it(vga_font_data,16#16#),
   INIT_17 => stuff_it(vga_font_data,16#17#),
   INIT_18 => stuff_it(vga_font_data,16#18#),
   INIT_19 => stuff_it(vga_font_data,16#19#),
   INIT_1A => stuff_it(vga_font_data,16#1A#),
   INIT_1B => stuff_it(vga_font_data,16#1B#),
   INIT_1C => stuff_it(vga_font_data,16#1C#),
   INIT_1D => stuff_it(vga_font_data,16#1D#),
   INIT_1E => stuff_it(vga_font_data,16#1E#),
   INIT_1F => stuff_it(vga_font_data,16#1F#),

   INIT_20 => stuff_it(vga_font_data,16#20#),
   INIT_21 => stuff_it(vga_font_data,16#21#),
   INIT_22 => stuff_it(vga_font_data,16#22#),
   INIT_23 => stuff_it(vga_font_data,16#23#),
   INIT_24 => stuff_it(vga_font_data,16#24#),
   INIT_25 => stuff_it(vga_font_data,16#25#),
   INIT_26 => stuff_it(vga_font_data,16#26#),
   INIT_27 => stuff_it(vga_font_data,16#27#),
   INIT_28 => stuff_it(vga_font_data,16#28#),
   INIT_29 => stuff_it(vga_font_data,16#29#),
   INIT_2A => stuff_it(vga_font_data,16#2A#),
   INIT_2B => stuff_it(vga_font_data,16#2B#),
   INIT_2C => stuff_it(vga_font_data,16#2C#),
   INIT_2D => stuff_it(vga_font_data,16#2D#),
   INIT_2E => stuff_it(vga_font_data,16#2E#),
   INIT_2F => stuff_it(vga_font_data,16#2F#),

   INIT_30 => stuff_it(vga_font_data,16#30#),
   INIT_31 => stuff_it(vga_font_data,16#31#),
   INIT_32 => stuff_it(vga_font_data,16#32#),
   INIT_33 => stuff_it(vga_font_data,16#33#),
   INIT_34 => stuff_it(vga_font_data,16#34#),
   INIT_35 => stuff_it(vga_font_data,16#35#),
   INIT_36 => stuff_it(vga_font_data,16#36#),
   INIT_37 => stuff_it(vga_font_data,16#37#),
   INIT_38 => stuff_it(vga_font_data,16#38#),
   INIT_39 => stuff_it(vga_font_data,16#39#),
   INIT_3A => stuff_it(vga_font_data,16#3A#),
   INIT_3B => stuff_it(vga_font_data,16#3B#),
   INIT_3C => stuff_it(vga_font_data,16#3C#),
   INIT_3D => stuff_it(vga_font_data,16#3D#),
   INIT_3E => stuff_it(vga_font_data,16#3E#),
   INIT_3F => stuff_it(vga_font_data,16#3F#),

   INITP_00 => 
X"0000000000000000000000000000000000000000000000000000000000000000",
   INITP_01 => 
X"0000000000000000000000000000000000000000000000000000000000000000",
   INITP_02 => 
X"0000000000000000000000000000000000000000000000000000000000000000",
   INITP_03 => 
X"0000000000000000000000000000000000000000000000000000000000000000",
   INITP_04 => 
X"0000000000000000000000000000000000000000000000000000000000000000",
   INITP_05 => 
X"0000000000000000000000000000000000000000000000000000000000000000",
   INITP_06 => 
X"0000000000000000000000000000000000000000000000000000000000000000",
   INITP_07 => 
X"0000000000000000000000000000000000000000000000000000000000000000")

   port map (
   CASCADEOUTA => open,            -- 1-bit cascade output
   CASCADEOUTB => open,            -- 1-bit cascade output
   DOA         => open,            -- 32-bit A port Data Output
   DOB         => dob,             -- 32-bit B port Data Output
   DOPA        => open,            -- 4-bit  A port Parity Output
   DOPB        => open,            -- 4-bit  B port Parity Output
   ADDRA       => (others=>'1'),   -- 15-bit A port Address Input
   ADDRB       => addr,            -- 15-bit B port Address Input
   CASCADEINA  => '0',             -- 1-bit cascade A input
   CASCADEINB  => '0',             -- 1-bit cascade B input
   CLKA        => '0',             -- Port A Clock
   CLKB        => clk,             -- Port B Clock
   DIA         => (others=>'1'),   -- 32-bit A port Data Input
   DIB         => (others=>'1'),   -- 32-bit B port Data Input
   DIPA        => (others=>'1'),   -- 4-bit  A port parity Input
   DIPB        => (others=>'1'),   -- 4-bit  B port parity Input
   ENA         => '0',             -- 1-bit  A port Enable Input
   ENB         => '1',             -- 1-bit  B port Enable Input
   REGCEA      => '0',             -- 1-bit A port register enable input
   REGCEB      => '1',             -- 1-bit B port register enable input
   SSRA        => '0',             -- 1-bit  A port Synchronous Set/Reset 
Input
   SSRB        => '0',             -- 1-bit  B port Synchronous Set/Reset 
Input
   WEA         => (others=>'0'),   -- 4-bit  A port Write Enable Input
   WEB         => (others=>'0') ); -- 4-bit  B port Write Enable Input

 q <= dob(0);

end behavioral;



"David Ashley" <dash@nowhere.net.dont.email.me> wrote in message 
news:DIGdnY0WlLIGaJjYnZ2dnUVZ_tmdnZ2d@adelphia.com...
>I want to create a 1152 by 6 bit rom and I want to use
> a bram. It can be clocked or not clocked, but I'd prefer
> not clocked. Can someone point me to a template?
>

> Embedded linux, device drivers, system architecture 



Article: 108518
Subject: Re: xilinx bram instantation template in vhdl?
From: David Ashley <dash@nowhere.net.dont.email.me>
Date: Tue, 12 Sep 2006 09:02:28 -0700
Links: << >>  << T >>  << A >>
Brad Smallridge wrote:
> Hi David,
> 
> I just finished an 8 by 8 bit font for hex nibble outputs, 0 to F.
> I did this for a Xilinx Virtex4 SX35 ML402 dev board in VHDL.
> The code below might give you some ideas about how to proceed.
> You can see the font better if you replace the 0s with periods,
> and back again, when you are ready to synthesize.
> ...
>    RAMB16_1 : RAMB16
>    generic map (
>    DOA_REG => 0, -- Optional output registers on the A port (0 or 1)
>    DOB_REG => 1, -- Optional output registers on the B port (0 or 1)
>    INIT_A => X"000000000", --  Initial values on A output port
>    INIT_B => X"000000000", --  Initial values on B output port
>    INVERT_CLK_DOA_REG => FALSE, -- Invert clock on A port output registers 
> (TRUE or FALSE)
>    INVERT_CLK_DOB_REG => FALSE, -- Invert clock on B port output registers 
> (TRUE or FALSE)
>    RAM_EXTENSION_A => "NONE", -- "UPPER", "LOWER" or "NONE" when cascaded
>    RAM_EXTENSION_B => "NONE", -- "UPPER", "LOWER" or "NONE" when cascaded
>    READ_WIDTH_A => 9, -- Valid values are 1,2,4,9,18 or 36
>    READ_WIDTH_B => 1, -- Valid values are 1,2,4,9,18 or 36
>    SIM_COLLISION_CHECK => "ALL", -- "ALL", "WARNING_ONLY", "GENERATE_X_ONLY" 
> or "NONE"
>    SRVAL_A => X"000000000", --  Port A ouput value upon SSR assertion
>    SRVAL_B => X"000000000", --  Port B ouput value upon SSR assertion
>    WRITE_MODE_A => "READ_FIRST", --  WRITE_FIRST, READ_FIRST or NO_CHANGE
>    WRITE_MODE_B => "READ_FIRST", --  WRITE_FIRST, READ_FIRST or NO_CHANGE
>    WRITE_WIDTH_A => 9, -- Valid values are 1,2,4,9,18 or 36
>    WRITE_WIDTH_B => 9, -- Valid values are 1,2,4,9,18 or 36

Brad,

Thanks. It looks too specific to xilinx though. When I added a clock
the brams got inferred automatically. See sample below. The
address input would have to be character# * font_row, and
the result is a 6 bit strip for that row.
0 <= character# <= 0x5f   --- ascii chars from 0x20 to 0x7f
0 <= font_row <= 11 -- row of font (6x12 font)

-Dave

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

entity fontrom is
	port (
		clk : in std_logic;
		addr : in unsigned ( 10 downto 0);
		data : out std_logic_vector ( 5 downto 0)
	);
end fontrom;

architecture rtl of fontrom is
	type small_rom is array (0 to 1151)
      of std_logic_vector(5 downto 0);
	constant this_rom : small_rom :=
	(
		0 => "000000",
		1 => "000000",
		2 => "000000",
		3 => "000000",
		4 => "000000",
		5 => "000000",
-- font data deleted for brevity, font is 6x12, ascii characters from
0x20 to 0x7f
		1145 => "111111",
		1146 => "111111",
		1147 => "111111",
		1148 => "111111",
		1149 => "111111",
		1150 => "111111",
		1151 => "111111",
		others => "000000"
	);
begin
	process(clk)
	begin
		if clk'event and clk = '1' then
			data <= this_rom(to_integer(addr));
		end if;
	end process;
end architecture rtl;

-- 
David Ashley                http://www.xdr.com/dash
Embedded linux, device drivers, system architecture

Article: 108519
Subject: Re: Help for Altera Nios II Cyclone EP1C12 evaluation kit!
From: "Jack Zkcmbcyk" <zkcmbcyk9@hotmail.com>
Date: Tue, 12 Sep 2006 12:20:05 -0400
Links: << >>  << T >>  << A >>
Hello Subroto!

    That article did it.  I was able to revise my simple project, load it 
and got my LED to start flashing.  Thanks a lot.


"Subroto Datta" <    > wrote in message 
news:tQrNg.347$e66.257@newssvr13.news.prodigy.com...
> Hi Jack,
>  This post may be useful:
> http://groups.google.com/group/comp.arch.fpga/browse_frm/thread/27cd7423127f3bbb/1fbb4ad5554ab9ca?lnk=st&q=device+and+pin+subroto&rnum=2#1fbb4ad5554ab9ca
>
> It deals with setting up Unused Pins for your projecs to the correct 
> value.
>
> Hope this helps,
> Subroto Datta
> Altera Corp.
>
> "Jack Zkcmbcyk" <zkcmbcyk9@hotmail.com> wrote in message 
> news:s5qNg.40493$8g4.523646@weber.videotron.net...
>> Hello out there!
>>
>>   I have purchased an Altera Nios II Cyclone based (EP1C12F324) evalution 
>> kit a while ago and didn't get to work with until recently.  At first I 
>> was happy to see how quickly I got the board up and running and 
>> interacting with my PC through an Ethernet LAN and serving web pages 
>> using the uClinux on-board http server.
>>
>>   Having had enough of the demo I started developping an application of 
>> my own.  I first downloaded (via the USB cable connector that provides a 
>> USB Blaster interface) a very simple code file to start flashing the 
>> LEDs. When that didn't work, I simplified the code to an even simpler 
>> test case where only one LED was involved.  After that not even working, 
>> I started combing through the documentation in search for some clues. 
>> This is when I noticed a lot of little discrepencies between the real 
>> board and the document set.
>>
>>    To this day, I still haven't been able to get a simple LED to flash 
>> (not even once).  I am getting a bit impatient with the whole thing and 
>> might just go back to a Xilinx board that is sitting around my ofice. 
>> Before I do that, I would like to know if any one out there has played 
>> with this board and might have some hints for me.
>>
>>    Thanks in advance for any tid bits.
>>
>> P.S.  When I download the code to the board using the Quartus II 
>> (6.0sp1), the download program seems all happy and returns with a 
>> "SUCCESS" message at the end of the process.  The board on the other end 
>> always contains the same NiosII implementation running uClinux!!!  Could 
>> it be that after the JTAG load is complete the FPGA resets and simply 
>> reloads the default application from the on-board configuration deice?
>>
>
> 



Article: 108520
Subject: Re: Xilkernel: Problem with mutex
From: David Ashley <dash@nowhere.net.dont.email.me>
Date: Tue, 12 Sep 2006 09:30:08 -0700
Links: << >>  << T >>  << A >>
Andreas Hofmann wrote:
> The other threads should be blocked because sleep() is called while the
> mutex is held by the sleeping thread.
> 
> Admittedly my code immediately tries to lock the mutex after releasing
> it so the other threads may have no chance to execute their lock
> request. This seems to cause the problems because after enabling
> yield()-support and calling yield() after pthread_mutex_unlock() solves
> the problem. The program does now behave as expected.
> 
> However, i do not fully understand what the kernel is doing when yield()
> is missing. Shouldn't the other threads, which do not hold the lock,
> starve while one of the thread locks the mutex over and over again?
> 
> On the other hand, the Xilinx manual clearly states that when
> pthread_mutex_unlock() is called "the thread
> that is at the head of the mutex wait queue is unblocked and
> allowed to lock the mutex.". Thus calling or omiting yield() shouldn't
> make any difference.

Andreas,

Something is wrong. As your code is written there is no way
the 2 threads can print out timestamps so close together.
It's as if your pthread locking is having no affect at all.

Did you init the mutex? Is the mutex residing on some cacheable
memory, and the cache hasn't been flushed? Check the details
of the mutex itself, there may be limitations. On blackfin dsp
mutex locking was based on their test and set instruction, which
was flawed -- you had to use external memory otherwise it didn't
work. There may be something similiar going on here.

-Dave

-- 
David Ashley                http://www.xdr.com/dash
Embedded linux, device drivers, system architecture

Article: 108521
Subject: Re: ddr with multiple users
From: David Ashley <dash@nowhere.net.dont.email.me>
Date: Tue, 12 Sep 2006 09:37:42 -0700
Links: << >>  << T >>  << A >>
Weng Tianxiang wrote:
> Hi Daniel,
> It is very interesting to learn there is a ring bus structure over
> there.

Weng,

It occured to me that your circuit was identical to the ring
buffer one. N users each had a fifo going to the DDR.
Then there was one stream coming out of the DDR, so
it's (N+1) interfaces. But then you said each user needs
its own fifo so it can store + forward data from the DDR.
So you've got 2N interfaces effectively. The new fifos are
just moved into the user's realm and not part of the DDR
controller.

My point is the same circuitry exists in both cases. You've
just exercised some creative accounting :).

-Dave

-- 
David Ashley                http://www.xdr.com/dash
Embedded linux, device drivers, system architecture

Article: 108522
Subject: Re: Xilinx ISE ver 8.2.02i is optimizing away and removing "redundant" logic - help!
From: "KJ" <Kevin.Jennings@Unisys.com>
Date: 12 Sep 2006 09:42:25 -0700
Links: << >>  << T >>  << A >>
james7uw@yahoo.ca wrote:
> >
> > > But how to indicate it
> > > is not
> > > really redundant, without using "keep" and "save" statements
> > > everywhere?
> > And this is where you start spinning your wheels (in my opinion).  Instead
> > of simply debugging the post-map sim to the source of the discrepancy you're
> > trying things based on a suspicion that is not proven.  Let's say for the
> > sake of argument that your suspicion is wrong about the removal of redundant
> > logic and that the problem is a timing issue with your testbench instead.
> > That would mean that every minute you spend chasing 'keep' and 'saves' etc.
> > was wasted time.
>
> I'm not really arguing for using those crutches; I'm seriously
> asking what to do so that I don't need them.
Like I said, what you have to do is debug the 'optomized post-map'
simulation model in the simulation environment to find out just exactly
when it differs from the original code and then backtrack through the
logic in the post-map design to find out why that is.

There really are no shortcuts to this process other than the things I
mentioned in earlier posts (like maybe the testbench is 'violating'
timing, use of things other than std_ulogic/std_logic, etc.).

>
> The "redundant" and "unused" logic terms I am copying from the mapper
> report and Xilinx documentation. The mapper report (see my
> first post) says "redundant" logic is being removed, not "unused
> logic".
> >From my reading of the Xilinx manuals I understand that "unused logic"
> means logic that is not connected to anything, so it can be removed
> (this latter is not what is happening to me).
> However, I haven't found anything in the manuals that explains what
> "redundant logic" is or how to write the code to avoid it.
A simple example of the 'redundant' logic that I was asking about is
something that one might decide to put in to avoid race conditions is
the following code which implements a transparent latch (By the way, do
not implement this in real code in an FPGA).
Q <= (en and D)          -- #1
    or (not(en) and Q)    -- #2
    or (en and Q);          --#3

The point is that #3 is a redundant logic term and any synthesis tool
will be able to recognize this and remove it.  If you remember how to
do Karnaugh maps this example is also easy enough to see it for
yourself.  If you don't know about Karnaugh maps just take my word on
it that #1 and #2 are 'logically' all you need.  Term #3 is something
that you would need to put into any actual implementation because using
only #1 and #2, although they are logically complete have a race
condition when 'en' is switching.

My whole reason for bringing this up was just to rule out the
possibility that this is what you meant by 'redundant'.  I didn't think
it was, but just wanted to confirm.  Moving on.

> I have a lot
> of identical ROMs that I use to do parallel processing; those were
> being removed in the synthesis and translate step due to not having
> clocks on them.
I don't doubt what you say but I also don't quite understand why ROMs
would be 'removed' either.  Maybe all you meant is that is that you
couldn't find specific entities in the post-map VHDL that equated to
the various 'ROMs' that you instantiated in the original code....but
that's OK, a ROM is simply an array of constants, I would expect those
to get rolled right into the logic.  I can see where targetting a
particular family might have to use logic blocks instead of embedded
memory to implement what your code says (but could use embedded memory
if you chose to implement a clocked ROM) but that doesn't mean that
that the original unclocked ROM is not synthesizable at all.

> So my mind is pretty much a blank as to what is
> meant by "redundant" logic, other than the common meaning that it
> is repetitive -- but it isn't really, of course, because I'm using them
> simultaneously for different data.
'Redundant' in this context generally means that the fitter found that
you have two equations that are logically equivalent.  An example...

d <= a or b or c;
h <= e or f or g;
....
a <= e;
b <= f;
c <= g;

The signal 'h' is redundant since it is logically equivalent to 'd'
since, although the signals appear to be different for calculating 'h',
from a logic perspective they are identical because of the 'a<= e....'
assignments.

>
> I agree that finding out what is going on is the best
> approach. Do you have any debugging tips other than comparing
> the simulation results in detail and seeing what logic calculations
> must be getting removed?
>
None, other the ones listed below and in previous posts.  Tweaking the
'no optomize' switches won't get you to the bottom of what ails your
sim.  It might just postpone the inevitable when you might find that
your design doesn't work on real hardware.

If the problem is actually in your testbench in how you generate inputs
to your design (i.e. meeting the timing requirements of the post-map
design) then this should be relatively straightforward to fix.  In
fact, this is a fairly common reason for why 'post' does not match
'pre' simulation results.

If nothing else it is probably much quicker to verify testbench timing
than to debug back through the post-map design....but that just means
you should look at that first.  If that's not the problem then you need
to debug.

> >
> > It could be that
> > - There is some bug in the translation tool
> > - Could be some setting in your build process
> > - Could be timing related (i.e. your testbench is violating the setup/hold
> > time requirements for the post-map model)
> > - Probably other things too
> >
> > In any case, treat the fully post-map model as something to debug and find
> > out the reason for the discrepancy and go from there.
>
> Thank you very much for your input. I really appreciate
> the time you are spending to try to help me.
> 
Good luck, not sure I'm helping much.

KJ


Article: 108523
Subject: Re: Xilinx ISE ver 8.2.02i is optimizing away and removing "redundant"
From: David Ashley <dash@nowhere.net.dont.email.me>
Date: Tue, 12 Sep 2006 09:47:37 -0700
Links: << >>  << T >>  << A >>
james7uw@yahoo.ca wrote:
>From my reading of the Xilinx manuals I understand that "unused logic"
> means logic that is not connected to anything, so it can be removed
> (this latter is not what is happening to me).
> However, I haven't found anything in the manuals that explains what
> "redundant logic" is or how to write the code to avoid it. I have a lot
> of identical ROMs that I use to do parallel processing; those were
> being removed in the synthesis and translate step due to not having
> clocks on them. So my mind is pretty much a blank as to what is
> meant by "redundant" logic, other than the common meaning that it
> is repetitive -- but it isn't really, of course, because I'm using them
> simultaneously for different data.

James,

Maybe there are switches to the synthesizer that would allow
turning off the optimization?

I would tend to agree that looking for bugs in the toolchain might
not be the best way to work through this.

I haven't been following this thread all along, but one thing occurs
to me. I'm new to VHDL and have settled in to an approach where
I make little incremental changes, then immediately test and verify
something didn't break. That way I can go back and the source of
the problem is obvious, because there is only a little bit of code to
examine.

In your case it's like maybe the sequence is
working, change code
working, change code
working, change code
working, change code
broken, change code  <-- it broke here but you didn't discover it
broken, change code
broken, change code
broken, change code
broken   <--- you're here

It's just a theory. But I've seen this sort of thing before. The
most recent change didn't cause the problem and in fact
couldn't have caused the problem, but it's not working.
Therefore the tools must be broken. Really the problem
occured earlier...

Sorry to intrude...

-Dave


-- 
David Ashley                http://www.xdr.com/dash
Embedded linux, device drivers, system architecture

Article: 108524
Subject: Re: Xilkernel: Problem with mutex
From: ryanrsrsrs@yahoo.com
Date: 12 Sep 2006 09:48:32 -0700
Links: << >>  << T >>  << A >>

Andreas Hofmann wrote:
> On the other hand, the Xilinx manual clearly states that when
> pthread_mutex_unlock() is called "the thread
> that is at the head of the mutex wait queue is unblocked and
> allowed to lock the mutex.". Thus calling or omiting yield() shouldn't
> make any difference.

Unblocking a thread is not the same as giving it processor time.
Assuming there are only two threads, then the unblocked thread will not
actually execute unless it has a higher priority than the current
thread, or the current thread blocks.  If the both threads have equal
priority, then the blocked thread will also run if the current thread
calls sched_yield().  And if the priorities are equal and the current
thread uses the SCHED_RR policy, then the blocked thread will also run
when the current thread's time quantum expires.  If either thread uses
the SCHED_OTHER policy then all bets are off.  Likewise, if Xilinx's
implementation is not POSIX conforming, then who knows what will happen.




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

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

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

Custom Search