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 106000

Article: 106000
Subject: Re: DDR Controller
From: "PeteS" <PeterSmith1954@googlemail.com>
Date: 4 Aug 2006 09:23:05 -0700
Links: << >>  << T >>  << A >>
yy wrote:
> Hi,
> I am to build a fpga system that captures data from external signals
> and store it to DDR, also after the capture data must be transferred to
> the PC via PCI bus via DMA or so.
> So this is a CAPTURE-to-DDR  DDR-to-PCI... How is this sytem
> implemented?

You've already stated the requirements (albeit in a vague way). Tighten
up the definition and any decent designer would be able to come up with
an implementation. If you are to build it, you'll learn nothing if you
don't try to figure out the implementation [truly a core skill in
design!] yourself.

Cheers

PeteS


Article: 106001
Subject: Re: Chipscope
From: "Antti" <Antti.Lukats@xilant.com>
Date: 4 Aug 2006 09:27:00 -0700
Links: << >>  << T >>  << A >>
maxascent schrieb:

> Thanks for your replies. It turns out that I needed to first program with
> impact and then start chipscope. Seems a bit stupid to have to do this but
> at least it works
>
> Jon

there is one difference with chipscope namly it does not auto-fix the
startup clock as impact does, so you need to generate the .bit
file with startupclock jtagclock,
but I guess you had that right.

well the chipscope and impact use a little different jtag algorithm,
meaning sometimes both work, sometimes only one, I have also
seen situations where impact cant be used but chipscope succeeds
to program the fpga!

so as usual, if one doesnt work then try the other :)

Antti


Article: 106002
Subject: Re: DDR Controller
From: "yy" <yy7d6@yahoo.com.ph>
Date: 4 Aug 2006 09:45:54 -0700
Links: << >>  << T >>  << A >>
Ayon kay PeteS:
> yy wrote:
> > Hi,
> > I am to build a fpga system that captures data from external signals
> > and store it to DDR, also after the capture data must be transferred to
> > the PC via PCI bus via DMA or so.
> > So this is a CAPTURE-to-DDR  DDR-to-PCI... How is this sytem
> > implemented?
>
> You've already stated the requirements (albeit in a vague way). Tighten
> up the definition and any decent designer would be able to come up with
> an implementation. If you are to build it, you'll learn nothing if you
> don't try to figure out the implementation [truly a core skill in
> design!] yourself.
>
> Cheers
>
> PeteS


Hi PeteS,
 I will elaborate so that my concept will be clear.
First of all the idea is for the PCI to read/write data from multiple
DDR (with DDR controller interface).
With the PCI Master core connected to a DMA Engine and FIFO buffer that
is connected to the 'DDR SDRAM Controller Interface' that is connected
to the DDR Module itself, and if possible be connected to other DDR
Controller Interface, can that be possible? such that when I access
BAR1, for example i'm accessing DDR1 Interface, BAR2 for DDR2 Interface
etc., along with this a Custom logic1 that use DDR1as its data must be
able to access the same 'DDR Controller Interface1' , Custom Logic2
that use DDR2 as its data must be able to access the same DDR
Controller Interface2, etc.
In short is it possible to have seperate port for a DDR Controller
Interface connected to a single DDR module to have dual access 'port',
one for the PCI-DMA Engine and one for the Custom Logic(but not both at
the same time)? 

Regards,
yy


Article: 106003
Subject: Re: Synplify
From: Jim_B <jim.big@hotmail.com>
Date: Fri, 04 Aug 2006 18:28:10 GMT
Links: << >>  << T >>  << A >>
I would copy all .edf, .edn, .mif, .hex, .ucf, .ncf (did I forget one?) 
into a new directory and run ISE on it. ISE will search the directory 
where the .edf is located for any other interesting files.

maxascent wrote:
> I have took a Xilinx design through synplify and then started ise from
> synplify to place and route. The problem is I have some coregen components
> and when I try and place and route it complains about missing edif files. I
> can find these files in the synplify directory but how do I tell ise about
> them?
> 
> Cheers
> 
> Jon

Article: 106004
Subject: How to implement large ROM's from binary sources?
From: "radarman" <jshamlet@gmail.com>
Date: 4 Aug 2006 11:39:42 -0700
Links: << >>  << T >>  << A >>
I did a few quick searches on this topic, only to find that there
aren't many good solutions for this.

I have written my own version of the Arclite (previously Vautomation v8
uRISC) 8-bit CPU in VHDL, with a few new instructions thrown in. The
processor runs fine in ModelSim, and I've executed some reasonably
complex programs using a non-synthesizable ROM model. (I essentially
run through a for loop during reset, and stuff values in one by one
using a large case structure - it stinks, but it works well enough for
testing)

I've also managed to modify an open-source assembler and linker (WLA)
to produce code for the beast. So, I'm now at the point where I would
like to actually build a ROM, and start testing the processor core on
actual hardware - and that's where it seems to break down.

My assembler and linker produce an executable binary image. I would
like to create a ROM model that contains that exact image (dead space
and all), and I don't mind writing a tool to do it, but I'm not clear
on the best way to proceed. Both the MIF and HEX formats would require
a great deal of massaging - though a script could probably handle
conversion to the .hex format.

I would like to support both Altera and Xilinx tool flows, so I want to
stay as vendor-neutral as possible.

Is there an easy way to take my binary executable, and stuff it into a
VHDL model for synthesis?

Right now, I'm thinking about just writing a small bootloader ROM that
will download code via a serial link to memory, but even that would be
large enough that I would like to find a way to automate it.


Article: 106005
Subject: Re: How to implement large ROM's from binary sources?
From: "MikeJ" <mikej@fpgaarcade.nospam.com>
Date: Fri, 04 Aug 2006 18:52:43 GMT
Links: << >>  << T >>  << A >>
Hi,
on the www.fpgaarcade.com site there is a program called romgen (with 
source). The latest version is in the Space Invaders game.
This will take a binary file and output VDHL source for either xilinx block 
rams or vendor neutral case statements or arrays.
Cheers,
MikeJ

"radarman" <jshamlet@gmail.com> wrote in message 
news:1154716782.089926.55250@p79g2000cwp.googlegroups.com...
>I did a few quick searches on this topic, only to find that there
> aren't many good solutions for this.
>
> I have written my own version of the Arclite (previously Vautomation v8
> uRISC) 8-bit CPU in VHDL, with a few new instructions thrown in. The
> processor runs fine in ModelSim, and I've executed some reasonably
> complex programs using a non-synthesizable ROM model. (I essentially
> run through a for loop during reset, and stuff values in one by one
> using a large case structure - it stinks, but it works well enough for
> testing)
>
> I've also managed to modify an open-source assembler and linker (WLA)
> to produce code for the beast. So, I'm now at the point where I would
> like to actually build a ROM, and start testing the processor core on
> actual hardware - and that's where it seems to break down.
>
> My assembler and linker produce an executable binary image. I would
> like to create a ROM model that contains that exact image (dead space
> and all), and I don't mind writing a tool to do it, but I'm not clear
> on the best way to proceed. Both the MIF and HEX formats would require
> a great deal of massaging - though a script could probably handle
> conversion to the .hex format.
>
> I would like to support both Altera and Xilinx tool flows, so I want to
> stay as vendor-neutral as possible.
>
> Is there an easy way to take my binary executable, and stuff it into a
> VHDL model for synthesis?
>
> Right now, I'm thinking about just writing a small bootloader ROM that
> will download code via a serial link to memory, but even that would be
> large enough that I would like to find a way to automate it.
> 



Article: 106006
Subject: Re: Chipscope
From: "Andy Peters" <Bassman59a@yahoo.com>
Date: 4 Aug 2006 13:00:22 -0700
Links: << >>  << T >>  << A >>
maxascent wrote:
> Thanks for your replies. It turns out that I needed to first program with
> impact and then start chipscope. Seems a bit stupid to have to do this but
> at least it works

Yeah, indeed.  I've found it easiest to use the Core Inserter, rather
than instantiating all of the ChipScope stuff in the VHDL (makes it
easier to change what you wish to monitor, too).  After the Core
Inserter does its thing, I re-implement, create a new PROM file and
re-program the EEPROM with Impact, then re-configure the device.  Then
ChipScope finds the core, no problem.

I know this all shouldn't be necessary, but that's the only way I get
it to work.

-a


Article: 106007
Subject: Re: Cyclone I & II memory fmax
From: "Martin Schoeberl" <mschoebe@mail.tuwien.ac.at>
Date: Fri, 4 Aug 2006 23:23:18 +0200
Links: << >>  << T >>  << A >>
Hi Subroto,

>
> The 210MHz is correct for Cyclone II M4K in SDP (simple dual port) mode
> with dual, non-PLL clocks.
> The speed for Cyclone II M4K in SDP mode with a single, non-PLL clock
> is 235Mhz.

Ok, thanks for the hint/correction. One should not try to
figure out performance numbers in the wrong context - no one
will drive a system with 200+ MHz without using the PLL.

With the PLL (and now Quartus 6.0sp1) the numbers
are (independent of single or dual clock):

    Cyclone I: fmax = 256 MHz
    Cyclone II: fmax = 235 MHz

Martin

BTW: It's very nice that Quartus instantiates the
simple dual port memory from plain VHDL - no vendor
specific components ;-)

For those who are interested here is the (very simple)
VHDL code:

library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;

entity sdpram is
generic (width : integer := 32; addr_width : integer := 7);
port (
    wrclk       : in std_logic;
    data        : in std_logic_vector(width-1 downto 0);
    wraddress   : in std_logic_vector(addr_width-1 downto 0);
    wren        : in std_logic;

    rdclk       : in std_logic;
    rdaddress   : in std_logic_vector(addr_width-1 downto 0);
    dout        : out std_logic_vector(width-1 downto 0)
);
end sdpram ;

architecture rtl of sdpram is

    signal reg_dout     : std_logic_vector(width-1 downto 0);

    subtype word is std_logic_vector(width-1 downto 0);
    constant nwords : integer := 2 ** addr_width;
    type ram_type is array(0 to nwords-1) of word;

    signal ram : ram_type;

begin

process (wrclk)
begin
    if rising_edge(wrclk) then
        if wren='1' then
            ram(to_integer(unsigned(wraddress))) <= data;
        end if;
    end if;
end process;

process (rdclk)
begin
    if rising_edge(rdclk) then
        reg_dout <= ram(to_integer(unsigned(rdaddress)));
        dout <= reg_dout;
    end if;
end process;

end rtl;



Article: 106008
Subject: Re: MPD file option HDL
From: "Nitesh" <nitesh.guinde@gmail.com>
Date: 4 Aug 2006 16:55:30 -0700
Links: << >>  << T >>  << A >>
sorry for not being clear about my question.  The ip core I had
designed was a mix of verilog and vhdl files as well as ngc files. So I
was having problem with the synthesis and the ngdbuild in XPS.
Finally I discovered that the mpd file should have the following
options to make it work.
OPTIONS HDL = MIXED
OPTION STYLE =MIX
I was assigning STYLE =HDL and  was getting errors in the ngdbuild
process.
Thanks a lot for your responses.




Felix Pang wrote:
> What did you mean "it doesn't work"?
>
> I do not see a problem in your options.
>
> -Felix
> Nitesh wrote:
> > I have an IP core made up of  verilog files as well as vhdl files. How
> > do I set my mpd file for the bitstream generation in XPS?
> > I tried putting
> >  OPTION HDL =MIXED
> > OPTION STLYE = HDL
> >  but it doesnt work .
> > Anyone done this before. 
> > Thanks,
> > Nitesh


Article: 106009
Subject: Re: Newbie question about SDRAM usage
From: "Tommy Thorn" <tommy.thorn@gmail.com>
Date: 4 Aug 2006 17:55:54 -0700
Links: << >>  << T >>  << A >>
drs39@cornell.edu wrote:
> I'm relatively new to FPGA programming and looking for some advice. I have
> an application that needs reliable, high bandwidth (+50 MHz),

Bandwidth is measured in bits/s or bytes/s.  How much are you storing
each cycle?

> The three
> possible ways I have come up with for implementing this part of my project
> are:
....
> 2. As before I could use the EDK memory controller core as a separate
> peripheral on the PLB however this time I could implement my peripheral as
> a master on the PLB bus. I believe that this would allow my peripheral to
> directly access the SDRAM controller without interference of/with the
> processor. However I do not know how difficult it is to write a PLB bus
> master and I do not know how to predict how detrimental other traffic on
> the PLB bus will be to the available bandwidth for my application.
..

To me this is the "obvious" right way to go unless you're really
pushing things to the edge (which will require special tricks with
DDR).  Rest assured, writing a PLB master is way way easier than
writing a DDR SDRAM controller (admitted I have no experience with PLB,
but otherwise there would be something very wrong with the PLB
design!).

> As I mentioned I am a relative beginner with FPGA programming and am looking
> for advice on how to proceed. I would also greatly appreciate any links to
> example projects or documentation that might be relevant to this project.

Methinks that this is not likely to be the best way to get started with
FPGAs.  You may start with a few simpler projects first, followed by a
few simple PLB peripherals.  Otherwise you'll spend a lot of time in
frustration.

Tommy


Article: 106010
Subject: Re: Where are Huffman encoding applications?
From: CBFalconer <cbfalconer@yahoo.com>
Date: Sat, 05 Aug 2006 00:40:40 -0400
Links: << >>  << T >>  << A >>
Weng Tianxiang wrote:
> 
> Your method is interesting, but is far from what I am looking for.
> 
> It is too slow. My target is 64-bit inputs on every clock and one must
> find its entry within 1-2 clocks and resolve entry conflicts if any at
> the same time.
> 
> This design, if succeeded, can be widely used for any dynamic Huffman
> encoding.
> 
> I think there is no such hardware design so far in the world and why I
> found that almost all Huffman encoding applications are static as in
> FAX, electronic books, ZIP files, JPEG, MPEG and so on.

Please do not top-post.  Your reply belongs after, or intermixed
with, the *snipped* material to which you reply.

Huffman encoding is rarely used today.  Adaptive Huffman is more
common.  For a complete review see: "The Compression Book" by Mark
Nelson and Jean-Loup Gailly, M & T Books, ISBN 1-5581-434-1.

-- 
Chuck F (cbfalconer@yahoo.com) (cbfalconer@maineline.net)
   Available for consulting/temporary embedded and systems.
   <http://cbfalconer.home.att.net> USE maineline address!


Article: 106011
Subject: Re: How to implement large ROM's from binary sources?
From: Ralf Hildebrandt <Ralf-Hildebrandt@gmx.de>
Date: Sat, 05 Aug 2006 08:26:28 +0200
Links: << >>  << T >>  << A >>
radarman wrote:

> Both the MIF and HEX formats would require
> a great deal of massaging - though a script could probably handle
> conversion to the .hex format.

ROM image download at runtime would be the smoothest way. But with this 
topic I can't help you.

I only want to give you the hint, that for pre-synthesis ROM creation 
with intel hex files and Altera FPGAs there is a bad pitfall: Altera 
says, that they accept intel hex, but they accept a variant of intel 
hex: addresses aligned to memory words (intel hex: always aligned to 
bytes) and big endian data order (intel hex: little endian).
(I found that bug in Altera MaxPlus. I don't know if it is fixed in 
Quartus.)


Ralf

Article: 106012
Subject: Re: DDR Controller
From: Nicolas Matringe <nicolas.matringe@fre.fre>
Date: Sat, 05 Aug 2006 10:34:06 +0200
Links: << >>  << T >>  << A >>
yy a écrit :
[...]
> With the PCI Master core connected to a DMA Engine and FIFO buffer that
> is connected to the 'DDR SDRAM Controller Interface' that is connected
> to the DDR Module itself, and if possible be connected to other DDR
> Controller Interface, can that be possible? such that when I access
> BAR1, for example i'm accessing DDR1 Interface, BAR2 for DDR2 Interface
> etc., along with this a Custom logic1 that use DDR1as its data must be
> able to access the same 'DDR Controller Interface1' , Custom Logic2
> that use DDR2 as its data must be able to access the same DDR
> Controller Interface2, etc.


Hi
There's really *nothing* fancy here.
Imagine a system with a microprocessor (with integrated cache), DDR and 
a PCI bus...

Nicolas

Article: 106013
Subject: Re: How to implement large ROM's from binary sources?
From: "Martin Schoeberl" <mschoebe@mail.tuwien.ac.at>
Date: Sat, 5 Aug 2006 11:22:53 +0200
Links: << >>  << T >>  << A >>
> Hi,
> on the www.fpgaarcade.com site there is a program called romgen (with source). The latest version is in the Space Invaders game.
> This will take a binary file and output VDHL source for either xilinx block rams or vendor neutral case statements or arrays.
> Cheers,
> MikeJ

That's a nice tool. However, it is not so easy to find - burried
too deep in the pacman .zip file. Would it be possible to provide
it in it's own .zip file.

I can use this kind of tool for a computer architecture lab
in the fall and would like to link to it.

BTW: perhaps there are some comments and suggestions on
this course. It is an open-content Wikiversity course at:
http://en.wikibooks.org/wiki/Wikiversity:Computer_Architecture_Lab

Cheers,
Martin 



Article: 106014
Subject: virtex ppclinux files
From: "Antti" <Antti.Lukats@xilant.com>
Date: 5 Aug 2006 02:51:56 -0700
Links: << >>  << T >>  << A >>
Hi

I have uploaded the files once available from Pauls website at the
university in Australia

http://hydraxc.xilant.com/CMS/index.php?option=com_remository&Itemid=41&func=select&id=11

the archive contains all that I fetched from the web when it was
available. I do not know exact reasons why the original pages are
vanished, but for me the files from there have been a big help to get
ppc linux working on Virtex-4

Antti


Article: 106015
Subject: Re: How to implement large ROM's from binary sources?
From: "MikeJ" <mikej@fpgaarcade.nospam.com>
Date: Sat, 05 Aug 2006 09:55:43 GMT
Links: << >>  << T >>  << A >>
>
> That's a nice tool. However, it is not so easy to find - burried
> too deep in the pacman .zip file. Would it be possible to provide
> it in it's own .zip file.

good point, I'll put the latest version on the Library page.
/mike 



Article: 106016
Subject: Re: Where are Huffman encoding applications?
From: "Weng Tianxiang" <wtxwtx@gmail.com>
Date: 5 Aug 2006 03:39:22 -0700
Links: << >>  << T >>  << A >>

CBFalconer wrote:
> Weng Tianxiang wrote:
> >
> > Your method is interesting, but is far from what I am looking for.
> >
> > It is too slow. My target is 64-bit inputs on every clock and one must
> > find its entry within 1-2 clocks and resolve entry conflicts if any at
> > the same time.
> >
> > This design, if succeeded, can be widely used for any dynamic Huffman
> > encoding.
> >
> > I think there is no such hardware design so far in the world and why I
> > found that almost all Huffman encoding applications are static as in
> > FAX, electronic books, ZIP files, JPEG, MPEG and so on.
>
> Please do not top-post.  Your reply belongs after, or intermixed
> with, the *snipped* material to which you reply.
>
> Huffman encoding is rarely used today.  Adaptive Huffman is more
> common.  For a complete review see: "The Compression Book" by Mark
> Nelson and Jean-Loup Gailly, M & T Books, ISBN 1-5581-434-1.
>
> --
> Chuck F (cbfalconer@yahoo.com) (cbfalconer@maineline.net)
>    Available for consulting/temporary embedded and systems.
>    <http://cbfalconer.home.att.net> USE maineline address!

Hi Chuck,
Thank you for your advice.

I have bought the book "The Compression Book". 

Weng


Article: 106017
Subject: Post PAR simulation, type not match
From: "Pasacco" <pasacco@gmail.com>
Date: 5 Aug 2006 06:53:52 -0700
Links: << >>  << T >>  << A >>
Hi

During loading for post route simulation (modelsim_SE, ISE7.1),
following errors occurred.
The design block contains "lots of" ports (which is more than 300).
So what I did was
I implemented after uncheking "Trim unconnected signals" and checking
"Create I/O Pads for Ports".
In UCF file, I connected clock and reset pins only.

It seems that the I/O of design module and test bench are not matching.
I checked NCD file using FPGA editor and it is (seems) quite okay.

Does anyone have this experience?
thankyou again in advance

----------------------------------------------------------------------------------------------------------
# Loading work.pe(structure)
# ** Failure: (vsim-3807) Types do not match between component and
entity for port rd_data_i
#    Time: 0 ns  Iteration: 0  Instance: /pe_tb/top File: # Loading
C:/Modeltech_6.1c/Compxlib/simprim.x_tri_pp(x_tri_pp_v)
# Loading C:/Modeltech_6.1c/Compxlib/simprim.x_inv_pp(x_inv_pp_v)
# Fatal error at c:/Xilinx/vhdl/src/simprims/simprim_VITAL_mti.vhd line
109182
#  while elaborating region: /pe_tb/top/rd_data_0_13_obuf
# Load interrupted
---------------------------------------------------------------------------------------------------------


Article: 106018
Subject: verilog versus vhdl
From: Markus Zingg <m.zingg@nct.ch>
Date: Sat, 05 Aug 2006 19:02:31 +0200
Links: << >>  << T >>  << A >>
Hi Group

I have to implement a design which requires an FPGA, but to do so
among other things I obviousely first have to learn one of the two
mentioned languages. I got the impression that europe seems to be more
vhdl centric whereas verilog seems to be more popular in the US but
this argument alone is for reasons beond the scope of this question
not so important to me. I have a strong background in C programming
(should that matter anyhow) and in general experience with embedded
systems, but FPGAs are new to me. I'm otherwise completely open and
alas wonder what you guys suggest I should choose. I'm mostly
interested in replies from people which know both languages cause
otherwise I fear that this thread ends up in some sort of religious
war...

TIA

Markus


Article: 106019
Subject: Re: verilog versus vhdl
From: Tim Wescott <tim@seemywebsite.com>
Date: Sat, 05 Aug 2006 10:17:46 -0700
Links: << >>  << T >>  << A >>
Markus Zingg wrote:
> Hi Group
> 
> I have to implement a design which requires an FPGA, but to do so
> among other things I obviousely first have to learn one of the two
> mentioned languages. I got the impression that europe seems to be more
> vhdl centric whereas verilog seems to be more popular in the US but
> this argument alone is for reasons beond the scope of this question
> not so important to me. I have a strong background in C programming
> (should that matter anyhow) and in general experience with embedded
> systems, but FPGAs are new to me. I'm otherwise completely open and
> alas wonder what you guys suggest I should choose. I'm mostly
> interested in replies from people which know both languages cause
> otherwise I fear that this thread ends up in some sort of religious
> war...
> 
> TIA
> 
> Markus
> 
Do not fear:  It'll end up in a religious war no matter what.

FWIW I'm a trained analog circuits & systems guy who usually adds value 
by architecting systems, designing control and communications 
algorithms, or implementing said algorithms in C or C++.  For years my 
job title was "software engineer" and the only circuit design I did was 
at home.

When I picked up FPGA design it was using Verilog because the two people 
I had to lean on for help were Verilog people.  I found it very easy and 
obvious, as long as I remembered that I was writing hardware 
descriptions, not writing "code".

-- 

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: 106020
Subject: Re: MIG 1.6 DDR2 testing problems (FIFO16 related?)
From: "=?iso-8859-1?B?R2FMYUt0SWtVc5k=?=" <taileb.mehdi@gmail.com>
Date: 5 Aug 2006 10:34:40 -0700
Links: << >>  << T >>  << A >>
Joseph Samson wrote:
> heinerlitz@gmx.de wrote:
> > Hi,
> > I finally got to run the MIG created DDR2 for VIrtex4 devices
> > controller. However I have two problems with the controller:
> >
> > 1. I am observing the ERROR signal which is created by the dataCompare
> > module. It goes high every 8th read pulse. Could this be related to the
> > FIFO16 bug?
>
> I don't have the DDR2 source code with me at home, but I'm pretty sure
> that the FIFO16 use was limited to the write data and the
> address/command. The write data FIFO has 2 different clocks, but the
> FIFO read clock is 90 degrees out of phase with FIFO write clock, so I
> think it is not a problem. I had problems with the address/command FIFO.
> The FIFO would be empty, but the DDR2 controller thought that the FIFO
> had data, so it would repeatedly read the same address.
>
> Is there a way to fix the fifo in the design? It would be
> > easy to fix the fifo issue in my own design but as I havent written the
> > ddr controler i have no glue what the requirements of the fifo16 are
> > and how the issue should can be fixed in the best way. Inverting the
> > readclock (as I read somewhere) didnt work and I do not know if the
> > coregenerated fifos are fast enough and if they can be simply exchanged
> > (no fall through for example).
>
> I created a Block RAM FIFO with CoreGen; it was pretty simple;just look
> at the MIG verilog or VHDL code. The FIFO16 is instantiated directly and
> the parameters are specified in the code. Fall through is supported in
> CoreGen.
>
>
> >
> > 2. My other problem is of different nature. The simulation environment
> > which is supplied by xilinx does not work with some RAMs. I had no
> > problem simulating a 8bit Micron DDR2 chip however the 16bit chip I am
> > currently using does not work. THe whole testbench verilog files are
> > corrupted showing false instantiations (wrong names, wrong bit sizes)
> > has anybody experienced the same problems?
>
> I built a DIMM simulation out of 8-bit parts. Why not just use 2 8-bit
> parts instead of a 16-bit? Even if you're trying to simulate with real
> PCB delays, 2 parts could work.
>
> >
> > Both problems could be probably solved by disassembing the whole
> > design, but that takes hours, so If anybody has already a solution for
> > the above problems I would be very happy.
>
> I'm not happy with the whole calibration procedure that DDR2 MIG has.
> The IDELAY part that looks at the data strobes seems to work OK, but
> then they write a pattern to memory, read it back and try to figure out
> how many clocks to wait after the read command before the data is
> available and can be shifted into the read data FIFO. Sometimes (most of
> the time) that logic would make the wrong choice and miss some of the
> read data. I eventually hard coded the delay and it worked fine after that.

Did you hard coded the number of needed clock cycles or the delay in
the IDELAY??
Thanks for help!
> 
> ---
> Joe Samson
> Pixel Velocity


Article: 106021
Subject: FPGA interface to serial ADC
From: "Ki" <kyomubi_ki@yahoo.co.uk>
Date: 5 Aug 2006 11:01:38 -0700
Links: << >>  << T >>  << A >>
I'm trying to get an FPGA (Spartan-II) to communicate with an ADC
(Serial interface, with a maximum throughput rate of 2Msps and the
maximum signal bandwith I'm sampling is 200kHz). I've been using a
counter to generate both the SCLK and CS signals and find that the ADC
doesn't seem to be sampling. The SCLK signal on the ADC board looks
distorted when I probe it with the scope and more worrying, I also see
the same distorted SCLK signal on the output data only biased about
ground! SCLK looks something like:

|||
| |
|  |
|   ||||
|      |        |
|      |        |
|      |        |
|      |        |
|      |        |
       |    ||||
       |   |
       |  |
       |||

I've just been reading elsewhere on this forum that it is not advisable
to drive the ADC clock inputs with an FPGA. I was wondering if the term
'clock' also refers to the SPI SCLK signal? The recommendations on the
forum say to use an (analog?) PLL to drive the ADC clock and the FPGA
separately. Would a clock distribution IC like AD9513 (I need 2 ADC
clocks and 1 FPGA clock, all CMOS compatible) do the job, or can I use
an EPROM clock generator like CY2071A?

Thanks
Ki


Article: 106022
Subject: Re: FPGA interface to serial ADC
From: "MM" <mbmsv@yahoo.com>
Date: Sat, 5 Aug 2006 14:15:14 -0400
Links: << >>  << T >>  << A >>
> The SCLK signal on the ADC board looks
> distorted when I probe it with the scope

What you see is normal undershoot/overshoot, not really much to worry about
unless it goes well beyond the spec of the device. However, I am not sure
you are doing proper measurement. Whether what you see on the scope is
really what's going on depends on the probe, how it is connected, and the
scope itself, but I bet your problem is not related to the shape of this
signal.

> I've just been reading elsewhere on this forum that it is not advisable
> to drive the ADC clock inputs with an FPGA. I was wondering if the term
> 'clock' also refers to the SPI SCLK signal?

No. It only applies to a sampling clock and only if jitter/phase noise of
the clock is critical for the application.


/Mikhail



Article: 106023
Subject: Re: verilog versus vhdl
From: nico@puntnl.niks (Nico Coesel)
Date: Sat, 05 Aug 2006 20:13:16 GMT
Links: << >>  << T >>  << A >>
Markus Zingg <m.zingg@nct.ch> wrote:

>Hi Group
>
>I have to implement a design which requires an FPGA, but to do so
>among other things I obviousely first have to learn one of the two
>mentioned languages. I got the impression that europe seems to be more
>vhdl centric whereas verilog seems to be more popular in the US but
>this argument alone is for reasons beond the scope of this question
>not so important to me. I have a strong background in C programming
>(should that matter anyhow) and in general experience with embedded
>systems, but FPGAs are new to me. I'm otherwise completely open and
>alas wonder what you guys suggest I should choose. I'm mostly
>interested in replies from people which know both languages cause
>otherwise I fear that this thread ends up in some sort of religious
>war...

I have a feeling VHDL is slightly more used than Verilog. You should
pick a language that you feel comfortable with. I never quite got the
grasp of Verilog (to me it seems like a description of a circuit
diagram instead of a structured language) so I choose to use VHDL.

-- 
Reply to nico@nctdevpuntnl (punt=.)
Bedrijven en winkels vindt U op www.adresboekje.nl

Article: 106024
Subject: Re: FPGA interface to serial ADC
From: "homoalteraiensis" <fpgaengineerfrankfurt@arcor.de>
Date: 5 Aug 2006 14:07:23 -0700
Links: << >>  << T >>  << A >>
I had no problem in driving a typical serial ADC's system clk and
control impulses @60Meg and above, which is already very close to the
ADCs spec!

A common problem is, to generate an approp riate clock with a valid
duty cycle. Here a PLL can be used to obtain a freq which ist no
directly synthesizeable from the FPGAs system clock (just like 100Megs
from out of 60Meg internal or 20Meg external).

But typically, you will run a ADC with half of the system freq, in
order to be able to do processing and decisions within one bit clock,
and toggle the required signal outputs for any of the peripheric
devices easily.(e.g. Bit0 of a counter, running at clock speed)

A special case is running the data aquisition fully pipelined, where
ADC's clock is equal to the fpga clock: With most programmable devices,
you will somehow violate the system clock net in simply passing out the
freq itself!   You will have to use dual data rate cells instead (which
also should be placed in the io-blocks for best performance).

If you are not familiar with this: The ddr-cell is a switch for two
channels controlled by a) the high level and b) as well the low level
of the cells's clock. By feeding the ddr cell with static 1 and 0 at
its inputs, it is somehow "abused" to switch a 1 at clk hi, and a zero
at clk lo. Thus it doubles the frequency to obtain the virtual factor 2
mentioned above (toggeling).

With a (pll based) well clk inside the FPGA, you will have a nice and
perfectly driven system clk outside too, with a dc of 50:50 (nearly).

The next issue is aquiring the ADCs output correctly according to the
given delay at the board: Some  ADCs pass out their data at the falling
edge, and with a tycical delay of 10ns, so you will find the data valid
in beneath of the next rising edge of the receiving flip flops. To
avoid this, simply generate a doubled system clk and generate a delayed
clock for the ddr-cells' clock to delay the ADCs clock. You may also
invert 0/1 to push the phase in a way, that the incoming data perfectly
meets to aquiring clock.




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