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
2017JanFebMarApr2017

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 137125

Article: 137125
Subject: Re: DFFR using DFF (only, may be extra gates)
From: Thomas Stanka <usenet_nospam_valid@stanka-web.de>
Date: Wed, 24 Dec 2008 01:18:33 -0800 (PST)
Links: << >>  << T >>  << A >>
On 23 Dez., 13:57, santhosh_h...@yahoo.com wrote:
> Now I need to implement ASYNCHRONOUS RESET flip flop
> using DFF ONLY, may be some extract logic. HOW CAN I DO THAT ?

Impossible without additional logic.
If you need to use additional logic, why bother about dff?
Assume you have really a technology with only dff as clocked gates,
you could still use pure logic (picked from a book in your high
school) as in the old days when you need to build your ff as a
bistable multivibrator and forget the dff. I think this saves you from
a lot of trouble

bye Thomas






Article: 137126
Subject: Generation of WR and RD signal for ASYNC FIFO
From: rajesh <rajvan123@gmail.com>
Date: Wed, 24 Dec 2008 04:00:25 -0800 (PST)
Links: << >>  << T >>  << A >>
Hi,

   I have some problem in generating read and write enable signal for
async FIFO.The hardware connection is like this.Processor address bus
is directly connected  CPLD and data bus is going through FIFO. This
FIFO capacity is 1k and our requirment is only 60 Byte .so i can not
use HALF and FULL flag.and whenever processor wants to write some data
into fifo, it sends one address to cpld then it has to read back
inside  register. Like this processor is writting 8 times w.r.t PWE
into fifo and CPLD is reading back.so this writing thing is dependent
on the processor but i dont want to make read thing dependent on
processor.this is our limitation.

i have written vhdl code for this requirment. but i am getting
multiple drive signal error while synthesiging code.Problem is i have
to generate read and write signal 8 times thats why its giving
error.but i have to do that bcoz processor is writting 8 times for
different different component.

so pleas direct this if any one of you have good information.

Thanks

Rajesh kumar

Article: 137127
Subject: Re: which HLL for HPC applications implementation?
From: Jan Decaluwe <jan@jandecaluwe.com>
Date: Wed, 24 Dec 2008 13:25:13 +0100
Links: << >>  << T >>  << A >>
Karl wrote:
> Hi,
> I have to map some scientific application algorithms on FPGA using a
> High Level Language (HLL) and not VHDL. I am lost regarding the choice
> of the HLL language to use which not only allows efficient mapping but
> also the user to alter and enhance the compiler and the mapping in
> general, preferably open source compiler!
> 


http://www.myhdl.org/doku.php/why#you_would_like_to_do_algorithm_development_and_implementation_in_the_same_environment

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
     Python as a hardware description language:
     http://www.myhdl.org

Article: 137128
Subject: Re: Bit width in CPU cores
From: Bruce McFarling <agila61@netscape.net>
Date: Wed, 24 Dec 2008 06:46:30 -0800 (PST)
Links: << >>  << T >>  << A >>
On Dec 22, 4:36 pm, Jonah Thomas <jethom...@gmail.com> wrote:
> In practice, if you try to use CHARS correctly but you leave one out,
> how would you notice? A Forth that does type-checking would find the
> problem for you. Otherwise you depend on your desk-checking skills
> without actually getting the machine to test for the problem. Unless you
> have a Forth system with different addressing.

You'd need a portability test implementation that broke the
assumption. The good news is that since it would not require blazing
speed for most portability testing, it could be a Forth implemented in
Forth.

Say, 20 bit addressing and 9-bit CHARS. That'd test a good number of
CHAR / CELL relationship assumptions.

Article: 137129
Subject: Re: which HLL for HPC applications implementation?
From: Colin Paul Gloster <Colin_Paul_Gloster@ACM.org>
Date: Wed, 24 Dec 2008 15:36:42 +0000
Links: << >>  << T >>  << A >>
On December 23rd, 2008, Charles submitted to news:comp.arch.fpga :

|----------------------------------------------------------------------|
|"I have to map some scientific application algorithms on FPGA using a |
|High Level Language (HLL) and not VHDL."                              |
|----------------------------------------------------------------------|

VHDL would actually be a better choice than many other languages,
including languages which you seem to be considering.

|----------------------------------------------------------------------|
|" I am lost regarding the choice                                      |
|of the HLL language to use which not only allows efficient mapping but|
|also the user to alter and enhance the compiler and the mapping in    |
|general, preferably open source compiler!"                            |
|----------------------------------------------------------------------|

One can expect inferior results from open source.

By following a hyperlink from
WWW-users.CS.York.ac.UK/~neil/erts/projects.html#YHAC
it used to be possible to obtain a compiler for a high level language
to target FPGAs from one particular vendor. I kept a copy, so if you
contact him and if he does not agree to adapt the toolchain as you
desire, then I could give you a copy.

Glenn Booker, of Drexel University, was involved with that
language (though possibly not FPGAs) and biology modeling.
WWW.Ischool.Drexel.edu/Home/people/faculty/facultydetails/?facultyid=28

You can learn about a company which uses that language (though
possibly not FPGAs) for medical devices by looking at
WWW.NewportInstruments.com
though I do not know whether it is involved with modeling.

|----------------------------------------------------------------------|
|"I got conflicting feedbacks about Mitrion-C in particular which i was|
|using to use. some suggested Handel-C other Mitrion-C, etc...i could  |
|not find a rigourous comparative studies. could you share your        |
|experience with us and/or any advice"                                 |
|----------------------------------------------------------------------|

It seems that you could easily be led astray on account of not being
suited to judge things which you are unfamiliar with. For example,
after reading
HTTP://Klabs.org/richcontent/MAPLDCon03/presentations/p/p17_duren_s.ppt
would you agree that it is easy to obtain results with C which are
almost as good as with a hardware description language? If so, then
you would have failed to notice that rival HDL intellectual properties
from Zelinda (
WWW.Zelinda.com
) and even to some extent gratis ones available on the Internet
perform much much better than the best ones mentioned in that
Powerpoint file ("USED XILINX CORE GENERATOR PROGRAM TO DEVELOP CORES").

Note that VHDL allows higher levels of abstraction than C and is more
efficient. I noticed that
HTTP://forum.Mitrionics.com/uploads/Mitrion_Users_Guide.pdf
contains:
"[..]

With Mitrion-C and the Mitrion Virtual Processor, some FPGA programming limits
are inherited:
[..]
* There is no signalling. There are also no exact exceptions (such as divide by zero or
index out of range).
* Debugging of applications running on the FPGA is complex and support may be
lacking from debuggers. It is not always possible to inspect all variables, and single
stepping has a different meaning.
[..]"

You would not have these problems with VHDL espite the claim that
these problems were "inherited" as "FPGA programming limits". (VHDL is
even mentioned in that document, so they should have known better.)

Another item in that list was
"* Memory management is comparatively rudimentary. The user is responsible for
data marshalling between multiple address spaces (see figure 2-2 below), and loads
and stores are word or line oriented, not cached and not coherent."
It is not as true with VHDL.

Yours sincerely,
Colin Paul Gloster

Article: 137130
Subject: PCI newbie problems
From: Massi <massi_srb@msn.com>
Date: Wed, 24 Dec 2008 08:40:10 -0800 (PST)
Links: << >>  << T >>  << A >>
Hi everyone,

I'm trying to set up a toy design on a Xilinx Virtex 5 (Avnet PCI
Express Development Kit board) and I'm having big problems to
understand how PCI works. I downloaded the PCI endpoint core bitstream
for the Programmed IO on the board and plugged it into a pc,
everything seems to work fine as a matter of fact PCI tree succeeds in
recognizing the board. My aim now is really simple, I would like to
write a byte on the memory space of the board (with PCI tree) and to
display the byte value on a seven-segment display. What I can't
understand is "where and how" I have to take the byte (from the FPGA
side), that is which signals of the PIO design I have to handle in my
module.
I apologize if my question is not very clear, but I'm a total newbie
in PCI, any hint or advice to understand it better would be really
appreciated.

Thanks in advance.

Article: 137131
Subject: Re: Generation of WR and RD signal for ASYNC FIFO
From: Mike Treseler <mtreseler@gmail.com>
Date: Wed, 24 Dec 2008 11:12:43 -0800
Links: << >>  << T >>  << A >>
rajesh wrote:

> i have written vhdl code for this requirement. but i am getting
> multiple drive signal error while synthesizing code.

Consider using a single process to avoid multiple drivers.
See the template here:
http://mysite.verizon.net/miketreseler/


  -- Mike Treseler

Article: 137132
Subject: Re: PCI newbie problems
From: Mike Treseler <mtreseler@gmail.com>
Date: Wed, 24 Dec 2008 11:18:45 -0800
Links: << >>  << T >>  << A >>
Massi wrote:

> I apologize if my question is not very clear, but I'm a total newbie
> in PCI, any hint or advice to understand it better would be really
> appreciated.

Learn vhdl or verilog hardware description
to collect the byte from the interface
and drive the display.

Article: 137133
Subject: Re: PCI newbie problems
From: newman5382@yahoo.com
Date: Wed, 24 Dec 2008 18:44:24 -0800 (PST)
Links: << >>  << T >>  << A >>
On Dec 24, 11:40=A0am, Massi <massi_...@msn.com> wrote:
> Hi everyone,
>
> I'm trying to set up a toy design on a Xilinx Virtex 5 (Avnet PCI
> Express Development Kit board) and I'm having big problems to
> understand how PCI works. I downloaded the PCI endpoint core bitstream
> for the Programmed IO on the board and plugged it into a pc,
> everything seems to work fine as a matter of fact PCI tree succeeds in
> recognizing the board. My aim now is really simple, I would like to
> write a byte on the memory space of the board (with PCI tree) and to
> display the byte value on a seven-segment display. What I can't
> understand is "where and how" I have to take the byte (from the FPGA
> side), that is which signals of the PIO design I have to handle in my
> module.
> I apologize if my question is not very clear, but I'm a total newbie
> in PCI, any hint or advice to understand it better would be really
> appreciated.
>
> Thanks in advance.


You may want to watch Implementing PCI Express v2.0 Compliant Designs
with Xilinx Virtex-5 FPGAs Tech Seminar

http://www.techonline.com/learning/webinar/211800334

Article: 137134
Subject: gtkwave website has moved
From: bybell@gmail.com
Date: Wed, 24 Dec 2008 22:54:50 -0800 (PST)
Links: << >>  << T >>  << A >>
The website has moved to sourceforge: http://gtkwave.sourceforge.net/
as my ISP has deleted the old site.

Please update any links accordingly.  It will likely take a while
before google sorts out where the new link is at.

-t

Article: 137135
Subject: Re: PCI newbie problems
From: Charles Gardiner <invalid@invalid.invalid>
Date: Fri, 26 Dec 2008 12:37:24 +0100
Links: << >>  << T >>  << A >>
Are you referring to the "LogiCore Endpoint for PCIexpress"? If so,
there is a manual on the Xilinx web site that I would look at first.
Essentially there are two 'packet ports' one for incoming packets and
one for outgoing (response) packets. Here you will have to attach some
form of state machine to generate/handle your data. I am sure there are
some examples available from Xilinx. PCIexpress is a packet-based protocol.

To be honest, I think you will find it extremely hard work if you don't
familiarise yourself with PCIexpress first.  A good starting point is
the Mindshare book by Anderson/Budruk/Shanley. I think there is also an
electronic version available. It's a big book but the first few chapters
are enough to get you started. For your test case, an understanding of
the following points is most important.
1) How to decode a PCIexpress packet. (Essentially a sequence of 32-bit
words)
2) When and how to generate a response packet (i.e. for all accesses
except Memory-Write/Message packets).

As regards writing to memory using PCItree. I am not so sure whether
that will work at all. If I remember correctly, PCItree really aims at
accessing configuration space. You will probably not be able to access
device memory space, either memory or I/O (to be more accurate, you
shouldn't be able to) if your device hasn't been enabled by the
operating system (Bit 0 in Command register in configuration space set
to '1'). For this you will need a device driver, since an OS typically
does not enable a PCI device for which it cannot find a driver. If you
are using Windows I'd recommend the KMDF framework (available from the
MS website). If you are working under Linux, take a good look at the
kernel sources and also Rubini's book which is available at O Reilly or
a number of online sources. In your case for just writing to a seven
segment display, under Linux you might get away without a driver since
many parts of the PCI API can be accessed from user mode.
If you do this with memory writes you don't even have to worry about
generating response packets in you hardware. But I expect you still have
to somehow set Bit 0 in Configuration-space.Command-reg first.


Massi schrieb:
> Hi everyone,
> 
> I'm trying to set up a toy design on a Xilinx Virtex 5 (Avnet PCI
> Express Development Kit board) and I'm having big problems to
> understand how PCI works. I downloaded the PCI endpoint core bitstream
> for the Programmed IO on the board and plugged it into a pc,
> everything seems to work fine as a matter of fact PCI tree succeeds in
> recognizing the board. My aim now is really simple, I would like to
> write a byte on the memory space of the board (with PCI tree) and to
> display the byte value on a seven-segment display. What I can't
> understand is "where and how" I have to take the byte (from the FPGA
> side), that is which signals of the PIO design I have to handle in my
> module.
> I apologize if my question is not very clear, but I'm a total newbie
> in PCI, any hint or advice to understand it better would be really
> appreciated.
> 
> Thanks in advance.

Article: 137136
Subject: Re: Generation of WR and RD signal for ASYNC FIFO
From: rajesh <rajvan123@gmail.com>
Date: Sat, 27 Dec 2008 03:08:25 -0800 (PST)
Links: << >>  << T >>  << A >>
On Dec 25, 12:12=A0am, Mike Treseler <mtrese...@gmail.com> wrote:
> rajesh wrote:
> > i have written vhdl code for this requirement. but i am getting
> > multiple drive signal error while synthesizing code.
>
> Consider using a single process to avoid multiple drivers.
> See the template here:http://mysite.verizon.net/miketreseler/
>
> =A0 -- Mike Treseler

HI Mike

      thanx for ur concern towards me....i could have done in single
process but the problem is like processor is writing so many
times.some times its writes only 1 bit data and some times 60 BYTE. so
i can not write in single process.

Pleas do somthing if possible

-- Rajesh kumar

Article: 137137
Subject: JTAG USB interface
From: dajjou <swissiyoussef@gmail.com>
Date: Sat, 27 Dec 2008 05:20:04 -0800 (PST)
Links: << >>  << T >>  << A >>
Hello everybody,

 I have no idea how to start !!  in fact i want to  use  USB JTAG
interface in order to communicate with my FPGA ( Virtex 4), I mean
using the FTD2232C instead of XILINX USB programmer.

 please i need your help .




Article: 137138
Subject: Re: JTAG USB interface
From: Uwe Bonnes <bon@elektron.ikp.physik.tu-darmstadt.de>
Date: Sat, 27 Dec 2008 13:39:49 +0000 (UTC)
Links: << >>  << T >>  << A >>
dajjou <swissiyoussef@gmail.com> wrote:
> Hello everybody,

>  I have no idea how to start !!  in fact i want to  use  USB JTAG
> interface in order to communicate with my FPGA ( Virtex 4), I mean
> using the FTD2232C instead of XILINX USB programmer.

In order to use with XILINX Impact, you either have to use a DLC-5 clone or
the original  DLC-9/10, as for the USB cables the protocolls between Impact
and the programmer isn't published. For pure programming, xc3sprog at
sourceforge can be a start. I fact I use xc3sprog with a home built FT2232
adapter for programming XCF and Spartan 3.  

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

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

Article: 137139
Subject: Re: PCI newbie problems
From: Massi <massi_srb@msn.com>
Date: Sat, 27 Dec 2008 06:46:48 -0800 (PST)
Links: << >>  << T >>  << A >>
On 26 Dic, 12:37, Charles Gardiner <inva...@invalid.invalid> wrote:
> Are you referring to the "LogiCore Endpoint for PCIexpress"? If so,
> there is a manual on the Xilinx web site that I would look at first.
> Essentially there are two 'packet ports' one for incoming packets and
> one for outgoing (response) packets. Here you will have to attach some
> form of state machine to generate/handle your data. I am sure there are
> some examples available from Xilinx. PCIexpress is a packet-based protoco=
l.
>
> To be honest, I think you will find it extremely hard work if you don't
> familiarise yourself with PCIexpress first. =A0A good starting point is
> the Mindshare book by Anderson/Budruk/Shanley. I think there is also an
> electronic version available. It's a big book but the first few chapters
> are enough to get you started. For your test case, an understanding of
> the following points is most important.
> 1) How to decode a PCIexpress packet. (Essentially a sequence of 32-bit
> words)
> 2) When and how to generate a response packet (i.e. for all accesses
> except Memory-Write/Message packets).
>
> As regards writing to memory using PCItree. I am not so sure whether
> that will work at all. If I remember correctly, PCItree really aims at
> accessing configuration space. You will probably not be able to access
> device memory space, either memory or I/O (to be more accurate, you
> shouldn't be able to) if your device hasn't been enabled by the
> operating system (Bit 0 in Command register in configuration space set
> to '1'). For this you will need a device driver, since an OS typically
> does not enable a PCI device for which it cannot find a driver. If you
> are using Windows I'd recommend the KMDF framework (available from the
> MS website). If you are working under Linux, take a good look at the
> kernel sources and also Rubini's book which is available at O Reilly or
> a number of online sources. In your case for just writing to a seven
> segment display, under Linux you might get away without a driver since
> many parts of the PCI API can be accessed from user mode.
> If you do this with memory writes you don't even have to worry about
> generating response packets in you hardware. But I expect you still have
> to somehow set Bit 0 in Configuration-space.Command-reg first.

Thank you really much for your help, I have already purchased the book
you suggested and started to learn something more about PCIe. Though I
still have some doubts about how transactions happen and the memory
spaces defined by PCIe. In particular:

1. Where do the three PCIe spaces physically reside in? I mean, when I
generate my enpoint block IP core I create of course a configuration
space and (in my case) a memory space of 64K; Have I to think to them
as ram memories instantiated in the endpoint block?

2. Which is the different between I/O spaces and the memory space?

3. When a memory write transaction happens, a packet (header+payload)
is transferred (for example) from the system memory to the FPGA. As
far as I see, the whole packet is written in the memory space and then
processed by the endpoint block which present it to the user logic
(for esample a PIO module), is this right or does the transaction
happen in a different way?

Again, I'm really grateful for your help.


Article: 137140
Subject: Re: PCI newbie problems
From: Charles Gardiner <invalid@invalid.invalid>
Date: Sat, 27 Dec 2008 17:36:44 +0100
Links: << >>  << T >>  << A >>
Massi schrieb:
> On 26 Dic, 12:37, Charles Gardiner <inva...@invalid.invalid> wrote:
>> Are you referring to the "LogiCore Endpoint for PCIexpress"? If so,
>> there is a manual on the Xilinx web site that I would look at first.
>> Essentially there are two 'packet ports' one for incoming packets and
>> one for outgoing (response) packets. Here you will have to attach some
>> form of state machine to generate/handle your data. I am sure there are
>> some examples available from Xilinx. PCIexpress is a packet-based protocol.
>>
>> To be honest, I think you will find it extremely hard work if you don't
>> familiarise yourself with PCIexpress first.  A good starting point is
>> the Mindshare book by Anderson/Budruk/Shanley. I think there is also an
>> electronic version available. It's a big book but the first few chapters
>> are enough to get you started. For your test case, an understanding of
>> the following points is most important.
>> 1) How to decode a PCIexpress packet. (Essentially a sequence of 32-bit
>> words)
>> 2) When and how to generate a response packet (i.e. for all accesses
>> except Memory-Write/Message packets).
>>
>> As regards writing to memory using PCItree. I am not so sure whether
>> that will work at all. If I remember correctly, PCItree really aims at
>> accessing configuration space. You will probably not be able to access
>> device memory space, either memory or I/O (to be more accurate, you
>> shouldn't be able to) if your device hasn't been enabled by the
>> operating system (Bit 0 in Command register in configuration space set
>> to '1'). For this you will need a device driver, since an OS typically
>> does not enable a PCI device for which it cannot find a driver. If you
>> are using Windows I'd recommend the KMDF framework (available from the
>> MS website). If you are working under Linux, take a good look at the
>> kernel sources and also Rubini's book which is available at O Reilly or
>> a number of online sources. In your case for just writing to a seven
>> segment display, under Linux you might get away without a driver since
>> many parts of the PCI API can be accessed from user mode.
>> If you do this with memory writes you don't even have to worry about
>> generating response packets in you hardware. But I expect you still have
>> to somehow set Bit 0 in Configuration-space.Command-reg first.
> 
> Thank you really much for your help, I have already purchased the book
> you suggested and started to learn something more about PCIe. Though I
> still have some doubts about how transactions happen and the memory
> spaces defined by PCIe. In particular:
> 
> 1. Where do the three PCIe spaces physically reside in? I mean, when I
> generate my enpoint block IP core I create of course a configuration
> space and (in my case) a memory space of 64K; Have I to think to them
> as ram memories instantiated in the endpoint block?

Taking an FPGA-centric view of your task, configuration space is
generally included in the PCIexpress IP-Core. Configuration space, as
the name suggests, is an address space that is accessible as soon as the
device has been turned on and before configuration takes place.
Assigning the resources (interrupts, memory base address, memory windows
etc.) is made through configuration space.
Memory Space and I/O space are the parts you must add yourself and are
external to the IP-Core. These are typically control registers, memory
areas etc. and represent the resources on your add-in card which can be
accessed by other PCI/PCIexpress devices or the PC during normal
operation. Note that you do not have to implement control registers in
I/O space (see below) it is better to map them into memory space. So the
64K memory space you plan on using is fine.

> 
> 2. Which is the different between I/O spaces and the memory space?

I/O Space is really a legacy feature from the early Intel architectures.
Control registers in the peripherals were in I/O space, bulk memory in
memory space. Most of the other architectures never made a distinction.
Control registers were just mapped into selected areas of memory space
which allowed uniform access mechanisms. Unless you are trying to
emulate an older device, PCIexpress advises not to use I/O space at all
any more.

> 
> 3. When a memory write transaction happens, a packet (header+payload)
> is transferred (for example) from the system memory to the FPGA. As
> far as I see, the whole packet is written in the memory space and then
> processed by the endpoint block which present it to the user logic
> (for esample a PIO module), is this right or does the transaction
> happen in a different way?

This is where the IP-Cores from the FPGA manufacturers follow slightly
different philosophies. Personally, I am most familiar αΊƒith the Lattice
Core but from a quick look at the Xilinx data sheet it seems to follow
the same strategy. The IP-core provides the user with two 'packet
ports'. One receives packets the other is where the user logic transmits
packets. The incoming packets (e.g. a memory write with your device as
target) appear as a stream of double-words (32 Bits) initiated by some
start signal. When your logic recognises the start signal, it begins
collecting the incoming packet. You collect the target address from the
header and write the payload (which arrives immediately after the
header) to the corresponding location (register or memory) in your
application logic. If your device has been located below 4GByte in
memory space the address will be the last header double-word. If your
device has been located at or above 4GByte, the address will be the last
two header double-words. The first double word in the header contains a
field indicating whether you must expect a 32-bit or 64-bit address. But
that is all well described in the Mindshare book.

With your reference to the PIO module and your earlier mail, I am
assuming that your Xilinx bitstream is some example application which
already contains the PCIexpress IP-Core plus some additional registers
that Xilinx have already connected to the 'packet port' described above.
 If this is so, you probably just have to bring out the PIO ports to
FPGA pins and can use them to directly control your seven-segment
display. You just have to know at which address(es) this/these PIO
registers are accessible. The remaining point is as I said in my
previous posting, a well behaved PCIexpress IP-core will not pass any
memory write request through to the application logic until bit 0 in the
PCI Command register (in configuration space) has been set to '1'.
Normally, the operating system does this after it recognises and
configures your device. If the operating system doesn't do it (which is
most likely in your case, since you will be presenting an unknown
device) you ideally need a device driver to take care of it. For a
start, under windows, you probably could set this bit using the PCItree
tool but you will still need some way of writing to the PIO register.
Under windows you cannot do this directly from a user-space program.

> 
> Again, I'm really grateful for your help.
> 

Article: 137141
Subject: Re: Generation of WR and RD signal for ASYNC FIFO
From: KJ <kkjennings@sbcglobal.net>
Date: Sat, 27 Dec 2008 09:05:30 -0800 (PST)
Links: << >>  << T >>  << A >>
On Dec 27, 6:08=A0am, rajesh <rajvan...@gmail.com> wrote:

> =A0 =A0 =A0 thanx for ur concern towards me....i could have done in singl=
e
> process but the problem is like processor is writing so many
> times.some times its writes only 1 bit data and some times 60 BYTE. so
> i can not write in single process.
>
> Pleas do somthing if possible
>
> -- Rajesh kumar

Rajesh,

Your problem description isn't very clear but for a single fifo there
can only be one process that generates the fifo read signal and the
fifo write signal.  The logic description that defines when the read
and write signals occur can be as simple or complicated as you like
but still there can only be one process.  It generally makes no
difference how many times something will be writing to it (i.e. '1 bit
data' or '60 bytes') since each individual write must be handled
separately.

Does simply 'or-ing' together the 8 different sources do the trick?
By that I mean take your 8 fifo write signals and give them unique
names (i.e. fifo_wrt_1, fifo_wrt_2...etc.).  Then the fifo write
signal that you send to the fifo is simply
fifo_write <=3D fifo_wrt_1 or fifo_wrt_2 or ...

Not sure that helps much but I'm not quite sure what the problem is
other than you've got one fifo but 8 different sources for writing to
a single fifo.

Kevin Jennings

Article: 137142
Subject: Re: JTAG USB interface
From: valwn@silvtrc.org
Date: Sun, 28 Dec 2008 03:37:39 +0000 (UTC)
Links: << >>  << T >>  << A >>
dajjou <swissiyoussef@gmail.com> wrote:
>Hello everybody,

> I have no idea how to start !!  in fact i want to  use  USB JTAG
>interface in order to communicate with my FPGA ( Virtex 4), I mean
>using the FTD2232C instead of XILINX USB programmer.

Use an USB-PHY + FPGA and some reverese-eng of the DLC protocol.


Article: 137143
Subject: FPGA > ASIC
From: "RealInfo" <therightinfo@yahoo.com>
Date: Sun, 28 Dec 2008 11:12:05 +0200
Links: << >>  << T >>  << A >>
Hi all

I have a litle dream to turn a FPGA based design into a real ASIC so I can 
sell this ASIC in the market .
This is an audio processing design aimed at the guitar effects market.

My question is how much can this venture cost in general .

A general estimate will be very good .

Is it realistic to search for an investor ?

Thanks in advance
EC



Article: 137144
Subject: Re: FPGA > ASIC
From: Lorenz Kolb <lorenz.kolb@uni-ulm.de>
Date: Sun, 28 Dec 2008 11:11:56 +0100
Links: << >>  << T >>  << A >>
RealInfo wrote:
> Hi all
> 
> I have a litle dream to turn a FPGA based design into a real ASIC so I can 
> sell this ASIC in the market .
> This is an audio processing design aimed at the guitar effects market.

So what quantities are we talking about?
Are you sure that an ASIC will be able to give You roi?

> 
> My question is how much can this venture cost in general .
> 
> A general estimate will be very good .

Depends on which way you are going. Are you using vendor specific IP-blocks?

> 
> Is it realistic to search for an investor ?

Think about Your story and then you might guess if that idea is worth 
some millions for an investor.

> 
> Thanks in advance
> EC
> 
> 

Maybe You'll want to have a look at Altera's HardCopy design-flow. ASICs 
created with that flow are not the cheapest ASICs, but are cheaper then 
FPGAs (and You won't need extra logic for configuring the FPGA). For 
quantities I suspect you are talking about HardCopy might be quite 
interesting.

Regards,

Lorenz

Article: 137145
Subject: Re: FPGA > ASIC
From: Muzaffer Kal <kal@dspia.com>
Date: Sun, 28 Dec 2008 03:22:42 -0800
Links: << >>  << T >>  << A >>
On Sun, 28 Dec 2008 11:12:05 +0200, "RealInfo"
<therightinfo@yahoo.com> wrote:

>Hi all
>
>I have a litle dream to turn a FPGA based design into a real ASIC so I can 
>sell this ASIC in the market .
>This is an audio processing design aimed at the guitar effects market.

An ASIC is only needed for very high volume and/or low margin
products. Do you really think that your product qualifies and it's
worth the effort to make an ASIC? You can probably use a low cost FPGA
to implement your audio implementation and in your market margins are
hopefully quite high. What's the cost of the FPGA you're using now?
What is your projected annual sales for the next couple of years? 
>
>My question is how much can this venture cost in general .
>
Assuming that you don't need a high-end process and 180nm would be
acceptable for die size/performance, your mask costs would probably be
around $250K and another $250K for converting your current RTL to ASIC
(including some hard IP like PLL & IO etc). Then you should be able to
buy 8 inch wafers for $1500 each which might give you 1000 5mm by 5mm
dice. Add another buck for packaging & test so you're looking at $2.5
per chip.
Now your real challenge starts: how are you going to advertise,
market, sell, distribute and support your chips? You can probably all
of the steps in the previous paragraph without getting off your chair
but the actual task of getting the chips to the customers and getting
them to use it is the main challenge. And this step is the same for an
ASIC or an FPGA. I'd suggest you start with an FPGA, make a product,
sell it and then depending on your volume see if an ASIC is justified.

>A general estimate will be very good .
>
>Is it realistic to search for an investor ?
>
Probably not for making an ASIC but maybe for getting your design into
the hands of your customers in any form. You have to find a market for
your product, make reasonable sales figures and have a good business
plan first and then search for an investor for your product whether it
uses an ASIC or an FPGA.

>Thanks in advance
>EC
>

Muzaffer Kal

DSPIA INC.
ASIC/FPGA Design Services
http://www.dspia.com

Article: 137146
Subject: Re: which HLL for HPC applications implementation?
From: Jeremy Bennett <jeremy.bennett@embecosm.com>
Date: Sun, 28 Dec 2008 05:33:10 -0600
Links: << >>  << T >>  << A >>
On Tue, 23 Dec 2008 06:18:30 -0800, Karl wrote:

> I have to map some scientific application algorithms on FPGA using a
> High Level Language (HLL) and not VHDL. I am lost regarding the choice
> of the HLL language to use which not only allows efficient mapping but
> also the user to alter and enhance the compiler and the mapping in
> general, preferably open source compiler!
> 
> I got conflicting feedbacks about Mitrion-C in particular which i was
> using to use. some suggested Handel-C other Mitrion-C, etc...i could not
> find a rigourous comparative studies. could you share your experience
> with us and/or any advice

Have you considered SystemC (www.systemc.org). It is an industry standard 
template library for C++ (IEEE 1666) for hardware and system design. An 
open source implementation is available. The language is supported by all 
the main hardware simulators.

Various companies and tools will map SystemC to hardware - for example 
Forte Design Systems and Bluespec. There are also various companies with 
products to map algorithms to hardware - for example Critical Blue.

The field is generally known as Electronic System Level (ESL) design. A 
search on Google for "ESL algorithm mapping" will give you lots of useful 
suggestions.

HTH,


Jeremy

Article: 137147
Subject: Re: FPGA > ASIC
From: Charles Gardiner <invalid@invalid.invalid>
Date: Sun, 28 Dec 2008 12:37:39 +0100
Links: << >>  << T >>  << A >>
The last time I looked into this myself, about five years ago, there
were two main price regions. I found three manufacturers who had so
called 'low-NRE' product lines, two Japanese and one Korean. The lowest
price came in at about EUR50.000 for a minimum order of 25.000 pieces
and a smallish die size.
Just in case your not familiar, NRE 'non-returnable engineering' costs
is what you pay up front for mask manufacturing etc. At the time the
low-NRE product lines were restricted in what you could do (number of
metalisation layers, clocking schemes, max die size etc.) For audio
frequencies though I would expect it to be OK for you, assuming these
lines are still offered.

For the more mainstream product lines I would say you are talking about
EUR250.000 upwards. There are a lot of variables, principally die size,
quantities, whether you use third IP etc. Some manufacturers won't even
have a serious conversation with you if you are not planning a minimum
of 250.000 pieces per year. Although with a crisis looming they might be
temporarily more friendly.

As a rule of thumb, my personal feeling is that if you are not planning
more than 25.000 pieces per year or do not need some special features
like fancy power management, special IP, clocking schemes etc. migrating
to an ASIC is not cost effective.

You still have a number of options to market your chip. As another
poster suggested, Altera offer hardCopy, others possibly as well (I
haven't looked). Lattice for instance offer encrypted FPGAs in the low
cost segment (ECP2M/S. Here, you could sell your customers the FPGA with
an encrypted bit-stream for somewhere below EUR20,00 (for more accurate
figures, talk to a Lattice guy) per piece. I'm not sure if they even
charge you for the encryption key, probably depends again on the
quantities. I know of at least one video-IP provider who currently uses
this model.

RealInfo schrieb:
> Hi all
> 
> I have a litle dream to turn a FPGA based design into a real ASIC so I can 
> sell this ASIC in the market .
> This is an audio processing design aimed at the guitar effects market.
> 
> My question is how much can this venture cost in general .
> 
> A general estimate will be very good .
> 
> Is it realistic to search for an investor ?
> 
> Thanks in advance
> EC
> 
> 

Article: 137148
Subject: Re: FPGA > ASIC
From: nico@puntnl.niks (Nico Coesel)
Date: Sun, 28 Dec 2008 12:08:21 GMT
Links: << >>  << T >>  << A >>
Muzaffer Kal <kal@dspia.com> wrote:

>On Sun, 28 Dec 2008 11:12:05 +0200, "RealInfo"
><therightinfo@yahoo.com> wrote:
>
>>Hi all
>>
>>I have a litle dream to turn a FPGA based design into a real ASIC so I can 
>>sell this ASIC in the market .
>>This is an audio processing design aimed at the guitar effects market.
>
>An ASIC is only needed for very high volume and/or low margin
>products. Do you really think that your product qualifies and it's
>worth the effort to make an ASIC? You can probably use a low cost FPGA
>to implement your audio implementation and in your market margins are
>hopefully quite high. What's the cost of the FPGA you're using now?
>What is your projected annual sales for the next couple of years? 

I think FPGA isn't the proper route either. I've made quite a
complicated audio processor around an ARM7 microcontroller and a
codec. The microcontroller costs a few dollars in larger quantities.
That's hard to beat!

-- 
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
                     "If it doesn't fit, use a bigger hammer!"
--------------------------------------------------------------

Article: 137149
Subject: Re: FPGA > ASIC
From: "RealInfo" <therightinfo@yahoo.com>
Date: Sun, 28 Dec 2008 20:08:50 +0200
Links: << >>  << T >>  << A >>
Many thanks to all who took time and effort to answer.

Be well .

EC


"Charles Gardiner" <invalid@invalid.invalid> ??? 
??????:gj7odu$lku$03$1@news.t-online.com...
> The last time I looked into this myself, about five years ago, there
> were two main price regions. I found three manufacturers who had so
> called 'low-NRE' product lines, two Japanese and one Korean. The lowest
> price came in at about EUR50.000 for a minimum order of 25.000 pieces
> and a smallish die size.
> Just in case your not familiar, NRE 'non-returnable engineering' costs
> is what you pay up front for mask manufacturing etc. At the time the
> low-NRE product lines were restricted in what you could do (number of
> metalisation layers, clocking schemes, max die size etc.) For audio
> frequencies though I would expect it to be OK for you, assuming these
> lines are still offered.
>
> For the more mainstream product lines I would say you are talking about
> EUR250.000 upwards. There are a lot of variables, principally die size,
> quantities, whether you use third IP etc. Some manufacturers won't even
> have a serious conversation with you if you are not planning a minimum
> of 250.000 pieces per year. Although with a crisis looming they might be
> temporarily more friendly.
>
> As a rule of thumb, my personal feeling is that if you are not planning
> more than 25.000 pieces per year or do not need some special features
> like fancy power management, special IP, clocking schemes etc. migrating
> to an ASIC is not cost effective.
>
> You still have a number of options to market your chip. As another
> poster suggested, Altera offer hardCopy, others possibly as well (I
> haven't looked). Lattice for instance offer encrypted FPGAs in the low
> cost segment (ECP2M/S. Here, you could sell your customers the FPGA with
> an encrypted bit-stream for somewhere below EUR20,00 (for more accurate
> figures, talk to a Lattice guy) per piece. I'm not sure if they even
> charge you for the encryption key, probably depends again on the
> quantities. I know of at least one video-IP provider who currently uses
> this model.
>
> RealInfo schrieb:
>> Hi all
>>
>> I have a litle dream to turn a FPGA based design into a real ASIC so I 
>> can
>> sell this ASIC in the market .
>> This is an audio processing design aimed at the guitar effects market.
>>
>> My question is how much can this venture cost in general .
>>
>> A general estimate will be very good .
>>
>> Is it realistic to search for an investor ?
>>
>> Thanks in advance
>> EC
>>
>> 





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
2017JanFebMarApr2017

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