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 151175

Article: 151175
Subject: Re: Video Framebuffer using Nexys2 (Spartan-3E)
From: "Ste" <lordste2@n_o_s_p_a_m.n_o_s_p_a_m.hotmail.com>
Date: Mon, 14 Mar 2011 01:11:18 -0500
Links: << >>  << T >>  << A >>
>>> I think it should be fine. Use the MIG to an interface for your
external
>>> RAM. Feed the incoming video into the MIG's FIFO and it'll write using
>>> burst mode. The 70 ns latency is only for switching to a new page - if
>>> you feed in a whole row of sequential writes this won't be such a big
>>> deal, and you can clock the RAM as fast as it'll go. Then read it back
>>> during the blanking period, or even in between writes if your
>>> calculations show that you'll have enough time.
>>>
>>> Joel
>>
>> Correct me if I'm wrong, but the last time I looked, MIG
>> only supported the standard DDR, and DDR2 parts for
>> Spartan 3, not the "specialty" parts like Cellular
>> PSDRAM.  Does the Nexsys2 kit come with some other
>> IP to talk to the PSDRAM?  Or do they just assume
>> that it's a simple enough interface to roll your
>> own?  In burst mode it should certainly be more than
>> fast enough to do what you want.  You could even
>> intersperse reading and writing as long as you
>> keep one direction long enough to keep up the
>> required throughput rate.  Just buffer the reads
>> and writes with block RAM.  You need some sort
>> of simple arbiter to switch between the read
>> and write processes at a "burst" level.  Then
>> the camera input can be effectively asynchronous
>> to the VGA screen refresh.
>>
>> -- Gabor
>
>Sorry, you're right, of course!
>
>The Nexys2's built in self test code contains a memory controller 
>(NexysOnBoardMemCtrl.vhd) but it's not clear at first glance if it's 
>advanced enough to support burst mode. Probably not.
>
>You could also try http://opencores.org/project,opb_psram_controller , 
>which looks like it would support the Nexys2.
>
>There might also be some helpful hints in the comments of this video: 
>http://www.youtube.com/watch?v=nyrllob-Juk
>
>Joel
>

Hmmm...let me just recap to make sure I understand everything thus far. 
Okay, so the general strategy is to sequentially push/pull the data to/from
DDR memory while using some BlockRAM to hold data between bursts.  Also,
some logic will be needed to determine when would be the best time to
switch between reading and writing.  Normally, one would create a DDR
memory controller using the MIG in Xilinx's Core Generator.  However, my
board doesn't have a standard DDR memory module and instead has a
PseudoSRAM (which the MIG doesn't support).  This particular external RAM
has a mode that acts like asynchronous SRAM which is slow but easy to write
a controller for.  It also has a burst mode that acts like synchronous
DRAM, which is fast but needs a more complicated controller.  All Digilent
supplies you with is a VHDL module that probably doesn't even support burst
mode.  I have a textbook that explains how to use the slow asynchronous
mode, but of course that won't cut it.

Since I know nothing about VHDL (I'm a Verilog boy), should I even attempt
learning VHDL to analyze the above sample code or should I just jump
straight into writing it in Verilog from scratch?  If I were to create a
VHDL controller based on the links above, can I even instantize a VHDL
module from my Verilog top module?  I don't want to have to rewrite the
rest of my code.  I should mention that we only have 40 days left until we
have to present this project, although Spring break is next week and I
should have tons of spare time.  Showing half the screen is good enough for
me, but I would like the whole picture to be available.  Because I know
nothing about DDR style memory controllers, is there anything else you guys
can point me to for help in designing a burst mode controller from scratch
(preferably more concepts than code)?  Or am I just stuck with what that
datasheet gives me?

Sorry for the run-on sentences, all the questions, and my stupidity.  But
thanks for all the help thus far!
	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 151176
Subject: Command line for fuse (behavioral sim), for ISE WebPack 9.2/xtclsh? (dbl)
From: "sdaau" <sd@n_o_s_p_a_m.n_o_s_p_a_m.imi.aau.dk>
Date: Mon, 14 Mar 2011 02:28:44 -0500
Links: << >>  << T >>  << A >>
Hi all, 

First, sorry for the double post - it's been a while, and I first tried to
post through fpgacentral.com, forgetting that it does *NOT* apparently
forward the message to usenet: 

http://www.fpgacentral.com/group/fpga/command-line-fuse-behavioral-sim-ise-webpack-9-2-xtclsh-1129531/

.. so, now I'm trying again through fpgarelated.com, as it has worked for
me with usenet in the past ... so here is the message:

**********

I'm still using ISE WebPack 9.2, and I'd like to use "Simulate Behavioral
Model" from the command line:

> % process run "Simulate Behavioral Model"
> ERROR:TclTasksC - ERROR:TclTasksCrocess_064 - process run : Unknown
process "Simulate Behavioral Model".
> Type [help project get_processes] for more information.

I can then enter "get_processes" in the Tcl Shell:

% project get_processes
{Synthesize - XST} {Check Syntax} {Generate Post-Synthesis Simulation
Model} {Implement Design} Translate {Generate Post-Translate Simulation
Model} Map {Generate Post-Map Static Timing} {Generate Post-Map Simulation
Model} {Place & Route} {Generate Post-Place & Route Static Timing}
{Generate Primetime Netlist} {Generate Post-Place & Route Simulation Model}
{Generate IBIS Model} {Back-annotate Pin Locations} {Generate Programming
File}

.. to obtain what commands would be executable in a xtclsh script via
'process run'. Unfortunately, I do not see "Simulate Behavioral Model" or
"Simulate Post-Place & Route Model" in there, so I assume 'fuse' needs to
be called separately.

So, I've looked through

http://www.xilinx.com/support/documentation/sw_manuals/xilinx11/devref.pdf
http://www.xilinx.com/itp/xilinx10/books/docs/dev/dev.pdf
http://www.xilinx.com/support/documentation/sw_manuals/xilinx11/plugin_ism.pdf
http://www.demandperipherals.com/docs/CmdLineFPGA.pdf

.. and I simply cannot find anywhere how to obtain the correct 'fuse'
command for what would correspond to "Simulate Behavioral Model" or
"Simulate Post-Place & Route Model" GUI items in ISE WebPack.

And unfortunately, when I run say "Simulate Behavioral Model", only the
following is displayed in the Console:

> Running Fuse ...
> Compiling project file "./mytest_tbw_beh__vlog.prj"
> ...
> Building mytest_tbw_isim_beh.exe
> Running ISim simulation engine ...

.. but unfortunately, no actual command line arguments (and nothing in log
files either, say by `grep -r 'fuse' .` in the project directory).

Does anyone have an idea (or reference to) what do the fuse command lines
look like for "Simulate Behavioral Model" and "Simulate Post-Place & Route
Model" respectively?

Thanks,
Cheers!
	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 151177
Subject: Re: pcb&bitstream
From: "RCIngham" <robert.ingham@n_o_s_p_a_m.n_o_s_p_a_m.gmail.com>
Date: Mon, 14 Mar 2011 05:40:55 -0500
Links: << >>  << T >>  << A >>
[snip]

>anyway as you can restrict small consumers to use the hardware you
>sell as you want i will restrict all my projects to be open only for
>non-xilinx&affiliated companies !
>sadly for you i didn't bought altera, you have one week to decide if
>you can publish the bit-stream specs of old products before i restrict
>all my open-sources projects with a "no-xilinx&al license" !
>if xilinx can't respect me cause i'm not a big buyer it's not my
>problem !
>thanks again Ed !

ROFLMAO!
	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 151178
Subject: Re: FPGA boards
From: Simon <wlpstxzhd@gmail.com>
Date: Mon, 14 Mar 2011 03:49:23 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 13, 6:32=A0pm, General Schvantzkoph <schvantzk...@yahoo.com>
wrote:
> I'm looking for cards for a couple of different applications, dual 10G
> Ehternet (requires dual SFP+) connectors and QDR InfiniBand (dual QSFP+).
> Both applications require 10G SerDes which means either a Stratix4GT or a
> Virtex6HXT, either is acceptable.
>
> Hitechglobal has some interesting cards that meet these requirements, wha=
t
> other vendors should I explore?

Both Xilinx and Altera have announced their own 10/100G FPGA
evaluation board solutions, check it out.
Apart from those two, Dinigroup is another vendor who delivers 10G
solution.

Simon

http://www.apsolo.com

Article: 151179
Subject: Re: pcb&bitstream
From: kclo4 <alexis.gabin@gmail.com>
Date: Mon, 14 Mar 2011 04:25:47 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi,

I think you do things completely in the wrong order, you buy fpga
without knowing how to use them and then complains you can not use
them because they don't want to give you all informations about it.

I also believe your project is quite ambitiuous for a beginner, you
want to create:

-a synthetizer (and doing one that convert algortihm designed in C or
equivalent is not an easy task)
-a place and route tool
-and design a pcb

I believe this represent a lot of different skills, company are
spending millions of dollars to have efficient software with hundred
of engineers working full time on those differents parts, I don't
think a single guy can do it on his own. Ok let's say you can (after
all you probably don't need your tool to be as efficient as
professional one).

You first should design a board and for this you'll find all needed
informations on xilinx website. (if i were you i will directly buy a
dev kit, gain a lot of time and you will have a working board)
Then make some simple design with vendors tools to see how FPGA works.
Learn about FPGA architecture.
Then learn about netlist and try to generate one and compile it.
Then do your software that would be able to generate a netlist
optimized for the co-processing you want to do on the fly.
Then maybe generate bitstream by playing in floorplanner to try to see
how the bitstream describe the interconnection and LUT content of fpga.
(this is the only part were information is not available)

After doing all that I will meet you in Arkham asylium...





Article: 151180
Subject: Re: pcb&bitstream
From: "Nial Stewart" <nial*REMOVE_THIS*@nialstewartdevelopments.co.uk>
Date: Mon, 14 Mar 2011 14:52:51 -0000
Links: << >>  << T >>  << A >>
> If you think that you will get farther in your goal by using FPGAs
> from Altera, Lattice, Microsemi (aka Actel), or QuickLogic then you
> should absolutely switch over.


Ed, I read this as "Please use someone else's devices so I can stop
answering these ****ing stupid questions".


:-)


Nial. 



Article: 151181
Subject: Re: pcb&bitstream
From: geobsd <geobsd.os@gmail.com>
Date: Mon, 14 Mar 2011 08:59:48 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 14, 12:25=A0pm, kclo4 <alexis.ga...@gmail.com> wrote:
> Hi,
>
> I think you do things completely in the wrong order, you buy fpga
> without knowing how to use them and then complains you can not use
> them because they don't wan t to give you all informations about it.
>
i knew they must be "programmed", the restrictions i didn't

> I also believe your project is quite ambitiuous for a beginner, you
> want to create:
>
> -a synthetizer (and doing one that convert algortihm designed in C or
> equivalent is not an easy task)
> -a place and route tool
no ;)
i wanted to use chunks of bit-stream assembled in my model conformance
to process in place of the cpu

> -and design a pcb
i'm not the first
>
> I believe this represent a lot of different skills, company are
> spending millions of dollars to have efficient software with hundred
> of engineers working full time on those differents parts, I don'tat'
> think a single guy can do it on his own. Ok let's say you can (after
> all you probably don't need your tool to be as efficient as
> professional one).
>
let me try before judging ;)

> Then maybe generate bitstream by playing in floorplanner to try to see
> how the bitstream describe the interconnection and LUT content of fpga.
> (this is the only part were information is not available)
that's the problem !
>
> After doing all that I will meet you in Arkham asylium...
why not friends
thanks

Article: 151182
Subject: Re: pcb&bitstream
From: NeedCleverHandle <d_s_klein@yahoo.com>
Date: Mon, 14 Mar 2011 10:03:05 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 14, 7:52=A0am, "Nial Stewart"
<nial*REMOVE_TH...@nialstewartdevelopments.co.uk> wrote:
> > If you think that you will get farther in your goal by using FPGAs
> > from Altera, Lattice, Microsemi (aka Actel), or QuickLogic then you
> > should absolutely switch over.
>
> Ed, I read this as "Please use someone else's devices so I can stop
> answering these ****ing stupid questions".
>
> :-)
>
> Nial.

My experience with the brand-X sales force leads me to believe that
they have significant training in politeness and political
correctness.  Many times I have watched in amazement as impossible
demands were deflected without insult.

I ain't made of that stuff.

RK

Article: 151183
Subject: Re: pcb&bitstream
From: "Nial Stewart" <nial*REMOVE_THIS*@nialstewartdevelopments.co.uk>
Date: Mon, 14 Mar 2011 17:27:50 -0000
Links: << >>  << T >>  << A >>
> My experience with the brand-X sales force leads me to believe that
> they have significant training in politeness and political
> correctness.  Many times I have watched in amazement as impossible
> demands were deflected without insult.
> I ain't made of that stuff.


Indeed, Ed is showing commendable restraint!


Nial. 



Article: 151184
Subject: Re: pcb&bitstream
From: Ed McGettigan <ed.mcgettigan@xilinx.com>
Date: Mon, 14 Mar 2011 10:37:41 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 14, 7:52=A0am, "Nial Stewart"
<nial*REMOVE_TH...@nialstewartdevelopments.co.uk> wrote:
> > If you think that you will get farther in your goal by using FPGAs
> > from Altera, Lattice, Microsemi (aka Actel), or QuickLogic then you
> > should absolutely switch over.
>
> Ed, I read this as "Please use someone else's devices so I can stop
> answering these ****ing stupid questions".
>
> :-)
>
> Nial.

Nial, In my defense I did proceed to give a long list of reasons why
switching to another vendor would be a bad idea in this case.  IMHO,
if your designing reconfigurable computing applications it would be
foolish to not use Xilinx due to the wealth of material that we
already provide publicly to support these applications.

Ed McGettigan
--
Xilinx Inc.

Article: 151185
Subject: ping pong buffer overflow issue
From: "salimbaba" <a1234573@n_o_s_p_a_m.n_o_s_p_a_m.owlpic.com>
Date: Mon, 14 Mar 2011 13:35:51 -0500
Links: << >>  << T >>  << A >>
Hi,
I am working on Gigabit MAC RTL, and i am using spartan3 xc3s4000 in my
design. I have a Ping Pong buffer implemented in the pipeline stage, but
the problem is that my buffers overflow when i send bursty traffic. Well,
on paper and simulations, they never overrun, but when i use IxChariot to
calculate throughput, they overrun after a while.
Now i need an advice, should i add more buffers like ping pong king kong or
what? 
Also, i start reading Ping/Pong after 50 writes. My buffers are using
different read and write clocks, write clock being twice of read clock.



If anyone has any idea, kindly help me out.

thanks
	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 151186
Subject: Re: pcb&bitstream
From: geobsd <geobsd.os@gmail.com>
Date: Mon, 14 Mar 2011 12:49:00 -0700 (PDT)
Links: << >>  << T >>  << A >>
On 12 Mrz., 05:27, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote:
"companies have been started and failed over the years
trying to mate FPGAs with CPUs"
http://www.xilinx.com/technology/roadmap/processing-platform.htm

Article: 151187
Subject: Re: pcb&bitstream
From: whygee <yg@yg.yg>
Date: Mon, 14 Mar 2011 21:35:42 +0100
Links: << >>  << T >>  << A >>
Hi,

geobsd wrote:
> On 12 Mrz., 05:27, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote:
> "companies have been started and failed over the years
> trying to mate FPGAs with CPUs"
> http://www.xilinx.com/technology/roadmap/processing-platform.htm
Altera and Actel too have coupled FPGA+CPU chips (as far as i know).
Years ago, there was one family of FPGA with
a PowerPC core, and now ARM is finding its way
in many new products. The market evolves
(it was easier to include the CPU in the FPGA array until recently)
and needs big companies to try (and sometimes fail)

What is your point ?

yg
-- 
http://ygdes.com / http://yasep.org

Article: 151188
Subject: Re: Nanosecond pulse generator using Spartan-3E
From: Philip <philip.freidin@gmail.com>
Date: Mon, 14 Mar 2011 15:08:57 -0700 (PDT)
Links: << >>  << T >>  << A >>

One way to do this is to use chips specifically designed to do this
function:


ECL interface:
   http://www.analog.com/en/obsolete/ad9500/products/product.html

and

TTL interface
   http://www.analog.com/en/obsolete/ad9501/products/product.html


but they are both obsolete. They have 256 steps, with a minimum step
size of
10 ps (256 x 10 ps = 2.5 ns full scale) up to a step size of 4us
giving a
full scale value of 1 ms.

Rochester shows 22K pieces in stock of the AD9500, and 26 pieces of
the AD9501.

Oh, and I have about a 100 pieces of the AD9501JN in a box in my hands
right
now  :-)

The data sheets show enough details, that you could build your own
circuit
with a DAC, a ramp generator, and some high speed comparators.

Another group of parts that are:

MC10EP195 (current), MC10EP196 (obsolete),

MC100EP195 (current), MC100EP196 (current)

These parts have a fixed delay of 10 ps per step, with 1024 steps.
They
can be cascaded for longer total delays, but is realllllly tricky.


Have fun,
Philip


On Mon, 28 Feb 2011 08:36:44 -0600, "Alex"
<aivochkin@n_o_s_p_a_m.gmail.com> wrote:
>Hello, I'm a novice in FPGA, so please forgive me if I'm asking simple
>questions.
>
>I've got Spartan-3E Evaluation Kit and I need to realize a programmable
>generator of pulses of nanosecond duration. The problem is as follows: I've
>got a trigger pulse and I need to generate a TTL pulse of nanosecond
>duration with programmable width (with step about 200-500 ps, range 2 ns -
>100 ns (for example)) and programmable delay (with 200-500 ps step). The
>maximum delay from in to out must not be more than 10 ns.
>Actually I need to realize a wide-range pulse generator, but as I
>understand there is no problem generate wide pulses (more than 100 ns) with
>larger step (10 ns) working in synchroneous regime and using clock. But for
>narrow pulses I think I should work in asynchroneous regime. I could use
>elements with known delay and link them into a chain.
>If it possible to realize such project using Spartan-3E FPGA chip, or maybe
>I need something from Virtex family.
>
>Thank you in advance.
>Alex.


Article: 151189
Subject: Alternative To Altera's Cyclone III Starter Board
From: "Abby Brown" <abbybrown@charter.net>
Date: Mon, 14 Mar 2011 18:38:06 -0400
Links: << >>  << T >>  << A >>
Hi,

Does someone produce a cheaper and simpler substitute for 
Altera's Cyclone III starter board?  It needs to connect to a 
laptop to download configuration and test cases and upload 
results (ICT).  A driver that connects to Windows .Net would be 
ideal.

Thanks,
Gary



Article: 151190
Subject: Re: Command line for fuse (behavioral sim), for ISE WebPack
From: Brian Davis <brimdavis@aol.com>
Date: Mon, 14 Mar 2011 16:45:56 -0700 (PDT)
Links: << >>  << T >>  << A >>
sdaau wrote:
>
> Does anyone have an idea (or reference to) what do the
> fuse command lines look like for "Simulate Behavioral Model"
> and "Simulate Post-Place & Route Model" respectively?
>

 If "tb.exe" is the name of the generated ISIM executable,
command line options can be listed at the command prompt with:
tb -h

 IIRC the only ISIM docs with 9.2 were the tool help files,
although the newer ISIM manuals should also be of help.
ISIM doc pointers:
 http://www.xilinx.com/support/answers/30942.htm


 Below are the files I use to do a RTL compile and run
with ISIM 9.2 :

<isim_comp.bat>    compiles project
<isim_rtl.prj>     list of project files for ISIM

<isim_run.bat>     runs simulation executable
<isim_run.tcl>     simulation commands

Note, these files don't check for tool error return codes.

Brian

---------------------------
<isim_comp.bat>

::
:: set environment path variables for core & target
::
set YC=%YARD_HOME%\HDL\cores\yard-1a
set YV=%YARD_SIM_TARGET%

::
:: this needs work to automatically compile
:: using a local file list for each target
::
:: just uses ISIM prj file for now
::
:: ISIM splatters run directory with temp files,
:: should move this to its' own isim_run directory
::
fuse  -prj isim_rtl.prj  -work work=work.isim  -o tb.exe  -top
testbench

---------------------------
<isim_rtl.prj>

vhdl work "$YC/y1_config.vhd"
vhdl work "$YC/y1_constants.vhd"
vhdl work "$YC/y1a_comps.vhd"
vhdl work "$YC/y1_probe_pkg.vhd"
vhdl work "$YC/pw2_rom.vhd"
vhdl work "$YC/flip.vhd"
vhdl work "$YC/ffb.vhd"
vhdl work "$YC/bitcnt.vhd"
vhdl work "$YC/rstack.vhd"
vhdl work "$YC/rf.vhd"
vhdl work "$YC/y1_probe.vhd"
vhdl work "$YC/y1_core.vhd"

vhdl work "$YV/stub_uart_tx.vhd"
vhdl work "$YV/stub_uart_rx.vhd"
vhdl work "$YV/rom_dat.vhd"
vhdl work "$YV/rtl_mem.vhd"
vhdl work "$YV/evb.vhd"
vhdl work "$YV/evb_tb.vhd"

---------------------------
<isim_run.bat>

::
:: run the ISIM generated executable
::
tb -tclbatch isim_run.tcl > isim_sim.out

---------------------------
<isim_run.tcl>

run 20000 ns
quit

---------------------------



Article: 151191
Subject: Re: ping pong buffer overflow issue
From: KJ <kkjennings@sbcglobal.net>
Date: Mon, 14 Mar 2011 16:55:36 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 14, 2:35=A0pm, "salimbaba"
<a1234573@n_o_s_p_a_m.n_o_s_p_a_m.owlpic.com> wrote:
> Hi,
> I am working on Gigabit MAC RTL, and i am using spartan3 xc3s4000 in my
> design. I have a Ping Pong buffer implemented in the pipeline stage, but
> the problem is that my buffers overflow when i send bursty traffic. Well,
> on paper and simulations, they never overrun,

Then your paper calculations and your simulations are not modelling
the reality.

> Now i need an advice, should i add more buffers like ping pong king kong =
or
> what?

First you need to go back and create a more accurate spreadsheet model
for your paper calculations, then run some simulations to see if you
missed something in your spreadsheet model.

> Also, i start reading Ping/Pong after 50 writes.

Is that included in your spreadsheet model?  Presumably it is in your
simulations if you're simulating your actual design.

> My buffers are using
> different read and write clocks, write clock being twice of read clock.
>

That only means that the idle time must be at least equal to the
transmit time.  If the burst size is too big, it will still overflow a
buffer that is not large enough.

> If anyone has any idea, kindly help me out.
>

Go back to a simple spreadsheet model first and make sure buffer sizes
are large enough to handle the actual burst sizes.  With a
spreadsheet, clock rates (input/output), burst size and latency values
you should be able to calculate worst case buffer sizes.  Then insure
that your buffers are that size or larger.

Kevin Jennings

Article: 151192
Subject: Re: pcb&bitstream
From: Kolja Sulimma <ksulimma@googlemail.com>
Date: Mon, 14 Mar 2011 17:46:49 -0700 (PDT)
Links: << >>  << T >>  << A >>
On 13 Mrz., 01:46, rickman <gnu...@gmail.com> wrote:
> since a bad bitstream has potential of frying an FPGA.

This argument is invalid.

You can fry an FPGA with VDHL and vendor synthesis software.
This has been demonstrated at the FPL conference a decade ago.

I guess the truth is closer to this argument: documenting the
bitstream format
is a lot of work and is likely to create only very few additional
revenue
from customer that are rather support intensive so it simply isn't
worthwhile for
the vendors.

I believe that documenting LUT content locations in the bitstream
would be a good
compromise. It is relatively easy to document and use and not much can
go wrong
and it has a decent amount of applications where it is useful.
OTOH: The introduction of SRL16 made it easy to support LUT-reloading
explicitely in the HDL.

Kolja








Article: 151193
Subject: Re: pcb&bitstream
From: Ed McGettigan <ed.mcgettigan@xilinx.com>
Date: Mon, 14 Mar 2011 18:23:06 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 14, 12:49=A0pm, geobsd <geobsd...@gmail.com> wrote:
> On 12 Mrz., 05:27, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote:
> "companies have been started and failed over the years
> trying to mate FPGAs with CPUs"http://www.xilinx.com/technology/roadmap/p=
rocessing-platform.htm

Christophe,

When I wrote my original statement I was referring to the system
architecture that you were trying to achieve, that is a high
performance CPU connected directly with a FPGA for dynamic algorithm
acceleration.

Implementing CPUs inside of a FPGA has been a relatively common
occurance as is using a low end CPU or microcontroller to configure
and control the operation of a FPGA.  Both of these are very different
from your stated goals.

Altera came out with an initiative called Excalibur that did not last
very long. One version included a hard ARM922T and processor sub-
system with FPGA fabric for soft peripherals. Two other versions with
MIPs and PowerPC were to be released but never were and the ARM
version lasted a very short time in the market.  The last leg of this
program was the NIOS soft processor which is still in existence and
recently updated to NIOS-II.

Triscend came out with a product that combined a hard ARM7 processor
with a FPGA fabric.  It did not succeed and the IP assets were bought
and the design team hired by Xilinx.

Microsemi (was Actel) had some ARM Cortex M1 and M3 processor
offerings, but the messaging around this was very confusing to me and
it was never clear to me if there was a hard option or if they was
only a soft option.  I don't believe that this received much traction
and I don't know what the fate was after the Microsemi acquistion.

Quicklogic had QuickMIPs that included a MIPS32 4Kc processor along
with their anti-fuse fabric.  I never saw much activity on this nor
understood why anyone thought that this made sense with an anti-fuse
one-time-programmable part.

Lattice Semiconductor has soft processors called LatticeMico8 and
LatticeMico32.

Xilinx has had a number of forays into this space including the Virtex-
II Pro and Virtex-4 FX families that included 1- hard PowerPC 405
cores.  The Virtex-5 FXT family that included 1-2 hard PowerPC 440
cores.  Soft processor cores are provided in the form of MicroBlaze
and PicoBlaze and are supported in every FPGA family since Virtex-II.
The next encarnation of a hard processor block will be present in the
recently announced family called Zynq-7000 and include a hard
implementation of dual ARM Cortex-A9 processors along with a FPGA
fabric.

In each of these cases the FPGA fabric and the processor, whether hard
or soft, was treated as a single entity to create a custom set of
peripherals around the processor to meet the needs that an off-the-
shelf processor couldn't.

Ed McGettigan
--
Xilinx Inc.

Article: 151194
Subject: Re: pcb&bitstream
From: Ed McGettigan <ed.mcgettigan@xilinx.com>
Date: Mon, 14 Mar 2011 18:28:24 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 14, 5:46=A0pm, Kolja Sulimma <ksuli...@googlemail.com> wrote:
> On 13 Mrz., 01:46, rickman <gnu...@gmail.com> wrote:
>
> > since a bad bitstream has potential of frying an FPGA.
>
> This argument is invalid.
>
> You can fry an FPGA with VDHL and vendor synthesis software.
> This has been demonstrated at the FPL conference a decade ago.
>
> I guess the truth is closer to this argument: documenting the
> bitstream format
> is a lot of work and is likely to create only very few additional
> revenue
> from customer that are rather support intensive so it simply isn't
> worthwhile for
> the vendors.
>
> I believe that documenting LUT content locations in the bitstream
> would be a good
> compromise. It is relatively easy to document and use and not much can
> go wrong
> and it has a decent amount of applications where it is useful.
> OTOH: The introduction of SRL16 made it easy to support LUT-reloading
> explicitely in the HDL.
>
> Kolja

> You can fry an FPGA with VDHL and vendor synthesis software.
> This has been demonstrated at the FPL conference a decade ago.

I am quite surprised about this. Can you provide any additional
material on how this was achieved?

There aren't any scenarios, other than internal tri-state contention,
that I can come up with to make this happen with a proven tool chain.

Ed McGettigan
--
Xilinx Inc.

Article: 151195
Subject: Re: pcb&bitstream
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Tue, 15 Mar 2011 01:58:55 +0000 (UTC)
Links: << >>  << T >>  << A >>
Ed McGettigan <ed.mcgettigan@xilinx.com> wrote:
> On Mar 14, 12:49 pm, geobsd <geobsd...@gmail.com> wrote:
>> On 12 Mrz., 05:27, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote:
>> "companies have been started and failed over the years
>> trying to mate FPGAs with CPUs
   "http://www.xilinx.com/technology/roadmap/processing-platform.htm
 
> When I wrote my original statement I was referring to the system
> architecture that you were trying to achieve, that is a high
> performance CPU connected directly with a FPGA for dynamic algorithm
> acceleration.

There is a whole conference for people interested in FPGA based
computing, that is FCCM.  FPGAs for Custom Computing Machines.

FPGA based co-processors for algorithm acceleration word fairly
well in fixed point, not so well in floating point.  There are a
few problems that need large amounts of computation.

Not so long ago, I was considering a project for genomics that
needs about 1e18 six bit add/subtract operations per day.  
I figured out that it could be done with about 2000 S3E devices,
though so far no interest in building one.

-- glen

Article: 151196
Subject: Re: pcb&bitstream
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Tue, 15 Mar 2011 02:02:05 +0000 (UTC)
Links: << >>  << T >>  << A >>
Kolja Sulimma <ksulimma@googlemail.com> wrote:
> On 13 Mrz., 01:46, rickman <gnu...@gmail.com> wrote:
>> since a bad bitstream has potential of frying an FPGA.
 
> This argument is invalid.
 
> You can fry an FPGA with VDHL and vendor synthesis software.
> This has been demonstrated at the FPL conference a decade ago.
 
(snip)
> I believe that documenting LUT content locations in the bitstream
> would be a good compromise. It is relatively easy to document 
> and use and not much can go wrong

They use to do that.  It was necessary to verify on readback when
RAM was in use, and the bits would change, such that you could mask
them out.  

> and it has a decent amount of applications where it is useful.
> OTOH: The introduction of SRL16 made it easy to support LUT-reloading
> explicitely in the HDL.

How much routing does that take?  

-- glen

Article: 151197
Subject: Re: pcb&bitstream
From: Ed McGettigan <ed.mcgettigan@xilinx.com>
Date: Mon, 14 Mar 2011 21:31:26 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 14, 7:02=A0pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
> Kolja Sulimma <ksuli...@googlemail.com> wrote:
> > On 13 Mrz., 01:46, rickman <gnu...@gmail.com> wrote:
> >> since a bad bitstream has potential of frying an FPGA.
> > This argument is invalid.
> > You can fry an FPGA with VDHL and vendor synthesis software.
> > This has been demonstrated at the FPL conference a decade ago.
>
> (snip)
>
> > I believe that documenting LUT content locations in the bitstream
> > would be a good compromise. It is relatively easy to document
> > and use and not much can go wrong
>
> They use to do that. =A0It was necessary to verify on readback when
> RAM was in use, and the bits would change, such that you could mask
> them out. =A0
>
> > and it has a decent amount of applications where it is useful.
> > OTOH: The introduction of SRL16 made it easy to support LUT-reloading
> > explicitely in the HDL.
>
> How much routing does that take? =A0
>
> -- glen

Nothing to speak of as the only nets are the DIN, CLK and CE.  The
SRLC16E, SRLC32E and SRLC64E primitives has two outputs Q and Q15/Q31/
Q63 so that the Q15/Q31/Q63 can be connected to the DIN of the next
SRLCxxE while the Q output is the result of the inputs.

The ChipScope ILA core uses this method to load the trigger controls.

Ed McGettigan
--
Xilinx Inc.

Article: 151198
Subject: Re: pcb&bitstream
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Tue, 15 Mar 2011 05:51:09 +0000 (UTC)
Links: << >>  << T >>  << A >>
Ed McGettigan <ed.mcgettigan@xilinx.com> wrote:

(snip, someone wrote)
>> > and it has a decent amount of applications where it is useful.
>> > OTOH: The introduction of SRL16 made it easy to support LUT-reloading
>> > explicitely in the HDL.

(then I wrote)
>> How much routing does that take?  
 
> Nothing to speak of as the only nets are the DIN, CLK and CE.  The
> SRLC16E, SRLC32E and SRLC64E primitives has two outputs Q and Q15/Q31/
> Q63 so that the Q15/Q31/Q63 can be connected to the DIN of the next
> SRLCxxE while the Q output is the result of the inputs.

But they have to route everywhere, and for ROMs I don't need
any such nets at all.

So, say a design has 300 ROMs that are 16x2.  (16 words of two bits.)
I need to get the CE to all the ROM/SRL16's, chain the DIN to
the DOUT of the previous one, and get a CLK to them.  I suppose
the CLK comes from the global clock tree, so doesn't need any
other routing resources.  Also, this doesn't have to be at the 
full speed on the rest of the design, so can use slower (longer)
routes without any penalty.

To be more specific, the idea is to get a search pattern in
for a systolic array search processor.  Without this, I would just
find the bits in the bitstream and stuff the appropriate data
into them.
 
> The ChipScope ILA core uses this method to load the trigger controls.

-- glen

Article: 151199
Subject: Re: pcb&bitstream
From: whygee <yg@yg.yg>
Date: Tue, 15 Mar 2011 07:53:05 +0100
Links: << >>  << T >>  << A >>
Ed McGettigan wrote:
<snip>
> In each of these cases the FPGA fabric and the processor, whether hard
> or soft, was treated as a single entity to create a custom set of
> peripherals around the processor to meet the needs that an off-the-
> shelf processor couldn't.

Thank you Ed for yet another post which could become the basis for
a wikipedia article :-) though yes, i know, "references needed"...

the new Actel/Microsemi solution with the ARM hard core
has many benefits compared to the usual FPGA vendors,
but it makes most sense in the industrial/automation/robotic
world, where the direct analog I/O cuts component count
for room/power/security sensitive applications (aerospace, for example)
but not for cost sensitive applications... the same old problem !

I love their original Fusion devices though i use the cost-conscious,
less integrated ProASIC3 parts, which give me just what I want, and I can
add a cheap peripheral (external ADC or Flash storage for example)
if needed. I suppose that everybody does the same...

> Ed McGettigan
yg
-- 
http://ygdes.com / http://yasep.org



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