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 114825

Article: 114825
Subject: Re: FPGA workstation - should I wait for Window Vista?
From: Joseph Samson <jsamson@the-company-name.com>
Date: Wed, 24 Jan 2007 16:48:27 -0500
Links: << >>  << T >>  << A >>
pbFJKD@ludd.invalid wrote:
>>which is a WINE port. One user reports some ISE 8.2 compatibility. Of 
>>course, what we really need is a Mac port of the Xilinx tools.
> 
> 
> Won't the linux-32bit version run under Mac OS X ..?
> ISE runs on FreeBSD and Mac OS X is based FreeBSD.
> 
I am in no way an expert on this topic, but my limited understanding 
(based on Google Group searches) is that Linux programs run on FreeBSD 
using the Linux compatibility layer, but the Linux compatibility layer 
doesn't really work on OS X.

---
Joe Samson
Pixel Velocity

Article: 114826
Subject: Re: FPGA clock gating ? Or how to avoid it in this case ?
From: Ben Jackson <ben@ben.com>
Date: Wed, 24 Jan 2007 15:48:49 -0600
Links: << >>  << T >>  << A >>
On 2007-01-24, Sylvain Munaut <SomeOne@SomeDomain.com> <246tnt@gmail.com> wrote:
>
> This takes a stream of continous data, and they have to be continuous,
> 1 each clock (there are pauses but very far apart) and they don't have
> "enable" on their registers. Now, the rest of my chain only can process
> 2 data in 3 cycles ...

So run the two processes in different clock domains.  Make one from the
other with a DCM so there's no long-term drift.  Then connect the two
with a fifo.

-- 
Ben Jackson AD7GD
<ben@ben.com>
http://www.ben.com/

Article: 114827
Subject: Re: Aligning data with clock
From: "bgshea" <bgshea@gmail.com>
Date: 24 Jan 2007 13:50:40 -0800
Links: << >>  << T >>  << A >>
Bill,

Is your bitstream synchronous with the input clock?

You could try sychronizing your data using two (or three) D-type FF,
such that the rising edge of the input clock, clocks the data into the
first FF, then into the second on the next rising edge. This will allow
the first FF (if the bit stream is not 100% synchronous) to stabilize
before entering the second FF before allowing to pass to the bitstream
decode locic.

You will have a 2 clock delay.

You can also use the DDR register to make the synchronized bitstream
and clock souce synchronous.

Clock the DDR register with the same input clock, tie one of the DDR's
inputs to Logic 1 and the other to 0, and also clock your bitstream
through a FF using the same input clock. Set the constraints to keep
the all that logic in the same area.

I've done this in the past for asynchronous signals and it worked okay.

You may also want to look in to the DCM, though i have less expeirence
with the DCM and there full capabilities in the Vertix 4.

Hope this helps.

--Brian

On Jan 24, 1:08 pm, Bill <seabass...@yahoo.com> wrote:
> I am using a virtex 4. I have an clock input, and another input for bitstream. What is the best way to align the rising edge of a bit to the rising edge of a clock? It needs very quick. Currently I am using IDELAY to shift the data until I notice no bit errors, but it is taking up to 500ms.


Article: 114828
Subject: Re: Does xiling cpld's need a power supply bypass cap?
From: "bgshea" <bgshea@gmail.com>
Date: 24 Jan 2007 14:16:10 -0800
Links: << >>  << T >>  << A >>
Always consult the datasheet. You may need more than 0.1uF bypass caps.
I will usually use a range from 0.01uF to 10uF and for more powerful
FPGAS up too 1000uF. This is something that can be determined using the
XPower tools from Xilinx ISE. For prototype you may not need to go
crazy on bypassing, but at a min 1 0.1uF per Power Pin as close to to
the power pin with a good low impeadance via (or three) to the ground
plane.

Also, the amount of bypassing needed will depend on the power supply
used, the routing of the power to the chip and how close it is to you
IC. If you use a switching PS you will need good high quality bypass
caps to clean out the high frequency switching noise. If the power
supply has a slow response to current spikes you will need more larger
caps to fill in where the Power supply cannot.

Keeping the PS as close to the load will always improve power quality
and also using large tracks or better yet power planes in pairs. Even
if it is a pour on the top and bottom.

Granted Xilinx CPLDs are great for low power consumption, but during
flashing, they can draw a significant load on the supplies.

--Brian

On Jan 24, 2:47 pm, Ben Jackson <b...@ben.com> wrote:
> On 2007-01-24, <imity> <> wrote:
>
> > I have previous experience with microchip pics, do I need a
> > 0.1uF bypass cap for the +/- pins?If you don't, I doubt you will even be able to program it.  The charge
> pump for the flash programming will fail.
> 
> --
> Ben Jackson AD7GD
> <b...@ben.com>http://www.ben.com/


Article: 114829
Subject: Re: Xilinx ISE 8.2
From: doug <doug@doug>
Date: Wed, 24 Jan 2007 14:32:48 -0800
Links: << >>  << T >>  << A >>
steve.lass@xilinx.com wrote:
> Doug,
> 
> If you have a case number, I can track it down and try to get you
> an answer.
> 
> Steve
> 
> "doug" <doug@doug> wrote in message 
> news:12rf4t0tknpph59@corp.supernews.com...
> 
>>jbnote wrote:
>>
>>>>Memory leaks come from sloppy programmers.  Not fixing memory leaks
>>>>comes from lazy or incompetent programmers.
>>>
>>>
>>>Even incompetent programmers can manage this. The use of valgrind
>>>[http://www.valgrind.org] will pinpoint memory leaks right to the line
>>>where the allocation was made. It runs on unmodified software. This
>>>would be, oh, one hour work maximum if you have the source.
>>>
>>>JB
>>>
>>
>>So, Austin and the other Xilinx people that monitor the board--
>>Why is Xilinx not willing to take the hour to fix a show stopper
>>problem that has existed for at least a year in at least NINE
>>versions of ISE?
>>
>>There have been 7 sevice packs issued which still have this
>>problem.  This means it is a management decision to not fix
>>things.  The fact that the service pack and the release came
>>at the same time was a very bad sign.
>>
>>On the other hand, could I get a job as a xilinx programmer,
>>or better yet, as a manager.  I have always had bosses who
>>exptected me to do things correctly.  This would be a nice
>>change.
>>
>>
> 
> 
> 
Case number 662555. CR 430822, 430823


Article: 114830
Subject: Re: ML403 board - VGA schematics - wrong pins
From: Gerhard Hoffmann <spamtrap@dk4xp.de>
Date: Wed, 24 Jan 2007 23:38:38 +0100
Links: << >>  << T >>  << A >>
On 24 Jan 2007 11:41:42 -0800, gsosar@gmail.com wrote:

>ERROR:MapLib:30 - LOC constraint L23 on PIN_L23 is invalid: No such
>site on the ...
>
>I understand that this pins labels are invalid in the FPGA of ML403
>board, and when I look for the pins in the Virtex IV datasheet I see
>that this both pins are not connected in the xc4vfx12ff668-10 FPGA.

>The BLUEpins, GREENpins, REDpins, VSYNCpin, HSYNCpin and CLOCKpin are
>right the wrong are:
>
>BLANKpin  "M24"
>SYNCpin "L23"
>
>Thanks in advance
>
>Gerardo Sosa

Hi, namesake,

On the ML403, some VGA pins are missing, IIRC there are only 5 bits per colour.
On the ML402, these pins are available. The epoxy board seems to be the same.
(I have ML402s only)

The 3 bits are not much of a loss, because the analog quality of the DAC
outputs is so sh***y that you will never see pretty eye diagrams etc if you use them 
as pseudo-analog test points for your DSP stuff (clock feedthru, overshoot...)
That hurts, because the ML402 is meant for DSP.

BTW, will the Webpack 9.1 recognize a valid full ISE 8.1 installation and work for the V4-SX35
on the ML402? (interim solution until the CDs are here)

regards, Gerhard

Article: 114831
Subject: Re: Does xiling cpld's need a power supply bypass cap?
From: <imity>
Date: Wed, 24 Jan 2007 22:56:11 -0000
Links: << >>  << T >>  << A >>
Hi there,
I have noticed that in microchip pic's the power pins are next
to each other, making it very easy to simply stick a 0.1u cap
between them. I wonder if this is the sign that a bypass
cap is required (as opposed to chips were the power pins are
furthest away, like e.g. pins 7/14 or 14/28 etc?)

"Tim Wescott" <tim@seemywebsite.com> wrote in message
news:urGdnQTweMpjDCrYnZ2dnUVZ_uOmnZ2d@web-ster.com...
> imity wrote:
> > I have previous experience with microchip pics, do I need a
> > 0.1uF bypass cap for the +/- pins?
> >
> >
> Every chip, everywhere should have bypass caps on all power pins.
>
> Period.
>
> If the manufacturer says not to do it, then you should comply, but
> reluctantly (re: Microchip Vpp line, which is driven by the programmer
> and Must Have Fast Edges).
>
> If it has more than one power pin, it should have more than one cap.
> The rule of thumb is to have one cap per power pin.  Extras never hurt.
>   If the chip designers were paying attention you'll find power and
> ground pins in pairs; you should lay out your board so you have short
> runs to the caps.  If the chip designers were _really_ paying attention
> you'll find a section of the data sheet that specifies how the bypass
> caps should be laid out.  Follow it.
>
> -- 
>
> Tim Wescott
> Wescott Design Services
> http://www.wescottdesign.com
>
> Posting from Google?  See http://cfaj.freeshell.org/google/
>
> "Applied Control Theory for Embedded Systems" came out in April.
> See details at http://www.wescottdesign.com/actfes/actfes.html



Article: 114832
Subject: Re: Xilinx ISE 8.2
From: <steve.lass@xilinx.com>
Date: Wed, 24 Jan 2007 16:06:30 -0700
Links: << >>  << T >>  << A >>
Doug,

The case was created on December 6, 2006. We reproduced the problem in-house 
and
created the CRs on December 13. This was after 9.1i was released.

CR 430822 is a memory leak and has been scheduled to be fixed in 10.1 to 
coincide with
an intiative we have to fix memory issues. We're going to try to fix CR 
430823 in 9.2.

Regarding spending an hour running Valgrind and finding all of the memory 
leaks, that might
make sense for a smaller application, but isn't possible for a multi-million 
line program that
has a large number of developers. We do use Valgrind and have spent at least 
a man year
on this resulting in many of the issues found and fixed, but not all.

Steve

"doug" <doug@doug> wrote in message 
news:12rfge2gh2ugh2c@corp.supernews.com...
> steve.lass@xilinx.com wrote:
>> Doug,
>>
>> If you have a case number, I can track it down and try to get you
>> an answer.
>>
>> Steve
>>
>> "doug" <doug@doug> wrote in message 
>> news:12rf4t0tknpph59@corp.supernews.com...
>>
>>>jbnote wrote:
>>>
>>>>>Memory leaks come from sloppy programmers.  Not fixing memory leaks
>>>>>comes from lazy or incompetent programmers.
>>>>
>>>>
>>>>Even incompetent programmers can manage this. The use of valgrind
>>>>[http://www.valgrind.org] will pinpoint memory leaks right to the line
>>>>where the allocation was made. It runs on unmodified software. This
>>>>would be, oh, one hour work maximum if you have the source.
>>>>
>>>>JB
>>>>
>>>
>>>So, Austin and the other Xilinx people that monitor the board--
>>>Why is Xilinx not willing to take the hour to fix a show stopper
>>>problem that has existed for at least a year in at least NINE
>>>versions of ISE?
>>>
>>>There have been 7 sevice packs issued which still have this
>>>problem.  This means it is a management decision to not fix
>>>things.  The fact that the service pack and the release came
>>>at the same time was a very bad sign.
>>>
>>>On the other hand, could I get a job as a xilinx programmer,
>>>or better yet, as a manager.  I have always had bosses who
>>>exptected me to do things correctly.  This would be a nice
>>>change.
>>>
>>>
>>
>>
>>
> Case number 662555. CR 430822, 430823
> 



Article: 114833
Subject: Re: Does xiling cpld's need a power supply bypass cap?
From: "Peter Alfke" <peter@xilinx.com>
Date: 24 Jan 2007 15:27:07 -0800
Links: << >>  << T >>  << A >>
No, this is just history. On the old 7400 gates and MSI parts, Vcc and
GRND were diagonally opposed, for no good reason (it actually gave max
length to the bond wires, and thus max inductance.)
One of the "Original Sins" of this industry. But remember, rise and
fall times were >10 ns !
Peter Alfke

On Jan 24, 2:56 pm, <imity> wrote:
> Hi there,
> I have noticed that in microchip pic's the power pins are next
> to each other, making it very easy to simply stick a 0.1u cap
> between them. I wonder if this is the sign that a bypass
> cap is required (as opposed to chips were the power pins are
> furthest away, like e.g. pins 7/14 or 14/28 etc?)
>
> "Tim Wescott" <t...@seemywebsite.com> wrote in messagenews:urGdnQTweMpjDCrYnZ2dnUVZ_uOmnZ2d@web-ster.com...
>
> > imity wrote:
> > > I have previous experience with microchip pics, do I need a
> > > 0.1uF bypass cap for the +/- pins?
>
> > Every chip, everywhere should have bypass caps on all power pins.
>
> > Period.
>
> > If the manufacturer says not to do it, then you should comply, but
> > reluctantly (re: Microchip Vpp line, which is driven by the programmer
> > and Must Have Fast Edges).
>
> > If it has more than one power pin, it should have more than one cap.
> > The rule of thumb is to have one cap per power pin.  Extras never hurt.
> >   If the chip designers were paying attention you'll find power and
> > ground pins in pairs; you should lay out your board so you have short
> > runs to the caps.  If the chip designers were _really_ paying attention
> > you'll find a section of the data sheet that specifies how the bypass
> > caps should be laid out.  Follow it.
>
> > --
>
> > Tim Wescott
> > Wescott Design Services
> >http://www.wescottdesign.com
>
> > Posting from Google?  Seehttp://cfaj.freeshell.org/google/
>
> > "Applied Control Theory for Embedded Systems" came out in April.
> > See details athttp://www.wescottdesign.com/actfes/actfes.html


Article: 114834
Subject: Re: FPGA workstation - should I wait for Window Vista?
From: Eric Smith <eric@brouhaha.com>
Date: 24 Jan 2007 15:38:36 -0800
Links: << >>  << T >>  << A >>
Joseph wrote:
> I wonder if anyone here are in the same situation as me.
> I am think of buying a new PC, but wondering if I should
> wait for Windows Vista become available first.

No.  Windows Vista won't do any better for FPGA development than
XP.  Likely it will just create new hassles.  Stick with what's
known to work.

Personally, I much prefer Linux.  I'm now using WebPACK 9.2i on
Fedora Core 6, and it works great, so I expect that the full ISE 9.2i
should be fine also.


Article: 114835
Subject: Re: Does xiling cpld's need a power supply bypass cap?
From: "-jg" <Jim.Granville@gmail.com>
Date: 24 Jan 2007 15:41:17 -0800
Links: << >>  << T >>  << A >>
Peter Alfke wrote:
> No, this is just history. On the old 7400 gates and MSI parts, Vcc and
> GRND were diagonally opposed, for no good reason (it actually gave max
> length to the bond wires, and thus max inductance.)
> One of the "Original Sins" of this industry. But remember, rise and
> fall times were >10 ns !
> Peter Alfke

The spin I heard, for the reason for corner pins, was to allow better
Power Supply
grid layouts. Yes, even using AC mains terminology & thinking  :)

In those days, multi-layer PCBs were rare, and WIDE traces were
also needed, to handle the Amps needed on a card with many TTL devices.
So, no trace-between-pins fancy stuff on the Supply traces.
Some cards used physical BUS Rails, to run the power/gnd supplies.

-jg


Article: 114836
Subject: General Number Field Sieve in FPGA
From: Thomas Langås <tlan@stud.ntnu.no>
Date: Wed, 24 Jan 2007 23:58:42 +0000 (UTC)
Links: << >>  << T >>  << A >>
Hi!

I've been trying to find some resources on the subject, but can't seem
to find much.  Has this been done?  And to what extent?  Is it
doable, or is this a very hard task?

If anyone could point me in any direction with more resources 
on this subject, I would be happy.  In advance, thanks!


-- 
Thomas

Article: 114837
Subject: Re: Aligning data with clock
From: Bill <-@-.com>
Date: Wed, 24 Jan 2007 16:13:56 -0800
Links: << >>  << T >>  << A >>
The input clock and input bitstream is probably not synchronized most of the time, and I need to synchronize it.

Article: 114838
Subject: Re: General Number Field Sieve in FPGA
From: Thomas Womack <twomack@chiark.greenend.org.uk>
Date: 25 Jan 2007 01:13:10 +0000 (GMT)
Links: << >>  << T >>  << A >>
In article <ep8rri$gbs$1@orkan.itea.ntnu.no>,
Thomas Langås  <tlan@stud.ntnu.no> wrote:
>Hi!
>
>I've been trying to find some resources on the subject, but can't seem
>to find much.  Has this been done?  And to what extent?  Is it
>doable, or is this a very hard task?

'General Number Field Sieve' is more a system than a task, simply breaking
down the task of factoring a big number into implementable chunks is quite
a job.  The place to look is probably the SHARCS conference reports (Special-
purpose Hardware for Attacking Cryptographic Systems): 
http://www.ruhr-uni-bochum.de/itsc/tanja/SHARCS has links to the slides for
the 2005 and 2006 conferences, the VAMPIRE project of ECRYPT is source of
much of the funding.

As far as I know, the status is:

* people have implemented ECM on large FPGAs, it's faster than a P4 but not
  faster-per-dollar

* the designs people have proposed for lattice-sieving and linear algebra
  are all special-structure hardware with a structure very different from
  FPGAs, particularly in terms of memory per logic-element; it's not
  clear they could be helpfully fitted into FPGA.  In any
  case they tend to propose rather peculiar external memory
  configurations (huge fast memories plus large extremely-fast memories)
  so you'd have to build costly custom boards before being able to test
  anything.

* to do anything very interesting is likely to require hardware costs and
  engineering effort well beyond the casual.

Tom

Article: 114839
Subject: Re: uClinux on Spartan 3
From: John Williams <jwilliams@itee.uq.edu.au>
Date: Thu, 25 Jan 2007 11:26:54 +1000
Links: << >>  << T >>  << A >>
Hi Lancer,

Lancer wrote:

> I want to install uClinux on a Spartan 3 XC3S1000.
> Now I need auto-config.in file to compile uClinux distro!
> But...How to generate this file "auto-config.in"?
> What I need?
> I'm using EDK 8.1i sp2 on Windows XP.

Take a look at developer.petalogix.com - there are quick start guides, 
complete documentation, tutorials and all sort of things to get you going.

If you take a look at the MSS file in some of the reference designs we 
provide (e.g. S3E-1600 or -500 boards), you'll see how the "OS" section 
defines which memory device to use, the IO peripherals and so on.

The auto-config.in file is generated during the EDK project build phase 
(libgen).  Then there is a petalinux helper script called 
petalinux-copy-autoconfig that automatically copies it across from the 
EDK HW directory into the correct place in the uClinux SW tree.

One thing to note, Windows is not a supported environment for building 
Microblaze / uClinux systems.  It may be one day, but for now you'll 
need a Linux box or virtual machine to build the embedded Linux software.

Regards,

Regards,

John

Article: 114840
Subject: Re: Aligning data with clock
From: "Peter Alfke" <alfke@sbcglobal.net>
Date: 24 Jan 2007 19:14:38 -0800
Links: << >>  << T >>  << A >>
The beauty of IDELAY is that you do not need any super-fast clock like
the previous post implies.
There really is no need to have multi-millisecond delays. You can
increment or decrement IDELAY as fast as you want. Your acquisition
time is governed by how long it takes you to make a decision. For 500
ms you must have evaluated many thousand bits before you ventured a
small change. It's entirely your decision. If you are in a hurry, you
could be thousand times faster.
Peter Alfke

On Jan 24, 4:13 pm, Bill <-...@-.com> wrote:
> The input clock and input bitstream is probably not synchronized most of the time, and I need to synchronize it.


Article: 114841
Subject: Re: Aligning data with clock
From: John_H <newsgroup@johnhandwork.com>
Date: Thu, 25 Jan 2007 05:15:51 GMT
Links: << >>  << T >>  << A >>
Bill wrote:
> The input clock and input bitstream is probably not synchronized most of the time, and I need to synchronize it.

If the data and clock aren't synchronized most of the time, how is 
adjusting the delays going to help?  Or do you mean "not aligning the 
sampling clock to the center of the bit" rather than "exact same 
frequency/bit rate, just an unknown phase?"  Synchronous items are at 
the same frequency.  Precisely.  If there's a phase/freq modulation on 
one synchronous item, the same phase/freq modulation should be on the other.

What are the data and clock rates you're working with?

Is it a high speed application where the data is a constant bit rate but 
you only have a solid asynchronous clock to work from?  Do you have 
multiple bits to synchronize?  If so, I'll point out the App note.

Article: 114842
Subject: virtex II pro development board(xupv2p) : maximum current driving strength from hirose connector
From: yashu <chethachetha@yahoo.com>
Date: Wed, 24 Jan 2007 22:41:16 -0800
Links: << >>  << T >>  << A >>
hello every body,

currently i am masters student working on the xilinx virtex II pro board (xupv2p).

I have to design a daughter board with four telephone interfaces(slics from silver telecom, Ag1170) and a quad channel codec (National semi con's TP3094).

The daughter board is supposed to connect to the development board through the 100 pin hirose connector provided on the board.

The above mentioned CODEC requires 50mA of current at 5V and each SLIC requires 1A in the worst case at 3.3V. I need help about the power supply of the daughter board.

Can the power supply present on the development board deliver such huge current. If not how much current can it deliver or do i have to design a separate power supply for the daughter board.

Please help me on this issue

Thanking you all yashu

Article: 114843
Subject: Re: Xilinx ISE 8.2
From: Andreas Ehliar <ehliar@lysator.liu.se>
Date: Thu, 25 Jan 2007 07:54:19 +0000 (UTC)
Links: << >>  << T >>  << A >>
On 2007-01-23, bgshea <bgshea@gmail.com> wrote:
> So, I ask Martin, as he posted a method of using build scripts, if you
> could even if in part, post some of what you use, that might benefit
> the community here.  I would certainly build on those scripts and post
> them back.

Hi, I wrote some Makefiles that we use in a course here. The entire
lab skeleton is actually available for download but I have uploaded
just the Makefiles to my homepage if you are interested:

http://www.da.isy.liu.se/~ehliar/stuff/

It is not perfect but it works ok for me and most students in the
course seem to think so as well :) They have been tested in both
Linux and cygwin.

I wrote the Makefiles for the following reasons:
* Since they are text based, revision control is easy
* We can avoid the (for now) unstable Project Navigator
* Building a project will not spew lots of temporary files
  in the project directory. (They will end up in the synthdir
  directory.)

The Makefile has been tested with ISE 8.1 and 8.2.

I also have a small shell script which I use to build small projects where
I haven't bothered to create a Makefile. That is also available on the
web page. It is heavily inspired by the Makefile mentioned above.


Some things which would be nice to be able to handle:

* VHDL libraries (not everything should end up in work)
* Don't recompile all files when starting a simulation target
* Mixed VHDL/Verilog in the Makefiles


Tips and tricks for these Makefiles will be gratefully received :)
I know that they are a bit ugly at the moment.

/Andreas

Article: 114844
Subject: Re: How to make a clock delay?
From: David R Brooks <davebXXX@iinet.net.au>
Date: Thu, 25 Jan 2007 01:03:19 -0800
Links: << >>  << T >>  << A >>
anesserm wrote:
>> Only if you disable logic optomizations in your synthesis tool....which in
>> most cases is generally 'not' what you want to do.  PLL (Altera), DCM
>> (Xilinx) or re-examining the design as to why you think you need a delayed
>> clock is a better approach.
> 
> Is there a way to fool the optimizer?
> 
Sometimes you can put a "keep" attribute on the intermediate signals.
But this has to be a very bad way of doing things: your design will 
probably not work on a different device, may be sensitive to 
temperature, supply voltage, moon's phase, etc.

Article: 114845
Subject: CONDITION VARIABLES IN XILKERNEL
From: "Pablo" <pbantunez@gmail.com>
Date: 25 Jan 2007 01:16:55 -0800
Links: << >>  << T >>  << A >>
Does Xilinx microkernel (xilkernel) support for Condition Variables in
Pthread?. That is, can I use code such as:

pthread_cond_init
pthread_cond_wait

Thanks for your help.

Pablo Ant=FAnez


Article: 114846
Subject: Re: Xilinx ISE 8.2
From: Sean Durkin <news_jan07@durkin.de>
Date: Thu, 25 Jan 2007 10:56:30 +0100
Links: << >>  << T >>  << A >>
Hi Steve,

first of all, I appreciate your comments.  I think I can say that actual
Xilinx employees with an insight reading and posting here is really a
"feature" most of us appreciate. :)

steve.lass@xilinx.com wrote:
> Actually, for the 9.1i release, feature freeze was in June 2006 and the 
> release to manufacturing was in December. We spend about 6 months fixing bugs
> and improving quality.
Then why do you release the first service pack days after the software?
Why not just push back the release for a few weeks and ship something
that is usable right away?
I can't comment on other customers, but in our case it's not like we're
desperately waiting for new ISE releases. It's not like we're waiting
for those new features (because we usually don't have any idea what
these new features might be, except the usual promised 30% increase in
speed). It's not like we're waiting for bugs to be fixed... we have our
workarounds, because we can't just wait until Xilinx fixes it, we need a
solution now.
It really is of no importance or relevance to us when a new ISE is
coming out. When it's there, it's there, and we'll give it a try to see
what's been changed/improved, hoping that some of the issues I had with
earlier versions are resolved.
As stated in my earlier post: I know of no other EDA software vendor who
handles the release cycle like Xilinx does (and Xilinx didn't always do
it like that either). And you really can't claim other vendors don't
have the same problems with dependencies between different products and
3rd party software etc.

> Yes, 7.1i had a new database and 8.1i had a new ProjNav GUI. The
> database was created in 1990 and needed to be rewritten and so did the
> GUI.
I agree. The switch to QT (or whatever it is you're using now) was long
overdue and made the GUI finally usable under Linux (be gone, WindU!).

> It's not as simple as saying we will release when its ready because of other
> dependencies. We need to make sure all of our other software products
> (ChipScope, PlanAhead, System Generator, EDK, etc.), all of our IP, and
> 3rd party tools all work together.
Yes, you have to, but they don't. A new EDK version is usually not
released for weeks or months after the corresponding ISE, so in most
cases I can't use the latest ISE anyway because it won't work with my
older EDK. Same applies for some IP (like MiG, for example): Those
usually don't work right away as well, but they will be released
sometime later in a version compatible with the latest ISE (BTW, the
later IP-updates are a friggin' 600MB in size, helloooo?). So in what
way does the fixed (and too early, quality-wise) release date help the
integration of other products, IP and 3rd party tools?

> Defining a release date and sticking to that
> date is the best way to accomplish this. So instead, we define a feature 
> freeze date. If a feature can't be done by that date, it gets pushed to the next 
> release.
I don't really understand this. Feature freeze date, yes. But why a
fixed release date?
Just to compare, look at the Debian Linux project (or any other bigger
open source project). There's a feature freeze date, and a projected
release date. At the feature freeze date, there's a certain number of
release-critical bugs, and a number of not-so critical bugs. The release
date usually will be pushed back until the number of release-critical
bugs drops below a certain threshold, or is 0. Only then is it more or
less guaranteed to work when it's released.
I had assumed it is similar at Xilinx, but with a release date fixed
well in advance, this can never work.
I realize that software can never be bug-free, but that's beside the
point. Why release a software that you *KNOW* has a bunch of critical
bugs (you already have the first service pack ready!), just so the
release date fits your regular release cycle?
3rd party tools as well as your other products and IPs are being worked
on long before ISE is released, so the actual release date is of no
relevance to those either.

> I agree with all of this. To be honest, no customers told us they were using
> partial reconfig in ISE 4 - 7, so we did not make it a priority.
Well, I did. John Williams initiated a whole separate mailing list just
for the topic. The subject regularly pops up in this very newsgroup. So
you can't say noone told you. But I guess noone "important" told you,
since all the people who used it until very recently were students or
researchers, not high-volume-customers. But I totally understand that,
this is not meant to be critizism. I guess it's pretty complicated to
implement it in the software, and you can't expect a huge company doing
all the work to fix it just for a handful of academic customers. Again,
this is not meant to be sarcastic, I wouldn't do it any other way if I
were in charge at Xilinx.

The thing that bugs me is just that if it's not a priority for you to
fix, why not just tell people? From ISE4 through ISE7, I was told "This
is going to be fixed in the next service pack/release", but it never
was. And after every new release, I invested a couple of days "porting"
my designs to the new software, only to find out that it's still not
working. A lot of time I could've spent smelling the roses or hugging
trees or generally doing something useful if only I would've been told
what's up right away.

> Don't be shy about reporting bugs to us and don't
> complain about bugs not being fixed if you don't report them.
Most of the time I run into known problems. I first check your website
and find that someone else has already reported it and "it will be fixed
in the next service pack". But if you say duplicate reports might help
prioritizing things, I'll start reporting.

> Steve Lass
> One of those Marketing guys. 
I apologize if my post read like I had something against marketing. :)

It's just my experience that priorities and ways of thinking simply
differ between "techies" and "marketing". I see it in our projects, too.
Sometimes we have to implement features that are complete nonsense that
no customer will ever use, but it looks good in the brochure and the
competition has it in their brochures as well, so it's gotta be
implemented; just in case a crazy customer decides to check if the
brochure is totally accurate (which occasionally does happen)...

I've had some interesting (and funny) chats with engineers from the
competition at trade shows about the very same subject, and it's the
same everywhere. The problem is that the people who decide which product
will be bought often aren't "techies" and hence rely only on the
brochures to compare, so it's gotta be in there. The question is who
started it in the first place, who put it in the first brochure. :)

And I'm not so sure how many of the new features are actually things
customers need or want. I can't imagine any customer requesting the
format of the project files to be switched to binary, or requesting the
feature to send detailed information about my designs to Xilinx after
synthesis... And I don't think a lot of customers need the "feature" of
a new ISE release for christmas every year.

cu,
Sean

-- 
My email address is only valid until the end of the month.
Go figure what the address is going to be after that...

Article: 114847
Subject: Re: Xilinx ISE 8.2
From: Martin Thompson <martin.j.thompson@trw.com>
Date: Thu, 25 Jan 2007 09:58:56 +0000
Links: << >>  << T >>  << A >>
Eric Smith <eric@brouhaha.com> writes:

> Martin Thompson <martin.j.thompson@trw.com> writes:
>> The best development environment I have ever used for Xilinx devices
>> is Emacs (with vhdl-mode) and a command-line build script :-)
>
> I do my editing in Emacs, but I despise vhdl-mode.  I normally use
> the GUI for everything but editing.
>

Interesting - could you say any more about what makes vhdl-mode so
bad?  My experience has been more of people thinking Emacs sucks, but
they wish their editor did all that vhdl-mode does!

Thanks,
Martin

-- 
martin.j.thompson@trw.com 
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.conekt.net/electronics.html

   

Article: 114848
Subject: On-chip randomness (V4FX)
From: jetmarc@hotmail.com
Date: 25 Jan 2007 02:15:37 -0800
Links: << >>  << T >>  << A >>
Hi,

I'm working on a V4FX design that contains cryptographic primitives.

To secure the system against an expected threat, it is necessary to
produce a different seed for every session. The seed doesn't have to be
random nor unpredictable, but the same seed should never be used more
than once.

The system contains non-volatile storage for the purpose of generating
a non-repeating seed.  However the storage is external to the V4FX. An
attacker could isolate the V4FX and make it repeat a seed by replaying
the external stimulus (as recorded from a previous session).

To counter this threat, I wish to mix the externally acquired seed with
on-chip generated "randomness". That would result in a different seed
even during a stimulus replay attack. I know that chips are designed to
behave as repeatable as possible, and I'm asking for quite the
opposite. But at least I want to try, given that even a small amount of
entropy can discourage an attack.

For example I'm thinking about an oscillating combinatorial loop,
sampled during the regular clock events. I expect the output would vary
(at least a little bit) with temperature, supply voltage and perhaps
moon phase.

What other V4FX resources could be (mis)used for this purpose? I'd like
to use two or three unrelated methods.

If you have any suggestion or experience, I'd highly appreciate your
input.

Regards,
Marc


Article: 114849
Subject: Re: uClinux on Spartan 3
From: "Lancer" <peppeunz@gmail.com>
Date: 25 Jan 2007 02:50:53 -0800
Links: << >>  << T >>  << A >>
On 25 Gen, 02:26, John Williams <jwilli...@itee.uq.edu.au> wrote:

First of all, thanks for your reply (and sorry for my english, I'm an
italian student...)

> Take a look at developer.petalogix.com - there are quick start guides,
> complete documentation, tutorials and all sort of things to get you going.

...but petalogix provide petalinux documentations, isn't it?

> If you take a look at the MSS file in some of the reference designs we
> provide (e.g. S3E-1600 or -500 boards), you'll see how the "OS" section
> defines which memory device to use, the IO peripherals and so on.

I've downloaded examples at this link:
http://www.petalogix.com/resources/reference_designs/xilinx

> The auto-config.in file is generated during the EDK project build phase
> (libgen).  Then there is a petalinux helper script called
> petalinux-copy-autoconfig that automatically copies it across from the
> EDK HW directory into the correct place in the uClinux SW tree.
>
> One thing to note, Windows is not a supported environment for building
> Microblaze / uClinux systems.  It may be one day, but for now you'll
> need a Linux box or virtual machine to build the embedded Linux software.

I'm using Slack 11 machine to build uClinux, and Win XP SP2 machine
with Xilinx tools to build Microblaze project.
When I begin a project, I specify the repository path
(edk_user_repository) that I've downloaded there:
http://www.petalogix.com/resources/downloads/uclinux-bsp   (BSP uClinux
package)
Then I build my Microblaze (for my Spartan 3 XC3S1000) e then I specify
in "Software Platform Settings" the uClinux OS.
Then I launch the libgen, and always I obtain this error message:

"ERROR:MDT - ERROR FROM TCL:- uclinux () - ERROR :: No MAIN_MEMORY
peripheral or
   START/SIZE parameters specified
       while executing
   "error "ERROR :: ${msg}""
       (procedure "do_manual_memory_setup" line 14)
       invoked from within
   "do_manual_memory_setup $config_file $os_handle $param_prefix
$config_prefix"
       (procedure "do_memory_setup" line 14)
       invoked from within
   "do_memory_setup $config_file $os_handle "MAIN_MEMORY"
CONFIG_XILINX_ERAM"
       (procedure "::sw_uclinux_v1_00_d::generate" line 22)
       invoked from within
   "::sw_uclinux_v1_00_d::generate 42422920"

Copying Library Files ...

ERROR:MDT - Error while running "generate" for processor
microblaze_0...

make: *** [microblaze_0/lib/libxil.a] Error 2

Done!"


What does it means?
Thank you very much

Regards




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