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 117425

Article: 117425
Subject: Re: Another simple DCM question
From: Austin Lesea <austin@xilinx.com>
Date: Fri, 30 Mar 2007 14:05:11 -0700
Links: << >>  << T >>  << A >>
Or,

Use an inverted version of the clock to a BUFGMUX, and when it isn't
right, switch the BUFGMUX to the other clock input.

Austin

Article: 117426
Subject: Re: (Xilinx) OPB watchdog timer fails to release RESET
From: "radarman" <jshamlet@gmail.com>
Date: 30 Mar 2007 14:14:19 -0700
Links: << >>  << T >>  << A >>
On Mar 28, 11:04 am, "Alan Nishioka" <a...@nishioka.com> wrote:
> On Mar 27, 11:14 am, "radarman" <jsham...@gmail.com> wrote:
>
> > The watchdog timer otherwise works fine. I can start/stop/reset the
> > timer with no problem. The trouble is that when the watchdog timer
> > DOES cause a reset, it won't release the reset line, which was
> > effectively locking up the system. It did NOT respond like the
> > datasheet.
>
> The source in /cygdrive/c/EDK81/hw/XilinxProcessorIPLib/pcores/
> opb_timebase_wdt_v1_00_a/hdl/vhdl/timebase_wdt_core.vhd says that the
> state machine will only leave the ExpiredTwice state on OPB_Rst.
>
> So you need an OPB_Rst to release the WDT_Reset line.
>
> Alan Nishioka

After I inserted the edge detector, the OPB reset was being released.
The trouble is that the watchdog timer refused to release ITS reset
output, even after OPB Reset cycled..

The reset controller is operating from the input clock, not the DCM
clock. It has to, in order to bring the dcm out of reset. The clock on
this board is a bit difficult, because it's not free-running at
configuration time.

Ultimately, the problem was solved another way. We have an async reset
line going to another FPGA that can handle the problem. If the
communications link goes down, the controller will just hit the "reset
button"


Article: 117427
Subject: Re: CycloneII altlvds_rx
From: Ben Twijnstra <ben.twijnstra@gmail.com>
Date: Fri, 30 Mar 2007 23:17:01 +0200
Links: << >>  << T >>  << A >>
Dolphin wrote:

> Rob,
> 
> If I take a look in the timing analysis then I see that not all my
> LVDS pins have the same setup time. I am worried that this causes the
> problem.
> 0.120 ns TA1

...

> 5.128 ns TE2
> 5.121 ns TE2

This definitely calls for a Tsu constraint. Cyclone II devices have
programmable input delay chains (in order to make Tsu/Th tradeoffs), and it
looks like these chains have been set to 0 on TA, and to 7 on the other
ones. 

You can find the actual Input Delay Chain values if, in the compilation
report, you for to the fitter report, Resource section, and then expand
the "Input pins" section. It's in one of the columns there.

I find that Quartus by default (i.e. unconstrained) sets only one bit in a
bus with delay tap 0 and the rest at 7. It's not really a Quartus 'bug',
according to someone at Altera - the mismatch is there in order to show up
and remind people to constrain their input buses...

I suggest you set Tsu for these inputs to 0.4ns and recompile. You may get
some errors, but at least the delay chain will be set to 0. Then raise the
Tsu to a little more than the largest Tsu you find after the initial
compilation and you should be all set.

Hope this helps a bit.

Best regards,



Ben


Article: 117428
Subject: Re: Spartan 3E Not enough block ram.
From: "Daniel S." <digitalmastrmind_no_spam@hotmail.com>
Date: Fri, 30 Mar 2007 17:26:15 -0400
Links: << >>  << T >>  << A >>
Ken Soon wrote:
> 
> Well, the reference design data file did say that the purpose of the wrapper
> is to minimize the number of external interconnect required by the scaler so
> that it can fit into a realistic target device. My wrapper has instantiates
> 2 sequential lookup tables and 6 horizontal coefficient tables and 3
> vertical coefficient tables.

So your scaler uses an FIR filter for scaling with 3x6 grid sampling and 
the coefficient sets for each available scaling factor are stored in 
BRAMs... yup, this can cost a handful of BRAMs - and you will have a hard 
time dumping these or your video line buffers in DRAMs.

You really need to look into exactly what is consuming how many BRAMs how 
and why as I suggested in my previous message. Coefficient tables and video 
line buffers will be difficult to shift into DRAM: you will need some BRAMs 
to buffer data to/from the DRAMs and are not going to be any better off if 
you end up with as many FIFO BRAMs as you originally needed plain BRAMs for 
the initial design... actually, you will be worse off given the extra 
glue-logic.

If coefficient tables are eating up those ~40 BRAMs, you may be in serious 
trouble since DRAMs cannot be programmed by a bitfile - you will need some 
method of initializing the DRAM. Analyze the design carefully to see how 
the BRAMs are used, there may be a few reduction tricks that can be applied 
to spare a few.

> Hmm, I guess I will be looking at other designs which have interface with
> the DDR SDRAM controller and from there, try to understand the interface and
> I hope to be able to do the same for my video scaler design.

Even if you find a suitable DRAM controller to paste into your design 
overnight, reworking your scaler to work with it will require some 
significant effort.

> Thanks alot for checking for me that the code is a BRAM inference wrapper
> for a dual port RAM. with independently clocked read and write ports.

The coding style is obvious to anyone who has spent any significant amount 
of time getting 'fancy' BRAM inferences to work. The independent read and 
write port BRAM, independently clocked or not, is the easiest to get right 
to the point of being nearly impossible to mess up.

> Yeh and sadly the evaluation board doesn't come with a dram interface
> instruction guides or somewhat. IT only comes with the pin numbers and a few
> brief description, alas.

If you want to interface DRAMs, I suggest you start by looking up the 
datasheets for your board's DRAMs. At the very least, it will give you an 
idea of how kludgey a DRAM interface can be. The road to a fast and stable 
DRAM interface is full of bumpy quirks.

Article: 117429
Subject: Re: Another simple DCM question
From: "Gabor" <gabor@alacron.com>
Date: 30 Mar 2007 14:43:16 -0700
Links: << >>  << T >>  << A >>
On Mar 30, 5:05 pm, Austin Lesea <aus...@xilinx.com> wrote:
> Or,
>
> Use an inverted version of the clock to a BUFGMUX, and when it isn't
> right, switch the BUFGMUX to the other clock input.
>
> Austin


I think this takes the BUFGMUX out of the feedback loop and you
would then lose your best phase relationship.

Normally a BUFGMUX (used as a BUFG) is connected from the CLK0
output of the DCM to the feedback pin to remove BUFG delay from
the clock.  You could use a second BUFGMUX on CLK0 and CLK180
outputs with a switch to select the one you want, but the routing
delays to the two BUFGMUXes might have a small difference.


Article: 117430
Subject: Re: shift register with distributed ram
From: Ray Andraka <ray@andraka.com>
Date: Fri, 30 Mar 2007 17:46:13 -0400
Links: << >>  << T >>  << A >>
John McCaskill wrote:


> The SLR16s have two outputs that can be used for serial to parallel
> shifters, the Q15 for cascading, and the selectable output.  I finally
> found the article that describes how to use an SRL plus a FF to build
> a 6 bit per slice serial to parallel shifter. It is by Kris Chaplin,
> not Ken Chapman like I had been thinking.
> 

This works nicely as long as you don't need speed.  The direct outputs 
(ie not through the slice register) from the SRL16 are quite slow.  Even 
just routing the SRL output directly to a flip-flop in another slice 
yields a huge minimum clock hit.

Article: 117431
Subject: Re: ModelSim VHDL Pragmas
From: "Gabor" <gabor@alacron.com>
Date: 30 Mar 2007 14:48:47 -0700
Links: << >>  << T >>  << A >>
On Mar 30, 4:11 pm, "Andy Peters" <goo...@latke.net> wrote:
> On Mar 30, 12:00 pm, "Peter Klemperer" <ftpe...@gmail.com> wrote:
>
> > Hi All,
>
> > In one of my VHDL designs I have a section of code that I want
> > different versions for synthesis than for simulation.  Currently I
> > just comment out one section and uncomment the other, but I had a
> > rather embarassing incident yesterday where I forgot to change the
> > comments before beginning synthesis.  Ooops.
>
> > I searched around a bit, but haven't found a definitive solution other
> > than using a preprocessor.  I don't think that this is a satisfactory
> > solution.  Eliminating the simulation only code is simple, the --
> > synthesis translate_off/on pragmas works great.  Is there an
> > equivalent for modelsim?
>
> Generate statements?
>
> -a


That's a solution to reducing the changes needed, but it doesn't fully
automate the changes unless there's a way to detect which compiler is
being used - Modelsim or synthesis.  If you had a way to put your
synthesis-specific code at the top of the file, you could use the -
line
option for vcom in Modelsim to start compilation after the synthesis
only section, but I don't see this as very practical.  If you were
using Verilog I could think of a few ways to deal with this...
In Verilog for example you can define a macro on the command line
and then use `ifdef `else to exclude code that is for synthesis only.


Article: 117432
Subject: Re: shift register with distributed ram
From: "Peter Alfke" <peter@xilinx.com>
Date: 30 Mar 2007 15:13:53 -0700
Links: << >>  << T >>  << A >>
 "Slow" (and "fast") are very nebulous statements. Losing a few
nanoseconds in an interconnect is o.k. when the clock runs at 100 MHz,
or even a bit faster...
Peter Alfke

On Mar 30, 2:46 pm, Ray Andraka <r...@andraka.com> wrote:
> John McCaskill wrote:
> > The SLR16s have two outputs that can be used for serial to parallel
> > shifters, the Q15 for cascading, and the selectable output.  I finally
> > found the article that describes how to use an SRL plus a FF to build
> > a 6 bit per slice serial to parallel shifter. It is by Kris Chaplin,
> > not Ken Chapman like I had been thinking.
>
> This works nicely as long as you don't need speed.  The direct outputs
> (ie not through the slice register) from the SRL16 are quite slow.  Even
> just routing the SRL output directly to a flip-flop in another slice
> yields a huge minimum clock hit.



Article: 117433
Subject: Re: RISC implementation questions
From: "Daniel S." <digitalmastrmind_no_spam@hotmail.com>
Date: Fri, 30 Mar 2007 18:22:05 -0400
Links: << >>  << T >>  << A >>
Patrick wrote:
> I am talking about the backend, the problem I have is quite simple.
> I have 2 execution units for arithmetic and logic, 1 memory access
> unit (Load/Store) and a mutliply unit.
> Obviously all of these 4 Units would like to write data at some point
> to the registers.
> So when i only have two write ports to the register file, then I have
> a problem if
> all 4 Units wanna write data into my regfile, right?
> 
> So I wonder how this is actually relised in a RISC architecture when
> there are more units to write to the regfile than I have writeports available

On an ASIC, there is no FPGA-esque restriction on how many write ports a 
register file / SRAM can have. If a given CPU's execution unit may produce 
up to six register results in any one cycle, the register file will have as 
many as six write ports.

For an FPGA-based implementation, there is a simple (but slow) way to 
simulate an ASIC-style register file / multi-ported SRAM: implement the 
register file as actual registers instead of dual-ported memories, this way 
you can read and write all registers at once if you want to but you will 
need read and write muxes to route your M write ports to your K registers 
and out your N read ports... huge and rather slow.

If you want to keep your logic simple, you can simply freeze the execution 
pipeline on cycles where there are pending register writes.

My third suggestion is to implement a register write queue (as little as 
two entries per port could be enough) and freeze the pipeline only when the 
queue is full - if an instruction depends on queued registers, fetch the 
relevant values from the queues instead of the registers.

Article: 117434
Subject: Re: A suggestion for a new input interface for functions in VHDL:
From: Jim Lewis <jim@synthworks.com>
Date: Fri, 30 Mar 2007 14:52:55 -0800
Links: << >>  << T >>  << A >>
Daniel S. & Weng
> Since most of the new syntaxes from this thread come from VHDL 200X 
> language extension drafts, chances are that none of these new extensions 
> will be included/supported in/by standard Xilinx synthesis 
> libraries/tools until the next ISE after (and probably only if) they 
> become official.

Accellera VHDL 3.0, is an Accellera Standardized that other
vendors are currently implementing to.  It was approved in
July 2006.

Hence, it is official so kick your vendor to get it implemented.
The sooner you kick Xilinx, the sooner they will update
their tools.

Best Regards,
Jim

Article: 117435
Subject: Re: xilinx ise/edk/modelsim - what does compilation really do?
From: David R Brooks <davebXXX@iinet.net.au>
Date: Fri, 30 Mar 2007 15:06:56 -0800
Links: << >>  << T >>  << A >>
Gabor wrote:
> On Mar 30, 8:47 am, "Brad Parker" <b...@heeltoe.com> wrote:
>> I have some questions about xilinx ISE/EDK and  modelsim simulation.
>> I'm looking for advice/pointers.
>>
>> I'm an reformed software guy, and my perspective is from using a lot
>> of open source tools
>> like linux and gcc.  I've done a lot of linux kernel work so I'm
>> familiar with big project trees, makefiles, etc...
>>
>> I'm sort of suprised by the state of EDA tools.  I've recently spent a
>> little time working with ISE & EDK
>> and trying to get model to simulate a virtex 4.
>>
>> [To me, it seems like all the tools have their fingers in all the
>> files and things are spread all out and
>> it's *really* difficult sometimes to debug when a flow does not work
>> or modelsim gives you a cryptic
>> messages like "need to recompile blah because foo has been updated".]
>>
>> I've spent a lot of time with iverilog (icarus) and cver, using
>> gtkwave and makefiles.  This is a simple
>> flow which works very reliably.  But when I plug the files into ISE I
>> end up with a large tree of who knows
>> what (well, I do know, but you get the point).  And when you add
>> modelsim, it just gets worse.
>>
>> Is there any place (a boot, website,etc...) which describes what
>> happens when I "compile libraries"
>> in ISE or EDK?  what get produced?  are the files in a standard form?
>> why do they need to be compiled?
>> (I'm guessing that somehow magic private behavior models are secretly
>> passed in a machine readable form
>> to modelsim)
>>
>> (and why on earth the "workspace" library called "work" on the disk,
>> why not "workspace"? is it just me?)
>>
>> -brad
> 
> 
> Brad,
> 
> Welcome to our world.  The short answer is that the software guys that
> write C compilers and operating systems actually use their software
> and
> to some extent understand how others use it, at least as that relates
> to developing software.  The guys who write EDA software have no clue
> what hardware design is all about for the most part.
> 
> As for what compilation does, this is all Modelsim, not Xilinx.  I
> doubt
> you'll get very far trying to decipher the compiled code unless you
> want
> a job at Mentor :)
> 
> In my opinion the Modelsim simulator runs remarkably fast considering
> what has to happen under the hood in your serial execution processor.
> There is no way an interpreted (as opposed to compiled) simulation
> engine could keep up with this.
> 
One important difference between VHDL & C (for example) is that 
"entities", unlike C headers, are referenced in their compiled form, not 
just copied in as source. So they must have been compiled (strictly, 
analysed) before any other unit which uses them. There are (with 
ModelSim) two ways to go about this:
1. Use vmake - ModelSim's tool which writes a makefile for you, 
respecting the order of things.
2. Compile in 2 steps, first compile everything using the -skip ab 
option (ie skip architectures & bodies), then repeat using the -just ab 
option (ie just those). That way, all entities (& other stuff) are done 
before they are needed.

Also, remember that every entity can have more than one architecture: 
this is as though you could have several implementations of a single C 
module, all valid together. Of course, the system needs a rule to choose 
which it shall use. This rule is called "binding".

"work" is the default library name, as defined by VHDL. But it's just 
that: the default. Use vlib to set up new libraries to your liking, & 
override the defaults in the vcom command line.

Article: 117436
Subject: Re: ModelSim VHDL Pragmas
From: David R Brooks <davebXXX@iinet.net.au>
Date: Fri, 30 Mar 2007 15:08:26 -0800
Links: << >>  << T >>  << A >>
Gabor wrote:
> On Mar 30, 4:11 pm, "Andy Peters" <goo...@latke.net> wrote:
>> On Mar 30, 12:00 pm, "Peter Klemperer" <ftpe...@gmail.com> wrote:
>>
>>> Hi All,
>>> In one of my VHDL designs I have a section of code that I want
>>> different versions for synthesis than for simulation.  Currently I
>>> just comment out one section and uncomment the other, but I had a
>>> rather embarassing incident yesterday where I forgot to change the
>>> comments before beginning synthesis.  Ooops.
>>> I searched around a bit, but haven't found a definitive solution other
>>> than using a preprocessor.  I don't think that this is a satisfactory
>>> solution.  Eliminating the simulation only code is simple, the --
>>> synthesis translate_off/on pragmas works great.  Is there an
>>> equivalent for modelsim?
>> Generate statements?
>>
>> -a
> 
> 
> That's a solution to reducing the changes needed, but it doesn't fully
> automate the changes unless there's a way to detect which compiler is
> being used - Modelsim or synthesis.  If you had a way to put your
> synthesis-specific code at the top of the file, you could use the -
> line
> option for vcom in Modelsim to start compilation after the synthesis
> only section, but I don't see this as very practical.  If you were
> using Verilog I could think of a few ways to deal with this...
> In Verilog for example you can define a macro on the command line
> and then use `ifdef `else to exclude code that is for synthesis only.
> 
Depending on the extent of your optional code, can you use two different 
architectures, & a configuration file to choose between them?

Article: 117437
Subject: Re: ModelSim VHDL Pragmas
From: "Peter Klemperer" <ftpeter@gmail.com>
Date: 30 Mar 2007 16:33:16 -0700
Links: << >>  << T >>  << A >>
Thank you all for your responses.  Unfortunately, I am sharing this
code among people
using different design flow and I don't want to change anybodies
flow.  For now, it seems
the most reliable solution would be using generate statements, but I
think we're going to just
have to remember to hand comment out when it's time to synthesize.

Thanks again,
--Peter

> Depending on the extent of your optional code, can you use two different
> architectures, & a configuration file to choose between them?



Article: 117438
Subject: Sysgen compilation target
From: "mans" <(use_my_name_here)-34@blueyonder.co.uk>
Date: Fri, 30 Mar 2007 23:34:28 GMT
Links: << >>  << T >>  << A >>
Hello,

   I am trying to create a new compilation target for SysGen and I found 
that the documentation is not complete and the sample compilation target 
that is provided with SysGen is not working. Did any body tried to build a 
compilation target for SysGen? Any success?



Regards





Article: 117439
Subject: Re: ModelSim VHDL Pragmas
From: Tim <tim@nooospam.roockyloogic.com>
Date: Sat, 31 Mar 2007 01:07:16 +0100
Links: << >>  << T >>  << A >>
Peter Klemperer wrote:
> Hi All,
> 
> In one of my VHDL designs I have a section of code that I want
> different versions for synthesis than for simulation.  Currently I
> just comment out one section and uncomment the other, but I had a
> rather embarassing incident yesterday where I forgot to change the
> comments before beginning synthesis.  Ooops.
> 
> I searched around a bit, but haven't found a definitive solution other
> than using a preprocessor.  I don't think that this is a satisfactory
> solution.  Eliminating the simulation only code is simple, the --
> synthesis translate_off/on pragmas works great.  Is there an
> equivalent for modelsim?

You can use this old trick:

constant MODELSIM : boolean := false
-- synthesis translate_off
     	or true
-- synthesis translate_on
	;

then
   if MODELSIM then foo; else bar; end if;

or similar.
	
Jonathan B will surely post a better solution in due course.

Article: 117440
Subject: Help with a face recognition system
From: "Islam Ossama" <islam.ossama@gmail.com>
Date: 30 Mar 2007 18:17:33 -0700
Links: << >>  << T >>  << A >>
Hi all,

I am a Computer Science student in my final year. My graduation
project is to build a face recognition system (based on Principle
Component Analysis and possibly Artificial Neural Networks) on FPGA.
Since software is the focus of our college study, hardware is not
quite my domain of expertise. I have been doing some reading on the
subject, but of course it's nothing in comparison to years of
experience. So, I was wondering if you can provide me with some
guidance on the following points:

- Which would be a better approach: implementing such system in HDL,
or using a soft microprocessor, which if I understand correctly will
make it possible to implement the system in assembly or even C. What
about mixing them, which I think is referred to as a hardware/software
co-design approach; would that be too hard to accomplish? What would
its advantage be over either of the two approaches?

- If the use of a microprocessor is suggested, what are the
recommendations for the type of microprocessor or the specific
implementation?

- I already went and bought an XESS XSA-200 prototyping board, which
operates a Spartan-II XC2S200-5FG256 (200k gates) FPGA. After spending
the last couple of months with it, I realize it might be a bit low-
end. The question is, would it be possible to fit the probably-complex
image processing system on it, or is it possible that I would reach a
point where I can't fit my design on it no matter what?


I realize this is a relatively long post, so I'd be grateful for any
answers to any part of it.

Thank you for reading this far, and thanks in advance for any replies.


Best Regards,
Islam Ossama
4th year, Computer Science Dept.
Faculty of Computer and Information,
Helwan University, Cairo, Egypt.


Article: 117441
Subject: Re: ModelSim VHDL Pragmas
From: "John McCaskill" <junkmail@fastertechnology.com>
Date: 30 Mar 2007 18:31:14 -0700
Links: << >>  << T >>  << A >>
On Mar 30, 7:07 pm, Tim <t...@nooospam.roockyloogic.com> wrote:
> Peter Klemperer wrote:
> > Hi All,
>
> > In one of my VHDL designs I have a section of code that I want
> > different versions for synthesis than for simulation.  Currently I
> > just comment out one section and uncomment the other, but I had a
> > rather embarassing incident yesterday where I forgot to change the
> > comments before beginning synthesis.  Ooops.
>
> > I searched around a bit, but haven't found a definitive solution other
> > than using a preprocessor.  I don't think that this is a satisfactory
> > solution.  Eliminating the simulation only code is simple, the --
> > synthesis translate_off/on pragmas works great.  Is there an
> > equivalent for modelsim?
>
> You can use this old trick:
>
> constant MODELSIM : boolean := false
> -- synthesis translate_off
>         or true
> -- synthesis translate_on
>         ;
>
> then
>    if MODELSIM then foo; else bar; end if;
>
> or similar.
>
> Jonathan B will surely post a better solution in due course.



Thank you Tim,

You just made my day. I use Verilog, but work with EDK which has a
strong VHDL bias.  I have been having to work around problems with
passing std_logic_vector generics to integer parameters and keeping
multiple versions of EDK and ModelSim happy at the same time.  This is
a much more elegant solution than any of the others that I have come
up with or had recomended to me.

Regards,

John McCaskill
www.fstertechnology.com


Article: 117442
Subject: Re: A suggestion for a new input interface for functions in VHDL: XOR(a0, a1, ...)
From: "Weng Tianxiang" <wtxwtx@gmail.com>
Date: 30 Mar 2007 19:28:22 -0700
Links: << >>  << T >>  << A >>
On Mar 30, 1:02 pm, "Daniel S." <digitalmastrmind_no_s...@hotmail.com>
wrote:
> Weng Tianxiang wrote:
> >>> Or I think I'd prefer:
> >>>   y_xor(0) <= xor (x and X"B4D1B4D14B2E4B2E");
> >>> Because it's much less typing.
> >> I like it.  Just if it was more readable.
>
> >> Jim- Hide quoted text -
>
> >> - Show quoted text -
>
> > Hi Lewis,
> > Can you tell me which Xilinx ISE version starts to support the new
> > definition you described in the form of XOR((...))?
>
> Since most of the new syntaxes from this thread come from VHDL 200X
> language extension drafts, chances are that none of these new extensions
> will be included/supported in/by standard Xilinx synthesis libraries/tools
> until the next ISE after (and probably only if) they become official.
>
> Until then, you will most likely have to wait for the next(next(next(...)))
> ISE revision and hope for "early" adoption. In the meantime, you can write
> your own package and define your own reduction functions, it takes only a
> minute or two to code your own xor_reduce function... assuming you do not
> already have one in your vendor's libraries that does the same job. No big
> deal.

Hi Daniel,
What I mentioned were coded without any trouble.

The trouble is each time one needs it, he must write the code for
himself,

A broad range same function can be written one time as a VHDL standard
and after that everybody doesn't have to write it again and again. Now
in any standard VHDL library, there are too many functions that are
useless, for example, XOR(a, b).

More general functions with variable size of std_logic_vector or
unsigned without troube to introduce another signal definition for the
temparorily set is easier to use and will be widely used.

Weng


Article: 117443
Subject: Re: What is the best application notes or patents filed by Xilinx to disclose Vertex-5 Slice L
From: "Weng Tianxiang" <wtxwtx@gmail.com>
Date: 30 Mar 2007 19:41:31 -0700
Links: << >>  << T >>  << A >>
On Mar 27, 8:44 pm, "Paul Leventis" <paul.leven...@gmail.com> wrote:
> Hi,
>
> Due to recent changes, the 2-to-4 year delay has been reduced
> somewhat.  If you go tohttp://www.uspto.gov/patft/, you can now view
> published applications.  I'm not sure how soon after filing that an
> application is made available to the public, but based on random
> searches of the patents of my colleagues it seems like it is in the
> neighborhood of 1 year.
>
> I agree with Peter -- rarely will you see what exactly was implemented
> in the chip in a patent; it is usually some combination of a bunch of
> patents mixed with good engineering and a dash of trade secrets.  And
> it can be hard to tell what a patent was really about by the time it
> gets turned into legalize...
>
> - Paul

Hi Paul,
Can you help identify where I can find the patent application:
U.S. Appl No. 11/151/796, filed Jun. 14, 2005.

It is said that a patent application will be published after 180 days
since its file date. But from U.S. Patent Office, I couldn't find it.
Why? Or any other technology to find it? Or it may be delayed longer
than 180 days?

Weng



Article: 117444
Subject: Re: What is the best application notes or patents filed by Xilinx to disclose Vertex-5 Slice L
From: "Peter Alfke" <alfke@sbcglobal.net>
Date: 30 Mar 2007 20:09:01 -0700
Links: << >>  << T >>  << A >>
Weng, I am glad you liked the paper. Here it is:
http://www.sunburst-design.com/papers/CummingsSNUG2002SJ_FIFO2.pdf

Both Cliff Cummins and I are deeply involved in the peculiarities of
asynchr. FIFOs. When we agreed to co-author this paper, Cliff was very
suspicious that my solution would not work properly, so I had to work
very hard to (almost) convince him. That definitely improved the
paper, which was then voted "best paper of the conference"(Synopsys
User Group, 2002)
Nice memories...
Thanks
Peter Alfke

On Mar 27, 10:03 pm, "Weng Tianxiang" <wtx...@gmail.com> wrote:
> On Mar 27, 7:15 pm, "Peter Alfke" <a...@sbcglobal.net> wrote:
>
>
>
> > Weng, you seem to believe that there is a one-to-one corresponcence
> > between the content of a patent and the Xilinx implementation.
> > That is not necessarily so.
> > If you want to learn what a certain company is interested in, then
> > looking at patents is meaningful, (but you still suffer from the 2-
> > to-4year delay in patent issuing.)
> > If you want to design an ASIC, intimate knowledge of the FPGA may be
> > more hindrance than help. The architecture and circuit trade-offs are
> > completely different.
> > Keep studying...
> > Peter Alfke
> > ==========================
>
> > On Mar 27, 6:10 pm, "Weng Tianxiang" <wtx...@gmail.com> wrote:
>
> > > On Mar 27, 3:25 pm, "John_H" <newsgr...@johnhandwork.com> wrote:
>
> > > > Is page 158 of the Virtex-5 User Guide
>
> > > >  http://direct.xilinx.com/bvdocs/userguides/ug190.pdf
>
> > > > just too darned simple for you?  Are you trying to understand the operation
> > > > of the part from the detailed silicon level tricks that may or may not be
> > > > applicable for this part of the device?  I tried looking at a DDR IOB cell
> > > > patent once and found it to be interestingly disconnected from my RTL and
> > > > chip level design experience.  If you are into physical level design of CMOS
> > > > chips on advanced processes you have a chance of understanding how things
> > > > come together.  If all you want to know is how that chip will work for you,
> > > > use the User's Guide!
>
> > > > I don't have to know about the metal casting used for the alternator in my
> > > > car to understand how the alternator works.  You don't need patents to
> > > > understand the SLICE_L.
>
> > > > - John_H
>
> > > > "Weng Tianxiang" <wtx...@gmail.com> wrote in message
>
> > > >news:1175036266.831589.180920@b75g2000hsg.googlegroups.com...
>
> > > > > Hi,
> > > > > When I am turning to Xilinx Virtex-5 new chips from Virtex-II, I would
> > > > > like to know which patents filed by Xilinx to disclose the contents of
> > > > > Slice L.
>
> > > > > Slice M is too complex for me to fully understand at the moment and
> > > > > just knowledge of Slice L is good enough for me to start with Virtex-5
> > > > > as basic knowledge for it.
>
> > > > > Thank you.
>
> > > > > Weng- Hide quoted text -
>
> > > > - Show quoted text -
>
> > > Hi John,
> > > Yes, I am interested in ASIC design of Slice L and want someone's help
> > > to locate the patent filed by Xilinx that contains the contents of
> > > Slice L. I am not interested in slice M that is too complex to me now.
>
> > > I have already printed the user manual you indicated and carefully
> > > read it. But it doesn't meet my curiority.
>
> > > Weng- Hide quoted text -
>
> > - Show quoted text -
>
> Hi Peter,
> Thank you for your advice.
>
> I like reading and learning. Your paper about asynchronous FIFO
> cooperated with another engineer is the best article I have read in my
> life.
>
> Weng



Article: 117445
Subject: Re: Help with a face recognition system
From: "Peter Alfke" <alfke@sbcglobal.net>
Date: 30 Mar 2007 20:17:51 -0700
Links: << >>  << T >>  << A >>
Islam,
If I were you, I would:
first explore the best algorithm
then see whether it can be implemented on a (any!) microprocessor,
achieving reasonable performance.
If the microprocessor implementation is too slow, I would look at a
way to speed it up with an FPGA, and I would use an existing board of
reasonable performance.
The Xilinx University Program has a better board, based on Virtex-
IIPro, that is surprisingly inexpensive for universities.
I would contact the Xilinx University Program about details.

Challenging project!
Peter Alfke

On Mar 30, 6:17 pm, "Islam Ossama" <islam.oss...@gmail.com> wrote:
> Hi all,
>
> I am a Computer Science student in my final year. My graduation
> project is to build a face recognition system (based on Principle
> Component Analysis and possibly Artificial Neural Networks) on FPGA.
> Since software is the focus of our college study, hardware is not
> quite my domain of expertise. I have been doing some reading on the
> subject, but of course it's nothing in comparison to years of
> experience. So, I was wondering if you can provide me with some
> guidance on the following points:
>
> - Which would be a better approach: implementing such system in HDL,
> or using a soft microprocessor, which if I understand correctly will
> make it possible to implement the system in assembly or even C. What
> about mixing them, which I think is referred to as a hardware/software
> co-design approach; would that be too hard to accomplish? What would
> its advantage be over either of the two approaches?
>
> - If the use of a microprocessor is suggested, what are the
> recommendations for the type of microprocessor or the specific
> implementation?
>
> - I already went and bought an XESS XSA-200 prototyping board, which
> operates a Spartan-II XC2S200-5FG256 (200k gates) FPGA. After spending
> the last couple of months with it, I realize it might be a bit low-
> end. The question is, would it be possible to fit the probably-complex
> image processing system on it, or is it possible that I would reach a
> point where I can't fit my design on it no matter what?
>
> I realize this is a relatively long post, so I'd be grateful for any
> answers to any part of it.
>
> Thank you for reading this far, and thanks in advance for any replies.
>
> Best Regards,
> Islam Ossama
> 4th year, Computer Science Dept.
> Faculty of Computer and Information,
> Helwan University, Cairo, Egypt.



Article: 117446
Subject: Re: Quartus warning messages reagarding timming and latchs
From: vbetz@altera.com
Date: 30 Mar 2007 20:46:36 -0700
Links: << >>  << T >>  << A >>
On Mar 26, 2:37 pm, djo...@btinternet.com wrote:
> Dear users
>
> Thank you for your reply.
>
> I found that my problem lies in the state machine it self, so i
> basically removed the RAM from my project and ran the synatizer using
> quartus.
>
> The warning message has slighted change but may be its caused by the
> same mistake
>
> Warning: Found 80 node(s) in clock paths which may be acting as ripple
> and/or gated clocks -- node(s) analyzed as buffer(s) resulting in
> clock skew
>
> Regarding the RAMS timing what my state machine is doing is creating a
> vector throughout differnt stages of the process and when the vector
> is ready to be saved . The statemachine goes to a state that asserts
> the Clock input to the RAM to '1' and this is asserted 1 for one clock
> cycle of the clock in the state machine before returning to '0';
>
> The other message i get is
> Warning: Timing Analysis is analyzing one or more combinational loops
> as latches
> Warning: Node "ramin[0]$latch" is a latch
> ..
> ...
> ....
>
> Am i strucuring my VHDL code wrongly or somthing. I am using mentor
> graphic FPGA adavantge and have graphical created a state machine.
>
>
>
> >From what i have understood is that- Hide quoted text -
>
> - Show quoted text -

It's hard to be sure of what's going on without seeing your design,
but those warning messages from Quartus are a strong indication you're
not coding your VHDL in a clean way.  Instead of gating the clock to
your RAM, use a clock enable (safer and easier to timing analyze).

Vaughn
Altera


Article: 117447
Subject: Re: Help with a face recognition system
From: "Islam Ossama" <islam.ossama@gmail.com>
Date: 30 Mar 2007 21:53:40 -0700
Links: << >>  << T >>  << A >>
Peter,

First of all, thanks for replying :-).

We (team of 5) spent the last semester exploring and evaluating the
different algorithms. We came to the conclusion that PCA would be the
best compromise between complexity and accuracy, with the
recommendation that Neural Networks be added into it if possible, to
increase the accuracy even further.

We did evaluate different implementations of the algorithm, some on
MATLAB and some running natively, and the performance was as we
expected: not suitable for real-time, especially for large face
databases.

This only confirmed what was suggested at the beginning of our
research, which was the main reason we wanted to explore an FPGA
implementation to make up for the performance shortcomings while
maintaining (or better, increasing) the level of accuracy.

Right now we have in fact divided up the work between us, and 3 of my
team are working on the algorithm (it being the main focus of the
project), while one is working on the neural network, and myself
working on the FPGA.

What remains to be determined is the kind of design that the algorithm
will be implemented with. Whether it would be solely VHDL, a soft
microprocessor and asm/C/C++ code, or some combination of the two.
And, of course, whether the hardware currently at hand would support
that design.

Also, after sending my earlier post, I stumbled upon a project on
opencores.org called Java Optimized Processor (http://
www.opencores.com/projects.cgi/web/jop/overview), which is essentially
a soft processor for Java bytecode. I was wondering how good/robust/
flexible it is, and whether someone here has actually used it in any
way on actual hardware. I might try to implement it and download it to
my FPGA, if I can get it to compile on Webpack 9.1i without trouble.

I did check out the Xilinx University Program. The "Virtex-II Pro
Development System" seems like an extreme overkill in our case, since
the use of FPGA isn't standard curriculum in our faculty; we are
mainly doing this as a unique, single-case approach. It seems like an
excellent choice for an engineering faculty, though. Unfortunately, I
don't think our faculty (Computer Science) would be willing to make
such a purchase based on a single case requirement, especially taking
into account the relatively high currency exchange rate (1 USD ~= 5.7
EGP).

Thanks again for your response, and I hope I haven't bored you with my
long reply...

Best Regards,
Islam Ossama

On Mar 31, 5:17 am, "Peter Alfke" <a...@sbcglobal.net> wrote:
> Islam,
> If I were you, I would:
> first explore the best algorithm
> then see whether it can be implemented on a (any!) microprocessor,
> achieving reasonable performance.
> If the microprocessor implementation is too slow, I would look at a
> way to speed it up with an FPGA, and I would use an existing board of
> reasonable performance.
> The Xilinx University Program has a better board, based on Virtex-
> IIPro, that is surprisingly inexpensive for universities.
> I would contact the Xilinx University Program about details.
>
> Challenging project!
> Peter Alfke


Article: 117448
Subject: Re: Help with a face recognition system
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Sat, 31 Mar 2007 17:42:53 +1200
Links: << >>  << T >>  << A >>
Islam Ossama wrote:

> Peter,
> 
> First of all, thanks for replying :-).
> 
> We (team of 5) spent the last semester exploring and evaluating the
> different algorithms. We came to the conclusion that PCA would be the
> best compromise between complexity and accuracy, with the
> recommendation that Neural Networks be added into it if possible, to
> increase the accuracy even further.
> 
> We did evaluate different implementations of the algorithm, some on
> MATLAB and some running natively, and the performance was as we
> expected: not suitable for real-time, especially for large face
> databases.

That would seem to be the key issue. FPGA should be able to scan
one face quite quickly, but trawling for a match becomes a data-scan
problem.

Just how large are these databases ?

-jg


Article: 117449
Subject: Re: Help with a face recognition system
From: Matthew Hicks <mdhicks2@uiuc.edu>
Date: Sat, 31 Mar 2007 07:23:19 +0000 (UTC)
Links: << >>  << T >>  << A >>
We (Illiac 6 research group at the University of Illinois) are currenlty 
working on porting one of the more popular face recognition programs for 
an application that is going to run on our "Communications Supercomputer", 
which involves a Virtex II-Pro FPGA.  These is no benefit from implementing 
a processor in the FPGA and then running the existing C code on it, becuase 
there is no way it will come close to the performance of a processor in ASIC. 
 Your only option of utilizing the FPGA for speedup is going to the roots 
of the algorithm(s), finding parallelism, and writing HDL code to exploit 
that parallelism.  That is the phase we are currently in.  Remember that 
an algorithm that may not be the best in a sequential environment may shine 
in a highly parallel environment, so it's best to look at all algorithms 
for possible parallel structure.


---Matthew Hicks


> Peter,
> 
> First of all, thanks for replying :-).
> 
> We (team of 5) spent the last semester exploring and evaluating the
> different algorithms. We came to the conclusion that PCA would be the
> best compromise between complexity and accuracy, with the
> recommendation that Neural Networks be added into it if possible, to
> increase the accuracy even further.
> 
> We did evaluate different implementations of the algorithm, some on
> MATLAB and some running natively, and the performance was as we
> expected: not suitable for real-time, especially for large face
> databases.
> 
> This only confirmed what was suggested at the beginning of our
> research, which was the main reason we wanted to explore an FPGA
> implementation to make up for the performance shortcomings while
> maintaining (or better, increasing) the level of accuracy.
> 
> Right now we have in fact divided up the work between us, and 3 of my
> team are working on the algorithm (it being the main focus of the
> project), while one is working on the neural network, and myself
> working on the FPGA.
> 
> What remains to be determined is the kind of design that the algorithm
> will be implemented with. Whether it would be solely VHDL, a soft
> microprocessor and asm/C/C++ code, or some combination of the two.
> And, of course, whether the hardware currently at hand would support
> that design.
> 
> Also, after sending my earlier post, I stumbled upon a project on
> opencores.org called Java Optimized Processor (http://
> www.opencores.com/projects.cgi/web/jop/overview), which is essentially
> a soft processor for Java bytecode. I was wondering how good/robust/
> flexible it is, and whether someone here has actually used it in any
> way on actual hardware. I might try to implement it and download it to
> my FPGA, if I can get it to compile on Webpack 9.1i without trouble.
> 
> I did check out the Xilinx University Program. The "Virtex-II Pro
> Development System" seems like an extreme overkill in our case, since
> the use of FPGA isn't standard curriculum in our faculty; we are
> mainly doing this as a unique, single-case approach. It seems like an
> excellent choice for an engineering faculty, though. Unfortunately, I
> don't think our faculty (Computer Science) would be willing to make
> such a purchase based on a single case requirement, especially taking
> into account the relatively high currency exchange rate (1 USD ~= 5.7
> EGP).
> 
> Thanks again for your response, and I hope I haven't bored you with my
> long reply...
> 
> Best Regards,
> Islam Ossama
> On Mar 31, 5:17 am, "Peter Alfke" <a...@sbcglobal.net> wrote:
> 
>> Islam,
>> If I were you, I would:
>> first explore the best algorithm
>> then see whether it can be implemented on a (any!) microprocessor,
>> achieving reasonable performance.
>> If the microprocessor implementation is too slow, I would look at a
>> way to speed it up with an FPGA, and I would use an existing board of
>> reasonable performance.
>> The Xilinx University Program has a better board, based on Virtex-
>> IIPro, that is surprisingly inexpensive for universities.
>> I would contact the Xilinx University Program about details.
>> Challenging project!
>> Peter Alfke





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